CN116762365A

CN116762365A - Sidestream transmission method, terminal equipment and network equipment

Info

Publication number: CN116762365A
Application number: CN202180090568.5A
Authority: CN
Inventors: 张博源; 卢前溪
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2021-05-11
Filing date: 2021-05-11
Publication date: 2023-09-15
Also published as: WO2022236682A1

Abstract

A method for sidestream transmission, a terminal device and a network device, the method comprises: the method comprises the steps that a first terminal determines version information of a first data packet or the type of a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) in the first data packet according to association information of the first data packet sent by a second terminal; and determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type corresponding to the first data packet. Therefore, the transmitting end indicates the version information of the data packet or the PDCP SDU type in the data packet through the association information of the transmitted data packet, so that the receiving end determines whether to receive the data packet according to the version information of the data packet or the PDCP SDU type corresponding to the data packet, and the problem of resource waste caused by receiving the data packet with an unsupported version is avoided.

Description

Sidestream transmission method, terminal equipment and network equipment

Technical Field

The embodiment of the application relates to the field of communication, in particular to a sidestream transmission method, terminal equipment and network equipment.

Background

In the related art, it is considered that an address resolution protocol (Address Resolution Protocol, ARP) type packet data convergence protocol (Packet Data Convergence Protocol, PDCP) SDU is introduced in a release 17 (Rel-17) side line relay, whereas release 16 (Rel-16) does not need to support an ARP type PDCP SDU, so how to implement side line packet reception is an urgent problem in a terminal coexistence scenario supporting Rel-16/Rel-17.

Disclosure of Invention

The application provides a method for side transmission, a terminal device and a network device, wherein a transmitting end indicates version information of a data packet or PDCP SDU type of the data packet through association information of the transmitted data packet, so that a receiving end determines whether to receive the data packet according to the version information of the data packet or the PDCP SDU type corresponding to the data packet, which is beneficial to avoiding the problem of resource waste caused by receiving the data packet with an unsupported version.

In a first aspect, a method for sidestream transmission is provided, including: the first terminal determines version information of a first data packet or a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) type of the first data packet according to association information of the first data packet sent by a second terminal;

and determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type of the first data packet.

In a second aspect, a method for sidestream transmission is provided, including: and the second terminal sends a first data packet to the first terminal, wherein the association information of the first data packet is used for determining version information of the first data packet or a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) type of the first data packet.

In a third aspect, a method for sidestream transmission is provided, including: the network device sends first information to the terminal device, wherein the first information is used for determining version information of the side line data packet or packet data convergence protocol PDCP service data unit SDU type of the side line data packet.

A fourth aspect provides a terminal device for performing the method of any one of the first to second aspects or each implementation thereof.

Specifically, the terminal device comprises functional modules for performing the method in any of the above-mentioned first to second aspects or in various implementations thereof.

In a fifth aspect, a network device is provided for performing the method of the third aspect or implementations thereof.

In particular, the network device comprises functional modules for performing the method of the third aspect described above or implementations thereof.

In a sixth aspect, a terminal device is provided, comprising 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 and executing the method in any one of the first to second aspects or each implementation manner thereof.

In a seventh aspect, a network device is provided that includes a processor and a memory. The memory is for storing a computer program and the processor is for calling and running the computer program stored in the memory for performing the method of the third aspect or implementations thereof.

In an eighth aspect, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the method of any one of the above first to third aspects or implementations thereof.

A ninth aspect provides a computer program product comprising computer program instructions for causing a computer to perform the method of any one of the first to third aspects or implementations thereof.

In a tenth aspect, there is provided a computer program which, when run on a computer, causes the computer to perform the method of any one of the above-described first to third aspects or implementations thereof.

An eleventh aspect provides a chip for implementing the method in any one of the first to third aspects or each implementation thereof.

Specifically, the chip includes: a processor for calling and running a computer program from a memory, causing a device in which the apparatus is installed to perform the method as in any one of the above first to third aspects or implementations thereof.

According to the technical scheme, under the condition that the second terminal sends the first data packet to the first terminal, the first terminal can determine whether to receive the first data packet according to the association information of the first data packet, for example, the version information of the first data packet or the PDCP SDU type of the first data packet is determined according to the association information of the first data packet, and further, whether to receive the first data packet or not is determined according to the version information of the first data packet or the PDCP SDU type of the first data packet, so that the problem of resource waste caused by receiving the data packet with an unsupported version is avoided.

Drawings

Fig. 1 is a schematic diagram of a communication system architecture provided by the present application.

Fig. 2 is a schematic diagram of another communication system architecture provided by the present application.

Fig. 3 is a schematic diagram of unicast sidestream communication provided by the present application.

Fig. 4 is a schematic diagram of a multicast side-link communication provided by the present application.

Fig. 5 is a schematic diagram of a broadcast side-by-side communication provided by the present application.

Fig. 6 is a schematic diagram of a format of a MAC PDU according to one embodiment of the present application.

Fig. 7 is a schematic diagram of a format of a MAC PDU sub-header according to one embodiment of the present application.

Fig. 8 is a schematic interaction diagram of a method of sidestream transport according to an embodiment of the present application.

Fig. 9 is a schematic block diagram of a terminal device according to an embodiment of the present application.

Fig. 10 is a schematic block diagram of another terminal device provided according to an embodiment of the present application.

Fig. 11 is a schematic block diagram of a network device provided according to an embodiment of the present application.

Fig. 12 is a schematic block diagram of a communication device provided according to an embodiment of the present application.

Fig. 13 is a schematic block diagram of a chip provided according to an embodiment of the present application.

Fig. 14 is a schematic block diagram of a communication system provided in accordance with an embodiment of the present application.

Detailed Description

The following description of the technical solutions according to the embodiments of the present application will be given with reference to the accompanying 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 those skilled in the art to which the application pertains without inventive faculty, are intended to fall within the scope of the application.

The technical scheme of the embodiment of the application can be applied to various communication systems, such as: global system for mobile communications (Global System of Mobile communication, GSM), code division multiple access (Code Division Multiple Access, CDMA) system, wideband code division multiple access (Wideband Code Division Multiple Access, WCDMA) system, general packet Radio service (General Packet Radio Service, GPRS), long term evolution (Long Term Evolution, LTE) system, long term evolution advanced (Advanced long term evolution, LTE-a) system, new Radio, NR system evolution system, LTE over unlicensed spectrum (LTE-based access to unlicensed spectrum, LTE-U) system, NR over unlicensed spectrum (NR-based access to unlicensed spectrum, NR-U) system, non-terrestrial communication network (Non-Terrestrial Networks, NTN) system, universal mobile telecommunication system (Universal Mobile Telecommunication System, UMTS), wireless local area network (Wireless Local Area Networks, WLAN), wireless fidelity (Wireless Fidelity, wiFi), fifth Generation communication (5 th-Generation, 5G) system, or other communication system, etc.

