WO2017088557A1 - 数据报文发送接收的处理方法及装置 - Google Patents

数据报文发送接收的处理方法及装置 Download PDF

Info

Publication number
WO2017088557A1
WO2017088557A1 PCT/CN2016/098730 CN2016098730W WO2017088557A1 WO 2017088557 A1 WO2017088557 A1 WO 2017088557A1 CN 2016098730 W CN2016098730 W CN 2016098730W WO 2017088557 A1 WO2017088557 A1 WO 2017088557A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
data
sub
processing
header
Prior art date
Application number
PCT/CN2016/098730
Other languages
English (en)
French (fr)
Inventor
韦先霜
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2017088557A1 publication Critical patent/WO2017088557A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets

Definitions

  • This document relates to, but is not limited to, the field of communication technology, and relates to a processing method and apparatus for transmitting and receiving data messages.
  • the packet header of the IP (Internet Protocol) data packet is transmitted between the general network elements, and the overhead of the packet header cannot be omitted regardless of the payload of the data packet. This will result in a lower effective bandwidth utilization of the link.
  • BSS mobile station base station subsystem
  • RNC Radio Network Controller
  • Service packets are generally short, such as a 14-byte MAC (Media Access Contro) header, a 20-byte IP header, an 8-byte UDP (User Datagram Protocol) header, and 4 bytes.
  • the MAC layer check, as well as the 7-byte preamble, 1-byte frame delimiter when the payload of the data message is less than 54 bytes, the bandwidth utilization of the data message transmission is less than 50%.
  • IPHC Internet Protocol Header Compression
  • the embodiment of the invention provides a processing method and device for sending and receiving data packets, which can reduce the transmission overhead of data packets, thereby improving bandwidth utilization.
  • An embodiment of the present invention provides a method for processing data packet transmission, where the method for processing the data packet transmission includes:
  • the packet includes at least a packet header and a plurality of sub-packets corresponding to the data packet processed by the packet and the packet, the sub-packet including a destination address identifier field of the data packet;
  • the parallel packet and the data packet that has not been processed and processed by the packet are added to the sending queue for transmission.
  • the data packet that is determined to be processed by the packet and processed by the packet is processed by the packet to generate a corresponding packet including:
  • the sub-packets are sequentially arranged and padded after the packet header, wherein the sub-packet further includes at least the data packet.
  • the related field in the header is updated and the cyclic redundancy check code CRC of the current packet is generated.
  • the CRC is filled into the current packet and the packet is sent.
  • the determining whether the data packet to be sent is a packet and the packet processing comprises: determining whether the data packet to be sent is determined according to whether the source media access control MAC address in the data packet corresponds to the specified MAC address. And performing packet processing and packet processing; or determining whether the data packet to be sent is a packet and processing the packet according to whether the IP address of the source network interconnection protocol in the data packet corresponds to the specified IP address;
  • the packet identifier includes a specified MAC address or an IP address or a UDP port number.
  • the destination address of the data packet includes an IP address of the receiving device, a network number of the receiving device, or an IP address of the receiving device. The identifier corresponding to the address.
  • the embodiment of the invention provides a processing method for receiving a data packet, and the processing method for receiving the data packet includes:
  • the packet When the received packet is received, it is determined whether the received packet is a detachable packet, and the packet is set in the packet identifier field, and includes a packet header and a number of sub-packets corresponding to data packets that are processed by the packet and processed by the packet;
  • the packet is a detachable packet, it is determined whether there is a sub-package corresponding to the receiving device in the packet.
  • the sub-packet corresponding to the receiving device is unpacked and processed to obtain a data packet corresponding to the receiving device.
  • the data packet obtained by the packet unpacking process corresponding to the sub-packet of the receiving device is added to the receiving queue for reception.
  • the unpacking process of the sub-packet corresponding to the receiving end device in the parallel packet to obtain the data packet corresponding to the receiving end device includes:
  • the sub-packet includes a destination address identifier field of the data packet, a payload field after the data packet is removed, and a length field of the sub-packet.
  • the determining whether the sub-package corresponding to the receiving end device exists in the parallel packet includes:
  • determining whether the received packet is a detachable packet includes:
  • the packet When receiving the packet, it determines whether there is a packet identifier in the packet, and if there is a packet identifier, it is determined to be a packet packet;
  • the cyclic redundancy check code CRC of the packet is calculated and it is determined whether the calculated CRC matches the CRC carried in the packet, and if yes, it is determined to be Detachable and packaged messages.
  • the method further includes: after the data packet obtained by performing packet unpacking processing on the sub-packet corresponding to the receiving end device in the packet is added to the receiving queue to be received,
  • the sub-packet corresponding to the receiving device is deleted from the packet and updated in the corresponding field of the packet. After that, the updated packet is added to the sending queue to be sent;
  • the packet is unpacked and processed by all the sub-packets that have not been subjected to the packet unpacking process to obtain the corresponding lower-level receiving device.
  • the data packet is added to the send queue for the data packet to be sent.
  • the embodiment of the present invention further provides a processing device for sending a data packet, where the processing device for sending the data packet includes:
  • the packet determining module is configured to determine whether the data packet to be sent is processed by the packet and before the data packet is sent;
  • the packet processing module is configured to process the data packet that is determined to perform packet processing and packet processing, and process the packet to generate a corresponding packet, wherein the packet is set with the packet identifier. a field, and the parallel packet includes at least a packet header and a plurality of sub-packets corresponding to the data packet processed by the packet and the packet, the sub-packet including a destination address identifier field of the data packet ;
  • the message sending module is configured to add the packet of the parallel packet and the data packet that has not been processed and processed by the packet into the sending queue for transmission.
  • the parallel processing module includes:
  • the sub-packet quantity control unit is configured to apply a parallel buffer with a preset maximum frame length MFL and start a timer to control and control the number of sub-packets in the packet;
  • the packet header filling unit is configured to fill and buffer the packet header into the parallel packet buffer, wherein the packet header field is set with the packet packet identifier field;
  • Sub-packet filling unit set to be when the current length of the packet is less than MFL, and/or timing When the time of the packet is not reached, the sub-packets are further arranged to be filled with a plurality of sub-packets after the header of the packet, wherein the sub-packet further includes a payload field after the packet is removed, and a length field of the sub-packet;
  • the packet generation unit is configured to: when the current length of the packet is greater than or equal to the MFL, and/or when the timer expires, update and packetize the relevant field in the header, and generate the current packet.
  • the cyclic redundancy check code CRC fills the CRC into the current packet and obtains a packet that can be sent.
  • the embodiment of the present invention further provides a processing device for receiving a data packet, where the processing device for receiving the data packet includes:
  • the unpacking determination module is configured to: when the received message is received, determine whether the received packet is a detachable packet, wherein the packet is set with a packet identifier field, and The method includes a packet header and a plurality of sub-packets corresponding to the data packet processed by the packet and the packet processing;
  • the determining module is configured to: when it is determined that the received packet is a detachable packet, determine whether the sub-packet corresponding to the receiving device exists in the parallel packet;
  • the unpacking processing module is configured to: when the sub-packet corresponding to the receiving end device exists in the packet, the packet is unpacked in the packet corresponding to the receiving device to obtain the corresponding receiving Data packet of the end device;
  • the packet receiving module is configured to add the data packet obtained by the packet unpacking processing of the sub-packet corresponding to the receiving device to the receiving queue for receiving.
  • the unpacking processing module includes:
  • Application unit set to apply for unpacking buffer
  • the data packet header filling unit is configured to fill the packet header with the packet header, where the source address in the packet header corresponds to the source address in the packet header, and the header in the packet header The destination address corresponds to the address of the receiving device;
  • the data packet generating unit is configured to fill the payload of the sub-packet corresponding to the receiving end device after the packet header filled in the unpacking buffer, and update the related field in the filled packet header to obtain a corresponding The data packet of the receiving device, where the sub-packet includes a destination address identifier field of the data packet, a payload field after the data packet is removed, and a length field of the sub-packet.
  • the processing device for receiving the data packet further includes:
  • the first sending processing module is configured to: when the receiving end device has a lower-level receiving end device and the lower-level receiving end device supports processing and packetizing the packet, the sub-packet corresponding to the receiving end device is deleted from the parallel packet and correspondingly After updating and including the relevant fields of the packet, the updated packet is added to the sending queue for transmission;
  • the second sending processing module is configured to unpack all the sub-packets that have not been subjected to packet unpacking processing when the receiving end device has a lower-level receiving end device and the lower-level receiving end device does not support processing and packet-receiving the packet.
  • the data packet corresponding to the receiving device of the lower-level device is obtained, and the data packet is added to the sending queue for transmission.
  • the embodiment of the invention further provides a computer readable storage medium, wherein the computer readable storage medium stores computer executable instructions, and the processing method for implementing data message transmission when the computer executable instructions are executed.
  • the embodiment of the invention further provides a computer readable storage medium, wherein the computer readable storage medium stores computer executable instructions, and the processing method for implementing data message reception when the computer executable instructions are executed.
  • the embodiment of the present invention by performing packet processing on multiple data packets to share one packet header, the actual transmission overhead of each data packet is reduced, that is, the packet header is relatively reduced. The overhead in the packet is further increased, which in turn increases the bandwidth utilization of the packet transmission.
  • only the data packets that are in need are subjected to the packet processing, and the data packets may be from the same sending end, or may be from different sending ends, that is, the embodiment of the present invention supports multiple The packets of the destination address are multiplexed, and the networking modes of the sender and the receiver are also supported, so that the data packets in the network can be processed in a more flexible manner, thereby improving the packet transmission in the network. Bandwidth utilization.
  • FIG. 1 is a schematic diagram of a cascade networking of a BSS network element RNC and a NodeB in an embodiment of an application scenario;
  • FIG. 2 is a schematic flowchart of a method for processing data packet transmission according to Embodiment 1 of the present invention
  • step S120 in FIG. 2 is a schematic diagram of a refinement process of step S120 in FIG. 2;
  • FIG. 4 is a schematic structural diagram of a sub-packet in a packet of a packet according to Embodiment 1 of the present invention.
  • FIG. 5 is a schematic structural diagram of a packet of a packet according to Embodiment 1 of the present invention.
  • FIG. 6 is another schematic structural diagram of a packet of a packet according to Embodiment 1 of the present invention.
  • FIG. 7 is another schematic flowchart of a method for processing data packet transmission according to Embodiment 1 of the present invention.
  • FIG. 8 is a first schematic flowchart 1 of a method for processing data packet receiving according to Embodiment 1 of the present invention.
  • FIG. 9 is a schematic structural diagram of data packets obtained after unpacking processing according to Embodiment 1 of the present invention.
  • FIG. 10 is a schematic diagram showing the refinement process of step S230 in FIG. 8;
  • FIG. 11 is a second schematic flowchart of a method for processing data packet receiving according to Embodiment 1 of the present invention.
  • FIG. 12 is a schematic flowchart 3 of a method for processing data packet receiving according to Embodiment 1 of the present invention.
  • FIG. 13 is a schematic diagram of functional blocks of a device for processing data packet transmission according to Embodiment 2 of the present invention.
  • FIG. 14 is a schematic diagram of a refinement function module of the parallel processing module in FIG. 13;
  • FIG. 15 is a schematic diagram of functional blocks of a data packet receiving processing apparatus according to Embodiment 2 of the present invention.
  • 16 is a schematic diagram of a refinement function module of the unpacking processing module of FIG. 15;
  • FIG. 17 is a schematic diagram of another functional module of a data packet receiving processing apparatus according to Embodiment 2 of the present invention.
  • the packet header processing is performed by using multiple data packets to reduce the packet header overhead, thereby improving the bandwidth utilization ratio during packet transmission.
  • the packet packet processing method and the packet unpacking processing manner provided by the embodiments of the present invention can be flexibly applied to various networking technologies, in consideration of different networking modes of the transmitting end and the receiving end. , thereby improving the bandwidth utilization of the message transmission network.
  • the network topology has a bus, a cascading, a star, a tree, a ring, a mesh, and the like. For the sake of convenience, in the embodiment of the present invention, only the cascading network is used as an example. Ming, other networking methods are similar, so do not go into too much detail.
  • FIG. 1 is a schematic diagram of a cascade networking of a BSS network element RNC and a NodeB in an embodiment of an application scenario according to an embodiment of the present invention.
  • the RNC is connected to the upper-layer device NodeB1, and the physical layer link of the IUB interface used between the two may be an Ethernet link or an E1/T1, STM-1 link.
  • the upper-layer device NodeB1 is connected to its next-level device NodeB2, and the NodeB2 is connected to its lower-level device NodeBN, where N is a positive integer greater than or equal to 1, thereby forming a cascaded network as shown in FIG.
  • FIG. 2 is a schematic flowchart diagram of a method for processing data packet transmission according to an embodiment of the present invention.
  • the processing method for sending the data packet includes:
  • Step S110 Before transmitting the data packet, determine whether the data packet to be sent is a packet and process the packet;
  • different data packets have different overheads in the headers.
  • the voice packet transmitted by the Ethernet link is used between the RNC and the NodeB. If the number of bytes in the packet header of the voice packet is greater than the payload of the packet, the bandwidth utilization of the voice packet is transmitted. Will be greatly reduced. Therefore, it is necessary to determine whether the data packet to be sent is a packet and packet processing.
  • the method for determining whether the data packet to be sent is processed by the packet and the packet processing is not limited, and the data packet to be sent may be determined according to whether the source MAC address in the data packet corresponds to the specified MAC address. Whether the packet is processed by the packet or the packet is processed; or whether the data packet to be sent is determined to be a packet and processed according to whether the source IP address in the data packet corresponds to the specified IP address. For example, some sender devices only send short-length data packets or data packets sent through an interface are relatively short. Therefore, any data packet sent by a device or an interface can be fixed and packetized. Or by judging the length of the header in the data packet as a whole. The proportion of the length of the data message is judged. If the ratio is greater than 50%, it is determined that the packet processing is required.
  • the attributes of different data packets are not the same or are sent to the same destination address, that is, any packet attributes and different packet addresses are supported in this embodiment. Parallel processing of data packets.
  • Step S120 The data packet that is determined to be processed by the packet and processed by the packet is processed and packetized to generate a corresponding packet, wherein the packet is set with the packet identifier field and the packet is encapsulated.
  • the method includes at least a packet header and a plurality of sub-packets corresponding to the data packet processed by the packet and the packet, and the sub-packet includes at least a destination address identifier field of the data packet;
  • the packet shares a packet header, and each data packet is connected in the form of a sub-packet and the packet header is formed, thereby forming a larger packet, and the packet includes the packet header and the header.
  • a plurality of sub-packets, wherein the sub-packets correspond to data packets that are processed by the packet and the packet, that is, the sub-packets have the same transmission payload as the corresponding data packets.
  • the manner of the parallel packet processing is not limited, and may be set according to actual needs.
  • the data packet and the packet are generally included in the network transmission network.
  • a packet packet identifier field needs to be set in each packet.
  • the packet identifier may be a specified MAC address, or an IP address, or a UDP port number.
  • the packet identifier may be a specified MAC address, or an IP address, or a UDP port number.
  • the MAC address, IP address, or UDP port number used by the specified sender device can be reported as a packet. Text identification.
  • step S130 the packet of the parallel packet and the data packet not processed by the packet and the packet are added to the sending queue for transmission.
  • the packet needs to be added to the sending queue to wait for the sending, and at the same time, since some data packets do not need to be processed and packetized, The data packet that is not processed by the packet and the packet is also directly added to the sending queue to be sent.
  • the implementation manner of sending the packet in the sending queue is the same as that in the prior art, so it has not been done. More details.
  • the actual transmission overhead of each data packet is reduced, that is, the packet header is relatively reduced.
  • the overhead in the packet packet which in turn increases the bandwidth utilization of the packet transmission.
  • only the data packets that are in need are subjected to the packet processing, and the data packets may be from the same sending end, or may be from different sending ends, that is, the embodiment of the present invention supports multiple
  • the packets of the destination address are multiplexed, and the networking modes of the sender and the receiver are also supported, so that the data packets in the network can be processed in a more flexible manner, thereby improving the packet transmission in the network.
  • Bandwidth utilization bandwidth utilization.
  • FIG. 3 is a schematic diagram of the refinement process of step S120 in FIG. Based on the above embodiment, in the embodiment, the foregoing step S120 includes:
  • Step S1201 Apply a buffer of a preset length of the maximum frame length MFL and start a timer to perform timing;
  • the real-time and transmission size requirements of the packet transmission are considered. Therefore, by controlling the size of the buffer for storing and packetizing the message and setting a timer, the packet packet processing is controlled, and the specific processing is used. Controls the number of sub-packets in the packet. In addition, the time at which the timer is started can also be set according to actual needs. For example, the packet buffer is filled and the packet header is opened before being opened.
  • Step S1202 filling and packetizing the header into the parallel buffer, wherein the packet header field is set in the packet header;
  • the packet header includes a MAC packet header and an IP packet header, where the source MAC address in the MAC packet header corresponds to the MAC address of the sender, and the source IP address in the IP packet header corresponds to the packet header.
  • the IP address of the IP address; in addition, the setting of the destination MAC address in the MAC packet header and the destination IP address in the IP packet header is set according to the actual situation. For example, the multicast address or the receiving end can be set to be the network respectively. The address of the device.
  • the packet identifier field may be set and included in the packet header.
  • the setting of the packet identifier is not limited. For example, it may be a specified MAC address or an IP address.
  • the source MAC address or the source IP address in the packet header is specified as a packet identifier. Reduce the message accordingly The length in bytes of the header.
  • a UDP packet header may be added to the packet header header, where the UDP packet header is set with the specified UDP port number.
  • Step S1203 When the current length of the packet is less than the MFL, and the timer time is not reached, the sub-packets are sequentially arranged to fill the sub-packets after the packet header, wherein the sub-packet further includes at least the data packet to remove the packet header.
  • the data packet in order to facilitate the sub-packet to be restored to the data packet before the packet processing after the unpacking process, the data packet is accurately transmitted. Therefore, the data packet needs to be set in the sub-packet.
  • the destination address identifier field and the payload field of the data packet are removed.
  • the sub-packet is also set.
  • the length field of the sub-packet is a schematic diagram of the structure of the sub-packet in the packet, including the destination address identification field (Flag) of the data packet, the sub-packet length field (SubLen), and the data packet. Remove the payload field (Data) after the header.
  • step S1204 when the current length of the packet is greater than or equal to the MFL, or the timer expires, the related field in the header is updated and the cyclic redundancy check code of the current packet is generated (Cyclic). Redundancy Check (CRC) and fill the CRC into the current packet, and get the packet that can be sent.
  • CRC Redundancy Check
  • the related fields in the packet header are updated, such as the packet header checksum, the packet length, and the like.
  • the cyclic redundancy check code CRC of the packet is also generated and reported as a packet. A part of the text is sent together, as shown in FIG. 5 and FIG.
  • FIG. 7 another flow chart of the processing method of data packet transmission is shown.
  • Step S11 Send a message
  • the packet may include a data packet, a packet packet, a packet packet, and the like.
  • the packet processing in the present invention is preferably performed on a data packet having a smaller packet length.
  • Step S12 it is determined whether to perform the parallel packet processing, if the parallel packet processing is not performed, step S13 is performed, and if the parallel packet processing is performed, step S14 is performed;
  • Step S13 Put the packet that is not processed by the packet into the sending queue.
  • Step S14 starting a timer, and applying a buffer whose length is a preset maximum frame length MFL;
  • the timer is started and a buffer of length MFL is applied for storing and processing the data in the process.
  • Step S15 Filling a buffer header with a buffer
  • the packet header includes an Ethernet MAC header and an IP header.
  • the source MAC address in the MAC header is the MAC address of the sender, the source IP address is the IP address of the sender, and the padded header also contains the packet identifier.
  • Step S16 Calculate and save the length of the current packet.
  • the field for example, the destination address identifier may be an IP address of the receiving device or a network number of the receiving device, or a unique identifier in other networks, for distinguishing from other receiving devices.
  • Step S17 it is determined whether the length of the current packet is less than the MFL, if the Length is less than the MFL, step S18 is performed, if the Length is greater than or equal to the MFL, step S21 is performed;
  • Step S18 The destination address identifier field of the sub-packet, the length field of the sub-packet, and the payload field of the sub-packet are filled in the buffer header, and the payload of the sub-packet is the payload after the packet header is removed.
  • Step S19 determining whether the timer time of the timer arrives, if the time arrives, step S21 is performed, if the time has not arrived, step S20 is performed;
  • Step S20 waiting for the next message to be sent, if waiting for the next message to be sent, then return to S16, if not waiting for the next message to be sent, then return to step S19;
  • Step S21 updating and packetizing the header
  • the field header checksum in the header and the length of the packet length may be updated, or a CRC check code may be generated and filled into the end of the packet.
  • Step S22 Put the generated parallel packet into a sending queue to be sent;
  • Step S23 canceling the timer timing
  • the timer and the parameter MFL are used to control the completion of the parallel packet of a multiplexed data.
  • MFL Maximum Frame Length
  • the timer starts counting and puts the message into the multiplexed data buffer.
  • Subsequent packets that need to be combined are also multiplexed into the multiplexed data buffer until the total length of the timer or the parallel packet exceeds the MFL and the packet ends.
  • the parallel packet of the entire multiplexed data is placed in the send queue. .
  • the timer is re-timed and the above process is repeated.
  • FIG. 8 is a schematic flowchart 1 of a method for processing data packet reception according to an embodiment of the present invention. Based on any of the foregoing methods for processing data packet transmission, in this embodiment, the processing method for receiving the data packet includes:
  • Step S210 when receiving the message, determining whether the received message is a detachable packet, wherein the packet is set with a packet identifier field and includes at least a packet header. And a plurality of sub-packets corresponding to the data message for processing the packet and packet processing;
  • the packet received by the receiving device may be a data packet, a packet packet, or the like, and may also be a packet. Therefore, it is necessary to first determine whether the received packet is a packet. The message, however, because the packet may be biased during the transmission process and affect the accuracy of the packet, it is necessary to judge again whether the packet can be unpacked, that is, the packet is judged. Whether it meets the requirements of the receiving end, such as the length requirement.
  • the packet identifier is determined to be included in the packet, and if yes, the packet is determined to be a packet, and when the packet is determined to be a packet, the packet is calculated.
  • the CRC of the text determines whether the calculated CRC matches the CRC carried in the parallel packet, and if it matches, it is determined to be a detachable packet.
  • Step S220 if it is determined that the packet is a detachable packet, it is determined whether there is a sub-package corresponding to the receiving device in the packet.
  • the phase may be added to a field of the parallel packet during the process of performing the parallel packet processing.
  • the identifier of the receiving device should be marked so that the receiving end can make a judgment confirmation.
  • the identifier may be an IP address of the receiving device or a network number of the receiving device, or a unique identifier in other networks, for distinguishing from other receiving devices.
  • the packet may be correspondingly configured in one-time packet. All sub-packets of the receiving device are identified, and then unpacked together.
  • the loop processing may be performed after the packet is determined to be detachable and packetized. For example, after identifying a sub-packet and performing unpacking processing, the next sub-packet is identified, and the specific processing manner is set according to actual needs.
  • determining whether the sub-packet corresponding to the receiving end device exists in the parallel packet includes: determining, according to the destination address identifier of the data packet in the sub-packet of the packet, and the destination address of the receiving device Whether there is a sub-package corresponding to the receiving device in the packet, wherein the length of the sub-packet is used to determine the starting address of the next sub-packet.
  • Step S230 If there is a sub-packet corresponding to the receiving end device, the sub-packet corresponding to the receiving end device in the parallel packet is subjected to packet unpacking processing to obtain a data packet corresponding to the receiving end device;
  • the structure of the packet is mainly composed of a packet header and a plurality of sub-packets, wherein the sub-packets are obtained by performing packet processing on the corresponding data packets, and therefore, the sub-packets are used in the embodiment.
  • the unpacking process is the reverse process of the parallel packet processing, that is, the unpacking process of the sub-packet corresponds to the parallel packet processing of the data packet, so the unpacking process of the sub-packet is the process of restoring the sub-package to the corresponding data message.
  • the specific unpacking processing method is not limited, and specific settings are made according to actual needs.
  • step S240 the data packet obtained by the packet unpacking process corresponding to the sub-packet of the receiving device is added to the receiving queue to be received.
  • the processing of receiving the data packet corresponds to the processing of sending the data packet, and the processing of the packet header can reduce the overhead of the packet header, thereby improving the transmission of the payload.
  • the quantity, that is, the transmission bandwidth utilization is improved, and the processing of receiving the data packet is specifically matched with the processing of the data packet transmission, so as to ensure that the data packet can be correctly transmitted and received from the transmitting end to the receiving end, and the transmission is guaranteed. Increased bandwidth utilization.
  • FIG. 10 is a schematic flowchart of the refinement of step S230 in FIG. Based on the above embodiment, in the embodiment, the foregoing step S230 includes:
  • Step S2301 applying for an unpacking buffer
  • the unpacking buffer is used to store the assembly data of the data packet of the receiving end corresponding to the sub-packet, including the packet header and payload of the data packet.
  • Step S2302 Filling the unpacking buffer with a packet header, where the source address and the destination address in the packet header respectively correspond to the source address in the packet header and the address of the receiving device;
  • the packet header of the data packet formed by the unpacking needs to be processed correspondingly, that is, the source address in the header of the packet and
  • the destination address corresponds to the source address in the packet header and the address of the receiving device.
  • the source MAC address in the packet header of the data packet corresponds to the source MAC address in the packet header
  • the source IP address in the packet header of the data packet corresponds to the source IP address in the packet header.
  • the destination MAC address in the packet header corresponds to the destination MAC address of the receiving device.
  • the destination IP address in the packet header of the data packet corresponds to the destination IP address of the receiving device.
  • step S2303 the payload of the sub-packet corresponding to the receiving device is filled in the packet header filled in the unpacking buffer, and the related field in the filled packet header is updated to obtain the corresponding receiving device.
  • the data packet where the sub-packet includes at least a destination address identifier field of the data packet, a payload field after the data packet is removed, and a length field of the sub-packet.
  • the process of unpacking the sub-packets in the packet is essentially a process of splitting the sub-packets into corresponding data packets.
  • the payload of the sub-packet is filled, that is, the payload of the data packet after the packet header is removed.
  • the processing of receiving the data packet corresponds to the processing of sending the data packet, and the number of transmissions of the payload can be relatively increased due to the overhead of the packet header after the packet processing of the plurality of data packets is performed. That is, the transmission bandwidth utilization is improved, and the processing of data packet reception is specifically matched with the processing of data packet transmission, so as to ensure that the transmission bandwidth can be correctly transmitted and received from the sender to the receiver. Increased utilization.
  • FIG. 11 is a flowchart showing a processing method of data packet receiving according to an embodiment of the present invention.
  • the processing method for receiving the data packet further includes:
  • Step S250 When the receiving end device has a lower-level receiving end device and the lower-level receiving end device supports processing and packetizing the packet, the sub-packet corresponding to the receiving end device is deleted from the parallel packet and updated and packetized in the corresponding packet. After the relevant field, the updated packet is added to the sending queue for transmission;
  • step S260 when the receiving device has a lower-level receiving device and the lower-level receiving device does not support the processing of the packet, the packet is unpacked and processed by all the sub-packets that have not been subjected to packet unpacking.
  • the data packet of the receiving device is added to the sending queue for transmission.
  • the execution order of the above steps S250 and S260 is not limited.
  • the packet transmission mode of the different networking modes is different.
  • the NodeB2 device has the next-level device NodeB2, and the packet of the NodeB2 device may also exist in the packet. Therefore, when the receiving device has a lower-level receiving device and the lower-level receiving device supports the processing of the packet, the sub-packet corresponding to the receiving device is deleted from the packet and updated and reported. After the related fields of the text, such as the checksum field, the packet length field, and the destination address field, the updated packet is added to the sending queue to be sent to the next-level device for unpacking.
  • the packet is unpacked and processed for all sub-packets that have not been subjected to the packet unpacking process, and the corresponding lower-level receiving is obtained.
  • the data packet of the end device is added to the sending queue to be sent to the corresponding lower-level receiving end device.
  • the destination address of the packet header of the data packet sent to the lower-level device needs to be updated to the address of the lower-level device.
  • the destination MAC address in the MAC header of the packet header is also updated to the lower-level device MAC address, and the destination IP address in the IP header is updated to the IP address of the lower-level device.
  • Step S31 receiving a message
  • the packet received by the receiving end includes a data packet, a packet packet, and a packet packet.
  • Step S32 it is determined whether the received message is a packet, if it is not a packet, step S33 is performed, if it is a packet, step S34 is performed;
  • Step S33 processing according to the normal message processing flow.
  • Step S34 extracting and encoding the length field (Length) in the header
  • Step S35 determining whether the length of the packet is smaller than the maximum message frame length MFL that can be received by the receiving end, if otherwise, executing step S36, if yes, executing step S37;
  • step S36 the unpacking fails, and the entire packet is discarded; at this time, the packet length does not meet the receiving request of the receiving end;
  • Step S37 reading the length of the sub-packet (subLen) and the destination address identifier (flag);
  • the length subLen of the sub-packet and the destination address identifier flag can be read by using a pointer reading manner.
  • Step S38 After reading, calculate the unparsed length of the current packet.
  • Step S39 determining whether the flag of the obtained sub-packet corresponds to the identifier of the receiving device, such as the corresponding MAC address, IP address or other identifier, and if so, executing step S41, if otherwise, executing step S40;
  • Step S40 determining whether there is a lower-level device, and whether the lower-level device supports the parallel device; if the lower-level device exists and the lower-level device supports the parallel packet, step S48 is performed to directly parse the next sub-packet, and if not, that is, if the sub-device does not exist , or the subordinate device does not support the package, then step S41;
  • the receiving device has a lower-level device, even if the packet received by the receiving device corresponds to a data packet that is not the receiving device, all the packets in the packet can be combined at the receiving end. After the sub-packet is unpacked, it is sent to the corresponding lower-level device. The data packet that is not the receiving device is sent to the lower-level device in the form of a packet.
  • Step S41 applying for a free buffer
  • the free buffer is used to store various data of the unpacking to generate a complete data message.
  • Step S42 Filling the packet header in the buffer, and filling the payload of the sub-packet after the packet header; wherein the destination address of the packet header is the address corresponding to the destination address identifier flag, that is, the receiving device Address, the payload of the sub-packet corresponds to the payload of the data packet;
  • Step S43 updating related fields of the packet header of the data packet, such as a packet header checksum, a packet length, and the like;
  • Step S44 determining whether the obtained flag of the sub-packet corresponds to the identity of the receiving device, such as the corresponding MAC address, IP address or other identifier, if yes, step S45 is performed, otherwise step S46 is performed;
  • step S45 the data packet generated after the sub-packet corresponding to the receiving end is unpacked is added to the receiving queue, and is received by the receiving end;
  • Step S46 adding a data packet generated after the sub-packet corresponding to the receiving end is unpacked to the sending queue
  • Step S47 if there is a lower-level device and the lower-level device also supports the parallel packet, the sub-packet that is solved in the parallel packet is deleted, and other sub-packets behind the deleted sub-packet are forwarded.
  • Step S48 determining whether the parallel packet parses the last sub-packet, and if the last packet is not parsed, returns to execution S37, and if the last packet is parsed, step S49 is performed; step S49, and the unpacked packet is updated.
  • the destination address is updated to the lower device address, the update packet checksum field, and the message length field.
  • Step S50 Add the unpacked packet to the sending queue of the receiving device to be sent to the lower device.
  • FIG. 13 is a schematic diagram of functional blocks of a data packet transmission processing apparatus according to an embodiment of the present invention.
  • the processing device for sending the data packet includes:
  • the packet determining module 110 is configured to determine whether the data packet to be sent is a packet and packet processing before sending the data packet;
  • the network element MSC, HLR, VLR, AUC, SGSN, and GGSN in the core system can directly or indirectly send various data packets to the RNC, different.
  • Data packets have different overheads in their headers.
  • the voice packet transmitted by the Ethernet link is used between the RNC and the NodeB. If the number of bytes in the packet header of the voice packet is greater than the payload of the packet, the bandwidth utilization of the voice packet is transmitted. Will be greatly reduced. Therefore, it is necessary to determine whether the data packet to be sent is a packet and packet processing by the parallel packet determining module 110.
  • the manner in which the packet determination module 110 determines whether the data packet to be sent is a packet and performs packet processing is not limited, and the source MAC address or the source IP address in the data packet is determined to be specified according to whether the source MAC address or the source IP address in the data packet is specified.
  • the MAC address or IP address is determined. For example, some sender devices only send short-length data packets or data packets sent through an interface are relatively short. Therefore, any data packet sent by a device or an interface can be fixed and packetized. Or, by judging the ratio of the length of the packet header in the data packet to the length of the entire data packet, if the ratio is greater than 50%, it is determined that the packet processing needs to be performed.
  • the attributes of different data packets are not the same or are sent to the same destination address, that is, multiple message attributes and message addresses are supported in this embodiment. Parallel processing of data packets.
  • the packet processing module 120 is configured to process the data packet that is determined to perform packet processing and packet processing, and process the packet to generate a corresponding packet packet, wherein the packet packet identifier field is set in the packet packet.
  • the parallel packet includes at least a packet header and a plurality of sub-packets corresponding to the data packet processed by the packet and the packet, and the sub-packet includes at least a destination address identifier field of the data packet;
  • each data packet shares a packet header, and each data packet is connected in the form of a sub-packet and encapsulates the packet header, thereby forming a larger packet packet, and the packet packet includes and The packet header and the plurality of sub-packets, wherein the sub-packets correspond to the data packets that are processed by the packet and the packet, that is, the sub-packets have the same transmission payload as the corresponding data packets.
  • the manner of the parallel packet processing is not limited, and may be set according to actual needs.
  • the data packet and the packet are generally included in the network transmission network.
  • a packet packet identifier field may be set in each packet.
  • the parallel packet identifier includes at least a specified MAC address or an IP address or a UDP port number. For example, only a few specified sender devices in the entire network transmission network can perform packet processing. Therefore, the MAC address or IP address of the specified sender device or the UDP port number used for transmission can be reported as a packet. Text identification.
  • the message sending module 130 is configured to add the packet of the parallel packet and the data packet that is not processed by the packet and the packet to the sending queue for transmission.
  • the packet sending module 130 adds the packet to the sending queue to wait for the sending, and does not need to perform the packet because some data packets exist.
  • the packet processing is performed. Therefore, the data packet that is not processed by the packet and the packet is directly added to the sending queue to be sent, and the implementation manner of sending the packet in the sending queue is the same as that in the prior art. So don't go into too much detail.
  • processing device for transmitting the data packet of the present invention may be set in each of the transmitting end devices, or may be set as a separate device on the transmission path of the packet sending end, and the specific setting manner is according to actual needs. Make settings.
  • the actual transmission overhead of each data packet is reduced, that is, the packet header is relatively reduced.
  • the overhead in the packet packet which in turn increases the bandwidth utilization of the packet transmission.
  • only the data packets that are in need are subjected to the packet processing, and the data packets may be from the same sending end, or may be from different sending ends, that is, the embodiment of the present invention supports multiple
  • the packets of the destination address are multiplexed, and the networking modes of the sender and the receiver are also supported, so that the data packets in the network can be processed in a more flexible manner, thereby improving the packet transmission in the network.
  • Bandwidth utilization bandwidth utilization.
  • FIG. 14 is a schematic diagram of a refinement function module of the parallel processing module in FIG. Based on the foregoing embodiment, in the embodiment, the parallel processing module 120 includes:
  • the sub-packet quantity control unit 1201 is configured to apply a parallel buffer with a preset maximum frame length MFL and start a timer to control and control the number of sub-packets in the packet;
  • the quantity control unit 1201 controls the completion of a parallel packet by controlling the size of the buffer of the packet and the setting of the timer, and is specifically used for controlling the number of sub-packets in the packet, and further, the timer is started.
  • the time point can also be set according to actual needs, such as filling and packetizing the header in the parallel buffer.
  • the packet header filling unit 1202 is configured to fill and encode the packet header into the parallel packet buffer, wherein the packet header identifier field is set in the packet header header;
  • the present invention has two types of packets, and the packet header includes a MAC packet header and an IP packet header.
  • the source MAC address in the MAC packet header corresponds to the MAC address of the sender, and the source IP address in the IP packet header corresponds to The IP address of the sender; in addition, the setting of the destination MAC address in the MAC packet header and the destination IP address in the IP packet header is set according to the actual situation.
  • the multicast address can be set to be the network multicast address or received. The address of the end device.
  • the packet identifier field may be set and included in the packet header.
  • the setting of the packet identifier is not limited. For example, it may be a specified MAC address or an IP address.
  • the source MAC address or the source IP address in the packet header is specified as a packet identifier. Reduce the byte length of the packet header accordingly.
  • a UDP packet header may be added to the packet header header, where the UDP packet header is set with the specified UDP port number.
  • the sub-packet filling unit 1203 is configured to: when the current length of the packet is smaller than the MFL, and/or, when the timer time is not reached, the sub-packets are sequentially arranged and filled in the packet header, wherein the sub-packets are at least
  • the data field includes a payload field after the packet header is removed, and a length field of the sub-packet.
  • the data packet in order to facilitate the sub-packet to be restored to the data packet before the packet processing after the unpacking process, the data packet is accurately transmitted. Therefore, the data packet needs to be set in the sub-packet.
  • the destination address identifier field and the payload field of the data packet are removed.
  • the sub-packet is also set.
  • the packet packet generating unit 1204 is configured to: when the current length of the packet is greater than or equal to the MFL, and/or when the timer expires, update and packetize the related field in the header and generate the current packet.
  • the cyclic redundancy check code CRC of the message is filled into the current packet, and the packet that can be sent is obtained.
  • the related fields in the packet header are updated, such as the packet header checksum, the packet length, and the like.
  • the cyclic redundancy check code CRC of the packet is also generated and reported as a packet. Part of the text is sent together.
  • FIG. 15 is a schematic diagram of functional blocks of a data packet receiving processing apparatus according to an embodiment of the present invention.
  • the processing apparatus for receiving the data packet includes:
  • the unpacking determination module 210 is configured to: determine, when the packet is received, whether the received packet is a detachable packet, wherein the packet is configured with a packet identifier field, and at least The method includes a packet header and a plurality of sub-packets corresponding to the data packet processed by the packet and the packet processing;
  • the packet received by the receiving device may be a data packet, a packet packet, or the like, and may also be a packet. Therefore, the unpacking determining module 210 first determines the received packet. Whether the message is a parallel packet, but because the packet may be biased during the transmission process and affect the accuracy of the packet, it is necessary to judge again and whether the packet can be unpacked. That is, it is judged whether the packet is in conformity with the requirements of the receiving end, such as the length requirement.
  • the unpacking determination module 210 determines whether there is a packet identifier in the packet, and if yes, determines that the packet is a packet; when the unpacking determination module 210 determines that the packet is determined to be After the packet is received, the CRC of the packet is calculated and it is determined whether the calculated CRC matches the CRC carried in the packet, and if yes, the unpacking determining module 210 determines that the packet is Detachable and packaged messages.
  • the description of the processing method of the packet data identifier and the CRC check code that has been sent in the foregoing data packet has been described in the embodiment, and therefore, no further description is made in this embodiment.
  • the determining module 220 is configured to: when it is determined that the received packet is a detachable packet, determine whether the sub-packet corresponding to the receiving device exists in the parallel packet;
  • the identifier of the receiving end device is added to a field of the parallel packet during the process of performing the parallel packet processing, so that the receiving end performs the judgment confirmation.
  • the logo can It is the IP address of the receiving device or the network number of the receiving device, or the unique identifier in other networks, which is used to distinguish it from other receiving devices.
  • the packet may be correspondingly configured in one-time packet. All sub-packets of the receiving device are identified, and then unpacked together.
  • the loop processing may be performed after the packet is determined to be detachable and packetized. For example, after identifying a sub-packet and performing unpacking processing, the next sub-packet is identified, and the specific processing manner is set according to actual needs.
  • determining whether the sub-packet corresponding to the receiving end device exists in the parallel packet includes: determining, according to the destination address identifier of the data packet in the sub-packet and the destination address of the receiving device, The sub-packet corresponding to the receiving end device exists in the packet, wherein the length of the sub-packet is used to determine the starting address of the next sub-packet.
  • the unpacking processing module 230 is configured to: when a sub-packet corresponding to the receiving end device exists in the parallel packet, the sub-packet corresponding to the receiving end device is unpacked and processed to obtain a corresponding copy. a data packet of the receiving device;
  • the structure of the packet is mainly composed of a packet header and a plurality of sub-packets, wherein the sub-packets are obtained by performing packet processing on the corresponding data packets, and therefore, the sub-packets are used in the embodiment.
  • the unpacking process is the reverse process of the parallel packet processing, that is, the unpacking process of the sub-packet corresponds to the parallel packet processing of the data packet, so the unpacking process of the sub-packet is the process of restoring the sub-package to the corresponding data message.
  • the specific unpacking processing method is not limited, and specific settings are made according to actual needs.
  • the packet receiving module 240 is configured to add a data packet obtained by performing packet unpacking processing on the sub-packet corresponding to the receiving device in the packet to be added to the receiving queue for reception.
  • processing apparatus for receiving the data packet in the embodiment of the present invention may be disposed in each receiving end device, or may be set as a separate device on the transmission path of the packet receiving end, and the specific setting manner is based on Actually need to be set.
  • the processing of receiving the data packet corresponds to the processing of sending the data packet, and the processing of the packet header can reduce the overhead of the packet header, thereby improving the transmission of the payload.
  • the quantity, that is, the transmission bandwidth utilization is improved, and the processing of receiving the data packet is specifically matched with the processing of the data packet transmission, so as to ensure that the data packet can be correctly transmitted and received from the transmitting end to the receiving end, and the transmission is guaranteed. Increased bandwidth utilization.
  • FIG. 16 is a schematic diagram of a refinement function module of the unpacking processing module of FIG. Based on the above embodiment, in the embodiment, the unpacking processing module 230 includes:
  • the application unit 2301 is configured to apply for an unpacking buffer
  • the unpacking buffer is used to store the assembly data of the data packet of the receiving end corresponding to the sub-packet, including the packet header and payload of the data packet.
  • the data packet header filling unit 2302 is configured to fill the unpacking buffer with a packet header, where the source address and the destination address in the packet header respectively correspond to the source address and the local address in the packet header.
  • the packet header of the data packet formed by the unpacking needs to be processed correspondingly, that is, the source address in the header of the packet and
  • the destination address corresponds to the source address in the packet header and the address of the receiving device.
  • the source MAC address in the packet header of the data packet corresponds to the source MAC address in the packet header
  • the source IP address in the packet header of the data packet corresponds to the source IP address in the packet header.
  • the destination MAC address in the packet header corresponds to the destination MAC address of the receiving device.
  • the destination IP address in the packet header of the data packet corresponds to the destination IP address of the receiving device.
  • the data packet generating unit 2303 is configured to fill the payload of the sub-packet corresponding to the receiving device after the packet header filled in the unpacking buffer, and update the related field in the filled packet header to obtain a corresponding The data packet of the receiving device, wherein the sub-packet includes at least a destination address identifier field of the data packet, a payload field after the data packet is removed, and a length field of the sub-packet.
  • the process of unpacking the sub-packets in the packet is essentially a process of splitting the sub-packets into corresponding data packets.
  • the payload of the sub-packet is filled, that is, the payload of the data packet after the packet header is removed.
  • the processing of receiving the data packet corresponds to the processing of sending the data packet, and the number of transmissions of the payload can be relatively increased due to the overhead of the packet header after the packet processing of the plurality of data packets is performed. That is, the transmission bandwidth utilization is improved, and the processing of data packet reception is specifically matched with the processing of data packet transmission, so as to ensure that the transmission bandwidth can be correctly transmitted and received from the sender to the receiver. Increased utilization.
  • FIG. 17 is a schematic diagram of another functional module of a data packet receiving processing apparatus according to an embodiment of the present invention. Based on the foregoing embodiment, in the embodiment, the processing device for receiving the data packet further includes:
  • the first sending processing module 250 is configured to: when the receiving end device has a lower-level receiving end device, and the lower-level receiving end device supports processing and packetizing the packet, deleting the sub-packet corresponding to the receiving end device from the parallel packet and After updating and including the related fields of the packet, the updated packet is added to the sending queue for transmission;
  • the second sending processing module 260 is configured to: when the receiving device has a lower-level receiving device, and the lower-level receiving device does not support the processing of the packet, the packet is unpacked for all the sub-packets that are not currently unpacked. The packet processing is performed to obtain a data packet corresponding to the lower-level receiving end device, and the data packet is added to the sending queue for transmission.
  • the packet transmission mode corresponding to different networking modes is different.
  • the NodeB1 device has the next-level device NodeB2, and the packet may be in the packet.
  • the packet of the NodeB2 device exists. Therefore, when the receiving device has a lower-level receiving device and the lower-level receiving device supports the processing of the packet, the sub-packet corresponding to the receiving device is deleted from the packet. After updating the related fields of the packet (such as the checksum field, the packet length field, the destination address field, and so on), the updated packet is added to the sending queue to be sent to the next-level device for unpacking. deal with.
  • the packet is unpacked and processed for all sub-packets that have not been subjected to the packet unpacking process, and the corresponding lower-level receiving is obtained.
  • the data packet of the end device is added to the sending queue to be sent to the corresponding lower-level receiving end device.
  • the destination address of the packet header of the data packet sent to the lower-level device needs to be updated to the address of the lower-level device.
  • the destination MAC address in the MAC header of the packet header is also updated to the lower-level device MAC address, and the destination IP address in the IP header is updated to the IP address of the lower-level device.
  • the embodiment of the invention further provides a computer readable storage medium, wherein the computer readable storage medium stores computer executable instructions, and the processing method for implementing data message transmission when the computer executable instructions are executed.
  • the embodiment of the invention further provides a computer readable storage medium, wherein the computer readable storage medium stores computer executable instructions, and the processing method for implementing data message reception when the computer executable instructions are executed.
  • each module/unit in the above embodiment may be implemented in the form of hardware, for example, by implementing an integrated circuit to implement its corresponding function, or may be implemented in the form of a software function module, for example, executing a program stored in the memory by a processor. / instruction to achieve its corresponding function.
  • This application is not limited to any specific combination of hardware and software.
  • the foregoing technical solution can reduce the transmission overhead of data packets, thereby improving bandwidth utilization, and correspondingly expanding the applicable scope of data packet merging.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种数据报文发送接收的处理方法及装置,其中,数据报文发送的处理方法包括:在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,并包报文中设置有并包报文标识字段且并包报文至少包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;将并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。通过本发明实施例不仅可以减少数据报文的传输开销进而提高带宽利用率,同时,本发明实施例中的数据报文也并不限定需要使用相同的传输属性以及目的地址才能进行合并,因而本发明实施例也相应扩大了数据报文合并的适用范围。

