CN117501741A

CN117501741A - Header compression method and device, terminal equipment and network equipment

Info

Publication number: CN117501741A
Application number: CN202180099491.8A
Authority: CN
Inventors: 王淑坤; 付喆
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2021-10-09
Filing date: 2021-10-09
Publication date: 2024-02-02
Also published as: WO2023056641A1

Abstract

The embodiment of the application provides a header compression method and device, terminal equipment and network equipment, wherein the method comprises the following steps: the terminal equipment receives first information sent by the network equipment, and establishes a header compression context based on the first information; and the terminal equipment receives the compressed packet sent by the network equipment in a multicast mode or a broadcast mode, and decompresses the compressed packet based on the header compression context.

Description

Header compression method and device, terminal equipment and network equipment

Technical Field

The embodiment of the application relates to the technical field of mobile communication, in particular to a header compression method and device, terminal equipment and network equipment.

Background

In a New Radio (NR) system, many scenarios need to support service requirements of a multicast type and a broadcast type, for example, in the internet of vehicles, the industrial internet, and so on. It is necessary to introduce multicast type and broadcast type multimedia broadcast service (Multimedia Broadcast Service, MBS) services in the NR.

In the NR, whether the multicast type MBS service or the broadcast type MBS service, in the process of transmitting the MBS service on the network side, some terminal equipment is added into the MBS service earlier, and some terminal equipment is added into the MBS service later. For terminal devices that join MBS services later, the network side may already transmit MBS services by using compressed packets, and how such terminal devices decompress compressed packets is a problem to be solved.

Disclosure of Invention

Embodiments of the present application provide a header compression method and apparatus, a terminal device, a network device, a chip, a computer readable storage medium, a computer program product, and a computer program.

The header compression method provided by the embodiment of the application comprises the following steps:

the terminal equipment receives first information sent by the network equipment, and establishes a header compression context based on the first information;

and the terminal equipment receives the compressed packet sent by the network equipment in a multicast mode or a broadcast mode, and decompresses the compressed packet based on the header compression context.

the network equipment sends first information to the terminal equipment, wherein the first information is used for the terminal equipment to establish a header compression context;

the network device sends a compressed packet to the terminal device in a multicast mode or a broadcast mode, and the header compression context is used for the terminal device to decompress the compressed packet.

The header compression device provided by the embodiment of the application is applied to terminal equipment, and comprises:

the receiving unit is used for receiving the first information sent by the network equipment;

a setting unit configured to set up a header compression context based on the first information;

The receiving unit is further configured to receive a compressed packet sent by the network device in a multicast manner or a broadcast manner;

and the processing unit is used for decompressing the compressed packet based on the header compression context.

The header compression device provided by the embodiment of the application is applied to network equipment, and comprises:

a transmitting unit, configured to transmit first information to a terminal device, where the first information is used for the terminal device to establish a header compression context; and sending a compressed packet to the terminal equipment in a multicast mode or a broadcast mode, wherein the header compression context is used for the terminal equipment to decompress the compressed packet.

The terminal equipment provided by the embodiment of the application comprises a processor and a memory. The memory is used for storing a computer program, and the processor is used for calling and running the computer program stored in the memory to execute the head compression method.

The network device provided by the embodiment of the application comprises a processor and a memory. The memory is used for storing a computer program, and the processor is used for calling and running the computer program stored in the memory to execute the head compression method.

The chip provided by the embodiment of the application is used for realizing the head compression method.

Specifically, the chip includes: and a processor for calling and running the computer program from the memory, so that the device mounted with the chip executes the head compression method described above.

The embodiment of the application provides a computer readable storage medium for storing a computer program, which causes a computer to execute the above-mentioned header compression method.

The computer program product provided by the embodiment of the application comprises computer program instructions, wherein the computer program instructions enable a computer to execute the head compression method.

The computer program provided in the embodiments of the present application, when executed on a computer, causes the computer to perform the header compression method described above.

By the technical scheme, how the terminal equipment establishes the header compression context is clarified in multicast or broadcast, so that the header compression can be performed on the compression packet sent by the network equipment in a multicast mode or a broadcast mode based on the header compression context, and the terminal equipment can normally receive the compression packet of multicast or broadcast.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

FIG. 1 is a schematic diagram of an application scenario according to an embodiment of the present application;

fig. 2 is a schematic diagram of a protocol stack corresponding to a PTM mode and a PTP mode in the embodiment of the present application;

fig. 3 is a schematic diagram of MBS service transmission according to PTM mode and PTP mode provided in the embodiment of the present application;

FIG. 4 is a flow chart of a header compression method provided in an embodiment of the present application;

FIG. 5 is a schematic diagram showing the structural components of a head compression device according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram II of the structural composition of a head compression device according to an embodiment of the present disclosure;

fig. 7 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

FIG. 8 is a schematic block diagram of a chip of an embodiment of the present application;

fig. 9 is a schematic block diagram of a communication system provided in an embodiment of the present application.

Detailed Description

The following description of the technical solutions in the embodiments of the present application will be made with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

Fig. 1 is a schematic diagram of an application scenario according to an embodiment of the present application.

As shown in fig. 1, communication system 100 may include a terminal device 110 and a network device 120. Network device 120 may communicate with terminal device 110 over the air interface. Multi-service transmission is supported between terminal device 110 and network device 120.

It should be understood that the present embodiments are illustrated by way of example only with respect to communication system 100, but the present embodiments are not limited thereto. That is, the technical solution of the embodiment of the present application may be applied to various communication systems, for example: long term evolution (Long Term Evolution, LTE) systems, LTE time division duplex (Time Division Duplex, TDD), universal mobile telecommunications system (Universal Mobile Telecommunication System, UMTS), internet of things (Internet of Things, ioT) systems, narrowband internet of things (Narrow Band Internet of Things, NB-IoT) systems, enhanced Machine-type-Type Communications (eMTC) systems, 5G communication systems (also known as New Radio (NR) communication systems), or future communication systems, etc.

In the communication system 100 shown in fig. 1, the network device 120 may be an access network device in communication with the terminal device 110. The access network device may provide communication coverage for a particular geographic area and may communicate with terminal devices 110 (e.g., UEs) located within the coverage area.

The network device 120 may be an evolved base station (Evolutional Node B, eNB or eNodeB) in a long term evolution (Long Term Evolution, LTE) system, or a next generation radio access network (Next Generation Radio Access Network, NG RAN) device, or a base station (gNB) in a NR system, or a radio controller in a cloud radio access network (Cloud Radio Access Network, CRAN), or the network device 120 may be a relay station, an access point, a vehicle device, a wearable device, a hub, a switch, a bridge, a router, or a network device in a future evolved public land mobile network (Public Land Mobile Network, PLMN), etc.

Terminal device 110 may be any terminal device including, but not limited to, a terminal device that employs a wired or wireless connection with network device 120 or other terminal devices.

For example, the terminal device 110 may refer to an access terminal, user Equipment (UE), subscriber unit, subscriber station, mobile station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or User Equipment. An access terminal may be a cellular telephone, a cordless telephone, a session initiation protocol (Session Initiation Protocol, SIP) phone, an IoT device, a satellite handset, a wireless local loop (Wireless Local Loop, WLL) station, a personal digital assistant (Personal Digital Assistant, PDA), a handset with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device, a terminal device in a 5G network or a terminal device in a future evolution network, etc.

The terminal Device 110 may be used for Device-to-Device (D2D) communication.

The wireless communication system 100 may further comprise a core network device 130 in communication with the base station, which core network device 130 may be a 5G core,5gc device, e.g. an access and mobility management function (Access and Mobility Management Function, AMF), further e.g. an authentication server function (Authentication Server Function, AUSF), further e.g. a user plane function (User Plane Function, UPF), further e.g. a session management function (Session Management Function, SMF). Optionally, the core network device 130 may also be a packet core evolution (Evolved Packet Core, EPC) device of the LTE network, for example a session management function+a data gateway (Session Management Function + Core Packet Gateway, smf+pgw-C) device of the core network. It should be appreciated that SMF+PGW-C may perform the functions performed by both SMF and PGW-C. In the network evolution process, the core network device may also call other names, or form a new network entity by dividing the functions of the core network, which is not limited in this embodiment of the present application.

