Communication method and communication device

Abstract

The invention provides a communication method and communication equipment. The method comprises: when a first device does not receive a first data packet, a first protocol layer of the first device generates a second data packet and sends the second data packet to a second protocol layer, the first data packet being a data packet sent by a second device to the first device, and the first data packet being a data packet passing through ROHC; the second protocol layer is the upper layer of the first protocol layer.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication method and a communication device. Background Technology

[0002] In communication systems, the data sender can perform robust header compression (ROHC) on data packets and send the compressed packets to the data receiver. However, when packet loss occurs, the efficient compression of the data packets sent by the data receiver cannot be maintained due to the ROHC mechanism. This results in larger transmitted data packets, wasting air interface resources and reducing transmission efficiency. Summary of the Invention

[0003] This application provides a communication method and a communication device. The various aspects covered by this application are described below.

[0004] In a first aspect, a communication method is provided, the method comprising: when a first device does not receive a first data packet, a first protocol layer of the first device generates a second data packet and sends the second data packet to a second protocol layer, wherein: the first data packet is a data packet sent by the second device to the first device, and the first data packet is a data packet that has passed through ROHC; and the second protocol layer is an upper layer of the first protocol layer.

[0005] In a second aspect, a communication device is provided, the communication device being a first device, the communication device comprising: a processing unit, configured to generate a second data packet at a first protocol layer and send the second data packet to a second protocol layer when the first device does not receive a first data packet, wherein: the first data packet is a data packet sent by the second device to the first device, and the first data packet is a data packet passing through ROHC; the second protocol layer is an upper layer of the first protocol layer.

[0006] Thirdly, a communication device is provided, including a transceiver, a memory, and a processor, wherein the memory is used to store a program, the processor is used to invoke the program in the memory, and to control the transceiver to receive or send signals, so that the communication device performs the method as described in the first aspect.

[0007] Fourthly, an apparatus is provided, including a processor for calling a program from memory to cause the apparatus to perform the method as described in the first aspect.

[0008] Fifthly, a chip is provided, including a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in the first aspect.

[0009] In a sixth aspect, a computer-readable storage medium is provided having a program stored thereon that causes a computer to perform the method as described in the first aspect.

[0010] In a seventh aspect, a computer program product is provided, characterized in that it includes a program that causes a computer to perform the method as described in the first aspect.

[0011] Eighthly, a computer program is provided that causes a computer to perform the method as described in the first aspect.

[0012] In this embodiment, a second data packet is introduced during the transmission of the first data packet via ROHC. If the first device does not receive the first data packet, its first protocol layer generates the second data packet and sends it to its second protocol layer. The presence of the second data packet helps maintain the data packets sent by the first device in a highly compressed state, thereby avoiding waste of air interface resources and reduction in transmission efficiency. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the communication system used in the embodiments of this application.

[0014] Figure 2 This is a schematic diagram of data packet transmission based on ROHC technology in related technologies.

[0015] Figure 3 This is a schematic flowchart of a communication method provided in one embodiment of this application.

[0016] Figure 4 This is a schematic flowchart of a communication method provided in another embodiment of this application.

[0017] Figure 5A This is a schematic flowchart of a communication method provided in another embodiment of this application.

[0018] Figure 5B This is a schematic flowchart of a communication method provided in another embodiment of this application.

[0019] Figure 5C This is a schematic flowchart of a communication method provided in another embodiment of this application.

[0020] Figure 6 This is a schematic diagram illustrating the generation of a second data packet according to an embodiment of this application.

[0021] Figure 7A This is a schematic diagram of the header of the Real-Time Transport Protocol (RTP) in related technologies.

[0022] Figure 7B This is a schematic diagram of the User Datagram Protocol (UDP) packet header in related technologies.

[0023] Figure 7C This is a schematic diagram of the Internet Protocol (IP) packet header in related technologies.

[0024] Figure 8 This is a schematic diagram of generating a second data packet according to another embodiment of this application.

[0025] Figure 9 This is a schematic flowchart of a communication method provided in another embodiment of this application.

[0026] Figure 10 This is a schematic diagram of generating virtual data packets provided in Embodiment 1 of this application.

[0027] Figure 11 This is a schematic diagram of generating virtual data packets provided in Embodiment 2 of this application.

[0028] Figure 12 This is a schematic diagram of the structure of the communication device provided in the embodiments of this application.

[0029] Figure 13 This is a schematic diagram of the communication device provided in the embodiments of this application. Detailed Implementation

[0030] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0031] Communication system The embodiments of this application can be applied to various communication systems. For example, the embodiments of this application can be applied to Global System for Mobile Communication (GSM), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), General Packet Radio Service (GPRS), Long Term Evolution (LTE), Advanced Long Term Evolution (LTE-A), New Radio (NR), evolution systems of NR, LTE-based access to unlicensed spectrum (LTE-U), NR-based access to unlicensed spectrum (NR-U), Universal Mobile Telecommunication System (UMTS), Wireless Local Area Networks (WLAN), Wireless Fidelity (WiFi), and 5th-generation (5G) systems. The embodiments of this application can also be applied to other communication systems, such as future communication systems. This future communication system could be, for example, a sixth-generation mobile communication system or a satellite communication system.

[0032] Traditional communication systems support a limited number of connections and are easy to implement. However, with the development of communication technology, communication systems can now support not only traditional cellular communication but also one or more other types of communication. For example, a communication system can support one or more of the following communication methods: device-to-device (D2D) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), vehicle-to-vehicle (V2V) communication, and vehicle-to-everything (V2X) communication. The embodiments of this application can also be applied to communication systems that support the above-mentioned communication methods.

[0033] The communication system in this application embodiment can be applied to carrier aggregation (CA) scenarios, dual connectivity (DC) scenarios, and standalone (SA) network deployment scenarios.

[0034] The communication system in this application embodiment can be applied to unlicensed spectrum. This unlicensed spectrum can also be considered a shared spectrum. Alternatively, the communication system in this application embodiment can also be applied to licensed spectrum. This licensed spectrum can also be considered a dedicated spectrum.

[0035] The embodiments of this application can be applied to terrestrial networks (TN) systems as well as non-terrestrial networks (NTN) systems. As an example, the NTN system may include an NR-based NTN system and an Internet of Things (IoT)-based NTN system.

[0036] A communication system may include one or more terminal devices. The terminal devices mentioned in the embodiments of this application may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0037] In some embodiments, the terminal device may be a station (ST) in a WLAN. In some embodiments, the terminal device may also be a cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA) device, handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, in-vehicle device, wearable device, terminal device in a next-generation communication system (such as an NR system), or terminal device in a future public land mobile network (PLMN) network, etc.

[0038] In some embodiments, the terminal device may be a device that provides voice and / or data connectivity to the user. For example, the terminal device may be a handheld device, an in-vehicle device, etc., with wireless connectivity. As some specific examples, the terminal device may be a mobile phone, tablet, laptop, PDA, mobile internet device (MID), wearable device, virtual reality (VR) device, augmented reality (AR) device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc.

[0039] In some embodiments, the terminal device may be deployed on land. For example, the terminal device may be deployed indoors or outdoors. In some embodiments, the terminal device may be deployed on water, such as on a ship. In some embodiments, the terminal device may be deployed in the air, such as on an airplane, balloon, or satellite.

