WO2022184043A1

WO2022184043A1 - Multicast service receiving method and configuring method, terminal, and network side device

Info

Publication number: WO2022184043A1
Application number: PCT/CN2022/078552
Authority: WO
Inventors: 刘佳敏
Original assignee: 维沃移动通信有限公司
Priority date: 2021-03-05
Filing date: 2022-03-01
Publication date: 2022-09-09
Also published as: CN115038048B; CN115038048A

Abstract

The present application relates to the technical field of wireless communications, and discloses a multicast service receiving method and configuring method, a terminal, and a network side device. The multicast service receiving method comprises: determining, according to an RNTI type, an HARQ process identifier and/or a logical channel identifier corresponding to received data, an RLC entity to which the received data belongs, the RLC entity being an RLC entity of unicast data, a PTP RLC entity of a target multicast service, or a PTM RLC entity of a target multicast service (31).

Description

Multicast service receiving method, configuration method, terminal and network side device

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Chinese Patent Application No. 202110247336.8 filed in China on Mar. 05, 2021, the entire contents of which are hereby incorporated by reference.

technical field

The present application belongs to the technical field of wireless communication, and specifically relates to a method for receiving a multicast service, a method for configuring the service, a terminal and a network side device.

Background technique

In the long-term evolution (Long Term Evolution, LTE) broadcast multicast transmission, it supports multicast broadcast single frequency network (Multicast Broadcast Single Frequency Network, MBSFN) mode Multimedia multicast broadcast service (Multimedia Broadcast Multicast Service, MBMS) transmission and single Cell point-to-multipoint (Single cell Point to Multipoint, sc-ptm) multicast service transmission. In the MBSFN mode, cells in the same MBSFN area will synchronously send the same broadcast service, which is convenient for user equipment (User Equipment, UE, also called terminal) to receive. The control information (control channel parameters, traffic channel parameters, scheduling information, etc.) and data information of the MBMS service are sent in a broadcast manner, so that both idle and connected UEs can receive the MBMS service. The biggest difference between sc-ptm and MBSFN is that it is only scheduled and sent in a single cell, and the service is scheduled by the Group Radio Network Tempory Identity (G-RNTI). In the broadcast message, broadcast control channel parameters, service identification and period information, etc., the scheduling information is notified by the Physical Downlink Control Channel (PDCCH) scrambled by G-RNTI, and the data part is sent by multicast. It is equivalent to that the interested UE monitors the G-RNTI to obtain data scheduling and then receives it.

For a multicast service, the network side can configure two paths for the UE to transmit at the same time, one is a point-to-point (Point to Point, PTP) path, and the other is a point-to-multipoint (Point to Multipoint, PTM) path. The PTM path refers to the use of a public wireless network temporary identity (Radio Network Tempory Identity, RNTI), such as G-RNTI to scramble the PDCCH, and all users in the group monitor the G-RNTI scheduling and receive subsequent scheduling data. The transmission can be received by multiple UEs at a time, and the PTP path refers to the use of the UE-specific Cell Radio Network Temporary Identifier (C-RNTI) to scramble the PDCCH. Only this UE can monitor the C-RNTI. Scheduling of the RNTI and receiving subsequent scheduling data, a transmission can only be received by one UE at a time.

PTM transmits to multiple UEs at the same time, and the transmission efficiency is high, but it needs to comprehensively consider the coverage of all UEs, so the selection of transmission parameters needs to be applicable to all UEs as much as possible, such as using omnidirectional antennas, considering poor users link quality, etc., PTM may not work well for individual UEs with extremely poor link quality. PTP is a dedicated transmission of a UE. You can adjust the transmission parameters by considering the link of the user, such as using a directional or shaped antenna, and set the appropriate transmission parameters according to the current link of the UE. Therefore, the transmission effect for a single UE is better. Good, but if there are multiple users, multiple transmission resources are required, and the resource efficiency is low.

In the prior art, only one PTM transmission mode is used for multicast transmission of LTE, and there is no PTP path.

The multicast transmission designed by NR, especially for multicast high quality of service (Quality of Service, QoS) requirements (multicast high QoS requirement) services, all UEs need to receive in the connected (Connected) state, so it has the ability to configure the PTP path at the same time. And the possibility of the PTM path, when there is the possibility of multi-path transmission of the multicast service, how to distinguish whether the received data belongs to unicast data or multicast data, and the PTP RLC entity or PTM RLC entity to which the multicast data belongs is an urgent problem to be solved. The problem.

SUMMARY OF THE INVENTION

The purpose of the embodiments of the present application is to provide a method for receiving a multicast service, a configuration method, a terminal and a network side device, which can solve the problem of how to distinguish the types of received data when there is multi-path transmission of the multicast service.

In order to solve the above technical problems, this application is implemented as follows:

In a first aspect, a method for receiving a multicast service is provided, executed by a terminal, and the method includes:

Determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, where the RLC entity is an RLC entity for unicast data and a PTP for target multicast services RLC entity or PTM RLC entity of the target multicast service.

In a second aspect, a method for configuring a multicast service is provided, which is performed by a network side device, and the method includes:

Send configuration information of at least one target multicast service to the terminal, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and, the PTP receiving entity of the target MRB configuration information;

The configuration information of the PTM receiving entity includes at least one of the following: the logical channel identifier of the PTM receiving entity, the configuration information of the PTM RLC entity, the G-RNTI used for scheduling the data of the target multicast service, the Indication information of whether the data of the PTM RLC entity is allowed to use the PDCCH scrambled by the C-RNTI;

The configuration information of the PTP receiving entity includes at least one of the following items: the configuration information of the PTP RLC entity and the logical channel identifier of the PTP receiving entity.

In a third aspect, a device for receiving a multicast service is provided, including:

A determination module for determining the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, where the RLC entity is an RLC entity of unicast data, a target The PTP RLC entity of the multicast service or the PTM RLC entity of the target multicast service.

In a fourth aspect, a device for configuring a multicast service is provided, including:

A sending module, configured to send configuration information of at least one target multicast service to the terminal, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and, the target Configuration information of the PTP receiving entity of the MRB;

In a fifth aspect, a terminal is provided, the terminal includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor, when the program or instruction is executed by the processor The steps of implementing the method as described in the first aspect.

In a sixth aspect, a network side device is provided, the network side device includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor, the program or instruction being executed by the The processor implements the steps of the method as described in the second aspect when executed.

In a seventh aspect, a readable storage medium is provided, and a program or an instruction is stored on the readable storage medium, and when the program or instruction is executed by a processor, the steps of the method described in the first aspect, or the The steps of the method of the second aspect.

In an eighth aspect, a chip is provided, the chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is used to run a network-side device program or instruction, and implements the method described in the first aspect. the method described, or implement the method described in the second aspect.

In a ninth aspect, a program product is provided, the program product is stored in a non-volatile storage medium, and the program product is executed by at least one processor to implement the method as described in the first aspect, or implement the method as described in the first aspect. The method described in the second aspect.

In the embodiment of the present application, when there is multi-path transmission of the multicast service, the terminal may determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data , effectively distinguishing the RLC entity to which the received data belongs, which is beneficial to ensure high reliability and efficient reception of multicast services by users, and greatly improves the UE's MBS service receiving experience on the basis of ensuring system efficiency.

Description of drawings

FIG. 1 is a block diagram of a wireless communication system to which an embodiment of the application can be applied;

FIG. 2 is a schematic diagram of a basic architecture of a terminal in multipath transmission involved in an embodiment of the present application;

3 is a schematic flowchart of a method for receiving a multicast service according to an embodiment of the present application;

4 is a schematic flowchart of a method for configuring a multicast service according to an embodiment of the present application;

5 is a schematic structural diagram of an apparatus for receiving a multicast service according to an embodiment of the present application;

6 is a schematic structural diagram of an apparatus for configuring a multicast service according to an embodiment of the present application;

FIG. 7 is a schematic structural diagram of a communication device according to an embodiment of the application;

