Inactive state multicast service transmission and reception method and apparatus

Abstract

The application discloses a non-activated multicast service sending and receiving method and device. The non-activated multicast service sending method comprises the following steps: sending first indication information and / or second indication information, wherein the first indication information indicates that multicast service is received in a non-activated state, and the second indication information indicates a condition required to be met for receiving multicast service in the non-activated state; and sending data of the multicast service. The technical scheme can realize the judgment of the non-activated transmission of the multicast service.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method and apparatus for transmitting and receiving inactive multicast services. Background Technology

[0002] The New Radio (NR) system will introduce Multimedia Broadcast Multicast Service (MBMS). In the current protocol version, for multicast services, due to their high quality-of-service requirements, user equipment (UE) needs to receive multicast services in connected mode. For connected UEs, they need to perform network-configured measurement tasks and report measurement reports when the reporting conditions are met. The network also configures UEs to perform physical layer (Layer 1) measurements and report channel state information. Therefore, connected UEs need to maintain significant signaling overhead, which is detrimental to both the UE's power consumption and the network load.

[0003] To reduce signaling overhead on terminal devices and lower network load, it is advisable to support multicast service transmission in the inactive state.

[0004] However, if it is necessary to receive multicast services in an inactive state, the first problem to be solved is how the terminal device determines whether it can receive multicast services in an inactive state. Summary of the Invention

[0005] The technical problem solved by this invention is how to determine the transmission of multicast services in an inactive state.

[0006] To address the aforementioned technical problems, in a first aspect, a method for transmitting inactive multicast services is provided. The method includes: transmitting first indication information and / or second indication information, wherein the first indication information indicates receiving multicast services in an inactive state, and the second indication information indicates the conditions that need to be met to receive multicast services in an inactive state; and transmitting multicast service data.

[0007] Optionally, the first indication information corresponds to the identifier of at least one multicast service, and the second indication information corresponds to the identifier of at least one multicast service.

[0008] Optionally, sending the first indication information includes: sending the first indication information carried in an RRC release signaling message.

[0009] Optionally, sending the second indication information includes: sending the second indication information carried in RRC signaling.

[0010] Optionally, sending the first indication information and / or the second indication information includes: for a terminal device that receives the multicast service and is in a connected state, if there is no multicast service or unicast service within a time period of a preset duration, then sending the first indication information or the second indication information.

[0011] Optionally, sending the first indication information includes: sending the first indication information carried in a paging message.

[0012] Optionally, sending the first indication information includes: for a terminal device in an inactive state, if there is data for the multicast service that needs to be transmitted, the first indication information is carried in a paging message and sent out, wherein the paging message also includes the identifier of the multicast service.

[0013] Optionally, the second indication information includes one or more of the following: being in a serving cell transmitting the multicast service; being in one or more beams of the serving cell, and the signal quality of at least one beam reaching a preset threshold; being in the serving cell, and the uplink advance timer has not timed out, and one or more configured authorizations are valid; being in the serving cell, and the uplink advance timer has not timed out, and the serving cell is configured to transmit uplink resources for HARQ feedback.

[0014] Secondly, a method for receiving inactive multicast services is provided. The method includes: receiving first indication information and / or second indication information, wherein the first indication information indicates receiving multicast services in an inactive state, and the second indication information indicates the conditions that need to be met to receive multicast services in an inactive state; and receiving multicast service data in an inactive state.

[0015] Optionally, upon receiving the first indication information, the conditions that need to be met for receiving multicast services in the inactive state are preset by the protocol.

[0016] Optionally, receiving the first indication information includes: receiving RRC release signaling in an active state, wherein the RRC release signaling includes the first indication information.

[0017] Optionally, receiving the second indication information includes: receiving RRC signaling in an active state, wherein the RRC signaling includes the second indication information.

[0018] Optionally, after receiving the first indication information and / or the second indication information, the process includes: entering an inactive state; and saving the multicast service reception configuration obtained in the active state.

[0019] Optionally, receiving the first indication information includes: receiving a paging in an inactive state, wherein the paging includes the first indication information.

[0020] Optionally, receiving multicast service data in the inactive state includes: if the first indication information is received, then receiving the multicast service data after receiving paging or update information indicating the data transmission of the multicast service; if the second indication information is received, then determining whether the condition indicated by the second indication information is met, and receiving the multicast service data after the condition is met and paging or update information indicating the data transmission of the multicast service is received; if only the first indication information is received, and the conditions to be met for receiving multicast services in the inactive state are preset by the protocol, determining whether the conditions are met, and receiving the multicast service data after the conditions are met and paging or update information indicating the data transmission of the multicast service is received.

[0021] Thirdly, an inactive multicast service transmission device is provided, comprising: an indication information transmission module for transmitting first indication information and / or second indication information, wherein the first indication information indicates receiving multicast services in an inactive state, and the second indication information indicates the conditions that need to be met to receive multicast services in an inactive state; and a data transmission module for transmitting multicast service data.

[0022] Fourthly, an inactive multicast service receiving device is provided, comprising: an indication information receiving module for receiving first indication information and / or second indication information, wherein the first indication information indicates receiving multicast service in an inactive state, and the second indication information indicates conditions that need to be met to receive multicast service in an inactive state; and a data receiving module for receiving multicast service data in an inactive state.

[0023] Fifthly, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processor, performs the steps of the inactive multicast service transmission method, or the steps of the inactive multicast service reception method, or the steps of the inactive multicast service transmission method.

[0024] In a sixth aspect, a network device is provided, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the steps of the inactive multicast service transmission method or the steps of the inactive multicast service transmission method when running the computer program.

[0025] In a seventh aspect, a terminal device is provided, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the steps of the inactive multicast service reception method or the steps of the inactive multicast service transmission method when running the computer program.

