Network system and message processing method

Abstract

The present application relates to the technical field of networks. Disclosed are a network system and a message processing method, which can accurately feed back congestion information of a device in a network system. When a transmission process of a message needs to pass through a target network in a network system, at an ingress device of the target network, congestion marking information is added to a message header in the message that is related to a transmission protocol of the target network, such that a network device in the target network can adjust the congestion marking information in the message header on the basis of a message congestion condition of the present device when the message is transmitted. Moreover, at an egress device of the target network, the message congestion condition is fed back on the basis of the congestion marking information in the message header, such that a congestion condition of the message in any network can be fed back.

Description

Network system and message processing method

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on June 30, 2023, with application number 202310801661.3 and invention name “A message transmission method, device and network system”, and the Chinese patent application filed with the State Intellectual Property Office on August 3, 2023, with application number 202310975598.5 and invention name “A network system and message processing method”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a network system and a message processing method. Background Art

[0003] In the communications field, Low Latency, Low Loss, and Scalable Throughput (L4S) technology is a congestion information feedback technology that aims to achieve low-latency and high-throughput message transmission.

[0004] When L4S technology is applied during packet transmission, network devices will mark the current packet congestion status in the Internet Protocol (IP) header of the message when transmitting the message, thereby feeding back the congestion status to other devices in the network. In this way, the sender of the message in the network, after learning the congestion status of the message during transmission, can adaptively adjust the message sending rate based on the congestion level, thereby achieving low latency and high throughput for message transmission and reception.

[0005] However, when a network system involves multiple networks, it may be difficult to obtain accurate congestion information of the network system.

[0006] Summary of the Invention

[0007] The present application provides a network system that can accurately feedback congestion information of devices in the network system.

[0008] In a first aspect, the present application provides a network system comprising: a first network device, a second network device, and a third network device, wherein the first network device and the third network device are edge devices of a target network, and the second network device is a device in the target network. That is, the second network device is located between the first network device and the third network device.

[0009] The first network device is used to generate a second message based on the received first message and send the second message to the device in the target network. The second message includes a first message header related to the transmission protocol of the target network, that is, the format of the first message header is defined by the transmission protocol used by the target network. The first message header includes congestion marking information, and the congestion marking information is generated by the first network device based on the content in the first message. For example, the congestion marking information in the first message header is generated by the first network device based on the message congestion information in the IP message header or other message header in the first message. In addition, the first message does not include a message header related to the transmission protocol of the target network, that is, the first message header in the second message is newly encapsulated by the first network device.

[0010] The second network device is configured to forward packets transmitted on a target network. During packet forwarding, the second network device determines whether to modify congestion marking information in a target packet header of the forwarded packet based on packet congestion conditions on the second network device. The target packet header is related to the transmission protocol of the target network. Specifically, if packet congestion occurs on the second network device, the second network device modifies the congestion marking information in the target packet header to indicate that the packet is congested. If packet congestion does not occur on the second network device, the second network device does not need to modify the congestion marking information in the target packet header.

[0011] The third network device is configured to feed back a message congestion condition according to congestion marking information in a second message header in a third message received from the target network, where the second message header is related to a transmission protocol of the target network.

[0012] In this solution, when the transmission process of a message needs to pass through a target network that adopts a specific transmission protocol, congestion marking information is added to the message header related to the transmission protocol of the target network at the ingress device of the target network. This allows the network devices in the target network to adjust the congestion marking information in the message header based on the message congestion situation on this device when transmitting the message. Furthermore, at the egress device of the target network, the message congestion situation is fed back based on the congestion marking information in the message header, thereby enabling the congestion situation of the message in any network to be fed back. In addition, because the congestion marking information is added to the message header related to the transmission protocol of the target network in the message in this solution, the network devices in the target network only need to adjust the message header related to the transmission protocol of the target network in the message according to the actual congestion situation, without having to deeply detect the inner message header in the message, which can effectively improve the processing efficiency of the ground message.

[0013] In one possible implementation, the congestion marking information in the first packet header is an L4S flag. Specifically, when the value of the L4S flag in the first packet header is 01, it indicates that the packet supports the LS4 marking mechanism. Therefore, when congestion occurs in the packet, the network device in the target network can modify the value of the L4S flag in the packet to reflect the congestion status. When the value of the L4S flag in the first packet header is 11, it indicates that the packet has been marked as congested, indicating that congestion has occurred in the network device.

[0014] In this solution, by adding the L4S identifier as congestion marking information to the message header related to the transmission protocol of the target network, the L4S mechanism can be used to feedback the message congestion situation during the message transmission process on the target network, thereby improving the applicability of the L4S mechanism in various network scenarios and reducing changes to existing technologies.

[0015] In one possible implementation, when the transport protocol of the target network is Segment Routing Transport Profile (SR-TP), the first packet header is an SR-TP packet header, and the congestion marking information is carried in a real-time transport protocol extension field in the SR-TP packet header.

[0016] Alternatively, when the transmission protocol of the target network is Segment Routing IPv6 (SRv6) based on the Internet Protocol version 6 (IPv6) forwarding plane, the first packet header is an SRv6 packet header, and the congestion marking information is carried in the IPv6 address field of the SRv6 packet header.

[0017] In this solution, by carrying congestion marking information in the message header extension field corresponding to the transmission protocol used by the target network, congestion feedback can be implemented in existing specific scenarios, thereby improving the applicability of the solution and reducing changes to existing technologies.

[0018] In one possible implementation, a third network device is configured to generate a fourth message based on the third message and send the fourth message to a device outside the target network. The fourth message no longer includes a message header related to the target network's transmission protocol, and the fourth message includes congestion information about the first message. The first message congestion information in the fourth message is generated based on congestion marking information in a message header related to the target network's transmission protocol in the third message, and the first message congestion information can be used to indicate congestion during message transmission.

[0019] In this solution, at the egress device of the target network, message congestion information is generated based on the congestion marking information in the message header, and the message congestion information is carried in the message sent to the device outside the target network, ensuring that the congestion situation encountered by the message in the target network can be reflected in subsequent messages, thereby realizing feedback on the message congestion situation.

[0020] In one possible implementation, the first message congestion information is carried in an Internet Protocol (IP) header of the fourth message. Furthermore, the first message congestion information is represented by an L4S identifier. The first message congestion information is used to indicate a congestion condition during message transmission.

[0021] That is to say, the first network device at the entrance of the target network sets the newly encapsulated message header corresponding to the target network based on the L4S identifier in the message entering the target network, and then the network device in the target network adjusts the value of the L4S identifier in the message header corresponding to the target network according to the congestion situation. Finally, the third network device at the exit of the target network processes the message leaving the target network to map the value of the L4S identifier in the message header corresponding to the target network to the IP message header of the message, thereby realizing feedback on the congestion situation in the target network.

[0022] In one possible implementation, the congestion information of the first message is obtained by copying the congestion marking information in the message header related to the transport protocol of the target network in the third message. For example, assuming that the value of the L4S indicator in the inner IP message header of the third message is 01, and the value of the L4S indicator in the outer message header corresponding to the mobile bearer network of the third message (i.e., the congestion marking information in the third message) is 11, the value of the L4S indicator in the inner IP message header of the fourth message (i.e., the congestion marking information in the first message) can be replaced with 11.

[0023] Alternatively, the first message congestion information is obtained by performing a logical OR operation on the congestion marking information in the message header related to the transport protocol of the target network in the third message and the second message congestion information in the IP message header of the third message. For example, assuming that the value of the L4S identifier in the inner IP message header of the third message is 01, and the value of the L4S identifier in the outer message header corresponding to the mobile bearer network of the third message is 11, then the result of the logical OR operation of these two L4S identifier values ​​is 11, and therefore the value of the L4S identifier in the inner IP message header of the fourth message is replaced with 11.

[0024] Alternatively, the first message congestion information is obtained by performing a logical OR operation on the congestion marking information in the message header related to the transport protocol of the target network in the third message, the second message congestion information in the IP message header of the third message, and the third message congestion information in the GTP message header of the third message. For example, assuming that the value of the L4S identifier in the inner IP message header of the third message is 01, the value of the L4S identifier in the GTP message header of the third message is 01, and the value of the L4S identifier in the outer message header corresponding to the mobile bearer network of the third message is 11, then the result of the logical OR operation of the three L4S identifier values ​​is 11, and therefore the value of the L4S identifier in the inner IP message header of the fourth message is replaced with 11.

[0025] In this solution, in different scenarios, different methods are used to map the congestion marking information in the outer layer of the message header related to the transmission protocol of the target network to the inner layer of the message header. This can ensure that any congestion that occurs when the message passes through any network can be reflected through the message congestion information in the inner layer message header.

[0026] In a possible implementation, the congestion marking information in the first packet header of the second packet is generated by the first network device according to the fourth congestion information in the IP packet header of the first packet, for example, according to the L4S identifier in the IP packet header of the first packet.

[0027] In one possible implementation, the congestion marking information includes a flag bit consisting of one or more bits. Different flag bit values ​​are used to indicate whether a packet is congested or not. For example, the congestion marking information includes a two-bit flag bit. A flag bit value of 01 indicates that the packet is not congested, while a flag bit value of 11 indicates that the packet is congested.

[0028] In a possible implementation, the first network device is a boundary device between the first network and the target network, the third network device is a boundary device between the target network and the second network, and the target network is used to connect the first network and the second network.