Generally, the number of connections supported by the conventional communication system is limited and easy to implement, however, as the communication technology advances, the mobile communication system will support not only conventional communication but also, for example, device-to-Device (D2D) communication, machine-to-machine (Machine to Machine, M2M) communication, machine type communication (Machine Type Communication, MTC), inter-vehicle (Vehicle to Vehicle, V2V) communication, or internet of vehicles (Vehicle to everything, V2X) communication, etc., to which the embodiments of the present application can also be applied.

Optionally, the communication system in the embodiment of the present application may be applied to a carrier aggregation (Carrier Aggregation, CA) scenario, a dual connectivity (Dual Connectivity, DC) scenario, or a Stand Alone (SA) fabric scenario.

Optionally, the communication system in the embodiment of the present application may be applied to unlicensed spectrum, where unlicensed spectrum may also be considered as shared spectrum; alternatively, the communication system in the embodiment of the present application may also be applied to licensed spectrum, where licensed spectrum may also be considered as non-shared spectrum.

Embodiments of the present application are described in connection with a network device and a terminal device, where the terminal device may also be referred to as a User Equipment (UE), an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote terminal, a mobile device, a User terminal, a wireless communication device, a User agent, a User Equipment, or the like.

The terminal device may be a STATION (ST) in a WLAN, may be a cellular telephone, a cordless telephone, a session initiation protocol (Session Initiation Protocol, SIP) phone, a wireless local loop (Wireless Local Loop, WLL) STATION, a personal digital assistant (Personal Digital Assistant, PDA) device, a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, a vehicle mounted device, a wearable device, a terminal device in a next generation communication system such as an NR network, or a terminal device in a future evolved public land mobile network (Public Land Mobile Network, PLMN) network, etc.

In the embodiment of the application, the terminal equipment can be deployed on land, including indoor or outdoor, handheld, wearable or vehicle-mounted; can also be deployed on the water surface (such as ships, etc.); but may also be deployed in the air (e.g., on aircraft, balloon, satellite, etc.).

In the embodiment of the present application, the terminal device may be a Mobile Phone (Mobile Phone), a tablet computer (Pad), a computer with a wireless transceiving function, a Virtual Reality (VR) terminal device, an augmented Reality (Augmented Reality, AR) terminal device, a wireless terminal device in industrial control (industrial control), a wireless terminal device in unmanned driving (self driving), a wireless terminal device in remote medical (remote medical), a wireless terminal device in smart grid (smart grid), a wireless terminal device in transportation security (transportation safety), a wireless terminal device in smart city (smart city), or a wireless terminal device in smart home (smart home), and the like.

By way of example, and not limitation, in embodiments of the present application, the terminal device may also be a wearable device. The wearable device can also be called as a wearable intelligent device, and is a generic name for intelligently designing daily wear by applying wearable technology and developing wearable devices, such as glasses, gloves, watches, clothes, shoes and the like. The wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also can realize a powerful function through software support, data interaction and cloud interaction. The generalized wearable intelligent device includes full functionality, large size, and may not rely on the smart phone to implement complete or partial functionality, such as: smart watches or smart glasses, etc., and focus on only certain types of application functions, and need to be used in combination with other devices, such as smart phones, for example, various smart bracelets, smart jewelry, etc. for physical sign monitoring.

In the embodiment of the present application, the network device may be a device for communicating with a mobile device, where the network device may be an Access Point (AP) in a WLAN, a base station (Base Transceiver Station, BTS) in GSM or CDMA, a base station (NodeB, NB) in WCDMA, an evolved base station (Evolutional Node B, eNB or eNodeB) in LTE, a relay station or an Access Point, a vehicle device, a wearable device, a network device or a base station (gNB) in an NR network, a network device in a PLMN network evolved in the future, or a network device in an NTN network, etc.

By way of example, and not limitation, in embodiments of the present application, a network device may have a mobile nature, e.g., the network device may be a mobile device. Alternatively, the network device may be a satellite, a balloon station. For example, the satellite may be a Low Earth Orbit (LEO) satellite, a medium earth orbit (medium earth orbit, MEO) satellite, a geosynchronous orbit (geostationary earth orbit, GEO) satellite, a high elliptical orbit (High Elliptical Orbit, HEO) satellite, or the like. Alternatively, the network device may be a base station disposed on land, in a water area, or the like.

In the embodiment of the present application, a network device may provide services for a cell, where a terminal device communicates with the network device through a transmission resource (e.g., a frequency domain resource, or a spectrum resource) used by the cell, where the cell may be a cell corresponding to the network device (e.g., a base station), and the cell may belong to a macro base station, or may belong to a base station corresponding to a Small cell (Small cell), where the Small cell may include: urban cells (Metro cells), micro cells (Micro cells), pico cells (Pico cells), femto cells (Femto cells) and the like, and the small cells have the characteristics of small coverage area and low transmitting power and are suitable for providing high-rate data transmission services.

It should be understood that the terms "system" and "network" are 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.

The terminology used in the description of the embodiments of the application herein is for the purpose of describing particular embodiments of the application only and is not intended to be limiting of the application. The terms "first," "second," "third," and "fourth" and the like in the description and in the claims and drawings are used for distinguishing between different objects and not necessarily for describing a particular sequential or chronological order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion.

It should be understood that the "indication" mentioned in the embodiments of the present application may be a direct indication, an indirect indication, or an indication having 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.

In the description of the embodiments of the present application, the term "corresponding" may indicate that there is a direct correspondence or an indirect correspondence between the two, or may indicate that there is an association between the two, or may indicate a relationship between the two and the indicated, configured, etc.

In the embodiment of the present application, the "pre-defining" or "pre-configuring" may be implemented by pre-storing corresponding codes, tables or other manners that may be used to indicate relevant information in devices (including, for example, terminal devices and network devices), and the present application is not limited to the specific implementation manner thereof. Such as predefined may refer to what is defined in the protocol.

In the embodiment of the present application, the "protocol" may refer to a standard protocol in the communication field, for example, may include an LTE protocol, an NR protocol, and related protocols applied in a future communication system, which is not limited in the present application.

Fig. 1 is a schematic diagram of a communication system to which an embodiment of the present application is applicable. The transmission resources of the in-vehicle terminals (in-vehicle terminal 121 and in-vehicle terminal 122) are allocated by the base station 110, and the in-vehicle terminals transmit data on the side links according to the resources allocated by the base station 110. Specifically, the base station 110 may allocate resources for single transmission to the terminal, or may allocate resources for semi-static transmission to the terminal.

Fig. 2 is a schematic diagram of another communication system to which embodiments of the present application are applicable. The vehicle-mounted terminals (the vehicle-mounted terminal 131 and the vehicle-mounted terminal 132) autonomously select transmission resources on the resources of the side links to perform data transmission. Optionally, the vehicle-mounted terminal may select the transmission resource randomly, or select the transmission resource by listening.