[0026] Eighthly, a method for transmitting inactive multicast services is provided, the method comprising: receiving a preamble sent by a terminal device in an inactive state; determining information of a first beam based on the timing of receiving the preamble; and transmitting multicast service data on the first beam.

[0027] Optionally, before transmitting the multicast service data on the first beam, the method further includes: determining the multicast service that the terminal device is interested in.

[0028] Optionally, determining the multicast service that the terminal device is interested in includes: determining the multicast service that the terminal device is interested in based on the preamble.

[0029] Optionally, each multicast service is configured with a dedicated preamble.

[0030] Optionally, determining the multicast service that the terminal device is interested in includes receiving message 3, wherein message 3 includes an identifier of the multicast service that the terminal device is interested in.

[0031] Optionally, before receiving the preamble sent by the terminal device using the first beam it is currently in, the method further includes: instructing the terminal device on information about the beam used by the multicast service to be transmitted, so that the terminal device can send the preamble when it discovers that its beam is different from the beam used to transmit the multicast service.

[0032] In a ninth aspect, a method for transmitting inactive multicast services is provided. The method includes: when in an inactive state, transmitting a preamble according to the currently located first beam, wherein the timing of receiving the preamble can be used to determine the information of the first beam; and receiving multicast service data on the first beam.

[0033] Optionally, after sending the preamble according to the current first beam, the method further includes: sending the service identifier of the multicast service.

[0034] Optionally, the service identifier includes: sending message 3, wherein message 3 includes the service identifier.

[0035] Optionally, each multicast service is configured with a dedicated preamble.

[0036] Optionally, the step of sending a preamble based on the current first beam includes: sending message 1 based on the first beam, wherein message 1 includes the preamble.

[0037] In a tenth aspect, an inactive multicast service transmission device is provided, comprising: a preamble receiving module for receiving a preamble sent by a terminal device in an inactive state; a beam information determining module for determining information of a first beam based on the timing of receiving the preamble; and a transmitting module for transmitting multicast service data on the first beam.

[0038] Eleventhly, an inactive multicast service transmission device is provided, comprising: a preamble transmission module, used to transmit a preamble according to the currently located first beam when in an inactive state, wherein the timing of receiving the preamble can be used to determine the information of the first beam; and a receiving module, used to receive multicast service data on the first beam.

[0039] Compared with the prior art, the technical solution of the embodiments of the present invention has the following beneficial effects:

[0040] In this invention, the network device can send a first indication message to the terminal device, which, according to the indication of the first indication message, can receive multicast service data in an inactive state; or, the network device can send a second indication message to the terminal device, which, according to the conditions indicated by the second indication message, determines whether it can receive multicast service data in an inactive state. By setting the first and second indication messages, this invention enables the terminal device to explicitly receive multicast service data in an inactive state, thus achieving inactive multicast service transmission, thereby reducing the signaling overhead of the terminal device and reducing network load.

[0041] Furthermore, for a terminal device receiving the multicast service and in a connected state, if there are no multicast or unicast services within a preset time period, the first indication information and / or the second indication information are sent. In this invention, the network device can notify the terminal device in the connected state to release the RRC connection via RRC release signaling, while simultaneously informing the terminal device to continue receiving multicast service data after entering an inactive state. This flexibility of indication is achieved through multiplexing signaling, eliminating the need for additional signaling and further reducing signaling overhead.

[0042] Furthermore, for a terminal device in an inactive state, if there is data for the multicast service that needs to be transmitted, the first indication information is carried in a paging message and sent out. The paging message also includes the identifier of the multicast service. In this invention, when the network device indicates that multicast service data is to be transmitted via paging, it can simultaneously indicate to the terminal device that it can receive multicast service data in an inactive state, thus achieving flexibility in indication. Attached Figure Description

[0043] Figure 1 This is a flowchart of a non-active multicast service transmission method according to an embodiment of the present invention;

[0044] Figure 2 This is an interactive flowchart of an inactive multicast service transmission embodiment of the present invention.

[0045] Figure 3 This is an interactive flowchart of another inactive multicast service transmission embodiment of the present invention;

[0046] Figure 4 This is a flowchart of a non-active multicast service transmission method according to an embodiment of the present invention;

[0047] Figure 5 This is an interactive flowchart of another inactive multicast service transmission method in an embodiment of the present invention;

[0048] Figure 6 This is an interactive flowchart of another inactive multicast service transmission method in an embodiment of the present invention;

[0049] Figure 7 This is a schematic diagram of the structure of a non-active multicast service transmission device according to an embodiment of the present invention;

[0050] Figure 8 This is a schematic diagram of the structure of a non-active multicast service receiving device according to an embodiment of the present invention;

[0051] Figure 9 A schematic diagram of the hardware structure of a communication device in an embodiment of the present invention. Detailed Implementation

[0052] The communication systems applicable to the embodiments of this application include, but are not limited to, long-term evolution (LTE) systems, 5th-generation (5G) systems, NR systems, and future evolution systems, or multiple converged communication systems. The 5G system can be a non-standalone (NSA) 5G system or a standalone (SA) 5G system. The technical solutions of this application are also applicable to different network architectures, including but not limited to relay network architectures, dual-link architectures, and vehicle-to-everything (V2X) architectures.

[0053] This application primarily relates to communication between terminal devices and network devices. Specifically:

[0054] The network device in this application embodiment can also be called an access network device, for example, it can be a base station (BS) (also called a base station device). A network device is a device deployed in a radio access network (RAN) to provide wireless communication functions. For example, in second-generation (2G) networks, equipment providing base station functionality includes base transceiver stations (BTS); in third-generation (3G) networks, it includes NodeBs; in fourth-generation (4G) networks, it includes evolved NodeBs (eNBs); in wireless local area networks (WLANs), it is an access point (AP); in NR (Radio Frequency Identification), it includes next-generation nodebase stations (gNBs) and further evolved NodeBs (ng-eNBs). The gNB communicates with the terminal device using NR technology, while the ng-eNB communicates with the terminal device using Evolved Universal Terrestrial Radio Access (E-UTRA) technology. Both gNBs and ng-eNBs can connect to the 5G core network. The network equipment in this application embodiment also includes equipment providing base station functionality in future new communication systems.