[0040] In addition to terminal devices, the communication system may also include one or more network devices. In this embodiment, the network device may be a device for communicating with the terminal device; this network device may also be referred to as an access network device or a radio access network device. For example, the network device may be a base station. In this embodiment, the network device may refer to an access network (RAN) node (or device) that connects the terminal device to the wireless network. Access network equipment can broadly encompass various names listed below, or be interchangeable with them, such as: NodeB, evolved NodeB (eNB), next-generation NodeB (gNB), relay station, access point, transmitting and receiving point (TRP), transmitting point (TP), master MeNB, secondary SeNB, multi-mode radio (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. Base stations can be macro base stations, micro base stations, relay nodes, donor nodes, or similar entities, or combinations thereof. A base station can also refer to a communication module, modem, or chip installed within the aforementioned equipment or apparatus. A base station can also be a mobile switching center, or a device that performs base station functions in device-to-device (D2D), vehicle-to-everything (V2X), and machine-to-machine (M2M) communications, a network-side device in a 6G network, or a device performing base station functions in future communication systems. Base stations can support networks using the same or different access technologies. The embodiments of this application do not limit the specific technologies or device forms used in the network equipment.

[0041] Base stations can be fixed or mobile. For example, a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move depending on the location of the mobile base station. In other examples, a helicopter or drone can be configured as a device to communicate with another base station.

[0042] In some deployments, the network device in this application embodiment can be an access network device. The access network device can be any of the following: gNB, centralized unit (CU), distributed unit (DU), centralized unit-control plane (CU-CP), or centralized unit-user plane (CU-UP).

[0043] In other deployments, the network device in this application embodiment can be a core network device. The core network device can be any of the following: a location management function (LMF) network element, a network slice selection function (NSSF) network element, an authentication server function (AUSF) network element, a unified data management (UDM) network element, an access and mobility management function (AMF) network element, a session management function (SMF) network element, a policy control function (PCF) network element, a user plane function (UPF) network element, a sensing function (SF) network element, a network data analytics function (NWDAF) network element, or an artificial intelligence (AI) function management entity.

[0044] By way of example and not limitation, in the embodiments of this application, the network device may have mobility characteristics; for example, the network device may be a mobile device. In some embodiments of this application, the network device may be satellite-based or space-based, that is, the network device is installed on a satellite or flying equipment. In some embodiments of this application, the network device may also be a base station installed in locations such as land or water.

[0045] In this embodiment of the application, the network device can provide services for a cell. The terminal device communicates with the network device through the transmission resources (e.g., frequency domain resources, or spectrum resources) used by the cell. The cell can be the cell corresponding to the network device (e.g., a base station). The cell can belong to a macro base station or to a base station corresponding to a small cell. The small cell here can include: metro cell, micro cell, pico cell, femto cell, etc. These small cells have the characteristics of small coverage area and low transmission power, and are suitable for providing high-speed data transmission services.

[0046] For example, Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application. Figure 1 As shown, the communication system 100 may include a network device 110, which may be a device that communicates with a terminal device 120 (or a communication terminal, terminal). The network device 110 can provide communication coverage for a specific geographical area and can communicate with terminal devices located within that coverage area.

[0047] Figure 1 An exemplary diagram shows a network device and two terminal devices. In some embodiments of this application, the communication system 100 may include multiple network devices and each network device may include other numbers of terminal devices within its coverage area. This application does not limit the scope of the embodiments.

[0048] It should be understood that devices with communication functions in the network / system of this application embodiment can be referred to as communication devices. Figure 1 Taking the communication system 100 shown as an example, the communication equipment may include a network device 110 and a terminal device 120 with communication functions. The network device 110 and the terminal device 120 may be the specific devices described above, and will not be repeated here. The communication equipment may also include other devices in the communication system 100, such as network controllers, mobility management entities, and other network entities. This application embodiment does not limit this.

[0049] ROHC technology ROHC (Recursive Header Redundancy Conversion) technology is based on high redundancy between the headers of consecutive data packets within the same data stream. In ROHC, the compression and decompression ends jointly maintain a context list to store historical header information. Initially, a complete list of static field information is gradually formed; subsequently, only dynamically changing field information needs to be transmitted. Introducing ROHC into communication effectively reduces packet header overhead, lowers error rate and transmission latency, and improves the utilization efficiency of air interface resources. ROHC technology is particularly suitable for communication scenarios where packet headers change little. For example, in voice calls, the header of voice data packets changes very little, or even remains unchanged. Introducing ROHC into voice calls can effectively reduce the overhead of voice packet headers.

[0050] As a concrete example, 3GPP Rel-20 established the project "Supporting IP Multimedia Subsystem (IMS) Voice Services via 4G Narrowband Internet of Things Non-terrestrial Networks (NB-IoT NTN)," aiming to provide voice service support for remote areas not covered by terrestrial networks. In NB-IoT NTN voice call scenarios, wireless channel bandwidth is limited, and the header of voice data packets typically accounts for a larger proportion than the effective voice payload, resulting in low transmission efficiency. Considering that the packet header in NB-IoT NTN voice services usually remains essentially unchanged or only slightly varies, ROHC technology can be applied to NB-IoT NTN voice call scenarios to compress the voice packet header for transmission, thereby saving air interface resources. Introducing ROHC in NB-IoT NTN voice calls can effectively reduce voice packet header overhead, lower the bit error rate and transmission latency, and improve the utilization efficiency of air interface resources.

[0051] In data transmission based on ROHC technology, if packet loss occurs, the data packets will be compressed at a lower compression efficiency to ensure normal decompression. For ease of understanding, the following will explain... Figure 2 Let's take downlink transmission in a voice call as an example for explanation.

[0052] like Figure 2 As shown, after a voice call is established, when a voice data stream arrives on the network side, the network device first sends an initial voice packet containing a complete header to the terminal device to synchronize the context between the two parties. Subsequently, when subsequent data packets of this data stream arrive, the network device performs ROHC on the subsequent data packets and sends the data packets with compressed headers to the terminal device. After receiving the data packets, the terminal device performs a decompression operation to restore the original header, thereby obtaining the complete data packets.

[0053] During data transmission, as the ROHC context stored by both the sender and receiver becomes more complete and continuously updated, the compressed packet header becomes smaller, thus improving compression efficiency. If packet loss occurs at the wireless interface, the context cannot be updated in time. If the sender and receiver interpret the same context ID differently, decompression will fail. To address this, ROHC uses a state machine, with different states corresponding to different compression efficiencies. If packet loss occurs, the ROHC state machine may roll back to a state with lower compression efficiency.

[0054] As can be seen from the above introduction, in the data transmission process based on ROHC technology, if packet loss occurs, the ROHC mechanism prevents the header of the data packet sent by the data receiver from being highly compressed. This results in the size of the data packet transmitted through the wireless interface becoming larger, thereby increasing the burden on the air interface and reducing transmission efficiency.

[0055] For example, during NB-IoT NTN voice calls based on ROHC technology, due to the instability of the satellite link air interface, continuous data packet loss may occur under poor air interface conditions. To ensure the reliability of the compression process, the ROHC state machine performs state rollback. However, the state rollback of the ROHC state machine prevents the voice packet header from being highly compressed, resulting in a larger data packet size transmitted through the wireless interface, thereby increasing the air interface load and reducing transmission efficiency.

[0056] To address the aforementioned issues, embodiments of this application introduce a second data packet during the transmission of the first data packet based on ROHC technology. The introduction of the second data packet avoids ROHC state machine rollback, which helps maintain the data packets sent by the first device in a highly compressed state, thereby preventing waste of air interface resources and reduced transmission efficiency.

[0057] In certain communication scenarios (e.g., voice communication scenarios), the packet headers typically remain largely unchanged or undergo only minor changes, and a small amount of packet loss can be tolerated. Therefore, although the communication method provided in this application avoids ROHC state machine rollback in the event of packet loss, it can still guarantee communication quality (e.g., call quality).

[0058] The communication method provided in the embodiments of this application will now be described in more detail with reference to the accompanying drawings.

[0059] Figure 3 This is a schematic flowchart illustrating the communication method provided in an embodiment of this application. Figure 3 The method is described from the perspective of the first device. In the embodiments of this application, the first device may be referred to as a data receiver or a data receiving device, and the second device may be referred to as a data sender or a data sending device.

[0060] In some implementations, Figure 3 The first device can be the terminal device 120 mentioned above, and the second device can be the network device 110 mentioned above.

[0061] In some other implementations, Figure 3 The first device can be the network device 110 mentioned above, and the second device can be the terminal device 120 mentioned above.

[0062] In some other implementations, Figure 3 Both the first and second devices can be the terminal devices 120 mentioned above.

[0063] Terminal equipment may include UE. Network equipment may include one or more of the following: eNB, control plane network elements in the core network, and user plane gateways in the core network. Control plane network elements in the core network include MME. User plane gateways in the core network include SGW.

[0064] For example, the first device is the UE, and the second device is the eNB, MME, or SGW.

[0065] For example, the first device is an eNB, MME, or SGW, and the second device is a UE.

[0066] For example, both the first device and the second device are UEs.

[0067] like Figure 3 As shown, the communication method provided in this application embodiment includes steps S310 and S320.

[0068] In step S310, if the first device does not receive the first data packet, the first protocol layer of the first device generates a second data packet.

[0069] In step S320, the first protocol layer sends the second data packet to the second protocol layer.

[0070] The first data packet is a data packet sent from the second device to the first device. Furthermore, the first data packet undergoes ROHC. That is, the first data packet can be obtained from the original data packet. In other words, the second device performs ROHC on the original data packet to obtain the first data packet and then sends the first data packet to the first device.

[0071] The raw data packet may include a header and a payload. The header of the raw data packet can be called the raw header. The first device performs ROHC on the header of the raw data packet to obtain the header of the first data packet. That is, the header of the first data packet is obtained by compressing the header of the raw data packet, and the payload of the first data packet is the same as the payload of the raw data packet. Therefore, the header of the first data packet can also be called the compressed header or the ROHC header.

[0072] For example, the original data packet includes a header and a payload, where the header includes an IP header, a UDP header, and an RTP header. The second device performs ROHC on the header of the original data packet to obtain the ROHC header. The ROHC header and the payload of the original data packet form the first data packet.

[0073] In some implementations, the first data packet is a data packet sent by the second device via the NB-IoT NTN.

[0074] In some implementations, the first data packet is used for voice services. For example, the first data packet is used for IMS voice services.

[0075] In some implementations, the first data packet is a data packet sent by the second device via the NB-IoT NTN, and the first data packet is used for voice services. For example, the first data packet is a data packet in an IMS voice service based on the NB-IoT NTN.

[0076] When the first data packet is used for voice services, the first data packet can be called a voice data packet or a voice packet.

[0077] In some implementations, the first data packet is a data packet in the uplink transmission.

[0078] In some other implementations, the first data packet is a data packet in the downlink transmission.

[0079] In some other implementations, the first data packet is a data packet transmitted in a sideline manner.

[0080] After the first device successfully receives the first data packet sent by the second device, it decompresses the first data packet to obtain the original data packet corresponding to the first data packet. If a certain first data packet is obtained by performing ROHC on a certain original data packet, then the data packet obtained by decompressing the first data packet is the original data packet.

[0081] For example, the original data packet includes a header and a payload, where the header includes an IP header, a UDP header, and an RTP header. The second device performs a ROHC operation on the header of the original data packet to obtain the ROHC header. The ROHC header and the payload of the original data packet form the first data packet, hereinafter referred to as data packet 1. The second device sends data packet 1 to the first device. After receiving data packet 1, the first device decompresses it to obtain the IP header, UDP header, RTP header, and payload. The IP header is the same as the IP header of the original data packet. The UDP header is the same as the UDP header of the original data packet. The RTP header is the same as the RTP header of the original data packet. The payload is the same as the payload of the original data packet.

[0082] In some cases, the first device may fail to receive the first data packet sent by the second device; that is, packet loss may occur on the first device's side. Or, a packet loss event may occur.

[0083] The first device can predict in advance when it should receive the first data packet. If the first device does not receive the first data packet at the predicted transmission time, the first device determines that it has not received the first data packet sent by the second device. For example, in voice services, voice data packets are transmitted based on the SPS mechanism. That is, voice data packets are transmitted periodically. The first device can predict the transmission time of the first data packet based on the transmission period of the voice data packets. If the first device fails to receive the first data packet at the predicted transmission time, it determines that the second device sent the voice data packet but it did not receive it.

[0084] If the first device does not receive the first data packet, the first protocol layer of the first device generates a second data packet and sends the second data packet to the second protocol layer.

[0085] In this embodiment, the second protocol layer is the upper layer of the first protocol layer. That is, the first protocol layer is the lower layer of the second protocol layer. In this embodiment, the first and second protocol layers should be interpreted broadly.

[0086] In some cases, the first and second protocol layers can be understood as separate protocol layers defined in the standard, such as the PDCP layer, MAC layer, RLC layer, etc.

[0087] For example, the first protocol layer is the Media Access Control (MAC) layer, and the second protocol layer is the PDCP layer.

[0088] For example, the first protocol layer is the MAC layer, and the second protocol layer is the RRC layer.

[0089] For example, the first protocol layer is the RLC layer, and the second protocol layer is the PDCP layer.

[0090] In other cases, the first and second protocol layers can be understood as layers within the same protocol layer defined in the standard, divided according to logical function. The first protocol layer can be understood as the logical function closer to the lower layer, and the second protocol layer can be understood as the logical function closer to the upper layer.

[0091] For example, the first protocol layer is the logical function that is closer to the lower layer in the PDCP layer, and the second protocol layer is the logical function that is closer to the upper layer in the PDCP layer.

[0092] In this embodiment, the purpose of the first protocol layer generating the second data packet is to mislead the second protocol layer into believing that the first device has received the data packet sent by the second device, thereby avoiding state machine rollback caused by the ROHC mechanism. The second data packet is not an actual data packet sent by the second device; therefore, it can also be called a virtual data packet or a simulated data packet.

[0093] In some implementations, such as Figure 4 As shown, before step S320, the communication method provided in this application embodiment may further include step S410.

[0094] In step S410, the first protocol layer performs ROHC on the second data packet.

[0095] In other words, after the first protocol layer generates the second data packet, it first compresses the second data packet and then sends the compressed second data packet to the second protocol layer. In this embodiment, the virtual data packet generated by the first protocol layer and the compressed virtual data packet are collectively referred to as the second data packet.

[0096] The first protocol layer can pre-integrate the ROHC module and maintain the compressor in a high-efficiency compression state. The ROHC module of the first protocol layer can simulate the ROHC behavior of the second device and perform ROHC on the generated second data packet.

[0097] The first protocol layer can send the second data packet at specific times; these times can be referred to as the sending timing of the second data packet. For example, the first protocol layer can send the generated second data packet to the second protocol layer immediately after it is generated. Alternatively, the first protocol layer can wait a preset time after generating the second data packet before sending it to the second protocol layer. The sending timing of the second data packet can be determined based on the capabilities of the first device, predefined protocol information, or the configuration information of the second device.

[0098] In some embodiments, the first protocol layer generates a second data packet multiple times and sends the second data packet multiple times to the second protocol layer. For example, the first protocol layer generates one second data packet at a time and sends the generated second data packet to the second protocol layer.

[0099] In other embodiments, the first protocol layer generates multiple second data packets at once and sends the generated second data packets to the second protocol layer in multiple batches. For example, the first protocol layer generates multiple second data packets at once and sends one of the multiple second data packets to the second protocol layer when needed.

[0100] There is a certain time interval between two adjacent second data packets sent by the first protocol layer. This time interval can be called the second data packet sending cycle or the virtual packet sending cycle.

[0101] The transmission cycle of the second data packet can be determined based on predefined protocol information or the configuration information of the second device. The configuration information of the second device can be carried in an RRC message, such as an RRC reconfiguration message. As a concrete example, the second device sends an RRC reconfiguration message to the first device. This RRC reconfiguration message includes the parameter VirtualPacketSendingCycle, which indicates the transmission cycle of the second data packet.

[0102] The transmission period of the second data packet can also be determined by the first device itself. For example, the first device can use the data period of the voice service as the transmission period of the second data packet.

[0103] As can be seen from the description of steps S310 and S320, using the communication method provided in this application embodiment, when the first device fails to receive data sent by the second device, the first device generates a second data packet to prevent the compressor state of the first device from reverting, thus maintaining the compressor's efficient compression state. In this way, it prevents the data packet size sent by the first device to the second device from being too large due to the use of a low-efficiency compression method, thereby saving air interface resources and improving transmission efficiency.

[0104] Furthermore, the communication method provided in this application embodiment can avoid the data packet transmission interval and communication delay introduced by the process of re-establishing context synchronization between the first device and the second device, thereby improving transmission efficiency, ensuring the continuity and quality of communication, and enhancing user experience.

[0105] Step S310 states that if the first device does not receive the first data packet, the first protocol layer generates a second data packet.

[0106] In this embodiment, the first protocol layer does not generate a second data packet when the first device does not receive the first data packet. Instead, it generates a second data packet under certain conditions. For ease of distinction, the conditions that the first protocol layer needs to meet to generate the second data packet are referred to as the first condition. The first condition can be called the triggering condition for the virtual data packet. The first condition can be determined based on protocol predefined information or the configuration information of the second device.

[0107] When a packet loss event first occurs, the first device can monitor the event based on its own capabilities and / or its configuration information to determine whether the first condition is met. If the first condition is not met, the first device does not need to generate a second data packet. If the first condition is met, the first device begins generating a second data packet.

[0108] The first condition may include: the number of first data packets that the first device has not received consecutively is greater than or equal to a first quantity threshold; and / or the duration during which the first device has not received the first data packets consecutively is greater than or equal to a first duration threshold.

[0109] In some implementations, the first condition includes: the number of first data packets that the first device has not received consecutively is greater than or equal to a first quantity threshold.

[0110] The first quantity threshold can be understood as the maximum number of consecutive packet losses allowed by the ROHC mechanism. This first quantity threshold can also be called the maximum consecutive packet loss threshold (MaxConsecutivePacketLossThreshold). Here, the first quantity threshold is a positive integer. If the first quantity threshold is 1, then when the first device does not receive a first data packet, the first protocol layer generates a second data packet. If the first quantity threshold is greater than 1, then when the number of consecutively unreceived first data packets by the first device reaches the first data volume threshold, the first protocol layer generates a second data packet.

[0111] For example, when a packet loss event occurs, the first device begins calculating the number of consecutive packet losses. If the first device successfully receives the first data packet before the number of consecutive packet losses reaches a first threshold, the first device stops calculating the number of consecutive packet losses. Upon the next packet loss event, the first device recalculates the number of consecutive packet losses. If the first device fails to receive the first data packet before the number of consecutive packet losses reaches the first threshold, the first protocol layer of the first device begins generating a second data packet when the number of consecutive packet losses reaches the first threshold.

[0112] A first quantity threshold can be set based on channel conditions. If channel conditions are poor, a larger first quantity threshold can be set. If channel conditions are good, a smaller first quantity threshold can be set. For example, if the first data packet is transmitted via an NB-IoT NTN based on geostationary earth orbit (GEO), a larger first quantity threshold can be set due to the poor channel conditions. Conversely, if the first data packet is transmitted via an NB-IoT NTN based on low earth orbit (LEO), a smaller first quantity threshold can be set due to the good channel conditions.

[0113] The first quantity threshold can be determined based on predefined protocol information or the configuration information of the second device. The configuration information of the second device can be carried in an RRC message, such as an RRC reconfiguration message. As a specific example, the second device sends an RRC reconfiguration message to the first device, which includes the parameter MaxConsecutivePacketLossThreshold, indicating the first quantity threshold M.

[0114] In some implementations, the first condition includes: the duration during which the first device has not received the first data packet for a continuous period of time is greater than or equal to a first duration threshold.

[0115] The first duration can be understood as the longest continuous packet loss duration allowed by the ROHC mechanism. In other words, the first protocol layer will not immediately generate a second data packet if the first data packet is not received, but will start generating a second data packet when the duration during which the first device has not received the first data packet is greater than or equal to the first duration threshold.

[0116] For example, a timer T1 can be set, with a duration equal to a first duration threshold. This timer can be called a packet loss timer. The timer starts when the first device detects a packet loss event. If the first device successfully receives the first data packet before timer T1 expires, timer T1 stops. It should be understood that the first data packet here is the first data packet retransmitted by the second device, not the lost first data packet mentioned earlier. When the first device detects a packet loss event again, timer T1 is restarted. If the first device does not successfully receive the first data packet before timer T1 expires, the first protocol layer of the first device generates a second data packet when timer T1 expires.

[0117] The initial duration can be set based on channel conditions. If channel conditions are poor, a longer initial duration can be set. If channel conditions are good, a shorter initial duration can be set. For example, if the first data packet is transmitted via an NB-IoT NTN implemented using GEO, a longer initial duration can be set due to poor channel conditions. Conversely, if the first data packet is transmitted via an NB-IoT NTN implemented using LEO, a shorter initial duration can be set due to better channel conditions.

[0118] The first duration can be determined based on predefined protocol information or the configuration information of the second device. The configuration information of the second device can be carried in an RRC message, such as an RRC reconfiguration message. As a specific example, the second device sends an RRC reconfiguration message to the first device, which includes the parameter PacketLossTimer to indicate the first duration.

[0119] In some implementations, the first condition includes: the number of first data packets that the first device has not received consecutively is greater than or equal to a first quantity threshold, and the duration for which the first device has not received the first data packets consecutively is greater than or equal to a first duration threshold.

[0120] In other words, the first protocol layer will not immediately generate a second data packet if the first data packet is not received. Instead, it will start generating a second data packet when the number of consecutively unreceived first data packets reaches a first data volume threshold and the duration of the consecutive unreceived first data packets by the first device is greater than or equal to a first duration threshold. The first quantity threshold and / or the first duration threshold can be determined based on protocol predefined information or the configuration information of the second device.

[0121] For example, a timer T1 and a first quantity threshold M are set, where the duration of timer T1 is equal to the first duration threshold. When a packet loss event occurs, the first device starts calculating the number of consecutive packet losses and starts timer T1. If the number of consecutive packet losses calculated by the first device is less than the first quantity threshold M and timer T1 has not expired, the first device continues to wait to receive the first data packet sent by the second device. If the first device successfully receives the first data packet before the number of consecutive packet losses reaches the first quantity threshold M or before timer T1 expires, the first device stops calculating the number of consecutive packet losses and stops timer T1. When the next consecutive packet loss event occurs, the first device restarts timer T1 and recalculates the number of consecutive packet losses. If the first device fails to successfully receive the first data packet before the number of consecutive packet losses reaches the first quantity threshold M and before timer T1 expires, the first protocol layer of the first device starts generating the second data packet.

[0122] As mentioned earlier, the first protocol layer can generate the second data packet multiple times and send the second data packet to the second protocol layer multiple times. Alternatively, the first protocol layer can generate the second data packet all at once and send the generated second data packet in multiple parts.

[0123] In this embodiment, the first protocol layer can stop generating the second data packet under certain conditions. For ease of distinction, the condition that the first protocol layer needs to stop generating the second data packet is referred to as the second condition. That is, the first protocol layer stops generating the second data packet when the second condition is met.

[0124] like Figure 5A , 5B As shown in Figure 5C, after step S320, the communication method provided in this application embodiment may further include step S510.

[0125] In step S510, the first protocol layer stops generating the second data packet.

[0126] The second condition can be determined based on predefined protocol information or the configuration information of the second device. The configuration information of the second device can be carried in an RRC message, such as an RRC reconfiguration message.

[0127] The second condition may include one or more of the following: the first device successfully receives the first data packet; the number of second data packets continuously sent by the first protocol layer is greater than or equal to a second quantity threshold; the duration of the first protocol layer continuously sending the second data packets is greater than or equal to a second duration threshold.

[0128] In some implementations, the second condition includes: the first device successfully receiving the first data packet.

[0129] In other words, if the first protocol layer successfully receives the first data packet while generating and sending the second data packet to the second protocol layer, the first protocol layer stops generating the second data packet.

[0130] As an example, see Figure 5A The first protocol layer begins generating a second data packet and sends it to the second protocol layer if it does not receive the first data packet. After a period of time, the first device successfully receives the first data packet, at which point the first protocol layer stops generating the second data packet.

[0131] In some implementations, the second condition includes: the number of second data packets continuously sent by the first protocol layer is greater than or equal to a second quantity threshold.

[0132] The second quantity threshold can be understood as the maximum number of times the second data packet is allowed to be sent. The second quantity threshold can also be called the maximum virtual packet threshold (MaxVirtualPacketThreshold). If, during the process of generating and sending the second data packet to the second protocol layer, the first protocol layer continuously sends a number of second data packets that are greater than or equal to the second quantity threshold, then the first protocol layer stops generating the second data packet.

[0133] As an example, see Figure 5B The first protocol layer begins generating a second data packet and sends it to the second protocol layer if it does not receive the first data packet. After a period of time, the first device still fails to receive the first data packet, but because the number of second data packets continuously sent by the first protocol layer has reached a second threshold, the first protocol layer stops generating second data packets.

[0134] The second quantity threshold can be determined based on predefined protocol information or the configuration information of the second device. The configuration information of the second device can be carried in an RRC message, such as an RRC reconfiguration message. As a specific example, the second device sends an RRC reconfiguration message to the first device, which includes the parameter MaxVirtualPacketThreshold to indicate the second quantity threshold.

[0135] In some implementations, the second condition includes: the duration for which the first protocol layer continuously sends the second data packet is greater than or equal to a second duration threshold.

[0136] The second duration threshold can be understood as the longest allowed continuous transmission duration of the second data packet. If, during the process of generating and transmitting the second data packet, the first protocol layer continuously transmits the second data packet for a duration greater than or equal to the second duration threshold, then the first protocol layer stops transmitting the second data packet.

[0137] As an example, see Figure 5C The first protocol layer begins generating a second data packet and sends it to the second protocol layer if it does not receive the first data packet. After a period of time, the first device still fails to receive the first data packet, but because the duration for which the first protocol layer continuously sends the second data packet reaches a second duration threshold, the first protocol layer stops sending the second data packet.

[0138] A timer T2 can be set, with its duration equal to a second duration threshold. Timer T2 can be called a Virtual PacketSendingTimer. Timer T2 starts when the first protocol layer begins sending the second data packet. Timer T2 stops when the first protocol layer stops sending the second data packet. Timer T2 restarts when the first protocol layer begins sending the second data packet again.

[0139] The second duration threshold can be determined based on protocol predefined information or network device configuration information. The configuration information of the second device can be carried in an RRC message, such as an RRC reconfiguration message. As a specific example, the second device sends an RRC reconfiguration message to the first device. The RRC reconfiguration message includes the parameter VirtualPacketSendingTimer, which indicates the duration of timer T2.

[0140] As mentioned above, the values ​​of one or more of the first quantity threshold, the first duration threshold, the second data packet transmission period, the second quantity threshold, and the second duration threshold can be determined based on the configuration information of the second device. In some cases, the second device can determine one or more of these parameters independently and send the determined parameters to the first device through the configuration information. In other cases, the second device can determine one or more of these parameters with reference to the suggestions of the first device and send the determined parameters to the first device through the configuration information. For example, the terminal device provides suggested values ​​for one or more of these parameters to the network device through UE assistance info, and the network device determines the parameter values ​​with reference to the suggested values ​​provided by the terminal device.

[0141] As mentioned above, the second device can provide the first device with one or more values ​​of a first quantity threshold, a first duration threshold, a second data packet transmission period, a second quantity threshold, and a second duration threshold via an RRC reconfiguration message. Upon receiving the RRC reconfiguration message, the first device's RRC layer parses the message to obtain the configuration information (indicating the parameter values) and passes this information to the lower layer. The lower layer of the first device stores this configuration information. This lower layer can be the PDCP layer, the RLC layer, or the MAC layer.

[0142] In this embodiment, the first protocol layer can generate a second data packet based on a third data packet. The third data packet can be understood as a data packet obtained by decompressing the first data packet successfully received by the first device.

[0143] In some implementations, the third data packet is the data packet obtained by decompressing the Nth to last (N is an integer greater than 1) first data packet successfully received by the first device.

[0144] In some implementations, the third data packet is the data packet obtained by decompressing the last first data packet successfully received by the first device. Based on the previous description of the first data packet, in this case, the third data packet is the same as the original data packet corresponding to the last first data packet successfully received by the first device.

[0145] The first protocol layer can generate the second data packet based on the third data packet in various ways. This application provides two possible implementation methods.

[0146] In some implementations, the first header of the second data packet is exactly the same as the first header of the third data packet. In this implementation, the first protocol layer can obtain the first header of the second data packet by copying the first header of the third data packet.

[0147] In some implementations, the value of the first field in the first header of the second data packet differs from the value of the first field in the first header of the third data packet. In this implementation, the first protocol layer can obtain the first header of the second data packet by modifying the value of the first field in the first header of the third data packet.

[0148] The following details two implementation methods for generating the second data packet from the first protocol layer.

[0149] Implementation Method 1: The first header of the second data packet is exactly the same as the first header of the third data packet. In implementation method one, the first header of the second data packet is identical to the first header of the third data packet. Here, the third data packet is the data packet obtained by decompressing the last first data packet successfully received by the first device. The identical first header of the second and third data packets means that all field values ​​in the first header of the second and third data packets are exactly the same. Therefore, the first protocol layer can obtain the first header of the second data packet by copying the first header of the third data packet.

[0150] In implementation method one, the payload of the second data packet can be exactly the same as the payload of the third data packet. Therefore, the first protocol layer can obtain the payload of the second data packet by copying the payload of the third data packet.

[0151] The third data packet is obtained by decompressing the last first data packet successfully received by the first device. The decompression of the first data packet is typically performed by the second protocol layer or a layer above it. For example, the layer above the second protocol layer might be the RRC layer, or even the application layer. The first protocol layer can send a request to the second protocol layer to request the third data packet when it needs to generate a second data packet.

[0152] As a concrete example, see Figure 6 , Figure 6 This is a schematic diagram illustrating the generation of a second data packet by a first protocol layer according to an embodiment of this application. Figure 6 As shown, the last first data packet successfully received by the first device includes an ROHC header and a payload. The second protocol layer or its upper layer decompresses the first data packet to obtain a third data packet. The third data packet includes a first header and a payload. When a second data packet needs to be generated, the first protocol layer sends a request to the second protocol layer, requesting the third data packet corresponding to the previously successfully received first data packet. The second protocol layer responds to the first protocol layer's request and sends the third data packet to the first protocol layer. The first protocol layer directly copies the first header and payload of the third data packet to generate the second data packet. Then, the first protocol layer performs ROHC on the second data packet and sends the compressed second data packet to the second protocol layer. The compressed second data packet includes an ROHC header and a payload.

[0153] In this embodiment of the application, the first header may include one or more of the following: RTP header, UDP header, and IP header.

[0154] Figure 7A , Figure 7B as well as Figure 7C The diagrams show the RTP header, UDP header, and IP header respectively.

[0155] like Figure 7A As shown, the IP header includes the version field, IHL field, type of service field, total length field, identification field, flags field, fragment offset field, time to live field, protocol field, header checksum field, source address field, destination address field, optional field, and padding field.

[0156] like Figure 7B As shown, the UDP header includes a source port field, a destination port field, a length field, a checksum field, and a data octets field.

[0157] like Figure 7C As shown, the RTP header includes a version field, a padding (P) field, an extension (X) field, a contributing source identifier count (CC) field, a marker (M) field, a payload type (PT) field, a sequence number field, a timestamp field, a synchronization source identifier (SSRC identifier) ​​field, and a contributing source identifier (CSRC identifier) ​​field.

[0158] In some embodiments, the RTP header of the second data packet is exactly the same as the RTP header of the third data packet. That is, the values ​​of all fields in the RTP header of the second data packet are exactly the same as the values ​​of all fields in the RTP header of the third data packet.

[0159] In some embodiments, the UDP header of the second data packet is exactly the same as the UDP header of the third data packet. That is, the values ​​of all fields in the UDP header of the second data packet are exactly the same as the values ​​of all fields in the UDP header of the third data packet.

[0160] In some embodiments, the IP header of the second data packet is exactly the same as the IP header of the third data packet. That is, the values ​​of all fields in the IP header of the second data packet are exactly the same as the values ​​of all fields in the IP header of the third data packet.

[0161] In some embodiments, the RTP header, UDP header, and IP header of the second data packet are exactly the same as the RTP header, UDP header, and IP header of the third data packet, respectively. That is, the values ​​of all fields in the RTP header, UDP header, and IP header of the second data packet are exactly the same as the values ​​of all fields in the RTP header, UDP header, and IP header of the third data packet.

[0162] In some implementations, the sequence number (SN) in the second header of the second data packet is different from the sequence number in the second header of the third data packet.

[0163] The second header here may include a radio link control (RLC) header. When the second header is an RLC header, the sequence number in the second header can be called the RLC SN.

[0164] The sequence number in the second header of the second data packet can be determined based on the sequence number in the second header of the third data packet. Taking RLC as the second header as an example, the RLC SN in the RLC header of the second data packet can be equal to the RLC SN in the RLC header of the third data packet plus 1.

[0165] Setting the sequence number in the second header of the second data packet to be different from the sequence number in the second header of the third data packet can prevent the second data packet from being dropped by the second protocol layer or the layer above the second protocol layer. When the second header is an RLC header, setting the sequence number in the RLC header of the second data packet to be different from the sequence number in the RLC header of the third data packet can prevent the second data packet from being dropped by the RLC layer of the first device.

[0166] In some implementations, the second data packet includes a first identifier, which is used by the second protocol layer to distinguish the second data packet from the first data packet.

[0167] The first identifier can be understood as a special identifier added by the first protocol layer to the second data packet.

[0168] In this embodiment, the first data packet is a data packet sent from the second device to the first device, used to carry the information that actually needs to be transmitted. The second data packet is a data packet generated internally by the first device and is not used to carry the information that actually needs to be transmitted. The second protocol layer or the layer above the second protocol layer needs to decompress the first and second data packets.

[0169] If a first identifier is added to the second data packet, the second protocol layer or its upper layer can effectively distinguish the second data packet from the first data packet upon receiving it, quickly identifying that it is the second data packet rather than the first data packet. In this way, the second protocol layer or its upper layer can avoid mistaking the second data packet for the first data packet due to outdated header information, thus preventing erroneous decompression of the second data packet.

[0170] In the first implementation method, the first protocol layer can generate the second data packet by copying the first packet header and payload of the third data packet. This is relatively simple to implement and can reduce communication latency and power consumption of the first device.

[0171] Implementation Method 2: The value of the first field in the first header of the second data packet is the same as the value in the first header of the third data packet. The values ​​of the first field are different. In implementation method two, the value of the first field in the first header of the second data packet differs from the value of the first field in the first header of the third data packet. Here, the third data packet is the data packet obtained by decompressing the last first data packet successfully received by the first device. The first protocol layer can obtain the first header of the second data packet by modifying the first field in the first header of the third data packet and copying all fields except the first field from the first header of the third data packet.

[0172] In the second implementation method, when the first protocol layer generates the second data packet, in addition to generating the header of the second data packet, it also needs to generate the payload of the second data packet.

[0173] In some embodiments, the payload of the second data packet is exactly the same as the payload of the third data packet. Therefore, the first protocol layer can obtain the payload of the second data packet by copying the payload of the third data packet.

[0174] In other embodiments, the payload of the second data packet has the same number of bits as the payload of the third data packet, but the values ​​of the bits are different. For example, the first protocol layer fills each bit of the payload of the third data packet with 0 to obtain the payload of the second data packet. Alternatively, the first protocol layer fills each bit of the payload of the third data packet with 1 to obtain the payload of the second data packet.

[0175] The third data packet is obtained by decompressing the last first data packet successfully received by the first device. The decompression of the first data packet is typically performed by the second protocol layer or a layer above it. Therefore, the first protocol layer can send a request to the second protocol layer to request the third data packet when it needs to generate a second data packet.

[0176] As a concrete example, see Figure 8 , Figure 8 This is a schematic diagram illustrating the generation of a second data packet by a first protocol layer according to an embodiment of this application. Figure 8As shown, the first device successfully receives the last first data packet, including the ROHC header and payload. The second protocol layer or its upper layer decompresses the first data packet to obtain the third data packet. The third data packet includes the first header and payload. When a second data packet needs to be generated, the first protocol layer sends a request to the second protocol layer, requesting the third data packet corresponding to the previously successfully received first data packet. The second protocol layer responds to the first protocol layer's request and sends the third data packet to the first protocol layer. The first protocol layer modifies the first field in the first header of the third data packet and the payload to generate the second data packet. Then, the first protocol layer performs ROHC on the second data packet and sends the compressed second data packet to the second protocol layer. The compressed second data packet includes the ROHC header and payload.

[0177] In this embodiment, the first header may include one or more of the following: an RTP header, a UDP header, and an IP header. For detailed information on the RTP header, UDP header, and IP header, please refer to the description in Implementation Method 1; further details will not be repeated here.

[0178] In some embodiments, the first field includes an identification field in the IP header. That is, the value of the identification field in the IP header of the second data packet is different from the value of the identification field in the IP header of the third data packet.

[0179] The value of the first second packet generated after the third packet can be obtained by incrementing the value of the identifier field in the IP header of the third packet by a first preset value. For example, the first preset value is 1.

[0180] If the first protocol layer needs to generate multiple second data packets, the value of the identification field in the IP header of the later-generated second data packet can be based on the identification field in the IP header of the earlier-generated second data packet. For example, the value of the identification field in the IP header of the later-generated second data packet can be obtained by adding a second preset value to the value of the identification field in the IP header of the earlier-generated second data packet. For example, the second preset value is 1. The first preset value and the second preset value can be different. Alternatively, the first preset value and the second preset value can be the same.

[0181] As a concrete example, the first protocol layer needs to generate N (N is a positive integer) second data packets. The value of the identifier field in the IP header of the first second data packet is obtained by incrementing the value of the identifier field in the IP header of the third data packet by 1. The value of the identifier field in the IP header of the second second data packet is obtained by incrementing the value of the identifier field in the IP header of the first second data packet by 1. The value of the identifier field in the IP header of the third second data packet is obtained by incrementing the value of the identifier field in the IP header of the second second data packet by 1. And so on, until the Nth second data packet is generated.

[0182] In some embodiments, the first field includes a sequence number field in the RTP header. That is, the value of the identifier field in the RTP header of the second data packet is different from the value of the identifier field in the RTP header of the third data packet.

[0183] The value of the first second data packet generated after the third data packet can be obtained by incrementing the value of the sequence number field in the RTP header of the third data packet by a third preset value. For example, the third preset value is 1.

[0184] If the first protocol layer needs to generate multiple second data packets, the value of the sequence number field in the RTP header of the later-generated second data packet can be determined based on the value of the sequence number field in the RTP header of the earlier-generated second data packet. For example, the value of the sequence number field in the RTP header of the later-generated second data packet can be obtained by adding a fourth preset value to the value of the sequence number field in the RTP header of the earlier-generated second data packet. For example, the fourth preset value is 1. The third preset value and the fourth preset value can be different. Alternatively, the third preset value and the fourth preset value can be the same.

[0185] As a concrete example, the first protocol layer needs to generate N (N is a positive integer) second data packets. The sequence number field of the RTP header of the first second data packet is obtained by incrementing the sequence number field of the RTP header of the third data packet by 1. The sequence number field of the RTP header of the second second data packet is obtained by incrementing the sequence number field of the RTP header of the first second data packet by 1. The sequence number field of the RTP header of the third second data packet is obtained by incrementing the sequence number field of the RTP header of the second second data packet by 1. And so on, until the Nth second data packet is generated.

[0186] In some embodiments, the first field includes a timestamp field in the RTP header. That is, the value of the timestamp field in the RTP header of the second data packet is different from the value of the timestamp field in the RTP header of the third data packet.

[0187] The value of the first second data packet generated after the third data packet can be obtained by adding a fifth preset value to the timestamp field of the RTP header of the third data packet. If the first protocol layer needs to generate multiple second data packets, the value of the timestamp field in the RTP header of the later generated second data packet is obtained by adding this fifth preset value to the timestamp field in the RTP header of the earlier generated second data packet. In other words, when generating a second data packet, the value of the timestamp field in the RTP header is increased linearly by the fifth preset value. Here, the fifth preset value is the generation period of the second data packet. The generation period of the second data packet can be understood as the time required to generate one second data packet.

[0188] As a concrete example, the first protocol layer needs to generate N (N is a positive integer) second data packets. The timestamp field of the RTP header of the first second data packet is obtained by adding the timestamp field of the RTP header of the third data packet to the generation period of the second data packet. The timestamp field of the RTP header of the second second data packet is obtained by adding the timestamp field of the RTP header of the first second data packet to the generation period. The timestamp field of the RTP header of the third second data packet is obtained by adding the timestamp field of the RTP header of the second second data packet to the generation period. And so on, until the Nth second data packet is generated.

[0189] The fifth preset value can be determined based on the number of samples in the first data packet. For example, the fifth preset value can be equal to the product of the transmission interval of the first data packet and the sampling rate. As a specific example, if the transmission interval of the first data packet is 20ms and the sampling rate is 8kHz, then the fifth preset value is 160.

[0190] In some cases, the fifth preset value is calculated by the first device. For example, the protocol predefines the transmission interval and sampling rate of the first data packet, and the first device calculates the fifth preset value based on the protocol-predefined transmission interval and sampling rate.

[0191] In other cases, the fifth preset value is determined based on the configuration information of the second device. For example, the second device configures the transmission interval and sampling rate of the first data packet, and calculates the fifth preset value based on the configured transmission interval and sampling rate. The second device then instructs the first device on the fifth preset value through the configuration information.

[0192] In some embodiments, the first field includes an identification field in the IP header, a sequence number field in the RTP header, and a timestamp field in the RTP header. The value of the identification field in the IP header of the second data packet differs from the value of the identification field in the IP header of the third data packet, the value of the identification field in the RTP header of the second data packet differs from the value of the identification field in the RTP header of the third data packet, and the value of the timestamp field in the RTP header of the second data packet differs from the value of the timestamp field in the RTP header of the third data packet.

[0193] The above describes two implementation methods for generating the second data packet from the first protocol layer.

[0194] In some implementations, the communication method provided in this application embodiment may further include: the first device sending first capability information to the second device. For example, when the first device is a terminal device and the second device is a network device, the terminal device may send the first capability information to the network device.

[0195] The first capability information is used to indicate one or more of the following: whether the first device supports generating a second data packet; whether the first device supports determining a first quantity, wherein the first quantity is the number of first data packets that the first device has not received consecutively; whether the first device supports determining a first duration, wherein the first duration is the duration for which the first device has not received a first data packet consecutively; whether the first device supports determining a second quantity, wherein the second quantity is the number of second data packets that the first protocol layer has consecutively sent to the second protocol layer; and whether the first device supports determining a second duration, wherein the second duration is the duration for which the first protocol layer has consecutively sent the second data packets to the second protocol layer.

[0196] In some embodiments, the first capability information is used to indicate whether the first device supports generating the second data packet.

[0197] In some embodiments, the first capability information is used to indicate whether the first device supports determining a first quantity, wherein the first quantity is the number of first data packets that the first device has not received consecutively.

[0198] The first quantity can be referred to as the number of consecutive packet losses by the first device. The first device supports determining the first quantity, which can be understood as the first device having the function of counting the number of consecutive packet losses on the first device side.

[0199] The first quantity can be determined based on the total transmission time of the first data packet, the transmission period of the first data packet, and the number of first data packets actually received by the first device. For example, if consecutive packet loss occurs for the first time (i.e., no packet loss occurred before, and no first data packet has been received since the start of packet loss), the total transmission time of the first data packet can be divided by the transmission period of the first data packet to obtain the total number of first data packets sent by the second device. Subtracting the number of first data packets actually received by the first device from the total number of first data packets sent by the second device gives the number of consecutive packet losses, i.e., the first quantity. As another example, if packet loss has occurred before and consecutive packet loss occurs again, the total transmission time of the first data packet can be calculated from the moment the first device last successfully received the first data packet. Dividing the total transmission time of the first data packet by the transmission period of the first data packet gives the total number of first data packets sent by the second device. Subtracting the number of first data packets actually received by the first device from the total number of first data packets sent by the second device gives the number of consecutive packet losses, i.e., the first quantity.

[0200] In some embodiments, the first capability information is used to indicate whether the first device supports determining a first duration, wherein the first duration is the duration during which the first device has not received the first data packet continuously.

[0201] The first duration can be referred to as the duration of continuous packet loss by the first device. The first device supports determining the first duration, which can be understood as the first device having the function of statistically analyzing the duration of continuous packet loss. The first device can determine the first duration based on a timer (e.g., timer T1). For example, when the first device detects that the expected first data packet has not been received, it can start timer T1.

[0202] In some embodiments, the first capability information is used to indicate whether the first device supports determining a second quantity, wherein the second quantity is the number of second data packets continuously sent by the first protocol layer to the second protocol layer.

[0203] The second quantity can be understood as the number of times the first protocol layer continuously sends the second data packet to the upper layer. The first device can determine the second quantity based on a counter (e.g., counter N1). For example, counter N1 starts counting when the first protocol layer starts sending the second data packet to the upper layer. The value of counter N1 is incremented by 1 each time the first protocol layer sends the second data packet to the upper layer.

[0204] In some embodiments, the first capability information is used to indicate whether the first device supports determining a second duration, wherein the second duration is the duration for which the first protocol layer continuously sends the second data packet to the second protocol layer.

[0205] The second duration can be understood as the duration during which the first protocol layer continuously sends the second data packet to the upper layer. The first device can determine the second duration based on a timer (e.g., timer T2). For example, timer T2 is started when the first protocol layer first sends the second data packet to the upper layer.

[0206] In this application embodiment, the first capability information may be carried in one or more of the following: radio resource control (RRC) messages, non-access stratum (NAS) messages, auxiliary messages of the first device, medium access control control element (MAC CE), packet data convergence protocol (PDCP) layer control signaling, and session initiation protocol (SIP) messages.

[0207] The assistance message from the first device may include UE assistance information.

[0208] PDCP layer control signaling may include PDCP control protocol data unit (PDCP control PDU).

[0209] In some embodiments, the first device actively sends first capability information to the second device.

[0210] If the first device actively sends the first capability information, the first device can autonomously determine when to send the first capability information.

[0211] In other embodiments, the first device responds to a request from the second device by sending first capability information to the second device.

[0212] For example, if the second device finds that it does not have the current capability information of the first device, the second device sends a request to the first device to request the first device to send its capability information.

[0213] For example, if the second device discovers that the existing capability information of the first device has expired, the second device sends a request to the first device to request the first device to send its capability information.

[0214] If the first device sends first capability information in response to a request from the second device, the timing of the first device sending the first capability information may be indicated by the second device.

[0215] This application does not limit the timing of the first device sending the first capability information. Taking the IMS voice service based on NB-IoT NTN as an example, the timing of the first device sending the first capability information includes, but is not limited to, the following: before performing IMS registration, during the IMS registration process, before initiating a call after IMS registration is completed, during the call setup process, and after the call setup is completed.

[0216] To better understand the communication method provided in the embodiments of this application, please refer to the following: Figures 9 to 11 This paper describes the communication method provided in this application embodiment in more detail, taking downlink transmission in NB-IoT NTN voice calls as an example. In Embodiments 1 and 2 below, the initiator or receiver of the voice call is not limited. Embodiments 1 and 2 can be applied to the following scenarios: scenarios where the UE is the caller, scenarios where the UE is the called party, and scenarios where the UE and eNB call simultaneously.

[0217] like Figure 9 As shown, both the communication method provided in Embodiment 1 and the communication method provided in Embodiment 2 include steps S910 to S950. The difference between Embodiment 1 and Embodiment 2 lies in the different methods of generating virtual data packets. Steps S910 to S950 will be described in detail below.

[0218] In step S910, the UE reports its capability information to the eNB.

[0219] UE capability information is used to indicate whether the UE supports generating virtual data packets. In addition, UE capability information is also used to indicate at least one of the following: whether the UE supports calculating the number of consecutive packet losses; whether the UE supports timer T1 to count the duration of consecutive packet losses; whether the UE supports counter N1 to count the number of times the UE sends virtual data packets to the upper layer; and whether the UE supports timer T2 to count the duration of sending virtual data packets.

[0220] If the UE supports calculating consecutive packet loss counts, when the first consecutive packet loss occurs (i.e., no packet loss has occurred before, and no data packets have been received since the start of packet loss), the total number of data packets that should have been received can be calculated by dividing the total data packet transmission time by the transmission period. The consecutive packet loss count is obtained by subtracting the number of data packets actually received from the total number of data packets that should have been received. If packet loss has occurred before and consecutive packet loss occurs again, the count can be calculated by starting the time from the last successfully received data packet and dividing the counted time by the transmission period.

[0221] If the UE supports timer T1, the UE starts timer T1 when it detects that the expected data packet has not been received.

[0222] If the UE supports counter N1, the UE increments the value of counter N1 by one each time it sends a virtual data packet to the upper layer.

[0223] If the UE supports timer T2, the UE starts timer T2 when it first sends a virtual data packet.

[0224] The UE reports UE capability information through one or more of the following messages: RRC message, NAS message, UE assistance information, MAC CE, PDCP control PDU, and SIP message.

[0225] The UE proactively reports its capability information to the eNB or reports it upon receiving a request from the eNB. If the eNB finds no UE capability information or that existing UE capability information has expired, it will request the UE to report its capability information. If the UE proactively reports its capability information, the UE determines when to report it. If the UE reports its capability information upon receiving a request from the eNB, the eNB instructs the UE on when to report the capability information. The UE can report its capability information at the following times: before performing IMS registration, during IMS registration, after IMS registration is completed and before initiating a call, during call setup, and after call setup is completed.

[0226] In step S920, the UE receives the RRC reconfiguration message sent by the eNB and determines the triggering conditions and transmission method of the virtual data packet based on the RRC reconfiguration message.

[0227] The RRC reconfiguration message includes one or more of the following parameters: MaxConsecutivePacketLossThreshold, indicating the threshold M, representing the maximum number of consecutive packet losses allowed by the ROHC mechanism; PacketLossTimer, indicating the duration of timer T1, representing the longest consecutive packet loss duration allowed by the ROHC mechanism; VirtualPacketSendingCycle, indicating the virtual packet sending cycle T, representing the time interval between the UE sending virtual packets to the upper layer; MaxVirtualPacketThreshold, indicating the threshold N, representing the maximum number of virtual packets that can be sent; and VirtualPacketSendingTimer, indicating the duration of timer T2, representing the longest continuous sending time of virtual packets that can be sent.

[0228] The values ​​of the above parameters are specified by the protocol. Alternatively, the values ​​of the above parameters are determined by the eNB and notified to the UE. Or, the values ​​of the above parameters are determined by the eNB based on the UE's suggestion (the UE suggests the base station to configure the values ​​through UE Assistance Information). For GEO scenarios, where channel conditions are poor, a larger consecutive packet loss threshold or a longer consecutive packet loss duration is configured. For LEO scenarios, where channel conditions are relatively good, a smaller consecutive packet loss threshold or a shorter consecutive packet loss duration is configured.

[0229] After receiving the RRC reconfiguration message, the UE parses it at the RRC layer to obtain the configuration information and then passes it to the lower layer (PDCP layer, RLC layer, or MAC layer). The lower layer stores the configuration information. Based on the parameter values, the UE determines the triggering conditions for the virtual data packet.

[0230] In step S930, if the triggering conditions for the virtual data packet are met, the UE generates a virtual data packet.

[0231] like Figure 9 As shown, the eNB sends data packets to the UE, and continuous packet loss begins starting with data packet n. The UE monitors these continuous packet loss events based on its own capabilities and stored configuration information to determine whether the triggering conditions for virtual data packets are met.

[0232] If the triggering conditions for a virtual data packet are not met, the UE does not need to generate a virtual data packet. If the number of consecutive packet losses calculated by the UE is less than the threshold M and timer T1 has not expired, the UE continues to wait to receive data packets sent by the eNB. If the UE successfully receives data packets sent by the eNB before the triggering conditions for a virtual data packet are met, the UE stops calculating the number of consecutive packet losses and stops timer T1. Upon the next occurrence of a consecutive packet loss event, the UE recalculates the number of consecutive packet losses and restarts timer T1.

[0233] The UE generates a virtual data packet if the triggering conditions are met. For example, the triggering condition is met when the number of consecutive packet losses calculated by the UE is greater than or equal to the threshold M. Another example is when timer T1 expires.

[0234] If the triggering conditions for a virtual data packet are met, the UE determines how to generate the virtual data packet. The UE's MAC layer sends a request to the upper layer (PDCP layer, RRC layer, or application layer) to obtain the most recently successfully received and decompressed complete data packet. The MAC layer generates a virtual data packet based on the data packet obtained from the upper layer. Subsequently, the MAC layer performs ROHC header compression on the generated virtual data packet to obtain a compressed virtual data packet. The MAC layer pre-integrates the ROHC module and maintains the compressor in an efficient compression state. The MAC layer performs the above compression operation by simulating the eNB's ROHC behavior.

[0235] In step S940, the UE sends a virtual data packet to the upper layer.

[0236] After compressing the generated virtual data packets, the UE periodically sends the compressed virtual data packets to the upper layer (PDCP layer or RRC layer) according to the configuration information. At the same time, counter N1 starts counting and timer T2 is started.

[0237] The timing at which the UE begins sending virtual data packets to the upper layer depends on the UE's capabilities, either configured by the eNB or specified by the protocol. For example, the UE may generate the first virtual data packet and perform compression before immediately sending the compressed virtual data packet to the upper layer.

[0238] In step S950, if the UE successfully receives the data packet sent by the eNB, the generation of virtual data packets is stopped.

[0239] While sending virtual data packets, the UE continues to attempt to receive data packets sent by the eNB. When the UE successfully receives a data packet sent by the eNB, the UE stops generating virtual data packets.

[0240] In step S930, the UE generates a virtual data packet. The methods for generating the virtual data packet differ between Embodiment 1 and Embodiment 2. The methods for generating the virtual data packet provided in Embodiment 1 and Embodiment 2 are described below.

[0241] Example 1 In Example 1, the MAC layer modifies the data packet based on the most recently successfully received data packet to generate a virtual data packet.

[0242] like Figure 10 As shown, when the triggering conditions for a virtual data packet are met, the MAC layer sends a request to the upper layer (PDCP layer, RRC layer, or application layer) to obtain the most recently successfully received and decompressed complete data packet, i.e., the decompressed data packet N. The MAC layer modifies data packet N to generate a virtual data packet with a complete header. The virtual data packet generated by the MAC layer includes a payload, IP header, UDP header, and RTP header.

[0243] The MAC layer modifies the payload of data packet N. For example, it fills each pair of bits in the payload of data packet N with 0 or 1, thus creating a virtual data packet payload.

[0244] The MAC layer modifies the header of data packet N. For continuous voice packets within the same data stream during an NB-IoT NTN voice call, most fields in the headers of different data packets remain unchanged. Typically, only the identifier field in the IP header and the sequence number and timestamp fields in the RTP header change. Based on data packet N, the MAC layer increments the values ​​of the identifier field in the IP header and the sequence number field in the RTP header of each virtual data packet generated by the MAC layer. Furthermore, for each virtual data packet generated, the timestamp field in the RTP header of the virtual data packet is increased linearly. The increment of the timestamp field is calculated by the UE itself or configured by the eNB. The increment can be set according to the number of voice packet samples. Each increment is equal to the data packet transmission interval multiplied by the sampling rate. For example, if the data packet transmission interval is 20ms and the sampling rate is 8kHz, then the timestamp field increment is 160 for each new virtual data packet.

[0245] After the MAC layer generates a virtual data packet, it performs ROHC header compression on the virtual data packet to obtain the compressed virtual data packet.

[0246] Example 2 In Example 2, the MAC layer copies the most recently successfully received data packet to generate a virtual data packet. This method can reduce voice call latency and decrease UE power consumption.

[0247] like Figure 11 As shown, when the triggering conditions for a virtual data packet are met, the MAC layer sends a request to the upper layer (PDCP layer, RRC layer, or application layer) to obtain the most recently successfully received and decompressed complete data packet, i.e., the decompressed data packet N. The MAC layer copies data packet N to generate a virtual data packet with a complete header. The virtual data packet generated by the MAC layer includes a payload, IP header, UDP header, RTP header, and RLC header.

[0248] The MAC layer obtains the payload of the virtual data packet by copying the payload of data packet N.

[0249] The MAC layer obtains the IP header, UDP header, and RTP header of the virtual data packet by copying the IP header, UDP header, and RTP header of data packet N.

[0250] The MAC layer obtains the RLC header of the virtual data packet by modifying the RLC SN in the RLC header of data packet N. For example, the MAC layer increments the RLC SN in the RLC header of data packet N by 1 to obtain the RLC header of the virtual data packet. Furthermore, for each subsequent virtual data packet generated, the RLC SN in the RLC header of the previously generated virtual data packet is incremented by 1. This method prevents virtual data packets from being discarded by the UE's RLC layer.

[0251] Furthermore, the UE adds a specific identifier to the generated virtual data packets. When the upper layer receives the virtual data packets, it can effectively distinguish the virtual data packets from the data packets sent by the eNB based on this identifier, thereby avoiding upper layer decompression errors caused by outdated header information of the virtual data packets.

[0252] In Embodiment 1 and Embodiment 2, when data packets are continuously lost, the UE avoids the compressor state rollback by generating virtual data packets, thereby saving air interface resources and ensuring call quality.

[0253] The above combination Figures 3 to 11 The communication method provided in the embodiments of this application has been described in detail below, in conjunction with... Figure 12 and Figure 13 The present application provides a detailed description of the apparatus embodiments. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the preceding method embodiments.

[0254] Figure 12 This is a schematic diagram of the structure of the communication device 1200 provided in an embodiment of this application. Figure 12 The communication device 1200 shown is a first device. The communication device 1200 includes a processing unit 1210. The processing unit 1210 is used to generate a second data packet at a first protocol layer and send the second data packet to a second protocol layer when the first device does not receive a first data packet, wherein: the first data packet is a data packet sent by the second device to the first device, and the first data packet is a data packet that has passed through ROHC; the second protocol layer is the upper layer of the first protocol layer.

[0255] In some implementations, the second data packet is generated based on a third data packet, which is a data packet obtained by decompressing the last first data packet successfully received by the first device.

[0256] In some implementations, the first header of the second data packet is exactly the same as the first header of the third data packet.

[0257] In some implementations, the sequence number in the second header of the second data packet is different from the sequence number in the second header of the third data packet.

[0258] In some implementations, the second header includes an RLC header.

[0259] In some implementations, the second data packet includes a first identifier, which is used by the second protocol layer to distinguish the second data packet from the first data packet.

[0260] In some implementations, the value of the first field in the first header of the second data packet is different from the value of the first field in the first header of the third data packet.

[0261] In some implementations, the first field includes one or more of the following: an identification field in the IP header, a sequence number field in the RTP header, and a timestamp field in the RTP header.

[0262] In some implementations, the timing of sending the second data packet is determined based on protocol predefined information or the configuration information of the second device; and / or, the period of sending the second data packet is determined based on protocol predefined information or the configuration information of the second device.

[0263] In some implementations, the processing unit 1210 is specifically used to generate the second data packet when the first condition is met.

[0264] In some implementations, the first condition includes one or more of the following: the number of first data packets that the first device has not received consecutively is greater than or equal to a first quantity threshold; the duration for which the first device has not received the first data packets consecutively is greater than or equal to a first duration threshold.

[0265] In some implementations, the processing unit 1210 is specifically used to: stop generating the second data packet when the second condition is met.

[0266] In some implementations, the second condition includes one or more of the following: the first device successfully receives the first data packet; the number of second data packets continuously sent is greater than or equal to a second quantity threshold; the duration of continuously sending the second data packets is greater than or equal to a second duration threshold.

[0267] In some implementations, the first condition and / or the second condition are determined based on protocol predefined information or the configuration information of the second device.

[0268] In some implementations, the processing unit is further configured to: perform ROHC on the second data packet before sending the second data packet.

[0269] In some implementations, the device further includes a transceiver unit for sending first capability information to the second device, wherein the first capability information indicates one or more of the following: whether the first device supports generating the second data packet; whether the first device supports determining a first quantity, wherein the first quantity is the number of first data packets that the first device has not received consecutively; whether the first device supports determining a first duration, wherein the first duration is the duration for which the first device has not received the first data packet consecutively; whether the first device supports determining a second quantity, wherein the second quantity is the number of second data packets that the first protocol layer has consecutively sent to the second protocol layer; and whether the first device supports determining a second duration, wherein the second duration is the duration for which the first protocol layer has continuously sent the second data packet to the second protocol layer.

[0270] In some implementations, the first capability information is carried in one or more of the following: Radio Resource Control (RRC) message, Non-Access Stratum (NAS) message, auxiliary message of the first device, Media Access Control (MAC) CE message, Packet Data Convergence Protocol (PDCP) layer control signaling, and Session Initiation Protocol (SIP) message.

[0271] In some implementations, the first protocol layer includes a Media Access Control (MAC) layer or an RLC layer.

[0272] In some implementations, the first data packet is a data packet sent by the second device through a narrowband Internet of Things (NB-IoT) NTN network; and / or, the first data packet is used for voice services.

[0273] Figure 13 This is a schematic diagram of the structure of a communication device applicable to the embodiments of this application. Figure 13 The dashed lines indicate that the unit or module is optional. The device 1300 can be used to implement the methods described in the above method embodiments. The device 1300 can be a chip, a terminal device, or a network device.

[0274] Apparatus 1300 may include one or more processors 1310. The processor 1310 may support apparatus 1300 in implementing the methods described in the preceding method embodiments. The processor 1310 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0275] The apparatus 1300 may further include one or more memories 1320. The memories 1320 store a program that can be executed by the processor 1310, causing the processor 1310 to perform the methods described in the preceding method embodiments. The memories 1320 may be independent of the processor 1310 or integrated within the processor 1310.