[0029] In one possible implementation, the first network is a radio access network (RAN), the target network is a mobile bearer network, and the second network is a core network; or, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0030] By applying this solution in the mobile bearer network located between the RAN and the core network, it is possible to feedback the congestion situation of messages passing through the mobile bearer network, ensuring the application of the message congestion feedback mechanism in specific scenarios, and avoiding the need to detect the deep message headers of messages when they are on the mobile bearer network, thereby improving the efficiency of message processing.

[0031] In a possible implementation, the first network device is a core network device or a provider edge (PE) device of a target network, and the third network device is a RAN device or a PE device of the target network.

[0032] In a possible implementation manner, the first network device is a RAN device or a PE device of the target network, and the third network device is a core network device or a PE device of the target network.

[0033] In one possible implementation, the third network device is a RAN device, and the third network device is further configured to send a congestion report message to a device in the core network when determining that congestion has occurred during transmission of the third message. The congestion report message is used to indicate that congestion has occurred in the message.

[0034] In a possible implementation, a device in the core network is configured to perform congestion marking on a passing packet based on a congestion report message;

[0035] Alternatively, the device in the core network is used to notify the server of message congestion based on the congestion report message.

[0036] A second aspect of the present application provides a message processing method, which is applied to a first network device, the first network device being a boundary device of a target network. In this method, the first network device receives a first message and generates a second message based on the first message, wherein the first message does not include a message header related to the transmission protocol of the target network, and the second message includes a first message header related to the transmission protocol of the target network, and the first message header includes congestion marking information, which is generated by the first network device based on the content of the first message, and the congestion marking information is used to indicate the congestion status of the message during transmission; then, the first network device sends the second message to a device in the target network.

[0037] In a possible implementation, the congestion marking information in the first packet header is an L4S identifier.

[0038] In a possible implementation, the first packet header is an SR-TP packet header, and the congestion marking information is carried in a real-time transport protocol extension field in the SR-TP packet header;

[0039] Alternatively, the first packet header is an SRv6 packet header, and the congestion marking information is carried in an IPv6 address field of the SRv6 packet header.

[0040] In a possible implementation, the first network device is a boundary device between the first network and the target network, and the target network is used to connect the first network and the second network.

[0041] In one possible implementation, the first network is a RAN, the target network is a mobile bearer network, and the second network is a core network;

[0042] Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0043] A third aspect of the present application provides a message processing method, which is applied to a third network device, the third network device being a border device of a target network. In the method, the third network device receives a third message from the target network, wherein a second message header in the third message includes congestion marking information, and the second message header is related to a transmission protocol of the target network;

[0044] The third network device feeds back the message congestion situation according to the congestion marking information in the second message header.

[0045] In one possible implementation, the third network device feeds back the message congestion situation based on the congestion marking information in the second message header, specifically including: the third network device generates a fourth message based on the third message, the fourth message includes the congestion information of the first message, the first message congestion information is generated based on the congestion marking information in the message header related to the transmission protocol of the target network in the third message, and the fourth message does not include the message header related to the transmission protocol of the target network; then, the third network device sends the fourth message to a device outside the target network.

[0046] In a possible implementation, the first message congestion information is carried in an Internet Protocol (IP) message header of the fourth message, and the first message congestion information is used to indicate a congestion condition of the message during transmission.

[0047] In a possible implementation, the first message congestion information is obtained by performing a logical OR operation on congestion marking information in a message header related to a transmission protocol of a target network in a third message and the second message congestion information in an IP message header of the third message;

[0048] Alternatively, the first message congestion information is obtained by performing a logical OR operation on the congestion marking information in the message header related to the transmission protocol of the target network in the third message, the second message congestion information in the IP message header of the third message, and the third message congestion information in the GTP message header of the third message.

[0049] In a possible implementation, the congestion marking information in the first packet header is generated by the first network device according to the fourth congestion information in the IP packet header in the first packet.

[0050] In a possible implementation, the congestion marking information includes a marking bit consisting of one or more bits, and different values ​​of the marking bit are used to indicate whether congestion occurs in the message or not.

[0051] In a possible implementation, the third network device is a boundary device between the target network and the second network, and the target network is used to connect the first network and the second network.

[0052] In one possible implementation, the first network is a RAN, the target network is a mobile bearer network, and the second network is a core network;

[0053] Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0054] In one possible implementation, the third network device is a RAN device, and the third network device is further configured to send a congestion report message to a device in the core network when determining that congestion has occurred during transmission of the third message. The congestion report message is used to indicate that congestion has occurred in the message.

[0055] A fourth aspect of the present application provides a message processing device, which is deployed on a first network device, which is a boundary device of a target network. The message processing device includes: a receiving module for receiving a first message; a processing module for generating a second message based on the first message, wherein the first message does not include a message header related to the transmission protocol of the target network, and the second message includes a first message header related to the transmission protocol of the target network, and the first message header includes congestion marking information, which is generated by the first network device based on the content of the first message, and the congestion marking information is used to indicate the congestion status of the message during transmission; and a sending module for sending the second message to a device in the target network.

[0056] In a possible implementation, the congestion marking information in the first packet header is an L4S identifier.

[0057] In a possible implementation, the first packet header is an SR-TP packet header, and the congestion marking information is carried in a real-time transport protocol extension field in the SR-TP packet header;

[0058] Alternatively, the first packet header is an SRv6 packet header, and the congestion marking information is carried in an IPv6 address field of the SRv6 packet header.

[0059] In a possible implementation, the first network device is a boundary device between the first network and the target network, and the target network is used to connect the first network and the second network.

[0060] In one possible implementation, the first network is a RAN, the target network is a mobile bearer network, and the second network is a core network;

[0061] Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0062] A fifth aspect of the present application provides a message processing apparatus, which is deployed on a third network device, the third network device being an edge device of a target network. The message processing apparatus includes: a receiving module configured to receive a third message from the target network, wherein a second message header in the third message includes congestion marking information, the second message header being related to the transmission protocol of the target network; and a sending module configured to provide feedback on message congestion based on the congestion marking information in the second message header.

[0063] In one possible implementation, the message processing device also includes a processing module for generating a fourth message based on the third message, the fourth message including congestion information of the first message, the first message congestion information being generated based on congestion marking information in a message header related to the transmission protocol of the target network in the third message, and the fourth message does not include a message header related to the transmission protocol of the target network; and a sending module specifically for sending the fourth message to a device outside the target network.

[0064] In a possible implementation, the first message congestion information is carried in an IP message header of the fourth message, and the first message congestion information is used to indicate a congestion condition of the message during transmission.

[0065] In a possible implementation, the first message congestion information is obtained by performing a logical OR operation on congestion marking information in a message header related to a transmission protocol of a target network in a third message and the second message congestion information in an IP message header of the third message;

[0066] Alternatively, the first message congestion information is obtained by performing a logical OR operation on the congestion marking information in the message header related to the transmission protocol of the target network in the third message, the second message congestion information in the IP message header of the third message, and the third message congestion information in the GTP message header of the third message.

[0067] In a possible implementation, the congestion marking information in the first packet header is generated by the first network device according to the fourth congestion information in the IP packet header in the first packet.

[0068] In a possible implementation, the congestion marking information includes a marking bit consisting of one or more bits, and different values ​​of the marking bit are used to indicate whether congestion occurs in the message or not.

[0069] In a possible implementation, the third network device is a boundary device between the target network and the second network, and the target network is used to connect the first network and the second network.

[0070] In one possible implementation, the first network is a RAN, the target network is a mobile bearer network, and the second network is a core network;

[0071] Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0072] In a possible implementation, the third network device is a RAN device, and the sending module is further used to send a congestion report message to a device in the core network when it is determined that congestion has occurred during the transmission of the third message. The congestion report message is used to indicate that congestion has occurred in the message.

[0073] In a sixth aspect, the present application provides a network device comprising a processor and a memory, wherein the memory is used to store program code, and the processor is used to call the program code in the memory to enable the network device to execute the method of any one of the implementations of the second or third aspects.

[0074] In a seventh aspect, the present application provides a computer-readable storage medium storing instructions, which, when executed on a computer, enables the computer to execute a method as in any one of the embodiments of the first aspect.

[0075] An eighth aspect of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute a method as in any one of the embodiments of the first aspect.

[0076] In a ninth aspect, the present application provides a chip comprising one or more processors. Part or all of the processors are used to read and execute computer instructions stored in a memory to execute the method in any possible implementation of any of the above aspects. Optionally, the chip also includes a memory. Optionally, the chip also includes a communication interface, and the processor is connected to the communication interface. The communication interface is used to receive data and / or information to be processed, the processor obtains data and / or information from the communication interface, processes the data and / or information, and outputs the processing results through the communication interface. Optionally, the communication interface is an input / output interface or a bus interface. The method provided in the present application is implemented by one chip, or by multiple chips working together.

[0077] The solutions provided in the second to ninth aspects are used to implement or cooperate with the method provided in the first aspect, and therefore can achieve the same or corresponding beneficial effects as the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] FIG1 is a schematic diagram of an L4S architecture provided in an embodiment of the present application;

[0079] FIG2 is a schematic diagram of a message transmission process in a mobile communication network provided in an embodiment of the present application;

[0080] FIG3 is a schematic diagram of a message transmission process of another mobile communication network provided in an embodiment of the present application;

[0081] FIG4 is a schematic diagram of an encapsulation format of a message header corresponding to the SR-TP protocol provided in an embodiment of the present application;

[0082] FIG5 is a schematic diagram of an encapsulation format of a message header corresponding to the SRv6 protocol provided in an embodiment of the present application;

[0083] FIG6 is a schematic diagram of a message transmitted in a target network of a network system according to an embodiment of the present application;