[0055] In this application, "terminal equipment" can refer to various forms of access terminals, user units, user stations, mobile stations, mobile stations (MS), remote stations, remote terminals, mobile devices, user terminals, wireless communication equipment, user agents, or user devices. Terminal equipment can also be cellular phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, Personal Digital Assistants (PDAs), handheld devices with wireless communication capabilities, computing devices, or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal equipment in future 5G networks, or terminal equipment in future evolved Public Land Mobile Networks (PLMNs), etc. This application does not limit the scope of these terms. Terminal equipment can also be called user equipment (UE), terminal, etc.

[0056] As described in the background section, in the current protocol version, network devices notify terminal devices that multicast services are about to begin transmission. After receiving the paging notification, terminal devices in idle or inactive states need to switch to connected state to receive the multicast service if they are interested in it. If a terminal device can receive multicast services in an inactive state, it first needs to determine whether it can receive multicast services in its current state.

[0057] The present invention provides a method that, by setting first indication information and second indication information, enables terminal devices to explicitly receive multicast service data in an inactive state, thereby realizing the transmission of inactive multicast services, reducing the signaling overhead of terminal devices and reducing network load.

[0058] Another issue to address when transmitting multicast services in an inactive state is that once an inactive terminal device is allowed to receive multicast services, the network device may not know which beams to transmit the multicast service on. In the current protocol version, when a terminal device in a connected state receives multicast services, the network device can learn which beams to transmit the multicast service on through the terminal device's reporting information at Layer 1 or Layer 3, etc. However, for inactive terminal devices, it is difficult for the network device to track the beam serving that terminal device in a timely manner. Therefore, it is necessary to determine the beam for transmitting multicast services so that inactive terminal devices can receive multicast services.

[0059] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0060] Figure 1 This is an embodiment of the present invention of a method for transmitting inactive multicast services.

[0061] The inactive multicast service transmission method can be used on the network device side, that is, the network device can execute each step of the transmission method.

[0062] Specifically, the method for transmitting inactive multicast services may include the following steps:

[0063] Step 101: Send a first indication message and / or a second indication message, wherein the first indication message indicates receiving multicast services in an inactive state, and the second indication message indicates the conditions that need to be met to receive multicast services in an inactive state;

[0064] Step 102: Send data for the multicast service.

[0065] It should be noted that the sequence number of each step in this embodiment does not represent a limitation on the execution order of each step.

[0066] In this embodiment, the first indication information directly indicates whether the terminal device can receive multicast services in an inactive state; the second indication information indirectly indicates whether the terminal device can receive multicast services in an inactive state through conditions. The network device can send the first indication information to the terminal device, and the terminal device, according to the indication of the first indication information, can receive multicast service data in an inactive state. The network device can also send the second indication information to the terminal device, and the terminal device, according to the conditions indicated by the second indication information, determines whether it can receive multicast service data in an inactive state.

[0067] Accordingly, the terminal device receives the first indication information and / or the second indication information; if the terminal device determines that it can receive multicast service data in the inactive state, then the terminal device receives multicast service data in the inactive state.

[0068] Furthermore, the second indication information may include some or all of the parameters related to the conditions for the terminal device to receive multicast services in the inactive state.

[0069] It is understood that, in specific implementations, the inactive multicast service transmission and reception methods can be implemented using software programs, which run in a processor integrated within the chip or chip module. This method can also be implemented using a combination of software and hardware; this application does not impose any restrictions.

[0070] In a non-limiting embodiment, the network device sends the first indication information to the terminal device in an RRC release signaling message.

[0071] Please refer to the details. Figure 2 , Figure 2 This diagram illustrates an interaction between terminal devices and network devices.

[0072] In step 201, the network device sends an RRC release signaling message to the terminal device. The RRC release signaling message includes first indication information and / or second indication information. After receiving the RRC release signaling message, the terminal device releases the connection and enters an inactive state, and determines that it can receive multicast services in the inactive state through the first indication information and / or second indication information in the RRC release signaling message.

[0073] Specifically, if the terminal device is in a connected state and is receiving multicast services, and the network device finds that there is no data transmission of the multicast service within a preset time period, and there are no other multicast or unicast services, then the network device can send the aforementioned RRC release signaling.

[0074] In step 202, the network device sends a paging message to the terminal device.

[0075] Specifically, when multicast service data needs to be transmitted, the network device notifies the terminal device of the multicast service data transmission via paging.

[0076] In step 203, the network device sends multicast service data to the terminal device.

[0077] Specifically, the terminal device uses previously saved configuration parameters of the multicast service, such as search space configuration parameters, to receive the multicast service data in the inactive state.

[0078] In a non-limiting embodiment, when the network device sends the second indication information, it can carry the second indication information in RRC signaling and send it out. The RRC signaling can be RRC release signaling or any other implementable RRC signaling, and this embodiment of the invention does not limit this.

[0079] In a non-limiting embodiment, the network device transmits the first indication information to the terminal device in a paging message.

[0080] Please refer to the details. Figure 3 , Figure 3 This diagram illustrates an interaction between terminal devices and network devices.

[0081] In step 301, the network device sends an RRC release signaling message to the terminal device.

[0082] Specifically, the terminal device is in a connected state and is receiving multicast services. When the serving cell has no multicast service data transmission, for example, no multicast service data transmission for a preset duration, and no other multicast or unicast services, it sends an RRC release signaling message to switch the terminal device in the connected state to an inactive state, thereby reducing network load.