In LTE-V2X, a broadcast transmission scheme is supported, and in NR-V2X, unicast and multicast transmission schemes are introduced. For unicast transmission, the receiving terminal has only one terminal, as shown in fig. 3, and unicast transmission is performed between UE1 and UE 2; for multicast transmission, the receiving end is all terminals in a communication group or all terminals in a certain transmission distance, as shown in fig. 4, UE1, UE2, UE3 and UE4 form a communication group, wherein UE1 sends data, and other terminal devices in the group are receiving end terminals; for the broadcast transmission mode, the receiving end is any one of the terminals around the transmitting end terminal, as shown in fig. 5, UE1 is the transmitting end terminal, and the other terminals around it, UE2 to UE6 are all receiving end terminals.

In sidelink transmission, a transmitting end terminal may generate a media access control (Media Access Control, MAC) protocol data unit (Protocol Data Unit, PDU) from data to be transmitted, and transmit the MAC PDU to a receiving end terminal.

In some embodiments, a MAC PDU includes a MAC PDU sub-header (sub-header), 0 or at least one MAC sub-PDU (sub-PDU), and possibly padding bits. Fig. 6 is an example of a MAC PDU format.

As shown in fig. 6, one MAC sub-pdu may include a sub-header of one MAC sub-pdu, and one sub-header of one MAC sub-pdu may correspond to one MAC service data unit (service data unit, SDU) or one MAC control element (MAC Control Element, MAC CE) or padding bit.

As shown in fig. 6, a subheader of one MAC subPDU may include at least one of the following fields:

r: reserving bits;

l: a length field for indicating a length of the MAC SDU or the MAC CE in bytes;

f: for indicating the length of the L field.

LCID: logical channel ID field.

Fig. 7 is a schematic diagram of a format of a subheader of a MAC PDU. The meaning of each field in the subheader of the MAC PDU is as follows:

v: version field, 4 bits, set to all 0;

r: a reserved (reserved) bit set to 0;

SRC: a source address field, occupying 16 bits, carrying a 16-bit most effective source layer two (layer 2) Identifier (ID);

DST: the destination address field, which takes 8 bits, carries the 8-bit most efficient destination layer two (layer 2) ID.

In some scenarios, considering that address resolution protocol (Address Resolution Protocol, ARP) type packet data convergence protocol (Packet Data Convergence Protocol, PDCP) SDUs are introduced in release 17 (Rel-17) side line relay, while release 16 (Rel-16) does not need to support ARP type PDCP SDUs, therefore, in a scenario where a Rel-16/Rel-17 enabled terminal coexist, if a Rel-17 terminal sends an ARP type data packet to a Rel-16 terminal, the Rel-16 terminal needs to parse the data packet to the PDCP layer to find that the receiving the data packet is not supported, which increases the resource consumption of the terminal, and therefore, how to implement receiving side line data packets to reduce the resource consumption of the terminal is an urgent problem to be solved.

Fig. 3 is a schematic interaction diagram of a method of sidestream transport according to an embodiment of the present application, as shown in fig. 3, the method 300 may include at least part of the following:

s310, the second terminal sends a first data packet to the first terminal;

s320, the first terminal determines version information of a first data packet or a packet data convergence protocol PDCP service data unit SDU type of the first data packet according to the association information of the first data packet sent by the second terminal;

S330, determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type of the first data packet.

Therefore, in the embodiment of the present application, when the second terminal sends the first data packet to the first terminal, the first terminal may determine whether to receive the first data packet according to the association information of the first data packet, for example, determine version information of the first data packet or PDCP SDU type of the first data packet according to the association information of the first data packet, and further determine whether to receive the first data packet according to the version information of the first data packet or PDCP SDU type of the first data packet, which is beneficial to avoiding the problem of resource waste caused by receiving and analyzing the data of the unsupported version.

In the embodiment of the present application, the version information of the first data packet is one of at least two versions. The at least two versions include a first version and a second version.

Alternatively, in some embodiments of the application, the first version may include Rel-17 and the second version includes Rel-16.

In some embodiments, the first version supports ARP-type packets and the second version does not support ARP-type packets.

It should be appreciated that in some embodiments of the present application, ARP-type packets may be replaced with ARP-type PDCP SDUs, ARP-type MAC PDUs.

In an embodiment of the present application, the first data packet includes a MAC PDU.

The encapsulation process of the protocol layer on the data can know that the MAC SDU in the MAC PDU comes from the PDCP SDU of the PDCP layer, so in the embodiment of the present application, the PDCP SDU type can also be considered as the MAC SDU type.

Optionally, the PDCP SDU type may include PDCP SDUs of ARP type and PDCP SDUs of non-ARP type.

Alternatively, the MAC SDU type may include ARP type MAC SDUs and non-ARP type MAC SDUs.

In some embodiments of the present application, the PDCP SDU type of the first data packet may refer to the PDCP SDU type of the data in the first data packet or the PDCP SDU type of the MAC SDU in the first data packet.

For example, the PDCP SDU type of the first data packet may refer to: the first data packet is PDCP SDU of ARP type, or the first data packet is PDCP SDU of other types.

For another example, the PDCP SDU type of the first data packet may refer to: the first data packet includes PDCP SDUs of ARP type or other types.

In some embodiments of the present application, the association information of the first data packet may be used to indicate version information of the first data packet, or whether a receiving end terminal of the first data packet needs to support an ARP type data packet, or whether the first data packet includes an ARP type PDCP SDU.

Whether the receiving terminal of the first data packet needs to support the ARP type data packet may refer to:

whether the receiving terminal of the first data packet needs to support PDCP SDUs of ARP type, or whether the receiving terminal of the first data packet needs to have the capability of receiving data packets of ARP type, or whether the receiving terminal of the first data packet needs to support data packets of the first version.

In some embodiments, sending or receiving data packets of the ARP type is a capability that the first version of the terminal must support. In this case, the PDCP SDU of ARP type must be included in the first version of the data packet. In this case, the PDCP SDU type indicating the first data packet is equivalent by indicating the version information of the first data packet.

In other embodiments, sending or receiving the ARP-type data packet is an optional capability of the first version of the terminal. In this case, the first version of the packet may or may not include PDCP SDUs of ARP type.

Optionally, in some embodiments, the version information of the first data packet includes a transmission profile (Tx profile) of the first data packet. That is, the first data packet Tx profile may be indicated by association information of the first data packet.

In some scenarios, such as multicast and broadcast services, the first terminal and the second terminal do not establish a PC5 RRC connection, and therefore, the Tx profile information cannot be directly transmitted from the transmitting end to the receiving end, in which case version information, such as Tx profile, may be indicated by the association information of the first data packet.

It should be understood that, in the embodiment of the present application, the association information of the first data packet may refer to any information associated with the first data packet, for example, resource information of the first data packet, scheduling information, information carried in the first data packet, and so on.

In some embodiments of the application, the association information of the first data packet includes side control information (Sidelink Control Information, SCI) for scheduling the first data packet. For example, when the first data packet is scheduled, version information of the scheduled first data packet may be indicated at the same time.

In some embodiments, the SCI includes first indication information for indicating version information of the first data packet.

