KR20220160648A - Internet protocol version IPv6-based wireless network communication method and communication device - Google Patents

Abstract

A wireless network communication method and communication device based on Internet protocol version IPv6 are provided. The method includes determining a transmission path of a plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, where the TEID field indicates a bearer to which the plaintext IPv6 packet belongs; and transmitting the plaintext IPv6 packet on the determined transmission path of the plaintext IPv6 packet.

Description

Internet protocol version IPv6-based wireless network communication method and communication device

This application claims priority to Chinese Patent Application No. 202010281148.2 filed with the Chinese Intellectual Property Office on April 10, 2020 and entitled "INTERNET PROTOCOL VERSION IPV6-BASED WIRELESS NETWORK COMMUNICATION METHOD AND COMMUNICATION DEVICE", and this application is incorporated herein by reference in its entirety.

The present application relates to the field of communication, and more particularly, to a wireless network communication method and communication device based on Internet protocol version IPv6.

With the exhaustion of Internet Protocol version 4 (IPv4) addresses, there is a trend for countries to migrate IPv4 IP addresses to Internet Protocol version 6 (IPv6) addresses. In the IPv4 protocol, 5-tuples are commonly used in the telecommunications industry to determine the forwarding path of data packets. In the IPv6 protocol, a delivery path of a data packet may be determined based on a 3-tuple including a source address, a destination address, and a flow label. However, the transmission paths calculated based on the 3-tuple may be identical, and as a result, all packets are transmitted along the same path, wasting bandwidth.

The present application provides a wireless network communication method and communication device based on Internet protocol version IPv6. According to the communication method, IPv6 packets of the same bearer may be transmitted on the same path, or IPv6 packets of different bearers may be hashed to be transmitted on different transmission paths, thereby implementing load balancing.

According to a first aspect, a network communication method based on internet protocol version IPv6 is provided. The method may be performed by an access network device or a chip in an access network device, or the method may be performed by a core network device or a chip in a core network device. The method includes determining a transmission path of a plaintext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet, where the TEID field indicates a bearer to which the plaintext IPv6 packet belongs; and transmitting the plaintext IPv6 packet on the determined transmission path of the plaintext IPv6 packet.

Accordingly, the transmission path of the plaintext IPv6 packet is determined based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet. The Tunnel Endpoint Identifier (TEID) field is an identifier of a bearer, and the TEID field of each bearer is different. Therefore, the transmission path of the plaintext IPv6 packet is determined based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, so that IPv6 packets of the same bearer can be transmitted on the same route, and IPv6 packets of different bearers can be transmitted on different transmission routes. hashed to be transmitted on the .

With reference to the first aspect, in some implementations of the first aspect, determining a transmission path of the plaintext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet comprises: filling a flow label field of the plaintext IPv6 packet based on the identifier (TEID) field; obtaining a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the filled flow label field, where SIP and DIP are SIP and DIP of plaintext IPv6 packets; and determining a transmission path of the plaintext IPv6 packet based on the first hash value.

With reference to the first aspect, in some implementations of the first aspect, populating a Flow Label field of the plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet comprises: filling N bits into N bits of the flow label field, where the flow label field includes N bits; or obtaining a second hash value by performing hash calculation on the TEID field and the first parameter, and filling N bits of the second hash value into N bits of the flow label field, wherein the flow label field includes N bits. includes

With reference to the first aspect, in some implementations of the first aspect, a flow label field of a plaintext IPv6 packet includes a first field and a second field. The filling of the Flow Label field of the plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet includes determining, from the TEID field, a length equal to a first field or a second field of the flow label field. filling in a first field or a second field of a flow label field by intercepting a portion having a length; Alternatively, a hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, and from the second hash value, a portion having the same length as the length of the first or second field of the flow label field is intercepted , filling in the first field or the second field of the flow label field.

Referring to the first aspect, in some implementations of the first aspect, when a plaintext IPv6 packet is fragmented into a plurality of data chips, the method comprises: a flow label field of each data chip of the plurality of data chips, a source address SIP , and performing hash calculation based on the destination address DIP to obtain a third hash value, where SIP and DIP are SIP and DIP of respective data chips, and the content of the flow label field of each data chip is a plaintext IPv6 packet Same as the contents of the flow label field of -; and determining a transmission path of each data chip based on the third hash value.

With reference to the first aspect, in some implementations of the first aspect, the method comprises, if the plaintext IPv6 packet needs to be encrypted for transmission, the ciphertext based on the populated Flow Label field of the plaintext IPv6 packet. filling the flow label field of the IPv6 packet, where the ciphertext IPv6 packet is a packet obtained by encrypting the plaintext IPv6 packet; and obtaining a fourth hash value by performing hash calculation based on a second parameter involved in hash calculation and the populated flow label field of the ciphertext IPv6 packet; and determining a transmission path of the ciphertext IPv6 packet based on the fourth hash value.

With reference to the first aspect, in some implementations of the first aspect, populating the flow label field of the ciphertext IPv6 packet based on the populated Flow Label field of the plaintext IPv6 packet comprises: a flow label field of the ciphertext IPv6 packet; that the content of is the same as that of the Flow Label field of the plaintext IPv6 packet; or obtaining a fifth hash value by performing hash calculation based on the flow label field of the plaintext IPv6 packet and the second parameter, and filling the flow label field of the ciphertext IPv6 packet based on the fifth hash value.

With reference to the first aspect, in some implementations of the first aspect, the flow label field of the ciphertext packet includes a third field and a fourth field. Filling the flow label field of the ciphertext IPv6 packet based on the fifth hash value includes filling N bits of the fifth hash value into N bits of the flow label field of the ciphertext IPv6 packet, the flow label field including N bits. -; or intercepting a portion having the same length as the length of the third or fourth field of the flow label field of the ciphertext IPv6 packet from the fifth hash value, and obtaining the third or fourth field of the flow label field of the ciphertext IPv6 packet. Including the filling step.

With reference to the first aspect, in some implementations of the first aspect, the method includes: populating a Flow Label field of a ciphertext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv4 packet; A ciphertext IPv6 packet is a packet obtained by encrypting a plaintext packet -; obtaining a sixth hash value by performing hash calculation based on the filled flow label field of the ciphertext IPv6 packet and the second parameter; and determining a transmission path of the ciphertext IPv6 packet based on the sixth hash value.

With reference to the first aspect, in some implementations of the first aspect, populating a Flow Label field of the ciphertext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv4 packet comprises: filling N bits into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet contains N bits; or performing hash calculation on the TEID field and the second parameter to obtain a seventh hash value, and filling N bits of the seventh hash value into N bits of the flow label field of the ciphertext IPv6 packet - flow label of the ciphertext IPv6 packet. The field contains N bits - contains.

With reference to the first aspect, in some implementations of the first aspect, the flow label field of the ciphertext IPv6 packet includes a fifth field and a sixth field. Filling the Flow Label field of the ciphertext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet comprises, from the TEID field, a fifth field or a sixth field of the flow label field of the ciphertext IPv6 packet filling in a fifth field or a sixth field of a flow label field of the ciphertext IPv6 packet by intercepting a portion having a length equal to the length of the cipher text IPv6 packet; or performing hash calculation on the TEID field and the second parameter to obtain an eighth hash value, having a length equal to a length of a fifth field or a sixth field of the flow label field of the ciphertext IPv6 packet, from the eighth hash value. intercepting the part, and filling in a fifth field or a sixth field of the flow label field of the ciphertext IPv6 packet.

Referring to the first aspect, in some implementations of the first aspect, when a plaintext IPv4 packet is fragmented into a plurality of chips, the method further comprises: fragmenting the plaintext IPv4 packet into a plurality of chips; encrypting each of a plurality of chips to obtain a cipher text packet of each chip; and filling the flow label field of each chip's ciphertext packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet; obtaining a ninth hash value by performing hash calculation based on the flow label field of the ciphertext packet and the second parameter; and determining a transmission path of each ciphertext chip based on the ninth hash value.

With reference to the first aspect, in some implementations of the first aspect, populating a flow label field of each chip's ciphertext packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet comprises: N of the TEID field; filling bits into N bits of the flow label field of each chip's ciphertext packet, wherein the flow label field of each chip's ciphertext packet contains N bits; or performing hash calculation on the TEID field and the second parameter to obtain a tenth hash value, and filling N bits of the tenth hash value into N bits of the flow label field of each chip's ciphertext packet - each chip The flow label field of the ciphertext packet of contains N bits.

With reference to the first aspect, in some implementations of the first aspect, the flow label field of the ciphertext packet of each chip of the plaintext IPv4 packet includes a seventh field and an eighth field. Filling the flow label field of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext packet includes, from the TEID field, a seventh field or an eighth field of the flow label field of the ciphertext packet of each chip filling in a seventh field or an eighth field of a flow label field of the cipher text packet of each chip by intercepting a portion having a length equal to the length of the field; or performing hash calculation on the TEID field and the first parameter to obtain a ninth hash value, and from the ninth hash value, a length equal to the length of the seventh field or the eighth field of the flow label field of the ciphertext packet of each chip intercepting a portion having a length, and filling a seventh field or an eighth field of a flow label field of the cipher text packet of each chip.

With reference to the first aspect, in some implementations of the first aspect, the first parameter includes at least one of the following parameters: a SIP of the plaintext IPv6 packet, a DIP of the plaintext IPv6 packet, a next header of the plaintext IPv6 packet, The source port SPt of the plaintext IPv6 packet, and the destination port DPt of the plaintext IPv6 packet.

With reference to the first aspect, in some implementations of the first aspect, the second parameter includes at least one of the following parameters: a SIP of the ciphertext packet, a DIP of the ciphertext packet, and a next header of the ciphertext packet.

According to a second aspect, a communication method based on internet protocol version IPv6 is provided. This method may be performed by the secure gateway device or may be performed by a chip within the secure gateway device. The method includes receiving a plaintext packet transmitted by a core network device; filling a Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet, wherein the ciphertext IPv6 packet is a packet obtained by encrypting the plaintext packet; obtaining a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the populated flow label field of the ciphertext IPv6 packet; and determining a transmission path of the ciphertext IPv6 packet based on the first hash value.

With reference to the second aspect, in some implementations of the second aspect, the plaintext packet is an IPv6 packet or an IPv4 packet. Filling the Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet comprises: filling N bits of the TEID field into N bits of the Flow Label field of the ciphertext IPv6 packet - The flow label field of the ciphertext IPv6 packet contains N bits -; or performing hash calculation on the TEID field and the first parameter to obtain a second hash value, and filling N bits of the second hash value into N bits of the flow label field of the ciphertext IPv6 packet - flow label of the ciphertext IPv6 packet. The field contains N bits - contains.

With reference to the second aspect, in some implementations of the second aspect, the plaintext packet is an IPv6 packet or an IPv4 packet. The flow label field of the ciphertext IPv6 packet includes a first field and a second field. Filling the Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet includes, from the TEID field, a first field or a second field of the flow label field of the ciphertext IPv6 packet. intercepting a portion having a length equal to the length and filling in a first field or a second field of a flow label field of the ciphertext IPv6 packet; or performing hash calculation on the TEID field and the first parameter to obtain a third hash value, having a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet, from the third hash value. intercepting the part, and filling in a first field or a second field of the flow label field of the ciphertext IPv6 packet.

With reference to the second aspect, in some implementations of the second aspect, the plaintext packet is an IPv6 packet. Filling the Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet determines the flow of the plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet. Filling the label (Flow Label) field; and copying the filled-in Flow Label field of the plaintext IPv6 packet to the Flow Label field of the ciphertext IPv6 packet.

With reference to the second aspect, in some implementations of the second aspect, the plaintext packet is an IPv6 packet. When the plaintext packet is fragmented into multiple chips, the method includes filling a Flow Label field of the plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet; fragmenting the plaintext IPv6 packet filled with the flow label field into a plurality of chips, each of the plurality of chips including the filled flow label field; copying the flow label field of each chip to the flow label field of the encrypted cipher text packet of each chip; obtaining a fourth hash value by performing hash calculation based on the flow label field of the ciphertext packet and the first parameter; and determining a transmission path of each ciphertext packet based on the fourth hash value.

With reference to the second aspect, in some implementations of the second aspect, populating a Flow Label field of the plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet comprises: filling N bits into N bits of the flow label field of the plaintext IPv6 packet, wherein the flow label field of the plaintext IPv6 packet includes N bits; or performing hash calculation on the TEID field and the second parameter to obtain a fifth hash value, and filling N bits of the fifth hash value into N bits of the flow label field of the plaintext IPv6 packet - flow label of the plaintext IPv6 packet. The field contains N bits - contains.

With reference to the second aspect, in some implementations of the second aspect, the flow label field of the plaintext IPv6 packet includes a first field and a second field. Filling the Flow Label field of the plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet includes, from the TEID field, a first field or a second field of the flow label field of the plaintext IPv6 packet filling in a first field or a second field of a flow label field of a plaintext IPv6 packet by intercepting a portion having a length equal to the length of ; or performing hash calculation on the TEID field and the second parameter to obtain a sixth hash value, having a length equal to the length of the first field or the second field of the flow label field of the plaintext IPv6 packet, from the sixth hash value. intercepting the part, and filling the first field or the second field of the flow label field of the plaintext IPv6 packet.

With reference to the second aspect, in some implementations of the second aspect, when the plaintext packet is an IPv4 packet or an IPv6 packet, and the plaintext packet is fragmented into a plurality of chips, the method comprises fragmenting the plaintext packet into a plurality of chips. step; encrypting each of a plurality of chips to obtain a cipher text packet of each chip; filling the flow label field of each chip's ciphertext packet based on the tunnel endpoint identifier (TEID) field of the plaintext packet; obtaining a seventh hash value by performing hash calculation based on the flow label field of the ciphertext packet and the first parameter; and determining a transmission path of each cipher text packet based on the seventh hash value.

