CN111818630A

CN111818630A - State variable maintenance method and device and user equipment

Info

Publication number: CN111818630A
Application number: CN201910632083.9A
Authority: CN
Inventors: 鲍炜
Original assignee: Vivo Mobile Communication Co Ltd
Current assignee: Vivo Mobile Communication Co Ltd
Priority date: 2019-07-12
Filing date: 2019-07-12
Publication date: 2020-10-23
Anticipated expiration: 2039-07-12
Also published as: CN111818630B

Abstract

The invention discloses a state variable maintenance method, a state variable maintenance device and user equipment, and belongs to the technical field of communication. The state variable maintenance method is applied to the sending end user equipment in the secondary link, and comprises any one of the following steps: sending Hyper Frame Number (HFN) and Sequence Number (SN) of a data packet to receiving end user equipment; and sending the SN of the data packet to the receiving end user equipment. The technical scheme of the invention can ensure that the UE at two ends of the sidelink accurately synchronizes the state variable, thereby carrying out correct receiving processing.

Description

State variable maintenance method and device and user equipment

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a state variable maintenance method and apparatus, and a user equipment.

Background

In Long Term Evolution (LTE) sidelink (sidelink, or sidelink and sidelink) transmission, a new method for initializing a receive variable is introduced into a vehicle networking (V2X), an initial value of a Sequence Number (SN) of the receive variable is set to be 1 added to an SN of a first received Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU), and a Hyper Frame Number (HFN) part is initialized to be zero. That is, for a receiving User Equipment (UE) added in the middle, a data packet missed before cannot exceed the number of data packets corresponding to one HFN range, and once the number of data packets exceeds the number of data packets corresponding to one HFN range, the HFN may be out of synchronization, so that a receiving operation is erroneous, which causes unsuccessful safety-releasing, and affects a receiving effect. In brief, if the HFN used by the data packet sent by the sending end is 2 and the HFN used by the receiving end is 0 (initial value), the same SN is adopted, and the obtained COUNT (COUNT) value is different, that is, the COUNT value adopted by the sending end for ciphering and the COUNT value used by the receiving end for deciphering are different, so that deciphering is not successful, UE data reception is failed, the service layer cannot correctly obtain data, and the receiving effect is poor.

Disclosure of Invention

The embodiment of the invention provides a state variable maintenance method, a state variable maintenance device and user equipment, which can enable UE at two ends of a sidelink to accurately synchronize state variables so as to perform correct receiving processing.

In a first aspect, an embodiment of the present invention provides a state variable maintenance method, which is applied to a sending-end user device in a sidelink, and includes any one of the following:

sending Hyper Frame Number (HFN) and Sequence Number (SN) of a data packet to receiving end user equipment;

and sending the SN of the data packet to the receiving end user equipment.

In a second aspect, an embodiment of the present invention provides a state variable maintenance method, which is applied to a receiving end user equipment in a sidelink, and includes any one of the following:

receiving a Hyper Frame Number (HFN) and a Sequence Number (SN) of a data packet of user equipment at a sending end;

and receiving the SN of the data packet of the user equipment at the sending end.

In a third aspect, an embodiment of the present invention further provides a state variable maintenance apparatus, applied to a sending-end user equipment in a sidelink, where the apparatus includes:

a sending module, configured to perform any one of the following operations:

and sending the SN of the data packet to the receiving end user equipment.

In a fourth aspect, an embodiment of the present invention provides a state variable maintenance apparatus, which is applied to a receiving end user equipment in a sidelink, and includes:

a receiving module configured to perform any one of the following operations:

In a fifth aspect, an embodiment of the present invention further provides a communication device, where the communication device includes a processor, a memory, and a computer program stored in the memory and running on the processor, and the processor implements the steps of the state variable maintenance method described above when executing the computer program.

In a sixth aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the state variable maintenance method described above.

In the above scheme, the sending end user equipment in the sidelink may send the HFN and the SN of the data packet to the receiving end user equipment, or send the SN of the data packet to the receiving end user equipment, so that the user equipment at both ends of the sidelink can accurately synchronize the state variables, thereby performing correct receiving processing.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

Fig. 1 shows a schematic diagram of Uplink, Downlink and Sidelink for an LTE system;

FIG. 2 is a schematic composition diagram showing the COUNT value;

fig. 3 is a flowchart illustrating a state variable maintenance method applied to a sending-end user equipment according to an embodiment of the present invention;

fig. 4 is a flowchart illustrating a state variable maintenance method applied to a receiving-end user equipment according to an embodiment of the present invention;

fig. 5 is a schematic block diagram illustrating a state variable maintenance apparatus applied to a sending-end user device according to an embodiment of the present invention;

fig. 6 is a schematic block diagram of a state variable maintenance apparatus applied to a receiving-end user device according to an embodiment of the present invention;

fig. 7 shows a block diagram of a user equipment according to an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

The terms first, second and the like in the description and in the claims of the present application are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. In the description and in the claims "and/or" means at least one of the connected objects.

The techniques described herein are not limited to Long Term Evolution (LTE)/LTE Evolution (LTE-Advanced) systems, and may also be used for various wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" are often used interchangeably. CDMA systems may implement Radio technologies such as CDMA2000, Universal Terrestrial Radio Access (UTRA), and so on. UTRA includes Wideband CDMA (Wideband code division Multiple Access, WCDMA) and other CDMA variants. TDMA systems may implement radio technologies such as Global System for Mobile communications (GSM). The OFDMA system may implement radio technologies such as Ultra Mobile Broadband (UMB), evolved-UTRA (E-UTRA), IEEE 802.11(Wi-Fi), IEEE 802.16(WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA and E-UTRA are parts of the Universal Mobile Telecommunications System (UMTS). LTE and higher LTE (e.g., LTE-A) are new UMTS releases that use E-UTRA. UTRA, E-UTRA, UMTS, LTE-A, and GSM are described in documents from an organization named "third Generation partnership project" (3 GPP). CDMA2000 and UMB are described in documents from an organization named "third generation partnership project 2" (3GPP 2). The techniques described herein may be used for both the above-mentioned systems and radio technologies, as well as for other systems and radio technologies. However, the following description describes the NR system for purposes of example, and NR terminology is used in much of the description below, although the techniques may also be applied to applications other than NR system applications.

The following description provides examples and does not limit the scope, applicability, or configuration set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the spirit and scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For example, the described methods may be performed in an order different than described, and various steps may be added, omitted, or combined. In addition, features described with reference to certain examples may be combined in other examples.

The LTE system supports sidelink, as shown in fig. 1, for direct data transmission between terminal UEs without passing through a network device.

The design of the LTE sidelink is suitable for specific public safety affairs (emergency communication in disaster places such as fire places or earthquakes) or vehicle networking communication and the like. The internet of vehicles communication includes various services, such as basic security type communication, advanced (automated) driving, formation, sensor expansion, and the like. Since LTE sidelink supports only broadcast communication, it is mainly used for basic security class communication, and other advanced V2X services with strict Quality of Service (QoS) requirements in terms of latency, reliability, etc. will be supported by NR sidelink.

The 5G NR system can be used for an operating frequency band of more than 6GHz which is not supported by LTE, and supports a larger operating bandwidth, but the NR system in the related art only supports an interface between a base station and a terminal, and does not support a Sidelink interface for direct communication between terminals.

The sidelink transmission mainly comprises broadcast (broadcast), multicast (groupcast) and unicast (unicast) transmission forms. Unicast, as the name implies, is a one-to-one transmission; multicasting is one-to-many (one to any) transmission; broadcast is also a one to many transmission, but broadcast does not have the concept that UEs belong to the same group, where sidelink unicast and multicast communication supports a physical layer Hybrid Automatic Repeat reQuest (HARQ) feedback mechanism.

The resource allocation patterns of the Sidelink UEs are divided into two types in total:

1) and a base station scheduling Mode (Mode 1) in which the network side device (base station) controls and allocates resources to each UE.

2) UE autonomous Mode (Mode 2) the resources are selected autonomously by each UE.

The received variables for LTE V2X include the following variables:

a variable Next _ PDCP _ RX _ SN indicates that for a Packet Data Convergence Protocol (PDCP) entity receiver, the Next expected received PDCP sequence number, the UE will set Next _ PDCP _ RX _ SN to 0. For PDCP entities mapped to LTE V2X, the UE needs to set Next _ PDCP _ RX _ SN to (x +1) modulo (Maximum _ PDCP _ SN +1), where x is the SN of the first received PDCP PDU with SN not 0.