[0083] In step 302, the network device sends a paging message to the terminal device. The paging message includes first indication information.

[0084] Specifically, when multicast service data needs to be transmitted, the network device notifies the terminal device of the multicast service data transmission via paging, and simultaneously instructs the terminal device in the paging that it can receive multicast service data in an inactive state.

[0085] In step 303, the network device sends multicast service data to the terminal device.

[0086] Specifically, the terminal device uses previously saved configuration parameters of the multicast service, such as search space configuration parameters, to receive the multicast service data in the inactive state.

[0087] In a non-limiting embodiment, the first indication information corresponds to the identifier of at least one multicast service, and the second indication information corresponds to the identifier of at least one multicast service.

[0088] In practice, since there are various types of multicast services, it is possible to independently indicate whether reception is possible in an inactive state for each type of multicast service. Specifically, an association can be established between the first indication information and the identifier of the multicast service. The first indication information can correspond to the identifier of one or more multicast services. Similarly, the second indication information can correspond to the identifier of one or more multicast services.

[0089] Specifically, the paging message includes identifiers for multiple multicast services. When carrying first indication information in the paging message, this first indication information can include multiple bit values, each corresponding to an identifier for a multicast service. In a specific example, the identifiers for multicast services can be in the form of a list, and the first indication information can also be in the form of a list. The contents of corresponding positions in the two lists have a corresponding relationship, so that the terminal device can determine which multicast service can be received in the inactive state based on the correspondence.

[0090] In a non-limiting embodiment, the second indication information includes one or more of the following: being in a serving cell transmitting the multicast service; being in a serving cell receiving the conditions; being in one or more beams of the serving cell, and the signal quality of at least one beam reaches a preset threshold; being in the serving cell, and the uplink advance timer has not expired, and one or more configured grants (CGs) are valid; being in the serving cell, and the uplink advance timer has not expired, and the serving cell is configured to transmit uplink resources for Hybrid Automatic Repeat reQuest (HARQ) feedback.

[0091] In specific implementation, the second indication information can directly indicate the specific condition content, or it can include some or all of the condition-related parameters. For example, for one or more beams within the serving cell, and at least one beam's signal quality reaching a preset threshold, the second indication information can indicate one or more beam identifiers and the preset threshold value. For uplink advance timers not timed out and one or more configured authorizations being valid, the second indication information can indicate the duration of the uplink advance timer and the configured one or more configuration authorizations. For uplink advance timers not timed out and uplink resources configured for transmitting hybrid automatic repeat request feedback, the second indication information can indicate the duration of the uplink advance timer and the configured uplink resources. Once the terminal device obtains some or all of the condition-related parameters, it can determine the specific content of the condition and thus judge whether the condition is met.

[0092] Among these conditions, the requirement that the signal quality of at least one beam reaches a preset threshold ensures that the terminal device can reliably receive multicast service data in the inactive state. The requirement that the uplink advance timer has not timed out ensures that the terminal device is in a condition capable of uplink feedback, and the requirement that one or more configured authorizations are valid ensures that the terminal device has uplink resources available for uplink feedback. Similarly, the requirement that the serving cell configures uplink resources for transmitting HARQ feedback ensures that the terminal device has uplink resources available for uplink feedback; these uplink resources can be Physical Uplink Control Channel (PUCCH) resources.

[0093] In practice, after entering the inactive state, the terminal device determines whether it can receive multicast services in the inactive state based on the criteria configured by the network device (i.e., the second indication information). When the serving cell resumes transmitting multicast service data, if the terminal device determines that it can receive multicast services in the inactive state, it remains in the inactive state and receives multicast service data using parameters such as the search space corresponding to the downlink control signaling for detecting multicast services. If the terminal device determines that the criteria are not met, for example, if the terminal device finds that the signal quality of multiple beams configured by the serving cell is lower than a preset threshold, or if the CG configured by the serving cell is no longer effective, the terminal device will not receive multicast data in the inactive state. If the terminal device is still interested in multicast services at this time, it needs to initiate a Radio Resource Control (RRC) connection establishment or recovery procedure, and after entering the connected state, wait for the reconfiguration of the serving cell before receiving multicast service data.

[0094] In a specific application scenario, an NR cell supports multicast services. This NR cell can transmit multicast services to terminal devices in different states within the cell, such as RRC connected state and inactive state (which can be extended to idle state). Over a period of time, the NR cell needs to transmit three types of multicast services, referred to as session 1, session 2, and session 3. Based on the service quality parameters of different sessions, the NR cell considers session 1 to be received by connected and inactive terminal devices, while the other two sessions (session 2 and session 3) must be received by connected terminal devices.

[0095] In one implementation, the network device is configured to receive multicast services (i.e., first indication information) in an inactive state via RRC Release signaling, and configured according to the session. For example, for a terminal device UE1 in a connected state that is receiving Session 1, if the serving cell finds that there is no data transmission for Session 1 for a period of time, and UE1 has no other multicast and unicast services, the network device can release the RRC connection of UE1 via RRC Release signaling, notify UE1 to enter an inactive state, and indicate in the signaling that Session 1 can receive data in the inactive state.

[0096] After entering the inactive state, UE1 saves the relevant configurations for receiving Session 1 obtained in the active state, such as parameters like the search space corresponding to the downlink control signaling for detecting multicast services. After a period of time, the network device obtains new Session 1 data from the core network. The network device instructs terminal devices interested in Session 1 to receive multicast data via paging instructions or multicast service update information (such as group activation notification instructions or MCCH change notifications). Upon receiving the instruction, UE1 uses the saved parameters of the search space for detecting the multicast service to receive Session 1 in the inactive state.