Alternatively, the first indication information is carried in a reserved field in the SCI, or in a reserved bit, or the version information of the first data packet may be indicated by using an invalid bit of an existing field in the SCI, which is not limited to this.

As an example, the first indication information includes at least one bit, and a value of the at least one bit is used to indicate a target version of version information of the first data packet, where the target version corresponds to the at least two versions. For example, a value of 0 indicates that the target version is the first version, and a value of 1 indicates that the target version is the second version.

In other embodiments of the present application, the association information of the first data packet includes a resource pool for transmitting the first data packet.

For example, the terminal device is configured with a first mapping relationship, where the first mapping relationship is a mapping relationship between a resource pool used for transmitting a data packet and version information of the data packet, so that a receiving end of the data packet can determine the version information corresponding to the data packet according to the resource pool for receiving the data packet.

Alternatively, in some embodiments, the first mapping relationship may be configured by a network device, or predefined, or transmitted by the second terminal to the first terminal.

It should be understood that the present application is not limited to a specific manner in which the second terminal sends the first mapping relationship to the first terminal, for example, in unicast communication, after the second terminal establishes a PC5 RRC connection with the first terminal, the second terminal may send the first mapping relationship to the first terminal.

In some embodiments, the network device may configure corresponding resource pools for the side-link services of the first version and the second version, for example, including a sending resource pool and a receiving resource pool, and the receiving end determines version information corresponding to the data packet through the resource pool used by receiving the data packet.

As an example, the network device configures the first version to correspond to the first resource pool, and the second version to correspond to the second resource pool, and if the first terminal receives the first data packet in the first resource pool, it may determine that version information of the first data packet is the first version.

In still other embodiments of the present application, the first terminal may determine version information of the first data packet according to information carried in the first data packet.

In some embodiments, the information carried in the first data packet includes information in a MAC PDU sub-header of the first data packet. The version information of the first data packet is indicated by the information in the subheader of the MAC PDU of the first data packet, or whether the receiving terminal of the first data packet needs to support the PDCP SDU of ARP type, so that the receiving terminal of the first data packet can know whether the receiving terminal supports the version of the first data packet or not only by analyzing the first data packet to the MAC layer, and further whether the subsequent data is received or not is determined.

In some embodiments, the information carried in the first data packet includes at least one of:

destination address information in header MAC PDU subheader in the first data packet, version information in MAC PDU subheader in the first data packet, reservation information in MAC PDU subheader in the first data packet.

In some embodiments, the first terminal is configured with a second mapping relationship, where the second mapping relationship is used to characterize a mapping relationship between a destination address of the data packet and version information of the data packet.

Therefore, the first terminal can acquire the target address information of the first data packet, and further determine the version information of the first data packet according to the target address information of the first data packet and the second mapping relation.

Alternatively, the first terminal may obtain first destination address information from a DST field in MAC PDU subheader of the first packet, obtain second destination address information from destination address information in SCI scheduling the first packet, and determine destination address information of the first packet according to the first destination address information and the second destination address information.

In some embodiments, the second mapping is configured by the network device, or is sent by the second terminal to the first terminal, or is predefined.

It should be understood that the present application is not limited to a specific manner in which the second terminal transmits the second mapping relationship to the first terminal. For example, in unicast communication, after the second terminal and the first terminal establish a PC5 RRC connection, the second terminal may send the second mapping relationship to the first terminal.

In some embodiments, the value of the V field in MAC PDU subheader of the first data packet indicates a target version of the version information of the first data packet corresponding to at least two versions.

As an example, the V field takes a value of all "0", which indicates that the first packet is a second version of a packet, for example, a Rel-16 type MAC PDU, and at least 1 bit is "1" in the V field, which indicates that the first packet is a first version of a packet, for example, a Rel-17 type MAC PDU.

In some embodiments, the version information of the first data packet indicates a corresponding target version of the at least two versions by a value of at least one R field in MAC PDU subheader of the first data packet.

As an example, the at least one R field has a value of all "0", which indicates that the first packet is a second version of a packet, for example, a Rel-16 type MAC PDU, and the at least one R field has a value of "1", which indicates that the first packet is a first version of a packet, for example, a Rel-17 type MAC PDU.

In some embodiments of the present application, the S330 may include:

in the case that the version information of the first data packet is a first version and the first terminal does not support receiving PDCP SDUs of ARP type, the first terminal discards the first data packet; or alternatively

And in the case that the version information of the first data packet is the first version and the first terminal supports receiving the PDCP SDU of ARP type, the first terminal receives the first data packet.

That is, when the version of the first data packet is a version that is not supported by the first terminal, the first terminal performs overall discard processing (i.e., does not receive data after MAC PDU subheader) on the first data packet, or when the version of the first data packet is a version that is supported by the first terminal, the first terminal performs overall receive processing (i.e., receives data after MAC PDU subheader) on the first data packet.

In some embodiments, when the first data packet is a first version data packet, the first terminal is a first version terminal, and the first version terminal supports that sending or receiving the first version data packet is a necessary capability (that is, the first terminal has a capability of receiving the ARP type data packet), the first terminal determines whether the first data packet is an ARP type data packet according to version information of the first data packet, and further performs overall discard processing or overall receiving processing on the first data packet.

In some scenarios, one MAC PDU may include at least one MAC sub-PDU, and each MAC sub-PDU may include one MAC SDU, and in some embodiments of the present application, the PDCP SDU type of the MAC SDU in the MAC sub-PDU may also be indicated by information in a sub-header in the MAC sub-PDU in the first data packet, for example, whether the MAC SDU includes PDCP SDU data of ARP type, or whether the MAC SDU is PDCP SDU data of ARP type, or the like. Further, the first terminal may determine the PDCP SDU type (or, whether the MAC SDU includes ARP-type PDCP SDU data) of the MAC SDU in each MAC sub-pdu according to the information in the sub-header in each MAC sub-pdu in the first data packet, so as to determine whether to receive the MAC SDU in each MAC sub-pdu, which enables finer-granularity reception control of the first data packet.

In some embodiments, the PDCP SDU type of the MAC SDU in the MAC subPDU, e.g., whether it is (or contains) ARP-type PDCP SDU data, may be indicated by reservation information in a subheader in the MAC subPDU.

As an example, the first data packet includes a first MAC sub-pdu and a second MAC sub-pdu, the first MAC sub-pdu includes a first sub-header, the second MAC sub-pdu includes a second sub-header, a PDCP SDU type of a MAC SDU in the first MAC sub-pdu may be indicated by reservation information in the first sub-header, and a PDCP SDU type of a MAC SDU in the second MAC sub-pdu may be indicated by reservation information in the second sub-header.

For example, if it is determined that the MAC SDU in the first MAC sub-pdu includes the PDCP SDU of the first version according to the reservation information in the first sub-header, it is determined that the MAC SDU in the second MAC sub-pdu includes the PDCP SDU of the second version according to the reservation information in the second sub-header, and the first terminal supports the second version of the data packet and does not support the first version of the data packet, the first terminal does not receive the MAC SDU in the first MAC sub-pdu (performs discard processing on the first MAC sub-pdu), and receives the MAC SDU in the second MAC sub-pdu.