A variable RX _ HFN indicating the HFN used for generating the COUNT value of the received PDCP PDU for one PDCP entity. At PDCP entity setup, the UE sets RX _ HFN to 0.

A variable Last _ transmitted _ PDCP _ RX _ SN indicating the SN of the Last PDCP Service Data Unit (SDU) delivered to a higher layer. At PDCP entity setup, the UE sets Last _ terminated _ PDCP _ RX _ SN to Maximum _ PDCP _ SN. For PDCP entities mapped to LTE V2X, the UE sets Last _ reported _ PDCP _ RX _ SN to (x-0.5 Reordering _ Window) modulo (Maximum _ PDCP _ SN +1), where x is the SN of the first received PDCP data PDU with SN other than 0. The COUNT value composition is shown in fig. 2.

In LTE sidelink transmission, V2X introduces a new way of receiving variable initialization, where the initial value of the SN of the receiving variable is set to the SN of the first received PDCP PDU plus 1, and the HFN part is initialized to zero. That is, for the receiving UE joining in the middle, the number of the data packets missed before cannot exceed the number of the data packets corresponding to one HFN range, and once the number of the data packets exceeds the number of the data packets, the HFN may be out of synchronization, so that the receiving operation is wrong, the security is not successfully decoded, and the receiving effect is affected. In brief, if the HFN used by the data packet sent by the sending end is 2 and the HFN used by the receiving end is 0 (initial value), the same SN is adopted, and the obtained COUNT value is different, that is, the COUNT value adopted by the sending end for encryption and the COUNT value used by the receiving end for decryption are different, so that the decryption will not be successful, the UE data reception will be failed, the service layer cannot correctly obtain the data, and the receiving effect is poor.

Furthermore, the receiving end operation of the NR PDCP and the PDCP receiving end operation of the LTE have a certain change, the former records the COUNT value of the state variable, and the latter maintains the SN and the HFN separately, and such a difference also exists in the state variable update operation, so that the LTE operation cannot be directly used in the NR and needs to be redesigned.

In order to solve the above problem, embodiments of the present invention provide a method and an apparatus for maintaining state variables, and user equipment, which can enable UEs at both ends of a sidelink to accurately synchronize state variables, so as to perform correct receiving processing.

An embodiment of the present invention provides a state variable maintenance method, which is applied to a sending-end user equipment in a sidelink, and as shown in fig. 3, the method includes any one of the following steps:

step 101: sending Hyper Frame Number (HFN) and Sequence Number (SN) of a data packet to receiving end user equipment;

step 102: and sending the SN of the data packet to the receiving end user equipment.

In this embodiment, the sending-end user equipment in the secondary link may send the HFN and the SN of the data packet to the receiving-end user equipment, or send the SN of the data packet to the receiving-end user equipment, so that the user equipment at both ends of the secondary link can accurately synchronize the state variables, thereby performing correct receiving processing. And the sending end user equipment simultaneously supports sending HFN and SN, and can ensure the synchronization of the COUNT values at the receiving end and the sending end, thereby ensuring the successful execution of decryption and integrity verification, achieving the effect of ensuring sidelink data transmission and obtaining better user experience.

Because the sending-end user equipment may send HFN and SN to the receiving-end user equipment, and may also send SN to the receiving-end equipment, the data packet further needs to carry first indication information for indicating that SN or a COUNT value is carried in the packet header of the data packet, where the COUNT value includes SN and HFN, so that the receiving-end UE can know that SN or a COUNT value is carried in the packet header of the data packet, and maintain the state variable according to the SN or the COUNT value.

Optionally, the capability of the sending-end user equipment and the receiving-end user equipment for supporting the air interface transmission COUNT value is determined by any one of the following manners: configuring through signaling; pre-configuring; agreement is agreed; default values are used.

In a specific embodiment, when the HFN of a data packet is the same as the HFN of the previous data packet or the HFN is 0, the packet header of the data packet carries the SN of the data packet;

when the HFN of a data packet is different from the HFN of the previous data packet or the HFN is not 0, the packet header of the data packet carries the COUNT value of the data packet.

When the HFN of a data packet is the same as the HFN of the previous data packet or the HFN is 0, the receiving end user equipment can accurately synchronize the state variable according to the SN of the data packet, so that the HFN does not need to be carried in the packet header of the data packet, and only the SN of the data packet can be carried; when the HFN of a data packet is different from the HFN of the previous data packet or the HFN is not 0, the ue at the receiving end needs to synchronize the state variables accurately according to the COUNT value of the data packet, and therefore, the HFN also needs to be carried in the packet header of the data packet.

In a specific embodiment, the sending the COUNT value of the data packet to the receiving-end ue includes:

sending N data packets carrying the COUNT value to the receiving end user equipment, wherein N is an integer greater than 1, and the N data packets carrying the COUNT value meet any one of the following conditions:

the N data packets carrying the COUNT value are continuous N data packets;

the hyper frame numbers of the N data packets carrying the COUNT values are the same, and the SN difference values of the adjacent data packets are all the same;

the hyper frame numbers of the N data packets carrying the COUNT value are the same, and the byte number of the accumulated service data unit SDU between the adjacent data packets meets a preset threshold value;

in the N data packets carrying the COUNT value, a preset time interval is reserved between adjacent data packets.

If the sending end UE only sends one data packet carrying the COUNT value, if the data packet carrying the COUNT value is lost, the sending end UE and the receiving end UE cannot synchronize the HFN. Considering that N consecutive data packets may be concatenated in a transmission block and transmitted simultaneously, and there is a possibility that N consecutive data packets carrying the COUNT value are lost simultaneously, the sending-end UE may send N discontinuous data packets carrying the COUNT value to the receiving-end UE.

In an embodiment, in order to inform the receiving end UE of the current HFN value, when the HFN of the data packet is not 0, the method further includes any one of the following steps:

after a data packet carrying a COUNT value is sent, starting a COUNT value periodic sending timer, sending a data packet carrying an SN before the COUNT value periodic sending timer is overtime, and sending the data packet carrying the COUNT value again after the COUNT value periodic sending timer is overtime, wherein the data packet carrying the COUNT value sent again and the data packet carrying the COUNT value carried in the previous data packet are not the same data packet but carry the COUNT value;

after sending the first or the last data packet in the N data packets carrying the COUNT value, starting a COUNT value periodic sending timer, sending the data packets carrying SN before the COUNT value periodic sending timer is overtime, and sending the N data packets carrying the COUNT value again after the COUNT value periodic sending timer is overtime, wherein N is an integer greater than 1;

after sending a data packet carrying a COUNT value, starting a data packet counter, when the value of the data packet counter is less than or equal to M, sending a data packet carrying SN, adding 1 to the value of the data packet counter when sending one data packet carrying SN, and after the value of the data packet counter is greater than M, sending the data packet carrying the COUNT value again, wherein M is an integer greater than 1;

after sending the first or the last data packet in the N data packets carrying the COUNT value, starting a data packet counter, sending the data packets carrying the SN when the value of the data packet counter is less than or equal to M, adding 1 to the value of the data packet counter when sending one data packet carrying the SN, and sending the N data packets carrying the COUNT value again after the value of the data packet counter is greater than M;

after sending a data packet carrying a COUNT value, starting a byte number counter of the data packet, sending the data packet carrying SN when the value of the byte number counter of the data packet is less than or equal to S, adding the byte number of the sent data packet by the byte number counter of the data packet when sending a data packet carrying SN, and sending the data packet carrying the COUNT value again after the value of the byte number counter of the data packet is greater than S, wherein S is an integer greater than 1;

after sending the first or the last data packet in the N data packets carrying the COUNT value, starting a byte number counter of the data packets, sending the data packets carrying SN when the value of the byte number counter of the data packets is less than or equal to S, adding the byte number of the sent data packets by the byte number counter of the data packets when sending one data packet carrying SN, and sending the N data packets carrying the COUNT value again after the value of the byte number counter of the data packets is greater than S;

the N data packets carrying the COUNT value satisfy any one of the following conditions:

the N data packets carrying the COUNT value are continuous N data packets;

In a specific embodiment, before sending the COUNT value of the data packet to the receiving-end user equipment, the method further includes:

receiving the COUNT value request of the receiving end user equipment, wherein after receiving the COUNT value request of the receiving end user equipment, the sending end user equipment can know that the receiving end user equipment can accurately synchronize the state variable only by using the COUNT value, and then sends the COUNT value to the receiving end user equipment.