With reference to the second aspect, in some implementations of the second aspect, populating a flow label field of each chip's ciphertext packet based on a tunnel endpoint identifier (TEID) field of the plaintext packet comprises N bits of the TEID field filling N bits of the flow label field of the ciphertext packet of each chip, wherein the flow label field of the ciphertext packet of each chip includes N bits; or performing hash calculation on the TEID field and the first parameter to obtain an eighth hash value, and filling N bits of the eighth hash value into N bits of the flow label field of each chip's ciphertext packet - each chip The flow label field of the ciphertext packet of contains N bits.

With reference to the second aspect, in some implementations of the second aspect, the flow label field of the ciphertext packet of each chip includes a first field and a second field, and a tunnel endpoint identifier (TEID) field of the plaintext packet includes: Filling the flow label field of the ciphertext packet of each chip based on the TEID field intercepts a portion having the same length as the length of the first field or the second field of the flow label field of the ciphertext packet of each chip, , filling the first field or the second field of the flow label field of the cipher text packet of each chip; or obtaining a ninth hash value by performing hash calculation on the TEID field and the first parameter; and intercepting, from the ninth hash value, a portion having a length equal to the length of the first field or the second field of the flow label field of the ciphertext packet of each chip, the first of the flow label field of the ciphertext packet of each chip Filling in the field or second field.

With reference to the second aspect, in some implementations of the second aspect, the first parameter includes at least one of the following parameters: a SIP of the ciphertext packet, a DIP of the ciphertext packet, or a next header of the ciphertext packet.

With reference to the second aspect, in some implementations of the second aspect, the second parameter includes at least one of the following parameters: SIP of the plaintext packet, DIP of the plaintext packet, next header of the plaintext packet, The source port SPt, and the destination port DPt of the plaintext packet.

According to a third aspect, a communication device is provided. The communication device includes: a processing unit configured to determine a transmission path of a plaintext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet; and a transceiver unit configured to transmit the plaintext IPv6 packet on the determined transmission path of the plaintext IPv6 packet.

With reference to the third aspect, in some implementations of the third aspect, the processing unit is specifically configured to populate a Flow Label field of the plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet; ; obtaining a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the filled flow label field; and determine a transmission path of the plaintext IPv6 packet based on the first hash value.

With reference to the third aspect, in some implementations of the third aspect, the processing unit specifically fills N bits of the TEID field into N bits of the flow label field, where the flow label field includes N bits; or performing hash calculation on the TEID field and the first parameter to obtain a second hash value, and filling N bits of the second hash value into N bits of the flow label field, wherein the flow label field includes N bits do.

With reference to the third aspect, in some implementations of the third aspect, the flow label field of the plaintext IPv6 packet includes a first field and a second field. The processing unit specifically intercepts, from the TEID field, a portion having a length equal to the length of the first field or the second field of the flow label field, and fills the first field or the second field of the flow label field; Alternatively, a hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, and from the second hash value, a portion having the same length as the length of the first or second field of the flow label field is intercepted , configured to fill in the first field or the second field of the flow label field.

With reference to the third aspect, in some implementations of the third aspect, when a plaintext IPv6 packet is fragmented into a plurality of data chips, the processing unit performs a hash based on the flow label field and the first parameter of each of the plurality of data chips. obtaining a third hash value by performing calculation - the content of the flow label field of each data chip is identical to that of the flow label field of the plaintext IPv6 packet; and determine a transmission path of each data chip based on the third hash value.

With reference to the third aspect, in some implementations of the third aspect, the processing unit, if the plaintext IPv6 packet needs to be encrypted for transmission, generates the ciphertext based on the populated Flow Label field of the plaintext IPv6 packet. Fill in the flow label field of the IPv6 packet, where the ciphertext IPv6 packet is a packet obtained by encrypting the plaintext IPv6 packet; obtaining a fourth hash value by performing hash calculation based on a second parameter involved in hash calculation and the filled flow label field of the ciphertext IPv6 packet, where SIP and DIP are SIP and DIP of the ciphertext IPv6 packet; and determine a transmission path of the ciphertext IPv6 packet based on the fourth hash value.

With reference to the third aspect, in some implementations of the third aspect, the processing unit copies the Flow Label field of the plaintext IPv6 packet to the Flow Label field of the ciphertext IPv6 packet; or performing hash calculation on the second parameter and the flow label field of the plaintext IPv6 packet to obtain a fifth hash value, and further filling in the flow label field of the ciphertext IPv6 packet based on the fifth hash value. It consists of

With reference to the third aspect, in some implementations of the third aspect, the flow label field of the ciphertext packet includes a third field and a fourth field. The processing unit fills N bits of the fifth hash value into N bits of the flow label field of the ciphertext IPv6 packet, where the flow label field contains N bits; or intercepting a portion having the same length as the length of the third or fourth field of the flow label field of the ciphertext IPv6 packet from the fifth hash value, and obtaining the third or fourth field of the flow label field of the ciphertext IPv6 packet. It is further configured to fill.

With reference to the third aspect, in some implementations of the third aspect, the processing unit fills in a Flow Label field of the ciphertext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv4 packet - the ciphertext An IPv6 packet is a packet obtained by encrypting a plaintext packet -; obtain a sixth hash value by performing hash calculation based on the filled-in flow label field of the ciphertext IPv6 packet and the second parameter; and determine a transmission path of the ciphertext IPv6 packet based on the sixth hash value.

With reference to the third aspect, in some implementations of the third aspect, the processing unit fills N bits of the TEID field into N bits of the flow label field of the ciphertext IPv6 packet - the flow label field of the ciphertext IPv6 packet is N bits contains -; or performing hash calculation on the TEID field and the second parameter to obtain a seventh hash value, and fills N bits of the seventh hash value into N bits of a flow label field of the ciphertext IPv6 packet, wherein the ciphertext IPv6 The flow label field of a packet contains N bits.

With reference to the third aspect, in some implementations of the third aspect, the flow label field of the ciphertext IPv6 packet includes a fifth field and a sixth field. The processing unit intercepts, from the TEID field, a portion having a length equal to the length of the fifth field or the sixth field of the flow label field of the ciphertext IPv6 packet, and obtains the fifth or sixth field of the flow label field of the ciphertext IPv6 packet. fill in; or performing hash calculation on the TEID field and the second parameter to obtain an eighth hash value, having a length equal to a length of a fifth field or a sixth field of the flow label field of the ciphertext IPv6 packet, from the eighth hash value. and intercepting the part to fill in a fifth field or a sixth field of a flow label field of the ciphertext IPv6 packet.

With reference to the third aspect, in some implementations of the third aspect, when the plaintext IPv4 packet is fragmented into a plurality of chips, the processing unit: fragments the plaintext IPv4 packet into a plurality of chips; encrypt each of the plurality of chips to obtain a cipher text packet of each chip; fill the flow label field of each chip's ciphertext packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet; obtain a ninth hash value by performing hash calculation based on the flow label field of the ciphertext packet and the second parameter; and determine a transmission path of each ciphertext chip based on the ninth hash value.

With reference to the third aspect, in some implementations of the third aspect, the processing unit fills N bits of the TEID field into N bits of the flow label field of each chip's cipher text packet - or flow label field contains N bits -; or performing hash calculation on the TEID field and the second parameter to obtain a tenth hash value, and filling N bits of the tenth hash value into N bits of a flow label field of each chip's cipher text packet; , the flow label field of each chip's cipher text packet contains N bits.

With reference to the third aspect, in some implementations of the third aspect, the flow label field of each chip's ciphertext packet includes a seventh field and an eighth field. The processing unit intercepts, from the TEID field, a portion having a length equal to the length of the seventh field or the eighth field of the flow label field of the ciphertext packet of each chip, and the first part of the flow label field of the ciphertext packet of each chip fill in field 7 or field 8; or performing hash calculation on the TEID field and the second parameter to obtain a ninth hash value, and from the ninth hash value, a length equal to the length of the seventh field or the eighth field of the flow label field of the ciphertext packet of each chip It is further configured to intercept a portion having a length and fill a seventh field or an eighth field of a flow label field of the cipher text packet of each chip.

With reference to the third aspect, in some implementations of the third aspect, the second parameter includes at least one of the following parameters: SIP of the plaintext packet, DIP of the plaintext packet, next header of the plaintext packet, The source port SPt, and the destination port DPt of the plaintext packet.

With reference to the third aspect, in some implementations of the third aspect, the second parameter includes at least one of the following parameters: a SIP of the ciphertext packet, a DIP of the ciphertext packet, and a next header of the ciphertext packet.

According to a fourth aspect, a secure gateway device is provided. The security gateway device includes a transceiver unit configured to receive a plaintext packet transmitted by a core network device; and a processing unit configured to fill a Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet, wherein the ciphertext IPv6 packet is a packet obtained by encrypting the plaintext packet. . The processing unit obtains a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the filled flow label field of the ciphertext IPv6 packet; and determine a transmission path of the ciphertext IPv6 packet based on the first hash value.

With reference to the fourth aspect, in some implementations of the fourth aspect, the plaintext packet is an IPv6 packet or an IPv4 packet. The processing unit fills N bits of the TEID field into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet contains N bits; or perform hash calculation on the TEID field and the first parameter to obtain a second hash value, and fill N bits of the second hash value into N bits of a flow label field of the ciphertext IPv6 packet; The flow label field contains N bits.

With reference to the fourth aspect, in some implementations of the fourth aspect, the plaintext packet is an IPv6 packet or an IPv4 packet, and a flow label field of the ciphertext IPv6 packet includes a first field and a second field. The processing unit intercepts, from the TEID field, a portion having a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet, and obtains the first field or the second field of the flow label field of the ciphertext IPv6 packet. fill in; or performing hash calculation on the TEID field and the first parameter to obtain a third hash value, having a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet, from the third hash value. and to intercept the part and fill in the first field or the second field of the flow label field of the ciphertext IPv6 packet.

With reference to the fourth aspect, in some implementations of the fourth aspect, the plaintext packet is an IPv6 packet, and the processing unit performs a flow label (Flow Label) of the plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet. Label) field; and copy the filled-in Flow Label field of the plaintext IPv6 packet to the Flow Label field of the ciphertext IPv6 packet.

With reference to the fourth aspect, in some implementations of the fourth aspect, the plaintext packet is an IPv6 packet. If the plaintext packet is fragmented into multiple chips, the processing unit fills in a Flow Label field of the plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet; fragment the plaintext IPv6 packet filled with the flow label field into a plurality of chips, each of the plurality of chips including the filled flow label field; copy the flow label field of each chip to the flow label field of each chip's encrypted cipher text packet; obtain a fourth hash value by performing hash calculation based on the first parameter and the flow label field of the ciphertext packet; and determine a transmission path of each cipher text packet based on the fourth hash value.

With reference to the fourth aspect, in some implementations of the fourth aspect, the processing unit fills N bits of the TEID field into N bits of the flow label field of the plaintext IPv6 packet - the flow label field of the plaintext IPv6 packet is N bits contains -; or performing hash calculation on the TEID field and the second parameter to obtain a fifth hash value, and filling N bits of the fifth hash value into N bits of a flow label field of the plaintext IPv6 packet; The flow label field contains N bits.

With reference to the fourth aspect, in some implementations of the fourth aspect, the flow label field of the plaintext IPv6 packet includes a first field and a second field. The processing unit intercepts, from the TEID field, a portion having a length equal to the length of the first field or the second field of the flow label field of the plaintext IPv6 packet, and obtains the first field or the second field of the flow label field of the plaintext IPv6 packet. fill in; or performing hash calculation on the TEID field and the second parameter to obtain a sixth hash value, having a length equal to the length of the first field or the second field of the flow label field of the plaintext IPv6 packet, from the sixth hash value. intercepting part, and filling in the first field or the second field of the flow label field of the plaintext IPv6 packet.

With reference to the fourth aspect, in some implementations of the fourth aspect, the plaintext packet is an IPv4 packet or an IPv6 packet. When the plaintext packet is fragmented into a plurality of chips, the processing unit fragments the plaintext packet into a plurality of chips; encrypt each of the plurality of chips to obtain a cipher text packet of each chip; fill the flow label field of each chip's ciphertext packet based on the tunnel endpoint identifier (TEID) field of the plaintext packet; obtain a seventh hash value by performing hash calculation based on the first parameter and the flow label field of the ciphertext packet; and determine a transmission path of each cipher text packet based on the seventh hash value.

With reference to the fourth aspect, in some implementations of the fourth aspect, the processing unit fills N bits of the TEID field into N bits of the flow label field of each chip's cipher text packet - or flow label field contains N bits -; or performing hash calculation on the TEID field and the first parameter to obtain an eighth hash value, and filling N bits of the eighth hash value into N bits of a flow label field of each chip's ciphertext packet; , the flow label field of each chip's cipher text packet contains N bits.

With reference to the fourth aspect, in some implementations of the fourth aspect, the flow label field of each chip's ciphertext packet includes a first field and a second field. The processing unit intercepts, from the TEID field, a portion having a length equal to the length of the first field or the second field of the flow label field of the cipher text packet of each chip, and the second field of the flow label field of the cipher text packet of each chip fill in field 1 or field 2; or performing hash calculation on the TEID field and the first parameter to obtain a ninth hash value, and from the ninth hash value, a length equal to the length of the first field or the second field of the flow label field of the ciphertext packet of each chip and intercepting a portion having a length to fill a first field or a second field of a flow label field of the cipher text packet of each chip.