8 is a schematic diagram of a hardware structure of a terminal according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a hardware structure of a network side device according to an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

The terms "first", "second" and the like in the description and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It is to be understood that the data so used are interchangeable under appropriate circumstances so that the embodiments of the present application can be practiced in sequences other than those illustrated or described herein, and "first", "second" distinguishes Usually it is a class, and the number of objects is not limited. For example, the first object may be one or multiple. In addition, "and/or" in the description and claims indicates at least one of the connected objects, and the character "/" generally indicates that the associated objects are in an "or" relationship.

It is worth noting that the technologies described in the embodiments of this application are not limited to Long Term Evolution (LTE)/LTE-Advanced (LTE-Advanced, LTE-A) systems, and can also be used in other wireless communication systems, such as code Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (Orthogonal Frequency Division Multiple Access, OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA) and other systems. The terms "system" and "network" in the embodiments of the present application are often used interchangeably, and the described technology can be used not only for the above-mentioned systems and radio technologies, but also for other systems and radio technologies. However, the following description describes a New Radio (NR) system for example purposes, and NR terminology is used in most of the description below, although these techniques are also applicable to applications other than NR system applications, such as 6th generation ( 6th ^Generation , 6G) communication system.

FIG. 1 shows a block diagram of a wireless communication system to which the embodiments of the present application can be applied. The wireless communication system includes a terminal 11 and a network-side device 12 . The terminal 11 may also be called a terminal device or a user terminal (User Equipment, UE), and the terminal 11 may be a mobile phone, a tablet computer (Tablet Personal Computer), a laptop computer (Laptop Computer) or a notebook computer, a personal digital computer Assistant (Personal Digital Assistant, PDA), handheld computer, netbook, ultra-mobile personal computer (ultra-mobile personal computer, UMPC), mobile Internet device (Mobile Internet Device, MID), wearable device (Wearable Device) or vehicle-mounted device (VUE), pedestrian terminal (PUE) and other terminal-side devices, wearable devices include: bracelets, headphones, glasses, etc. It should be noted that, the embodiment of the present application does not limit the specific type of the terminal 11 . The network side device 12 may be a base station or a core network, wherein the base station may be referred to as a Node B, an evolved Node B, an access point, a Base Transceiver Station (BTS), a radio base station, a radio transceiver, a basic service Set (Basic Service Set, BSS), Extended Service Set (Extended Service Set, ESS), Node B, Evolved Node B (eNB), Home Node B, Home Evolved Node B, WLAN Access Point, WiFi Node, Send Transmitting Receiving Point (TRP) or some other suitable term in the field, as long as the same technical effect is achieved, the base station is not limited to specific technical terms. The base station in the NR system is taken as an example, but the specific type of the base station is not limited.

The method for receiving the multicast service, the configuration method, the terminal, and the network-side device provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings through specific embodiments and application scenarios thereof.

Please refer to FIG. 2 , which is a schematic diagram of a basic architecture of a terminal in multi-path transmission involved in an embodiment of the present application.

Please refer to 1) in Figure 2. In the first architecture, only one leg (PTM leg) is configured for an MBMS bearer (MRB) on the network side, that is, a PTM Radio Link Control (RLC) entity is configured (entity), when scheduling transmission, either the PDCCH scrambled by G-RNTI can be used to schedule and transmit the data of this PTM RLC entity (that is, the PTM link in 1 of Figure 2), or the data scrambled by C-RNTI can be used. PDCCH is used to schedule and transmit the data of this PTM RLC entity (that is, the PTP link in Figure 2 1)). The scheduling of PDCCH scrambled with G-RNTI is equivalent to transmitting to multiple UEs at the same time, and multiple UEs receive it together, and the transmission efficiency is high. , while the PDCCH scrambled by the C-RNTI is used for transmission for one UE, and the transmission parameters can be adjusted according to the link quality of a single UE, and the transmission success rate is higher.

Please refer to 2 in Figure 2). In the second architecture, the network side configures two legs (PTM leg and PTP leg) for one MRB at the same time, that is, the PTM RLC entity and the PTP RLC entity are configured at the same time. Data can only be scheduled through the PDCCH scrambled by the C-RNTI (ie, the PTP link in Figure 2, 2)), while the data of the PTM RLC entity can be scheduled through the PDCCH scrambled by the G-RNTI or through the C-RNTI scrambled PDCCH. RNTI scrambled PDCCH scheduling (ie, PTP link and PTM link in Figure 2, 2).

A typical application scenario of the first architecture is that the PTM leg data is first transmitted from the network side to multiple UEs through the G-RNTI of the PTM link. Suppose there are a total of 100 UEs, of which 90 UEs receive correct , HARQ ACK is fed back, the remaining 10 UEs fail to decode, and HARQ NACK is fed back, then the network side can use their respective C-RNTI to retransmit the above HARQ process again for these 10 UEs, and the retransmission is successfully received , the 10 UEs can send the correctly decoded data to the corresponding PTM RLC entity for subsequent processing.

In the second architecture, both the data of the same PTM leg may be transmitted by different links, but also the transmission of different legs. There are more path choices, leaving more flexibility for the network side, which is convenient for the network On the basis of considering the overall efficiency, try to improve the receiving success rate of each UE.

The current problem is that all are scheduled by the PDCCH scrambled by the C-RNTI, how does the UE distinguish which of the following data is scheduled by the PDCCH scrambled by the C-RNTI this time:

Unicast data needs to be sent to the corresponding SRB or DRB for subsequent processing;

PTP leg data needs to be sent to the PTP RLC entity for subsequent processing;

PTM leg data needs to be sent to the correct PTM RLC entity.

In order to solve the above problem, please refer to FIG. 3 , an embodiment of the present application provides a method for receiving a multicast service, which is executed by a terminal, including:

Step 31: According to the wireless network temporary identification (Radio Network Tempory Identity, RNTI) type, hybrid automatic repeat request (Hybrid Automatic Repeat reQuest, HARQ) process identification (process ID) and/or logical channel identification ( Logical channel ID), determine the RLC entity to which the received data belongs, and the RLC entity is the RLC entity of the unicast data, the PTP RLC entity of the target multicast service or the PTM RLC entity of the target multicast service.

In the embodiment of the present application, when the multicast service has multi-path transmission, the terminal may determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, Effectively distinguish the RLC entities to which the received data belongs, and receive MBS services on different paths, which not only ensures the flexibility of network scheduling, but also ensures the user experience of the UE. On the basis of improving the QoS and experience of the UE receiving MBS services , to further ensure system efficiency.

The RNTI type corresponding to the received data refers to whether the received data is scheduled by the C-RNTI or by the G-RNTI.

(1) In some embodiments of the present application, optionally, according to the RNTI type, HARQ process identifier and new data indicator (New data indicator, NDI) corresponding to the received data, it is determined that the received data belongs to the RLC entity.

Optionally, according to the RNTI type, HARQ process identifier and NDI corresponding to the received data, it is determined that the RLC entity to which the received data belongs includes at least one of the following:

1) The physical layer recognizes that the received data is scheduled by the PDCCH scrambled by the cell wireless network temporary identifier C-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

In this embodiment of the present application, optionally, if it is identified that the received data is scheduled by the PDCCH scrambled by the C-RNTI, and the received data is identified as initial transmission data according to the NDI of the received data, it is determined that the received data is Data is scheduled by C-RNTI scrambled PDCCH.

In this embodiment of the present application, optionally, if it is identified that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the received data is identified as retransmission data according to the NDI of the received data, and the received data is The initial transmission of the data is scheduled by the PDCCH scrambled by the C-RNTI (retransmission and initial transmission of the same data can be identified by the same HARQ process identifier), and it is determined that the received data is scheduled by the PDCCH scrambled by the C-RNTI.

2) If the physical layer recognizes that the received data is scheduled by the PDCCH scrambled by the group wireless network temporary identifier G-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