In some embodiments, the PDCP SDU type of the MAC SDU in the MAC sub-pdu, e.g., whether it is ARP-type PDCP SDU data, may be indicated by a logical channel identification (Logic Channel Identify, LCID) in a sub-header in the MAC sub-pdu.

In some embodiments, a third mapping relationship is configured on the first terminal, where the third mapping relationship is used to indicate an LCID corresponding to a PDCP SDU of the ARP type and an LCID corresponding to a PDCP SDU of the non-ARP type.

Corresponding LCIDs may be configured for different types of PDCP SDUs, so that different LCID indications may be used in corresponding MAC subpdus when the second terminal may transmit different versions of PDCP SDUs.

In some embodiments, the third mapping is configured by the network device, or is sent by the second terminal to the first terminal, or is predefined.

It should be understood that the present application is not limited to a specific manner in which the second terminal sends the third mapping relationship to the first terminal, for example, in unicast communication, after the second terminal establishes a PC5 RRC connection with the first terminal, the second terminal may send the third mapping relationship to the first terminal.

As an example, the first data packet includes a first MAC sub-pdu and a second MAC sub-pdu, the first MAC sub-pdu includes a first sub-header, the second MAC sub-pdu includes a second sub-header, a PDCP SDU type of a MAC SDU in the first MAC sub-pdu may be indicated by an LCID in the first sub-header, and a PDCP SDU type of a MAC SDU in the second MAC sub-pdu may be indicated by an LCID in the second sub-header.

For example, if it is determined that the MAC SDU in the first MAC sub-pdu includes the PDCP SDU of the first version according to the LCID in the first sub-header, it is determined that the MAC SDU in the second MAC sub-pdu includes the PDCP SDU of the second version according to the LCID in the second sub-header, and the first terminal supports the second version of the data packet and does not support the first version of the data packet, the first terminal does not receive the MAC SDU in the first MAC sub-pdu (i.e., performs discard processing on the first MAC sub-pdu), and receives the MAC SDU in the second MAC sub-pdu.

In some embodiments of the present application, the method 300 further comprises:

and the first terminal reports first capability information to the second terminal, wherein the first capability information is used for indicating whether the first terminal supports receiving the PDCP SDU of ARP type.

That is, the receiving end of the data packet may report to the sending end of the data packet whether the receiving end supports receiving the data packet of the first version, or whether the receiving end has the capability of receiving the data packet of the first version.

In some embodiments of the present application, the method 200 further comprises:

and the first terminal receives second capability information uploaded by the second terminal, wherein the second capability information is used for indicating whether the second terminal supports receiving the PDCP SDU of the ARP type.

I.e. the sender of the data packet may report to the receiver of the data packet whether itself supports receiving the first version of the data packet, or whether it has the capability of receiving said first version of the data packet.

In summary, the sending end and the receiving end of the data packet can interact with each other to the receiving capability of the first version of the data packet, so that in the subsequent side communication, the sending end of the data packet can send the data packet of the proper version according to the receiving capability of the receiving end, which is beneficial to avoiding the resource waste caused by unnecessary data packet analysis.

It should be understood that the embodiments of the present application are not limited to a specific manner in which the first terminal and the second terminal interact with each other to correspond to the receiving capability of the first version of the data packet, for example, in unicast communication, multicast communication, or broadcast communication interaction.

In some embodiments, the second terminal may send the second capability information to the first terminal in unicast communication. Correspondingly, the first terminal can also send the first capability information to the second terminal in unicast communication

In some embodiments, the second terminal may send the second capability information to the plurality of terminals in multicast communication, wherein the plurality of terminals includes the first terminal. Correspondingly, the first terminal may send the first capability information to the second terminal via a physical sidelink feedback channel (Physical Sidelink Feedback Channel, PSFCH).

In some embodiments, the second terminal may transmit the second capability information in a broadcast communication. Similarly, the first terminal may also transmit the first capability information through broadcast communication.

the second terminal sends capability information of a first target address to the network device, where the capability information of the first target address is used to indicate whether the first target address supports PDCP SDUs of ARP type or whether the first target address supports data packets of a first version. The first target address is a target address of the second terminal.

For example, the capability information of the first target address is reported to the network device through side-link user equipment information (SidelinkUEInformation). Further, the network device may send capability information of the first target address to the first terminal.

For example, in the subsequent side transmission, the first terminal may acquire a target address in the first data packet, further determine whether the target address of the first data packet supports the PDCP SDU of the ARP type in combination with capability information of the first target address, and further determine whether to receive the first data packet.

In summary, in the embodiment of the present application, when the second terminal sends the first data packet to the first terminal, the first terminal may determine whether to receive the first data packet according to the association information of the first data packet, for example, determine version information of the first data packet according to the association information of the first data packet, further determine whether to receive the first data packet according to the version information of the first data packet, or determine the PDCP SDU type of the MAC SDU in each MAC sub pdu in the first data packet according to the information carried in the first data packet, and further determine whether to receive the MAC SDU in each MAC sub pdu in the first data packet according to the PDCP SDU type of the MAC SDU in the first data packet, which is beneficial to avoid the problem that the parsing of the first data packet into the PDCP layer does not support the resource waste caused by the reception of the first data packet.

The method embodiment of the present application is described in detail above with reference to fig. 8, and the apparatus embodiment of the present application is described in detail below with reference to fig. 9 to 13, it being understood that the apparatus embodiment corresponds to the method embodiment, and similar descriptions can refer to the method embodiment.

Fig. 9 shows a schematic block diagram of a terminal device 400 according to an embodiment of the application. As shown in fig. 9, the terminal apparatus 400 includes:

a processing unit 410, configured to determine version information of a first data packet or a type of a packet data convergence protocol PDCP service data unit SDU in the first data packet according to association information of the first data packet sent by a second terminal; and determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type of the first data packet.

In some embodiments of the present application, the association information of the first data packet includes at least one of the following:

the side control information SCI is used for scheduling the first data packet, and is used for transmitting a resource pool of the first data packet, wherein the information is carried in the first data packet.

In some embodiments of the present application, the SCI includes first indication information, where the first indication information is used to indicate version information of the first data packet.

In some embodiments of the present application, the terminal device is configured with a first mapping relationship, where the first mapping relationship is used to characterize a mapping relationship of version information of the resource pool and the data packet.

In some embodiments of the present application, the first mapping relationship is configured by a network device, or is sent to the terminal device by the second terminal, or is predefined.

In some embodiments of the present application, the information carried in the first data packet includes at least one of the following:

the method comprises the steps of controlling target address information in a Media Access Control (MAC) Protocol Data Unit (PDU) subheader in a first data packet, version information in the MAC PDU subheader in the first data packet and reservation information in the MAC PDU subheader in the first data packet.

In some embodiments of the present application, the terminal device is configured with a second mapping relationship, where the second mapping relationship is used to characterize a mapping relationship between a destination address of a data packet and version information of the data packet.