With reference to the fourth aspect, in some implementations of the fourth aspect, the first parameter includes at least one of the following parameters: a SIP of the ciphertext packet, a DIP of the ciphertext packet, and a next header of the ciphertext packet.

With reference to the fourth aspect, in some implementations of the fourth aspect, the second parameter includes at least one of the following parameters: SIP of the plaintext packet, DIP of the plaintext packet, source port SPt of the plaintext packet, plaintext packet The destination port of DPt, and the next header of the plaintext packet.

According to a fifth aspect, a communication device is provided. A communication device includes a processor. The processor is connected to a memory, and the memory is configured to store a computer program. The processor is configured to execute the computer program stored in the memory, such that the apparatus performs the method in the first aspect or any of the possible implementations of the first aspect, or the method in the second aspect or any of the possible implementations of the second aspect. do the way

According to a sixth aspect, a computer readable storage medium is provided. A computer readable storage medium stores a computer program. When executed, the computer program is used to perform a method in the first aspect or any of the possible implementations of the first aspect, or a method in any of the second aspect or possible implementations of the second aspect.

According to a seventh aspect, a chip is provided. A chip includes a processor and an interface. The processor is configured to read instructions for performing a method in any of the first aspect or possible implementations of the first aspect, or a method in any of the second aspect or possible implementations of the second aspect.

Optionally, the chip may further include memory. Memory stores instructions. The processor is configured to execute instructions stored in memory or instructions from other modules.

According to an eighth aspect, a communication system is provided. Such a system comprises an apparatus having functions for implementing the methods and possible designs in the first aspect, and an apparatus having functions for implementing the methods and possible designs in the second aspect.

1 is a schematic diagram of an application scenario according to an embodiment of the present application.
2 is a schematic diagram of end-to-end load balancing behavior according to an embodiment of the present application.
3 is a schematic flow diagram of forwarding data packets of the same session on the same path to avoid changing the order of the packets according to an embodiment of the present application.
4 is a schematic flowchart of a wireless network communication method based on Internet protocol version IPv6 according to an embodiment of the present application.
Fig. 5 is a schematic diagram of the basic format of an IPv6 packet.
6A is a schematic diagram of a first chip obtained by fragmenting an IPv6 packet according to an embodiment of the present application;
6B is a schematic diagram of a second chip obtained by fragmenting an IPv6 packet according to an embodiment of the present application.
7 is a schematic flowchart of another Internet protocol version IPv6-based wireless network communication method according to an embodiment of the present application.
Figure 8a shows the filling scheme in IPsec AH encapsulation scenario.
Figure 8b shows the filling scheme in IPsec ESP encapsulation scenario.
Fig. 9 is a schematic diagram of the basic format of an IPv4 packet.
10 is a schematic diagram of a plaintext scenario using Ethernet link aggregation technology for load balancing according to an embodiment of the present application.
11 is a schematic diagram of a cryptogram scenario using Ethernet link aggregation technology for load balancing according to an embodiment of the present application.
12 is a schematic diagram of equal-cost route load balancing in a plaintext scenario according to an embodiment of the present application.
13 is a schematic diagram of equivalent route load balancing in a plaintext scenario for reliability improvement according to an embodiment of the present application.
14 is a schematic block diagram of a communication device according to an embodiment of the present application.
15 is a schematic diagram of the structure of an access network device according to the present application.

The following describes the technical solutions of the present application with reference to the accompanying drawings.

The technical solutions of the embodiments of the present application are a global system for mobile communications (GSM), a code division multiple access (CDMA) system, and a wideband code division multiple access (wideband code division multiple access). access, WCDMA) system, general packet radio service (GPRS) system, long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (time division duplex) division duplex (TDD) system, universal mobile telecommunications system (UMTS), worldwide interoperability for microwave access (WiMAX) communication system, and 5th generation (5G) systems Alternatively, it may be used in various communication systems such as a new radio (NR) system. Also, the communication system may be further utilized in a later evolved system, for example, a 6th generation (6G) communication system or even a more advanced 7th generation (7G) communication system.