The above embodiment sends the HFN to the receiving end user equipment through the header of the data packet, and further, may send the HFN of the data packet through the control protocol data unit PDU of the packet data convergence protocol PDCP layer. Wherein, the control PDU and the data packet are independent.

Wherein, a header field of the control PDU carries second indication information for indicating that the control PDU carries the HFN.

In order to avoid the situation that the receiving end cannot synchronize the HFN due to only sending one control PDU carrying the HFN being lost, the sending end UE may send N consecutive control PDUs carrying the HFN to the receiving end UE, in an embodiment, the N control PDUs carrying the HFN are sent to the receiving end UE, where the N control PDUs carrying the HFN satisfy any one of the following conditions:

including one said control PDU in each media access control, MAC, transport block, TB;

in the N control PDUs carrying HFN, the adjacent control PDUs are separated by a set number of data PDUs;

in the N control PDUs carrying HFN, the adjacent control PDUs are separated by the byte number of the data PDU with the preset number;

and in the N control PDUs carrying the HFN, the interval between adjacent control PDUs is set time length.

Considering that N consecutive control PDUs may be concatenated in one transport block and transmitted simultaneously, and there is a possibility that N consecutive control PDUs carrying HFN are lost simultaneously, a manner of repeatedly transmitting the control PDUs carrying HFN at a certain interval, a certain number of data packets, or a number of bytes of transmitted SDUs may also be adopted.

In a specific embodiment, the method further comprises any one of:

after sending control PDU carrying HFN, starting a COUNT value periodic sending timer, and after the COUNT value periodic sending timer is overtime, sending the control PDU carrying HFN again;

after sending the first or the last control PDU in N control PDUs carrying HFN, starting a COUNT value periodic sending timer, and after the COUNT value periodic sending timer is overtime, sending N control PDUs carrying HFN again, wherein N is an integer greater than 1;

after sending control PDU carrying HFN, starting a data packet counter, adding 1 to the value of the data packet counter when sending a data packet carrying SN, and sending the control PDU carrying HFN again after the value of the data packet counter is greater than M, wherein M is an integer greater than 1;

after the first or the last control PDU in the N control PDUs carrying HFN is sent, starting a data packet counter, adding 1 to the value of the data packet counter when sending a data packet carrying SN, and sending the N control PDUs carrying HFN again after the value of the data packet counter is larger than M;

after sending control PDU carrying HFN, starting a data packet byte number counter, adding the byte number of the sent data packet by the data packet byte number counter when sending a data packet carrying SN, and sending the control PDU carrying HFN again after the value of the data packet byte number counter is greater than S, wherein S is an integer greater than 1;

after the first or the last control PDU in the N control PDUs carrying HFN is sent, starting a data packet byte number counter, adding the byte number of the sent data packet to the data packet byte number counter when a data packet carrying SN is sent, and sending the N control PDUs carrying HFN again after the value of the data packet byte number counter is greater than S;

the N control PDUs carrying HFNs satisfy any one of the following:

the N control PDUs carrying HFN are continuous N control PDUs;

Specifically, the control PDU is bound with a corresponding data packet for transmission, and the HFN of the corresponding data packet is the HFN carried by the control PDU, so that the HFN in the control PDU and the SN in the data packet can accurately synthesize a COUNT value, which is convenient for the UE at the receiving end to determine and process.

In a specific embodiment, the method further comprises:

before the sending state variable TX _ NEXT is updated by HFN, the higher layer entity is informed to carry out the reconstruction of the load or PDCP entity.

In a specific embodiment, the method further comprises:

the higher layer entity performs PDCP reconstruction and/or reconfiguration through at least one of the following modes:

updating the security key;

updating the algorithm;

and updating the mode of the bearing identification.

In this embodiment, the COUNT synchronization between the receiving end and the sending end can be completed only by changing the UE at the sending end, which can reduce the implementation difficulty.

An embodiment of the present invention further provides a state variable maintenance method, which is applied to a receiving-end user equipment in a sidelink, and as shown in fig. 4, the method includes any one of the following steps:

step 201: receiving a Hyper Frame Number (HFN) and a Sequence Number (SN) of a data packet of user equipment at a sending end;

step 202: and receiving the SN of the data packet of the user equipment at the sending end.

In this embodiment, the sending-end user equipment in the secondary link may send the HFN and the SN of the data packet to the receiving-end user equipment, or send the SN of the data packet to the receiving-end user equipment, so that the user equipment at both ends of the secondary link can accurately synchronize the state variables, thereby performing correct receiving processing.

Optionally, the method further comprises any one of:

maintaining a state variable according to a COUNT value composed of the HFN and the SN;

and maintaining state variables according to the SN.

After receiving the hyper frame number HFN and the sequence number SN of the data packet of the sending-end user equipment, the receiving-end user equipment may maintain a state variable according to a COUNT value composed of the HFN and the SN; after receiving the SN of the data packet of the sending-end user equipment, the receiving-end user equipment may maintain the state variable according to the SN.

Optionally, the method specifically includes setting an initial value of a reception state variable according to a COUNT value or an SN of the received first packet, where the method includes any one of:

when the first data packet carries the COUNT value, setting the initial value of RX _ NEXT as the COUNT value of the first data packet plus 1;

when a first data packet carries a COUNT value and the COUNT value is larger than half the size of a receiving window, setting the initial value of RX _ DELIV to be the COUNT value of the first data packet minus the half the size of the receiving window, and when the COUNT value is smaller than or equal to the half the size of the receiving window, setting the initial value of RX _ DELIV to be 0;

when a first data packet only carries SN, an SN part and an HFN part are utilized to form RX _ NEXT, the value of the SN part is that the SN of the first data packet is added with 1, and the value of the HFN part is all 0;

when the first data packet only carries SN, the SN is converted into a corresponding COUNT value, the relation between the COUNT value and half of the size of a receiving window is judged, if the COUNT value is larger than the half of the size of the receiving window, the initial value of RX _ DELIV is set to be the value obtained by subtracting the half of the size of the receiving window from the COUNT value of the first data packet, and when the COUNT value is smaller than or equal to the half of the size of the receiving window, the initial value of RX _ DELIV is set to be 0.

Optionally, after setting the initial value of the receiving state variable, the method further includes:

and judging whether the data packet is synchronous with the user equipment at the sending end or not according to the COUNT value or the HFN of the data packet.

Optionally, the determining, according to the COUNT value of the data packet, whether to synchronize with the sending-end user equipment includes:

judging whether the COUNT value is positioned in a receiving window, if so, judging that the COUNT value is synchronous with user equipment at a sending end; if the COUNT value is outside the receiving window, judging that the user equipment at the sending end is out of step, resetting the user equipment at the receiving end, and setting the initial value of the receiving state variable by taking the COUNT value as the COUNT value of the first data packet.

Optionally, the determining, according to the HFN of the data packet, whether to synchronize with the sending-end user equipment includes:

judging whether the HFN is positioned in a receiving window, if so, judging that the HFN is synchronous with the user equipment at the sending end; if the HFN is positioned outside the receiving window, judging that the HFN is out of synchronization with the user equipment at the sending end, and executing any one of the following operations:

resetting the receiving end user equipment;

after the control PDU carrying the HFN is determined to be received, the SN of the first received data PDU and the HFN carried in the previous control PDU form a COUNT value together, and the COUNT value is used as the COUNT value of the first data packet to set the initial value of the receiving state variable;

the HFN portion of the RX _ NEXT variable is replaced with the received HFN, and the HFN of the COUNT value of all packets within the boundary of the receive window is replaced with the received HFN.

The state variable maintenance method of the present invention is further described below with reference to specific embodiments:

example one

Since the V2X service has multicast and broadcast scenarios, in these two types of transmission, it is likely that the receiving UE will not receive the service data continuously from the beginning of the service, but join the reception from the middle. In this case, the UE that joins later will cause the HFN at both ends of transceiving to be out of synchronization if the number of missed packets is large enough to exceed the size of the PDCP SN space. This is generally not the case with V2X unicast, mainly because unicast is generally a one-to-one connection and the connection between the receiving UE and the sending UE is maintained stably.

The COUNT value of the data packet is directly transmitted to the receiving end user equipment from the transmitting end user equipment through data packet carrying, and the problem that the receiving state of the transmitting and receiving end is not synchronous can be directly solved. But each COUNT value is 32 bits long, and carrying the COUNT value by a packet will cause a large overhead. Therefore, in some unnecessary scenarios (such as the scenario that the receiving status synchronization can be achieved according to the SN), the COUNT value may not be carried in the data packet, but only the SN is carried. Thus, two packet formats have emerged: one is that the data packet header carries SN, and the other is that the data packet header carries a COUNT value, and the two data packet formats are distinguished using a first indication information of 1bit of the data packet header to indicate that SN or a COUNT value is carried in the packet header of the data packet.