[0097] In another implementation, the network device uses RRC signaling to configure the criteria for receiving multicast services in the inactive state (i.e., the second indication information), and the terminal device determines whether to receive multicast services in the inactive state according to the criteria.

[0098] For example, for UE2 in connected state that is receiving Session 1, if the serving cell detects no data transmission for Session 1 for a period of time, and UE2 has no other multicast or unicast services, the serving cell can release the UE's RRC connection via RRC release signaling, notifying UE2 to enter inactive state. Simultaneously, the signaling may indicate the criteria for receiving Session 1 in inactive state. Possible criteria include one or more of the following:

[0099] 1. UE2 continues in the serving cell (i.e., the serving cell that transmits the criteria), or

[0100] 2. Under one or more beams configured in the serving cell, if UE2 measures that any one (at least one) of the multiple beams exceeds a preset threshold, such as when the serving cell configures beams according to SSBs, configuring SSB1 and SSB2, and configuring a preset threshold, the criterion is considered met as long as UE2 measures that at least one of SSB1 or SSB2 exceeds the preset threshold.

[0101] 3. Under this serving cell, if UE2's uplink timing advance timer has not expired and one or more configured authorizations are valid, UE2 can upload necessary information through the configuration authorization, such as HARQ ACK / NACK for receiving multicast data, channel state information of the beam measured by UE2, etc., or

[0102] 4. Under this serving cell, UE2's uplink advance timer has not expired, and the serving cell has configured PUCCH resources for UE2 to transmit HARQ feedback.

[0103] After UE2 enters the inactive state, it determines whether it can receive Session 1 in the inactive state based on the criteria configured in the network device. When the serving cell resumes transmitting Session 1 data, if UE2 determines that it can receive Session 1 in the inactive state, it remains in the inactive state and uses the saved parameters such as the search space corresponding to the downlink control signaling for detecting multicast services to receive the scheduling information and data of Session 1. If UE2 determines that the criteria are not met, for example, if UE2 finds that the signal quality of multiple beams configured by the serving cell is lower than a preset threshold, or if the configuration authorization configured by the serving cell is no longer valid, then UE2 will not receive Session 1 data in the inactive state. If UE2 is still interested in Session 1 at this time, UE2 needs to initiate an RRC connection establishment or recovery procedure, and after entering the connected state, wait for the serving cell to reconfigure before receiving Session 1 data.

[0104] In another implementation, when there is no multicast data transmission, the serving cell can switch the terminal device that was originally in the connected state receiving multicast data to the inactive state. After a period of time, if there is multicast data transmission, the serving cell will notify the terminal device via paging that there is data transmission in Session 1. At the same time, the serving cell will indicate in the paging that it can receive the data of Session 1 in the inactive state.

[0105] For terminal devices that have transitioned to an inactive state, the previously saved configuration for receiving Session 1, such as search space configuration parameters, is used to receive data from Session 1.

[0106] In another implementation, the serving cell notifies the terminal device via a first indication message that it can receive multicast services in an inactive state. The conditions (i.e., criteria) that the terminal device must meet to receive multicast services in an inactive state are pre-defined by the protocol. If the terminal device in the inactive state continues to be interested in multicast services, it needs to determine whether the conditions are met. If the conditions are met and a paging or update message indicating the data transmission of the multicast service is received, the terminal device receives the multicast service data. The conditions that must be met to receive multicast services in an inactive state include one or more of the following:

[0107] 1. The UE continues in the serving cell (i.e., the serving cell that sent the first indication information), or

[0108] 2. Under one or more beams configured in the serving cell, if the UE measures that any one (at least one) of the multiple beams exceeds a preset threshold, such as when the serving cell configures beams according to SSBs, configuring SSB1 and SSB2, and configuring a preset threshold, the criterion is considered met as long as UE2 measures that either SSB1 or SSB2 exceeds the preset threshold, or...

[0109] 3. If the UE's uplink timing advance timer has not expired within the serving cell, and one or more configured authorizations are valid, UE2 can upload necessary information through the configuration authorization, such as HARQ ACK / NACK for receiving multicast data, channel state information of the beam measured by the UE, etc., or

[0110] 4. Under the serving cell, the uplink advance timer of the UE has not expired, and the serving cell has configured PUCCH resources for the UE to transmit HARQ feedback.

[0111] This invention also discloses a method for transmitting inactive multicast services. In this embodiment, the terminal device is in an inactive state.

[0112] Specifically, please refer to Figure 4 The inactive multicast service transmission method may include the following steps:

[0113] The terminal device first obtains the service identifier of the multicast service that can be received in the inactive state, as well as the preamble information corresponding to each multicast service, through the system message or MCCH of the serving cell. The UE expecting to receive multicast services in the inactive state, based on the preamble corresponding to the multicast service it is interested in, enables the network device to know its beam position through a random access procedure. The network device can then send multicast data in the corresponding beam, avoiding sending multicast data on all beams, which can effectively save wireless transmission resources.

[0114] Step 401: The terminal device sends a preamble during the RACH Occasion corresponding to the first beam. The terminal device is on the first beam, meaning it uses the first beam to send and receive data. Correspondingly, the network device receives the preamble.

[0115] Step 402: The network device determines the information of the first beam based on the timing of the preamble reception. Specifically, the network device can determine the identifier of the first beam.

[0116] Step 403: The network device transmits multicast service data on the first beam. That is, after the network device learns through the preamble that the terminal device is transmitting and receiving data on the first beam, it can send multicast service data to the terminal device through the first beam to achieve reliable transmission of the multicast service. Correspondingly, the terminal device receives the multicast service data.

[0117] The embodiments of the present invention enable network devices to know which beams need to be used to transmit multicast services. In other words, the network devices can know the distribution of inactive terminal devices in the cell and which beams the terminal devices receive multicast service data in, so that the multicast service data can be correctly transmitted to the inactive terminal devices.