An access network device in embodiments of the present application may be a device for communicating with a terminal device, may be a base station, an access point, or a network device, or may be a wireless terminal via an air interface in an access network via one or more sectors. It can be a device that communicates with. A network device may be configured to interconvert received over-the-air frames and IP packets and act as a router between a wireless terminal and the rest of an access network, where The remainder may include Internet Protocol (IP) networks. The network device may further coordinate attribute management of the air interface. For example, the access network device may be a Base Transceiver Station (BTS) in a Global System for Mobile communications (GSM) system or a Code Division Multiple Access (CDMA) system. or may be a base station (NodeB, NB) in a Wideband Code Division Multiple Access (WCDMA) system, or may be an evolved NodeB (eNB, or eNodeB) in an LTE system, or a radio controller in a cloud radio access network (CRAN) scenario. Alternatively, the access device may be a network device in a relay station, an access point, a vehicle-mounted device, a wearable device, an access device in a 5G network, a network device in a future evolved PLMN network, etc., or an access point in a WLAN ( It may be an access point (AP), or it may be a gNB in a new radio (NR) system. This is not limited in the embodiments of this application. It should be noted that in a 5G system, one or more transmission reception points (TRPs) may exist on one base station. All TRPs belong to the same cell, and the measurement reporting method described in the embodiments of the present application may be used for each of the TRPs and the UE. In another scenario, network devices may be further divided into Control Units (CUs) and Data Units (DUs). A plurality of DUs may exist under one CU. The measurement reporting method described in the embodiments of the present application may be used for each DU and UE. The difference between the CU-DU separation scenario and the multi-TRP scenario is that the TRP serves only as a radio unit or antenna device, but the DU can implement protocol stack functions, e.g. the DU can implement physical layer functions. The point is that it can.

Also, in embodiments of the present application, an access network device is a device within a radio access network (RAN), or in other words, a RAN node connecting a terminal device to a radio network. For example, by way of example and not limitation, an access network device may include a gNB, a transmission reception point (TRP), an evolved NodeB (eNB), a radio network controller (RNC), a NodeB (NodeB, NB), base station controller (BSC), base transceiver station (BTS), home base station (eg, home evolved NodeB, or home NodeB, HNB), baseband unit ( It may be a base band unit (BBU), wireless fidelity (Wi-Fi) access point (AP), and the like.

An access network device provides services to a cell. The terminal device communicates with the access network device using transmission resources (eg frequency domain resources, or in other words, spectral resources) used by the cell. A cell may be a cell corresponding to an access network device (eg, a base station), a cell may belong to a macro base station, or may belong to a base station corresponding to a small cell. A small cell in the present specification may include a metro cell, a micro cell, a pico cell, a femto cell, and the like. These small cells have characteristics of small coverage and low transmission power, and are applicable to providing high-speed data transmission service.

In embodiments of the present application, a core network device may be connected to an access network device, such that a terminal device may communicate with the core network device via the access network device. For example, a core network device may include the following network elements or functions:

Access management function (AMF) is access and mobility, including registration management (RM) and connection management (CM), access authentication and access authorization, reachability management, mobility management, etc. mainly responsible for control.

The user plane function (UPF) is mainly an access point between the PDU session and the data network, data packet routing and forwarding, data packet detection and user plane policy enforcement, QoS processing for the user plane, and downlink data packet buffering. , downlink data notification triggering, etc. to provide user plane support.

The packet control function (PCF) primarily provides policy control functionality, including supporting unified policy frameworks to govern network behavior and providing policy rules to the control planes to enforce them.

The authentication server function (AUSF) is mainly responsible for providing security-related functions such as authentication and authorization.

Unified data management (UDM) is responsible for functions related to user authentication and authorization, including authentication credential processing, user identification processing, subscription information management, access authorization, and the like.

Session: A session is the basic unit of service. A service can contain one or more sessions. It is important to note that while strict order preservation is required for packets in one session, it is not required for packets in different sessions. The communication term "flow" may be equivalent to the communication term "session" in embodiments of the present application. Both flow and session mentioned in the embodiments of this application are unidirectional. In this specification, a session can be understood as a set of all packets having the same “hash values” of 3-tuples.

Bearer: A Public Data Network (PDN) connection is a tunnel between a UE and a PGW, and an Evolved Packet System (EPS) bearer is a smaller tunnel included in a PDN connection. A PDN connection is for IP connectivity. In the same PDN connection, different EPS bearers represent different quality of service. While the PDN connection is being set up, one EPS bearer is being set up, which is referred to as the default bearer. In the same PDN connection, the subsequently set up EPS bearer is referred to as a dedicated bearer. Data packets in the same direction of the bearer have the same TEID value (in the GTP header). If there is only a default bearer, one UE can simply be considered as corresponding to one bearer. The concept of a bearer is not used in 5G, but a "PDU session" is used instead. In embodiments of the present application, a 4G bearer or 5G PDU session may be used. The term bearer is used below for explanation.

Hash Algorithm: A mapping rule for mapping a binary string of arbitrary length to a binary string of fixed length is referred to as a hash algorithm, and a binary value obtained through original data mapping is referred to as a hash value. The hash algorithm has the following characteristics:

1. Since it is one-way and difficult to infer the original data in reverse, the original data cannot be inferred backward from the hash value.

2. It is sensitive to input data and has an avalanche effect. Even if only one bit is modified, the obtained hash values are the same.

3. Has a low probability of hash collisions. If the hash keys are different, the probability that the calculated hash values are the same is low.

1 is a schematic diagram of an application scenario 100 according to an embodiment of the present application. In FIG. 1 , an access network device 110 and a core network device 120 are included. The access network device 110 may be used, for example, in an evolved universal mobile telecommunications system, an evolved UMTS terrestrial radio access (E-UTRA) system, or in a NR system, or in a next generation communication system or other communication system. It works. In the communication system, the access network device 110 and the core network device 120 can transmit data to each other, so the communication system is also referred to as a wireless backhaul network.

In Fig. 1, the access network device is for example a base station. An access network device corresponds to different devices in different systems. For example, an access network device may correspond to an eNB in a 4G system and may correspond to a 5G access network device such as a gNB in a 5G system. The technical solutions provided in the embodiments of the present application may also be applied to future mobile communication systems. Thus, the access network device of FIG. 1 may correspond to an access network device in a future mobile communication system. In Fig. 1, an example is used where the access network device is a base station. In practice, reference is made to the above description for access network devices.

It should be understood that the communication system shown in FIG. 1 may further include more network nodes, for example devices such as terminal devices, other access network devices, security gateways, and switches. The access network device or core network device included in the communication system shown in FIG. 1 may be the aforementioned various types of access network devices or core network devices. Details are not shown one by one in the drawings in this embodiment of the present application.

The technical solutions in this application can also be applied to other communication systems. The communication system shown in FIG. 1 is not limiting for this application.

As data packets are transmitted in network nodes, the bandwidth can increase exponentially, and according to the Institute of Electrical and Electronics Engineers (IEEE) 802.3ad (IEEE 802.3ad is a standard method for performing link aggregation ) Higher reliability of data transmission can be achieved using a combination of Ethernet link aggregation technology and equivalent route load balancing technology. When multiple transmission paths exist in a network node, the multiple data packets of a node need to be evenly distributed over the paths to maximize bandwidth utilization. Also, data packets of the same session need to be delivered on the same path to ensure that data packets of the same session or flow do not change order. In a multi-path scenario, if data packets of a session are evenly distributed on multiple paths for delivery, out-of-order may occur, which may impair normal functions and performance of the session. Therefore, order preservation is required for data packets of the same session in the telecommunications industry.

2 shows end-to-end load balancing behavior. There are two paths for delivery at forwarding node R1. The first session is represented by black blocks and the second session by white blocks. Data packets of the first session arrive at forwarding node R5 through forwarding nodes R2 and R3, and data packets of the second session reach forwarding node R5 through forwarding node R4. Data packets of the same session are delivered on the same path to ensure that data packets of the same session do not change order. The forwarding nodes of FIG. 2 may be forwarding nodes between the access network device and the core network device shown in FIG. 1 . For example, a data link between an access network device and a core network device includes forwarding nodes R1, R2, R3, R4, and R5.

In the following, with reference to FIG. 3, the reason why data packets of the same session are transferred on the same path to ensure that the data packets of the same session do not change order is further explained. Figure 3 is a schematic flow diagram of forwarding data packets of the same session on the same path to ensure that data packets of the same session do not change order. Numbers in FIG. 3 represent sequence numbers of data packets in respective sessions. Figure 3 shows three sessions: a first session, a second session and a third session. Using the first session as an example, the sequence of data packets of the first session before delivery is 1, 2, and 3, and the sequence of data packets of the first session after delivery is still 1, 2, and 3 without disorder. Conversely, if data packets of the same session are delivered through different paths, the data packets may be out of order, for example, the order of data packets is 3, 1, and 2, which affects service performance.

In the era of IPv4, 5-tuples (e.g. Source IP, SIP), Destination IP Address (Destination IP, DIP), Transport Layer Protocol (Protocol, Prot), Source Port (SPt), and Destination Port (DPt)) is generally used to determine whether data packets belong to the same session. Specifically, hash calculation is performed on 5-tuples of IPv4 packets, and if hash calculation results of two data packets match, the two data packets belong to the same session. The process of calculating different hash values may also be referred to as hashing. More different hash values indicate that hashing is more appropriate. From a statistical point of view, it is easier to distribute data packets evenly over multiple paths for full bandwidth utilization.

The network node performs calculations on all data packets to obtain the 5-tuple hash values of the data packets. Each hash value uniquely represents a session. To ensure order preservation of data packets of the same session during forwarding, packets with the same hash value can be forwarded on the same route, and packets with different hash values can be forwarded on multiple routes.

Referring to FIG. 3 and Table 1, the relationship between 5-tuples, hash values, and sessions, and load balancing behavior are further described. A first session, a second session, and a third session can be seen intuitively from FIG. 3 . The table below shows hash values obtained by performing hash calculation based on the 5-tuple of each session. Each part of the 5-tuple is a hash key. Five hash keys are used to obtain a hash value using a hash algorithm. One or more different fields in the 5-tuple may result in different hash values. The hash value uniquely identifies a session. Data packets of the same session may be carried on one path, and data packets of different sessions may be carried on different paths. This ensures that the order of data packets in any session is preserved for both the source and destination nodes.

Table 1 hash values calculated based on 5-tuple

For a load balancing algorithm for forwarding IPv6 data packets over multiple routes, the IETF-RFC 6437 specification (i.e., The Internet Engineering Task Force (IETF) Request For Comments (RFC), where: According to the RFC released by the Internet Engineering Task Force (IETF), packet distribution may be performed based on a 3-tuple (e.g., may contain SIP, DIP, and flow label Flow_Label) hash . However, the IPv6 Flow_Label field is used openly in industry and has no common use, and there is no mandatory requirement for the IPv6 Flow_Label field in the standard. Currently, the solution is to set all 20 bits of Flow_Label to zero. Therefore, if packet distribution is performed based on the 3-tuple (including SIP, DIP, and flow label Flow_Label) hash, the transmission paths of many data packets are determined to be the same. This is a huge waste of bandwidth.

In current technology, packet distribution is performed for IPv6 packets based on a 5-tuple (SIP, DIP, Next Header, SPt, and Dpt) hash, i.e., multiple IPv6 packets are delivered on different paths. Even if the 5-tuple hash is used for distribution of IPv6 packets, load balancing cannot be fully implemented in the following scenarios.

For example, in a typical IPv6-based scenario involving one Public Data Network Gateway (PGW)/User Plane Function (UPF) plus one local service, the PGW/UPF is an IPv6 address. configured, and the base station is configured with an IPv6 address. Therefore, as shown in Table 2, the contents of the 3-tuples or 5-tuples of all data packets are the same, and the hash values calculated based on the 3-tuples or 5-tuples of all the data packets are the same . As a result, data packets cannot be hashed and are all forwarded on the same path, resulting in load balancing failure and wasting bandwidth on idle paths.

Table 2 Exactly the same hash values of data packets of different users

In another example, in an IPv6-based scenario that includes multiple local services in addition to multiple public data gateways (PGWs)/user plane functions (UPFs), the PGWs/UPFs have two IPv6 addresses, namely IPv6_1 and It consists of IPv6_2. The base station is also configured with two IPv6 addresses, IPv6_1 and IPv6_2. Hash values of 3-tuples or 5-tuples of all data packets can be distinguished in a limited way as shown in Table 3. However, the amount of IPv6 addresses configured for a PGW/UPF/base station is limited, so data packets cannot be fully hashed. As a result, traffic cannot be evenly distributed over multiple paths, and load balancing performance is inadequate. The base station IPv6_1 shown in Table 3 is a plain text IPv6 address.

Table 3 Only two hash values calculated for data packets of different users

In another example, in an IPv6 Internet Protocol Security (IPsec) scenario, a pair of Internet Key Exchange (IKE) IPv6 addresses (i.e., the ciphertext IPv6 addresses described herein) are used. . The values of SIPs and DIPs of encrypted data packets of different users are all the same. Thus, as shown in Table 4, the hash values of the ciphertexts of all users' encrypted data packets are the same (there is no SPt or DPt field in IPsec packets regardless of whether they use ESP encapsulation or AH encapsulation). As a result, data packets cannot be hashed, resulting in load balancing failure. The local tunnel IP addresses in Table 4 are ciphertext IPv6 addresses.

Table 4 Exactly identical hash values of encrypted data packets of different users

In another example, a path maximum transmission unit (PMTU) mechanism is introduced in IPv6, such that fragmentation in IPv6 is uncontrollable compared to that in IPv4. In the scenario of IPv6 source packet fragmentation, after the source packet is fragmented, the first chip retains the complete header information of the source packet, and subsequent chips have only IPv6 headers but User Datagram Protocol (UDP) headers don't have If a 5-tuple hash is used, the hash value of the first chip is different from the hash values of subsequent chips, and different fragmented packets are delivered on different paths, resulting in disorder of the packets in the same session. As shown in Table 5, after the user's data packet is fragmented, the second chip loses UDP header information. Therefore, the hash value of the second chip is different from the hash value of the first chip. As a result, fragmented packets may be forwarded on two paths and reach the aggregation node out of order, i.e., the second chip arrives at the destination before the first chip, affecting performance.

Table 5 Different Hash Values of Users' Fragmented Data Packets

Now, in current technology, multiple SIPs or DIPs can be deployed only at the source or destination end of the backhaul network for hashing. Details are as follows. In a plaintext scenario, it is recommended that multi-service IPv6 be configured at the local end to make a difference in SIPs/DIPs resulting in a difference in hash values. Also, there are requirements on the amount of SIPs/DIPs.

As shown in Table 3, in the system shown in Table 3, two addresses are placed on the access network device and two addresses are placed on the core network device. Thus, hash values of data packets of different users are different, and load balancing may succeed, but may also fail. In the implementation of the mapping between the hash value and the selected path, after the hash value is obtained through multi-tuple hashing, a modulo computation is performed for the path mapping. For example, in dual-path load balancing, a modulo 2 calculation is performed. That is, divide the hash value by 2 to get the remainder. If the result is 0, PATH1 is selected, and if the result is 1, PATH2 is selected. In 3-path load balancing, a modulo 3 calculation is performed. That is, divide the hash value by 3 to get the remainder. If the result is 0, PATH1 is selected, if the result is 1, PATH2 is selected, and if the result is 2, PATH3 is selected. Other cases are inferred by analogy. It needs to be ensured that results obtained through hash and modulo calculation using a plurality of SIPs/DIPs are different. Otherwise, load balancing cannot be implemented. Therefore, proper consideration and pre-computation are required for SIP/DIP schemes to avoid load balancing failures because results obtained by performing modulo computation on hash values obtained through multi-tuple hash computation are unique. As shown in Table 6, two IPv6 addresses are deployed on the base station. However, due to improper address selection, even if hash values of data packets of different users are different, results obtained through modulo calculation are the same, resulting in load balancing failure.

Table 6 Failed Load Balancing in the Scenario of Deploying Two IPv6 Addresses on a Base Station

As shown in Table 7, two IPv6 addresses are deployed on the base station. Selected addresses are precomputed. Hash values of data packets of different users are different, and results obtained through modulo operation are also different. Thus, load balancing succeeds.

Table 7 Successful load balancing in the scenario of deploying two IPv6 addresses on a base station

Similarly, in current technology, in an IPv6 Internet Protocol security (IPsec) scenario, multiple IPv6 addresses of a secure gateway or multiple IPv6 addresses of a local end (multiple IPv6 addresses of a secure gateway and multiple IPv6 addresses of a local end) Addresses (both refer to outer tunnel ciphertext IPv6 addresses) are configured to make a difference in SIPs/DIPs resulting in a difference in hash values. Also, there are requirements on the amount of SIPs/DIPs.

In this technique, additional IPv6 addresses need to be deployed for users, and the non-uniqueness to the module obtained through multi-tuple hash calculation needs to be fully guaranteed. This can hamper networking design, evolved solutions, and address planning, increase cost, impair product competitiveness, and cause serious hash inadequacies. For example, if two SIPs are configured on a base station, only two hash values can be hashed using a hash algorithm, and load balancing is performed for the two corresponding paths. This can cause severe imbalance in load balancing (which means one path has an extremely large amount of traffic and another path has an extremely small amount of traffic). As a result, bandwidth resources cannot be fully utilized, load balancing is compromised, and reliability is dependent on the detection mechanism of the transport layer (ie, layer 4 protocol). The control plane detects links according to the SCTP heartbreak mechanism. If the link is faulty, convergence takes 45 to 50 seconds, where 45 to 50 are typical values and can be changed through configuration. The data plane detects links according to the GTP-U echo mechanism. If the link is faulty, convergence takes 15 to 75 seconds, where 15 to 75 are typical values and can be changed through configuration. When path switching occurs from a path fault, services are interrupted for a long time, affecting service experience and deteriorating reliability.

Considering this, the present application provides a wireless network communication method based on Internet Protocol version IPv6, which implements hashing per bearer without adding SIP/DIP, in order to fully utilize bandwidth resources.

A wireless network communication method based on Internet protocol version IPv6 provided in the present application will be described in detail below with reference to FIG. 4 . 4 is a schematic flowchart of a wireless network communication method 200 based on Internet Protocol Version IPv6 according to an embodiment of the present application. Method 200 may be applied to the scenario shown in FIG. 1, or may of course be applied to other communication scenarios. This is not limited to this embodiment of the present application.

It should also be understood that in this embodiment of the present application, this method is described using an example performed by an access network device and a core network device. By way of example and not limitation, the method may alternatively be performed by chips, chip systems, processors, etc. used in the access network device and the core network device.

As shown in FIG. 4 , the method 200 shown in FIG. 4 may include S210 and S220. The steps of method 200 are described in detail below with reference to FIG. 4 .

S210. The transmission path of the plaintext IPv6 packet is determined based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet.

S220. The plaintext IPv6 packet is transmitted on the determined transmission path of the plaintext IPv6 packet.

The transmission path of the plaintext IPv6 packet is determined based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet. The Tunnel Endpoint Identifier (TEID) field is the identifier of the GTP tunnel, and the TEID field of each bearer (which is a PDU session in 5G and described as a bearer below without emphasis) is different. Therefore, the transmission path of the plaintext IPv6 packet is determined based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, so that IPv6 packets of the same bearer can be transmitted on the same route, and IPv6 packets of different bearers perform load balancing. guaranteed to be completely hashable for

In this embodiment of the present application, the plaintext IPv6 packet is a data service IPv6 packet, and the plaintext IPv4 packet is a data service IPv4 packet. Plaintext packets are only used to differentiate ciphertext packets in encryption scenarios. The ciphertext IPv6 packet is a data service IPv6 packet obtained by encrypting a plaintext IPv6 packet or a plaintext IPv4 packet.

For a clearer understanding of the present application, step S210 is described in detail below.

The basic format of IPv6 packets is explained first. 5 shows the basic format of an IPv6 packet. An IPv6 packet contains an IPv6 header and payload. The IPv6 header contains:

IP Version (4 bits) where the value of this field is 6;

Traffic Class (8 bits);

Flow Label (20 bits) used to identify information about bearers of IPv6 data packets;

Payload Length (16 bits) where an extension header is also included in the payload length;

Next Header (8 bits), a new method for segmentation, security, mobility, loose source routing, and route recording;

Hop Limit (8 bits) defining the maximum number of hops an IP packet can traverse - and this value is decremented by 1 for each hop;

Source Address (128 bits);

Destination Address (128 bits); and

Extension Header(s) of data packets.

The flow label field of the IPv6 header of the IPv6 packet shown in FIG. 5 is 0, and the 3-tuple hash values are identical. Therefore, load balancing cannot be implemented using 3-tuples. In this application, a transmission path of a plaintext IPv6 packet is determined based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet. Since the tunnel endpoint identifier (TEID) fields of plaintext IPv6 packets of different bearers are different, determining the transmission path of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet is It can be ensured that it is delivered on the same path and that the packets of the bearer are sequentially delivered. Also, the hash values of different bearers are different, and the packets are completely hashed based on the different hash values, thereby implementing load balancing.

Optionally, step S210 includes filling the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet into the Flow Label field of the plaintext IPv6 packet; obtaining a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the filled flow label field; and determining a transmission path of the plaintext IPv6 packet based on the first hash value.

Therefore, the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet is filled in the Flow Label field of the plaintext IPv6 packet, and then hash calculation based on the first parameter involved in hash calculation and the filled flow label field. is performed to obtain the first hash value. Since the TEID field uniquely identifies a bearer, hash values of the same bearer are the same, and hash values of different bearers are different. The transmission path of the plaintext IPv6 packet is determined based on the first hash value to ensure that the bearer's packets are delivered on the same path and that the bearer's packets are delivered sequentially. Also, the hash values of different bearers are different, and the packets are completely hashed based on the different hash values, thereby implementing load balancing.

For example, in a dual-path scenario, as shown in Table 8, each of the base station and core network is configured with an IPv6 address, but the TEIDs of different users are different. The TEID field is used to fill the flow label field, and the value of the filled flow label field for each user is different. Different hash values are obtained by calculating a 3-tuple hash value based on each user's populated flow label fields, SIP and DIP. For example, user 1's hash value is 321, user 2's hash value is 432, user 3's hash value is 543, user 4's hash value is 654, and user 5's hash value is 765. By performing a modulo operation on a plurality of different hash values for path selection, user 1's transmission path is PATH2, user 2's transmission path is PATH1, user 3's transmission path is PATH2, and user 4's transmission path is PATH1 and user 5's transmission path is PATH2, thereby implementing load balancing.

Table 8 Load Balancing in a Dual-Path Scenario

The first parameter involved in the hash calculation is the following parameters: SIP of the plaintext IPv6 packet, DIP of the plaintext IPv6 packet, next header of the plaintext IPv6 packet, source port SPt of the plaintext IPv6 packet, and destination port DPt of the plaintext IPv6 packet. It should be understood that it may include any one or more of these.

In addition to obtaining the first hash value by performing hash calculation based on the first parameter involved in hash calculation and the filled flow label field, the first hash value is 3-tuple (SIP of plaintext IPv6 packet, SIP of plaintext IPv6 packet DIP, and a filled flow label field). Alternatively, the first hash value is a 6-tuple (SIP of the plaintext IPv6 packet, DIP of the plaintext IPv6 packet, next header of the plaintext IPv6 packet, source port SPt of the plaintext IPv6 packet, destination port DPt of the plaintext IPv6 packet, and padded flow label field). This is not limited in this application. In this embodiment of the present application, 3-tuple is used as an example for explaining a method of determining a transmission path of a plaintext packet or a ciphertext packet.

The Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet is filled in the Flow Label field of the plaintext IPv6 packet. After the plaintext IPv6 packet filled with the Flow Label field is received by the intermediate node, the intermediate node may also determine the transmission path of the plaintext IPv6 packet based on the 3-tuple. An intermediate node may also implement load balancing and implement appropriate allocation of computing resources per bearer.

The Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet is filled in the Flow Label field of the plaintext IPv6 packet. After the plaintext IPv6 packet filled with the flow label field is received by the receiver, if the receiver includes a plurality of computing processing units, the receiver performs computing processing for processing the plaintext IPv6 packet based on the 3-tuple By determining the unit, it is possible to implement proper allocation of computing resources of the receiver and avoid uneven configuration of computing units.

When the plaintext IPv6 packet needs to be fragmented into multiple chips, the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet is filled in the Flow Label field of the plaintext IPv6 packet before the plaintext IPv6 packet is fragmented. , the plaintext IPv6 packet is fragmented, then the filled Flow Label field of the plaintext IPv6 packet is copied to each chip of the plaintext IPv6 packet to ensure that the 3-tuple hash values of all fragments are the same.

Specifically, in the plaintext IPv6 packet fragmentation scenario, before the plaintext IPv6 packet is fragmented, the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet is filled in the Flow Label field of the plaintext IPv6 packet, and then the plaintext IPv6 Packets are fragmented. Hereinafter, plaintext IPv6 packet fragmentation scenarios will be described in detail with reference to FIGS. 6A, 6B, and Table 9.

6A and 6B are schematic diagrams in which a data packet is split into two fragmented packets. Table 9 shows header information of fragmented packets of data packets. In a wireless backhaul network, the next layer headers of a plaintext IPv6 packet are a User Datagram Protocol (UDP) header and a General packet radio service Tunneling Protocol (GTPv1) header, respectively. As shown in Fig. 6A, the IPv6 packet shown in Fig. 6A includes an IPv6 header, a fragment extension header, a UDP header, a GTPv1 header, and a payload. The GTPv1 header is a type of GTP header, and the GTPv1 header includes a Tunnel Endpoint Identifier (TEID) field. When the IPv6 packet is fragmented, the first chip inherits the header of the original packet, and the other chip copies only the IPv6 header. Before the IPv6 packet is fragmented, the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet is filled in the Flow Label field of the plaintext IPv6 packet, the plaintext IPv6 packet is fragmented, and then the filled flow of the plaintext IPv6 packet A label (Flow Label) field is copied to each chip obtained by fragmenting a plain text IPv6 packet. 6a shows a first chip. The first chip includes an IPv6 header, a UDP header, a GTPv1 header, and a payload. 6b shows a second chip. The second chip contains an IPv6 header and payload. 6A corresponds to the first chip of the packet in Table 9, and FIG. 6B corresponds to the second chip of the packet in Table 9. Contents of flow label fields in the IPv6 headers of the first chip and the second chip are the same. Therefore, the hash results obtained by calculating the 3-tuple hash values for the first chip and the second chip are identical, and based on the hash results, it is determined that the paths of the two packets match.

Table 9 Consistent Transmission Paths of Fragmented Packets

Hereinafter, a method of filling the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet in the flow label field of the plaintext IPv6 packet will be described in detail.

In implementations, the N bits of the TEID field are padded to the N bits of the flow label field, where the flow label field contains N bits; Alternatively, hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, N bits of the second hash value are filled in N bits of the flow label field, and the flow label field includes N bits. In summary, the Flow Label field of the plaintext IPv6 packet is filled based on the TEID field. For example, the TEID field is 32 bits and the flow label field is 20 bits. The N bits of the TEID field may be the first 20 bits or the last 20 bits of the TEID field, or the 20 bits may be selected randomly or in a specific sequence from the TEID field.

In this embodiment of the present application, the first parameter used when the hash calculation is performed based on the filled flow label field and the first parameter involved in the hash calculation to determine the transmission path of the plaintext IPv6 packet is (TEID field and a second hash value (obtained by performing a hash calculation on the first parameter) may be the same as or different from the first parameter used when the flow label field is populated.

In an implementation, a flow label field of a plaintext IPv6 packet includes a first field and a second field. A portion having the same length as the length of the first or second field of the flow label field is intercepted from the TEID field, and fills the first or second field of the flow label field. Alternatively, hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, and a portion having a length equal to the length of the first field or the second field of the flow label field is obtained from the second hash value It is intercepted and fills the first field or the second field of the flow label field.

For example, the TEID field includes 32 bits and the flow label field includes 20 bits. The flow label field is divided into a first field and a second field, the first field includes 18 bits, and the first field includes 2 bits. 18 bits may be intercepted from the TEID field and filled in the first field of the flow label field. Alternatively, a hash calculation may be performed on the TEID field and the first parameter to obtain a second hash value, and 18 bits of the second hash value are intercepted to populate the first field of the flow label field.

It should be understood that one field of the flow label field is filled in and another field is reserved. The reserved field may be used for other purposes, for example for QoS identifiers. This is not limited in this application.

It should be further understood that the amount of bits in the first field and the amount of bits in the second field may be set based on specific application scenarios. This is not limited in this application.

In implementation, the first parameter is at least one of the following parameters: the SIP of the plaintext IPv6 packet, the DIP of the plaintext IPv6 packet, the source port SPt of the plaintext IPv6 packet, the destination port DPt of the plaintext IPv6 packet, or the Next header of the plaintext IPv6 packet. contains one

To more clearly understand how to populate the Tunnel Endpoint Identifier (TEID) field of a plaintext IPv6 packet into the Flow Label field of a plaintext IPv6 packet, the following provides a description according to a specific example.

For example, the last 20 bits of the TEID field are intercepted directly to fill in the flow label field.

For example, after a hash calculation is performed on a 3-tuple (including SIP, DIP, and TEID), 20 bits are intercepted to fill the flow label field, or only 18 bits are intercepted to form the flow label Fill in the field, the first 2 bits are reserved.

For example, after a hash calculation is performed on a 4-tuple (including SIP, DIP, Next Header, and TEID), 20 bits are intercepted to fill, or only 18 bits are intercepted to fill, and the first 2 bits are reserved.

For example, after a hash calculation is performed on a 6-tuple (including SIP, DIP, next header, SPt, DPt, and TEID), 20 bits are intercepted to fill, or only 18 bits are intercepted to fill. It is filled, and the first 2 bits are reserved.

The method of implementing flow load balancing for each bearer by filling the flow label field in the IPv6 plaintext scenario has been described above. The following describes in detail how to implement flow load balancing for each bearer by filling the flow label field in the IPv6 IPsec tunnel mode ciphertext scenario.

In the wireless backhaul network, in the IPv6 IPsec tunnel mode ciphertext scenario, uplink data is encrypted by the access network device and downlink data is encrypted by the Security Gateway (SeGW). The core network device may also encrypt downlink data. However, this increases the computational load of the core network device. Therefore, downlink data is generally encrypted by the SeGW.

In the IPv6 IPsec tunnel mode ciphertext scenario, the plaintext packets (inner packets) can be IPv6 packets or IPv4 packets, and the ciphertext packets (outer packets) can be IPv6 packets.

The communication method provided in this application is described in detail below with reference to FIG. 7 . 7 is a schematic flowchart of a wireless network communication method 300 based on another Internet protocol version IPv6 according to an embodiment of the present application. Method 300 may be applied to the scenario shown in FIG. 1, or may of course be applied to other communication scenarios. This is not limited to this embodiment of the present application.

It should be further understood that in this embodiment of the present application, this method is described using an example performed by an access network device and a secure gateway. By way of example and not limitation, the method may alternatively be performed by chips, chip systems, processors, etc. used in access network devices and secure gateways.

As shown in FIG. 7 , the method 300 shown in FIG. 7 may include S310 and S330. The steps of method 300 are described in detail below with reference to FIG. 7 .

S310. Populates the Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet.

S320. A first hash value is obtained by performing hash calculation based on the first parameter involved in hash calculation and the filled flow label field.

S330. A transmission path of the ciphertext IPv6 packet is determined based on the first hash value.

The Flow Label field of the ciphertext IPv6 packet is populated based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet, where the Tunnel Endpoint Identifier (TEID) field is the identifier of the bearer, and each bearer's TEID field is different. Accordingly, the Flow Label field of the ciphertext IPv6 packet filled in based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet is associated with the bearer. Hash calculation is performed based on the first parameter involved in hash calculation and the filled flow label field to obtain a first hash value. Determining the transmission path of the ciphertext IPv6 packet based on the first hash value means that ciphertext IPv6 packets of the same bearer can be transmitted on the same route, or ciphertext IPv6 packets of different bearers can be completely hashed, thereby implementing load balancing. can guarantee that Table 10 describes load balancing of ciphertext packets obtained by filling the Flow Label field using the TEID and calculating hash values of 3-tuples in the dual-path scenario. Tunnel local IP addresses and tunnel peer IP addresses in Table 10 are ciphertext IPv6 addresses.

Table 10 Load Balancing Achieved After Packets Are Encrypted

It should be understood that the first parameter involved in the hash calculation may include any one or more of the following parameters: SIP of the ciphertext IPv6 packet, DIP of the ciphertext IPv6 packet, and Next header of the ciphertext IPv6 packet.

In addition to obtaining the first hash value by performing hash calculation based on the first parameter involved in hash calculation and the filled flow label field, the first hash value is 3-tuple (SIP of the ciphertext IPv6 packet, SIP of the ciphertext IPv6 packet DIP, and a filled flow label field). This is not limited in this application. In this embodiment of the present application, 3-tuple is used as an example for explaining a method of determining a transmission path of a plaintext packet or a ciphertext packet.

First, when the plaintext packet is an IPv6 packet, how to fill the flow label field of the ciphertext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext packet is described.

In an implementation, when the plaintext packet is an IPv6 packet, the N bits of the TEID field are filled into the N bits of the flow label field of the ciphertext IPv6 packet, where the flow label field of the ciphertext IPv6 packet contains N bits. Alternatively, a hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, and N bits of the second hash value are filled into N bits of a flow label field of the ciphertext IPv6 packet, where the ciphertext IPv6 The flow label field of a packet contains N bits.

In the implementation, when the plaintext packet is an IPv6 packet, the flow label field of the ciphertext IPv6 packet includes a first field and a second field, and has a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet. The part having is intercepted from the TEID field and fills the first field or the second field of the flow label field of the ciphertext IPv6 packet. Alternatively, hash calculation is performed on the TEID field and the first parameter to obtain a third hash value, and a portion having a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet is 3 is intercepted from the hash value and fills the first field or the second field of the flow label field of the ciphertext IPv6 packet.

In an implementation, the plaintext packet is an IPv6 packet. The Flow Label field of the plaintext IPv6 packet is populated based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, and the populated Flow Label field of the plaintext IPv6 packet is the flow label of the ciphertext IPv6 packet ( Flow Label) field.

8a illustrates a filling scheme in an IPsec Authentication Header (AH) encapsulation scenario. The TEID field is filled in the flow label field by the IPv6 header (inner IPv6) of the plaintext packet, and when the IPv6 header (outer IPv6) of the ciphertext packet is encapsulated after the plaintext packet is encrypted, the flow label field of the plaintext packet is Filled in the flow label field of the IPv6 header of The flow label fields of ciphertext packets of different bearer services are different, so the hash value can be hashed based on the bearer.

8b illustrates a filling scheme in an IPsec Encapsulating Security Payload (ESP) encapsulation scenario. Refer to one filling scheme in the above IPsec AH encapsulation scenario. Details are not described herein again.

In an implementation, the plaintext packet is an IPv6 packet. The Flow Label field of the plaintext IPv6 packet is populated based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, and the Flow Label field of the ciphertext IPv6 packet is the populated flow label ( Flow Label) field. It should be understood that for a specific method for filling the Flow Label field of a plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, reference is made to the method described in Method 200 above. . Details are not described herein again.

In an implementation, the filling of the Flow Label field of the ciphertext IPv6 packet based on the filled Flow Label field of the plaintext IPv6 packet is based on the Flow Label field of the plaintext IPv6 packet and the first parameter performing hash calculation on to obtain a fourth hash value; and filling a flow label field of the ciphertext IPv6 packet based on the fourth hash value.

In an implementation, the flow label field of the ciphertext packet includes a third field and a fourth field. Filling the flow label field of the ciphertext IPv6 packet based on the fourth hash value includes filling N bits of the fourth hash value into N bits of the flow label field of the ciphertext IPv6 packet, the flow label field including N bits. -; or intercepting a portion having a length equal to the length of the third or fourth field of the flow label field of the ciphertext IPv6 packet from the fourth hash value, and obtaining the third or fourth field of the flow label field of the ciphertext IPv6 packet. Including the filling step.

In an implementation, the plaintext packet is an IPv6 packet. When the plaintext packet is fragmented into multiple chips, the Flow Label field of the plaintext IPv6 packet is filled based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet; The plaintext IPv6 packet filled with the flow label field is fragmented into a plurality of chips, each of the plurality of chips including a filled flow label field; The flow label field of each chip is copied to the flow label field of each chip's encrypted cipher text packet.

In an implementation, the plaintext packet is an IPv6 packet. If the plaintext packet is fragmented into a plurality of chips, the method includes fragmenting the plaintext packet into a plurality of chips; encrypting each of a plurality of chips to obtain a cipher text packet of each chip; filling the flow label field of each chip's ciphertext packet based on the tunnel endpoint identifier (TEID) field of the plaintext packet; obtaining a fifth hash value by performing hash calculation based on a second parameter involved in hash calculation and the flow label field of the ciphertext packet; and determining a transmission path of the ciphertext packet based on the fifth hash value.

In an implementation, populating a flow label field of each chip's ciphertext packet based on a tunnel endpoint identifier (TEID) field of the plaintext packet comprises: replacing N bits of the TEID field with N bits of the flow label field of each chip's ciphertext packet. filling in bits, the flow label field of each chip's cipher text packet contains N bits; or performing hash calculation on the TEID field and the first parameter to obtain a sixth hash value, and filling N bits of the sixth hash value into N bits of the flow label field of each chip's cipher text packet - each chip The flow label field of the ciphertext packet of contains N bits.

In the implementation, the flow label field of each chip's ciphertext packet includes a fifth field and a sixth field, and the flow label field of each chip's ciphertext packet is determined based on the tunnel endpoint identifier (TEID) field of the plaintext packet. The filling step intercepts, from the TEID field, a portion having a length equal to the length of the fifth field or the sixth field of the flow label field of the ciphertext packet of each chip, and filling in the 5th field or the 6th field; or obtaining a seventh hash value by performing hash calculation on the TEID field and the first parameter; and intercepting, from the ninth hash value, a portion having the same length as the length of the fifth or sixth field of the flow label field of the ciphertext packet of each chip, and filling in the field or the sixth field.

In an implementation, the first parameter includes at least one of the following parameters: the SIP of the ciphertext packet, the DIP of the ciphertext packet, and the next header of the ciphertext packet.

In an implementation, the second parameter includes at least one of the following parameters: the SIP of the plaintext packet, the DIP of the plaintext packet, the source port SPt of the plaintext packet, the destination port DPt of the plaintext packet, and the next header of the plaintext packet.

To more clearly understand how to populate the Tunnel Endpoint Identifier (TEID) field of a plaintext IPv6 packet into the Flow Label field of a ciphertext IPv6 packet, the following provides an explanation according to a specific example.

For example, the flow label field in the inner IPv6 header of the plaintext packet is directly copied to fill the flow label field of the ciphertext IPv6 packet.

For example, after a hash calculation is performed on a 3-tuple (including Out_SIP, Out_DIP, and Inner_FL), 20 bits are intercepted for padding, or only 18 bits are intercepted for padding, and the first 2 bits are are reserved

For example, after a hash calculation is performed on a 4-tuple (including Out_SIP, Out_DIP, Out_Next_Header, and Inner_FL), 20 bits are intercepted for padding, or only 18 bits are intercepted for padding, and the first 2 Bits are reserved.

In the above examples, Out and Inner represent the IPv6 header of the outer ciphertext and the IPv6 header of the inner plaintext in IPsec tunnel mode.

Hereinafter, when the plaintext packet is an IPv4 packet, a method of determining a transmission path of a ciphertext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext packet will be described.

The basic format of IPv4 packets is explained first. 9 shows the basic format of an IPv4 packet. An IPv4 packet contains an IPv4 header and payload. The IPv4 header contains:

IP version where the value of this field is 4 (4 bits);

Header Length (HL), 4 bits;

a Type of Service (TOS) that distinguishes priorities for data packets waiting to pass through a transmitting device;

Total Length (TL) - this is a 16-bit field indicating the length of the IP datagram in bytes, including the IP header and data payload;

Identification is a 16-bit field, and the 16-bit field is the value assigned to the message transmitted by the source IP with increasing sequence. When a message sent to the IP layer is too large to fit into one datagram, the IP layer splits the message into multiple datagrams, sorts the datagrams, and assigns the same identifier to the datagrams. The receiver reassembles the message into the original message based on these values;

Flags - where the length of this field is 3 bits, the first bit is not used and the second bit is the "don't fragment" bit, where this bit is set to 1 If, this indicates that the intermediate forwarding node cannot fragment the packet, the 3rd bit is the “more fragmentation” bit, where if the 3rd bit is set to 1, this indicates that there are subsequent fragmented packets;

Fragment Offset - where this field is a value, and the destination device's IP uses this value to reassemble the fragments in the correct sequence;

Time To Live (TTL), where this field indicates router hops that can be reserved before the data packet is discarded. Each router checks this field and subtracts at least one from the router hops. When the value of this field reaches 0, the data packet is discarded;

Protocol - This field indicates the protocol used by the payload data -;

Header Checksum, where this field is used only to check the validity of the header. Each router through which the datagram passes recalculates the value of the TTL field because the value of the TTL field keeps changing;

Source IP Address (SIP);

Destination IP Address (DIP);

Options field which supports some optional header settings and is mainly used for testing, debugging and security purposes; and

Payload, which is the data part.

It can be seen from the foregoing that IPv4 packets do not contain a flow label field. Thus, in an implementation, when the plaintext packet is an IPv4 packet, the step of filling the Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet is to set N bits of the TEID field to the ciphertext filling in N bits of the flow label field of the IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet contains N bits; or performing hash calculation on the TEID field and the first parameter to obtain an eighth hash value, and filling N bits of the eighth hash value into N bits of the flow label field of the ciphertext IPv6 packet - flow label of the ciphertext IPv6 packet. The field contains N bits - contains.

In implementation, when the plaintext packet is an IPv4 packet, the flow label field of the ciphertext IPv6 packet includes a seventh field and an eighth field. Filling the Flow Label field of the ciphertext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet includes, from the TEID field, a seventh field or an eighth field of the flow label field of the ciphertext IPv6 packet. intercepting a portion having a length equal to the length and filling in a seventh field or an eighth field of a flow label field of the ciphertext IPv6 packet; or performing hash calculation on the TEID field and the first parameter to obtain a ninth hash value, having a length equal to the length of the seventh or eighth field of the flow label field of the ciphertext IPv6 packet, from the ninth hash value. intercepting the part, and filling in a seventh field or an eighth field of a flow label field of the ciphertext IPv6 packet.

In an implementation, the plaintext packet is an IPv4 packet. A plaintext packet is fragmented into a plurality of chips. Each of the plurality of chips is encrypted to obtain the ciphertext IPv6 packet of each chip. The flow label field of each chip's ciphertext IPv6 packet is populated based on the Tunnel Endpoint Identifier (TEID) field of the plaintext packet.

It should be understood that plaintext packets are IPv4 packets. As for the method for filling the flow label field of each chip's ciphertext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext packet, when the plaintext packet is an IPv6 packet, the tunnel endpoint identifier (TEID) field of the plaintext packet Refer to the above method for filling the flow label field of each chip's ciphertext IPv6 packet based on Details are not described herein again.

In an implementation, the first parameter includes at least one of the following parameters: the SIP of the ciphertext packet, the DIP of the ciphertext packet, and the next header of the ciphertext packet.

In an implementation, the second parameter includes at least one of the following parameters: SIP of the plaintext packet, DIP of the plaintext packet, next header of the plaintext packet, source port SPt of the plaintext packet, and destination port DPt of the plaintext packet.

In an embodiment of method 300, if the plaintext packet is an IPv6 packet and the flow label field of the plaintext packet is populated, the access network device determines the flow label of the ciphertext IPv6 packet based on the Flow Label field of the plaintext IPv6 packet. It should be understood that you can directly fill in the (Flow Label) field. For a specific filling method, refer to the method described above. To avoid repetition, details are not described herein again.

In this embodiment of the present application, in a scenario in which an access network device uses only a pair of service IPv6 addresses and a pair of Internet Key Exchange (IKE) IPv6 addresses, the uplink plaintext and ciphertext are sent to the plurality of access network devices per bearer. can implement flow load balancing of the transmission port of , effectively and fully utilize the transmission bandwidth. In a scenario where the downlink plaintext uses only a pair of service IPv6 addresses in the core network device, the downlink plaintext implements flow load balancing of multiple transport ports of the core network per bearer to effectively use transmission bandwidth. In a scenario where the downlink ciphertext uses a pair of service IPv6 addresses and a pair of IKE IPv6 addresses on the secure gateway, after the downlink packet is encrypted on the secure gateway, flow load balancing of multiple transport ports per bearer is implemented , effectively use the transmission bandwidth.

It should be understood that filling field 1 into field 2 means filling field 1's value into field 2 in the embodiments of the present application. That is, the value of field 1 is the same as the value of field 2. For example, filling the first field of the flow label field by intercepting a portion having a length equal to the length of the first field of the flow label field from the TEID field, the value of the portion intercepted from the TEID field is the flow label field It means filling in the first field of That is, the value of the part intercepted from the TEID field is the same as the value of the first field of the flow label field.

It should be understood that, in the embodiments of the present application, filling the N bits of field 1 into the N bits of field 2 means filling the value of the N bits of field 1 into the N bits of field 2. In other words, the value of N bits of field 1 is the same as the value of N bits of field 2. For example, filling N bits of the TEID field into N bits of the flow label field means filling the value of the TEID field into the flow label field. That is, the value of the TEID field is the same as the value of the flow label field.

In the following, load balancing and reliability in multiple scenarios of embodiments of the present application are briefly described. 10 illustrates the “IEEE 802.3ad Ethernet Link Aggregation” technique for load balancing. Ethernet link aggregation is to aggregate a plurality of Ethernet links into an aggregation group to implement load sharing between member ports and improve connection reliability. In FIG. 10 , an access network device 410 , a switch 420 and a router 430 are included. The two lines in FIG. 10 indicate that the two links are aggregated together. The link to transmit the packet depends on the hash value. Corresponding to the hash value calculated using 3-tuple in this embodiment of the present application, the access network device 410 may perform the corresponding procedure described in method 200, that is, in FIG. 4. have. In the figure, packets of different types represent packets of different bearers. Packets of the same bearer are transmitted on the same path because the hash values match. Packets of different bearers may be hashed on different paths for transmission. If one path is defective, flow packets that should be transmitted on the defective path can be immediately forwarded to the other path for transmission, improving reliability.

In Figure 11, in the ciphertext scenario, source and intermediate nodes implement bearer-based flow load balancing based on hash calculation. 11 is the ciphertext scenario of FIG. 10; In FIG. 11 , an access network device 510 , a switch 520 , a security gateway 530 , and a router 540 are included. During uplink data transmission, the access network device 510 may execute what is described in method 200 and copy the flow label field populated in the plaintext packet to the ciphertext packet, so that the ciphertext packet obtains the bearer information. . Load balancing may be performed in the manner shown in FIG. 10 . During uplink data transmission, security gateway 530 may execute a procedure described in method 300, i.e., corresponding to the procedure in FIG.

In Figure 12, in the equivalent routing scenario, source and intermediate nodes implement bearer-based flow load balancing based on hash calculation. Access network device 610 , switch 620 , router 630 , and router 640 are included in FIG. 12 . Two routes with the same priority are configured on switch 620. The access network device 610 may perform a procedure described in the method 200 , that is, corresponding to the procedure in FIG. 4 . The access network device 610 calculates a hash value based on the populated flow label field and the second parameter, thereby determining to forward packets to different routes through different routes, thereby implementing load balancing among multiple routes. .

In FIG. 13 , an access network device 710 , a switch 720 , a router 730 and a router 740 are included. Two routes with the same priority are configured on switch 720. In a load balancing scenario, when one path is faulty, for example, the path from switch 720 to router 740 is faulty, the service is quickly switched to the normal path for transport to improve reliability. , which is much faster than the reliability switching of layer 4 protocols.

It should be understood that the source device is a packet sender and may be an access network device or a core network device. Intermediate nodes can be routers, switches, and the like.

A wireless network communication method based on Internet protocol version IPv6 according to embodiments of the present application has been described in detail with reference to FIGS. 1 to 13 . Hereinafter, communication devices according to embodiments of the present application will be described in detail with reference to FIGS. 14 and 15 .

14 is a schematic block diagram of a communication device 800 according to an embodiment of the present application.

In some embodiments, apparatus 800 may be an access network device, or may be a chip or circuit, eg, a chip or circuit that may be disposed in an access network device.

In some embodiments, apparatus 800 may be a core network device, or may be a chip or circuit, eg, a chip or circuit that may be disposed in a core network device.

In some embodiments, apparatus 800 may be a secure gateway device, or may be a chip or circuit, eg, a chip or circuit that may be disposed in a secure gateway device.

In a possible manner, the apparatus 800 may include a processing unit 810 (ie, an example of a processor) and a transceiver unit 830 . In some possible implementations, processing unit 810 may also be referred to as a decision unit. In some possible implementations, transceiver unit 830 may include a receiving unit and a transmitting unit.

In implementations, transceiver unit 830 may be implemented using a transceiver, transceiver-related circuitry, or interface circuitry.

In implementations, the device may further include a storage unit 820 . In a possible manner, the storage unit 820 is configured to store instructions. In implementations, a storage unit may alternatively be configured to store data or information. The storage unit 820 may be implemented using a memory.

In a possible design, the processing unit 810 is configured to execute instructions stored in the storage unit 820, enabling the apparatus 800 to implement the steps performed by the terminal device in the method described above. Alternatively, the processing unit 810 may be configured to retrieve data in the storage unit 820 to enable the apparatus 800 to implement the steps performed by the terminal device in the method described above.

In a possible design, the processing unit 810 is configured to execute instructions stored in the storage unit 820, enabling the apparatus 800 to implement the steps performed by the access network device in the method described above. Alternatively, processing unit 810 may be configured to retrieve data in storage unit 820 to enable apparatus 800 to implement steps performed by an access network device in the method described above.

For example, the processing unit 810, the storage unit 820, and the transceiver unit 830 may communicate with each other through an internal connection path to transmit control signals and/or data signals. For example, storage unit 820 is configured to store a computer program. The processing unit 810 calls a computer program from the storage unit 820 and executes the computer program to receive and/or transmit a signal by controlling the transceiver unit 830, so as to access or access a terminal device in the above-described method. It can be configured to complete the steps of a network device. The storage unit 820 may be integrated into the processing unit 810 or may be disposed separately from the processing unit 810 .

Optionally, when apparatus 800 is a communication device (eg, terminal device or access network device), transceiver unit 830 includes a receiver and a transmitter. The receiver and transmitter may be the same physical entity or different physical entities. When the receiver and transmitter are the same physical entity, the receiver and transmitter may be collectively referred to as a transceiver.

Optionally, when device 800 is a chip or circuit, transceiver unit 830 includes an input interface and an output interface.

In an implementation, the functions of the transceiver unit 830 may be considered to be implemented using a transceiver circuit or a dedicated transceiver chip. It is contemplated that processing unit 810 may be implemented using a dedicated processing chip, processing circuit, processing unit, or general purpose chip.

In another implementation, a communication device (eg, a terminal device or an access network device) provided in this embodiment of the present application may be considered implemented using a general-purpose computer. That is, program codes for implementing the functions of the processing unit 810 and the transceiver unit 830 are stored in the storage unit 820, and the general-purpose processing unit executes the code in the storage unit 820, thereby processing the processing unit. 810 and transceiver unit 830.

In some embodiments, apparatus 800 may be an access network device or a core network device, or may be a chip or circuit disposed in an access network device or a core network device. When the device 800 is an access network device or a core network device, or a chip or circuit deployed in an access network device or a core network device, the processing unit 810 bases the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet on the to determine a transmission path of the plaintext IPv6 packet; The transceiver unit 830 is configured to transmit the plaintext IPv6 packet on the determined transmission path of the plaintext IPv6 packet.

In an implementation, the processing unit 810 is specifically configured to populate a Flow Label field of a plaintext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet; obtaining a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the filled flow label field, where SIP and DIP are SIP and DIP of the plaintext IPv6 packet; and determine a transmission path of the plaintext IPv6 packet based on the first hash value.

In an implementation, the processing unit 810 specifically fills N bits of the TEID field into N bits of the flow label field, where the flow label field includes N bits; or performing hash calculation on the TEID field and the first parameter to obtain a second hash value, and filling N bits of the second hash value into N bits of the flow label field, wherein the flow label field includes N bits do.

In an implementation, a flow label field of a plaintext IPv6 packet includes a first field and a second field. Specifically, the processing unit 810 intercepts, from the TEID field, a portion having a length equal to the length of the first or second field of the flow label field, and fills the first or second field of the flow label field, or ; Alternatively, a hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, and from the second hash value, a portion having the same length as the length of the first or second field of the flow label field is intercepted , configured to fill in the first field or the second field of the flow label field.

In an implementation, the processing unit 810 copies the Flow Label field of the plaintext IPv6 packet to the Flow Label field of the ciphertext IPv6 packet; or performing hash calculation on the second parameter and the flow label field of the plaintext IPv6 packet to obtain a fifth hash value, and further filling in the flow label field of the ciphertext IPv6 packet based on the fifth hash value. It consists of

When the apparatus 800 is or is configured within an access network device or a core network, the modules or units within the apparatus 800 perform actions or processing processes performed by the access network device or the core network device in the methods described above. can be configured to perform. To avoid repetition, detailed descriptions are omitted herein.

In some embodiments, device 800 may be a secure gateway, or may be a chip or circuit disposed in a secure gateway. When the device 800 is a security gateway, or a chip or circuit disposed in the security gateway, the transceiver unit 830 is configured to receive the plaintext packet sent by the core network device; The processing unit 810 is configured to populate a Flow Label field of a ciphertext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext packet, wherein the ciphertext IPv6 packet is a packet obtained by encrypting the plaintext packet to be. The processing unit obtains a first hash value by performing hash calculation based on a first parameter involved in hash calculation and the filled flow label field of the ciphertext IPv6 packet, where SIP and DIP are SIP and DIP of the ciphertext IPv6 packet. ; and determine a transmission path of the ciphertext IPv6 packet based on the first hash value.

In implementations, the plaintext packets are IPv6 packets or IPv4 packets. The processing unit 810 fills N bits of the TEID field into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet contains N bits; or perform hash calculation on the TEID field and the first parameter to obtain a second hash value, and fill N bits of the second hash value into N bits of a flow label field of the ciphertext IPv6 packet; The flow label field contains N bits.

In an implementation, the plaintext packet is an IPv6 packet or an IPv4 packet, and the flow label field of the ciphertext IPv6 packet includes a first field and a second field. The processing unit 810 intercepts, from the TEID field, a portion having a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet, and obtains the first field or the first field of the flow label field of the ciphertext IPv6 packet. fill in the second field; or performing hash calculation on the TEID field and the first parameter to obtain a third hash value, having a length equal to the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet, from the third hash value. and to intercept the part and fill in the first field or the second field of the flow label field of the ciphertext IPv6 packet.

In an implementation, the plaintext packet is an IPv6 packet. The processing unit 810 fills the Flow Label field of the plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet, and converts the filled Flow Label field of the plaintext IPv6 packet into ciphertext. It is configured to be copied to the Flow Label field of IPv6 packets.

In an implementation, the plaintext packet is an IPv6 packet. If the plaintext packet is fragmented into multiple chips, the processing unit 810 fills the Flow Label field of the plaintext IPv6 packet based on the Tunnel Endpoint Identifier (TEID) field of the plaintext IPv6 packet; fragment the plaintext IPv6 packet filled with the flow label field into a plurality of chips, each of the plurality of chips including the filled flow label field; copy the flow label field of each chip to the flow label field of each chip's encrypted cipher text packet; obtain a fourth hash value by performing hash calculation based on the first parameter and the flow label field of the ciphertext packet; and determine a transmission path of each cipher text packet based on the fourth hash value.

In an implementation, the processing unit 810 fills N bits of the TEID field into N bits of the flow label field of the plaintext IPv6 packet, wherein the flow label field of the plaintext IPv6 packet contains N bits; or performing hash calculation on the TEID field and the second parameter to obtain a fifth hash value, and filling N bits of the fifth hash value into N bits of the flow label field of the plaintext IPv6 packet; The flow label field of a packet contains N bits.

In an implementation, a flow label field of a plaintext IPv6 packet includes a first field and a second field. The processing unit 810 intercepts, from the TEID field, a portion having a length equal to the length of the first field or the second field of the flow label field of the plaintext IPv6 packet, and obtains the first field or the first field of the flow label field of the plaintext IPv6 packet. fill in the second field; or performing hash calculation on the TEID field and the second parameter to obtain a sixth hash value, having a length equal to the length of the first field or the second field of the flow label field of the plaintext IPv6 packet, from the sixth hash value. intercepting part, and filling in the first field or the second field of the flow label field of the plaintext IPv6 packet.

In implementations, the plaintext packets are IPv4 packets or IPv6 packets. If the plaintext packet is fragmented into multiple chips, the processing unit 810 fragments the plaintext packet into multiple chips; encrypt each of the plurality of chips to obtain a cipher text packet of each chip; fill the flow label field of each chip's ciphertext packet based on the tunnel endpoint identifier (TEID) field of the plaintext packet; obtain a seventh hash value by performing hash calculation based on the first parameter and the flow label field of the ciphertext packet; and determine a transmission path of each cipher text packet based on the seventh hash value.

When device 800 is configured in or is a security gateway, modules or units within device 800 may be configured to perform actions or processing processes performed by the security gateway in the methods described above. To avoid repetition, detailed descriptions are omitted herein.

For the concepts, descriptions, detailed descriptions, and other steps of the device 800 related to the technical solutions provided in the embodiments of the present application, the content in the foregoing methods or other embodiments see explanations. Details are not described herein again.

15 is a schematic diagram of the structure of an access network device 900 according to an embodiment of the present application. The access network device 900 may be configured to implement functions of an access device (eg, a first access network device, a second access network device, or a third access network device) in the method described above. The access network device 900 includes a remote radio unit (RRU) 910 and one or more baseband units (BBUs) (which may also be referred to as digital units (DUs)) 920 ) and includes one or more radio frequency units such as The RRU 910 may be referred to as a transceiver unit, a transceiver, a transceiver circuit, a transceiver machine, and the like, and may include at least one antenna 911 and a radio unit 912 . The RRU 910 is mainly configured to transmit and receive radio frequency signals, perform conversion between radio frequency signals and baseband signals, and transmit signaling messages in the foregoing embodiments to a terminal device, for example. do. BBU 920 is mainly configured to perform baseband processing, control base stations, and the like. RRU 910 and BBU 920 may be physically co-located, or may be physically separate, ie, in a distributed base station.

BBU 920 is the control center of a base station and is also referred to as a processing unit that is primarily configured to implement baseband processing functions such as channel encoding, multiplexing, modulation, or spreading. For example, BBU (processing unit) 920 may be configured to control base station 40 to perform operational procedures related to network devices in the foregoing method embodiments.

In an example, BBU 920 may include one or more boards, and multiple boards may jointly support a radio access network (such as an LTE system or a 5G system) in a single access standard, or a radio access network in different access standards. Access networks can be individually supported. The BBU 920 further includes a memory 921 and a processor 922. Memory 921 is configured to store necessary instructions and data. For example, the memory 921 stores codebooks and the like in the above-described embodiments. The processor 922 is configured to control the base station to perform necessary actions, for example, to control the base station to perform an operating procedure related to the network device in the foregoing method embodiments. Memory 921 and processor 922 may serve one or more boards. That is, the memory and processor may be placed on separate boards. Alternatively, multiple boards may share the same memory and processor. In addition, necessary circuitry can be additionally placed on each board.

In a possible implementation, with the development of system-on-chip (SoC) technology, all or some of the functions of portions 920 and 910 may be implemented using SoC technology, e.g., one It can be implemented using a base station function chip. A base station function chip integrates components such as a processor, memory, and antenna port. A program of functions related to the base station is stored in a memory, and the processor executes the program to implement the functions related to the base station. Optionally, the base station function chip may also read the external memory of the chip to implement the related functions of the base station.

It should be understood that the structure of the access network device shown in FIG. 15 is merely a possible form and should not constitute any limitation to the embodiments of the present application. This application does not exclude the possibility that other types of base station structures may appear in the future.

The processor in the embodiments of the present application may be a central processing unit (CPU), or another general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC) ), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or the like. A general purpose processor may be a microprocessor, or the processor may be any conventional processor or the like.