Communication may also be achieved by establishing connections between various functional units in the communication system 100 through a next generation Network (NG) interface.

For example, the terminal device establishes an air interface connection with the access network device through an NR interface, and is used for transmitting user plane data and control plane signaling; the terminal equipment can establish control plane signaling connection with AMF through NG interface 1 (N1 for short); an access network device, such as a next generation radio access base station (gNB), can establish a user plane data connection with a UPF through an NG interface 3 (N3 for short); the access network equipment can establish control plane signaling connection with AMF through NG interface 2 (N2 for short); the UPF can establish control plane signaling connection with the SMF through an NG interface 4 (N4 for short); the UPF can interact user plane data with the data network through an NG interface 6 (N6 for short); the AMF may establish a control plane signaling connection with the SMF through NG interface 11 (N11 for short); the SMF may establish a control plane signaling connection with the PCF via NG interface 7 (N7 for short).

Fig. 1 exemplarily illustrates one base station, one core network device, and two terminal devices, alternatively, the wireless communication system 100 may include a plurality of base station devices and each base station may include other number of terminal devices within a coverage area, which is not limited in the embodiment of the present application.

It should be noted that fig. 1 illustrates, by way of example, a system to which the present application is applicable, and of course, the method shown in the embodiment of the present application may be applicable to other systems. Furthermore, the terms "system" and "network" are often used interchangeably herein. The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship. It should also be understood that, in the embodiments of the present application, the "indication" may be a direct indication, an indirect indication, or an indication that there is an association relationship. For example, a indicates B, which may mean that a indicates B directly, e.g., B may be obtained by a; it may also indicate that a indicates B indirectly, e.g. a indicates C, B may be obtained by C; it may also be indicated that there is an association between a and B. It should also be understood that, in the embodiments of the present application, reference to "corresponding" may mean that there is a direct correspondence or an indirect correspondence between the two, or may mean that there is an association between the two, or may be a relationship between an instruction and an indicated, configured, or the like. It should also be understood that "predefined" or "predefined rules" mentioned in the embodiments of the present application may be implemented by pre-storing corresponding codes, tables or other manners that may be used to indicate relevant information in devices (e.g., including terminal devices and network devices), and the present application is not limited to a specific implementation thereof. Such as predefined may refer to what is defined in the protocol. It should also be understood that, in the embodiments of the present application, the "protocol" may refer to a standard protocol in the field of communications, and may include, for example, an LTE protocol, an NR protocol, and related protocols applied in future communication systems, which are not limited in this application.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the following description is given of related technologies of the embodiments of the present application, and the following related technologies may be optionally combined with the technical solutions of the embodiments of the present application as an alternative, which all belong to the protection scope of the embodiments of the present application.

With the pursuit of speed, delay, high speed mobility, energy efficiency and diversity and complexity of future life business, the third generation partnership project (3 ^rd Generation Partnership Project,3 GPP) international standards organization began developing 5G. The main application scenario of 5G is: enhanced mobile Ultra-wideband (enhanced Mobile Broadband, emmbb), low latency high reliability communication (URLLC), large-scale Machine-based communication (mctc).

On the one hand, embbs still target users to obtain multimedia content, services and data, and their demand is growing very rapidly. On the other hand, since an eMBB may be deployed in different scenarios, such as indoors, urban, rural, etc., its capabilities and requirements are also quite different, so that detailed analysis must be performed in connection with a specific deployment scenario, not in general. Typical applications of URLLC include: industrial automation, electric power automation, remote medical operation (surgery), traffic safety guarantee and the like. Typical characteristics of mctc include: high connection density, small data volume, delay insensitive traffic, low cost and long service life of the module, etc.

At early deployment of NRs, full NR coverage is difficult to acquire, so typical network coverage is wide area LTE coverage and island coverage mode of NRs. And a large amount of LTE is deployed below 6GHz, and the frequency spectrum below 6GHz which can be used for 5G is few. NR must study spectral applications above 6GHz while high-band coverage is limited and signal fading is fast. Meanwhile, in order to protect the mobile operators from early investment in LTE, a working mode of tight coupling (tight interworking) between LTE and NR is proposed.

MBMS

MBMS is a technology for transmitting data from one data source to a plurality of terminal equipments through a shared network resource, which can effectively utilize the network resource while providing a multimedia service, and realize broadcasting and multicasting of a multimedia service of a higher rate (e.g., 256 kbps).

Due to the low MBMS spectrum efficiency, it is not sufficient to effectively carry and support the operation of the mobile tv type service. In LTE, 3GPP has therefore explicitly proposed to enhance the support capability for the downlink high speed MBMS service and to determine the design requirements for the physical layer and the air interface.

The 3gpp R9 introduces evolved MBMS (eMBMS) into LTE. eMBMS proposes the concept of a single frequency network (Single Frequency Network, SFN), i.e. a multimedia broadcast multicast service single frequency network (Multimedia Broadcast multicast service Single Frequency Network, MBSFN), wherein the MBSFN uses a unified frequency to simultaneously transmit traffic data in all cells, but synchronization between the cells is guaranteed. The method can greatly improve the overall signal-to-noise ratio distribution of the cell, and the frequency spectrum efficiency can be correspondingly and greatly improved. eMBMS implements broadcast and multicast of services based on IP multicast protocols.

In LTE or LTE-Advanced (LTE-a), MBMS has only a broadcast bearer mode and no multicast bearer mode. In addition, the reception of the MBMS service is applicable to terminal devices in an idle state or a connected state.

A single cell point-to-multipoint (Single Cell Point To Multiploint, SC-PTM) concept is introduced in 3gpp r13, SC-PTM being based on the MBMS network architecture.

MBMS introduces new logical channels including Single Cell multicast control channel (SC-MCCH) and Single Cell multicast transport channel (SC-MTCH) and Single Cell-Multicast Transport Channel. The SC-MCCH and SC-MTCH are mapped onto a Downlink-Shared Channel (DL-SCH), and further, the DL-SCH is mapped onto a physical Downlink Shared Channel (Physical Downlink Shared Channel, PDSCH), wherein the SC-MCCH and SC-MTCH belong to a logical Channel, the DL-SCH belongs to a transport Channel, and the PDSCH belongs to a physical Channel. The SC-MCCH and SC-MTCH do not support hybrid automatic repeat request (Hybrid Automatic Repeat reQuest, HARQ) operation.

MBMS introduces a new system information block (System Information Block, SIB) type, SIB20. Specifically, the configuration information of the SC-MCCH is transmitted through the SIB20, and one cell has only one SC-MCCH. The configuration information of the SC-MCCH comprises: the modification period of the SC-MCCH, the repetition period of the SC-MCCH, the radio frame and subframe for scheduling the SC-MCCH and other information. Further, 1) the boundary of the modification period of the SC-MCCH satisfies SFN mod m=0, where SFN represents a system frame number of the boundary, and m is a modification period (i.e., SC-MCCH-modification period) of the SC-MCCH configured in SIB20. 2) The radio frame of the scheduling SC-MCCH meets the following conditions: SFN mod MCCH-repetition period = MCCH-Offset, where SFN represents the system frame number of the radio frame, MCCH-repetition period represents the repetition period of the SC-MCCH, and MCCH-Offset represents the Offset of the SC-MCCH. 3) The subframes of the scheduling SC-MCCH are indicated by SC-MCCH-Subframe.