[0276] The device 1300 may also include a transceiver 1330. The processor 1310 can communicate with other devices or chips via the transceiver 1330. For example, the processor 1310 can send and receive data with other devices or chips via the transceiver 1330.

[0277] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to the communication device provided in this application, and the program causes a computer to execute the methods performed by the communication device in various embodiments of this application.

[0278] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the communication device provided in this application embodiment, and the program causes a computer to execute the methods performed by the communication device in various embodiments of this application.

[0279] This application also provides a computer program. This computer program can be applied to the communication device provided in this application, and causes the computer to execute the methods performed by the communication device in various embodiments of this application.

[0280] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0281] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0282] In the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0283] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship of instruction and being instructed, configuration and being configured, etc.

[0284] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0285] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0286] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0287] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0288] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0289] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0290] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0291] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0292] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method, characterized in that, include: If the first device does not receive the first data packet, the first protocol layer of the first device generates a second data packet and sends the second data packet to the second protocol layer, wherein: The first data packet is a data packet sent from the second device to the first device, and the first data packet is a data packet with robust header compression (ROHC). The second protocol layer is the upper layer of the first protocol layer.

2. The method according to claim 1, characterized in that, The second data packet is generated based on the third data packet, which is a data packet obtained by decompressing the last first data packet successfully received by the first device.