It should be further understood that memory in embodiments of the present application may be volatile memory or non-volatile memory, or may include volatile memory and non-volatile memory. Non-volatile memory includes read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EPROM). EPROM, EEPROM), or flash memory. Volatile memory may be random access memory (RAM) used as an external cache. By way of example and not limitation, there are many forms of random access memory (RAM), such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory ( synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchlink dynamic random access memory (synchlink DRAM, SLDRAM) , and direct rambus random access memory (direct rambus RAM, DR RAM) may be used.

All or part of the foregoing embodiments may be implemented using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, the above-described embodiments may be fully or partially implemented in the form of a computer program product. A computer program product includes one or more computer instructions or computer programs. When computer instructions or computer programs are loaded onto a computer and executed, procedures or functions according to embodiments of the present application are all or partially created. A computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device. Computer instructions may be stored on a computer readable storage medium or transferred from a computer readable storage medium to another computer readable storage medium. For example, computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center by wire (eg, infrared, radio, and microwave, etc.) . A computer readable storage medium can be any available medium that is accessible by a computer, or a data storage device, such as a server or data center, that incorporates one or more available media. Usable media may be magnetic media (eg floppy disk, hard disk, or magnetic tape), optical media (eg DVD), or semiconductor media. The semiconductor medium may be a solid state drive.

Embodiments of the present application further provide a computer readable medium storing a computer program. When the computer program is executed by a computer, the steps performed by the access network device, the steps performed by the core network device, or the steps performed by the security gateway device in any one of the foregoing embodiments are implemented. .

Embodiments of the present application further provide a computer program product. When the computer program product is executed by a computer, the steps performed by the access network device, the steps performed by the core network device, or the steps performed by the security gateway device in any one of the foregoing embodiments are implemented. do.

Embodiments of the present application further provide a system chip. The system chip includes a communication unit and a processing unit. A processing unit may be, for example, a processor. A communication unit may be, for example, a communication interface, an input/output interface, a pin, a circuit, or the like. The processing unit is capable of executing computer instructions, so that a chip in the communication apparatus steps performed by an access network device, steps performed by a core network device, or security steps provided in the foregoing embodiments of the present application. Perform the steps performed by the gateway device.

Optionally, computer instructions are stored in the storage unit.

According to the method provided in the embodiments of the present application, the embodiment of the present application further provides a communication system. The communication system includes the aforementioned access network device, core network device, and security gateway device.

Embodiments of the present application may be used independently or may be used jointly. This is not limited here.

Also, aspects or features of the present application may be implemented as a method, apparatus, or product using standard programming and/or engineering techniques. The term "product" as used in this application covers a computer program that can be accessed from any computer readable component, carrier or medium. For example, computer readable media include magnetic storage components (eg, hard disks, floppy disks, or magnetic tape), optical disks (eg, compact discs (CDs), and digital versatile discs). versatile disc (DVD)), smart cards, and flash memory components (e.g., erasable programmable read-only memory (EPROM), card, stick, or key drive), but , but is not limited thereto. Additionally, various storage media described herein can represent one or more devices and/or other machine-readable media configured to store information. The term "machine-readable medium" may include, but is not limited to, a radio channel and various other media capable of storing, containing and/or carrying instructions and/or data.