[0084] FIG7 is a schematic diagram of a process of transmitting a message through multiple network devices according to an embodiment of the present application;

[0085] FIG8 is a schematic diagram of the architecture of a network system provided in an embodiment of the present application;

[0086] FIG9 is a schematic diagram of a processing flow of a message during downlink transmission in a mobile communication network according to an embodiment of the present application;

[0087] FIG10 is a schematic diagram of a congestion feedback process provided by an embodiment of the present application;

[0088] FIG11 is a schematic diagram of another congestion feedback process provided in an embodiment of the present application;

[0089] FIG12 is a schematic diagram of another congestion feedback process provided in an embodiment of the present application;

[0090] FIG13 is a schematic diagram of a processing flow of a message during uplink transmission on a mobile communication network according to an embodiment of the present application;

[0091] FIG14 is a flowchart illustrating a process of a message passing through a mobile bearer network according to an embodiment of the present application;

[0092] FIG15 is a schematic structural diagram of a message processing device provided in an embodiment of the present application;

[0093] FIG16 is a schematic diagram of the structure of a network device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0094] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present application, not all of the embodiments. Those skilled in the art will appreciate that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0095] The terms "first", "second" and the like in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0096] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0097] Generally speaking, L4S technology involves processing at both the transport and IP layers. The sending and receiving ends of packets are primarily responsible for processing the transport layer. The network devices involved in packet transmission are responsible for processing the IP layer. Their core purpose is to provide timely feedback to the sending end regarding network congestion. Upon receiving this feedback, the sending end adjusts the congestion window size based on the level of congestion on the network device, thereby achieving low latency and high throughput for packet transmission and reception.

[0098] Please refer to Figure 1, which is a schematic diagram of an L4S architecture provided in an embodiment of the present application. As shown in Figure 1, when the sending end supports the L4S mechanism, for a message sent by the sending end, the 2-bit Explicit Congestion Notification (ECN) flag in the IP message header is set to 01 to indicate that the message is an L4S message.

[0099] When a message sent by a sender passes through a network node between the sender and receiver, the node marks the message with a certain probability based on the level of message congestion at the node, indicating whether the message is experiencing congestion. Specifically, after receiving a message, the node first identifies the 2-bit ECN flag in the IP header to determine whether the received message supports the L4S mechanism. The meaning of each ECN flag value is shown in Table 1.

[0100] Table 1

[0101] As shown in Table 1, when the ECN flag value in a packet is 01, it indicates that the packet supports the L4S mechanism. When the ECN flag value in a packet is 11, it indicates that the packet supports L4S marking and has been marked as over-congested. In other words, when the ECN flag value in a packet is 01 or 11, the packet is classified as an L4S data flow; otherwise, the packet is classified as a classic data flow.

[0102] When network nodes implement packet marking, the node's queue is set with a small and large threshold, and packets are marked before entering the queue. When the queue length q in the network node is less than the small threshold, no packets are marked. When the queue length q is between the small threshold (denoted as qlow) and the large threshold (denoted as qhigh), packets are marked with a probability of (q-qlow) / (qhigh-qlow). When the queue length exceeds the large threshold, all packets entering the queue are marked.

[0103] After receiving a message marked as congested, the receiver reports the congestion to the sender, for example, using an Acknowledgment (ACK) message in the Transmission Control Protocol (TCP).

[0104] After sending a message, the sender will receive a reply message from the receiver. The reply message contains a 1-bit flag bit, which is used to indicate whether the corresponding IP message is marked as congested. The sender can obtain the proportion of marked messages under the current congestion window by counting the total number of messages in a congestion window and the number of marked messages. The proportion of marked messages is recorded as M. Define a variable α to represent the congestion window adjustment ratio on the end side; g is the estimated gain, ranging from [0,1]; then, the congestion window adjustment ratio is updated according to the following formula: α = α × (1-g) + g × M. After obtaining α, the congestion window is updated according to the following formula:

[0105] During message transmission, the network system through which the message passes may include multiple networks. For example, the network system includes a first network, a second network, and a third network, where the first network and the third network are connected via the second network. The following description uses a mobile communication network as an example. It is understood that the technical solutions provided in this application can also be applied to other network systems and are not limited to mobile communication networks.

[0106] The mobile communication network may include a radio access network (RAN), a mobile bearer network and a core network, and the access network and the core network are connected through the mobile bearer network. Please refer to Figures 2 and 3, Figure 2 is a schematic diagram of a message transmission process of a mobile communication network provided in an embodiment of the present application, and Figure 3 is a schematic diagram of a message transmission process of another mobile communication network provided in an embodiment of the present application. As shown in Figures 2 and 3, the mobile communication networks shown in Figures 2 and 3 both include RAN, a mobile bearer network and a core network. The difference is that the transmission protocol used by the mobile bearer network in the mobile communication network shown in Figure 2 is a transport-oriented segment routing (SR-TP) protocol, and the transmission protocol used by the mobile bearer network in the mobile communication network shown in Figure 3 is a segment routing (SRv6) protocol based on the IPv6 forwarding plane.

[0107] As shown in Figures 2 and 3, as a message passes through the mobile bearer network, a header is added layer by layer (i.e., a new header is encapsulated on the outer layer of the message) to support transmission at a specific network stage. In Figure 2, when the message passes through the RAN or core network, a header corresponding to the GPRS Tunneling Protocol (GTP) is added; when the message passes through the mobile bearer network, a header corresponding to the SR-TP protocol is added. In Figure 3, when the message passes through the RAN or core network, a header corresponding to the GTP protocol is added; when the message passes through the mobile bearer network, a header corresponding to the SR v6 protocol is added.

[0108] In addition, in the mobile bearer network, the encapsulation format of the message header corresponding to the SR-TP protocol is shown in Figure 4, and the encapsulation format of the message header corresponding to the SRv6 protocol is shown in Figure 5. For specific format descriptions, please refer to the standard documents RFC3711 and RFC8754 respectively, and will not be repeated here.

[0109] The inventors have found that, at present, when a message needs to be transmitted through multiple networks, the congestion encountered by the message in some networks of the multiple networks may be difficult to feedback through the L4S mechanism. Taking the mobile communication network as an example, when the message passes through the mobile bearer network located between the RAN and the core network, it often encapsulates a layer of the message header of the transmission protocol used by the mobile bearer network (such as SR-TP or SRv6), and realizes the transmission of the message in the mobile bearer network based on the newly encapsulated message header. Because the network equipment in the mobile bearer network only detects the information in the message header corresponding to the mobile bearer network when forwarding the message, and the message will strip off the message header corresponding to the mobile bearer network when leaving the mobile bearer network, it is often difficult to feedback the congestion situation of the message in the mobile bearer network. Based on this, an embodiment of the present application provides a network system and a message processing method. When the message transmission process needs to pass through a target network that adopts a specific transmission protocol, at the ingress device of the target network, congestion marking information is added to the message header in the message related to the transmission protocol of the target network, so that the network device in the target network can adjust the congestion marking information in the message header based on the message congestion situation on the device when transmitting the message. In addition, at the egress device of the target network, message congestion information is generated based on the congestion marking information in the message header, and the message congestion information is carried in the message sent to the device outside the target network, ensuring that the congestion situation encountered by the message in the target network can be reflected in subsequent messages, thereby enabling the congestion situation in any network to be fed back.

[0110] To facilitate understanding, the following will describe in detail the process of processing messages by the network system and the devices in the network system provided in this embodiment with reference to the accompanying drawings.

[0111] Please refer to Figure 6, which is a schematic diagram of a message transmitted in a target network of a network system according to an embodiment of the present application. As shown in Figure 6, the network system includes a first network device, a second network device, and a third network device. The first network device and the third network device are boundary devices of the target network, and the second network device is a device in the target network. In addition, the first network device and the second network device can be directly connected, and other network devices can be connected between the first network device and the second network device; similarly, the second network device and the third network device can be directly connected, and other network devices can be connected between the second network device and the third network device. This embodiment does not limit the number of network devices included in the target network.

[0112] Optionally, the first network device, the second network device, and the third network device are physical devices such as routers, gateways, switches, or firewalls. Alternatively, the first network device, the second network device, and the third network device are virtualized devices deployed on hardware devices, such as virtual gateways or virtual switches.

[0113] In a network system, the message transmission direction is, for example, from a first network device to a second network device to a third network device, i.e., the first network device is the ingress device of the target network, and the third network device is the egress device of the target network. Alternatively, the message transmission direction is from the third network device to the second network device to the first network device. The message transmission direction may vary in different message transmission scenarios (e.g., uplink and downlink message transmission scenarios), and this embodiment does not limit the message transmission direction.

[0114] For ease of description, the following description will be made by taking the transmission direction of the message as the first network device → the second network device → the third network device as an example.

[0115] At the ingress of the target network, after receiving the message, the first network device encapsulates a new message header based on the received message (for example, encapsulating the new message header in the outermost layer or in the middle of the received message), thereby generating a message encapsulated with the new message header. The newly encapsulated message header by the first network device is a message header corresponding to the transmission protocol used by the target network, that is, the format of the newly encapsulated message header by the first network device is defined by the transmission protocol used by the target network.

[0116] For example, assuming that the message received by the first network device is a first message, the first network device generates a second message based on the received first message and sends the second message to the target network. Compared to the first message, the second message includes a first message header related to the transmission protocol of the target network, while the first message does not include a message header related to the transmission protocol of the target network. The first message header includes congestion marking information, which is generated by the first network device based on the content of the first message. For example, the congestion marking information in the first message header is generated by the first network device based on message congestion information in the IP message header or other message headers in the first message.