Description

数据报文发送接收的处理方法及装置 技术领域
本文涉及但不限于通信技术领域,涉及数据报文发送接收的处理方法及装置。
背景技术
相关技术中一般网元之间传输IP(Internet Protocol,网络互连协议)数据报文的报文头是固定开销,且不管数据报文的有效载荷多小报文头的开销都不能省略,因而会造成链路带宽有效利用率较低。以移动通信基站子系统(Base Station Subsystem,BSS)为例,当BSS网元RNC(Radio Network Controller,无线网络控制器)与NodeB之间的IUB接口采用以太网链路传输时,语音报文等业务报文一般都很短,比如包括14字节MAC(Media Access Contro,媒体访问控制)头、20字节IP头、8字节UDP(User Datagram Protocol,用户数据报协议)头、4字节MAC层检验,以及7字节前导、1字节帧定界符,当数据报文的有效载荷小于54字节时,则数据报文传输时的带宽利用率就达不到50%。
当前解决方法主要是采用IPHC(Internet Protocol Header Compression,IP头压缩)以间隔发全头报文和压缩头报文,但该方法更适合点到点直连场景,而不适合于需要穿越交换机和路由器的以太网链路或其他组网方式。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本发明实施例提供一种数据报文发送接收的处理方法及装置,可以减少数据报文的传输开销,从而提高了带宽利用率。
本发明实施例提供一种数据报文发送的处理方法,所述数据报文发送的处理方法包括:
在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;
将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,所述并包报文中设置有并包报文标识字段,且所述并包报文至少包括并包报文头以及与进行报文并包处理的所述数据报文相对应的若干子包,所述子包包括所述数据报文的目的地址标识字段;
将所述并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。
可选地,所述将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文包括:
申请长度为预设最大帧长MFL的并包缓冲区并开启定时器进行计时;
向所述并包缓冲区中填充并包报文头,其中,并包报文头中设置有并包报文标识字段;
当并包报文的当前长度小于MFL,和/或,定时器时间未到达时,在所述并包报文头后依次排列填充若干子包,其中,子包至少还包括数据报文去掉报文头后的载荷字段以及子包的长度字段;
当并包报文的当前长度大于或等于MFL,和/或,定时器时间到达时,更新并包报文头中的相关字段,以及生成当前并包报文的循环冗余校验码CRC并将该CRC填充到当前并包报文中,得到可发送的并包报文。
可选地,所述确定待发送的数据报文是否进行报文并包处理包括:根据判断数据报文中的源媒体访问控制MAC地址是否对应为指定的MAC地址确定待发送的数据报文是否进行报文并包处理;或者,根据判断数据报文中的源网络互连协议IP地址是否对应为指定的IP地址确定待发送的数据报文是否进行报文并包处理;
其中,所述并包报文标识包括指定的MAC地址或IP地址或UDP端口号;所述数据报文的目的地址标识括接收设备的IP地址、接收设备的网络号、或与接收设备的IP地址相对应的标识符。
本发明实施例提供一种数据报文接收的处理方法,所述数据报文接收的处理方法包括:
当接收到报文时,确定所接收的报文是否为可拆包的并包报文,其中,所述并包报文中设置有并包报文标识字段,且包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;
若确定为可拆包的并包报文,则判断该并包报文中是否存在对应本接收端设备的子包;
若存在对应本接收端设备的子包,则将该并包报文中对应本接收端设备的子包进行报文拆包处理,以得到对应本接收端设备的数据报文;
将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收。
可选地,所述将该并包报文中对应本接收端设备的子包进行报文拆包处理,以得到对应本接收端设备的数据报文包括:
申请拆包缓冲区;
向所述拆包缓冲区中填充报文头,其中,该报文头中的源地址对应为并包报文头中的源地址,该报文头中的目的地址对应为本接收端设备的地址;
在所述拆包缓冲区中所填充的报文头后填充对应本接收端设备的子包的载荷并更新所填充的报文头中的相关字段,以得到对应本接收端设备的数据报文,其中,所述子包包括数据报文的目的地址标识字段、数据报文去掉报文头后的载荷字段以及子包的长度字段。
可选地,所述判断该并包报文中是否存在对应本接收端设备的子包包括:
根据并包报文内子包中数据报文的目的地址标识与本接收端设备的目的地址进行判断该并包报文中是否存在对应本接收端设备的子包,其中,子包的长度用于确定下一子包的起始地址。
可选地,所述当接收到报文时,确定所接收的报文是否为可拆包的并包报文包括:
当接收到报文时,确定并包报文中是否存在并包报文标识,若存在并包报文标识,则确定为并包报文;
当确定为并包报文后,计算该并包报文的循环冗余校验码CRC并判断计算所得到的CRC是否与该并包报文所携带的CRC相符合,若符合,则确定为可拆包的并包报文。
可选地,所述方法还包括:所述将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收之后,
当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段后,将更新后的并包报文加入发送队列中以待发送;
当本接收端设备存在下级接收端设备且下级接收端设备不支持处理并包报文时,将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送。
本发明实施例还提供一种数据报文发送的处理装置,所述数据报文发送的处理装置包括:
并包确定模块,设置为在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;
并包处理模块,设置为将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,所述并包报文中设置有并包报文标识字段,且所述并包报文至少包括并包报文头以及与进行报文并包处理的所述数据报文相对应的若干子包,所述子包包括数据报文的目的地址标识字段;
报文发送模块,设置为将并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。
可选地,所述并包处理模块包括:
子包数量控制单元,设置为申请长度为预设最大帧长MFL的并包缓冲区并开启定时器进行计时以控制并包报文中子包的数量;
并包报文头填充单元,设置为向所述并包缓冲区中填充并包报文头,其中,并包报文头中设置有并包报文标识字段;
子包填充单元,设置为当并包报文的当前长度小于MFL,和/或,定时 器时间未到达时,在所述并包报文头后依次排列填充若干子包,其中,子包至少还包括数据报文去掉报文头后的载荷字段以及子包的长度字段;
并包报文生成单元,设置为当并包报文的当前长度大于或等于MFL,和/或,定时器时间到达时,更新并包报文头中的相关字段,以及生成当前并包报文的循环冗余校验码CRC并将该CRC填充到当前并包报文中,得到可发送的并包报文。
本发明实施例还提供一种数据报文接收的处理装置,所述数据报文接收的处理装置包括:
拆包确定模块,设置为当接收到报文时,确定所接收的报文是否为可拆包的并包报文,其中,所述并包报文中设置有并包报文标识字段,且包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;
判断模块,设置为当确定所接收的报文为可拆包的并包报文时,判断该并包报文中是否存在对应本接收端设备的子包;
拆包处理模块,设置为当并包报文中存在对应本接收端设备的子包时,将该并包报文中对应本接收端设备的子包进行报文拆包处理以得到对应本接收端设备的数据报文;
报文接收模块,设置为将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收。
可选地,所述拆包处理模块包括:
申请单元,设置为申请拆包缓冲区;
数据报文头填充单元,设置为向所述拆包缓冲区中填充报文头,其中,该报文头中的源地址对应为并包报文头中的源地址,该报文头中的目的地址对应为本接收端设备的地址;
数据报文生成单元,设置为在所述拆包缓冲区中所填充的报文头后填充对应本接收端设备的子包的载荷并更新所填充的报文头中的相关字段,以得到对应本接收端设备的数据报文,其中,子包包括数据报文的目的地址标识字段、数据报文去掉报文头后的载荷字段以及子包的长度字段。
可选地,所述数据报文接收的处理装置还包括:
第一发送处理模块,设置为当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段后,将更新后的并包报文加入发送队列中以待发送;
第二发送处理模块,设置为当本接收端设备存在下级接收端设备且下级接收端设备不支持处理并包报文时,将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送。
本发明实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机可执行指令,所述计算机可执行指令被执行时实现数据报文发送的处理方法。
本发明实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机可执行指令,所述计算机可执行指令被执行时实现数据报文接收的处理方法。
本发明实施例中,通过将多个数据报文进行并包处理以共用一个并包报文头,从而减少了每个数据报文的实际传输开销,也即相对减小了报文头在整个并包报文中的开销,进而相对提高了报文传输的带宽利用率。此外,本发明实施例中仅对有需要的数据报文进行并包处理,数据报文可以是来自同一个发送端,也可以是来自不同的多个发送端,也即本发明实施例支持多个目的地址的报文复用,同时也支持发送端与接收端的多种组网方式,从而能够更加灵活地对组网内的数据报文进行并包处理,从而提高组网内报文传输的带宽利用率。在阅读并理解了附图和详细描述后,可以明白其它方面。
附图说明
图1为本发明实施例的一应用场景实施例中BSS网元RNC与NodeB的级联组网示意图;
图2为本发明实施例一的数据报文发送的处理方法的流程示意图;
图3为图2中步骤S120的细化流程示意图;
图4为本发明实施例一的并包报文中子包的结构示意图;
图5为本发明实施例一的并包报文的结构示意图;
图6为本发明实施例一的并包报文的另一结构示意图;
图7为本发明实施例一的数据报文发送的处理方法的另一流程示意图;
图8为本发明实施例一的数据报文接收的处理方法的流程示意图一;
图9为本发明实施例一的中拆包处理后所得到的数据报文的结构示意图;
图10为图8中步骤S230的细化流程示意图;
图11为本发明实施例一的数据报文接收的处理方法的流程示意图二;
图12为本发明实施例一的数据报文接收的处理方法的流程示意图三;
图13为本发明实施例二的数据报文发送的处理装置的功能模块示意图;
图14为图13中并包处理模块的细化功能模块示意图;
图15为本发明实施例二的数据报文接收的处理装置的功能模块示意图;
图16为图15中拆包处理模块的细化功能模块示意图;
图17为本发明实施例二的数据报文接收的处理装置的另一功能模块示意图。
具体实施方式
下面结合实施例和附图说明本申请的技术方案。应当理解,此处所描述的具体实施例仅用以解释本申请,并不用于限定本申请。
本发明实施例通过将多个数据报文进行并包处理,从而达到减少报文头开销,进而相对提高报文传输时对带宽的利用率。此外,考虑到不同设备所构成的发送端与接收端的组网方式的不同,本发明实施例所提供的报文并包处理方式以及报文拆包处理方式能够灵活适用于各种不同的组网,从而提升报文传输网络的带宽利用率。现在组网拓扑有总线形、级联形、星形、树形、环形、网状等等,为便于说明,本发明实施例中仅以级联形组网进行举例说 明,其他组网方式类似,因此不做过多赘述。
图1为本发明实施例的一应用场景实施例中BSS网元RNC与NodeB的级联组网示意图。在BSS系统中,RNC与上级设备NodeB1连接,二者之间所使用的IUB接口的物理层链路可以是以太网链路,也可以是E1/T1、STM-1链路。上级设备NodeB1再与其下一级设备NodeB2连接,NodeB2再与其下级设备NodeBN连接,其中N为大于或等于1的正整数,从而形成如图1所示的级联组网。需要说明的是,通常不同链路其所对应的传输协议不同,因而存在一些链路支持并包(复用报文)处理,如以太网链路,而有些不支持并包处理,如E1/T1链路。本发明实施例中以支持并包处理的以太网链路进行举例说明。此外,需要进一步说明的是,本发明实施例中,对于接收端设备与发送端设备的设置不限,如图1所示的RNC与NodeB既可以是发送端,同时也可以是接收端,具体根据实际组网需求进行设置。
实施例一
参照图2,图2为本发明实施例的数据报文发送的处理方法的流程示意图。本实施例中,所述数据报文发送的处理方法包括:
步骤S110,在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;
本实施例中,不同的数据报文其报文头所占开销不同。比如,RNC与NodeB之间采用以太网链路所传输的语音报文,若语音报文的报文头所占字节数大于报文的有效载荷,则该语音报文传输时的带宽利用率会大大下降。因此,需要确定待发送的数据报文是否进行报文并包处理。
本实施例中,对于确定待发送的数据报文是否进行报文并包处理的方式不限,可选根据判断数据报文中的源MAC地址是否对应为指定的MAC地址确定待发送的数据报文是否进行报文并包处理;或者,根据判断数据报文中的源IP地址是否对应为指定IP地址确定待发送的数据报文是否进行报文并包处理。比如有些发送端设备只发送长度较短的数据报文或者通过一接口所发送的数据报文都比较短,因此可以固定将一设备或者一接口所发送的任意数据报文都进行并包处理。或者通过判断数据报文中报文头的长度占整个 数据报文长度的比例进行判断,如果比例大于50%,则确定需要进行并包处理。
另外,需要进一步说明的是,本实施例中并不限定不同数据报文的属性是否相同或者是否都发送到同一目的地址,也即本实施例中支持任何报文属性以及不同报文地址的多个数据报文的并包处理。
步骤S120,将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,并包报文中设置有并包报文标识字段且并包报文至少包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包,子包至少包括数据报文的目的地址标识字段;
通常情况下,在任意组网中都不会仅存在一条符合并包处理的数据报文,因此,本实施例中可通过将至少两个数据报文进行并包处理,也即是每个数据报文共用一个报文头,而每个数据报文以子包的形式连接在并包报文头后,从而形成一个更大的并包报文,并包报文包括并包报文头以及若干子包,其中,子包与进行报文并包处理的数据报文相对应,也即是子包与对应的数据报文具有相同的传输载荷。本实施例中,对于并包处理的方式不限,可以根据实际需要进行设置。
此外,由于组网传输网络中一般会同时存在数据报文与并包报文,为便于相互区别,本实施例中需要在每个并包报文中设置一并包报文标识字段。可选的,并包报文标识可以是指定的MAC地址、或IP地址、或UDP端口号。比如整个组网传输网络中仅有指定的少数几个发送端设备可以进行并包处理,因此可将该指定的发送端设备的MAC地址、IP地址或传输所使用的UDP端口号作为并包报文标识。
步骤S130,将并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。
本实施例中,当完成一个并包报文后,需要将该并包报文加入到发送队列中以等待发送,同时,由于存在某些数据报文并不需要进行报文并包处理,因此,可直接将未进行报文并包处理的数据报文也加入到发送队列中以待发送,其中,将发送队列中的报文发送出去的实现方式与现有技术方式相同,因此不做过多赘述。
本实施例中,通过将多个数据报文进行并包处理以共用一个并包报文头,从而减少了每个数据报文的实际传输开销,也即相对减小了报文头在整个并包报文中的开销,进而相对提高了报文传输的带宽利用率。此外,本发明实施例中仅对有需要的数据报文进行并包处理,数据报文可以是来自同一个发送端,也可以是来自不同的多个发送端,也即本发明实施例支持多个目的地址的报文复用,同时也支持发送端与接收端的多种组网方式,从而能够更加灵活地对组网内的数据报文进行并包处理,从而提高组网内报文传输的带宽利用率。
可选地,参照图3,图3为图2中步骤S120的细化流程示意图。基于上述实施例,本实施例中,上述步骤S120包括:
步骤S1201,申请长度为预设最大帧长MFL的并包缓冲区并开启定时器进行计时;
本实施例中,考虑到报文传输的实时性与传输大小要求,因此,通过控制存储并包报文的缓冲区的大小以及设置定时器来控制一个报文并包处理的完成,具体用于控制并包报文中子包的数量,此外,开启定时器的时间点也可以根据实际需要进行设置,比如在并包缓冲区中填充并包报文头后再行开启。
步骤S1202,向所述并包缓冲区中填充并包报文头,其中,并包报文头中设置有并包报文标识字段;
本实施中,并包报文头主要包括MAC报文头和IP报文头,其中,MAC报文头中的源MAC地址对应发送端的MAC地址,IP报文头中的源IP地址对应为发送端的IP地址;另外,对于MAC报文头中的目的MAC地址以及IP报文头中的目的IP地址的设置具体根据实际情况进行设置,例如可分别对应设置为组网的组播地址或接收端设备的地址。
另外,本实施例中,为便于对网络中传输的并包报文与数据报文进行区分,可选在并包报文头中设置并包报文标识字段。对于并包报文标识的设置不限,例如可以是指定的MAC地址或IP地址,比如对并包报文头中的源MAC地址或源IP地址进行指定以作为并包报文标识,从而可相应减小报文 头的字节长度。另外,也可以在并包报文头中加上UDP报文头,其中,UDP报文头设置有指定的UDP端口号。
步骤S1203,当并包报文的当前长度小于MFL,并且定时器时间未到达时,在并包报文头后依次排列填充若干子包,其中,子包至少还包括数据报文去掉报文头后的载荷字段以及子包的长度字段;
本实施例中,为便于子包在进行拆包处理后能够还原为并包处理前的数据报文,从而实现对数据报文的精确发送,因此,在子包中需要设置有数据报文的目的地址标识字段以及数据报文去掉报文头后的载荷字段,同时,为便于对整个并包报文进行长度统计,同时也便于区分每个子包所属长度范围,因此,在子包中还设置有子包的长度字段,如图4所示,为并包报文中子包的结构示意图,包括数据报文的目的地址标识字段(Flag),子包长度字段(SubLen),以及数据报文去掉报文头后的载荷字段(Data)。
步骤S1204,当并包报文的当前长度大于或等于MFL,或定时器时间到达时,更新并包报文头中的相关字段,以及生成当前并包报文的循环冗余校验码(Cyclic Redundancy Check,CRC)并将该CRC填充到当前并包报文中,得到可发送的并包报文。
本实施例中,在并包报文的长度达到设定的MFL或者定时器时间到达时,需要对并包报文头中的相关字段进行更新,比如报文头校验和、报文长度等。此外,为进一步确保并包处理后的并包报文在发送端与接收端的一致正确性,本实施例中还生成了并包报文的循环冗余校验码CRC并将其作为并包报文的一部分一起进行发送,如图5、6所示的并包报文的结构示意图。
参照图7所示的数据报文发送的处理方法的另一流程示意图。
步骤S11、发送一个报文;
在本步骤中,报文可以包括发送数据报文、分组报文、包报文等,本发明中的并包处理优选针对报文长度较小的数据报文。
步骤S12、判断是否进行并包处理,若不进行并包处理,则执行步骤S13,若进行并包处理,则执行步骤S14;
步骤S13、将不进行并包处理的报文放到发送队列。
步骤S14、开启定时器以及申请一个长度为预设最大帧长MFL的缓冲区;
在本步骤中,开启定时器以及申请一个长度为MFL的缓冲区以用于存放并包处理过程中的数据。
步骤S15、向缓冲区填充报文头;
报文头包括以太网MAC头和IP头,MAC头中的源MAC地址是发送端的MAC地址,源IP地址是发送端的IP地址,并且该填充的报文头中还包含有并包标识。
步骤S16、计算并保存当前并包报文的长度;
可以通过以下公式计算当前并包报文的长度:Length=Length+subLen,其中Length初始值为0,subLen是子包的长度,子包包括子包的载荷、子包长度字段和子包目的地址标识字段,其中,例如目的地址标识可以是接收端设备的IP地址或是接收端设备的网络号,或者是其它网络中唯一的标识,用于与其它接收端设备区分。
步骤S17、判断当前并包报文的长度(Length)是否小于MFL,若Length小于MFL,则执行步骤S18,若Length大于或等于MFL,则执行步骤S21;
步骤S18、在缓冲区中报文头后依次填充子包的目的地址标识字段、子包的长度字段和子包的载荷字段,其中,子包的载荷为对应报文去除报文头后的载荷;
步骤S19、判断定时器的定时时间是否到达,若时间到达,则执行步骤S21,若时间未到达,则执行步骤S20;
步骤S20、等待下一个要发送的报文,若等待到下一个要发送的报文,则返回S16,若未等待到要发送的下一报文,则返回步骤S19;
步骤S21、更新并包报文头;
本步骤中可以更新并包报文头中的报文头校验和、并包报文长度等字段,或者还可以生成CRC校验码并将其填充到并包报文尾部。
步骤S22、将生成的并包放入发送队列以待发送;
步骤S23、取消定时器计时;
本实施例中,定时器和参数MFL(Max Frame Length,最大帧长)被用来控制一个复用数据的并包的完成。当需要并包的第一个报文产生时,定时器开始计时,将报文放入复用数据缓冲区中。后续需要并包的报文也依次复用到该复用数据缓冲区中,直到定时器到或者并包的总长度超过MFL时并包结束,整个复用数据的并包会放到发送队列中。当下一个需要并包的报文又产生时,定时器又重新计时,重复上述流程。
参照图8,图8为本发明实施例的数据报文接收的处理方法的流程示意图一。基于上述数据报文发送的处理方法任一实施例,本实施例中,所述数据报文接收的处理方法包括:
步骤S210,当接收到报文时,确定所接收的报文是否为可拆包的并包报文,其中,并包报文中设置有并包报文标识字段且至少包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;
本实施例中,接收端设备所接收到的报文既有可能是数据报文、分组报文等,同时也有可能是并包报文,因此,需要先判断接收到的报文是否为并包报文,然而由于并包报文在传送过程中可能会出现偏差而影响到并包报文的准确性,因而需要再次判断并包报文是否可进行拆包处理,也即判断并包报文是否符合接收端的要求,比如长度要求等。
可选地,当接收到报文时,确定并包报文中是否存在并包报文标识,若存在,则确定为并包报文;当确定为并包报文后,计算该并包报文的CRC并判断计算所得到的CRC是否与该并包报文所携带的CRC相符合,若符合,则确定为可拆包的并包报文。其中,并包报文标识与CRC校验码已在上述数据报文发送的处理方法的实施例中已做说明,因此本实施例中不再做过多赘述。
步骤S220,若确定为可拆包的并包报文,则判断该并包报文中是否存在对应本接收端设备的子包;
本实施例中,可通过在进行并包处理过程中,在并包的一字段中加入相 应的标示接收端设备的标识以便于接收端进行判断确认。其中,该标识可以是接收端设备的IP地址或是接收端设备的网络号,或者是其它网络中唯一的标识,用于与其它接收端设备区分。
本实施例中,考虑到并包报文中可能存在有对应本接收端设备的多个子包,因此,在确定为可拆包的并包报文后,可以一次性将并包报文中对应本接收端设备的所有子包识别出来,然后再一起进行拆包处理。此外,也可以是在确定为可拆包的并包报文后进行循环处理,比如先识别一个子包并进行拆包处理后,再识别下一个子包,具体处理方式根据实际需要进行设置。
可选地,判断该并包报文中是否存在对应本接收端设备的子包包括:根据并包报文内子包中数据报文的目的地址标识与本接收端设备的目的地址进行判断该并包报文中是否存在对应本接收端设备的子包,其中,子包的长度用于确定下一子包的起始地址。
步骤S230,若存在对应本接收端设备的子包,则将该并包报文中对应本接收端设备的子包进行报文拆包处理,以得到对应本接收端设备的数据报文;
本实施例中,并包报文的结构主要包括并包报文头以及若干子包,其中,子包为相应数据报文进行并包处理后所得到,因此,本实施例中对于子包的拆包处理是并包处理的逆向过程,也即子包的拆包处理与数据报文的并包处理相对应,因此子包的拆包处理就是将子包还原为相应数据报文的过程,具体拆包处理方式不限,根据实际需要进行具体设置。
步骤S240,将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收。
如图9所示的为进行拆包处理后所得到的数据报文格式。本实施例中,数据报文接收的处理与数据报文发送的处理相对应,由于多个数据报文进行并包处理后能够减少报文头所占开销,进而相对提高了对于有效载荷的传输数量,也即提高了传输带宽利用率,数据报文接收的处理具体与数据报文发送的处理相配合,以达到从发送端到接收端都能正确发送与接收数据报文的同时,保证传输带宽利用率的提升。
参照图10,图10为图8中步骤S230的细化流程示意图。基于上述实施例,本实施例中,上述步骤S230包括:
步骤S2301,申请拆包缓冲区;
本实施例中,拆包缓冲区用于存储进行子包所对应的本接收端的数据报文的组装数据,包括数据报文的报文头、载荷等。
步骤S2302,向所述拆包缓冲区中填充报文头,其中,该报文头中的源地址及目的地址分别对应为并包报文头中的源地址及本接收端设备的地址;
本实施例中,为便于本接收端设备对本接收端的数据报文进行处理,需要将拆包所形成的数据报文的报文头进行相应的处理,也即将该报文头中的源地址及目的地址分别对应为并包报文头中的源地址及本接收端设备的地址。其中,数据报文的报文头中源MAC地址对应并包报文头中的源MAC地址,数据报文的报文头中源IP地址对应并包报文头中的源IP地址,数据报文的报文头中目的MAC地址对应本接收端设备的目的MAC地址,数据报文的报文头中目的IP地址对应本接收端设备的目的IP地址。
步骤S2303,在所述拆包缓冲区中所填充的报文头后填充对应本接收端设备的子包的载荷并更新所填充的报文头中的相关字段,以得到对应本接收端设备的数据报文,其中,子包至少包括数据报文的目的地址标识字段、数据报文去掉报文头后的载荷字段以及子包的长度字段。
本实施例中,对于并包报文中子包的拆包处理过程实质就是将子包拆分以组装成对应数据报文的过程。在拆包缓冲区中填充报文头后填充子包的载荷,也即对应为进行并包处理时数据报文去掉报文头后的载荷。本实施例中,数据报文接收的处理与数据报文发送的处理相对应,由于多个数据报文进行并包处理后能够报文头所占开销,进而相对提高了对于有效载荷的传输数量,也即提高了传输带宽利用率,数据报文接收的处理具体与数据报文发送的处理相配合,以达到从发送端到接收端都能正确发送与接收数据报文的同时,保证传输带宽利用率的提升。
参照图11,图11为本发明实施例的数据报文接收的处理方法的流程示 意图二。基于上述实施例,本实施例中,上述步骤S240之后,所述数据报文接收的处理方法还包括:
步骤S250,当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段后,将更新后的并包报文加入发送队列中以待发送;
步骤S260,当本接收端设备存在下级接收端设备且下级接收端设备不支持处理并包报文时,将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送。
本实施例中,上述步骤S250与S260的执行顺序不限。
考虑到不同组网方式所对应的报文传输方式不同,比如图1所示的级联组网方式中,NodeB1设备存在下一级设备NodeB2,而并包报文中也可能存在NodeB2设备的报文,因此,当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段(比如校验和字段、报文长度字段、目的地址字段等)后,将更新后的并包报文加入发送队列中以待发送给下一级设备进行拆包处理。
此外,若本接收端设备存在下级接收端设备但下级接收端设备不支持处理并包报文,则将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送给相应的下级接收端设备。需要说明的是,在发给下级设备的数据报文的报文头的目的地址需要更新为下级设备的地址。也即将报文头的MAC头中的目的MAC地址更新为下级设备MAC地址,IP头中目的IP地址更新为下级设备的IP地址。
参照图12所示的数据报文接收的处理方法的流程示意图。三
步骤S31、接收一个报文;
接收端所接收的报文包括数据报文、分组报文、并包报文等;
步骤S32、判断接收到的报文是否为并包报文,若不是并包报文,则执行步骤S33,若是并包报文,则执行步骤S34;
步骤S33、按普通报文处理流程进行处理.
步骤S34、取出并包报文头中的长度字段(Length);
步骤S35、判断并包报文的长度(Length)是否小于本接收端可接收的最大报文帧长MFL,若否则执行步骤S36,若是则执行步骤S37;
步骤S36、解包失败,丢弃整个并包报文;此时并包报文长度不符合接收端的接收要求;
步骤S37、读取子包的长度(subLen)以及目的地址标识(flag);
在本实施例中,可以采用指针读取方式读取子包的长度subLen以及目的地址标识flag。
步骤S38、读取完后,计算当前并包报文未解析长度;
可以通过以下公式计算当前并包报文未解析长度:Length=Length-subLen,并将指针指向下一子包,比如通过子包的长度(subLen)确定下一子包。
步骤S39、判断获取的子包的flag是否对应为本接收端设备的标识,比如对应MAC地址、IP地址或其他标识符等,若是则执行步骤S41,若否则执行步骤S40;
步骤S40、判断是否存在下级设备,且下级设备是否支持并包;若存在下级设备且下级设备支持并包,则执行步骤S48,直接解析下一个子包,若否,也就是若不存在下级设备,或者下级设备不支持并包,则执行步骤S41;
其中,若本接收端设备存在下级设备,即使本接收端设备所接收到的并包报文中对应非本接收端设备的数据报文,既可以在本接收端将并包报文中的所有子包进行拆包处理后,再发送给相应的下级设备,也可以将非本接收端设备的数据报文不拆包处理直接以并包形式发送给下级设备;本实施例以后者为例。
步骤S41、申请一个空闲缓冲区;
空闲缓冲区用于存放拆包的各种数据以生成完整的数据报文。
步骤S42、在缓冲区中填充报文头,并在报文头后再填充子包的载荷;其中,报文头的目的地址为目的地址标识flag所对应的地址,也即本接收端设备的地址,子包的载荷对应为数据报文的载荷;
步骤S43、更新数据报文的报文头的相关字段,比如报文头校验和、报文长度等字段;
步骤S44、判断获取的子包的标识(flag)是否对应为本接收端设备的标识,比如对应MAC地址、IP地址或其他标识符等,若是则执行步骤S45,若否则执行步骤S46;
步骤S45、将对应本接收端的子包拆包后生成的数据报文加入到接收队列中,以待本接收端接收;
步骤S46,将对应不是本接收端的子包拆包后生成的数据报文加入到发送队列中;
步骤S47、可选的,若存在下级设备且下级设备也支持并包,则将并包报文中解出的子包删除并将该删除子包后面的其他子包都前移。
步骤S48、判断并包是否解析完最后一个子包,若没有解析完最后一个包,则返回执行S37,若解析完最后一个包,则执行步骤S49;步骤S49、更新解包后的并包报文中报文头的相关字段;
比如将目的地址更新为下级设备地址、更新报文校验和字段、报文长度字段等。
步骤S50、将经过拆包处理后的并包报文加入到本接收端设备的发送队列中,以待发送至下级设备。
实施例二
参照图13,图13为本发明实施例的数据报文发送的处理装置的功能模块示意图。本实施例中,所述数据报文发送的处理装置包括:
并包确定模块110,设置为在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;
本实施例中,在发送数据报文前,比如在通信系统中,核心系统中网元MSC,HLR,VLR,AUC,SGSN,GGSN都可以直接或间接向RNC发送各种数据报文,不同的数据报文其报文头所占开销不同。比如,RNC与NodeB之间采用以太网链路所传输的语音报文,若语音报文的报文头所占字节数大于报文的有效载荷,则该语音报文传输时的带宽利用率会大大下降。因此,需要通过并包确定模块110确定待发送的数据报文是否进行报文并包处理。
本实施例中,对于并包确定模块110确定待发送的数据报文是否进行报文并包处理的方式不限,可选根据判断数据报文中的源MAC地址或源IP地址是否对应为指定的MAC地址或IP地址进行确定。比如有些发送端设备只发送长度较短的数据报文或者通过一接口所发送的数据报文都比较短,因此可以固定将一设备或者一接口所发送的任意数据报文都进行并包处理。或者通过判断数据报文中报文头的长度占整个数据报文长度的比例进行判断,如果比例大于50%,则确定需要进行并包处理。
另外,需要进一步说明的是,本实施例中并不限定不同数据报文的属性是否相同或者是否都发送到同一目的地址,也即本实施例中支持任何报文属性以及报文地址的多个数据报文的并包处理。
并包处理模块120,设置为将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,并包报文中设置有并包报文标识字段且并包报文至少包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包,子包至少包括数据报文的目的地址标识字段;
通常情况下,在任意组网中都不会仅存在一条符合并包处理的数据报文,因此,本实施例中可通过并包处理模块120将至少两个数据报文进行并包处理,也即是每个数据报文共用一个报文头,而每个数据报文以子包的形式连接在并包报文头后,从而形成一个更大的并包报文,并包报文包括并包报文头以及若干子包,其中,子包与进行报文并包处理的数据报文相对应,也即是子包与对应的数据报文具有相同的传输载荷。本实施例中,对于并包处理的方式不限,可以根据实际需要进行设置。
此外,由于组网传输网络中一般会同时存在数据报文与并包报文,为便于相互区别,本实施例中可选在每个并包报文中设置一并包报文标识字段。 可选地,并包报文标识至少包括指定的MAC地址或IP地址或UDP端口号。比如整个组网传输网络中仅有指定的少数几个发送端设备可以进行并包处理,因此可将该指定的发送端设备的MAC地址或IP地址或传输所使用的UDP端口号作为并包报文标识。
报文发送模块130,设置为将并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。
本实施例中,当完成一个并包报文后,报文发送模块130将该并包报文加入到发送队列中以等待发送,同时,由于存在某些数据报文并不需要进行报文并包处理,因此,可直接将未进行报文并包处理的数据报文也加入到发送队列中以待发送,其中,将发送队列中的报文发送出去的实现方式与现有技术方式相同,因此不做过多赘述。
另外,需要说明的是,本发明的数据报文发送的处理装置可设置在各发送端设备内,或者也可以作为一个单独的设备设置在报文发送端的传输路径上,具体设置方式根据实际需要进行设置。
本实施例中,通过将多个数据报文进行并包处理以共用一个并包报文头,从而减少了每个数据报文的实际传输开销,也即相对减小了报文头在整个并包报文中的开销,进而相对提高了报文传输的带宽利用率。此外,本发明实施例中仅对有需要的数据报文进行并包处理,数据报文可以是来自同一个发送端,也可以是来自不同的多个发送端,也即本发明实施例支持多个目的地址的报文复用,同时也支持发送端与接收端的多种组网方式,从而能够更加灵活地对组网内的数据报文进行并包处理,从而提高组网内报文传输的带宽利用率。
参照图14,图14为图13中并包处理模块的细化功能模块示意图。基于上述实施例,本实施例中,所述并包处理模块120包括:
子包数量控制单元1201,设置为申请长度为预设最大帧长MFL的并包缓冲区并开启定时器进行计时以控制并包报文中子包的数量;
本实施例中,考虑到报文传输的实时性与传输大小要求,因此,子包数 量控制单元1201通过控制存储并包报文的缓冲区的大小以及设置定时器来控制一个并包报文的完成,具体用于控制并包报文中子包的数量,此外,开启定时器的时间点也可以根据实际需要进行设置,比如在并包缓冲区中填充并包报文头后再行开启。
并包报文头填充单元1202,设置为向所述并包缓冲区中填充并包报文头,其中,并包报文头中设置有并包报文标识字段;
本实施两种,并包报文头主要包括MAC报文头和IP报文头,其中,MAC报文头中的源MAC地址对应发送端的MAC地址,IP报文头中的源IP地址对应为发送端的IP地址;另外,对于MAC报文头中的目的MAC地址以及IP报文头中的目的IP地址的设置具体根据实际情况进行设置,例如可分别对应设置为组网的组播地址或接收端设备的地址。
另外,本实施例中,为便于对网络中传输的并包报文与数据报文进行区分,可选在并包报文头中设置并包报文标识字段。对于并包报文标识的设置不限,例如可以是指定的MAC地址或IP地址,比如对并包报文头中的源MAC地址或源IP地址进行指定以作为并包报文标识,从而可相应减小报文头的字节长度。另外,也可以在并包报文头中加上UDP报文头,其中,UDP报文头设置有指定的UDP端口号。
子包填充单元1203,设置为当并包报文的当前长度小于MFL,和/或,定时器时间未到达时,在并包报文头后依次排列填充若干子包,其中,子包至少还包括数据报文去掉报文头后的载荷字段以及子包的长度字段;
本实施例中,为便于子包在进行拆包处理后能够还原为并包处理前的数据报文,从而实现对数据报文的精确发送,因此,在子包中需要设置有数据报文的目的地址标识字段以及数据报文去掉报文头后的载荷字段,同时,为便于对整个并包报文进行长度统计,同时也便于区分各子包所属长度范围,因此,在子包中还设置有子包的长度字段,如图4所示。Flag对应于数据报文的目的地址标识字段,SubLen对应于子包的长度字段,Data对应于数据报文去掉报文头后的载荷字段。
并包报文生成单元1204,设置为当并包报文的当前长度大于或等于MFL,和/或,定时器时间到达时,更新并包报文头中的相关字段以及生成当前并包 报文的循环冗余校验码CRC并将该CRC填充到当前并包报文中,得到可发送的并包报文。
本实施例中,在并包报文的长度达到设定的MFL或者定时器时间到达时,需要对并包报文头中的相关字段进行更新,比如报文头校验和、报文长度等。此外,为进一步确保并包处理后的并包报文在发送端与接收端的一致正确性,本实施例中还生成了并包报文的循环冗余校验码CRC并将其作为并包报文的一部分一起进行发送。
参照图15,图15为本发明实施例的数据报文接收的处理装置的功能模块示意图。本实施例中,所述数据报文接收的处理装置包括:
拆包确定模块210,设置为当接收到报文时,确定所接收的报文是否为可拆包的并包报文,其中,并包报文中设置有并包报文标识字段,且至少包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;
本实施例中,接收端设备所接收到的报文既有可能是数据报文、分组报文等,同时也有可能是并包报文,因此,需要通过拆包确定模块210先判断接收到的报文是否为并包报文,然而由于并包报文在传送过程中可能会出现偏差而影响到并包报文的准确性,因而需要再次判断并包报文是否可进行拆包处理,也即判断并包报文是否符合接收端的要求,比如长度要求等。
可选地,当接收到报文时,拆包确定模块210确定并包报文中是否存在并包报文标识,若存在,则确定为并包报文;当拆包确定模块210确定为并包报文后,计算该并包报文的CRC并判断计算所得到的CRC是否与该并包报文所携带的CRC相符合,若符合,则拆包确定模块210确定该并包报文为可拆包的并包报文。其中,并包报文标识与CRC校验码已在上述数据报文发送的处理方法的实施例中已做说明,因此本实施例中不再做过多赘述。
判断模块220,设置为当确定所接收的报文为可拆包的并包报文时,判断该并包报文中是否存在对应本接收端设备的子包;
本实施例中,可通过在进行并包处理过程中,在并包的一字段中加入相应的标示接收端设备的标识以便于接收端进行判断确认。其中,该标识可以 是接收端设备的IP地址或是接收端设备的网络号,或者是其它网络中唯一的标识,用于与其它接收端设备区分。
本实施例中,考虑到并包报文中可能存在有对应本接收端设备的多个子包,因此,在确定为可拆包的并包报文后,可以一次性将并包报文中对应本接收端设备的所有子包识别出来,然后再一起进行拆包处理。此外,也可以是在确定为可拆包的并包报文后进行循环处理,比如先识别一个子包并进行拆包处理后,再识别下一个子包,具体处理方式根据实际需要进行设置。
可选地,判断该并包报文中是否存在对应本接收端设备的子包包括:根据并包报文内子包中数据报文的目的地址标识与本接收端设备的目的地址进行判断判断该并包报文中是否存在对应本接收端设备的子包,其中,子包的长度用于确定下一子包的起始地址。
拆包处理模块230,设置为当并包报文中存在对应本接收端设备的子包时,将该并包报文中对应本接收端设备的子包进行报文拆包处理以得到对应本接收端设备的数据报文;
本实施例中,并包报文的结构主要包括并包报文头以及若干子包,其中,子包为相应数据报文进行并包处理后所得到,因此,本实施例中对于子包的拆包处理是并包处理的逆向过程,也即子包的拆包处理与数据报文的并包处理相对应,因此子包的拆包处理就是将子包还原为相应数据报文的过程,具体拆包处理方式不限,根据实际需要进行具体设置。
报文接收模块240,设置为将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收。
另外,需要说明的是,本发明实施例的数据报文接收的处理装置可设置在各接收端设备内,或者也可以作为一个单独的设备设置在报文接收端的传输路径上,具体设置方式根据实际需要进行设置。
本实施例中,数据报文接收的处理与数据报文发送的处理相对应,由于多个数据报文进行并包处理后能够减少报文头所占开销,进而相对提高了对于有效载荷的传输数量,也即提高了传输带宽利用率,数据报文接收的处理具体与数据报文发送的处理相配合,以达到从发送端到接收端都能正确发送与接收数据报文的同时,保证传输带宽利用率的提升。
参照图16,图16为图15中拆包处理模块的细化功能模块示意图。基于上述实施例,本实施例中,所述拆包处理模块230包括:
申请单元2301,设置为申请拆包缓冲区;
本实施例中,拆包缓冲区用于存储进行子包所对应的本接收端的数据报文的组装数据,包括数据报文的报文头、载荷等。
数据报文头填充单元2302,设置为向所述拆包缓冲区中填充报文头,其中,该报文头中的源地址及目的地址分别对应为并包报文头中的源地址及本接收端设备的地址;
本实施例中,为便于本接收端设备对本接收端的数据报文进行处理,需要将拆包所形成的数据报文的报文头进行相应的处理,也即将该报文头中的源地址及目的地址分别对应为并包报文头中的源地址及本接收端设备的地址。其中,数据报文的报文头中源MAC地址对应并包报文头中的源MAC地址,数据报文的报文头中源IP地址对应并包报文头中的源IP地址,数据报文的报文头中目的MAC地址对应本接收端设备的目的MAC地址,数据报文的报文头中目的IP地址对应本接收端设备的目的IP地址。
数据报文生成单元2303,设置为在所述拆包缓冲区中所填充的报文头后填充对应本接收端设备的子包的载荷并更新所填充的报文头中的相关字段以得到对应本接收端设备的数据报文,其中,子包至少包括数据报文的目的地址标识字段、数据报文去掉报文头后的载荷字段以及子包的长度字段。
本实施例中,对于并包报文中子包的拆包处理过程实质就是将子包拆分以组装成对应数据报文的过程。在拆包缓冲区中填充报文头后填充子包的载荷,也即对应为进行并包处理时数据报文去掉报文头后的载荷。本实施例中,数据报文接收的处理与数据报文发送的处理相对应,由于多个数据报文进行并包处理后能够报文头所占开销,进而相对提高了对于有效载荷的传输数量,也即提高了传输带宽利用率,数据报文接收的处理具体与数据报文发送的处理相配合,以达到从发送端到接收端都能正确发送与接收数据报文的同时,保证传输带宽利用率的提升。
参照图17,图17为本发明实施例的数据报文接收的处理装置的另一功能模块示意图。基于上述实施例,本实施例中,所述数据报文接收的处理装置还包括:
第一发送处理模块250,设置为当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段后,将更新后的并包报文加入发送队列中以待发送;
第二发送处理模块260,设置为当本接收端设备存在下级接收端设备且下级接收端设备不支持处理并包报文时,将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送。
本实施例中,考虑到不同组网方式所对应的报文传输方式不同,比如图1所示的级联组网方式中,NodeB1设备存在下一级设备NodeB2,而并包报文中也可能存在NodeB2设备的报文,因此,当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段(比如检验和字段、报文长度字段、目的地址字段等)后,将更新后的并包报文加入发送队列中以待发送给下一级设备进行拆包处理。
此外,若本接收端设备存在下级接收端设备但下级接收端设备不支持处理并包报文,则将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送给相应的下级接收端设备。需要说明的是,在发给下级设备的数据报文的报文头的目的地址需要更新为下级设备的地址。也即将报文头的MAC头中的目的MAC地址更新为下级设备MAC地址,IP头中目的IP地址更新为下级设备的IP地址。
本发明实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机可执行指令,所述计算机可执行指令被执行时实现数据报文发送的处理方法。
本发明实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机可执行指令,所述计算机可执行指令被执行时实现数据报文接收的处理方法。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件(例如处理器)完成,所述程序可以存储于计算机可读存储介质中,如只读存储器、磁盘或光盘等。可选地,上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地,上述实施例中的各模块/单元可以采用硬件的形式实现,例如通过集成电路来实现其相应功能,也可以采用软件功能模块的形式实现,例如通过处理器执行存储于存储器中的程序/指令来实现其相应功能。本申请不限制于任何特定形式的硬件和软件的结合。本领域的普通技术人员应当理解,可以对本申请的技术方案进行修改或者等同替换,而不脱离本申请技术方案的精神和范围,均应涵盖在本申请的权利要求范围当中。
工业实用性
上述技术方案可以减少数据报文的传输开销进而提高带宽利用率,并相应扩大了数据报文合并的适用范围。