In some embodiments of the present application, the second mapping relationship is configured by a network device, or is sent to the terminal device by the second terminal, or is predefined.

In some embodiments of the present application, the value of the version information in the MAC PDU sub-header of the first data packet is used to indicate a target version of the version information of the first data packet corresponding to at least two versions, where the at least two versions include a first version and a second version.

In some embodiments of the present application, the value of the reservation information in the MAC PDU sub-header of the first data packet is used to indicate a target version of version information of the first data packet corresponding to at least two versions, where the at least two versions include a first version and a second version.

In some embodiments of the present application, the version information of the first data packet is a first version or a second version, where the first version supports sending or receiving PDCP SDUs of an ARP type, and the second version does not support sending or receiving PDCP SDUs of an ARP type.

In some embodiments of the present application, the processing unit 410 is specifically configured to:

controlling a communication unit of the terminal device not to receive the first data packet under the condition that the version information of the first data packet is a first version and the terminal device does not support receiving PDCP SDU of ARP type; or alternatively

And controlling a communication unit of the terminal equipment to receive the first data packet under the condition that the version information of the first data packet is the first version and the terminal equipment supports receiving the PDCP SDU of the ARP type.

In some embodiments of the application, the first version comprises version 17 and the second version comprises version 16.

reservation information in a sub-header of the MAC sub-PDU in the first data packet, and a logical channel identifier LCID in the sub-header of the MAC sub-PDU in the first data packet.

In some embodiments of the present application, the association information of the first data packet is used to determine whether the PDCP SDU type in the MAC sub-PDU in the first data packet is an ARP type.

In some embodiments of the present application, the different values of the reservation information in the subheader of the MAC sub-PDU of the first data packet are used to indicate whether the PDCP SDU type in the MAC sub-PDU is an ARP type.

In some embodiments of the present application, a third mapping relationship is configured on the terminal device, where the third mapping relationship is used to indicate LCID corresponding to PDCP SDU of ARP type and LCID corresponding to PDCP SDU of non-ARP type.

In some embodiments of the present application, the third mapping relationship is configured by a network device, or is sent to the terminal device by the second terminal, or is predefined.

controlling a communication unit of the terminal device to receive the MAC SDU in the first MAC sub-PDU under the condition that the first MAC sub-PDU in the first data packet comprises the PDCP SDU of ARP type and the terminal device supports receiving the PDCP SDU of ARP type; or alternatively

In the case that the first MAC sub-PDU in the first data packet includes a PDCP SDU of ARP type and the terminal device does not support reception of the PDCP SDU of ARP type, the communication unit controlling the terminal device does not receive the MAC SDU in the first MAC sub-PDU.

In some embodiments of the present application, the terminal device further includes:

and the communication unit is used for reporting first capability information to the second terminal, wherein the first capability information is used for indicating whether the terminal equipment supports receiving the PDCP SDU of the ARP type.

In some embodiments of the present application, the first capability information is sent via a physical sidelink feedback channel PSFCH.

and the terminal equipment receives second capability information reported by the second terminal, wherein the second capability information is used for indicating whether the second terminal supports receiving the PDCP SDU of the ARP type.

In some embodiments of the present application, the version information of the first data packet includes a transmission specification of the first data packet.

Alternatively, in some embodiments, the communication unit may be a communication interface or transceiver, or an input/output interface of a communication chip or a system on a chip. The processing unit may be one or more processors.

It should be understood that the terminal device 400 according to the embodiment of the present application may correspond to the terminal device in the embodiment of the method of the present application, and the foregoing and other operations and/or functions of each unit in the terminal device 400 are respectively for implementing the corresponding flow of the first terminal in the method 300 shown in fig. 8, and are not repeated herein for brevity.

Fig. 10 is a schematic block diagram of a terminal device according to another embodiment of the present application. The terminal device 500 of fig. 10 includes:

a communication unit 510, configured to send a first data packet to a first terminal, where association information of the first data packet is used to determine version information of the first data packet or a type of a packet data convergence protocol PDCP service data unit SDU in the first data packet.

In some embodiments of the present application, the first terminal is configured with a first mapping relationship, where the first mapping relationship is used to characterize a mapping relationship of version information of the resource pool and the data packet.

In some embodiments of the present application, the second mapping relationship is configured by the network device or predefined.

In some embodiments of the present application, the value of the version information in the MAC PDU sub-header of the first data packet is used to indicate that the version information of the first data packet is a target version corresponding to at least two versions, where the at least two versions include a first version and a second version.

In some embodiments of the present application, the value of the reservation information in the MAC PDU sub-header of the first data packet is used to indicate that the version information of the first data packet is a target version corresponding to at least two versions, where the at least two versions include a first version and a second version.

In some embodiments of the present application, the value of the reservation information in the subheader of the MAC sub-PDU of the first data packet is used to indicate whether the PDCP SDU type in the MAC sub-PDU is an ARP type.

In some embodiments of the present application, the third mapping relationship is configured by the network device or predefined.

and the communication unit is used for receiving the first capability information reported by the first terminal, and the first capability information is used for indicating whether the first terminal supports receiving the PDCP SDU of the ARP type.

and the communication unit is used for reporting second capability information to the first terminal, wherein the second capability information is used for indicating whether the terminal equipment supports receiving the PDCP SDU of the ARP type.

a communication unit, configured to send capability information of a first target address to a network device, where the capability information of the first target address is used to indicate whether the first target address needs to support PDCP SDUs of ARP type, and the first target address is a target address of the terminal device.

In some embodiments of the present application, the capability information of the first target address is reported to the network device through the side uplink user equipment information.

It should be understood that the terminal device 500 according to the embodiment of the present application may correspond to the network device in the embodiment of the method of the present application, and the above and other operations and/or functions of each unit in the terminal device 500 are respectively for implementing the corresponding flow of the second terminal in the method 300 shown in fig. 8, which is not described herein for brevity.

Fig. 11 is a schematic block diagram of a network device according to an embodiment of the present application. The network device 800 of fig. 11 includes:

a communication unit 810, configured to send first information to a terminal device, where the first information is used to determine version information of a side line data packet or a type of a packet data convergence protocol PDCP service data unit SDU in the side line data packet.

Optionally, the terminal device may be the first terminal and/or the second terminal described above.

In some embodiments of the application, the first information includes at least one of:

the first mapping relation is used for indicating the mapping relation of the resource pool and version information of the data packet;

the second mapping relation is used for indicating the mapping relation between the target address of the side line data packet and the version information of the side line data packet;

and the third mapping relation is used for indicating a logical channel identifier LCID corresponding to the PDCP SDU of the ARP type and LCID corresponding to the PDCP SDU of the non-ARP type.

In some embodiments of the present application, the communication unit 810 is further configured to:

and receiving capability information of a first target address reported by the terminal equipment, wherein the capability information of the first target address is used for indicating whether the first target address needs to support the PDCP SDU of an ARP type, and the first target address is the target address of the terminal equipment.