3. The method according to claim 2, characterized in that, The first header of the second data packet is exactly the same as the first header of the third data packet.

4. The method according to claim 2 or 3, characterized in that, The sequence number in the second header of the second data packet is different from the sequence number in the second header of the third data packet.

5. The method according to claim 4, characterized in that, The second header includes the Radio Link Control (RLC) header.

6. The method according to any one of claims 2-5, characterized in that, The second data packet includes a first identifier, which is used by the second protocol layer to distinguish the second data packet from the first data packet.

7. The method according to claim 2, characterized in that, The value of the first field in the first header of the second data packet is different from the value of the first field in the first header of the third data packet.

8. The method according to claim 7, characterized in that, The first field includes one or more of the following: the identifier field of the Internet Protocol (IP) header, the sequence number field of the Real-Time Transport Protocol (RTP) header, and the timestamp field of the RTP header.

9. The method according to any one of claims 2-8, characterized in that, The first header includes one or more of the following: RTP header, User Datagram Protocol (UDP) header, and IP header.

10. The method according to any one of claims 1-9, characterized in that: The timing of sending the second data packet is determined based on predefined protocol information or the configuration information of the second device; and / or, The sending period of the second data packet is determined based on protocol predefined information or the configuration information of the second device.

11. The method according to any one of claims 1-10, characterized in that, The first protocol layer generates a second data packet, including: The first protocol layer generates the second data packet when the first condition is met.