Claims (13)

  1. 一种数据报文发送的处理方法,所述数据报文发送的处理方法包括:
    在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;
    将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,所述并包报文中设置有并包报文标识字段,且所述并包报文至少包括并包报文头以及与进行报文并包处理的所述数据报文相对应的若干子包,所述子包包括所述数据报文的目的地址标识字段;
    将所述并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。
  2. 如权利要求1所述的数据报文发送的处理方法,其中:所述将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文包括:
    申请长度为预设最大帧长MFL的并包缓冲区并开启定时器进行计时;
    向所述并包缓冲区中填充并包报文头,其中,并包报文头中设置有并包报文标识字段;
    当并包报文的当前长度小于MFL,和/或,定时器时间未到达时,在所述并包报文头后依次排列填充若干子包,其中,子包至少还包括数据报文去掉报文头后的载荷字段以及子包的长度字段;
    当并包报文的当前长度大于或等于MFL,和/或,定时器时间到达时,更新并包报文头中的相关字段,以及生成当前并包报文的循环冗余校验码CRC并将该CRC填充到当前并包报文中,得到可发送的并包报文。
  3. 如权利要求2所述的数据报文发送的处理方法,其中:所述确定待发送的数据报文是否进行报文并包处理包括:根据判断数据报文中的源媒体访问控制MAC地址是否对应为指定的MAC地址确定待发送的数据报文是否进行报文并包处理;或者,根据判断数据报文中的源网络互连协议IP地址是否对应为指定的IP地址确定待发送的数据报文是否进行报文并包处理;
    其中,所述并包报文标识包括指定的MAC地址或IP地址或UDP端口号;所述数据报文的目的地址标识括接收设备的IP地址、接收设备的网络号、或与接收设备的IP地址相对应的标识符。
  4. 一种数据报文接收的处理方法,所述数据报文接收的处理方法包括:
    当接收到报文时,确定所接收的报文是否为可拆包的并包报文,其中,所述并包报文中设置有并包报文标识字段,且包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;
    若确定为可拆包的并包报文,则判断该并包报文中是否存在对应本接收端设备的子包;
    若存在对应本接收端设备的子包,则将该并包报文中对应本接收端设备的子包进行报文拆包处理,以得到对应本接收端设备的数据报文;
    将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收。
  5. 如权利要求4所述的数据报文接收的处理方法,其中:所述将该并包报文中对应本接收端设备的子包进行报文拆包处理,以得到对应本接收端设备的数据报文包括:
    申请拆包缓冲区;
    向所述拆包缓冲区中填充报文头,其中,该报文头中的源地址对应为并包报文头中的源地址,该报文头中的目的地址对应为本接收端设备的地址;
    在所述拆包缓冲区中所填充的报文头后填充对应本接收端设备的子包的载荷并更新所填充的报文头中的相关字段,以得到对应本接收端设备的数据报文,其中,所述子包包括数据报文的目的地址标识字段、数据报文去掉报文头后的载荷字段以及子包的长度字段。
  6. 如权利要求5所述的数据报文接收的处理方法,其中:所述判断该并包报文中是否存在对应本接收端设备的子包包括:
    根据并包报文内子包中数据报文的目的地址标识与本接收端设备的目的地址进行判断该并包报文中是否存在对应本接收端设备的子包,其中,子包的长度用于确定下一子包的起始地址。
  7. 如权利要求4-6中任一项所述的数据报文接收的处理方法,其中:所述当接收到报文时,确定所接收的报文是否为可拆包的并包报文包括:
    当接收到报文时,确定并包报文中是否存在并包报文标识,若存在并包 报文标识,则确定为并包报文;
    当确定为并包报文后,计算该并包报文的循环冗余校验码CRC并判断计算所得到的CRC是否与该并包报文所携带的CRC相符合,若符合,则确定为可拆包的并包报文。
  8. 如权利要求7所述的数据报文接收的处理方法,所述方法还包括:所述将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收之后,
    当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段后,将更新后的并包报文加入发送队列中以待发送;
    当本接收端设备存在下级接收端设备且下级接收端设备不支持处理并包报文时,将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送。
  9. 一种数据报文发送的处理装置,所述数据报文发送的处理装置包括:
    并包确定模块,设置为在发送数据报文前,确定待发送的数据报文是否进行报文并包处理;
    并包处理模块,设置为将确定进行报文并包处理的数据报文进行报文并包处理以生成相应的并包报文,其中,所述并包报文中设置有并包报文标识字段,且所述并包报文至少包括并包报文头以及与进行报文并包处理的所述数据报文相对应的若干子包,所述子包包括数据报文的目的地址标识字段;
    报文发送模块,设置为将并包报文以及未进行报文并包处理的数据报文加入发送队列中以待发送。
  10. 如权利要求9所述的数据报文发送的处理装置,其中:所述并包处理模块包括:
    子包数量控制单元,设置为申请长度为预设最大帧长MFL的并包缓冲区并开启定时器进行计时以控制并包报文中子包的数量;
    并包报文头填充单元,设置为向所述并包缓冲区中填充并包报文头,其中,并包报文头中设置有并包报文标识字段;
    子包填充单元,设置为当并包报文的当前长度小于MFL,和/或,定时器时间未到达时,在所述并包报文头后依次排列填充若干子包,其中,子包至少还包括数据报文去掉报文头后的载荷字段以及子包的长度字段;
    并包报文生成单元,设置为当并包报文的当前长度大于或等于MFL,和/或,定时器时间到达时,更新并包报文头中的相关字段,以及生成当前并包报文的循环冗余校验码CRC并将该CRC填充到当前并包报文中,得到可发送的并包报文。
  11. 一种数据报文接收的处理装置,所述数据报文接收的处理装置包括:
    拆包确定模块,设置为当接收到报文时,确定所接收的报文是否为可拆包的并包报文,其中,所述并包报文中设置有并包报文标识字段,且包括并包报文头以及与进行报文并包处理的数据报文相对应的若干子包;
    判断模块,设置为当确定所接收的报文为可拆包的并包报文时,判断该并包报文中是否存在对应本接收端设备的子包;
    拆包处理模块,设置为当并包报文中存在对应本接收端设备的子包时,将该并包报文中对应本接收端设备的子包进行报文拆包处理以得到对应本接收端设备的数据报文;
    报文接收模块,设置为将并包报文中对应本接收端设备的子包进行报文拆包处理所得到的数据报文加入接收队列中以待接收。
  12. 如权利要求11所述的数据报文接收的处理装置,其中:所述拆包处理模块包括:
    申请单元,设置为申请拆包缓冲区;
    数据报文头填充单元,设置为向所述拆包缓冲区中填充报文头,其中,该报文头中的源地址对应为并包报文头中的源地址,该报文头中的目的地址对应为本接收端设备的地址;
    数据报文生成单元,设置为在所述拆包缓冲区中所填充的报文头后填充对应本接收端设备的子包的载荷并更新所填充的报文头中的相关字段,以得到对应本接收端设备的数据报文,其中,子包包括数据报文的目的地址标识字段、数据报文去掉报文头后的载荷字段以及子包的长度字段。
  13. 如权利要求11或12所述的数据报文接收的处理装置,所述数据报文接收的处理装置还包括:
    第一发送处理模块,设置为当本接收端设备存在下级接收端设备且下级接收端设备支持处理并包报文时,将对应本接收端设备的子包从并包报文中删除并在相应更新并包报文的相关字段后,将更新后的并包报文加入发送队列中以待发送;
    第二发送处理模块,设置为当本接收端设备存在下级接收端设备且下级接收端设备不支持处理并包报文时,将当前未进行报文拆包处理的所有子包进行报文拆包处理,得到对应下级接收端设备的数据报文并将该数据报文加入发送队列中以待发送。