The SC-MCCH is scheduled through a physical downlink control channel (Physical Downlink Control Channel, PDCCH). In one aspect, a new radio network temporary identity (Radio Network Tempory Identity, RNTI), i.e., single Cell RNTI (SC-RNTI), is introduced to identify a PDCCH (e.g., SC-MCCH PDCCH) for scheduling the SC-MCCH, optionally with the SC-RNTI fixed value FFFC. On the other hand, a new RNTI, i.e., a single cell notification RNTI (Single Cell Notification RNTI, SC-N-RNTI) is introduced to identify a PDCCH (e.g., notification PDCCH) for indicating a change notification of the SC-MCCH, optionally, the SC-N-RNTI is fixed to a value of FFFB; further, the change notification may be indicated with one bit of 8 bits (bits) of DCI 1C. In LTE, the configuration information of SC-PTM is based on the SC-MCCH configured by SIB20, and then SC-MCCH configures SC-MTCH for transmitting service data.

Specifically, the SC-MCCH transmits only one message (i.e., scptm configuration) for configuring configuration information of the SC-PTM. The configuration information of the SC-PTM comprises: temporary mobile Group identity (Temporary Mobile Group Identity, TMGI), session identity (session id), group RNTI (G-RNTI), discontinuous reception (Discontinuous Reception, DRX) configuration information, SC-PTM service information of neighbor cells, and the like. Note that SC-PTM in R13 does not support the robust header compression (Robust Header Compression, ROHC) function.

The downlink discontinuous reception of the SC-PTM is controlled by the following parameters: onDurationTimerSCPTM, drx-InactivityTimerSCPTM, SC-MTCH-scheduling cycle, and SC-MTCH-scheduling offset.

When [ (SFN 10) +subframe number ] module (SC-MTCH-scheduling cycle) =sc-MTCH-scheduling offset is satisfied, a timer ondurationtimerscpm is started;

when receiving downlink PDCCH scheduling, starting a timer drx-InactivityTimerSCPTM;

the downstream SC-PTM service is received only when the timer onduration timerscpm or drx-incaactyitimerscpm is running.

The SC-PTM service continuity adopts the MBMS service continuity concept based on SIB15, namely a mode of SIB15 and MBMSInterestindication. The traffic continuity of the terminal device in idle state is based on the concept of frequency priority.

In the technical solution of the embodiment of the present application, a new SIB (referred to as a first SIB) is defined, where the first SIB includes configuration information of a first MCCH, where the first MCCH is a control channel of an MBMS service, in other words, the first SIB is used to configure configuration information of a control channel of an NR MBMS, alternatively, the control channel of the NR MBMS may also be referred to as an NR MCCH (i.e. the first MCCH).

Further, the first MCCH is used to carry the first signaling, and in the embodiment of the present application, the name of the first signaling is not limited, for example, the first signaling is signaling a, where the first signaling includes configuration information of at least one first MTCH, where the first MTCH is a traffic channel (also referred to as a data channel or a transport channel) of an MBMS service, and the first MTCH is used to transport MBMS service data (such as service data of NR MBMS). In other words, the first MCCH is used to configure configuration information of a traffic channel of the NR MBMS, alternatively, the traffic channel of the NR MBMS may also be called as NR MTCH (i.e., the first MTCH).

Specifically, the first signaling is used for configuring a service channel of the NR MBMS, service information corresponding to the service channel, and scheduling information corresponding to the service channel. Further optionally, the service information corresponding to the service channel, for example, TMGI, session id, and other identification information for identifying the service. Scheduling information corresponding to the service channel, for example, RNTI used when MBMS service data corresponding to the service channel is scheduled, for example, G-RNTI, DRX configuration information, and the like.

The transmissions of the first MCCH and the first MTCH are scheduled based on the PDCCH. The RNTI used for scheduling the PDCCH of the first MCCH uses a unique network identifier, i.e. a fixed value. The RNTI used for scheduling PDCCH use of the first MTCH is configured through the first MCCH.

It should be noted that, in the embodiment of the present application, the naming of the first SIB, the first MCCH and the first MTCH is not limited. For convenience of description, the first SIB may also be simply referred to as SIB, the first MCCH may also be simply referred to as MCCH, and the first MTCH may also be simply referred to as MTCH, and a PDCCH (i.e. MCCH PDCCH) for scheduling the MCCH and a notification PDCCH are configured through SIB, where a PDSCH (i.e. MCCH PDSCH) for transmitting the MCCH is scheduled through DCI carried in MCCH PDCCH. Further, M PDCCHs for scheduling MTCH (i.e., MTCH 1PDCCH, MTCH2PDCCH, …, MTCH M PDCCH) are configured through the MCCH, wherein DCI carried by MTCH n PDCCH schedules PDSCH for transmitting MTCH n (i.e., MTCH n PDSCH), n being an integer greater than or equal to 1 and less than or equal to M. The MCCH and the MTCH are mapped to the DL-SCH, and further, the DL-SCH is mapped to the PDSCH, wherein the MCCH and the MTCH belong to a logical channel, the DL-SCH belongs to a transport channel, and the PDSCH belongs to a physical channel.

It should be noted that, although the above scheme is described by taking MBMS as an example, the description of "MBMS" may be replaced by "MBS". The embodiment of the present application is described by taking MBS as an example, and the description of "MBS" may be replaced by "MBMS".

In NR systems, many scenarios require support of multicast type and broadcast type traffic demands, such as in the internet of vehicles, industrial internet, etc. It is necessary to introduce multicast type and broadcast type MBS services in the NR. It should be noted that, the multicast type MBS service refers to an MBS service transmitted through a multicast manner. The broadcast type MBS service refers to an MBS service transmitted through a broadcast manner.

In the NR system, for the multicast type MBS service, the MBS service is addressed to all terminal equipments in a certain group. The terminal equipment receives the multicast MBS service in the RRC connection state, and the terminal equipment can receive the multicast MBS service data in the PTM mode or the PTP mode. Referring to fig. 2, the MBS service data of the ptm mode scrambles corresponding scheduling information through a G-RNTI configured by a network side, and the MBS service data of the PTP mode scrambles corresponding scheduling information through a C-RNTI.

For multicast type MBS service, after receiving the MBS service issued by the core network from the shared tunnel (tunnel), the base station may issue the MBS service to all terminal devices in a group through an air interface. Here, the base station may issue the MBS service to all terminal equipments in a group by PTP and/or PTM. For example: a group comprises a terminal device 1, a terminal device 2 and a terminal device 3, wherein the base station can issue MBS service to the terminal device 1 in a PTP mode, issue MBS service to the terminal device 2 in a PTP mode, and issue MBS service to the terminal device 3 in a PTP mode; or the base station can issue MBS business to the terminal equipment 1 in a PTP mode, and issue MBS business to the terminal equipment 2 and the terminal equipment 3 in a PTM mode; or, the base station may send the MBS service to the terminal device 1, the terminal device 2 and the terminal device 3 in the PTM mode. Referring to fig. 3, a shared GTP tunnel (Shared GTP tunnel) is used between the core network and the base station to transmit MBS services, i.e., both PTM-mode MBS services and PTP-mode MBS services are shared with the GTP tunnel. The base station transmits MBS service data to the UE1 and the UE2 according to the PTM mode, and transmits MBS service data to the UE3 according to the PTP mode.

The header compression function in unicast is located in a packet data convergence protocol (Packet Data Convergence Protocol, PDCP) layer, and configuration information for the header compression function for unicast is shown in table 1 below.

TABLE 1

In order to facilitate understanding of the technical solutions of the embodiments of the present application, some key terms related to header compression are described below.

Head compression (header compression): and compressing the packet header of the data packet to improve the transmission efficiency of the data packet. As an example, the types of header compression are: reliable header compression (Robust Header Compression, ROHC) and ethernet header compression (Ethernet Header Compression, EHC).

PDU session Type (PDU session Type): a PDU session refers to an association between a terminal device and a data network providing a protocol data unit (Protocol Data Unit, PDU) connection service. The type of this association, i.e., PDU session type, may be an IPv4 type, an IPv6 type, an Ethernet (Ethernet) type, etc. The header structures of the data packets corresponding to different PDU session types are different.