The length of the SN is determined by a signaling configuration or a default configuration mode. For example, if the sending-end UE and the receiving-end UE can support a PC5 Radio Resource Control (RRC) configuration signaling process, the sending-end UE and the receiving-end UE may perform configuration and negotiation with respect to the SN length, and finally determine an SN length, such as 12bit, 16bit, or 18bit, and may also perform negotiation and configuration with respect to whether an air interface transmission COUNT value is supported between the sending-end UE and the receiving-end UE, and after the SN length and the COUNT transmission function are configured, the sending-end UE and the receiving-end UE start to operate according to the configuration.

If the PC5RRC configuration signaling procedure is not supported between the sending UE and the receiving UE, the sending UE and the receiving UE may determine the SN length by means of pre-configuration, protocol specification, or default, for example, selecting one of 12 bits, 16 bits, or 18 bits, and may also adopt a pre-configuration, protocol specification, or default manner if the sending UE and the receiving UE support the air interface transmission COUNT value.

When the sending end UE and the receiving end UE support the sending of the SN and COUNT values simultaneously in the air interface, the sending end UE may determine that the SN or COUNT value is carried in the data packet according to the following rules:

for the sending end UE, after the PDCP entity is initially established, the COUNT value of the sending variable is initialized to 0, the SN initialization value corresponding to the COUNT value is also 0, and the HFN is also 0, and starting from the first data packet, the SN of each data packet is sequentially added with 1, so that from the first data packet after initialization, when the SN space maximum value is accumulated for the first time (taking the SN length of 12 bits as an example, when the SN increases from 0 to 4095), the HFNs of the data packets are all 0, and these data packets are all initialized with HFN value 0, so that the sending end UE only needs to carry the SN value in the data packets when sending these data packets;

when the HFN corresponding to the data packet sent by the sending end UE is updated, for example, the HFN changes from 0- >1 or 1- >2, the sending end UE needs to start sending the COUNT value, that is, the air interface data packet does not carry SN any more but carries the COUNT value, so as to synchronize and update the HFN information of the receiving end at the same time.

Further, in order to avoid the situation that the receiving end cannot synchronize the HFN due to only sending one data packet carrying the COUNT value being lost, the sending end UE may send N consecutive data packets carrying the COUNT value to the receiving end UE, where N is an integer greater than 1, so as to improve the reliability of synchronization. For example, when HFN is updated from 0 to 1, the sending UE carries COUNT value in 10 consecutive packets, SN of the 10 packets increases from 0 to 9, and HFN is 1, and the COUNT value formed by combining SN and HFN is sent to the receiving UE, so that the receiving UE can better synchronize the COUNT value and HFN at both ends.

Considering that N consecutive data packets may be concatenated in a transport block and transmitted simultaneously, and there is a possibility that N consecutive data packets carrying the COUNT value are lost simultaneously, it is also possible to adopt a method of repeating transmission of data packets carrying the COUNT value after a certain number of data packets or the number of bytes of the transmitted SDU are separated, for example, when HFN is updated from 0 to 1, 5 data packets carrying the COUNT value are separated, SN is 0, 20, 40, 60, 80 (corresponding to the certain number of data packets separated), or SN is 0, 5, 18, 29, 41 (corresponding to the certain number of bytes of SDU separated, i.e. the accumulated SDUs among the data packets of 0-5, 5-18, 18-29, 29-41, etc. satisfy a preset threshold), and HFN of these data packets are all 1, and these data packets SN and HFN are combined into the COUNT value, the method and the device are all sent to the receiving end UE, the COUNT value and the HFN of the sending end UE and the receiving end UE can be synchronized, and the reliability of synchronization is improved.

When the HFN is not 0, the sending-end UE may also send a plurality of packets carrying the COUNT value at regular intervals, so as to inform the receiving-end UE of the current HFN value, which is added later, in a manner including any of the following:

based on a periodic timer approach: after the first HFN update (when HFN is from 0- > 1), the first sending process of the COUNT value is started, then the periodic sending timer of the COUNT value can be started after the first sending of the COUNT value, the sending of the COUNT value is performed again each time the periodic sending timer of the COUNT value is overtime, and after the sending of the COUNT value is performed again, the periodic sending timer of the COUNT value is restarted to wait for the next sending of the COUNT value;

if the sending end UE continuously generates N COUNT values, the timer for periodically sending the COUNT values can be started or restarted after the Nth COUNT value is sent; in the process that the COUNT value periodic sending timer continuously runs, the UE at the sending end only carries SN in the data packet; of course, it is also possible to start the COUNT value periodic transmission timer after the first COUNT value of the N COUNT values is sent out every time, until the next time the COUNT value periodic transmission timer times out, which is equivalent to calculating the time for sending the remaining N-1 COUNT values in the timing of the COUNT value periodic transmission timer;

based on the way of the COUNT _ Counter (i.e. the packet Counter), when HFN is updated for the first time (HFN is from 0- > 1), the transmission process of the first COUNT value is started, so that after the first transmission of the COUNT value, the Counter COUNT _ Counter for the transmitted packet (with an initial value of 0) can be started, and after each transmission of a packet COUNT _ Counter +1 carrying only SN, when the COUNT _ Counter is accumulated to the threshold M, the transmission of the COUNT value is started again, and after the retransmission of the COUNT value, the Counter COUNT _ Counter for the transmitted packet (with an initial value of 0) is restarted, and each transmission of a packet COUNT _ Counter +1 carrying only SN, the Counter reaches the threshold and the next transmission of the COUNT value is waited;

if the sending end UE continuously generates N COUNT values, the COUNT _ Counter may be started or restarted after the nth COUNT value is sent; in the process of continuously running the COUNT _ Counter Counter, the UE at the sending end only carries SN in the data packet; of course, it is also possible to start the COUNT _ Counter each time after the first COUNT value is sent out, until the threshold is met next time, and the number of packets corresponding to the remaining N-1 COUNT values sent is also counted in the COUNT of the COUNT _ Counter;

based on the SDU _ Byte _ Counter (i.e. the above-mentioned packet Byte Counter), when HFN is updated for the first time (HFN is from 0- > 1), the sending process of the first COUNT value is started, then after the first COUNT value is sent, the Counter SDU _ Byte _ Counter (initial value is 0) for the number of bytes of the sent packet may be started, when the SDU _ Byte _ Counter value + the number of bytes of the current packet is sent, and when the SDU _ Byte _ Counter value is accumulated to the threshold S, the sending of the COUNT value is started again, and after the COUNT value is sent again, the Counter SDU _ Byte _ Counter (initial value is 0) for the number of bytes of the sent packet is restarted, and when the SDU _ Byte _ Counter value + the number of bytes of the current packet is sent, the SDU _ Byte _ Counter reaches the next sending COUNT value;

if the sending end UE continuously generates N COUNT values, the SDU _ Byte _ Counter may be started or restarted after the nth COUNT value is sent; in the process of continuously operating the SDU _ Byte _ Counter, the sending end UE only carries SN in the data packet; of course, it is also possible to start the SDU _ Byte _ Counter after the first COUNT value is sent out every time until the threshold is met next time, which is equivalent to counting the number of bytes of data packets sent by the remaining N-1 COUNT values in the COUNT of the SDU _ Byte _ Counter;

the above-mentioned modes of the period timer and the counter may be used simultaneously, or may be used in cooperation with the sending of the COUNT value triggered by other modes, for example, the sending end HFN updates, which is equivalent to that the counter reaches a threshold or the period timer times out or any one of other triggers is satisfied, the sending of the COUNT value may be started, and once the COUNT value is sent, the counter or the timer is cleared, and meanwhile, the range of the counter or the timer may include the sending of subsequent continuous N-1 COUNT values, or may not include the sending of subsequent continuous N-1 COUNT values.

The above-described trigger scheme is also applicable to a scheme of transmitting N COUNT values at intervals.

When the sending end UE knows that there is a new added receiving end UE and the sending end HFN is not equal to the initial value 0 at this time, the sending end UE may start the COUNT value sending.

In addition, when the receiving end UE performs feedback to request to synchronize the COUNT value or report some errors, the sending end UE may also be triggered to start sending the COUNT value, for example, the receiving end UE finds some errors during the security releasing operation, such as failure of integrity verification, and the receiving end UE may report the errors to the sending end UE, and at this time, the sending end UE first considers that HFN desynchronization occurs, so that sending of the COUNT value is started.