PCT/CN2016/098730 2015-11-27 2016-09-12 数据报文发送接收的处理方法及装置 WO2017088557A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510867635.6A CN106817726A (zh) 2015-11-27 2015-11-27 数据报文发送接收的处理方法及装置
CN201510867635.6 2015-11-27

Publications (1)

Publication Number Publication Date
WO2017088557A1 true WO2017088557A1 (zh) 2017-06-01

Family

ID=58763908

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/098730 WO2017088557A1 (zh) 2015-11-27 2016-09-12 数据报文发送接收的处理方法及装置

Country Status (2)

Country Link
CN (1) CN106817726A (zh)
WO (1) WO2017088557A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110971537A (zh) * 2019-12-19 2020-04-07 北京浪潮数据技术有限公司 一种数据传输方法、装置、设备及可读存储介质
CN111488015A (zh) * 2020-03-19 2020-08-04 成都理工大学 一种基于arm11平台的温湿度控制方法
CN112039777A (zh) * 2019-06-04 2020-12-04 华为技术有限公司 一种集合通信的方法、装置及系统
CN112532618A (zh) * 2020-11-26 2021-03-19 国网山西省电力公司电力科学研究院 用于稳控测试系统联调测试的非透明协议转换方法及装置
CN114157401A (zh) * 2021-12-03 2022-03-08 中国人民解放军国防科技大学 一种支持长短两种报文格式的重传缓冲装置

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108600124B (zh) * 2018-04-09 2020-10-13 上海电气泰雷兹交通自动化系统有限公司 基于安全协议的网络拆包和组包方法
CN109996288B (zh) * 2019-03-28 2022-11-01 京信网络系统股份有限公司 Rlc层的数据级联方法、装置、计算机设备和存储介质
CN110401509A (zh) * 2019-06-12 2019-11-01 广汽丰田汽车有限公司 用于提高汽车can总线传输效率的方法、设备、介质及装置
CN110381051A (zh) * 2019-07-12 2019-10-25 苏州浪潮智能科技有限公司 一种报文解析的方法、系统、设备及计算机可读存储介质
CN110445658B (zh) * 2019-08-16 2023-01-24 中国银行股份有限公司 一种报文处理方法及系统
CN111083208B (zh) * 2019-12-03 2022-10-28 华为技术有限公司 网络结构、网络中网元之间的报文发送方法及接收方法
CN111541749B (zh) * 2020-04-14 2023-05-02 杭州涂鸦信息技术有限公司 一种嵌入式设备的数据通信方法、系统及相关设备
CN115348333A (zh) * 2022-08-16 2022-11-15 南方电网电力科技股份有限公司 基于udp双端通信交互的数据传输方法、系统及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020064190A1 (en) * 2000-11-30 2002-05-30 Sikora John J. Method for compressing packet headers within a trunking protocol for aggregating multiple information channels across a network
CN101136856A (zh) * 2007-06-05 2008-03-05 中兴通讯股份有限公司 单板间合并报文传输方法和系统
CN101415276A (zh) * 2008-11-24 2009-04-22 中兴通讯股份有限公司 一种发送和接收数据的方法及其设备
CN101800750A (zh) * 2010-03-03 2010-08-11 华为技术有限公司 数据传输方法、装置及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020064190A1 (en) * 2000-11-30 2002-05-30 Sikora John J. Method for compressing packet headers within a trunking protocol for aggregating multiple information channels across a network
CN101136856A (zh) * 2007-06-05 2008-03-05 中兴通讯股份有限公司 单板间合并报文传输方法和系统
CN101415276A (zh) * 2008-11-24 2009-04-22 中兴通讯股份有限公司 一种发送和接收数据的方法及其设备
CN101800750A (zh) * 2010-03-03 2010-08-11 华为技术有限公司 数据传输方法、装置及系统

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112039777A (zh) * 2019-06-04 2020-12-04 华为技术有限公司 一种集合通信的方法、装置及系统
CN112039777B (zh) * 2019-06-04 2023-09-15 华为技术有限公司 一种集合通信的方法、装置及系统
US11818033B2 (en) 2019-06-04 2023-11-14 Huawei Technologies Co., Ltd. Collective communication method, apparatus, and system
CN110971537A (zh) * 2019-12-19 2020-04-07 北京浪潮数据技术有限公司 一种数据传输方法、装置、设备及可读存储介质
CN111488015A (zh) * 2020-03-19 2020-08-04 成都理工大学 一种基于arm11平台的温湿度控制方法
CN112532618A (zh) * 2020-11-26 2021-03-19 国网山西省电力公司电力科学研究院 用于稳控测试系统联调测试的非透明协议转换方法及装置
CN112532618B (zh) * 2020-11-26 2023-02-28 国网山西省电力公司电力科学研究院 用于稳控测试系统联调测试的非透明协议转换方法及装置
CN114157401A (zh) * 2021-12-03 2022-03-08 中国人民解放军国防科技大学 一种支持长短两种报文格式的重传缓冲装置
CN114157401B (zh) * 2021-12-03 2024-01-23 中国人民解放军国防科技大学 一种支持长短两种报文格式的重传缓冲装置