In this embodiment of the present application, optionally, if it is identified that the received data is scheduled by the PDCCH scrambled by the G-RNTI, and the received data is identified as initial transmission data according to the NDI of the received data, it is determined that the received data is Data is scheduled by G-RNTI scrambled PDCCH.

In this embodiment of the present application, optionally, if it is identified that the received data is scheduled by the PDCCH scrambled by the G-RNTI, the received data is identified as retransmission data according to the NDI of the received data, and the received data is The initial transmission data is scheduled by the PDCCH scrambled by G-RNTI (retransmission and initial transmission of the same data can be identified by the same HARQ process identifier), and it is determined that the received data is scheduled by the PDCCH scrambled by G-RNTI.

3) According to the RNTI type, HARQ process identifier and NDI corresponding to the received data, the physical layer identifies that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scheduled by the PDCCH scrambled by the C-RNTI. .

In this embodiment of the present application, optionally, if it is identified that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the received data is identified as retransmission data according to the NDI of the received data, and the received data is The initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI (the retransmission and initial transmission of the same data can be identified by the same HARQ process identifier), and it is determined that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, The retransmission is scheduled by the PDCCH scrambled by the C-RNTI.

In summary, if it is identified that the received data is scheduled by the PDCCH scrambled by the C-RNTI, and the received data is the initial transmission data, it is determined that the received data is scheduled by the PDCCH scrambled by the C-RNTI;

If it is recognized that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the received data is retransmission data, and the initial transmission of the received data is scheduled by the PDCCH scrambled by the C-RNTI, determine the received data PDCCH scheduling scrambled by C-RNTI;

If it is identified that the received data is scheduled by the PDCCH scrambled by the G-RNTI, and the received data is the initial transmission data, determine that the received data is scheduled by the PDCCH scrambled by the G-RNTI;

If it is recognized that the received data is scheduled by the PDCCH scrambled by the G-RNTI, the received data is retransmission data, and the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, determine the received data PDCCH scheduling scrambled by G-RNTI;

If it is recognized that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the received data is retransmission data, and the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, determine the received data The initial transmission is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scheduled by the PDCCH scrambled by the C-RNTI.

In the embodiment of the present application, the above three types of data can be multiplexed with HARQ process identifiers, which is more efficient. For case 3), there will be restrictions, because the UE needs to judge according to the G-RNTI+HARQ process identifier of the initial transmission. The subsequent C-RNTI uses the same HARQ process identifier to schedule the retransmission, which is the PTM corresponding to the initial transmission. The leg data must be in strict accordance with this order and cannot be disrupted. For example, C-RNTI + new HARQ process identifier cannot be used to initially transmit and schedule the data of the PTM leg, because the UE cannot correctly identify the data of a PTM leg at this time. Instead, it will be mistaken for SRB, DRB, or MRB PTP data.

In some embodiments of the present application, the physical layer may indicate the RNTI type corresponding to the data received by the MAC layer, and the MAC layer determines the received data according to the indication of the physical layer and according to the logical channel identifier of the received data The RLC entity to which it belongs.

In some embodiments of the present application, optionally, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, determining the RLC entity to which the received data belongs includes at least one of the following:

11) When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the MAC layer determines the RLC entity or PTP RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI. ;

In this case, the physical layer only needs to instruct the MAC layer that the received data is scheduled by the PDCCH scrambled by the C-RNTI, and the MAC layer can determine the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI. RLC entity or PTP RLC entity.

12) When the MAC layer indicates that the received data is scheduled by the PDCCH scrambled by the G-RNTI and indicates the G-RNTI corresponding to the received data at the physical layer, according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data, Determine the PTM RLC entity to which the received data belongs;

In this case, the physical layer needs to indicate that the data received by the MAC layer is scheduled by the PDCCH scrambled by the G-RNTI, and indicate the G-RNTI to the MAC layer, and the MAC layer determines the reception according to the logical channel identifier corresponding to the G-RNTI. The PTM RLC entity to which the received data belongs.

13) When the MAC layer indicates that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scheduled by the PDCCH scrambled by the C-RNTI and indicates the G-RNTI corresponding to the received data, according to The logical channel identifier corresponding to the G-RNTI corresponding to the received data determines the PTM RLC entity to which the received data belongs.

In this case, the physical layer needs to instruct the MAC layer that the initial transmission of the data received by the MAC layer is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scheduled by the PDCCH scrambled by the C-RNTI, and indicate the G-RNTI to the MAC layer, The MAC layer determines the PTM RLC entity to which the received data belongs according to the logical channel identifier corresponding to the G-RNTI.

21) When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the MAC layer determines the RLC entity or PTP RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI. ;

22) When the physical layer indicates the G-RNTI corresponding to the received data, the MAC layer determines the PTM RLC entity to which the received data belongs according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data.

That is, in the embodiment of the present application, 12) and 13) in the above-mentioned embodiments are combined. In these two cases, the physical layer only needs to indicate the G-RNTI corresponding to the data received by the MAC layer, and the MAC layer can Determine the PTM RLC entity of which MRB of the target multicast service the received data belongs to through the logical channel identifier corresponding to the G-RNTI.

(2) In some embodiments of the present application, optionally, the RLC entity to which the received data belongs is determined according to the HARQ process identifier of the received data.

In the embodiment of the present application, optionally, according to the HARQ process identifier of the received data, determining that the received data belongs to the RLC entity of the target multicast service includes:

The MAC layer identifies at the physical layer that the HARQ process identifier of the received data is a dedicated HARQ process identifier, and determines that the received data belongs to the target multicast service;

The MAC layer determines the RLC entity to which the received data belongs according to the logical channel identifier of the received data.

In this embodiment of the present application, the network side may configure a dedicated HARQ process identifier for the initial transmission of the target multicast service scheduled by the PDCCH scrambled by G-RNTI and the retransmission of the target multicast service scheduled by the PDCCH scrambled by C-RNTI. When the data is identified by a dedicated HARQ process, it is directly determined that the received data belongs to the target multicast service, and then the RLC entity to which it belongs is determined according to the logical channel identification of the received data.

When the initial transmission is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scheduled by the PDCCH scrambled by the C-RNTI, a dedicated HARQ process identifier is configured. For example, two HARQ process identifiers are reserved. The identifier is not allowed to be used in the other two manners, and the reserved two HARQ process identifiers are bound to G-RNTI or TMGI, that is, only this multicast service is allowed to be used.

The biggest advantage of this method is that there is an independent distinction between the initial transmission of PDCCH scrambled by G-RNTI and the retransmission of PDCCH scrambled by C-RNTI. After the UE obtains the HARQ process identifier, it can know the Yes, the initial transmission is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scheduled by the PDCCH scrambled by the C-RNTI, so whether the initial transmission or the retransmission is scheduled by the C-RNTI or the PDCCH scrambled by the G-RNTI, The UE will send the data to the PTM leg corresponding to the G-RNTI or TMGI, no error will occur, and there is no restriction on the order of scheduling.

In the embodiment of this application, the above-mentioned method (1) (multiplexing HARQ process identifier) and method (2) (dedicated HARQ process identifier) can be used at the same time. For example, for relatively important multicast services, method (2) is used to configure a dedicated HARQ process identifier. For other multicast services, the method of multiplexing the HARQ process identifier is adopted.

(3) In some embodiments of the present application, the MAC layer may also determine the RLC entity to which the received data belongs only according to the logical channel identifier of the received data.

Optionally, the MAC layer determines, according to the logical channel identifier of the received data, that the RLC entity to which the received data belongs includes at least one of the following:

If the MAC layer identifies that the logical channel identifier of the received data is the first logical channel identifier configured for the target unicast data, determine that the received data belongs to the RLC entity of the target unicast data;

If the MAC layer identifies that the logical channel identifier of the received data is the second logical channel identifier configured to the PTP RLC entity of the target multicast service, determine that the received data belongs to the PTP RLC entity of the target multicast service;