After the sending end UE can simultaneously support the data packet formats sent by the SN and the COUNT value, the sending end UE determines which times to send the data packets carrying the SN and which times to send the data packets carrying the COUNT value according to the rules, and performs different assignments on the packet format indication information (i.e., the first indication information) according to different data formats when sending different types of data packets, for example, an indication field including 1bit in the packet header, when the value of the 1bit field is 0, indicates that the SN is carried in the packet header of the data packet, and when the value of the 1bit field is 1, indicates that the packet header of the data packet carries the COUNT value.

For the low-version or low-capability UE, the indication field of 1bit may be defined through a protocol, so that the low-version or low-capability UE only interprets the data packet whose value of the 1bit field is 0, and when the value of the 1bit field of the data packet is not 0, the entire data packet may be directly deleted.

Example two

If the format of the data packet is changed, the data packet carries the COUNT value, which may cause the compatibility problem of the low-version or different-capability UE, so that the HFN can be carried by the control PDU independent of the data packet, and the HFN carried by the control PDU and the SN carried by the data packet form the COUNT value of the data packet, so that the UE at the receiving end knows the COUNT value of the data packet, thereby realizing the synchronization of the COUNT values at the transmitting and receiving ends.

In this embodiment, when the sending-end UE needs to send the COUNT value, the COUNT value is not carried in a data packet, but a separate control PDU is organized, and the control PDU is used to carry the HFN, and the PDU belongs to the format of the control PDU, so that the D/C field of the data packet header is set to the control value instead of the data value, which represents that the PDU is a control PDU, and then the sending-end UE indicates that the PDU is a control PDU of the sending HFN type in the header field of the control PDU, for example, an Rbit is used, or the value of the extended PDU type field is used. Table 1 shows the existing PDU type values:

TABLE 1 existing PDU type

Table 2 shows PDU type values after the extension of this embodiment:

TABLE 2 extended PDU type

Bit	Description
			000	PDCP status report
001	Interspersed ROHC feedback
		010	HFN
011-111	Reserved

In a specific example, a packet format of a control PDU carrying HFN information is shown in table 3:

TABLE 3

The type of the control PDU, that is, whether the control PDU is a control PDU carrying HFN, may be indicated by an R/H field, or may be indicated by different values of PDU type. As shown in table 3, if the configured SN length is 12 bits, the remaining HFN has a length of 20 bits, and if the configured SN length changes, the HFN length may also change accordingly.

The triggering method for triggering the packet carrying the COUNT value as described in the first embodiment may be used to trigger the transmission of the control PDU carrying the HFN. However, since the control PDU is an independent packet type and is different from the packet type, when transmitting the control PDU carrying HFN, there is only one packet type, i.e. only the packet carrying SN, and there is no packet carrying the COUNT value, so that when counting by the packet counter, it is not necessary to distinguish the packet type, and the value of the packet counter is increased by 1 every time a packet is transmitted.

Specifically, after each control PDU carrying HFN is sent, the period timer may be started or restarted, and after the period timer is over, a control PDU carrying HFN is sent again; or, after each control PDU carrying HFN is sent, the packet counter may be cleared to start counting, and after the packet counter exceeds M, a control PDU carrying HFN is sent again, where M is an integer greater than 1.

In order to ensure that the control PDU carrying HFN can be received correctly, N control PDUs carrying HFN may be transmitted continuously, and preferably, the N control PDUs carrying HFN are not transmitted continuously, so as to avoid that MAC layer packets are transmitted in one transport block, and once the MAC layer packets are lost, the N control PDUs carrying HFN are transmitted in a manner that:

if the inter-layer interaction can be carried out with a Media Access Control (MAC)/radio link layer control protocol (RLC) layer, one control PDU carrying HFN can be sent every time MAC group package is carried out, and the control PDU is continuously sent for N times so as to ensure separate sending and avoid that N control PDUs carrying HFN are sent all unsuccessfully;

or sending a control PDU carrying HFN at a certain data PDU number interval, and continuously sending N times;

or sending a control PDU carrying HFN at a certain data PDU byte number interval, and continuously sending N times;

or sending a control PDU carrying HFN at a certain time interval, and continuously sending N times.

In addition, control PDU transmission with HFN may be triggered N times in any of the following ways:

when sending N control PDUs carrying HFN, only the first control PDU can cause the resetting of a period timer and a data packet counter, once the first control PDU is sent, the PDCP can restart the related period timer or clear the related data packet counter to restart counting; the subsequent transmission of N-1 control PDUs does not influence the operation of a period timer or a data packet counter;

resetting of a period timer and a data packet counter is caused every time a control PDU is sent, once the control PDU carrying the HFN is sent, the PDCP can restart the related period timer or clear the related data packet counter to restart counting; if the transmission is carried out for N times, N times of restarting or resetting can be triggered;

optionally, the control PDU carrying the HFN is bound with at least one data packet for transmission, so that the HFN in the control PDU and the SN in the data packet can accurately synthesize a COUNT value, which is convenient for the UE at the receiving end to judge and process; if a plurality of data packets are transmitted together with the control PDU carrying the HFN, it is necessary to ensure that the HFN corresponding to the data packets is equal to the HFN value in the control PDU, or in the data packets sequentially sent to the bottom layer, the HFN value corresponding to the data packet next to the control PDU should be equal to the HFN value in the control PDU.

It is noted that for the transmitting UE, the transmitted HFN is the HFN value corresponding to the current TX _ NEXT variable.

EXAMPLE III

If there is a connection establishment and/or bearer establishment and/or PDCP entity establishment procedure between the receiving end UE and the sending end UE, it is equivalent to that based on the procedure, the sending end UE and the receiving end UE establish a PDCP entity. Then, the sending end UE sets all the sending state variables corresponding to the PDCP entity to initial values, which is specifically as follows:

TX _ NEXT: this variable indicates the COUNT value corresponding to the next transmitted PDCP SDU. The initial value is 0. Generally, every packet is sent, the value of the variable is incremented by 1.

For the receiving end UE, at this time, the receiving variable corresponding to the PDCP entity is set as an initial value, which is specifically as follows:

RX _ NEXT: this variable indicates the COUNT value corresponding to the next expected PDCP SDU, and the initial value is 0. When a data packet with the COUNT value of n is received, the value of the variable is added with 1 to be changed into n +1, which indicates that the next PDCP SDU with the COUNT value of n +1 is expected to be received;

RX _ DELIV: this variable indicates the COUNT value corresponding to the first PDCP SDU not delivered to the higher layer, and the initial value is 0. This variable acts as a lower boundary of the receive window, for example, when the receive side receives packets with COUNT values 0-5, 7, 9, where 0-5 are delivered to higher layers because they are received sequentially, and RX _ DELIV is 6.

If there is no connection establishment, bearer establishment, or PDCP entity establishment procedure between the sending UE and the receiving UE, for example, in a broadcast or multicast scenario, the feasible procedure is as follows:

the UE at the sending end needs to send service data, establishes a bearer and a PDCP entity, and normally starts to send data packets after the initialization is completed;

only when receiving the first service data, the receiving end UE establishes a corresponding receiving entity, such as a PDCP entity, and it is likely that the receiving end UE starts receiving from the middle of the service, so the receiving end UE is not suitable for setting the receiving state variable of the PDCP to the initial value, and needs to set the initial value of its receiving state variable according to the SN of the received first data packet, which is specifically as follows:

if the received first data packet carries the COUNT value, directly setting the initial value of RX _ NEXT as the COUNT value +1 of the first data packet;

if the first packet received carries a COUNT value, then if the COUNT value is greater than half the size of the receive window (the receive window is defined as half the SN space, e.g. 4096 when the SN is 12 bits and 2048 when half the receive window is 1024), the initial value RX _ DELIV is equal to the COUNT value of the first packet minus half the size of the receive window, and when the COUNT value is less than or equal to half the size of the receive window, the initial value RX _ DELIV is 0;

if the first data packet carries SN value, RX _ NEXT is formed by combining two parts, wherein the value of the low SN _ Length bit is SN value +1 of the first data packet, and the value of the high 32-SN _ Length bit is all zero. For example, when the SN field length is 12 bits, that is, the SN effective range is [0,4095], if the received first packet SN is 32 (for convenience of illustration, decimal), the low 12 bits of RX _ NEXT are 32+1 ═ 33, and the high 20 bits of RX _ NEXT are all zeros, which is equivalent to RX _ NEXT ═ 33, but RX _ NEXT itself is a binary number of 32 bits;