It should be understood that all table parameters in this application are used only as examples and do not represent specific calculated values, parameters, etc.

It should be understood that the term "and/or" describes an associative relationship between associated objects and indicates that three relationships may exist. For example, A and/or B may represent the following three cases: that only A exists, that both A and B exist, and that only B exists. The character "/" generally indicates an "or" relationship between related objects. The term “at least one” means one or more. The term “at least one of A and B,” similar to the term “A and/or B,” describes an association relationship between associated objects, indicating that three relationships may exist. For example, at least one of A and B may represent the following three cases: that only A exists, that both A and B exist, and that only B exists.

It should be understood that there are multiple hash values in this application, eg, "first hash value", "second hash value", and "third hash value". These represent hash values obtained by performing a hash operation based on different parameters. Specific values of "first hash value", "second hash value", and "third hash value" are determined by hash parameters. "First", "Second", "Third", etc. do not impose any restrictions on the hash value.

A person skilled in the art may know that, in combination with the examples described in the embodiments disclosed herein, units and algorithm steps may be implemented by electronic hardware or a combination of computer software and electronic hardware. . Whether the functions are performed by hardware or software depends on the specific applications and design constraints of the technical solutions. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that such implementation goes beyond the scope of the present application.

For convenient and brief description, for detailed working processes of the foregoing systems, apparatuses, and units, reference is made to corresponding processes in the foregoing method embodiments, and details are not described herein again. can be clearly understood by those skilled in the art.