Also Published As

Publication number Publication date
CN106817726A (zh) 2017-06-09

Similar Documents

Publication Publication Date Title
WO2017088557A1 (zh) 数据报文发送接收的处理方法及装置
EP3451595B1 (en) Method, device and system for data transmission
US9894003B2 (en) Method, apparatus and system for processing data packet
JP5038425B2 (ja) パケット遠隔通信ネットワークにおけるトラフィックの制御の最適化プロセス
EP3611962B1 (en) Quality of service control method and device
US20160285820A1 (en) Method for processing address resolution protocol message, switch, and controller
US11134009B2 (en) Packet processing method and apparatus
EP3122012B1 (en) Data processing method and apparatus for openflow network
US11902401B2 (en) Data compression method and base station
CN109120540B (zh) 传输报文的方法、代理服务器和计算机可读存储介质
WO2021088813A1 (zh) 报文封装方法及装置、报文解封装方法及装置
WO2019101054A1 (zh) 聚合速率控制方法、设备以及系统
KR20090076816A (ko) Hspa를 이용하여 수신한 회선 교환 데이터의 오류 제어방법
WO2017091941A1 (zh) 一种处理业务数据包的方法及装置
WO2012100679A1 (zh) 一种服务质量QoS保持方法、装置及系统
JP2022517665A (ja) イーサネットフレームの伝送方法及び通信機器
US20160134522A1 (en) Data flow processing method, device, and system
CN108809549B (zh) 一种传输数据的方法及设备
EP4152808A1 (en) Quality of service control method, device, and system
EP2996303A1 (en) Input parameter generation method and device
WO2016061985A1 (zh) 报文处理方法、装置及系统
US8583822B2 (en) Method and system for minimum frame size support for a communication protocol encapsulated over Ethernet
CN107409100B (zh) 软件定义网络中进行通信的方法、装置及通信系统
RU2715016C1 (ru) Передающее устройство, способ, программа и носитель записи
WO2020192940A1 (en) Compressed transmission of ethernet traffic through a wireless link

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16867784

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16867784

Country of ref document: EP

Kind code of ref document: A1