If the MAC layer identifies that the logical channel identifier of the received data is the third logical channel identifier configured to the PTM RLC entity of the target multicast service, determine that the received data belongs to the PTM RLC entity of the target multicast service;

Wherein, the values of the first logical channel identifier, the second logical channel identifier and the third logical channel identifier do not overlap.

In the embodiment of the present application, different logical channel identifiers are respectively configured for the RLC entity of unicast data, the PTP RLC entity of the target multicast service, and the PTM RLC entity of the target multicast service, so that the MAC layer can distinguish between the logical channel identifiers according to the logical channel identifiers. The type of data without an indication of the physical layer.

In this embodiment of the present application, although the MAC layer does not need an indication from the physical layer, the physical layer can also identify the RNTI type or HARQ process identifier corresponding to the received data.

The value ranges of logical channels of various types of data in the embodiments of the present application will be described below.

Please refer to Table 1. Table 1 shows the value range of the logical channel identifier of the downlink shared channel (DL-SCH).

Table 1 Value range of the logical channel identifier of the downlink shared channel (DL-SCH)

In this embodiment of the present application, the data types may be as follows:

1) The first type of data: unicast data scheduled by PDCCH scrambled by C-RNTI, refers to SRB or DRB data, and its LCID (logical channel identifier) value can be 0-32 in Table 1;

2) The second type of data: MRB PTP leg data corresponding to multicast services scheduled by PDCCH scrambled by C-RNTI, such as MRB1 PTP leg+MRB2 PTP leg of TMGI1, MRB2 PTP leg+MRB3 PTP leg of TMGI2, etc., Since this part of the data is always scheduled by the PDCCH scrambled by the C-RNTI, it can share the LCID space with the first type of data and can be distinguished from each other. 46 parts, and does not overlap with the first type of LCID value.

When 0-32 is not enough, you can start to extend the 1-byte LCID space or extend the 2-byte LCID space. The use of the extended LCID space can be based on the capabilities of the UE, and only the UE that supports the extended capability can perform related configurations;

The logical channel identifiers of the first and second types of data can be configured through dedicated Radio Resource Control (RRC) signaling, and configured for each UE according to the situation. Once the configuration is completed, it can be used until Release or reconfigure.

3) The third type of data: MRB PTM leg data corresponding to multicast services scheduled by PDCCH scrambled by G-RNTI, for example, MRB1 or MRB2 PTM leg of TMGI1 is scheduled by G-RNTI 1, MRB1, MRB2 or MRB3 of TMGI2 PTM leg uses G-RNTI 2 scheduling etc.

In the embodiment in which the MAC layer distinguishes data independently according to the logical channel identifier, the third type of data needs to be different from the logical channel identifiers of the first and second types of data in order to be distinguished.

In the embodiment where the physical layer indicates the G-RNTI corresponding to the data received by the MAC layer, since the third type of data uses different G-RNTIs, they have passed the G-RNTI between each other and the first two types of data. RNTI makes a distinction, so in principle, the same LCID can be reused between MRB PTM legs of different TMGI/G-RNTI and between the first two data types, for example, 1-32 points or 33- points in Table 1 can be used 34 or 35-46 parts, and can overlap with other types of data.

4) The fourth type of data: the MRB PTM leg data corresponding to the multicast service scheduled by the PDCCH scrambled by the C-RNTI, this type is the third type of content in terms of the data content itself, the difference is the use of Different RNTIs are used to schedule, there are two cases:

One is that the physical layer can identify the MRB PTM leg data of a TMGI/G-RNTI scheduled by the PDCCH scrambled by the C-RNTI and instruct the MAC layer, then the values of these MRB PTM leg do not need to have any As an additional consideration, it can be directly in all LCID spaces, such as points 1-32 or 33-34 or 35-46 in Table 1, and can overlap with other types of data;

On the other hand, if the physical layer does not indicate the MAC layer, the MAC layer needs the LCID to distinguish which corresponding RLC entity the decomposed MAC PDU needs to be thrown into. At this time, the LCID value of these MRB PTM legs needs to be followed by the first and The second is strictly differentiated, that is, each can be identified independently, for example, points 1-32 or 33-34 or 35-46 in Table 1 can be used, and cannot overlap with other data. With the independently identifiable LCID configuration, the UE can determine which TMGI MRB PTM leg is from the LCID, so the received data packets can be correctly delivered to the corresponding RLC entity.

In the embodiment of the present application, optionally, before determining the RLC entity to which the received data belongs, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, the method further includes: receiving at least one target multiple configuration information of the multicast service, the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and configuration information of the PTP receiving entity of the target MRB;

The configuration information of the PTM receiving entity includes at least one of the following: the logical channel identifier of the PTM receiving entity, the configuration information of the PTM RLC entity, the G-RNTI used for scheduling the data of the target multicast service, the Indication information of whether the data of the PTM RLC entity is allowed to use the PDCCH scheduling scrambled by the C-RNTI; in the embodiment of the present disclosure, the G-RNTI is for a Temporary Mobile Group Identifier (TMGI) granularity, that is, the G-RNTI and the TMGI are One-to-one correspondence, TMGI is a service identifier, one TMGI can contain multiple MRBs, and one MRB corresponds to one or two RLC entities.

Optionally, the indicated indication information is display indication information. The display indication information can be a 1bit switch.

Optionally, the indication information is implicit indication information, and whether the data of the PTM RLC entity is allowed to use the data scrambled by the C-RNTI is indicated by whether the HARQ process identifier and/or the logical channel identifier can distinguish the following three kinds of data. PDCCH scheduling: Unicast data, PTP RLC entity data, PTM RLC entity data. The unicast data may be unicast Signaling Radio Bearer (SRB) data or unicast Data Radio Bearer (DRB) data. If the HARQ process identifier and/or the logical channel identifier can distinguish the above three kinds of data, the data indicating the PTM RLC entity is allowed to be scheduled using the PDCCH scrambled by the C-RNTI, if the HARQ process identifier and/or the logical channel identifier cannot Distinguishing the above three kinds of data, it indicates that the data of the PTM RLC entity is not allowed to be scheduled using the PDCCH scrambled by the C-RNTI.

The method for receiving a multicast service in this application will be illustrated below with reference to specific embodiments.

First, if the UE is interested in one or more multicast services, it reports the interested TMGI list (list) to the network side in the connected state. The configuration information, for example, includes the following:

1) LCID 1-10 is configured to the UE's unicast RB or reserved for possible unicast RB;

2) The QoS flow (flow) of the TMGI1 service (allocating G-RNTI1) that the UE is interested in is mapped to 3 MRBs, and 3 MRBs have high block error rate requirements, so configure PTP leg and PTM at the same time leg, configure the respective configuration parameters of the 6 RLC entities, assign LCID=35 and PTP leg LCID=11 to the PTM leg of MRB1, assign LCID=36 and PTP leg LCID=12 to the PTM leg of MRB2, and assign LCID to the PTM leg of MRB3 = 37 and PTP leg LCID = 13;

3) The QoS flow of the TMGI2 service that the UE is interested in (allocating G-RNTI2) is mapped to 4 MRBs, and 3 MRBs have higher block error rates and are required to be configured with PTP leg and PTM leg at the same time, and the remaining 1 If each MRB has only PTM leg, the respective configuration parameters of 7 RLC entities also need to be configured. The PTM leg of MRB1 is assigned LCID=35 and the PTP leg LCID=14, the PTM leg of MRB2 is assigned LCID=36 and the PTP leg LCID=15, Assign LCID=37 and PTP leg LCID=16 to the PTM leg of MRB3, assign LCID=38 to the PTM leg of MRB4 and have no corresponding PTP leg;

That is, in addition to unicast data, the UE establishes a total of 13 RLC entities for multicast services.

After the configuration, the UE establishes the relevant L2 receiving entity according to the content of the configuration, and starts to receive data:

1) The UE monitors the scheduling of G-RNTI1 in the discontinuous reception (DRX) pattern of TMGI1. If it receives and decodes correctly, it unpacks the MAC PDU and reads the LCID field in the MAC subheader to determine which one belongs to. A PTM RLC entity, such as the PTM RLC entity of MRB1 corresponding to LCID=35 belonging to TMGI1, is sent to the correct RLC entity for subsequent processing;

2) The UE monitors the scheduling of G-RNTI2 in the DRX pattern of TMGI2. If it receives and decodes correctly, it unpacks the MAC PDU and determines which PTM RLC entity it belongs to by reading the LCID field in the MAC subheader. For example, the PTM RLC entity belonging to MRB1 corresponding to LCID=35 of TMGI1 is sent to the correct RLC entity for subsequent processing.

In the above two cases, although the LCID of PTM is overlapping, since different G-RNTIs have completely distinguished TMGI1 and TMGI2, they can be correctly distinguished.

3) The UE monitors the scheduling of C-RNTI in the unicast DRX pattern. If it receives and decodes correctly, it unpacks the MAC PDU and reads the LCID field in the MAC subheader to determine whether it belongs to unicast RB or TMGI. PTP leg, for example, LCID 1-10 are unicast RBs, LCID 11-13 are the PTP legs corresponding to MRB1-MRB3 of TMGI1, and LCIDs 14-16 are the PTP legs corresponding to MRB1-MRB3 of TMGI2, so the LCID can accurately The corresponding RLC entity is found without error.

4) In the process of monitoring C-RNTI, if the UE receives a certain TMGI in the scheduling of C-RNTI, for example, the retransmission corresponding to the initial transmission of TMGI1, the judgment method is that G-RNTI1 first schedules the HARQ process identifier = After the initial transmission of 3, the UE uses C-RNTI to monitor the retransmission of the same HARQ process ID = 3, then the UE knows that the content of this retransmission is the PTM leg data of TMGI1, and if it is received correctly, it can be judged through the LCID field. It is the PTM leg of which MRB of TMGI1, so it can also be submitted up accurately.

Note: The above various DRX patterns are optional configurations. If no DRX pattern is configured, it means that PDCCH monitoring of related RNTIs is performed in all downlink subframes.

Further, in the above example, the following enhanced configurations and behaviors are also possible:

1) Allocate a dedicated HARQ process ID=1, 2, and/or for TMGI1, or allocate a dedicated HARQ process ID=3, 4 for TMGI2; for UE reception, if the C-RNTI monitors the dedicated HARQ process ID The scheduling of the C-RNTI can determine which TMGI it is, and then further distinguish which leg it is through the LCID field, so the corresponding RLC entity can be found accurately; and the C-RNTI can be either the initial transmission scheduling or the retransmission scheduling, which can be identified.

2) Assign identifiable LCIDs to the PTM legs of TMGI1 and TMGI2. For example, the LCIDs corresponding to MRB1-3 of TMGI1 are 35-37, and the LCIDs corresponding to MRB1-4 of TMGI2 are 38-41, so that different LCIDs can be distinguished by LCID. RLC entity.

Further, since the UE group where UE1 is located supports extended LCIDs, the PTM legs of TMGI1 and TMGI2 can be assigned identifiable LCIDs within the extended LCID range. For example, the LCIDs corresponding to MRB1-3 of TMGI1 are 335-337. The LCIDs corresponding to MRB1-4 of TMGI2 are 338-341, so that different RLC entities can also be distinguished by LCIDs.

For the receiving UE, since both of the above two methods have an identifiable LCID, the UE can find the corresponding RLC entity through the unique LCID.

In some of the above-mentioned embodiments, the physical layer can determine that the PDCCH scrambled by the C-RNTI schedules the data of the PTM leg of a certain TMGI, the physical layer can notify the MAC layer of this information through inter-layer interaction, and the MAC layer then passes LCID can find the PTM RLC entity corresponding to the correct TMGI.

In some of the above-mentioned embodiments, if the MAC layer is independently distinguished by LCID, it is equivalent to that the physical layer does not need to judge that the PDCCH scrambled by the C-RNTI schedules the PTM leg data of the TMGI, and the physical layer receives the data normally and submits it to the MAC. layer, the MAC layer finds the PTM RLC entity corresponding to the correct TMGI through the LCID.

In other above-mentioned embodiments, the physical layer can also determine that the PDCCH scrambled by the C-RNTI schedules the data of the PTM leg of a certain TMGI, but does not notify the MAC layer, and the MAC layer directly finds the correct TMGI through the LCID. The corresponding PTM RLC entity.

Referring to FIG. 4 , an embodiment of the present application further provides a method for configuring a multicast service, which is performed by a network side device, including:

Step 41: Send configuration information of at least one target multicast service to the terminal, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and The configuration information of the PTP receiving entity;

Optionally, the indicated indication information is display indication information;

or,

The indication information is implicit indication information, whether the data of the PTM RLC entity is allowed to use the PDCCH scheduling scrambled by the C-RNTI is indicated by whether the HARQ process identifier and/or the logical channel identifier can distinguish the following three types of data: single broadcast data, PTP RLC entity data, PTM RLC entity data.

It should be noted that, in the method for receiving a multicast service provided by the embodiments of the present application, the execution subject may be a device for receiving a multicast service, or, in the device for receiving a multicast service, a method for executing a method for receiving a multicast service is executed. control module. In the embodiments of the present application, a method for receiving a multicast service performed by a device for receiving a multicast service is used as an example to describe the device for receiving a multicast service provided by the embodiments of the present application.

Referring to FIG. 5 , an embodiment of the present application further provides an apparatus 50 for receiving a multicast service, including:

A determination module 51 is used to determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, where the RLC entity is an RLC entity of unicast data, The PTP RLC entity of the target multicast service or the PTM RLC entity of the target multicast service.

Optionally, the determining module is configured to determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and NDI corresponding to the received data.

Optionally, the determining module includes:

The first determination sub-module is used to identify the PDCCH scheduling that the received data is scrambled by the cell wireless network temporary identifier C-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

The second determination sub-module is used to identify the PDCCH scheduling that the received data is scrambled by the group wireless network temporary identifier G-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

The third determination sub-module is used to identify, according to the RNTI type, HARQ process identifier and NDI corresponding to the received data, that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scrambled by the C-RNTI. scrambled PDCCH scheduling.

Optionally, the determining module includes:

The fourth determination submodule is used to determine the RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI when the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI or PTP RLC entity;

The fifth determination sub-module is used for when the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the G-RNTI and indicates the G-RNTI corresponding to the received data, according to the corresponding G-RNTI of the received data. Logical channel identifier to determine the PTM RLC entity to which the received data belongs;

The sixth determination sub-module is used to indicate at the physical layer that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, the retransmission is scheduled by the PDCCH scrambled by the C-RNTI, and the G-RNTI corresponding to the received data is indicated. During RNTI, the PTM RLC entity to which the received data belongs is determined according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data.

Optionally, the determining module includes:

The seventh determination sub-module is used to determine the RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI when the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI or PTP RLC entity;

The eighth determination submodule is used to determine the PTM RLC entity to which the received data belongs according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data when the physical layer indicates the G-RNTI corresponding to the received data.

Optionally, the determining module includes:

The ninth determination submodule is configured to determine, according to the HARQ process identifier of the received data, that the received data belongs to the RLC entity of the target multicast service.

Optionally, the ninth determination submodule is used to identify at the physical layer that the HARQ process identifier of the received data is a dedicated HARQ process identifier, and determine that the received data belongs to the target multicast service; according to the received data The logical channel identifier to determine the RLC entity to which the received data belongs.

Optionally, the determining module is configured to determine, according to the logical channel identifier of the received data, the RLC entity to which the received data belongs, where the RLC entity is an RLC entity of unicast data and a PTP of a target multicast service. RLC entity or PTM RLC entity of the target multicast service.

Optionally, the determining module includes:

The tenth determination submodule is used to determine that the received data belongs to the RLC entity of the target unicast data if the MAC layer identifies that the logical channel identifier of the received data is the first logical channel identifier configured to the target unicast data;