[0118] In one specific embodiment, the preamble can be sent and received via message 1 (Msg1).

[0119] In a non-limiting embodiment, please refer to Figure 5 The interaction process between terminal devices and network devices is as follows.

[0120] In step 501, the terminal device sends Msg1 to the network device, and Msg1 includes a preamble. This preamble can be a standard preamble, that is, the form and content of a preamble specified in the communication standard protocol.

[0121] In step 502, the network device determines the information of the first beam based on the timing of the preamble reception.

[0122] In step 503, the network device sends Msg2 to the terminal device. Msg2 can be a response message to Msg1, specifically a random access response.

[0123] In step 504, the terminal device sends Msg3 to the network device, where Msg3 includes the service identifier of the multicast service it is interested in.

[0124] In step 505, the network device sends Msg4 to the terminal device. Msg4 can be a response message to Msg3, specifically an acknowledgment message (ACK) or a conflict resolution message.

[0125] At this point, the network device can determine the identifier of the first beam used by the terminal device to receive multicast data, as well as the service identifier of the multicast service that the terminal device is interested in. Therefore, the network device can send the multicast service data indicated by the service identifier to the terminal device on the first beam.

[0126] In another non-limiting embodiment, please refer to Figure 6 The interaction process between terminal devices and network devices is as follows.

[0127] Step 601: The terminal device sends Msg1 to the network device. Msg1 includes a preamble specific to the multicast service. Specifically, the network device can allocate a specific preamble to the terminal device requesting multicast service transmission in the MBMS point-to-multipoint control channel (MCCH), such as allocating a dedicated preamble for the Session 1 request.

[0128] Step 602: The network device determines the information of the first beam based on the timing of the preamble reception. Furthermore, the network device can also determine the service identifier of the multicast service corresponding to the preamble.

[0129] Step 603: The network device sends Msg2 to the terminal device. Msg2 can be a response message to Msg1, specifically a random access response.

[0130] Step 604: The network device sends multicast service data on the first beam.

[0131] Compared to the aforementioned embodiments, this embodiment of the invention sets a preamble dedicated to multicast services, so that the terminal device and the network device only need to interact with Msg1 and Msg2 to enable the network device to obtain the required information, thereby improving the efficiency of interaction between the terminal device and the network device.

[0132] It should be noted that the terminal device can send preambles multiple times to send beam information back to the network device until it receives the multicast service data.

[0133] In practical implementation, because NR is deployed at high frequencies, and wireless signals at high frequencies exhibit good directionality but high path loss, a cell with a large coverage area requires multiple beams to achieve complete coverage, while a single beam can only cover a limited area. A cell with a smaller coverage area can contain only one beam. For cells composed of multiple beams, due to hardware limitations, not all beams can be transmitted simultaneously; time-division transmission is required, known as beam sweeping. For an NR cell, its synchronization signals (including primary and secondary synchronization signals) are transmitted according to a certain period, such as 5ms / 10ms / 20ms / 40ms / 80ms. A cell transmits one or more Synchronization Signal Blocks (SSBs) (i.e., different beams), such as 4 or 8 SSBs. Within one period, these SSBs are distributed within 5ms. An SSB includes PSS / SSS and PBCH. PSS and SSS are used to enable terminal devices to identify the cell identifier and to enable terminal devices to obtain symbol-level synchronization. When a terminal device evaluates the signal quality of a cell, it needs to combine the N strongest beams measured in that cell to obtain the cell's signal quality. The value of N can be configured by the network, and N>=1.

[0134] In a specific application scenario, a serving cell typically contains eight SSBs, from SSB0 to SSB7. Based on the distribution of connected terminal devices that need to receive Session 1 data, the serving cell determines that it must transmit Session 1 data in at least SSB2, SSB3, and SSB5. However, the serving cell is unaware of the distribution of inactive terminal devices that need to receive Session 1 data within the cell; that is, it does not know which beams the inactive terminal devices will receive multicast data on.

[0135] To determine which other beams besides SSB2, SSB3, and SSB5 should transmit Session 1 data, the serving cell indicates the beam information (i.e., SSB2, SSB3, and SSB5) to be transmitted in the MCCH. For inactive terminal devices that need to be served by other beams, they need to send feedback information to the serving cell, indicating which beam they need to receive Session 1 on.

[0136] Specifically, if an inactive terminal device can receive Session 1 on SSB2, SSB3, or SSB5, it does not need to indicate any information to the base station. For terminal devices that cannot receive Session 1 on SSB2, 3, or 5, they need to indicate to the serving cell which beam (or beams) they need to receive Session 1 on. This can be done through a random access procedure.

[0137] One approach is for the terminal device to send a preamble via Msg1 and indicate the Session 1 identifier to the serving cell via Msg3. The network device determines which SSB the terminal device needs to receive Session 1 from based on the timing of the preamble sent by the terminal device.

[0138] Another approach is for the serving cell to allocate a specific preamble (a preamble dedicated to multicast services) in the MCCH for the terminal device requesting the multicast service, such as allocating a dedicated preamble for the Session 1 request. Once the serving cell receives this preamble, it can determine from the timing of the UE sending the preamble which SSB the terminal device needs to receive Session 1.

[0139] If the terminal device fails to receive Session 1 from the corresponding beam after multiple requests, it initiates an RRC connection / recovery request to the network device. After entering the connected state, it requests the serving cell to send Session 1 to it. The threshold for the number of failed requests can be set by the serving cell. When the number of failed requests is less than or equal to this threshold, the terminal device indicates the multicast services it is interested in and its current beam information to the network device in the manner described above.

[0140] Please refer to Figure 7 This invention also discloses an inactive multicast service transmission device. The inactive multicast service transmission device 70 may include:

[0141] The instruction information sending module 701 is used to send first instruction information and / or second instruction information, wherein the first instruction information indicates receiving multicast services in an inactive state, and the second instruction information indicates the conditions that need to be met to receive multicast services in an inactive state.

[0142] The data sending module 702 is used to send data for multicast services.

[0143] In specific implementations, the aforementioned inactive multicast service transmission device may correspond to a chip in a network device that has inactive multicast service transmission function, such as a SOC (System-On-a-Chip), baseband chip, etc.; or to a chip module in a network device that includes a chip module with inactive multicast service transmission function; or to a chip module with a data processing function chip; or to a network device.

[0144] Please refer to Figure 8 This invention also discloses a deactivated multicast service receiving device. The deactivated multicast service receiving device 80 may include:

[0145] Instruction information receiving module 801 is used to receive first instruction information and / or second instruction information, wherein the first instruction information indicates receiving multicast services in an inactive state, and the second instruction information indicates the conditions that need to be met to receive multicast services in an inactive state.

[0146] The data receiving module 802 is used to receive multicast service data in an inactive state.

[0147] In specific implementations, the aforementioned inactive multicast service receiving device may correspond to a chip in a terminal device that has inactive multicast service receiving function, such as a SOC (System-On-a-Chip), baseband chip, etc.; or correspond to a chip module in a terminal device that includes inactive multicast service receiving function; or correspond to a chip module with data processing function chip; or correspond to a terminal device.

[0148] For more information on the working principle and operation mode of the inactive multicast service transmitting device 70 or the inactive multicast service receiving device 80, please refer to [link / reference needed]. Figures 1 to 6 The relevant descriptions in the text will not be repeated here.

[0149] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0150] This invention also discloses a storage medium, which is a computer-readable storage medium storing a computer program thereon, the computer program being executable during runtime. Figures 1 to 6 The steps of the method shown are illustrated. The storage medium may include ROM, RAM, disk, or optical disk, etc. The storage medium may also include non-volatile memory or non-transitory memory, etc.

[0151] Please refer to Figure 9 This application also provides a schematic diagram of the hardware structure of a communication device. The device includes a processor 901, a memory 902, and a transceiver 903.

[0152] Processor 901 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program according to the present application. Processor 601 may also include multiple CPUs, and processor 901 can be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, or processing cores used to process data (e.g., computer program instructions).

[0153] The memory 902 can be a ROM or other type of static storage device capable of storing static information and instructions, RAM or other type of dynamic storage device capable of storing information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer. This application embodiment does not impose any limitations on this. The memory 902 can exist independently (in this case, the memory 902 can be located outside or inside the device) or can be integrated with the processor 901. The memory 902 may contain computer program code. The processor 901 is used to execute the computer program code stored in the memory 902, thereby implementing the method provided in this application embodiment.

[0154] The processor 901, memory 902, and transceiver 903 are connected via a bus. The transceiver 903 is used to communicate with other devices or communication networks. Optionally, the transceiver 903 may include a transmitter and a receiver. The device in the transceiver 903 that implements the receiving function can be considered as a receiver, which is used to perform the receiving steps in the embodiments of this application. The device in the transceiver 903 that implements the transmitting function can be considered as a transmitter, which is used to perform the transmitting steps in the embodiments of this application.

[0155] when Figure 9 The structural diagram shown is used to illustrate the structure of the terminal device involved in the above embodiments. The processor 901 is used to control and manage the actions of the terminal device. For example, the processor 901 is used to support the terminal device in performing...Figure 5 Steps 501 and 504 in the text, or Figure 6 The processor 901 performs actions in step 601 and / or other processes described in the embodiments of this application. The processor 901 can communicate with other network entities via the transceiver 903, for example, with the aforementioned network devices. The memory 902 stores the program code and data of the terminal device. When the processor runs the computer program, it can control the transceiver 903 to receive RRC release signaling, paging, multicast service data, Msg2, Msg4, etc.

[0156] when Figure 9 The schematic diagram shown illustrates the structure of the network device involved in the above embodiments. The processor 901 is used to control and manage the actions of the network device; for example, the processor 901 is used to support the network device in performing... Figure 1 Steps 101 and 102 in the text, or Figure 2 Steps 201, 202, and 203 in the process, Figure 3 Steps 301, 302, and 303 in the text, Figure 4 Steps 402 and 403 in the process, Figure 5 Steps 502, 503, and 505 in the text, Figure 6 Steps 602, 603, and 604 in the process described in the embodiments of this application, and / or other actions performed by the network device in other processes. The processor 901 can communicate with other network entities via the transceiver 903, for example, with the aforementioned terminal device. The memory 902 is used to store the program code and data of the network device. When the processor runs the computer program, it can control the transceiver 903 to send one or more of RRC signaling, MAC signaling, and DCI.

[0157] In this application embodiment, a one-way communication link from the access network to the terminal device is defined as a downlink, and the data transmitted on the downlink is called downlink data. The transmission direction of the downlink data is called the downlink direction. On the other hand, a one-way communication link from the terminal device to the access network is defined as an uplink, and the data transmitted on the uplink is called uplink data. The transmission direction of the uplink data is called the uplink direction.

[0158] In this application embodiment, the one-way communication link from the access network to the terminal is defined as the downlink, the data transmitted on the downlink is called downlink data, and the transmission direction of the downlink data is called the downlink direction; while the one-way communication link from the terminal to the access network is defined as the uplink, the data transmitted on the uplink is called uplink data, and the transmission direction of the uplink data is called the uplink direction.

[0159] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article indicates that the preceding and following related objects have an "or" relationship.

[0160] In the embodiments of this application, "multiple" refers to two or more.