[0117] Optionally, the congestion marking information includes a marking bit consisting of one or more bits, and different values ​​of the marking bit are used to indicate that the message is congested and that the message is not congested. For example, the congestion marking information in the first message header is, for example, an L4S identifier, and the value of the L4S identifier in the first message header can be determined based on the L4S identifier in the IP message or other message header in the first message. That is, the congestion marking information in the first message header is a 2-bit marking bit, which can be used to implement congestion marking under the L4S mechanism. When the value of the L4S identifier in the message is 01, it means that the message supports the LS4 marking mechanism, so the network device can modify the value of the L4S identifier in the message when congestion occurs to reflect the congestion situation of the message; when the value of the L4S identifier in the message is 11, it means that the message has been marked as congested, that is, the message has been congested in the network device.

[0118] The format of the first header in the second message is related to the transport protocol of the target network. For example, when the transport protocol of the target network is Segment Routing Transport Profile (SR-TP), the first header is an SR-TP header; or when the transport protocol of the target network is Segment Routing IPv6 (SRv6), the first header is an SRv6 header.

[0119] It should be noted that, when generating the first packet header, the first network device, as a border device of the target network, may also determine the content of the congestion marking information in the first packet header based on the packet congestion status of the first network device. For example, when packet congestion occurs in the first network device, the congestion marking information in the first packet header generated by the first network device may indicate that packet congestion has occurred.

[0120] In the target network, the second network device is responsible for forwarding packets transmitted within the target network. During packet forwarding, the second network device determines whether to modify the congestion marking information in the target packet header of the forwarded packets based on the packet congestion status within the second network device. The target packet header refers to a packet header associated with the transmission protocol of the target network. For example, assuming that the congestion marking information in the target packet header of the packet forwarded by the second network device is represented by an L4S identifier, and the value of the L4S identifier is 01, this indicates that the packet has not experienced congestion before the second network device. When packet congestion occurs at the second network device, the second network device modifies the value of the L4S identifier in the target packet header to 11 to indicate that the packet is congested.

[0121] Among them, there are many ways for the second network device to determine whether to modify the congestion marking information in the target message header based on the message congestion situation, and this embodiment does not specifically limit this. For example, the second network device can determine whether to modify the congestion marking information in the target message header based on the L4S message marking mechanism introduced above, that is, the second network device sets a large threshold and a small threshold, and determines whether to modify and how to modify the congestion marking information in the target message header by comparing the large threshold and the small threshold with the number of messages in the message queue. For another example, if the message in the second network device is congested, the second network device modifies the congestion marking information in the target message header to indicate that the message is congested; if the message in the second network device is not congested, the second network device does not modify the congestion marking information in the target message header.

[0122] In general, when message congestion occurs on the second network device, the second network device can indicate that message congestion occurs by modifying the congestion marking information in the target message header; when message congestion does not occur on the second network device, the second network device does not need to modify the congestion marking information in the target message header.

[0123] At the egress of the target network, after receiving a message from the target network, the third network device generates a new message by decapsulating the message header related to the target network's transmission protocol in the message. Moreover, in the process of the third network device generating a new message, message congestion information can be generated in the new message based on the congestion marking information carried in the message header related to the target network's transmission protocol, so as to ensure that the message can still reflect the congestion situation encountered by the message in the target network after decapsulating the message header related to the target network's transmission protocol. Alternatively, in the process of generating a new message, the third network device may not generate message congestion information in the new message, but may feedback the message congestion situation in other ways (for example, sending a congestion report message to a device outside the target network).

[0124] In general, after receiving a message from the target network, the third network device obtains the message congestion status based on the congestion marking information in the message header related to the transmission protocol of the target network in the message, and feeds back the message congestion status to other devices.

[0125] For example, assume that a third network device receives a third message from a target network. The third network device generates a fourth message based on the third message and sends the fourth message to a device outside the target network. The fourth message no longer includes a message header related to the target network's transmission protocol, and the fourth message includes congestion information about the first message. The first message congestion information in the fourth message is generated based on the congestion marking information in the message header related to the target network's transmission protocol in the third message. The first message congestion information can be used to indicate congestion during message transmission.

[0126] Optionally, the first message congestion information is carried in an Internet Protocol (IP) header of the fourth message. Furthermore, the first message congestion information is represented by an L4S identifier. That is, the first network device at the entrance of the target network copies the L4S identifier of the IP header of the message entering the target network to the newly encapsulated message header corresponding to the target network. The network device in the target network then adjusts the value of the L4S identifier in the message header corresponding to the target network according to the congestion situation. Finally, the third network device at the exit of the target network processes the message leaving the target network to map the value of the L4S identifier in the message header corresponding to the target network to the IP header of the message, thereby providing feedback on the congestion situation in the target network.

[0127] Furthermore, as a border device of the target network, the third network device may also, when generating the fourth message, determine the first message congestion information in the fourth message based on the message congestion status of the third network device and the congestion marking information in the message header related to the transmission protocol of the target network in the third message. For example, if message congestion occurs in the third network device and the congestion marking information in the message header related to the transmission protocol of the target network in the third message indicates that the message is not congested, the first congestion information in the fourth message generated by the third network device may also indicate that the message is congested.

[0128] To facilitate understanding of the changes that occur to a message as it passes through the target network, the following describes in detail the changes to the message during transmission, taking the second network device as the next hop device of the first network device, and the third network device as the next hop device of the second network device, as an example. It should be noted that the embodiments of this application are merely examples provided to facilitate description of message transformation. In actual applications, other network devices may be connected between the first and second network devices, and between the second and third network devices.

[0129] Please refer to FIG. 7 , which is a flow chart of a message transmitted through multiple network devices according to an embodiment of the present application.

[0130] As shown in Figure 7, a first network device, acting as the ingress device to the target network, receives a first packet from outside the target network. The first packet includes an IP header, which includes an L4S flag. Furthermore, the value of the L4S flag in the IP header of the first packet is 01, indicating that the first packet supports the L4S mechanism and has not experienced congestion.

[0131] After receiving the first message, the first network device encapsulates a new message header for the first message, such as an SR-TP message header, to obtain a second message. In addition, while the first network device is encapsulating the new message header for the first message, the first network device can also modify part of the content in the original message header in the first message, so that the second message includes the modified content in the first message and the newly encapsulated SR-TP message header. Moreover, when the first network device encapsulates the SR-TP message header, the first network device copies the L4S identifier in the IP message header of the first message to the SR-TP message header, so that the SR-TP message header also carries the L4S identifier, and the value of the L4S identifier in the SR-TP message header is also 01.

[0132] After generating the second message, the first network device sends the second message to the second network device, which then forwards the second message. Upon receiving the second message, the second network device, based on the message congestion on its own device, modifies the value of the L4S flag in the SR-TP header of the second message to 11, thereby generating a third message. The value of the L4S flag in the SR-TP header of the third message is 11, indicating that congestion has occurred in the third message.

[0133] After generating the third message, the second network device sends the third message to a third network device at the destination network egress. After receiving the third message, the third network device removes the SR-TP header from the third message to obtain a fourth message. Furthermore, the third network device modifies the L4S flag in the IP header of the fourth message based on the L4S flag in the SR-TP header of the third message, specifically, changing the value of the L4S flag in the IP header of the fourth message to 11.

[0134] In this way, even if the message header corresponding to the target network is stripped after the message passes through the target network, the congestion situation of the message in the target network can be mapped to the IP message header, thereby realizing feedback on the congestion situation of the message in the target network.

[0135] The preceding describes how packets are processed by edge devices and devices within the target network. The following describes how packets are processed during transmission, using specific scenarios.

[0136] Please refer to Figure 8, which is a schematic diagram of the architecture of a network system provided in an embodiment of the present application. As shown in Figure 8, the network system provided in an embodiment of the present application includes a first network, a target network, and a second network, wherein the target network is used to connect the first network and the second network. In other words, the target network is located between the first network and the second network. The first network device is a boundary device between the first network and the target network, the second network device is a device in the target network, and the third network device is a boundary device between the target network and the second network.

[0137] In the case where the network system is a mobile communication network, the first network is, for example, a RAN, the target network is a mobile bearer network, and the second network is a core network. Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0138] In a scenario where the first network is a RAN and the third network is a core network, the message transmission direction is an uplink transmission direction. The first network device is, for example, a RAN device (such as a base station) or a provider edge (PE) device of the target network, and the third network device is, for example, a core network device (such as a user plane function (UPF) device) or a PE device of the target network. For example, the first network device is a RAN device and the third network device is a core network device; or, the first network device is a PE device of the target network and the third network device is a core network device; or, the first network device is a RAN device and the third network device is a PE device of the target network; or, the first network device is a RAN device and the third network device is a PE device of the target network; or, the first network device is a PE device of the target network.

[0139] In a scenario where the first network is a core network and the third network is a RAN, the packet transmission direction is downlink. The first network device is, for example, a core network device or a PE device of the target network, and the third network device is, for example, a RAN device or a PE device of the target network. For example, the first network device is a core network device and the third network device is a RAN device; or, the first network device is a PE device of the target network and the third network device is a RAN device; or, the first network device is a core network device and the third network device is a PE device of the target network; or, the first network device is a PE device of the target network and the third network device is a PE device of the target network.