The eleventh determination sub-module is used to determine that the received data belongs to the target multicast service if the MAC layer identifies that the logical channel identifier of the received data is the second logical channel identifier of the PTP RLC entity configured for the target multicast service. PTP RLC entity for broadcasting service;

The twelfth determination sub-module is used to determine that the received data belongs to the target multicast service if the MAC layer identifies that the logical channel identifier of the received data is the third logical channel identifier of the PTM RLC entity configured for the target multicast service. PTM RLC entity for broadcasting service;

Optionally, the device further includes:

A receiving module, configured to receive configuration information of at least one target multicast service, where the configuration information includes at least one of the following: configuration information of a PTM receiving entity of a target MRB of the target multicast service, and, The configuration information of the PTP receiving entity;

The apparatus for receiving the multicast service in this embodiment of the present application may be an apparatus, or may be a component, an integrated circuit, or a chip in a terminal. The device may be a mobile terminal or a non-mobile terminal. Exemplarily, the mobile terminal may include, but is not limited to, the types of terminals 11 listed above, and the non-mobile terminal may be a server, a network attached storage (NAS), a personal computer (personal computer, PC), a television ( television, TV), teller machine, or self-service machine, etc., which are not specifically limited in the embodiments of the present application.

The apparatus for receiving the multicast service in the embodiment of the present application may be an apparatus having an operating system. The operating system may be an Android (Android) operating system, an ios operating system, or other possible operating systems, which are not specifically limited in the embodiments of the present application.

The apparatus for receiving a multicast service provided by the embodiment of the present application can implement each process implemented by the method embodiment in FIG. 3 , and achieve the same technical effect. To avoid repetition, details are not described here.

It should be noted that, in the configuration method for multicast services provided by the embodiments of the present application, the execution subject may be a configuration device for multicast services, or, in the configuration device for multicast services, the configuration method for executing multicast services control module. In the embodiment of the present application, the device for configuring a multicast service provided by the embodiment of the present application is described by taking a method for configuring a multicast service performed by a device for configuring a multicast service as an example.

Referring to FIG. 6 , an embodiment of the present application further provides an apparatus 60 for configuring a multicast service, including:

A sending module 61, configured to send configuration information of at least one target multicast service to the terminal, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and the Configuration information of the PTP receiving entity of the target MRB;

or,

As shown in FIG. 7 , an embodiment of the present application further provides a communication device 70, including a processor 71, a memory 72, a program or instruction stored in the memory 72 and executable on the processor 71, for example, the communication When the device 70 is a terminal, when the program or instruction is executed by the processor 71, each process of the above-mentioned embodiment of the method for receiving a multicast service is implemented, and the same technical effect can be achieved. When the communication device 70 is a network-side device, when the program or instruction is executed by the processor 71, each process of the above-mentioned embodiment of the multicast service configuration method can be realized, and the same technical effect can be achieved. To avoid repetition, details are not repeated here. .

FIG. 8 is a schematic diagram of a hardware structure of a terminal implementing an embodiment of the present application. The terminal 80 includes but is not limited to: a radio frequency unit 81, a network module 82, an audio output unit 83, an input unit 84, a sensor 85, a display unit 86, a user input unit 87, an interface unit 88, a memory 89, a processor 810 and other components .

Those skilled in the art can understand that the terminal 80 may also include a power source (such as a battery) for supplying power to various components, and the power source may be logically connected to the processor 810 through a power management system, so as to manage charging, discharging, and power consumption through the power management system management and other functions. The terminal structure shown in FIG. 8 does not constitute a limitation on the terminal, and the terminal may include more or less components than shown, or combine some components, or arrange different components, which will not be repeated here.

It should be understood that, in this embodiment of the present application, the input unit 84 may include a graphics processor (Graphics Processing Unit, GPU) 841 and a microphone 842. Such as camera) to obtain still pictures or video image data for processing. The display unit 86 may include a display panel 861, which may be configured in the form of a liquid crystal display, an organic light emitting diode, or the like. The user input unit 87 includes a touch panel 881 and other input devices 882 . The touch panel 881 is also called a touch screen. The touch panel 881 may include two parts, a touch detection device and a touch controller. Other input devices 882 may include, but are not limited to, physical keyboards, function keys (such as volume control keys, switch keys, etc.), trackballs, mice, and joysticks, which are not described herein again.

In the embodiment of the present application, the radio frequency unit 81 receives the downlink data from the network side device, and then processes it to the processor 810; in addition, sends the uplink data to the network side device. Typically, the radio frequency unit 81 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like.

Memory 89 may be used to store software programs or instructions as well as various data. The memory 89 may mainly include a storage program or instruction area and a storage data area, wherein the storage program or instruction area may store an operating system, an application program or instruction required for at least one function (such as a sound playback function, an image playback function, etc.) and the like. In addition, the memory 89 may include a high-speed random access memory, and may also include a non-volatile memory, wherein the non-volatile memory may be a read-only memory (Read-Only Memory, ROM), a programmable read-only memory (Programmable ROM) , PROM), erasable programmable read-only memory (Erasable PROM, EPROM), electrically erasable programmable read-only memory (Electrically EPROM, EEPROM) or flash memory. For example at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device.

The processor 810 may include one or more processing units; optionally, the processor 810 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, application programs or instructions, etc., Modem processors mainly deal with wireless communications, such as baseband processors. It can be understood that, the above-mentioned modulation and demodulation processor may not be integrated into the processor 810.

The processor 810 is configured to determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, and the RLC entity is an RLC of unicast data entity, the PTP RLC entity of the target multicast service, or the PTM RLC entity of the target multicast service.

Optionally, the processor 810 is configured to determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and NDI corresponding to the received data.

Optionally, the processor 810 is configured to execute at least one of the following:

The physical layer recognizes that the received data is scheduled by the PDCCH scrambled by the cell wireless network temporary identifier C-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

The physical layer recognizes that the received data is scheduled by the PDCCH scrambled by the group wireless network temporary identifier G-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

According to the RNTI type, HARQ process identifier and NDI corresponding to the received data, the physical layer identifies that the initial transmission of the received data is scheduled by PDCCH scrambled by G-RNTI, and the retransmission is scheduled by PDCCH scrambled by C-RNTI.

When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the MAC layer determines the RLC entity or PTP RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI;

When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the G-RNTI and indicates the G-RNTI corresponding to the received data, the MAC layer determines the received data according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data. The PTM RLC entity to which the received data belongs;

When the physical layer indicates that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, the retransmission is scheduled by the PDCCH scrambled by the C-RNTI and indicates the G-RNTI corresponding to the received data, according to the received data. The logical channel identifier corresponding to the G-RNTI corresponding to the received data determines the PTM RLC entity to which the received data belongs.

When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the RLC entity or the PTP RLC entity of the unicast data to which the received data belongs is determined according to the logical channel identifier corresponding to the C-RNTI;

When the physical layer indicates the G-RNTI corresponding to the received data, the MAC layer determines the PTM RLC entity to which the received data belongs according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data.

Optionally, the processor 810 is configured to determine, according to the HARQ process identifier of the received data, that the received data belongs to the RLC entity of the target multicast service.

Optionally, the processor 810 is used to identify the HARQ process identifier of the received data as a dedicated HARQ process identifier at the physical layer, and determine that the received data belongs to the target multicast service; according to the logical channel identifier of the received data , to determine the RLC entity to which the received data belongs.

Optionally, the processor 810 is configured to determine, according to the logical channel identifier of the received data, the RLC entity to which the received data belongs.

Optionally, the radio frequency unit 81 is configured to receive configuration information of at least one target multicast service, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and, the configuration information of the PTP receiving entity of the target MRB;

or,