if the SN value is carried in the first packet, it is first converted into a corresponding COUNT value, by way of zero padding for all high bits, for example, when the SN field length is 12 bits, i.e. the SN valid range is [0,4095], and if the SN of the received first packet is 32 (for convenience of description, taking decimal), its corresponding COUNT value is 32 for 12 low bits, and all high bits are 20 zero, which is equivalent to the COUNT value being 32. Then, judging the relation between the COUNT value and half size of the receiving window, if the COUNT value is larger than half size of the receiving window, the RX _ DELIV initial value is equal to the COUNT value of the first data packet minus half size of the receiving window, and when the COUNT value is smaller than or equal to half size of the receiving window, the RX _ DELIV initial value is 0;

and after the initialization is finished, the receiving end UE receives data according to a normal flow.

If the receiving end UE receives a data packet carrying a COUNT value or a control PDU carrying an HFN after initializing the receiving state variable, the feasible processing flow is as follows:

firstly, the receiving end judges whether the two ends of the sending end and the receiving end are synchronous according to the received COUNT value or HFN value, and judges whether the COUNT values at the two ends are synchronous, wherein the judging method comprises the following steps:

if the received value is the COUNT value, judging whether the COUNT value is in a receiving window, wherein the receiving window is defined as: the current RX _ DELIV is the lower receive window boundary and the upper receive window boundary is RX _ DELIV plus the receive window size (the receive window is defined as half of the SN space, e.g. 4096 when SN is 12 bits and 2048), if RX _ DELIV < > is satisfied as receive COUNT < RX _ DELIV + receive window size, then the receive COUNT value is within the current receive window, otherwise outside the current receive window;

if the COUNT value is located in the receiving window, the COUNT value and the HFN at the two ends of the sending end and the receiving end are considered to be synchronous, and at the moment, the data packet carrying the COUNT value is processed according to the normal received data packet;

if the COUNT value is outside the receiving window, the COUNT value and the HFN at the two ends of the transmitting end and the receiving end are considered to be out of step, at this time, the receiving end is all reset, the received COUNT value is taken as the COUNT value of the first received data packet, and the operation of initializing the variable of the receiving end is executed again.

Or, the receiving end UE may further determine whether the HFNs at the two ends are synchronized according to the received HFN value, where the determining method is as follows:

judging whether the received HFN value is in a receiving window or not, wherein the receiving window is defined as above, taking the HFN value corresponding to the upper boundary of the receiving window as x, taking the HFN value of the lower boundary of the current receiving window as y, and when the HFN value is obtained, only the COUNT value corresponding to the boundary of the receiving window needs to be directly removed, namely the lower bit of the SN length is directly removed, generally, x > is equal to y, and according to the definition of the receiving window, the HFN value is only half of the SN space, so that x and y are equal or have 1 difference, other possibilities cannot occur, at the moment, if the received HFN value is equal to any one value of x and y, the HFN is judged to be synchronous, otherwise, the HFN is judged to be out of step;

if the HFN is synchronous, ignoring the control PDU carrying the HFN, and normally receiving the data;

if the HFN is out of sync, then a resynchronization is needed, either:

resetting the receiving end;

after selecting to receive the control PDU carrying HFN, the SN of the first received data PDU (preferably, if the first data PDU is sent in a MAC PDU bound with the control PDU), and the SN and the HFN carried in the previous control PDU jointly form a COUNT value, and the COUNT value is taken as the COUNT value of the first received data packet, and the operation of initializing the receiving end variable is executed again;

the receiver is not reset, but the receiving variable and the received data are reconstructed by replacing the HFN part of the RX _ NEXT variable with the received HFN, and the corresponding lower and upper bounds of the receive window and the COUNT value of all received packets need to be updated and calculated accordingly. The updating method comprises the following steps: if the HFN part of the COUNT value of the previous data and boundary is equal to the HFN part of the COUNT value of the previous RX _ NEXT variable, the HFN part of the new COUNT value is also updated to the newly received HFN, and if not equal, the original gap is guaranteed to be the same as the gap after the update. For example, if HFN is 3 and HFN corresponding to the original RX _ NEXT variable is 0 (for example, immediately after initialization), SN of RX _ NEXT variable after update is partially unchanged, HFN is partially changed to 3 directly, and the rest of relevant boundaries and data are updated, HFN is partially updated to 3 uniformly if HFN is 0, and if some data, for example, the original HFN of reception window upper boundary is already 1, HFN of reception window upper boundary is updated to 4 in order to ensure that the difference between the original HFN and RX _ NEXT variable before and after update is unchanged.

Example four

The above embodiments all require updating the data format and the behavior at both the transmitting and receiving ends, with a certain complexity. In order to reduce the complexity of the operation, the sending UE may perform some active avoidance processing in case of loss of synchronization of COUNT or loss of synchronization of HFN.

In a specific example, when the sending end UE finds its own sending state variable TX _ NEXT, that is, an update of the HFN part is about to occur, the sending end UE notifies a higher layer to perform bearer or PDCP entity reestablishment. For example, because the initial value of TX _ NEXT is 0, meaning that its HFN initial value is also 0, all the intermediately-added receiving UEs, corresponding to this, can only default to 0 for their initial values of the state variable RX _ NEXT, as well as their HFN portions.

When the HFN of TX _ NEXT at the transmitting end is to be updated from 0 to 1, that is, the transmission is resumed, only from the UE that has been initialized or is already receiving, based on the existing historical reception information and the reception window operation, the HFN part of RX _ NEXT can be correctly resolved, and for any newly joined UE, HFN out-of-sync and COUNT out-of-sync must occur when the HFN part of the COUNT value of the first packet received by the UE is actually equal to 1. In this case, in order to avoid the UE that joins later to lose synchronization, the UE PDCP layer is sent to request the higher layer to request bearer or PDCP re-establishment, and the re-establishment method includes any one of the following:

the high layer can change destination ID (destination identification) and/or source ID (source identification), because the high layer also has a mechanism for preventing tracking of service, the ID of the high layer can be updated periodically, and then the HFN is updated and added as one of the trigger conditions;

or else, destination ID and/or source ID are/is not changed, but the higher layer selects to update the bearer or the PDCP entity, namely updating the bearer ID, and reconstructing a new PDCP entity;

in the above manner, the main purpose is to update at least one parameter of the key 5 parameters of the security input, so that the PDCP entity can start to reuse the transmission COUNT value and the SN value with HFN of 0, where the 5 input parameters of the security operation include: COUNT value, security key, security algorithm, bearer ID, data transmission direction. Generally, when the destination ID/source ID is changed, the security key and/or security algorithm may be changed, and the bearer ID may also be changed based on the bearer or PDCP entity update, so that the same COUNT value may be reused when the two types of changes are changed.

For example, if the PDCP SN is 12 bits, the packet COUNT value range corresponding to HFN ═ 0 is 0 to 4095, when the sending end has sent the packet with COUNT ═ 4095, or a bit ahead of time, some margin is given, for example, the sending end has sent the packet with COUNT ═ 4085, the sending end requests the PDCP to the higher layer for PDCP re-establishment, the higher layer performs PDCP re-establishment or reconfiguration by updating the security key and/or algorithm and/or bearer ID, and at this time, the PDCP may reuse the packet COUNT value range of 0 to 4095. For the receiving end, as any one of the destination ID, the source ID and the bearer ID is changed, the receiving end will newly establish a brand new PDCP entity for receiving data, so that the problem of possible desynchronization of HFN and COUNT is well solved, and the data can be well and correctly received for the UE which is continuously received and the UE which is added later.

In this embodiment, the COUNT synchronization between the receiving end and the transmitting end can be completed only by changing the UE at the transmitting end.

An embodiment of the present invention further provides a state variable maintenance apparatus, which is applied to a sending-end user equipment 300 in a sidelink, and as shown in fig. 5, the state variable maintenance apparatus includes:

a sending module 310, configured to perform any one of the following operations:

and sending the SN of the data packet to the receiving end user equipment.

Since the sending-end user equipment may send HFN and SN to the receiving-end user equipment, and may also send SN to the receiving-end equipment, the data packet also needs to carry first indication information to indicate that SN or a COUNT value is carried in a packet header of the data packet, where the COUNT value includes SN and HFN.

In a specific embodiment, the sending module 310 is specifically configured to send, to the receiving-end user equipment, N data packets carrying COUNT values, where N is an integer greater than 1, and the N data packets carrying COUNT values satisfy any of the following:

the N data packets carrying the COUNT value are continuous N data packets;