And (3) complete package: an ethernet packet or an IP packet, which contains complete header information, by means of which header compression context can be established, which header compression context is used for compression and/or decompression of the header. The compression of the packet header may be referred to as header compression, and the decompression of the packet header may be referred to as header decompression.

And (3) compressing: an ethernet packet or an IP packet, the packet comprising header information that is compressed. After receiving the compressed packet, the receiving end needs to recover the complete packet header information according to the header compression context.

And (3) feedback package: the decompression end sends the decompression or context information related packet to the compression end, and is used for changing the state of the compression end or the decompression end.

In NR, the PDCP layer is supported either for multicast or broadcast, and the header compression function in unicast is located in the PDCP layer, so that the header compression function can be supported in the PDCP layer for multicast and broadcast as well. However, whether the multicast type MBS service or the broadcast type MBS service, there are some terminal equipments which join the MBS service earlier and some terminal equipments which join the MBS service later in the process of transmitting the MBS service on the network side. For terminal devices that join MBS services later, the network side may already transmit MBS services by using compressed packets, and how such terminal devices decompress compressed packets is a problem to be solved.

For this reason, the following technical solutions of the embodiments of the present application are proposed.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the present application are described in detail below through specific embodiments. The above related technologies may be optionally combined with the technical solutions of the embodiments of the present application, which all fall within the scope of protection of the embodiments of the present application. Embodiments of the present application include at least some of the following.

Fig. 4 is a schematic flow chart of a header compression method according to an embodiment of the present application, as shown in fig. 4, where the header compression method includes the following steps:

step 401: the terminal equipment receives first information sent by the network equipment, and establishes a header compression context based on the first information.

Here, the network device sends first information to the terminal device, the first information being used by the terminal device to establish a header compression context. Accordingly, the terminal device receives the first information sent by the network device, and establishes a header compression context based on the first information.

Step 402: and the terminal equipment receives the compressed packet sent by the network equipment in a multicast mode or a broadcast mode, and decompresses the compressed packet based on the header compression context.

Here, the network device sends a compressed packet to the terminal device in a multicast manner or a broadcast manner, and the header compression context is used for the terminal device to decompress the compressed packet. Correspondingly, the terminal equipment receives the compressed packet sent by the network equipment in a multicast mode or a broadcast mode, and decompresses the compressed packet based on the header compression context.

In some alternative embodiments, the network device is a base station.

In some alternative embodiments, the terminal device may refer to a terminal device in the following three scenarios.

Scene one: for a terminal device that is handed over to a cell, the cell is transmitting a MBS service that the terminal device expects or is receiving or is about to receive. Here, the transmission method of the MBS service may be a multicast method or a broadcast method.

Scene II: for a certain terminal device, a certain MBS service is established in a current service cell, and the MBS service is already established and sent in the current cell. Here, the transmission mode of the MBS service may be a transmission mode or a broadcast mode.

Scene III: for a terminal device receiving MBS service, radio link failure, complete protection verification failure, reconfiguration failure, or switching failure occurs, RRC connection reestablishment occurs, and a network side establishes receiving of MBS service for the terminal device reestablishing RRC connection, and the MBS service is established and sent in a current cell. Here, the transmission method of the MBS service may be a multicast method or a broadcast method.

For the terminal equipment in the above three scenarios, when the terminal equipment receives the MBS service, the terminal equipment receives a compressed packet of the MBS service, and in order to truly receive the compressed packet, the terminal equipment needs to establish a header compression context based on the first information sent by the network equipment, and then decompress the received compressed packet based on the header compression context. Here, header decompression refers to decompressing the header of a compressed packet, thereby recovering the complete header information.

In this embodiment of the present application, the terminal device receives the compressed packet sent by the network device in a multicast manner or a broadcast manner, which may have the following implementation manners:

mode one: after the terminal equipment establishes the header compression context, the terminal equipment autonomously receives the compression packet sent by the network equipment through a multicast mode or a broadcast mode on a multicast radio bearer (Multicast Radio Bearer, MRB).

Mode two: after the terminal equipment establishes the header compression context, receiving a compression packet sent by the network equipment in a multicast mode or a broadcast mode on the MRB based on the indication of the network equipment.

Here, the network device indicates to the terminal device to receive the compressed packet on the MRB.

In some optional embodiments, the network device may explicitly instruct the terminal device to receive, on the MRB, a compressed packet sent by the network device in a multicast manner or a broadcast manner, and specifically, the indication of the network device is first indication information, where the first indication information is used to instruct the terminal device to receive, on the MRB, the compressed packet. Here, optionally, the first indication information is carried in a PDCCH or a medium access Control (Media Access Control, MAC) Control Element (CE) or radio resource Control (Radio Resource Control, RRC) signaling.

In some optional embodiments, the network device may implicitly instruct the terminal device to receive, on the MRB, a compressed packet sent by the network device in a multicast manner or a broadcast manner, and specifically, the indication of the network device is first configuration information, where the first configuration information is used to configure the MRB, and the first configuration information is further used to instruct the terminal device to receive, on the MRB, the compressed packet.

Mode three: after the terminal equipment establishes the header compression context, based on the timeout of a timer configured by the network side, receiving a compression packet sent by the network equipment in a multicast mode or a broadcast mode on the MRB.

Here, the network device configures a timer for the terminal device, and the timer expires for triggering the terminal device to receive the compressed packet on the MRB. Specifically, if the timer is overtime, the terminal device receives the compressed packet sent by the network device through a multicast mode or a broadcast mode on the MRB.

In some optional embodiments, the terminal device starts or restarts the timer if at least one of the following conditions is met:

the terminal equipment receives the configuration of the timer;

the terminal equipment receives reconfiguration of the timer;

the terminal equipment receives the reconfiguration of the MRB;

the terminal device receives a reconfiguration of a data radio bearer (Data Resource Bearer, DRB), the DRB having an association with the MRB.

In some optional embodiments, the terminal device stops the timer if at least one of the following conditions is met:

the terminal equipment receives the de-configuration of the timer;

the terminal equipment receives the deconfiguration of the MRB;

the terminal equipment receives the de-configuration of the DRB, and the DRB and the MRB have an association relation.

In the above scheme, DRB refers to a radio bearer for unicast service, and MRB refers to a radio bearer for MBS service (which may be multicast type MBS service or broadcast type MBS service). The network equipment configures one or more MRBs for the MBS service and transmits the MBS service on the configured MRBs. The terminal equipment receives the MBS service on the configured MRB, wherein the terminal equipment receives the compressed package of the MBS service on the configured MRB.

In the above scheme, when configuring the DRB for the terminal device, the network device also configures the MRB associated with the DRB, that is, the DRB has an association relationship with a certain MRB, where the MRB is the radio bearer of the terminal device for receiving the compressed packet of the MBS service.

In some optional embodiments, before the terminal device receives the compressed packet sent by the network device in the multicast mode or the broadcast mode, after the terminal device establishes the header compression context, feedback information is sent to the network device, where the feedback information is used to feed back that the terminal device establishes the header compression context.

In some optional embodiments, the network device determines that the terminal device has established a header compression context based on its implementation; or the network equipment receives feedback information sent by the terminal equipment, wherein the feedback information is used for feeding back the established header compression context of the terminal equipment.

In the embodiment of the application, the terminal equipment receives the first information sent by the network equipment, and establishes the header compression context based on the first information. The implementation of the first information is described below in connection with a specific scheme.

Scheme one

In this embodiment of the present application, the first information is header information of a complete packet.

And the network equipment sends a complete packet to the terminal equipment through the DRB, and the packet header information in the complete packet is used for the terminal equipment to establish a header compression context. Correspondingly, the terminal equipment receives a complete packet sent by the network equipment through the DRB, acquires packet header information from the complete packet, and establishes a header compression context based on the packet header information.