12. The method according to claim 11, characterized in that, The first condition includes one or more of the following: The number of the first data packets that the first device has not received consecutively is greater than or equal to a first quantity threshold. The duration during which the first device continuously fails to receive the first data packet is greater than or equal to a first duration threshold.

13. The method according to any one of claims 1-12, characterized in that, The method further includes: If the second condition is met, the first protocol layer stops generating the second data packet.

14. The method according to claim 13, characterized in that, The second condition includes one or more of the following: The first device successfully received the first data packet; The number of the second data packets continuously sent by the first protocol layer is greater than or equal to the second quantity threshold; The duration for which the first protocol layer continuously sends the second data packet is greater than or equal to the second duration threshold.

15. The method according to any one of claims 11-14, characterized in that, The first condition and / or the second condition are determined based on protocol predefined information or the configuration information of the second device.

16. The method according to any one of claims 1-15, characterized in that, Before the first protocol layer sends the second data packet, the method further includes: The first protocol layer performs ROHC on the second data packet.

17. The method according to any one of claims 1-16, characterized in that, The method further includes: The first device sends first capability information to the second device, wherein the first capability information is used to indicate one or more of the following: Does the first device support generating the second data packet? Does the first device support determining a first quantity, wherein the first quantity is the number of first data packets that the first device has not received consecutively; Does the first device support determining a first duration, wherein the first duration is the duration during which the first device has not continuously received the first data packet; Does the first device support determining a second quantity, wherein the second quantity is the number of second data packets continuously sent from the first protocol layer to the second protocol layer; Does the first device support determining a second duration, wherein the second duration is the duration for which the first protocol layer continuously sends the second data packet to the second protocol layer? 18. The method according to claim 17, characterized in that, The first capability information is carried in one or more of the following: Radio Resource Control (RRC) message, Non-Access Stratum (NAS) message, auxiliary message of the first device, Media Access Control (MAC) Control Element (CE), Packet Data Convergence Protocol (PDCP) layer control signaling, and Session Initiation Protocol (SIP) message.