[0140] Since the target network is a mobile bearer network, for the message transmitted in the target network, the congestion marking information carried in the message header related to the transmission protocol of the mobile bearer network can be carried in certain available fields in the transmission protocol of the mobile bearer network. For example, assuming that the transmission protocol of the mobile bearer network is SR-TP, the Real-time Transport Protocol (RTP) extension field in the SR-TP message header (i.e., the RTP extension field shown in Figure 4) can be used to carry congestion marking information (i.e., the above-mentioned L4S identifier). For another example, assuming that the transmission protocol of the mobile bearer network is SRv6, the IPv6 address field of the SRv6 message header (i.e., the 128-bit IPv6 address field shown in Figure 5) can be used to carry congestion marking information.

[0141] Please refer to Figure 9, which illustrates a schematic diagram of a message processing flow during downlink transmission over a mobile communications network, according to an embodiment of the present application. During downlink transmission over a mobile communications network, a message is sent by a server, sequentially passes through the core network, the mobile bearer network, and the RAN, before finally reaching the user terminal. As shown in Figure 9, the message processing process as it passes through the core network, the mobile bearer network, and the RAN specifically includes the following steps 901-905.

[0142] In step 901, the core network device at the core network egress copies the L4S identifier in the IP header of the message to the header corresponding to the mobile bearer network when encapsulating the message into the header corresponding to the mobile bearer network.

[0143] In this embodiment, the core network device (such as a UPF device) at the core network egress is the boundary device between the core network and the mobile bearer network, and is responsible for encapsulating the message header corresponding to the mobile bearer network before the message enters the mobile bearer network. The message header corresponding to the mobile bearer network refers to the message header corresponding to the transmission protocol used by the mobile bearer network. For example, when the transmission protocol used by the mobile bearer network is SR-TP, the message header corresponding to the mobile bearer network is the SR-TP message header, and the core network device can copy the L4S identifier in the IP message header to the RTP extension field of the SR-TP message header; for another example, when the transmission protocol used by the mobile bearer network is SRv6, the message header corresponding to the mobile bearer network is the SRv6 message header, and the core network device can copy the L4S identifier in the IP message header to the IPv6 address field of the SRv6 message header.

[0144] In addition, as the message passes through the core network, the core network equipment will also encapsulate a layer of GTP message header outside the IP message header, and the GTP message header may also use the L4S identifier to record the congestion encountered by the message in the core network. Therefore, in some possible embodiments, the core network device at the core network egress may perform a logical OR operation on the L4S identifier in the IP message header and the L4S identifier in the GTP message header, and copy the result of the logical OR operation to the message header corresponding to the mobile bearer network. In other possible embodiments, the core network device at the core network egress may copy the L4S identifier in the GTP message header to the message header corresponding to the mobile bearer network.

[0145] Step 902: During the transmission of a message in the mobile bearer network, a network device in the mobile bearer network determines whether message congestion occurs on the current device.

[0146] For example, a network device in a mobile bearer network may be pre-configured with a threshold. When the number of packets in a message queue (i.e., packets awaiting forwarding) exceeds the threshold, it indicates that message congestion has occurred on the current device. If the number of packets in the message queue is not greater than the threshold, it indicates that message congestion has not occurred on the current device. Furthermore, the network device may determine whether congestion has occurred on the current device based on other methods, which are not specifically limited in this embodiment.

[0147] If the network device in the mobile bearer network determines that there is no packet congestion on the current device, it does not need to adjust the value of the L4S identifier on the packet header corresponding to the mobile bearer network, but forwards the packet to the next-hop device according to the normal forwarding process.

[0148] In step 903, if the network device in the mobile bearer network experiences message congestion, the network device in the mobile bearer network determines whether the message supports the L4S mechanism based on the value of the L4S identifier on the message header corresponding to the mobile bearer network.

[0149] Specifically, if the value of the L4S identifier on the message header corresponding to the mobile bearer network in the message is 01 or 11, it means that the message supports the L4S mechanism; if the value of the L4S identifier on the message header corresponding to the mobile bearer network in the message is not 01 or 11, it means that the message does not support the L4S mechanism.

[0150] If the message does not support the L4S mechanism, the network device in the mobile bearer network does not need to adjust the value of the L4S identifier on the message header corresponding to the mobile bearer network, but forwards the message to the next-hop device according to the normal forwarding process.

[0151] Step 904: If the message supports the L4S mechanism, the network device in the mobile bearer network adjusts the value of the L4S identifier on the message header corresponding to the mobile bearer network in the message.

[0152] When packet congestion occurs in a mobile bearer network device and the packet supports the L4S mechanism, the network device can adjust the value of the L4S identifier in the packet header corresponding to the mobile bearer network, for example, from 01 to 11, to indicate that the packet is congested. After adjusting the value of the L4S identifier in the packet header corresponding to the mobile bearer network, the network device forwards the adjusted packet to the next-hop device.

[0153] It should be noted that if the value of the L4S identifier on the message header corresponding to the mobile bearer network in the message is already 11, that is, the L4S identifier indicates that the message has been congested, then the network equipment in the mobile bearer network no longer needs to adjust the value of the L4S identifier.

[0154] In step 905 , when stripping the message header corresponding to the mobile bearer network from the message, the RAN device maps the value of the L4S identifier in the message header corresponding to the mobile bearer network to the L4S identifier in the IP message header in the inner layer of the message.

[0155] Specifically, if the GTP header of a message does not support the L4S mechanism, the RAN device can copy the L4S identifier in the message header corresponding to the mobile bearer network to the IP header in the inner layer of the message, thereby replacing the value of the L4S identifier in the inner IP header with the value of the L4S identifier in the message header corresponding to the mobile bearer network. For example, assuming that the value of the L4S identifier in the inner IP header of the message is 01, and the value of the L4S identifier in the outer header of the message corresponding to the mobile bearer network is 11, the value of the L4S identifier in the inner IP header of the message can be replaced with 11.

[0156] When the GTP header of a message supports the L4S mechanism, the value of the L4S identifier in the IP header of the inner layer of the message may have changed based on the value of the L4S identifier in the GTP header. Therefore, in order to avoid affecting the value of the L4S identifier in the IP header of the inner layer of the message, the RAN device can perform a logical OR operation on the value of the L4S identifier in the message header corresponding to the mobile bearer network and the value of the L4S identifier in the IP header, and replace the value of the L4S identifier in the IP header of the inner layer of the message with the result of the logical OR operation. For example, assuming that the value of the L4S identifier in the IP header of the inner layer of the message is 01, and the value of the L4S identifier in the message header of the outer layer of the message corresponding to the mobile bearer network is 11, then the result of the logical OR operation of the two L4S identifier values ​​is 11, so the value of the L4S identifier in the IP header of the inner layer of the message is replaced with 11. For example, suppose the value of the L4S identifier in the inner IP header of the message is 11, and the value of the L4S identifier in the outer header of the message corresponding to the mobile bearer network is 01. Then the logical OR operation result of the two L4S identifier values ​​is 11. Therefore, the value of the L4S identifier in the inner IP header of the message is not adjusted.

[0157] Alternatively, the RAN device can perform a logical OR operation on the value of the L4S identifier in the packet header corresponding to the mobile bearer network, the value of the L4S identifier in the GTP packet header, and the value of the L4S identifier in the IP packet header, and replace the value of the L4S identifier in the inner IP packet header of the packet with the result of the logical OR operation. For example, assuming that the value of the L4S identifier in the inner IP packet header of the packet is 01, the value of the L4S identifier in the GTP packet header of the packet is 01, and the value of the L4S identifier in the outer packet header corresponding to the mobile bearer network is 11, then the result of the logical OR operation of these three L4S identifier values ​​is 11, so the value of the L4S identifier in the inner IP packet header of the packet is replaced with 11. For example, assume that the L4S identifier value in the inner IP header of the message is 01, the L4S identifier value in the GTP header of the message is 11, and the L4S identifier value in the outer header of the message corresponding to the mobile bearer network is 01. Then the logical OR operation result of these three L4S identifier values ​​is 11. Therefore, the L4S identifier value in the inner IP header of the message is replaced with 11.

[0158] In general, by performing a logical OR operation on the values ​​of the L4S identifiers in different packet headers and replacing the value of the L4S identifier in the IP packet header with the result of the logical OR operation, it can be ensured that any congestion that occurs when the packet passes through any network can be reflected by the L4S identifier in the IP packet header.

[0159] It should be noted that the above uses core network equipment and RAN equipment as examples to describe the process of the core network equipment encapsulating the packet header corresponding to the mobile bearer network and adding the L4S identifier to the packet header corresponding to the mobile bearer network (i.e., the process described in step 901 above), and the process of the RAN equipment mapping the L4S identifier on the packet header corresponding to the mobile bearer network to the L4S identifier in the inner IP packet header (i.e., the process described in step 905 above). In actual applications, the entity executing the process described in step 901 above may also be a PE device at the ingress of the mobile bearer network, and the entity executing the process described in step 905 above may also be a PE device at the egress of the mobile bearer network. In other words, the device executing step 901 above may be any one of the core network equipment and the PE device at the ingress of the mobile bearer network, and the device executing step 905 above may be any one of the RAN equipment and the PE device at the egress of the mobile bearer network. For example, in one possible implementation, the device executing step 901 is a core network device, and the device executing step 905 is a PE device at the mobile bearer network egress; in another possible implementation, the device executing step 901 is a PE device at the mobile bearer network inlet, and the device executing step 905 is a RAN device or a PE device at the mobile bearer network egress.

[0160] In addition, when the RAN device executes the above step 905, the RAN device may first determine the congestion situation of the message, and then process the message based on the congestion situation of the message.