In some alternative embodiments, before the network device sends the complete packet to the terminal device through the DRB, the network device sends second configuration information to the terminal device, where the second configuration information is used to configure the DRB. Correspondingly, before the terminal equipment receives the complete packet sent by the network equipment through the DRB, the terminal equipment receives second configuration information sent by the network equipment, wherein the second configuration information is used for configuring the DRB.

In some optional embodiments, the second configuration information carries second indication information, where the second indication information is used to indicate an MRB identifier of an MRB having an association with the DRB, and the MRB identifier is used to indicate that the DRB is used to establish a header compression context of the MRB having an association with the DRB.

In some alternative embodiments, the second configuration information is carried in RRC signaling.

Scheme II

And the network equipment sends a complete packet to the terminal equipment through MRB, and the packet header information in the complete packet is used for the terminal equipment to establish a header compression context. Correspondingly, the terminal equipment receives a complete packet sent by the network equipment through the MRB, acquires packet header information from the complete packet, and establishes a header compression context based on the packet header information.

In some alternative embodiments, before the network device sends a complete packet to a terminal device through an MRB, the network device sends first configuration information to the terminal device, where the first configuration information is used to configure the MRB. Correspondingly, before the terminal equipment receives a complete packet sent by the network equipment through the MRB, the terminal equipment receives first configuration information sent by the network equipment, wherein the first configuration information is used for configuring the MRB.

Scheme III

In this embodiment of the present application, the first information is third configuration information, where the third configuration information includes a header compression context or the third configuration information is used to assist the terminal device in establishing the header compression context; the network equipment sends the third configuration information to terminal equipment, wherein the third configuration information is used for the terminal equipment to establish a header compression context; correspondingly, the terminal equipment receives the third configuration information sent by the network equipment, and establishes a header compression context based on the third configuration information.

Option 1) in some alternative embodiments, the third configuration information is carried in RRC signaling.

Further, optionally, the third configuration information carries third indication information, where the third indication information is used to indicate an MRB identifier of an MRB having an association with the third configuration information, and the MRB identifier is used to indicate that the third configuration information is used to establish a header compression context of the MRB having an association with the third configuration information.

Here, after receiving the third configuration information, the terminal device sends the third configuration information to a corresponding packet data convergence protocol PDCP layer based on the MRB identifier, and establishes a header compression context based on the third configuration information through the PDCP layer.

Option 2) in some alternative embodiments, the third configuration information is carried in MCCH signaling.

In some alternative embodiments, the MCCH signaling further carries configuration information indicating a length of a Context ID (CID) field in a packet. Here, the information carried in the CID field is an identification of the header compression context (abbreviated CID). The length of the CID domain in the data packet is configured in the MCCH signaling, so that the terminal equipment can correctly analyze the CID domain.

Option 3) in some alternative embodiments, the third configuration information is carried in a PDCP control PDU.

Here, the PDCP layer of the terminal device acquires the third configuration information from the PDCP control PDU, and establishes a header compression context based on the third configuration information.

In the above aspect, optionally, the header compression context includes at least one of the following information: indication information for indicating a complete packet or a compressed packet, indication information for indicating data information or control information, a context identification, a profile identification, a source address, a destination address, a source port, a destination port, an 802.1Q tag, a length, a type.

The following describes the technical solutions of the embodiments of the present application by way of example with reference to specific application examples. The terminal devices in the following application examples refer to terminal devices in the following three scenarios.

Application example 1

The network device configures one DRB through RRC dedicated signaling, but the DRB does not turn on the header compression function, i.e. the network device sends a complete packet on the DRB. Further, the DRB associates an MRB identifier, and the MRB identifier is used for indicating that the complete packet sent by the DRB is used for establishing a header compression context of the MRB indicated by the MRB identifier.

The terminal equipment receives the complete packet on the DRB, acquires the packet header information from the complete packet, and establishes a header compression context according to the packet header information, wherein the header compression context is the header compression context of the MRB. After the terminal device establishes the header compression context, the terminal device autonomously receives the compression packet on the MRB or receives the compression packet on the MRB based on the indication of the network device or receives the compression packet on the MRB based on the timeout of the timer configured by the network device, and decompresses the received compression packet based on the established header compression context.

Here, in some optional embodiments, the network device may explicitly instruct the terminal device to receive the compressed packet on the MRB, and specifically, the indication of the network device is first indication information, where the first indication information is used to instruct the terminal device to receive the compressed packet on the MRB. Here, optionally, the first indication information is carried in a PDCCH or MAC CE or RRC) order. Or in some optional embodiments, the network device may implicitly instruct the terminal device to receive the compressed packet on the MRB, specifically, the indication of the network device is first configuration information, where the first configuration information is used to configure the MRB or a DRB having an association relationship with the MRB, and the first configuration information is further used to instruct the terminal device to receive the compressed packet on the MRB.

the terminal equipment receives the configuration of the timer;

the terminal equipment receives reconfiguration of the timer;

the terminal equipment receives the reconfiguration of the MRB;

and the terminal equipment receives the reconfiguration of the DRB, wherein the DRB and the MRB have an association relation.

the terminal equipment receives the de-configuration of the timer;

the terminal equipment receives the deconfiguration of the MRB;

Application instance two

When the network device configures an MRB (which may be 1 or more MRBs) for the terminal device newly joining the MBS service, or later, the network device adopts a headless compression mode to transmit MBS service data, that is, the network device sends a complete packet on the MRB.

The terminal equipment receives the complete packet on the MRB, acquires the packet header information from the complete packet, and establishes a header compression context according to the packet header information.

When the network device receives feedback information of the terminal device or based on the network device implementation, the network device considers that the terminal device has established the header compression context, the network device starts transmission of header compression data again, that is, the network device sends a compression packet on the MRB.

Application example three

When or after the network device configures an MRB (which may be 1 or more MRBs) for the terminal device newly joining the MBS service, the network device configures at least one header compression context for the terminal device through RRC signaling or configuration information (i.e., third configuration information) of the auxiliary terminal to establish the header compression context, for the auxiliary terminal device to establish the header compression context. Further, the third configuration information is associated with an MBR identification.

After receiving third configuration information configured by the network equipment through RRC signaling, the terminal equipment sends the third configuration information to the corresponding PDCP layer according to the associated MRB identification, and establishes a header compression context according to the third configuration information through the PDCP layer.

After the terminal equipment establishes the header compression context, receiving the compression packet of the MBS service on the MRB indicated by the MRB identifier, and decompressing the compression packet according to the established header compression context.

Application example four

When or after the network device configures an MRB (which may be 1 or more MRBs) for the terminal device newly joining the MBS service, the network device configures at least one header compression context for the terminal device through the PDCP control PDU or configuration information (i.e., third configuration information) of the auxiliary terminal to establish the header compression context, for the auxiliary terminal device.

After receiving the third configuration information, the PDCP layer of the terminal device establishes a header compression context according to the third configuration information.

After the terminal equipment establishes the header compression context, receiving the compression packet of the MBS service on the MRB, and decompressing the compression packet according to the established header compression context.

Application example five

The method comprises the steps that a terminal device receives a SIB, obtains configuration information of an MCCH from the SIB, receives MCCH based on the configuration information of the MCCH, and obtains MCCH signaling from the MCCH, wherein the MCCH signaling carries configuration information of MBS (multicast service), and the configuration information of the MBS comprises a header compression context or configuration information (namely third configuration information) of an auxiliary terminal for establishing the header compression context. Further, the third configuration information is associated with an MBR identification. In some alternative embodiments, the MCCH signaling also carries configuration information indicating the length of the CID field in the data packet.

After receiving third configuration information configured by the network equipment through the MCCH signaling, the terminal equipment sends the third configuration information to a corresponding PDCP layer according to the associated MRB identifier, and establishes a header compression context according to the third configuration information through the PDCP layer.

In the foregoing aspect of the embodiments of the present application, the header compression may be ROHC or EHC.