[0161] The descriptions of "first," "second," etc., appearing in the embodiments of this application are for illustrative purposes and to distinguish the objects being described. They have no order and do not indicate any special limitation on the number of devices in the embodiments of this application, nor do they constitute any limitation on the embodiments of this application.

[0162] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0163] It should be understood that in the embodiments of this application, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0164] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0165] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

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

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

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

[0169] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can be physically comprised separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0170] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0171] While the present invention has been disclosed above, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A method for transmitting inactive multicast services, characterized in that, include: Send a first indication message and a second indication message, wherein the first indication message indicates receiving multicast services in an inactive state, and the second indication message indicates the conditions that need to be met to receive multicast services in an inactive state; Sending the first indication information includes: carrying the first indication information in a paging message and sending it out; the first indication information corresponds to the identifier of at least one multicast service, and the second indication information corresponds to the identifier of at least one multicast service. Send data for multicast services.

2. The method for transmitting inactive multicast services according to claim 1, characterized in that, The sending of the second instruction information includes: The second indication information is carried in RRC signaling and sent out.

3. The method for transmitting inactive multicast services according to claim 1 or 2, characterized in that, The sending of the first indication information and the second indication information includes: For a terminal device that receives the multicast service and is in a connected state, if there is no multicast or unicast service within a time period of a preset duration, the first indication information or the second indication information is sent.

4. The method for transmitting inactive multicast services according to claim 1, characterized in that, The sending of the first instruction information includes: For terminal devices in an inactive state, if there is data for the multicast service that needs to be transmitted, the first indication information is carried in a paging message and sent out. The paging message also includes the identifier of the multicast service.

5. The method for transmitting inactive multicast services according to claim 1, characterized in that, The second instruction information includes one or more of the following conditions: The serving cell is located where the multicast service is being transmitted. The serving cell is in which the first instruction information or the second instruction information is received; The signal quality of at least one beam in the serving cell reaches a preset threshold. The user is located in the serving cell, and the uplink advance timer has not expired, and one or more configured authorizations are valid. The serving cell is located in the serving cell and the uplink advance timer has not expired. The serving cell is configured to transmit uplink resources for HARQ feedback.

6. The method for transmitting inactive multicast services according to claim 1, characterized in that, The second indication information includes some or all of the parameters related to the conditions.

7. The method for transmitting inactive multicast services according to claim 1, characterized in that, The data sent for multicast services includes: The receiving terminal device sends the beam information indicated by MSG1 or MSG3, and transmits the multicast service data in the beam indicated by the beam information.

8. A method for receiving inactive multicast services, characterized in that, include: Receive first indication information and second indication information, wherein the first indication information indicates receiving multicast services in an inactive state, and the second indication information indicates the conditions that need to be met to receive multicast services in an inactive state; Receiving the first indication information includes: receiving a paging in an inactive state, wherein the paging includes the first indication information; The first indication information corresponds to the identifier of at least one multicast service, and the second indication information corresponds to the identifier of at least one multicast service. Receive multicast service data in the inactive state.

9. The inactive multicast service reception method according to claim 8, characterized in that, Upon receiving the first instruction information, the conditions that need to be met to receive multicast services in the inactive state are preset by the protocol.

10. The inactive multicast service reception method according to claim 8, characterized in that, The first indication information is set according to the multicast service identifier to determine whether to receive multicast services in the inactive state.

11. The inactive multicast service reception method according to claim 8, characterized in that, The receipt of the second indication information includes: In the active state, RRC signaling is received, and the RRC signaling includes the second indication information.

12. The inactive multicast service reception method according to claim 8 or 10, characterized in that, After receiving the first indication information and the second indication information, the following is included: Entering an inactive state; The parameter configuration for receiving the multicast service obtained when the system is in the active state is stored.

13. The inactive multicast service reception method according to claim 8, characterized in that, The data received in the inactive state for multicast services includes: If the first indication information is received, then after receiving the paging or update information indicating the data transmission of the multicast service, the data of the multicast service is received; If the second indication information is received, it is determined whether the condition indicated by the second indication information is met, and after the condition is met and a paging or update information indicating the data transmission of the multicast service is received, the data of the multicast service is received. If only the first indication information is received, and the conditions for receiving multicast services in the inactive state are preset by the protocol, it is determined whether the conditions are met. If the conditions are met and a paging or update information indicating the data transmission of the multicast service is received, the data of the multicast service is received.

14. A non-active multicast service transmission device, characterized in that, include: An instruction information sending module is used to send first instruction information and second instruction information, wherein the first instruction information indicates receiving multicast services in an inactive state, and the second instruction information indicates the conditions that need to be met to receive multicast services in an inactive state. Sending the first indication information includes: transmitting the first indication information in a paging message; the second indication information includes some or all parameters related to the conditions; the first indication information corresponds to the identifier of at least one multicast service, and the second indication information corresponds to the identifier of at least one multicast service. The data sending module is used to send data for multicast services.

15. A non-active multicast service receiving device, characterized in that, include: An instruction information receiving module is used to receive first instruction information and second instruction information, wherein the first instruction information indicates receiving multicast services in an inactive state, and the second instruction information indicates the conditions that need to be met to receive multicast services in an inactive state. The receiving of the first indication information includes: receiving a paging in an inactive state, the paging including the first indication information; the first indication information corresponds to the identifier of at least one multicast service, and the second indication information corresponds to the identifier of at least one multicast service. The data receiving module is used to receive multicast service data in an inactive state.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it performs the steps of the inactive multicast service transmission method according to any one of claims 1 to 7, or the steps of the inactive multicast service reception method according to any one of claims 8 to 13.

17. A network device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor runs the computer program, it performs the steps of the inactive multicast service transmission method according to any one of claims 1 to 7.

18. A terminal device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor runs the computer program, it performs the steps of the inactive multicast service reception method according to any one of claims 8 to 13.

Images