[0161] In one possible scenario, the RAN device supports the L4S mechanism, meaning it can determine the packet congestion status on the current device. If the RAN device determines that packet congestion is occurring on the current device, the RAN device may determine that packets passing through the current device are congested. If the RAN device determines that packet congestion is not occurring on the current device, the RAN device performs a logical OR operation on the L4S flag in the packet's IP header, the L4S flag in the GTP header, and the L4S flag in the corresponding packet header of the mobile bearer network. If the result of the logical OR operation is 11, the RAN device determines that the packet is congested.

[0162] In another possible scenario, the RAN device does not support the L4S mechanism. The RAN device performs a logical OR operation on the L4S identifier in the IP header, the L4S identifier in the GTP header, and the L4S identifier in the header corresponding to the mobile bearer network in the message. If the result of the logical OR operation is 11, the RAN device determines that the message is congested.

[0163] It should be noted that if in the above two cases, the GTP message header does not have the L4S identifier, the RAN device performs a logical OR operation on the L4S identifier of the IP message header in the message and the L4S identifier of the message header corresponding to the mobile bearer network.

[0164] When the RAN device determines that message congestion occurs, the RAN device may execute any of the following congestion feedback methods.

[0165] In method 1, the RAN device changes the value of the L4S identifier in the IP packet header to 11.

[0166] That is, the RAN device implements congestion feedback on packets by performing congestion marking under the L4S mechanism on the packets.

[0167] Please refer to Figure 10, which is a flowchart of a congestion feedback process provided by an embodiment of the present application. As shown in Figure 10, the transmission direction of the message is: server → core network device → mobile bearer network → RAN device → user terminal. In addition, the server continuously sends messages to the user terminal. When the message passes through the RAN device, the RAN device evaluates the congestion situation of the message during transmission, and when it is determined that the message has been congested, it performs congestion marking on the message (that is, the value of the L4S identifier in the IP header of the message is modified to 11), and then sends the message with congestion marking to the user terminal. After receiving the message with congestion marking, the user terminal sends a congestion feedback message to the server through the RAN device, mobile bearer network and core network device to indicate that the message encountered congestion during transmission. In this way, the server adjusts the message sending rate based on the congestion feedback message sent by the user terminal.

[0168] In mode 2, the RAN device does not modify the value of the L4S identifier in the IP packet header, and the RAN device sends a congestion report message to the core network device, which then performs congestion marking under the L4S mechanism on subsequent packets.

[0169] In other words, RAN devices no longer need to perform congestion marking on packets under the L4S mechanism. Instead, they report congestion to the core network devices, which then perform congestion marking.

[0170] Please refer to Figure 11, which is a schematic diagram of another congestion feedback process provided by an embodiment of the present application. As shown in Figure 11, the message transmission direction is the same as the message transmission direction shown in Figure 10. When a message passes through a RAN device, the RAN device evaluates the congestion status of the message during transmission and, if it determines that the message has experienced congestion, sends a congestion report message to the core network device to indicate that the message passing through the RAN device has experienced congestion. Then, after receiving the congestion report message, the core network device performs congestion marking on subsequent messages in the same data flow that pass through the core network device (i.e., changes the value of the L4S flag in the IP header of the message to 11). In this way, subsequent messages that have been congested marked by the core network device are transmitted to the user terminal after passing through the RAN device. The user terminal, based on the congestion marking in the received message, sends a congestion feedback message to the server to indicate that the message encountered congestion during transmission. In this way, the server adjusts the message transmission rate based on the congestion feedback message sent by the user terminal.

[0171] Each time the RAN device determines that a message has been congested, it sends a congestion report message to the core network device to indicate that a message in the current data flow has been congested. Each time the core network device receives a congestion report message, it performs congestion marking on the next message in the data flow indicated by the congestion report message. For example, the RAN device can implement the sending of congestion report messages based on messages under the 5th Generation Mobile Communication Technology (5G) protocol, and the information indicating that the message has been congested can be carried in the GTP message header of the congestion report message.

[0172] In mode 3, the RAN device does not modify the value of the L4S identifier in the IP packet header, and the RAN device sends a congestion report message to the core network device, which then notifies the server of the congestion.

[0173] That is, when the RAN device confirms that the message is congested, the RAN device and the core network device no longer perform congestion marking on the message, but directly notify the server of the message congestion through uplink notification.

[0174] Please refer to Figure 12, which is a schematic diagram of another congestion feedback process provided by an embodiment of the present application. As shown in Figure 12, the message transmission direction is the same as the message transmission direction shown in Figure 10. When a message passes through a RAN device, the RAN device evaluates the congestion status of the message during transmission. If it determines that the message has experienced congestion, it sends a congestion report message to the core network device to indicate that the message passing through the RAN device has experienced congestion. Then, after receiving the congestion report message, the core network device sends a notification message to the server to indicate that the message has encountered congestion during transmission. In this way, the server adjusts the message transmission rate based on the notification message sent by the core network device.

[0175] Each time the RAN device determines that a packet has experienced congestion, it sends a congestion report message to the core network device, indicating that a packet in the current data flow has experienced congestion. Each time the core network device receives a congestion report message, it sends a notification message to the server, indicating that a packet in the current data flow has experienced congestion. For example, the core network device notifies the server of packet congestion using the openness Application Programming Interface (API) mechanism. The server then counts the number of notification messages received within a congestion window to determine the number of congested packets and adaptively adjust the packet generation rate.

[0176] The above describes the processing process of a message during downlink transmission in a mobile communication network. The following describes the processing process of a message during uplink transmission in a mobile communication network.

[0177] Please refer to Figure 13, which illustrates a flowchart illustrating the processing of a message during uplink transmission on a mobile communication network, according to an embodiment of the present application. During uplink transmission on a mobile communication network, a message is sent by a user terminal, sequentially passes through the RAN, the mobile bearer network, and the core network, and finally reaches a server. As shown in Figure 13, the message processing process as it passes through the RAN, the mobile bearer network, and the core network specifically includes the following steps 1301-1305.

[0178] Step 1301 , when encapsulating a message into a message header corresponding to the mobile bearer network, the PE device at the ingress of the mobile bearer network copies the L4S identifier in the IP message header of the message into the message header corresponding to the mobile bearer network.

[0179] In this embodiment, the PE device at the entrance of the mobile bearer network is the boundary device between the RAN and the mobile bearer network, and is responsible for encapsulating the message with a header corresponding to the mobile bearer network before the message enters the mobile bearer network. The message header corresponding to the mobile bearer network refers to the message header corresponding to the transmission protocol used by the mobile bearer network. For example, when the transmission protocol used by the mobile bearer network is SR-TP, the message header corresponding to the mobile bearer network is the SR-TP message header, and the PE device at the entrance of the mobile bearer network can copy the L4S identifier in the IP message header to the RTP extension field of the SR-TP message header; for another example, when the transmission protocol used by the mobile bearer network is SRv6, the message header corresponding to the mobile bearer network is the SRv6 message header, and the PE device at the entrance of the mobile bearer network can copy the L4S identifier in the IP message header to the IPv6 address field of the SRv6 message header.

[0180] Furthermore, as packets pass through the RAN, devices within the RAN also encapsulate a GTP header outside of the packet's IP header. The GTP header may also use an L4S identifier to record the congestion encountered by the packet in the core network. Therefore, in some possible embodiments, the PE device at the ingress of the mobile bearer network may perform a logical OR operation on the L4S identifier in the IP header and the L4S identifier in the GTP header, and copy the result of the logical OR operation to the header corresponding to the mobile bearer network. In other possible embodiments, the PE device at the ingress of the mobile bearer network may copy the L4S identifier in the GTP header to the header corresponding to the mobile bearer network.

[0181] Step 1302 : During the transmission of a message in the mobile bearer network, a network device in the mobile bearer network determines whether message congestion occurs on the current device.

[0182] In step 1303, if the network device in the mobile bearer network experiences message congestion, the network device in the mobile bearer network determines whether the message supports the L4S mechanism based on the value of the L4S identifier on the message header corresponding to the mobile bearer network.

[0183] Step 1304: If the message supports the L4S mechanism, the network device in the mobile bearer network adjusts the value of the L4S identifier on the message header corresponding to the mobile bearer network in the message.

[0184] Among them, steps 1302-1304 are similar to the above steps 902-904. Please refer to the above steps 902-904 for details, and will not be repeated here.

[0185] Step 1305 , when the PE device at the mobile bearer network egress strips the message header corresponding to the mobile bearer network from the message, it maps the value of the L4S identifier in the message header corresponding to the mobile bearer network to the L4S identifier in the IP message header in the inner layer of the message.

[0186] Specifically, when the GTP header of a message does not support the L4S mechanism, the PE device at the mobile bearer network egress can copy the L4S identifier in the message header corresponding to the mobile bearer network to the IP header in the inner layer of the message, thereby replacing the value of the L4S identifier in the IP header in the inner layer of the message with the value of the L4S identifier in the message header corresponding to the mobile bearer network. For example, assuming that the value of the L4S identifier in the IP header in the inner layer of the message is 01, and the value of the L4S identifier in the message header in the outer layer of the message corresponding to the mobile bearer network is 11, the value of the L4S identifier in the IP header in the inner layer of the message can be replaced with 11.

[0187] If the GTP header of a packet supports the L4S mechanism, the value of the L4S identifier in the IP header of the packet may have changed based on the value of the L4S identifier in the GTP header. Therefore, the PE device at the egress of the mobile bearer network can perform a logical OR operation on the value of the L4S identifier in the packet header corresponding to the mobile bearer network and the value of the L4S identifier in the IP header, and replace the value of the L4S identifier in the IP header of the packet with the result of the logical OR operation.