In an embodiment, when the HFN of the data packet is not 0, the sending module 310 is further configured to perform any one of the following:

after sending a data packet carrying a COUNT value, starting a COUNT value periodic sending timer, sending a data packet carrying an SN before the COUNT value periodic sending timer is overtime, and sending the data packet carrying the COUNT value again after the COUNT value periodic sending timer is overtime;

the N data packets carrying the COUNT value are continuous N data packets;

In a specific embodiment, the apparatus further comprises:

a receiving module, configured to receive the COUNT value request of the receiving-end ue, where after the COUNT value request of the receiving-end ue is received, the sending-end ue can know that the receiving-end ue needs to use the COUNT value to accurately synchronize the state variables, and then send the COUNT value to the receiving-end ue.

The foregoing embodiment transmits the HFN to the receiving end user equipment through the header of the data packet, and further, the transmitting module 310 is further configured to transmit the HFN of the data packet through a packet data convergence protocol PDCP control protocol data unit PDU. Wherein, the control PDU and the data packet are independent.

In an embodiment, the sending module 310 sends, to the receiving-end user equipment, N control PDUs carrying HFN, where the N control PDUs carrying HFN satisfy any one of the following conditions:

In a specific embodiment, the sending module 310 is further configured to perform any one of the following:

the N control PDUs carrying HFNs satisfy any one of the following:

the N control PDUs carrying HFN are continuous N control PDUs;

Specifically, the control PDU is sent in a binding manner with a corresponding data packet, and an HFN of the corresponding data packet is an HFN carried by the control PDU.

In an embodiment, the sending module 310 is further configured to notify a higher layer entity to perform bearer or PDCP entity reestablishment before the HFN is updated when the TX _ NEXT is sent.

In a specific embodiment, the higher layer entity performs PDCP re-establishment and/or reconfiguration in at least one of the following manners:

updating the security key;

updating the algorithm;

and updating the mode of the bearing identification.

An embodiment of the present invention further provides a state variable maintenance apparatus, which is applied to a receiving-end user equipment 400 in a sidelink, as shown in fig. 6, and includes:

a receiving module 420, configured to perform any one of the following operations:

Optionally, the apparatus further comprises a processing module configured to perform any one of the following operations:

and maintaining state variables according to the SN.

Optionally, the processing module is specifically configured to set an initial value of a receiving state variable according to a COUNT value or an SN of the received first data packet, where the initial value includes any one of:

Optionally, the apparatus further comprises:

and the judging module is used for judging whether the data packet is synchronous with the user equipment at the sending end according to the COUNT value or the HFN of the data packet.

Optionally, the determining module is specifically configured to determine whether the COUNT value is located within a receiving window, and if the COUNT value is located within the receiving window, determine that the COUNT value is synchronized with the sending-end user equipment; if the COUNT value is outside the receiving window, judging that the user equipment at the sending end is out of step, resetting the user equipment at the receiving end, and setting the initial value of the receiving state variable by taking the COUNT value as the COUNT value of the first data packet.

Optionally, the determining module is specifically configured to determine whether the HFN is located within a receiving window, and if the HFN is located within the receiving window, determine that the HFN is synchronized with the sending-end user equipment; if the HFN is positioned outside the receiving window, judging that the HFN is out of synchronization with the user equipment at the sending end, and executing any one of the following operations:

resetting the receiving end user equipment;

To better achieve the above object, further, fig. 7 is a schematic diagram of a hardware structure of a user equipment implementing various embodiments of the present invention, and the user equipment can implement various processes of the foregoing state variable maintenance method embodiment and can achieve the same technical effect. The user equipment 40 includes but is not limited to: radio frequency unit 41, network module 42, audio output unit 43, input unit 44, sensor 45, display unit 46, user input unit 47, interface unit 48, memory 49, processor 410, and power supply 411. Those skilled in the art will appreciate that the user equipment configuration shown in fig. 7 does not constitute a limitation of the user equipment, which may include more or fewer components than shown, or some components may be combined, or a different arrangement of components. In the embodiment of the present invention, the user equipment includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle-mounted terminal, a wearable device, a pedometer, and the like.

When the rf unit 41 is applied to a user equipment at a transmitting end, the HFN and the SN are used to send a Hyper Frame Number (HFN) and a Sequence Number (SN) of a data packet to a user equipment at a receiving end; or the SN of the data packet is sent to the receiving end user equipment. When the rf unit 41 is applied to the ue at the transmitting end, the HFN and the SN are used to receive the hyper frame number HFN and the serial number SN of the data packet of the ue at the transmitting end; or receives the SN of the data packet of the transmitting user equipment.

It should be understood that, in the embodiment of the present invention, the radio frequency unit 41 may be used for receiving and sending signals during a message sending and receiving process or a call process, and specifically, receives downlink data from a base station and then processes the received downlink data to the processor 410; in addition, the uplink data is transmitted to the base station. In general, radio frequency unit 41 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like. In addition, the radio frequency unit 41 can also communicate with a network and other devices through a wireless communication system.

The user device provides wireless broadband internet access to the user via the network module 42, such as to assist the user in emailing, browsing web pages, and accessing streaming media.

The audio output unit 43 may convert audio data received by the radio frequency unit 41 or the network module 42 or stored in the memory 49 into an audio signal and output as sound. Also, the audio output unit 43 may also provide audio output related to a specific function performed by the user equipment 40 (e.g., a call signal reception sound, a message reception sound, etc.). The audio output unit 43 includes a speaker, a buzzer, a receiver, and the like.

The input unit 44 is for receiving an audio or video signal. The input Unit 44 may include a Graphics Processing Unit (GPU) 441 and a microphone 442, and the Graphics processor 441 processes image data of still pictures or videos obtained by an image capturing device (such as a camera) in a video capturing mode or an image capturing mode. The processed image frames may be displayed on the display unit 46. The image frames processed by the graphic processor 441 may be stored in the memory 49 (or other storage medium) or transmitted via the radio frequency unit 41 or the network module 42. The microphone 442 may receive sound and may be capable of processing such sound into audio data. The processed audio data may be converted into a format output transmittable to a mobile communication base station via the radio frequency unit 41 in case of the phone call mode.