19. The method according to any one of claims 1-18, characterized in that, The first protocol layer includes a Media Access Control (MAC) layer or an RLC layer.

20. The method according to any one of claims 1-19, characterized in that, The first data packet is a data packet sent by the second device through the narrowband Internet of Things non-terrestrial network NB-IoT NTN; and / or, the first data packet is used for voice services.

21. A communication device, characterized in that, The communication device is a first device, and the device includes: The processing unit is configured to generate a second data packet at a first protocol layer and send the second data packet to a second protocol layer when the first device does not receive the first data packet, wherein: The first data packet is a data packet sent by the second device to the first device, and the first data packet is a data packet with robust header compression (ROHC). The second protocol layer is the upper layer of the first protocol layer.

22. The device according to claim 21, characterized in that, The second data packet is generated based on the third data packet, which is a data packet obtained by decompressing the last first data packet successfully received by the first device.

23. The device according to claim 22, characterized in that, The first header of the second data packet is exactly the same as the first header of the third data packet.

24. The device according to claim 22 or 23, characterized in that, The sequence number in the second header of the second data packet is different from the sequence number in the second header of the third data packet.

25. The device according to claim 24, characterized in that, The second header includes the Radio Link Control (RLC) header.

26. The device according to any one of claims 22-25, characterized in that, The second data packet includes a first identifier, which is used by the second protocol layer to distinguish the second data packet from the first data packet.