The embodiment of the present application also provides a network side device. As shown in FIG. 9 , the network device 90 includes: an antenna 91 , a radio frequency device 92 , and a baseband device 93 . The antenna 91 is connected to the radio frequency device 92 . In the uplink direction, the radio frequency device 92 receives information through the antenna 91, and sends the received information to the baseband device 93 for processing. In the downlink direction, the baseband device 93 processes the information to be sent and sends it to the radio frequency device 92 , and the radio frequency device 92 processes the received information and sends it out through the antenna 91 .

The above-mentioned frequency band processing apparatus may be located in the baseband apparatus 93 , and the method performed by the network side device in the above embodiments may be implemented in the baseband apparatus 93 . The baseband apparatus 93 includes a processor 94 and a memory 95 .

The baseband device 93 may include, for example, at least one baseband board on which a plurality of chips are arranged. As shown in FIG. 9 , one of the chips is, for example, the processor 94 , which is connected to the memory 95 to call the program in the memory 95 and execute it. The network devices shown in the above method embodiments operate.

The baseband device 93 may further include a network interface 96 for exchanging information with the radio frequency device 92, and the interface is, for example, a common public radio interface (CPRI for short).

Specifically, the network-side device in the embodiment of the present application further includes: an instruction or program stored in the memory 95 and executable on the processor 94, and the processor 94 invokes the instruction or program in the memory 95 to execute each module shown in FIG. 6 . The implementation method and achieve the same technical effect, in order to avoid repetition, it is not repeated here.

An embodiment of the present application further provides a readable storage medium, where a program or an instruction is stored on the readable storage medium, and when the program or instruction is executed by a processor, the above-mentioned method for receiving a multicast service or a method for configuring a multicast service is implemented. Each process of the embodiment can achieve the same technical effect, and to avoid repetition, it will not be repeated here.

Wherein, the processor is the processor in the terminal described in the foregoing embodiment. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk or an optical disk, and the like.

An embodiment of the present application further provides a chip, where the chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is used for running network-side device programs or instructions to implement the above multicast service Each process of the embodiment of the receiving method or the configuration method of the multicast service can achieve the same technical effect, and to avoid repetition, it will not be repeated here.

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

An embodiment of the present application further provides a program product, the program product is stored in a non-volatile storage medium, and the program product is executed by at least one processor to implement the above-mentioned method for receiving a multicast service or a method for receiving a multicast service. The various processes of the configuration method embodiments can achieve the same technical effect, and are not repeated here to avoid repetition.

It should be noted that, herein, the terms "comprising", "comprising" or any other variation thereof are intended to encompass non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements, It also includes other elements not expressly listed or inherent to such a process, method, article or apparatus. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in a process, method, article or apparatus that includes the element. Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of the present application is not limited to performing the functions in the order shown or discussed, but may also include performing the functions in a substantially simultaneous manner or in the reverse order depending on the functions involved. To perform functions, for example, the described methods may be performed in an order different from that described, and various steps may also be added, omitted, or combined. Additionally, features described with reference to some examples may be combined in other examples.

From the description of the above embodiments, those skilled in the art can clearly understand that the method of the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is better implementation. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product in essence or in a part that contributes to the prior art, and the computer software product is stored in a storage medium (such as ROM/RAM, magnetic disk, CD-ROM), including several instructions to make a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) execute the methods described in the various embodiments of this application.

The embodiments of the present application have been described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific embodiments, which are merely illustrative rather than restrictive. Under the inspiration of this application, without departing from the scope of protection of the purpose of this application and the claims, many forms can be made, which all fall within the protection of this application.

Claims

A method for receiving a multicast service, executed by a terminal, includes:

Determine the radio link layer control protocol RLC entity to which the received data belongs, according to the wireless network temporary identifier RNTI type, hybrid automatic repeat request HARQ process identifier and/or logical channel identifier corresponding to the received data. The entities are RLC entities for unicast data, point-to-point PTP RLC entities for target multicast services, or point-to-multipoint PTM RLC entities for target multicast services.
The method according to claim 1, wherein, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, determining the RLC entity to which the received data belongs comprises:

The RLC entity to which the received data belongs is determined according to the RNTI type, the HARQ process identifier and the new data indicator NDI corresponding to the received data.
The method according to claim 2, wherein, according to the RNTI type, HARQ process identifier and NDI corresponding to the received data, determining the RLC entity to which the received data belongs includes at least one of the following:

The physical layer recognizes that the received data is scheduled by the PDCCH scrambled by the cell wireless network temporary identifier C-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

The physical layer recognizes that the received data is scheduled by the PDCCH scrambled by the group wireless network temporary identifier G-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

According to the RNTI type, HARQ process identifier and NDI corresponding to the received data, the physical layer identifies that the initial transmission of the received data is scheduled by PDCCH scrambled by G-RNTI, and the retransmission is scheduled by PDCCH scrambled by C-RNTI.
The method according to claim 3, wherein, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, determining the RLC entity to which the received data belongs includes at least one of the following:

When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the MAC layer determines the RLC entity or PTP RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI;

When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the G-RNTI and indicates the G-RNTI corresponding to the received data, the MAC layer determines the received data according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data. The PTM RLC entity to which the received data belongs;

When the physical layer indicates that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, the retransmission is scheduled by the PDCCH scrambled by the C-RNTI and indicates the G-RNTI corresponding to the received data, according to the received data. The logical channel identifier corresponding to the G-RNTI corresponding to the received data determines the PTM RLC entity to which the received data belongs.
The method according to claim 3, wherein, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, determining the RLC entity to which the received data belongs includes at least one of the following:

When the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI, the MAC layer determines the RLC entity or PTP RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI;

When the physical layer indicates the G-RNTI corresponding to the received data, the MAC layer determines the PTM RLC entity to which the received data belongs according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data.
The method according to claim 1, wherein, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, determining the RLC entity to which the received data belongs comprises:

According to the HARQ process identifier of the received data, it is determined that the received data belongs to the RLC entity of the target multicast service.
The method according to claim 6, wherein, according to the HARQ process identifier of the received data, determining that the received data belongs to the RLC entity of the target multicast service comprises:

The MAC layer identifies at the physical layer that the HARQ process identifier of the received data is a dedicated HARQ process identifier, and determines that the received data belongs to the target multicast service;

The MAC layer determines the RLC entity to which the received data belongs according to the logical channel identifier of the received data.
The method according to claim 1, 3 or 6, wherein, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, determining the RLC entity to which the received data belongs comprises:

The MAC layer determines the RLC entity to which the received data belongs according to the logical channel identifier of the received data.
The method according to claim 8, wherein, according to the logical channel identifier of the received data, the MAC layer determines that the RLC entity to which the received data belongs includes at least one of the following:

If the MAC layer identifies that the logical channel identifier of the received data is the first logical channel identifier configured for the target unicast data, determine that the received data belongs to the RLC entity of the target unicast data;

If the MAC layer identifies that the logical channel identifier of the received data is the second logical channel identifier configured to the PTP RLC entity of the target multicast service, determine that the received data belongs to the PTP RLC entity of the target multicast service;

If the MAC layer identifies that the logical channel identifier of the received data is the third logical channel identifier configured to the PTM RLC entity of the target multicast service, determine that the received data belongs to the PTM RLC entity of the target multicast service;

Wherein, the values of the first logical channel identifier, the second logical channel identifier and the third logical channel identifier do not overlap.
The method according to claim 1, wherein, before determining the RLC entity to which the received data belongs, according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, further comprising:

Receive configuration information of at least one target multicast service, where the configuration information includes at least one of the following: configuration information of a PTM receiving entity of a target MRB of the target multicast service, and configuration of a PTP receiving entity of the target MRB information;

The configuration information of the PTM receiving entity includes at least one of the following: the logical channel identifier of the PTM receiving entity, the configuration information of the PTM RLC entity, the G-RNTI used for scheduling the data of the target multicast service, the Indication information of whether the data of the PTM RLC entity is allowed to use the PDCCH scrambled by the C-RNTI;

The configuration information of the PTP receiving entity includes at least one of the following items: the configuration information of the PTP RLC entity and the logical channel identifier of the PTP receiving entity.
The method of claim 10, wherein,