The user device 40 also includes at least one sensor 45, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor that adjusts the brightness of the display panel 461 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 461 and/or the backlight when the user device 40 moves to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), detect the magnitude and direction of gravity when stationary, and can be used to identify the user equipment posture (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration identification related functions (such as pedometer, tapping), and the like; the sensors 45 may also include fingerprint sensors, pressure sensors, iris sensors, molecular sensors, gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., which are not described in detail herein.

The display unit 46 is used to display information input by the user or information provided to the user. The Display unit 46 may include a Display panel 461, and the Display panel 461 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like.

The user input unit 47 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the user device. Specifically, the user input unit 47 includes a touch panel 471 and other input devices 472. The touch panel 471, also referred to as a touch screen, may collect touch operations by a user (e.g., operations by a user on or near the touch panel 471 using a finger, a stylus, or any other suitable object or accessory). The touch panel 471 can include two parts, a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 410, receives a command from the processor 410, and executes the command. In addition, the touch panel 471 can be implemented by various types, such as resistive, capacitive, infrared, and surface acoustic wave. The user input unit 47 may include other input devices 472 in addition to the touch panel 471. Specifically, the other input devices 472 may include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a track ball, a mouse, and a joystick, which are not described herein again.

Further, the touch panel 471 can be overlaid on the display panel 461, and when the touch panel 471 detects a touch operation on or near the touch panel 471, the touch panel transmits the touch operation to the processor 410 to determine the type of the touch event, and then the processor 410 provides a corresponding visual output on the display panel 461 according to the type of the touch event. Although in fig. 4, the touch panel 471 and the display panel 461 are implemented as two separate components to implement the input and output functions of the user device, in some embodiments, the touch panel 471 and the display panel 461 may be integrated to implement the input and output functions of the user device, and are not limited herein.

The interface unit 48 is an interface for connecting an external device to the user equipment 40. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having an identification module, an audio input/output (I/O) port, a video I/O port, an earphone port, and the like. The interface unit 48 may be used to receive input from external devices (e.g., data information, power, etc.) and transmit the received input to one or more elements within the user equipment 40 or may be used to transmit data between the user equipment 40 and external devices.

The memory 49 may be used to store software programs as well as various data. The memory 49 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 49 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The processor 410 is a control center of the user equipment, connects various parts of the entire user equipment using various interfaces and lines, performs various functions of the user equipment and processes data by running or executing software programs and/or modules stored in the memory 49 and calling data stored in the memory 49, thereby performing overall monitoring of the user equipment. Processor 410 may include one or more processing units; preferably, the processor 410 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 410.

The user device 40 may further include a power supply 411 (e.g., a battery) for supplying power to various components, and preferably, the power supply 411 may be logically connected to the processor 410 through a power management system, so as to implement functions of managing charging, discharging, and power consumption through the power management system.

In addition, the user equipment 40 includes some functional modules that are not shown, and are not described in detail here.

Preferably, an embodiment of the present invention further provides a user equipment, which includes a processor 410, a memory 49, and a computer program that is stored in the memory 49 and can be run on the processor 410, and when the computer program is executed by the processor 410, the processes of the foregoing state variable maintenance method embodiment are implemented, and the same technical effect can be achieved, and in order to avoid repetition, details are not described here again. The user equipment may be a wireless terminal or a wired terminal, and the wireless terminal may be a device providing voice and/or other service data connectivity to a user, a handheld device having a wireless connection function, or other processing device connected to a wireless modem. Wireless terminals, which may be mobile terminals such as mobile telephones (or "cellular" telephones) and computers having mobile terminals, such as portable, pocket, hand-held, computer-included, or vehicle-mounted mobile devices, may communicate with one or more core networks via a Radio Access Network (RAN), which may exchange language and/or data with the RAN. For example, Personal Communication Service (PCS) phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, Personal Digital Assistants (PDAs), and the like. A wireless Terminal may also be referred to as a system, a Subscriber Unit (Subscriber Unit), a Subscriber Station (Subscriber Station), a Mobile Station (Mobile), a Remote Station (Remote Station), a Remote Terminal (Remote Terminal), an access Terminal (access Terminal), a User Terminal (User Terminal), a User Agent (User Agent), and a User Equipment (User device User Equipment), which are not limited herein.

The embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the computer program implements each process of the foregoing state variable maintenance method embodiment, and can achieve the same technical effect, and in order to avoid repetition, details are not repeated here. The computer-readable storage medium may be a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.

It should be noted that the division of the modules of the network device and the terminal is only a logical division, and the actual implementation may be wholly or partially integrated into one physical entity, or may be physically separated. And these modules can be realized in the form of software called by processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling software by the processing element, and part of the modules can be realized in the form of hardware. For example, the determining module may be a processing element separately set up, or may be implemented by being integrated in a chip of the apparatus, or may be stored in a memory of the apparatus in the form of program code, and the function of the determining module is called and executed by a processing element of the apparatus. Other modules are implemented similarly. In addition, all or part of the modules can be integrated together or can be independently realized. The processing element described herein may be an integrated circuit having signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.

For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as: one or more Application Specific Integrated Circuits (ASICs), or one or more microprocessors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs), etc. For another example, when some of the above modules are implemented in the form of a processing element scheduler code, the processing element may be a general purpose processor, such as a Central Processing Unit (CPU) or other processor that can invoke the program code. As another example, these modules may be integrated together, implemented in the form of a system-on-a-chip (SOC).

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

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

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

Furthermore, it is to be noted that in the device and method of the invention, it is obvious that the individual components or steps can be decomposed and/or recombined. These decompositions and/or recombinations are to be regarded as equivalents of the present invention. Also, the steps of performing the series of processes described above may naturally be performed chronologically in the order described, but need not necessarily be performed chronologically, and some steps may be performed in parallel or independently of each other. It will be understood by those skilled in the art that all or any of the steps or elements of the method and apparatus of the present invention may be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or any combination thereof, which can be implemented by those skilled in the art using their basic programming skills after reading the description of the present invention.

Thus, the objects of the invention may also be achieved by running a program or a set of programs on any computing device. The computing device may be a general purpose device as is well known. The object of the invention is thus also achieved solely by providing a program product comprising program code for implementing the method or the apparatus. That is, such a program product also constitutes the present invention, and a storage medium storing such a program product also constitutes the present invention. It is to be understood that the storage medium may be any known storage medium or any storage medium developed in the future. It is further noted that in the apparatus and method of the present invention, it is apparent that each component or step can be decomposed and/or recombined. These decompositions and/or recombinations are to be regarded as equivalents of the present invention. Also, the steps of executing the series of processes described above may naturally be executed chronologically in the order described, but need not necessarily be executed chronologically. Some steps may be performed in parallel or independently of each other.

While the preferred embodiments of the present invention have been described, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined in the following claims.

Claims

1. A state variable maintenance method is applied to sending end user equipment in a sidelink, and is characterized by comprising any one of the following steps:

and sending the SN of the data packet to the receiving end user equipment.

2. The method according to claim 1, wherein the data packet carries first indication information to indicate that SN or a COUNT value is carried in a header of the data packet, and the COUNT value includes SN and HFN.

3. The state variable maintenance method according to claim 2, wherein the capability of the sending-end user equipment and the receiving-end user equipment to support air interface transmission COUNT value is determined by any one of the following manners: configuring through signaling; pre-configuring; agreement is agreed; default values are used.

4. The state variable maintenance method according to claim 2,

when the HFN of a data packet is the same as the HFN of the previous data packet or the HFN is 0, the packet header of the data packet carries the SN of the data packet;

5. The state variable maintenance method of claim 2, wherein the transmitting the COUNT value of the packet to the receiving-side ue comprises:

the N data packets carrying the COUNT value are continuous N data packets;

6. The state variable maintenance method according to claim 4, wherein when the HFN of the packet is not 0, the method further comprises any one of:

the N data packets carrying the COUNT value are continuous N data packets;

7. The state variable maintenance method of claim 2, wherein before sending the COUNT value of the packet to the receiving-side ue, the method further comprises:

and receiving a COUNT value request of the receiving end user equipment.

8. The state variable maintenance method according to claim 1, wherein the sending HFN and SN of the data packet to the receiving end user equipment comprises:

sending the HFN of the packet via a control Protocol Data Unit (PDU).

9. The method of claim 8, wherein a header field of the control PDU carries second indication information for indicating that the control PDU carries the HFN.

10. The state variable maintenance method according to claim 9,

sending N control PDUs carrying HFN to the receiving end user equipment, wherein the N control PDUs carrying HFN satisfy any one of the following conditions:

11. The state variable maintenance method according to claim 8, characterized in that the method further comprises any of:

the N control PDUs carrying HFNs satisfy any one of the following:

the N control PDUs carrying HFN are continuous N control PDUs;

12. The method of claim 9, wherein the control PDU is sent in a bundle with a corresponding packet, and the HFN of the corresponding packet is the HFN carried by the control PDU.

13. The state variable maintenance method according to claim 1, further comprising:

14. The state variable maintenance method according to claim 13, further comprising:

updating the security key;

updating the algorithm;

and updating the mode of the bearing identification.

15. A state variable maintenance method is applied to receiving end user equipment in a sidelink, and is characterized by comprising any one of the following steps:

16. The state variable maintenance method according to claim 15, further comprising any one of:

and maintaining state variables according to the SN.

17. The method according to claim 16, wherein the method specifically includes setting an initial value of the receiving state variable according to a COUNT value or a SN value of the received first packet, and includes any one of:

18. The state variable maintenance method of claim 17, wherein after setting the initial value of the received state variable, the method further comprises:

19. The state variable maintenance method of claim 18, wherein the determining whether to synchronize with the sending end user equipment according to the COUNT value of the packet comprises:

20. The method of claim 18, wherein determining whether to synchronize with the sending ue according to the HFN of the packet comprises:

resetting the receiving end user equipment;

after the control PDU carrying the HFN is determined to be received, the SN of the first received data PDU and the HFN carried in the previous control PDU jointly form a COUNT value, and the COUNT value is used as the COUNT value of the first data packet to set the initial value of the receiving state variable;

21. A state variable maintenance device is applied to a sending end user equipment in a sidelink, and is characterized by comprising:

a sending module, configured to perform any one of the following operations:

and sending the SN of the data packet to the receiving end user equipment.

22. A state variable maintenance device applied to a receiving end user equipment in a sidelink, comprising:

a receiving module configured to perform any one of the following operations:

23. A communication device, characterized in that the communication device comprises a processor, a memory and a computer program stored on the memory and running on the processor, the processor implementing the steps of the state variable maintenance method according to any one of claims 1 to 14 or the steps of the state variable maintenance method according to any one of claims 15 to 20 when executing the computer program.

24. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, carries out the steps of the state variable maintenance method according to one of the claims 1 to 14 or the steps of the state variable maintenance method according to one of the claims 15 to 20.