27. The device according to claim 22, characterized in that, The value of the first field in the first header of the second data packet is different from the value of the first field in the first header of the third data packet.

28. The device according to claim 27, characterized in that, The first field includes one or more of the following: the identifier field of the Internet Protocol (IP) header, the sequence number field of the Real-Time Transport Protocol (RTP) header, and the timestamp field of the RTP header.

29. The device according to any one of claims 22-28, characterized in that, The first header includes one or more of the following: RTP header, User Datagram Protocol (UDP) header, and IP header.

30. The method according to any one of claims 21-29, characterized in that: The timing of sending the second data packet is determined based on predefined protocol information or the configuration information of the second device; and / or, The sending period of the second data packet is determined based on protocol predefined information or the configuration information of the second device.

31. The device according to any one of claims 21-30, characterized in that, The processing unit is specifically used for: If the first condition is met, the second data packet is generated.

32. The device according to claim 31, characterized in that, The first condition includes one or more of the following: The number of the first data packets that the first device has not received consecutively is greater than or equal to a first quantity threshold. The duration during which the first device continuously fails to receive the first data packet is greater than or equal to a first duration threshold.

33. The device according to any one of claims 21-32, characterized in that, The processing unit is specifically used for: If the second condition is met, stop generating the second data packet.

34. The method according to claim 33, characterized in that, The second condition includes one or more of the following: The first device successfully received the first data packet; The number of the second data packets sent consecutively is greater than or equal to the second quantity threshold; The duration of continuously sending the second data packet is greater than or equal to the second duration threshold.