The indication information shown is display indication information;

or

The indication information is implicit indication information, whether the data of the PTM RLC entity is allowed to use the PDCCH scheduling scrambled by the C-RNTI is indicated by whether the HARQ process identifier and/or the logical channel identifier can distinguish the following three types of data: single broadcast data, PTP RLC entity data, PTM RLC entity data.
A method for configuring a multicast service, performed by a network side device, includes:

Send configuration information of at least one target multicast service to the terminal, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and, the PTP receiving entity of the target MRB configuration information;

The configuration information of the PTM receiving entity includes at least one of the following: the logical channel identifier of the PTM receiving entity, the configuration information of the PTM RLC entity, the G-RNTI used for scheduling the data of the target multicast service, the Indication information of whether the data of the PTM RLC entity is allowed to use the PDCCH scrambled by the C-RNTI;

The configuration information of the PTP receiving entity includes at least one of the following items: the configuration information of the PTP RLC entity and the logical channel identifier of the PTP receiving entity.
The method of claim 12, wherein,

The indication information shown is display indication information;

or

The indication information is implicit indication information, whether the data of the PTM RLC entity is allowed to use the PDCCH scheduling scrambled by the C-RNTI is indicated by whether the HARQ process identifier and/or the logical channel identifier can distinguish the following three types of data: single broadcast data, PTP RLC entity data, PTM RLC entity data.
A device for receiving multicast services, comprising:

A determination module for determining the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and/or logical channel identifier corresponding to the received data, where the RLC entity is an RLC entity of unicast data, a target The PTP RLC entity of the multicast service or the PTM RLC entity of the target multicast service.
The apparatus according to claim 14, wherein the determining module is configured to determine the RLC entity to which the received data belongs according to the RNTI type, HARQ process identifier and NDI corresponding to the received data.
The apparatus of claim 15, wherein the determining module comprises:

The first determination sub-module is used to identify the PDCCH scheduling that the received data is scrambled by the cell wireless network temporary identifier C-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

The second determination sub-module is used to identify the PDCCH scheduling that the received data is scrambled by the group wireless network temporary identifier G-RNTI according to the RNTI type, HARQ process identifier and NDI corresponding to the received data;

The third determination sub-module is used to identify, according to the RNTI type, HARQ process identifier and NDI corresponding to the received data, that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, and the retransmission is scrambled by the C-RNTI. scrambled PDCCH scheduling.
The apparatus of claim 16, wherein the determining module comprises:

The fourth determination sub-module is used to determine the RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI when the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI or PTP RLC entity;

The fifth determination sub-module is used for when the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the G-RNTI and indicates the G-RNTI corresponding to the received data, according to the corresponding G-RNTI of the received data. Logical channel identifier to determine the PTM RLC entity to which the received data belongs;

The sixth determination sub-module is used to indicate at the physical layer that the initial transmission of the received data is scheduled by the PDCCH scrambled by the G-RNTI, the retransmission is scheduled by the PDCCH scrambled by the C-RNTI, and the G-RNTI corresponding to the received data is indicated. During RNTI, the PTM RLC entity to which the received data belongs is determined according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data.
The apparatus of claim 16, wherein the determining module comprises:

The seventh determination sub-module is used to determine the RLC entity of the unicast data to which the received data belongs according to the logical channel identifier corresponding to the C-RNTI when the physical layer indicates that the received data is scheduled by the PDCCH scrambled by the C-RNTI or PTP RLC entity;

The eighth determination submodule is used to determine the PTM RLC entity to which the received data belongs according to the logical channel identifier corresponding to the G-RNTI corresponding to the received data when the physical layer indicates the G-RNTI corresponding to the received data.
The apparatus of claim 14, wherein the determining module comprises:

The ninth determination submodule is configured to determine, according to the HARQ process identifier of the received data, that the received data belongs to the RLC entity of the target multicast service.
The apparatus according to claim 19, wherein the ninth determination sub-module is used to identify the HARQ process identifier of the received data as a dedicated HARQ process identifier at the physical layer, and determine that the received data belongs to the target multicast Service; according to the logical channel identifier of the received data, determine the RLC entity to which the received data belongs.
The apparatus according to claim 14 or 16 or 19, wherein the determining module is configured to determine the RLC entity to which the received data belongs according to a logical channel identifier of the received data.
The apparatus of claim 21, wherein the determining module comprises:

The tenth determination submodule is used to determine that the received data belongs to the RLC entity of the target unicast data if the MAC layer identifies that the logical channel identifier of the received data is the first logical channel identifier configured to the target unicast data;

The eleventh determination sub-module is used to determine that the received data belongs to the target multicast service if the MAC layer identifies that the logical channel identifier of the received data is the second logical channel identifier of the PTP RLC entity configured for the target multicast service. PTP RLC entity for broadcasting service;

The twelfth determination sub-module is used to determine that the received data belongs to the target multicast service if the MAC layer identifies that the logical channel identifier of the received data is the third logical channel identifier of the PTM RLC entity configured for the target multicast service. PTM RLC entity for broadcasting service;

Wherein, the values of the first logical channel identifier, the second logical channel identifier and the third logical channel identifier do not overlap.
The apparatus of claim 14, further comprising:

A receiving module, configured to receive configuration information of at least one target multicast service, where the configuration information includes at least one of the following: configuration information of a PTM receiving entity of a target MRB of the target multicast service, and, The configuration information of the PTP receiving entity;

The configuration information of the PTM receiving entity includes at least one of the following: the logical channel identifier of the PTM receiving entity, the configuration information of the PTM RLC entity, the G-RNTI used for scheduling the data of the target multicast service, the Indication information of whether the data of the PTM RLC entity is allowed to use the PDCCH scrambled by the C-RNTI;

The configuration information of the PTP receiving entity includes at least one of the following items: the configuration information of the PTP RLC entity and the logical channel identifier of the PTP receiving entity.
A device for configuring multicast services, comprising:

A sending module, configured to send configuration information of at least one target multicast service to the terminal, where the configuration information includes at least one of the following: configuration information of the PTM receiving entity of the target MRB of the target multicast service, and, the target Configuration information of the PTP receiving entity of the MRB;

The configuration information of the PTM receiving entity includes at least one of the following: the logical channel identifier of the PTM receiving entity, the configuration information of the PTM RLC entity, the G-RNTI used for scheduling the data of the target multicast service, the Indication information of whether the data of the PTM RLC entity is allowed to use the PDCCH scrambled by the C-RNTI;

The configuration information of the PTP receiving entity includes at least one of the following items: the configuration information of the PTP RLC entity and the logical channel identifier of the PTP receiving entity.
A terminal, comprising a processor, a memory, and a program or instruction stored on the memory and executable on the processor, wherein the program or instruction is executed by the processor to implement the procedures as claimed in claims 1 to 1. 11. The steps of any one of the methods for receiving a multicast service.
A network-side device, comprising a processor, a memory, and a program or instruction stored on the memory and running on the processor, wherein the program or instruction is executed by the processor to achieve as claimed in the claims Steps of the method for configuring a multicast service described in 12 or 13.
A readable storage medium, wherein a program or an instruction is stored on the readable storage medium, and when the program or instruction is executed by a processor, the method for receiving a multicast service according to any one of claims 1 to 11 is implemented , or the steps of implementing the method for configuring a multicast service according to claim 12 or 13 .
A chip, comprising a processor and a communication interface, wherein the communication interface is coupled with the processor, and the processor is used for running a program or an instruction to implement the multicast service according to any one of claims 1 to 11 the receiving method, or the steps of implementing the method for configuring a multicast service according to claim 12 or 13.
A computer program product, wherein the computer program product is stored in a non-volatile storage medium, the computer program product being executed by at least one processor to implement the multi-function according to any one of claims 1 to 11. the method for receiving the multicast service, or the steps of implementing the method for configuring the multicast service according to claim 12 or 13.