In some embodiments provided herein, it should be understood that the disclosed systems, apparatus, and methods may be implemented in other ways. For example, the device embodiments described are merely examples. For example, division into units may be just logical function division or other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. Also, the indicated or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. Indirect couplings or communication connections between devices or units may be implemented in electrical, mechanical, or other forms.

Units described as separate parts may or may not be physically separate, and parts presented as units may or may not be physical units, may be located in one location, or may be located on a plurality of networks. Can be distributed over units. Some or all of the units may be selected according to actual requirements to achieve the objectives of the solutions of the embodiments.

Also, functional units in the embodiments of the present application may be integrated into one processing unit, each of the units may physically exist alone, or two or more units are integrated into one unit.

When functions are implemented in the form of a software functional unit and sold or used as an independent product, these functions may be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially, or the part contributing to the current technology, or part of the technical solutions may be implemented in the form of a software product. The software product is stored in a storage medium and contains several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform all or part of the steps of the methods described in the embodiments of the present application. include The aforementioned storage medium may store program codes, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Including any medium with

The foregoing descriptions are merely specific implementations of the present application, and are not intended to limit the protection scope of the present application. Any variation or replacement readily figured out by a person skilled in the art within the technical scope disclosed in this application shall fall within the protection scope of this application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims.

Claims (26)