35. The device according to any one of claims 21-34, characterized in that, The first condition and / or the second condition are determined based on protocol predefined information or the configuration information of the second device.

36. The device according to any one of claims 21-35, characterized in that, The processing unit is also used for: Before sending the second data packet, perform ROHC on the second data packet.

37. The device according to any one of claims 21-36, characterized in that, The device further includes a transceiver unit for sending first capability information to the second device, wherein the first capability information is used to indicate one or more of the following: Does the first device support generating the second data packet? Does the first device support determining a first quantity, wherein the first quantity is the number of first data packets that the first device has not received consecutively; Does the first device support determining a first duration, wherein the first duration is the duration during which the first device has not continuously received the first data packet; Does the first device support determining a second quantity, wherein the second quantity is the number of second data packets continuously sent from the first protocol layer to the second protocol layer; Does the first device support determining a second duration, wherein the second duration is the duration for which the first protocol layer continuously sends the second data packet to the second protocol layer? 38. The device according to claim 37, characterized in that, The first capability information is carried in one or more of the following: Radio Resource Control (RRC) message, Non-Access Stratum (NAS) message, auxiliary message of the first device, Media Access Control (MAC) Control Element (CE), Packet Data Convergence Protocol (PDCP) layer control signaling, and Session Initiation Protocol (SIP) message.

39. The device according to any one of claims 21-38, characterized in that, The first protocol layer includes a Media Access Control (MAC) layer or an RLC layer.

40. The device according to any one of claims 21-39, characterized in that, The first data packet is a data packet sent by the second device through the narrowband Internet of Things non-terrestrial network NB-IoT NTN; and / or, the first data packet is used for voice services.

41. A communication device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or send signals so that the communication device performs the method as described in claims 1 to 20.

42. An apparatus, characterized in that, Includes a processor for calling a program from memory to cause the device to perform the method as claimed in claims 1 to 20.

43. A chip, characterized in that, Includes a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in claims 1 to 20.

44. A computer-readable storage medium, characterized in that, It contains a program that causes a computer to perform the method as described in claims 1 to 20.

45. A computer program product, characterized in that, Includes a program that causes a computer to perform the method as described in claims 1 to 20.

46. ​​A computer program, characterized in that, The computer program causes the computer to perform the method as described in claims 1 to 20.

Images