According to the scheme, how the terminal equipment establishes the header compression context is clarified in multicast or broadcast, and further header decompression can be performed on the compression packet sent by the network equipment in a multicast mode or a broadcast mode based on the header compression context, so that the terminal equipment can normally receive the compression packet of multicast or broadcast.

The preferred embodiments of the present application have been described in detail above with reference to the accompanying drawings, but the present application is not limited to the specific details of the above embodiments, and various simple modifications may be made to the technical solutions of the present application within the scope of the technical concept of the present application, and all the simple modifications belong to the protection scope of the present application. For example, the specific features described in the above embodiments may be combined in any suitable manner, and in order to avoid unnecessary repetition, various possible combinations are not described in detail. As another example, any combination of the various embodiments of the present application may be made, as long as it does not depart from the spirit of the present application, which is also regarded as disclosed herein. For example, the various embodiments and/or technical features of the various embodiments described herein may be combined with any other of the prior art without conflict, and the combined technical solutions should also fall within the scope of protection of the present application.

It should be further understood that, in the various method embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic of the processes, and should not constitute any limitation on the implementation process of the embodiments of the present application. Further, in the embodiment of the present application, the terms "downstream", "upstream" and "sidestream" are used to indicate a transmission direction of signals or data, where "downstream" is used to indicate that the transmission direction of signals or data is a first direction from a station to a user equipment of a cell, "upstream" is used to indicate that the transmission direction of signals or data is a second direction from the user equipment of the cell to the station, and "sidestream" is used to indicate that the transmission direction of signals or data is a third direction from the user equipment 1 to the user equipment 2. For example, "downstream signal" means that the transmission direction of the signal is the first direction. In addition, in the embodiment of the present application, the term "and/or" is merely an association relationship describing the association object, which means that three relationships may exist. Specifically, a and/or B may represent: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

Fig. 5 is a schematic structural diagram of a header compression device according to an embodiment of the present application, which is applied to a terminal device, as shown in fig. 5, and the header compression device includes:

a receiving unit 501, configured to receive first information sent by a network device;

an establishing unit 502, configured to establish a header compression context based on the first information;

the receiving unit 501 is further configured to receive a compressed packet sent by the network device in a multicast manner or a broadcast manner;

a processing unit 503, configured to decompress the compressed packet based on the header compression context.

In some optional embodiments, the receiving unit 501 is configured to autonomously receive, on the MRB, a compressed packet sent by the network device in a multicast manner or a broadcast manner; or receiving a compressed packet sent by the network equipment in a multicast mode or a broadcast mode on the MRB based on the indication of the network equipment; or receiving the compressed packet sent by the network device in a multicast mode or a broadcast mode on the MRB based on the timeout of the timer configured by the network device.

In some optional embodiments, the indication of the network device is first indication information, where the first indication information is used to instruct the terminal device to receive the compressed packet on the MRB; or the indication of the network device is first configuration information, wherein the first configuration information is used for configuring the MRB, and the first configuration information is also used for indicating the terminal device to receive the compressed packet on the MRB.

In some optional embodiments, the first indication information is carried in PDCCH or MAC CE or RRC signaling.

In some optional embodiments, the processing unit 503 is further configured to start or restart the timer if at least one of the following conditions is met:

the terminal equipment receives the configuration of the timer;

the terminal equipment receives reconfiguration of the timer;

the terminal equipment receives the reconfiguration of the MRB;

and the terminal equipment receives the reconfiguration of the Data Radio Bearer (DRB), and the DRB and the MRB have an association relation.

In some alternative embodiments, the processing unit 503 is further configured to stop the timer if at least one of the following conditions is met:

the terminal equipment receives the de-configuration of the timer;

the terminal equipment receives the deconfiguration of the MRB;

In some alternative embodiments, the apparatus further comprises: and the sending unit is used for sending feedback information to the network equipment, wherein the feedback information is used for feeding back the established header compression context of the terminal equipment.

In some optional embodiments, the first information is header information of a complete packet;

the receiving unit 501 is configured to receive, through a DRB, a complete packet sent by a network device;

the establishing unit 502 is configured to obtain header information from the complete packet, and establish a header compression context based on the header information.

In some optional embodiments, the receiving unit 501 is further configured to receive second configuration information sent by the network device, where the second configuration information is used to configure the DRB.

the receiving unit 501 is configured to receive, through MRB, a complete packet sent by a network device;

In some optional embodiments, the receiving unit 501 is further configured to receive first configuration information sent by the network device, where the first configuration information is used to configure the MRB.

In some optional embodiments, the first information is third configuration information, where the third configuration information includes a header compression context or the third configuration information is used to assist the terminal device in establishing the header compression context;

the receiving unit 501 is configured to receive the third configuration information sent by the network device;

the establishing unit 502 is configured to establish a header compression context based on the third configuration information.

In some alternative embodiments, the third configuration information is carried in RRC signaling.

In some alternative embodiments, the third configuration information is carried in MCCH signaling.

In some alternative embodiments, the MCCH signaling also carries configuration information indicating the length of the CID field in the data packet.

In some optional embodiments, the third configuration information carries third indication information, where the third indication information is used to indicate an MRB identifier of an MRB having an association with the third configuration information, and the MRB identifier is used to indicate that the third configuration information is used to establish a header compression context of the MRB having an association with the third configuration information.

In some optional embodiments, the establishing unit 502 is configured to send the third configuration information to a corresponding PDCP layer based on the MRB identifier, and establish, by the PDCP layer, a header compression context based on the third configuration information.

In some alternative embodiments, the third configuration information is carried in a PDCP control PDU.

In some optional embodiments, the establishing unit 502 is configured to obtain, by using a PDCP layer of the terminal device, the third configuration information from the PDCP control PDU, and establish a header compression context based on the third configuration information.

In some alternative embodiments, the header compression context includes at least one of the following information:

indication information for indicating a complete packet or a compressed packet, indication information for indicating data information or control information, a context identification, a profile identification, a source address, a destination address, a source port, a destination port, an 802.1Q tag, a length, a type.

It should be understood by those skilled in the art that the above description of the head compression device of the embodiments of the present application may be understood with reference to the description of the head compression method of the embodiments of the present application.

Fig. 6 is a schematic diagram ii of the structural composition of a header compression device provided in the embodiment of the present application, which is applied to a network device, as shown in fig. 6, where the header compression device includes:

A sending unit 601, configured to send first information to a terminal device, where the first information is used for the terminal device to establish a header compression context; and sending a compressed packet to the terminal equipment in a multicast mode or a broadcast mode, wherein the header compression context is used for the terminal equipment to decompress the compressed packet.

In some alternative embodiments, the apparatus further comprises:

an indication unit, configured to indicate to the terminal device that the compressed packet is received on an MRB; or,

and the configuration unit is used for configuring a timer for the terminal equipment, and the timer is overtime and is used for triggering the terminal equipment to receive the compressed packet on the MRB.

In some optional embodiments, the indication is first indication information, where the first indication information is used to instruct the terminal device to receive the compressed packet on the MRB; or the indication is first configuration information, the first configuration information is used for configuring the MRB, and the first configuration information is also used for indicating the terminal equipment to receive the compressed packet on the MRB.

In some alternative embodiments, the apparatus further comprises:

a determining unit, configured to determine that the terminal device establishes a header compression context based on its implementation; or,

and the receiving unit is used for receiving feedback information sent by the terminal equipment, wherein the feedback information is used for feeding back the established header compression context of the terminal equipment.

the sending unit 601 is configured to send a complete packet to a terminal device through a DRB, where header information in the complete packet is used for the terminal device to establish a header compression context.

In some optional embodiments, the sending unit 601 is further configured to send second configuration information to the terminal device, where the second configuration information is used to configure the DRB.

the sending unit 601 is configured to send a complete packet to a terminal device through MRB, where header information in the complete packet is used for the terminal device to establish a header compression context.