[0188] Alternatively, the PE device at the mobile bearer network egress may perform a logical OR operation on the value of the L4S identifier in the message header corresponding to the mobile bearer network, the value of the L4S identifier in the GTP message header, and the value of the L4S identifier in the IP message header, and replace the value of the L4S identifier in the IP message header in the inner layer of the message with the result of the logical OR operation.

[0189] It should be noted that the above uses the PE device at the ingress of the mobile bearer network and the PE device at the egress of the mobile bearer network as examples to describe the process of the PE device at the ingress of the mobile bearer network encapsulating the packet header corresponding to the mobile bearer network and adding the L4S identifier to the packet header corresponding to the mobile bearer network (i.e., the process described in step 1301 above), and the process of the PE device at the egress of the mobile bearer network mapping the L4S identifier on the packet header corresponding to the mobile bearer network to the L4S identifier in the inner IP packet header (i.e., the process described in step 1305 above). In actual applications, the entity executing the process described in step 1301 above may also be a RAN device, and the entity executing the process described in step 1305 above may also be a core network device. In other words, the device executing step 1301 above may be either a PE device at the ingress of the mobile bearer network or a RAN device, and the device executing step 1305 above may be either a PE device at the egress of the mobile bearer network or a core network device. For example, in one possible implementation, the device executing step 1301 is a PE device at the entrance of the mobile bearer network, and the device executing step 1305 is a core network device; in another possible implementation, the device executing step 1301 is a RAN device, and the device executing step 1305 is a core network device or a PE device at the exit of the mobile bearer network.

[0190] In general, in both the uplink and downlink message transmission scenarios, the processing of a message passing through a mobile bearer network can be summarized by the process shown in Figure 14. Please refer to Figure 14, which is a flowchart of a message processing process passing through a mobile bearer network according to an embodiment of the present application. As shown in Figure 14, the processing of a message passing through a mobile bearer network includes the following steps 1401-1403.

[0191] Step 1401: A device at the ingress of the mobile bearer network sets an L4S identifier in a message header corresponding to the mobile bearer network based on the L4S identifier in the received message.

[0192] Exemplarily, after receiving a message, the device at the ingress of the mobile bearer network generates a new message based on the received message and sets the L4S identifier in the message header of the new message corresponding to the mobile bearer network based on the L4S identifier in the received message. Optionally, the device at the ingress of the mobile bearer network sets the L4S identifier in the message header of the new message corresponding to the mobile bearer network based on the L4S identifier in at least one message header in the received message. Optionally, the device at the ingress of the mobile bearer network performs a logical OR operation on the L4S identifier in each L4S-supporting message header in the received message, and copies the result of the logical OR operation to the message header of the new message corresponding to the mobile bearer network. For example, if the message header supporting L4S in the message received by the device at the ingress of the mobile bearer network includes an IP message header and a GTP message header, the device at the ingress of the mobile bearer network performs a logical OR operation on the L4S identifier in the IP message header and the L4S identifier in the GTP message header, and copies the result of the logical OR operation to the message header of the new message corresponding to the mobile bearer network. Optionally, if any one of the message headers in the received message supports L4S, the mobile bearer network entry device can directly set the L4S identifier in the message header corresponding to the mobile bearer network in the new message to support L4S (for example, the L4S identifier is 01). Optionally, the device at the mobile bearer network entry copies the L4S identifier in any message header that supports L4S in the received message to the message header corresponding to the mobile bearer network in the new message. For example, the L4S identifier in the IP message header of the received message is copied to the message header corresponding to the mobile bearer network in the new message, or the L4S identifier in the GTP message header of the received message is copied to the message header corresponding to the mobile bearer network in the new message.

[0193] In the uplink message transmission scenario, the device at the ingress of the mobile bearer network is, for example, a RAN device or a PE device at the ingress of the mobile bearer network. In the downlink message transmission scenario, the device at the ingress of the mobile bearer network is, for example, a core network device or a PE device at the ingress of the mobile bearer network. It should be noted that in the uplink message transmission scenario, the PE device at the ingress of the mobile bearer network refers to the device in the mobile bearer network connected to the RAN; in the downlink message transmission scenario, the PE device at the ingress of the mobile bearer network refers to the device in the mobile bearer network connected to the core network.

[0194] In step 1402, the device in the mobile bearer network determines whether the message supports the L4S mechanism based on the L4S identifier in the message header corresponding to the mobile bearer network, and adjusts the L4S identifier in the message header corresponding to the mobile bearer network based on the message congestion situation if the message supports the L4S mechanism.

[0195] After a message enters the mobile bearer network for transmission, the device in the mobile bearer network will trigger adjustment of the L4S flag in the message header corresponding to the mobile bearer network only when it determines that the message supports the L4S flag based on the L4S flag in the message header corresponding to the mobile bearer network and message congestion actually occurs in the current device, so that the L4S flag in the message header corresponding to the mobile bearer network indicates that the message is congested.

[0196] In step 1403, the device at the mobile bearer network egress maps the value of the L4S identifier in the message header corresponding to the mobile bearer network in the message to the L4S identifier in the inner message header of the message.

[0197] For example, the value of the L4S identifier in the message header corresponding to the mobile bearer network in the message is mapped to the L4S identifier in the IP message header of the inner layer of the message. Mapping the value of the L4S identifier in the message header corresponding to the mobile bearer network in the message to the L4S identifier in the IP message header of the inner layer of the message actually reflects the information that the message is congested in the mobile bearer network in the IP message header of the message. When the L4S identifier in the IP message header of the message already indicates that the message is congested, or the message is not congested in the mobile bearer network, there is no need to adjust the value of the L4S identifier in the IP message header of the message.

[0198] It should be noted that in the uplink message transmission scenario, the PE device at the mobile bearer network egress refers to the device in the mobile bearer network that is connected to the core network; in the downlink message transmission scenario, the PE device at the mobile bearer network egress refers to the device in the mobile bearer network that is connected to the RAN.

[0199] It should be noted that, when the message supports the L4S mechanism, if message congestion occurs in the device at the entrance of the mobile bearer network or the device at the exit of the mobile bearer network, then the device at the entrance of the mobile bearer network or the device at the exit of the mobile bearer network can also adjust the value of the L4S identifier in the message header corresponding to the mobile bearer network in the message, so that the L4S identifier can indicate that the message is congested.

[0200] Please refer to Figure 15, which is a structural diagram of a message processing device provided in an embodiment of the present application. In one possible example, the message processing device is deployed on a first network device, and the first network device is a boundary device of the target network. The message processing device includes: a receiving module 1501, which is used to receive a first message; a processing module 1502, which is used to generate a second message based on the first message, the first message does not include a message header related to the transmission protocol of the target network, the second message includes a first message header related to the transmission protocol of the target network, the first message header includes congestion marking information, the congestion marking information is generated by the first network device based on the content in the first message, and the congestion marking information is used to indicate the congestion situation of the message during transmission; a sending module 1503, which is used to send the second message to the device in the target network.

[0201] In a possible implementation, the congestion marking information in the first packet header is an L4S identifier.

[0202] In a possible implementation, the first packet header is an SR-TP packet header, and the congestion marking information is carried in a real-time transport protocol extension field in the SR-TP packet header;

[0203] Alternatively, the first packet header is an SRv6 packet header, and the congestion marking information is carried in an IPv6 address field of the SRv6 packet header.

[0204] In a possible implementation, the first network device is a boundary device between the first network and the target network, and the target network is used to connect the first network and the second network.

[0205] In one possible implementation, the first network is a RAN, the target network is a mobile bearer network, and the second network is a core network;

[0206] Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0207] In another possible example, a message processing apparatus is deployed on a third network device, which is an edge device of a target network. The message processing apparatus includes: a receiving module 1501, configured to receive a third message from the target network, wherein a second message header in the third message includes congestion marking information, and the second message header is related to the transmission protocol of the target network; and a sending module 1503, configured to provide feedback on message congestion based on the congestion marking information in the second message header.

[0208] In one possible implementation, the message processing device also includes a processing module 1502, which is used to generate a fourth message based on the third message, the fourth message including the first message congestion information, the first message congestion information is generated based on the congestion mark information in the message header related to the transmission protocol of the target network in the third message, and the fourth message does not include the message header related to the transmission protocol of the target network; a sending module 1503, which is specifically used to send the fourth message to a device outside the target network.

[0209] In a possible implementation, the first message congestion information is carried in an IP message header of the fourth message, and the first message congestion information is used to indicate a congestion condition of the message during transmission.

[0210] In a possible implementation, the first message congestion information is obtained by performing a logical OR operation on congestion marking information in a message header related to a transmission protocol of a target network in a third message and the second message congestion information in an IP message header of the third message;

[0211] Alternatively, the first message congestion information is obtained by performing a logical OR operation on the congestion marking information in the message header related to the transmission protocol of the target network in the third message, the second message congestion information in the IP message header of the third message, and the third message congestion information in the GTP message header of the third message.

[0212] In a possible implementation, the congestion marking information in the first packet header is generated by the first network device according to the fourth congestion information in the IP packet header in the first packet.

[0213] In a possible implementation, the congestion marking information includes a marking bit consisting of one or more bits, and different values ​​of the marking bit are used to indicate whether congestion occurs in the message or not.

[0214] In a possible implementation, the third network device is a boundary device between the target network and the second network, and the target network is used to connect the first network and the second network.

[0215] In one possible implementation, the first network is a RAN, the target network is a mobile bearer network, and the second network is a core network;

[0216] Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