In some embodiments of the present application, the version information of the sidestream data packet is a first version or a second version, where the first version supports sending or receiving PDCP SDUs of the ARP type, and the second version does not support sending or receiving PDCP SDUs of the ARP type.

It should be understood that the network device 800 according to the embodiment of the present application may correspond to the network device in the embodiment of the method of the present application, and the foregoing and other operations and/or functions of each unit in the network device 800 are respectively for implementing the corresponding flow of the network device in the method 300 shown in fig. 8, which is not described herein for brevity.

Fig. 12 is a schematic block diagram of a communication device 600 according to an embodiment of the present application. The communication device 600 shown in fig. 12 comprises a processor 610, from which the processor 610 may call and run a computer program to implement the method in an embodiment of the application.

Optionally, as shown in fig. 12, the communication device 600 may further comprise a memory 620. Wherein the processor 610 may call and run a computer program from the memory 620 to implement the method in an embodiment of the application.

The memory 620 may be a separate device from the processor 610 or may be integrated into the processor 610.

Optionally, as shown in fig. 12, the communication device 600 may further include a transceiver 630, and the processor 610 may control the transceiver 630 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.

The transceiver 630 may include a transmitter and a receiver, among others. Transceiver 630 may further include antennas, the number of which may be one or more.

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

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

Fig. 13 is a schematic structural view of a chip of an embodiment of the present application. The chip 700 shown in fig. 13 includes a processor 710, and the processor 710 may call and run a computer program from a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 13, chip 700 may also include memory 720. Wherein the processor 710 may call and run a computer program from the memory 720 to implement the method in an embodiment of the application.

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

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

Optionally, the chip 700 may further include an output interface 740. The processor 710 may control the output interface 740 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 the 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 the first terminal or the second terminal in the embodiment of the present application, and the chip may implement a corresponding flow implemented by the first terminal or the second terminal 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. 14 is a schematic block diagram of a communication system 900 provided by an embodiment of the present application. As shown in fig. 14, the communication system 900 includes a first terminal 910, a second terminal 920, and a network device 930.

The first terminal 910 may be used to implement the corresponding function implemented by the first terminal or the second terminal in the above method, the second terminal 920 may be used to implement the corresponding function implemented by the second terminal in the above method, and the network device 930 may be used to implement the corresponding function implemented by the network device in the above method, which is 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 the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding 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 application may be 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 illustrative but not restrictive, 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.

The embodiment of the application also provides 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 embodiment 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 embodiment of the present application, which is not described herein for brevity.

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

The embodiment of the application also provides a computer program product comprising computer program instructions.

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

Optionally, the computer program product may be applied to the first terminal or the second terminal in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the first terminal or the second terminal 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 embodiment 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 embodiment of the present application, which is not described herein for brevity.

Optionally, the computer program may be applied to the first terminal or the second terminal in the embodiment 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 first terminal or the second terminal in each method in the embodiment of the present application, which is not described herein for brevity.

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 by the present 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 the embodiments 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 this 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, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-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 illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within 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 sidestream transmission, comprising:

the first terminal determines version information of a first data packet or a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) type of the first data packet according to association information of the first data packet sent by a second terminal;

and determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type of the first data packet.
The method of claim 1, wherein the association information of the first data packet comprises at least one of:

the side control information SCI is used for scheduling the first data packet, and is used for transmitting a resource pool of the first data packet, wherein the information is carried in the first data packet.
The method of claim 2 wherein the SCI includes first indication information indicating version information of the first data packet.
A method according to claim 2 or 3, wherein the first terminal is configured with a first mapping relationship, and the first mapping relationship is used for representing a mapping relationship of version information of the resource pool and the data packet.
The method according to any of claims 2-4, wherein the information carried in the first data packet comprises at least one of:

the method comprises the steps of controlling target address information in a Media Access Control (MAC) Protocol Data Unit (PDU) subheader in a first data packet, version information in the MAC PDU subheader in the first data packet and reservation information in the MAC PDU subheader in the first data packet.
The method of claim 5, wherein the first terminal is configured with a second mapping relationship, and the second mapping relationship is used for representing a mapping relationship between a destination address of the data packet and version information of the data packet.
The method of claim 6, wherein the second mapping is configured by a network device or is sent by the second terminal to the first terminal or is predefined.
The method according to any of claims 5-7, wherein the value of the version information in the MAC PDU sub-header of the first data packet is used to indicate a target version of the version information of the first data packet corresponding to at least two versions, wherein the at least two versions include a first version and a second version.
The method according to any of claims 5-8, wherein the value of the reservation information in the MAC PDU sub-header of the first data packet is used to indicate a target version of the version information of the first data packet corresponding to at least two versions, wherein the at least two versions include a first version and a second version.
The method according to any of claims 2-9, wherein the version information of the first data packet is a first version supporting sending or receiving PDCP SDUs of the address resolution protocol ARP type or a second version not supporting sending or receiving PDCP SDUs of the ARP type.
The method of claim 10, wherein the determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type of the first data packet comprises:

in the case that the version information of the first data packet is a first version and the first terminal does not support receiving PDCP SDUs of ARP type, the first terminal discards the first data packet; or alternatively

And in the case that the version information of the first data packet is the first version and the first terminal supports receiving the PDCP SDU of ARP type, the first terminal receives the first data packet.
The method of any of claims 8-11, wherein the first version comprises version 17 and the second version comprises version 16.
The method of claim 1, wherein the association information of the first data packet comprises at least one of:

reservation information in a sub-header of the MAC sub-PDU in the first data packet, and a logical channel identifier LCID in the sub-header of the MAC sub-PDU in the first data packet.
The method of claim 13 wherein the association information of the first data packet is used to determine whether the PDCP SDU type of the MAC sub-PDU in the first data packet is an ARP type.
The method of claim 14 wherein the different values of the reservation information in the subheader of the MAC sub-PDU of the first data packet are used to indicate whether the PDCP SDU type of the MAC sub-PDU is ARP type.
The method according to any of claims 13-15, wherein a third mapping relationship is configured on the first terminal, where the third mapping relationship is used to indicate an LCID corresponding to a PDCP SDU of ARP type and an LCID corresponding to a PDCP SDU of non-ARP type.
The method of claim 16, wherein the third mapping is configured by a network device, or is sent by the second terminal to the first terminal, or is predefined.
The method according to any of claims 14-17, wherein the determining whether to receive the first data packet according to version information of the first data packet or PDCP SDU type of the first data packet comprises:

in the case that a first MAC sub-PDU in the first data packet includes a PDCP SDU of ARP type and the terminal device supports receiving the PDCP SDU of ARP type, the terminal device receives the MAC SDU in the first MAC sub-PDU; or alternatively

In the case that the first MAC sub-PDU in the first data packet includes a PDCP SDU of ARP type and the terminal device does not support reception of the PDCP SDU of ARP type, the terminal device discards the MAC SDU in the first MAC sub-PDU.
The method according to any one of claims 1-18, further comprising:

and the first terminal reports first capability information to the second terminal, wherein the first capability information is used for indicating whether the first terminal supports receiving the PDCP SDU of ARP type.
The method of claim 19, wherein the first capability information is transmitted over a physical sidelink feedback channel, PSFCH.
The method according to any one of claims 1-20, further comprising:

and the first terminal receives second capability information uploaded by the second terminal, wherein the second capability information is used for indicating whether the second terminal supports receiving the PDCP SDU of the ARP type.
The method according to any of claims 1-21, wherein the version information of the first data packet comprises a transmission specification of the first data packet.
A method of sidestream transmission, comprising:

and the second terminal sends a first data packet to the first terminal, wherein the association information of the first data packet is used for determining the version information of the first data packet or the type of a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) in the first data packet.
The method of claim 23, wherein the association information of the first data packet comprises at least one of:

the side control information SCI is used for scheduling the first data packet, and is used for transmitting a resource pool of the first data packet, wherein the information is carried in the first data packet.
The method of claim 24 wherein the SCI includes first indication information indicating version information of the first data packet.
The method according to claim 24 or 25, wherein the first terminal is configured with a first mapping relationship, and the first mapping relationship is used for representing a mapping relationship of version information of the resource pool and the data packet.
The method according to any one of claims 24-26, wherein the information carried in the first data packet comprises at least one of:

the method comprises the steps of controlling target address information in a Media Access Control (MAC) Protocol Data Unit (PDU) subheader in a first data packet, version information in the MAC PDU subheader in the first data packet and reservation information in the MAC PDU subheader in the first data packet.
The method of claim 27, wherein the second terminal is configured with a second mapping relationship, and the second mapping relationship is used for characterizing a mapping relationship between a destination address of the data packet and version information of the data packet.
The method of claim 28, wherein the second mapping is network device configured or predefined.
The method according to any of claims 27-29, wherein the value of the version information in the MAC PDU sub-header of the first data packet is used to indicate that the version information of the first data packet is a target version corresponding to at least two versions, wherein the at least two versions include a first version and a second version.
The method according to any of claims 27-30, wherein the value of the reservation information in the MAC PDU sub-header of the first data packet is used to indicate that the version information of the first data packet is a target version corresponding to at least two versions, wherein the at least two versions include a first version and a second version.
The method according to any of claims 24-31, wherein the version information of the first data packet is a first version supporting transmitting or receiving PDCP SDUs of the address resolution protocol ARP type or a second version not supporting transmitting or receiving PDCP SDUs of the ARP type.
The method of any of claims 30-32, wherein the first version comprises version 17 and the second version comprises version 16.
The method according to any of claims 23-33, wherein the version information of the first data packet comprises a transmission specification of the first data packet.
The method of claim 23, wherein the association information of the first data packet comprises at least one of:

reservation information in a sub-header of the MAC sub-PDU in the first data packet, and a logical channel identifier LCID in the sub-header of the MAC sub-PDU in the first data packet.
The method of claim 35 wherein the association information of the first data packet is used to determine whether the PDCP SDU type of the MAC sub-PDU in the first data packet is ARP.
The method of claim 36 wherein the value of the reservation information in the subheader of the MAC sub-PDU of the first data packet is used to indicate whether the PDCP SDU type of the MAC sub-PDU is ARP type.
The method according to any of claims 35-37, wherein a third mapping relationship is configured on the second terminal, where the third mapping relationship is used to indicate an LCID corresponding to a PDCP SDU of ARP type and an LCID corresponding to a PDCP SDU of non-ARP type.
The method of claim 38, wherein the third mapping is network device configured or predefined.
The method of any one of claims 23-39, further comprising:

and the second terminal receives first capability information uploaded by the first terminal, wherein the first capability information is used for indicating whether the first terminal supports receiving the PDCP SDU of ARP type.
The method of claim 40, wherein the first capability information is sent over a physical sidelink feedback channel, PSFCH.
The method of any one of claims 23-41, further comprising:

and the second terminal reports second capability information to the first terminal, wherein the second capability information is used for indicating whether the second terminal supports receiving the PDCP SDU of ARP type.
The method of any one of claims 23-42, further comprising:

the second terminal sends capability information of a first target address to the network device, wherein the capability information of the first target address is used for indicating whether the first target address needs to support PDCP SDUs of ARP type, and the first target address is the target address of the second terminal.
The method of claim 43, wherein the capability information of the first destination address is reported to the network device via side-uplink user equipment information.
A method of sidestream transmission, comprising:

the network device sends first information to the terminal device, wherein the first information is used for determining version information of a side line data packet or the type of a packet data convergence protocol PDCP service data unit SDU in the side line data packet.
The method of claim 45, wherein the first information comprises at least one of:

the first mapping relation is used for indicating the mapping relation of the resource pool and version information of the data packet;

the second mapping relation is used for indicating the mapping relation between the target address of the side line data packet and the version information of the side line data packet;

and the third mapping relation is used for indicating a logical channel identifier LCID corresponding to the PDCP SDU of the ARP type and LCID corresponding to the PDCP SDU of the non-ARP type.
The method of claim 45 or 46, further comprising:

the network device receives capability information of a first target address reported by the terminal device, wherein the capability information of the first target address is used for indicating whether the first target address needs to support PDCP SDU of ARP type, and the first target address is the target address of the terminal device.
The method of claim 47, wherein the capability information of the first destination address is reported to the network device via side-uplink user equipment information.
The method according to any of claims 45-48, wherein the version information of the sideline data packet is a first version supporting sending or receiving PDCP SDUs of the address resolution protocol ARP type or a second version not supporting sending or receiving PDCP SDUs of the ARP type.
The method of claim 49, wherein the first version comprises version 17 and the second version comprises version 16.
A terminal device, comprising:

a processing unit, configured to determine version information of a first data packet or a type of a packet data convergence protocol PDCP service data unit SDU in the first data packet according to association information of the first data packet sent by a second terminal; and determining whether to receive the first data packet according to the version information of the first data packet or the PDCP SDU type of the first data packet.
A terminal device, comprising:

And the communication unit is used for sending a first data packet to the first terminal, wherein the association information of the first data packet is used for determining the version information of the first data packet or the type of a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) in the first data packet.
A network device, comprising:

a communication unit, configured to send first information to a terminal device, where the first information is used to determine version information of a side line data packet or a type of a packet data convergence protocol PDCP service data unit SDU in the side line data 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 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 for performing the method of any of claims 23 to 44.
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 1 to 22 or the method of any one of claims 23 to 44.
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 or the method of any one of claims 23 to 44.
A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 1 to 22 or the method of any one of claims 23 to 44.
A computer program, characterized in that the computer program causes a computer to perform the method of any one of claims 1 to 22 or the method of any one of claims 23 to 44.
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 45 to 50.
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 45 to 50.
A computer readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 45 to 50.
A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 45 to 50.
A computer program, characterized in that the computer program causes a computer to perform the method of any one of claims 45 to 50.