A wireless network communication method based on Internet protocol version IPv6, comprising:
determining a transmission path of the plaintext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet, wherein the TEID field indicates a bearer to which the plaintext IPv6 packet belongs; and
Transmitting the plaintext IPv6 packet on the determined transmission path of the plaintext IPv6 packet
Including, method. According to claim 1,
The step of determining a transmission path of the plaintext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet,
filling a flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet;
obtaining a first hash value by performing hash calculation based on the filled flow label field and the first parameter; and
Determining a transmission path of the plaintext IPv6 packet based on the first hash value
Including, method. According to claim 2,
The flow label field includes N bits, and filling the flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet includes:
filling N bits of the TEID field into N bits of the flow label field; or
Obtaining a second hash value by performing hash calculation on the TEID field and the first parameter, and filling N bits of the second hash value into N bits of the flow label field.
Including, method. According to claim 2,
The flow label field of the plaintext IPv6 packet includes a first field and a second field, and a flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet The step of filling is,
intercepting a portion having a length equal to a length of the first or second field of the flow label field from the TEID field, and filling the first or second field of the flow label field; or
A hash calculation is performed on the TEID field and the first parameter to obtain a second hash value, and a length equal to the length of the first or second field of the flow label field is obtained from the second hash value. Intercepting a part having a part and filling the first field or the second field of the flow label field
Including, method. According to any one of claims 1 to 4,
The method,
filling a Flow Label field of the ciphertext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext IPv4 packet, wherein the ciphertext IPv6 packet is a packet obtained by encrypting a plaintext packet;
obtaining a sixth hash value by performing hash calculation based on the filled flow label field of the ciphertext IPv6 packet and a second parameter; and
determining a transmission path of the ciphertext IPv6 packet based on the third hash value;
Further comprising a method. According to claim 5,
Filling the flow label field of the ciphertext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet,
filling N bits of the TEID field into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet includes N bits; or
obtaining a fourth hash value by performing hash calculation on the TEID field and the second parameter; and
filling N bits of the fourth hash value into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet includes N bits;
Including, method. According to claim 6,
The flow label field of the ciphertext IPv6 packet includes a third field and a fourth field, and fills a flow label field of the ciphertext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet. step is,
intercepting, from the TEID field, a portion having the same length as the length of the third field or the fourth field of the flow label field of the ciphertext IPv6 packet, and the third field of the flow label field of the ciphertext IPv6 packet; or filling the fourth field; or
obtaining a fifth hash value by performing hash calculation on the TEID field and the second parameter; and
intercepting, from the fifth hash value, a portion having the same length as the length of the third field or the fourth field of the flow label field of the ciphertext IPv6 packet; Filling the 3rd field or the 4th field
Including, method. According to claim 5,
The plaintext IPv4 packet includes a plurality of chips, and the method comprises:
encrypting each of the plurality of chips to obtain a cipher text packet of each chip;
filling a flow label field of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet; and
Obtaining a sixth hash value by performing hash calculation based on the flow label field of the ciphertext packet and the second parameter.
Including more,
wherein determining a transmission path of the ciphertext IPv6 packet based on the third hash value comprises determining a transmission path of each ciphertext chip based on the sixth hash value. According to claim 8,
Filling a flow label field of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext IPv4 packet;
filling N bits of the TEID field into N bits of the flow label field of the cipher text packet of each chip, wherein the flow label field of the cipher text packet of each chip includes N bits; or
obtaining a seventh hash value by performing hash calculation on the TEID field and the second parameter; and
filling N bits of the seventh hash value into N bits of the flow label field of the ciphertext packet of each chip, wherein the flow label field of the ciphertext packet of each chip includes N bits;
Including, method. According to claim 8,
The flow label field of the ciphertext packet of each chip includes a fifth field and a sixth field, and the flow label of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext packet Steps to fill in the fields are:
The flow label of the ciphertext packet of each chip by intercepting a part having the same length as the length of the fifth field or the sixth field of the flow label field of the ciphertext packet of each chip from the TEID field filling the fifth field or the sixth field of a field; or
obtaining an eighth hash value by performing hash calculation on the TEID field and the second parameter; and
From the eighth hash value, a portion having the same length as the length of the fifth field or the sixth field of the flow label field of the ciphertext packet of each chip is intercepted, and the ciphertext packet of each chip is intercepted. Filling the fifth field or the sixth field of the flow label field
Including, method. As a communication method based on Internet protocol version IPv6,
Receiving a plaintext packet from a core network device;
filling a Flow Label field of a ciphertext IPv6 packet based on a Tunnel Endpoint Identifier (TEID) field of the plaintext packet, wherein the ciphertext IPv6 packet is a packet obtained by encrypting the plaintext packet;
obtaining a first hash value by performing hash calculation based on the filled flow label field of the ciphertext IPv6 packet and a first parameter; and
determining a transmission path of the ciphertext IPv6 packet based on the first hash value;
Including, method. According to claim 11,
The plaintext packet is an IPv6 packet or an IPv4 packet, and filling a flow label field of the ciphertext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext packet comprises:
filling N bits of the TEID field into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet includes N bits; or
obtaining a second hash value by performing hash calculation on the TEID field and the first parameter; and
filling N bits of the second hash value into N bits of the flow label field of the ciphertext IPv6 packet, wherein the flow label field of the ciphertext IPv6 packet includes N bits;
Including, method. According to claim 11,
The plaintext packet is an IPv6 packet or an IPv4 packet, the flow label field of the ciphertext IPv6 packet includes a first field and a second field, and based on a tunnel endpoint identifier (TEID) field of the plaintext packet, an ciphertext IPv6 packet The step of filling the Flow Label field of
intercepting, from the TEID field, a portion having the same length as the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet, and the first field of the flow label field of the ciphertext IPv6 packet; or filling the second field; or
obtaining a third hash value by performing hash calculation on the TEID field and the first parameter; and
intercepting, from the third hash value, a portion having the same length as the length of the first field or the second field of the flow label field of the ciphertext IPv6 packet; Filling in one field or the second field
Including, method. According to claim 11,
The plaintext packet is an IPv6 packet, and filling a flow label field of the ciphertext IPv6 packet based on a tunnel endpoint identifier (TEID) field of the plaintext packet comprises:
filling a flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet; and
copying the filled-in flow label field of the plaintext IPv6 packet to the flow label field of the ciphertext IPv6 packet;
Including, method. According to claim 11,
When the plaintext packet is an IPv6 packet and the plaintext packet is fragmented into a plurality of chips, the method comprises:
filling a flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet;
fragmenting the plaintext IPv6 packet filled with the flow label field into a plurality of chips, each of the plurality of chips including a filled flow label field;
copying the flow label field of each chip to the flow label field of the encrypted cipher text packet of each chip;
obtaining a fourth hash value by performing hash calculation based on the flow label field of the ciphertext packet and the first parameter; and
Determining a transmission path of each ciphertext packet based on the fourth hash value
Further comprising a method. The method of claim 14 or 15,
Filling a flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet includes:
filling N bits of the TEID field into N bits of the flow label field of the plaintext IPv6 packet, wherein the flow label field of the plaintext IPv6 packet includes N bits; or
obtaining a fifth hash value by performing hash calculation on the TEID field and a second parameter; and
filling N bits of the fifth hash value into N bits of the flow label field of the plaintext IPv6 packet, wherein the flow label field of the plaintext IPv6 packet includes N bits;
Including, method. The method of claim 14 or 15,
The flow label field of the plaintext IPv6 packet includes a first field and a second field, and a flow label field of the plaintext IPv6 packet based on the tunnel endpoint identifier (TEID) field of the plaintext IPv6 packet The step of filling is,
The first field of the flow label field of the plaintext IPv6 packet by intercepting a portion having the same length as the length of the first field or the second field of the flow label field of the plaintext IPv6 packet from the TEID field; or filling the second field; or
obtaining a sixth hash value by performing hash calculation on the TEID field and a second parameter; and
intercepting, from the sixth hash value, a portion having the same length as the length of the first field or the second field of the flow label field of the plaintext IPv6 packet; Filling in one field or the second field
Including, method. According to claim 11,
When the plaintext packet is an IPv4 packet or an IPv6 packet, and the plaintext packet is fragmented into a plurality of chips, the method comprises:
fragmenting the plaintext packet into the plurality of chips;
encrypting each of the plurality of chips to obtain a cipher text packet of each chip;
filling a flow label field of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext packet;
obtaining a seventh hash value by performing hash calculation based on the flow label field of the ciphertext packet and the first parameter; and
Determining a transmission path of each ciphertext packet based on the seventh hash value
Further comprising a method. According to claim 18,
Filling the flow label field of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext packet,
filling N bits of the TEID field into N bits of the flow label field of the cipher text packet of each chip, wherein the flow label field of the cipher text packet of each chip includes N bits; or
obtaining an eighth hash value by performing hash calculation on the TEID field and the first parameter; and
filling N bits of the eighth hash value into N bits of the flow label field of the ciphertext packet of each chip, wherein the flow label field of the ciphertext packet of each chip includes N bits;
Including, method. According to claim 19,
The flow label field of the ciphertext packet of each chip includes a first field and a second field, and the flow label of the ciphertext packet of each chip based on the tunnel endpoint identifier (TEID) field of the plaintext packet Steps to fill in the fields are:
The flow label of the ciphertext packet of each chip by intercepting a part having the same length as the length of the first field or the second field of the flow label field of the ciphertext packet of each chip from the TEID field filling the first field or the second field of a field; or
obtaining a ninth hash value by performing hash calculation on the TEID field and the first parameter; and
From the ninth hash value, a portion having the same length as the length of the first field or the second field of the flow label field of the ciphertext packet of each chip is intercepted, and the ciphertext packet of each chip is intercepted. Filling the first field or the second field of the flow label field
Including, method. As a communication device,
11. A device comprising a processor, the processor being connected to a memory, the memory being configured to store a computer program, the processor being configured to execute the computer program stored in the memory, wherein the apparatus is configured to: 21. A communication device for performing a method according to any one of claims 11 to 20. As a computer readable storage medium,
The computer readable storage medium stores a computer program; A computer-readable storage medium, wherein the method according to any one of claims 1 to 10 or the method according to any one of claims 11 to 20 is implemented when the computer program is executed. A chip containing a processor and an interface,
The processor is configured to read instructions for performing a method according to any one of claims 1 to 10 or a method according to any one of claims 11 to 20. As a communication system,
A communication system comprising a communication device for performing a method according to any one of claims 1 to 10 and a communication device for performing a method according to any one of claims 11 to 20 . As a computer program product,
21. A computer program product comprising a program, wherein when the program is executed, the method according to any one of claims 1 to 20 is performed. As a communication device,
21. A communication device configured to perform a method according to any one of claims 1 to 20.

Images