In some optional embodiments, the sending unit 601 is further configured to send first configuration information to the terminal device, where the first configuration information is used to configure the MRB.

the sending unit 601 is configured to send the third configuration information to a terminal device, where the third configuration information is used for the terminal device to establish a header compression context.

Fig. 7 is a schematic block diagram of a communication device 700 according to an embodiment of the present application. The communication device may be a terminal device or a network device. The communication device 700 shown in fig. 7 comprises a processor 710, from which the processor 710 may call and run a computer program to implement the method in the embodiments of the present application.

Optionally, as shown in fig. 7, the communication device 700 may further comprise a memory 720. Wherein the processor 710 may call and run a computer program from the memory 720 to implement the methods in embodiments of the present application.

Wherein the memory 720 may be a separate device from the processor 710 or may be integrated into the processor 710.

Optionally, as shown in fig. 7, the communication device 700 may further include a transceiver 730, and the processor 710 may control the transceiver 730 to communicate with other devices, and in particular, may send information or data to other devices or receive information or data sent by other devices.

Among other things, transceiver 730 may include a transmitter and a receiver. Transceiver 730 may further include antennas, the number of which may be one or more.

Optionally, the communication device 700 may be specifically a network device in the embodiment of the present application, and the communication device 700 may implement a corresponding flow implemented by the network device in each method in the embodiment of the present application, which is not described herein for brevity.

Optionally, the communication device 700 may be specifically a mobile terminal/terminal device in the embodiment of the present application, and the communication device 700 may implement a corresponding flow implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein for brevity.

Fig. 8 is a schematic structural diagram of a chip of an embodiment of the present application. The chip 800 shown in fig. 8 includes a processor 810, and the processor 810 may call and run a computer program from a memory to implement the methods in the embodiments of the present application.

Optionally, as shown in fig. 8, chip 800 may also include memory 820. Wherein the processor 810 may call and run a computer program from the memory 820 to implement the methods in embodiments of the present application.

Wherein the memory 820 may be a separate device from the processor 810 or may be integrated into the processor 810.

Optionally, the chip 800 may also include an input interface 830. The processor 810 may control the input interface 830 to communicate with other devices or chips, and in particular, may obtain information or data sent by other devices or chips.

Optionally, the chip 800 may further include an output interface 840. The processor 810 may control the output interface 840 to communicate with other devices or chips, and in particular, may output information or data to other devices or chips.

Optionally, the chip may be applied to a network device in the embodiment of the present application, and the chip may implement a corresponding flow implemented by the network device in each method in the embodiment of the present application, which is not described herein for brevity.

Optionally, the chip may be applied to a mobile terminal/terminal device in the embodiment of the present application, and the chip may implement a corresponding flow implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein for brevity.

It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, or the like.

Fig. 9 is a schematic block diagram of a communication system 900 provided in an embodiment of the present application. As shown in fig. 9, the communication system 900 includes a terminal device 910 and a network device 920.

The terminal device 910 may be configured to implement the corresponding functions implemented by the terminal device in the above method, and the network device 920 may be configured to implement the corresponding functions implemented by the network device in the above method, which are not described herein for brevity.

It should be appreciated that the processor of an embodiment of the present application may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method embodiments may be implemented by integrated logic circuits of hardware in a processor or instructions in software form. The processor may be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

It will be appreciated that the memory in embodiments of the present application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and Direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

It should be understood that the above memory is exemplary but not limiting, and for example, the memory in the embodiments of the present application may be Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), direct RAM (DR RAM), and the like. That is, the memory in embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

Embodiments of the present application also provide a computer-readable storage medium for storing a computer program.

Optionally, the computer readable storage medium may be applied to a network device in the embodiments of the present application, and the computer program causes a computer to execute a corresponding flow implemented by the network device in each method in the embodiments of the present application, which is not described herein for brevity.

Optionally, the computer readable storage medium may be applied to a mobile terminal/terminal device in the embodiments of the present application, and the computer program causes a computer to execute a corresponding procedure implemented by the mobile terminal/terminal device in each method of the embodiments of the present application, which is not described herein for brevity.

Embodiments of the present application also provide a computer program product comprising computer program instructions.

Optionally, the computer program product may be applied to a network device in the embodiments of the present application, and the computer program instructions cause the computer to execute corresponding flows implemented by the network device in the methods in the embodiments of the present application, which are not described herein for brevity.

Optionally, the computer program product may be applied to a mobile terminal/terminal device in the embodiments of the present application, and the computer program instructions cause a computer to execute corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiments of the present application, which are not described herein for brevity.

The embodiment of the application also provides a computer program.

Optionally, the computer program may be applied to a network device in the embodiments of the present application, and when the computer program runs on a computer, the computer is caused to execute a corresponding flow implemented by the network device in each method in the embodiments of the present application, which is not described herein for brevity.

Optionally, the computer program may be applied to a mobile terminal/terminal device in the embodiments of the present application, where the computer program when executed on a computer causes the computer to execute corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiments of the present application, and for brevity, will not be described herein.

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

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

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

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

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

A method of header compression, the method comprising:

the terminal equipment receives first information sent by the network equipment, and establishes a header compression context based on the first information;

and the terminal equipment receives the compressed packet sent by the network equipment in a multicast mode or a broadcast mode, and decompresses the compressed packet based on the header compression context.
The method of claim 1, wherein the terminal device receiving the compressed packet sent by the network device through a multicast manner or a broadcast manner, comprises:

after the terminal equipment establishes the header compression context, the terminal equipment autonomously receives a compression packet sent by the network equipment in a multicast mode or a broadcast mode on a Multicast Radio Bearer (MRB); or,

after the terminal equipment establishes the header compression context, receiving a compression packet sent by the network equipment in a multicast mode or a broadcast mode on an MRB (multicast-broadcast) based on the indication of the network equipment; or,

After the terminal equipment establishes the header compression context, receiving the compression packet sent by the network equipment in a multicast mode or a broadcast mode on the MRB based on the timeout of a timer configured by the network equipment.
The method of claim 2, wherein,

the indication of the network equipment is first indication information, wherein the first indication information is used for indicating the terminal equipment to receive the compressed packet on the MRB; or,

the indication of the network device is first configuration information, the first configuration information is used for configuring the MRB, and the first configuration information is also used for indicating the terminal device to receive the compressed packet on the MRB.
The method of claim 3, wherein the first indication information is carried in a physical downlink control channel PDCCH or a medium access control MAC control element CE or radio resource control RRC signaling.
The method of claim 2, wherein the method further comprises:

and under the condition that at least one of the following conditions is met, the terminal equipment starts or restarts the timer:

the terminal equipment receives the configuration of the timer;

the terminal equipment receives reconfiguration of the timer;

The terminal equipment receives the reconfiguration of the MRB;

and the terminal equipment receives the reconfiguration of the Data Radio Bearer (DRB), and the DRB and the MRB have an association relation.
The method of claim 2 or 5, wherein the method further comprises:

the terminal device stops the timer if at least one of the following conditions is satisfied:

the terminal equipment receives the de-configuration of the timer;

the terminal equipment receives the deconfiguration of the MRB;

the terminal equipment receives the de-configuration of the DRB, and the DRB and the MRB have an association relation.
The method according to any one of claims 1 to 6, wherein before the terminal device receives the compressed packet sent by the network device by multicast or broadcast, the method further comprises:

and after the terminal equipment establishes the header compression context, sending feedback information to the network equipment, wherein the feedback information is used for feeding back the header compression context established by the terminal equipment.
The method of any of claims 1 to 7, wherein the first information is header information of a complete packet;

the terminal device receives first information sent by a network device, establishes a header compression context based on the first information, and comprises:

The terminal equipment receives a complete packet sent by the network equipment through the DRB, acquires packet header information from the complete packet, and establishes a header compression context based on the packet header information.
The method of claim 8, wherein before the terminal device receives the complete packet sent by the network device through the DRB, the method further comprises:

the terminal equipment receives second configuration information sent by the network equipment, wherein the second configuration information is used for configuring the DRB.
The method of claim 9, wherein the second configuration information carries second indication information, the second indication information being used to indicate an MRB identity of an MRB having an association with the DRB, the MRB identity being used to indicate a header compression context used by the DRB to establish the MRB having an association therewith.
The method according to claim 9 or 10, wherein the second configuration information is carried in RRC signaling.
The method of any of claims 1 to 7, wherein the first information is header information of a complete packet;

the terminal device receives first information sent by a network device, establishes a header compression context based on the first information, and comprises:

The terminal equipment receives a complete packet sent by the network equipment through the MRB, acquires packet header information from the complete packet, and establishes a header compression context based on the packet header information.
The method of claim 12, wherein before the terminal device receives the complete packet sent by the network device through the MRB, the method further comprises:

the terminal equipment receives first configuration information sent by the network equipment, wherein the first configuration information is used for configuring the MRB.
The method of any of claims 1 to 7, wherein the first information is third configuration information comprising a header compression context or the third configuration information is used to assist the terminal device in establishing a header compression context;

the terminal device receives first information sent by a network device, establishes a header compression context based on the first information, and comprises:

and the terminal equipment receives the third configuration information sent by the network equipment, and establishes a header compression context based on the third configuration information.
The method of claim 14, wherein the third configuration information is carried in RRC signaling.
The method of claim 14, wherein the third configuration information is carried in multicast control channel, MCCH, signaling.
The method of claim 16, the MCCH signaling further carries configuration information indicating a length of a context identification CID field in a data packet.
The method according to any one of claims 14 to 17, wherein the third configuration information carries third indication information for indicating an MRB identity of an MRB having an association with the third configuration information, the MRB identity being for indicating that the third configuration information is used to establish a header compression context of the MRB having an association with the third configuration information.
The method of claim 18, wherein the establishing a header compression context based on the third configuration information comprises:

the terminal equipment sends the third configuration information to a corresponding Packet Data Convergence Protocol (PDCP) layer based on the MRB identification, and establishes a header compression context based on the third configuration information through the PDCP layer.
The method of claim 14, wherein the third configuration information is carried in a PDCP control PDU.
The method of claim 20, wherein the establishing a header compression context based on the third configuration information comprises:

The PDCP layer of the terminal equipment acquires the third configuration information from the PDCP control PDU and establishes a header compression context based on the third configuration information.
The method of any of claims 1-21, wherein the header compression context includes at least one of the following information:

indication information for indicating a complete packet or a compressed packet, indication information for indicating data information or control information, a context identification, a profile identification, a source address, a destination address, a source port, a destination port, an 802.1Q tag, a length, a type.
A method of header compression, the method comprising:

the network equipment sends first information to the terminal equipment, wherein the first information is used for the terminal equipment to establish a header compression context;

the network device sends a compressed packet to the terminal device in a multicast mode or a broadcast mode, and the header compression context is used for the terminal device to decompress the compressed packet.
The method of claim 23, wherein the method further comprises:

the network device indicates to the terminal device to receive the compressed packet on MRB; or,

the network device configures a timer for the terminal device, and the timer expires to trigger the terminal device to receive the compressed packet on the MRB.
The method of claim 24, wherein,

the indication is first indication information, and the first indication information is used for indicating the terminal equipment to receive the compressed packet on the MRB; or,

the indication is first configuration information, the first configuration information is used for configuring the MRB, and the first configuration information is also used for indicating the terminal equipment to receive the compressed packet on the MRB.
The method of claim 25, wherein the first indication information is carried in PDCCH or MAC CE or RRC signaling.
The method according to any one of claims 23 to 26, wherein before the network device sends compressed packets to the terminal device by multicast or broadcast, the method further comprises:

the network equipment determines that the terminal equipment establishes a header compression context based on the realization of the network equipment; or,

and the network equipment receives feedback information sent by the terminal equipment, wherein the feedback information is used for feeding back the established header compression context of the terminal equipment.
The method of any of claims 23 to 27, wherein the first information is header information of a complete packet;

The network device sends first information to a terminal device, including:

and the network equipment sends a complete packet to the terminal equipment through the DRB, and the packet header information in the complete packet is used for the terminal equipment to establish a header compression context.
The method of claim 28, wherein before the network device sends the complete packet to the terminal device via the DRB, the method further comprises:

and the network equipment sends second configuration information to the terminal equipment, wherein the second configuration information is used for configuring the DRB.
The method of claim 29, wherein the second configuration information carries second indication information indicating an MRB identity of an MRB having an association with the DRB, the MRB identity indicating a header compression context used by the DRB to establish the MRB having an association with the DRB.
The method of claim 29 or 30, wherein the second configuration information is carried in RRC signaling.
The method of any of claims 23 to 27, wherein the first information is header information of a complete packet;

the network device sends first information to a terminal device, including:

And the network equipment sends a complete packet to the terminal equipment through MRB, and the packet header information in the complete packet is used for the terminal equipment to establish a header compression context.
The method of claim 32, wherein before the network device sends the complete packet to the terminal device via the MRB, the method further comprises:

the network device sends first configuration information to the terminal device, wherein the first configuration information is used for configuring the MRB.
The method of any of claims 23 to 27, wherein the first information is third configuration information comprising a header compression context or the third configuration information is used to assist the terminal device in establishing a header compression context;

the network device sends first information to a terminal device, including:

the network device sends the third configuration information to the terminal device, wherein the third configuration information is used for the terminal device to establish a header compression context.
The method of claim 34, wherein the third configuration information is carried in RRC signaling.
The method of claim 34, wherein the third configuration information is carried in MCCH signaling.
The method of claim 36, wherein the MCCH signaling further carries configuration information indicating a length of a CID field in a packet.
The method according to any one of claims 34 to 37, wherein the third configuration information carries third indication information for indicating an MRB identity of an MRB having an association with the third configuration information, the MRB identity being for indicating that the third configuration information is used to establish a header compression context of the MRB having an association with the third configuration information.
The method of claim 34, wherein the third configuration information is carried in a PDCP control PDU.
The method of any of claims 23 to 39, wherein the header compression context includes at least one of the following information:

indication information for indicating a complete packet or a compressed packet, indication information for indicating data information or control information, a context identification, a profile identification, a source address, a destination address, a source port, a destination port, an 802.1Q tag, a length, a type.
A header compression apparatus for use in a terminal device, the apparatus comprising:

the receiving unit is used for receiving the first information sent by the network equipment;

A setting unit configured to set up a header compression context based on the first information;

the receiving unit is further configured to receive a compressed packet sent by the network device in a multicast manner or a broadcast manner;

and the processing unit is used for decompressing the compressed packet based on the header compression context.
A header compression apparatus for use in a network device, the apparatus comprising:

a transmitting unit, configured to transmit first information to a terminal device, where the first information is used for the terminal device to establish a header compression context; and sending a compressed packet to the terminal equipment in a multicast mode or a broadcast mode, wherein the header compression context is used for the terminal equipment to decompress the compressed packet.
A terminal device, comprising: a processor and a memory for storing a computer program, the processor being for invoking and running the computer program stored in the memory, performing the method of any of claims 1 to 22.
A network device, comprising: a processor and a memory for storing a computer program, the processor being for invoking and running the computer program stored in the memory, performing the method of any of claims 23 to 40.
A chip, comprising: a processor for calling and running a computer program from a memory, causing a device in which the chip is installed to perform the method of any of claims 1 to 22.
A chip, comprising: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform the method of any one of claims 23 to 40.
A computer readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 1 to 22.
A computer readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 23 to 40.
A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 1 to 22.
A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 23 to 40.
A computer program which causes a computer to perform the method of any one of claims 1 to 22.
A computer program which causes a computer to perform the method of any one of claims 23 to 40.