[0217] In one possible implementation, the third network device is a RAN device, and the sending module 1503 is further configured to send a congestion report message to a device in the core network when it is determined that congestion has occurred during transmission of the third message. The congestion report message is used to indicate that congestion has occurred in the message.

[0218] Figure 16 is a schematic diagram of the structure of a network device provided in an embodiment of the present application. The network device is equipped with the message processing device described in Figure 15 above, and the network device is implemented by a general bus architecture.

[0219] The network device includes at least one processor 1601 , a communication bus 1602 , a memory 1603 , and at least one communication interface 1604 .

[0220] Optionally, processor 1601 is a general-purpose CPU, NP, microprocessor, or one or more integrated circuits for implementing the solution of the present application, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD is a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0221] Communication bus 1602 is used to transmit information between the above components. Communication bus 1602 is divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0222] Alternatively, the memory 1603 is a read-only memory (ROM) or other types of static storage devices that can store static information and instructions. Alternatively, the memory 1603 is a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions. Alternatively, the memory 1603 is an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. Alternatively, the memory 1603 exists independently and is connected to the processor 1601 via a communication bus 1602. Alternatively, the memory 1603 and the processor 1601 are integrated together.

[0223] Communication interface 1604 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 1604 includes a wired communication interface. Optionally, communication interface 1604 also includes a wireless communication interface. The wired communication interface is, for example, an Ethernet interface. The Ethernet interface is an optical interface, an electrical interface, or a combination thereof. The wireless communication interface is a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0224] In a specific implementation, as an embodiment, the processor 1601 includes one or more CPUs, such as CPU0 and CPU1 shown in FIG16 .

[0225] In a specific implementation, as an embodiment, the network device includes multiple processors, such as processor 1601 and processor 1605 shown in Figure 16. Each of these processors is a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor here refers to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0226] In some embodiments, the memory 1603 is used to store program code 1616 for executing the solution of the present application, and the processor 1601 executes the program code 1616 stored in the memory 1603. In other words, the network device implements the above method embodiment through the processor 1601 and the program code 1616 in the memory 1603.

[0227] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. Wherein, A refers to B, which means that A is the same as B or A is a simple variation of B.

[0228] The terms "first" and "second" in the description and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects, and should not be construed as indicating or implying relative importance. For example, the terms "first speed-limited channel" and "second speed-limited channel" are used to distinguish different speed-limited channels, not to describe a specific order of speed-limited channels, and should not be construed as implying that the first speed-limited channel is more important than the second speed-limited channel.

[0229] In the embodiments of the present application, unless otherwise specified, “at least one” means one or more, and “a plurality of” means two or more.

[0230] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in accordance with the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0231] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A network system, characterized in that: include: A first network device, a second network device and a third network device, wherein the first network device and the third network device are edge devices of a target network, and the second network device is a device in the target network; The first network device is used to generate a second message according to the received first message, and send the second message to the device in the target network, wherein the second message includes a first message header related to the transmission protocol of the target network, and the first message header includes congestion marking information, and the congestion marking information is generated by the first network device according to the content in the first message; The second network device is used to forward the message transmitted in the target network, and during the message forwarding, determine whether to modify the congestion marking information in the target message header of the forwarded message based on the message congestion situation in the second network device, wherein the target message header is related to the transmission protocol of the target network; The third network device is used to feed back message congestion status according to congestion marking information in a second message header in a third message received from the target network, where the second message header is related to a transmission protocol of the target network.

2. The network system according to claim 1, characterized in that: The congestion marking information in the first packet header is a low-latency, low-packet-loss, flexible-throughput L4S identifier.

3. The network system according to claim 1 or 2, characterized in that: The first message header is a transmission-oriented segment routing SR-TP message header, and the congestion marking information is carried in a real-time transport protocol extension field in the SR-TP message header; Or, the first message header is a segment routing SRv6 message header based on the Internet Protocol version 6 IPv6 forwarding plane, and the congestion marking information is carried in the IPv6 address field of the SRv6 message header.

4. The network system according to any one of claims 1 to 3, characterized in that: The third network device is used to generate a fourth message based on the third message and send the fourth message to the device outside the target network, the fourth message includes the first message congestion information, and the first message congestion information is generated based on the congestion marking information of the second message header in the third message.

5. The network system according to claim 4, characterized in that: The first message congestion information is carried in an Internet Protocol (IP) message header of the fourth message, and the first message congestion information is used to indicate a congestion situation of a message during transmission.

6. The network system according to claim 4 or 5, characterized in that: The first message congestion information is obtained by performing logical or operation on the congestion marking information in the message header related to the transmission protocol of the target network in the third message and the congestion information in other message headers in the third message, and the other message headers include one or more of the following: IP message header, General Packet Radio System Tunneling Protocol GTP message header.

7. The network system according to any one of claims 1 to 6, characterized in that: The congestion marking information in the first packet header is generated by the first network device according to the fourth congestion information in the IP packet header in the first packet.

8. The network system according to any one of claims 1 to 7, characterized in that: The congestion marking information includes a marking bit composed of one or more bits, and different values ​​of the marking bit are used to indicate whether congestion occurs in the message or not.

9. The network system according to any one of claims 1 to 8, characterized in that: The first network device is a boundary device between the first network and the target network, the third network device is a boundary device between the target network and the second network, and the target network is used to connect the first network and the second network.

10. The network system according to claim 9, characterized in that: The first network is a radio access network RAN, the target network is a mobile bearer network, and the second network is a core network; Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

11. The network system according to claim 10, characterized in that: The first network device is a core network device or an operator edge PE device of the target network, and the third network device is a RAN device or a PE device of the target network.

12. The network system according to claim 10, characterized in that: The first network device is a RAN device or a PE device of the target network, and the third network device is a core network device or a PE device of the target network.

13. The network system according to claim 10 or 11, characterized in that: The third network device is a RAN device, and the third network device is further used to send a congestion report message to a device in the core network when it is determined that congestion has occurred in the transmission process of the third message, and the congestion report message is used to indicate that congestion has occurred in the message.

14. The network system according to claim 13, characterized in that: The device in the core network is used to perform congestion marking on the passing packets based on the congestion report message; Alternatively, the device in the core network is used to notify the server of message congestion based on the congestion report message.

15. A message processing method, characterized in that: The method is applied to a first network device, where the first network device is a border device of a target network, and the method includes: The first network device receives a first message, and generates a second message according to the first message, wherein the first message does not include a message header related to the transmission protocol of the target network, the second message includes a first message header related to the transmission protocol of the target network, the first message header includes congestion marking information, the congestion marking information is generated by the first network device according to the content in the first message, and the congestion marking information is used to indicate the congestion situation of the message during transmission; The first network device sends the second message to a device in the target network.

16. The method according to claim 15, characterized in that The congestion marking information in the first packet header is an L4S identifier.

17. The method according to claim 15 or 16, characterized in that The first message header is a transmission-oriented segment routing SR-TP message header, and the congestion marking information is carried in a real-time transport protocol extension field in the SR-TP message header; Or, the first message header is a segment routing SRv6 message header of the 6th version of the Internet Protocol IPv6 forwarding plane, and the congestion marking information is carried in the IPv6 address field of the SRv6 message header.

18. The method according to any one of claims 15 to 17, characterized in that: The first network device is a boundary device between the first network and the target network, and the target network is used to connect the first network and the second network.

19. The method according to claim 18, characterized in that The first network is a radio access network RAN, the target network is a mobile bearer network, and the second network is a core network; Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

20. A message processing method, characterized in that: The method is applied to a third network device, where the third network device is a border device of a target network, and the method includes: The third network device receives a third message from the target network, wherein a second message header in the third message includes congestion marking information, and the second message header is related to a transmission protocol of the target network; The third network device feeds back message congestion status according to the congestion marking information of the second message header.

21. The method according to claim 20, characterized in that The third network device feeds back the message congestion situation according to the congestion marking information of the second message header, including: The third network device generates a fourth message according to the third message, and sends the fourth message to the device outside the target network, The fourth message includes first message congestion information, where the first message congestion information is generated based on congestion marking information of the second message header in the third message.

22. The method according to claim 21, characterized in that The first message congestion information is carried in the IP message header of the fourth message, and the first message congestion information is used to indicate the congestion situation of the message during transmission.

23. The method according to claim 21 or 22, characterized in that The first message congestion information is obtained by performing logical or operation on the congestion marking information in the message header related to the transmission protocol of the target network in the third message and the congestion information in other message headers in the third message, and the other message headers include one or more of the following: IP message header, General Packet Radio System Tunneling Protocol GTP message header.

24. The method according to any one of claims 20 to 23, characterized in that: The third network device is a boundary device between the target network and the second network, and the target network is used to connect the first network and the second network.

25. The method according to claim 24, characterized in that The first network is a radio access network RAN, the target network is a mobile bearer network, and the second network is a core network; Alternatively, the first network is a core network, the target network is a mobile bearer network, and the second network is a RAN.

26. The method according to claim 24 or 25, characterized in that The third network device is a RAN device, and the method further includes: When determining that congestion has occurred in the transmission process of the third message, the third network device sends a congestion report message to a device in the core network, where the congestion report message is used to indicate that congestion has occurred in the message.

27. A network device, comprising a processor and a memory, wherein the memory is used to store program codes, and the processor is used to call the program codes in the memory so that the network device executes the method according to any one of claims 15 to 26.

28. A computer-readable storage medium storing instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 15 to 26.

29. A computer program product, characterized in that The computer program product comprises program codes, and when a computer runs the computer program product, the computer executes the method according to any one of claims 15 to 26.

Images