Communication method and apparatus

Abstract

A communication method and apparatus. The method comprises: a terminal device receives an RRC release message, the RRC release message comprising first indication information, and the first indication information instructing or configuring the terminal device to receive multicast in an RRC inactive state; if the terminal device cannot in the RRC inactive state read a multicast configuration sent by a network device or cannot in the RRC inactive state receive multicast data sent by the network device, the terminal device sends an RRC resume request; and the terminal device receives an RRC resume message and enters an RRC connected state to receive the multicast, or the terminal device receives an RRC release message and receives the multicast in the RRC inactive state. According to the method, occurrences of the terminal device being unable to receive multicast services can be reduced, thereby ensuring normal reception of the multicast services by the terminal device as much as possible.

Description

Communication method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on March 28, 2024, with application number 202410374523.6 and application name "A Communication Method and Device", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0004] Multicast services can be provided to terminal devices in the radio resource control (RRC) inactive state. When a terminal device switches from the RRC connected state to the RRC inactive state, it can still receive multicast services according to the multicast configuration provided by the network device.

[0005] However, for terminal devices with limited capabilities, when they enter the RRC inactive state, they may not be able to receive multicast services in certain cells. For example, if the bandwidth of the multicast service scheduled by a cell exceeds the maximum receiving bandwidth of the terminal device, the terminal device may not be able to receive the multicast service in that cell. Summary of the Invention

[0006] The embodiments of the present application provide a communication method and apparatus for reducing the occurrence of situations where a terminal device cannot receive a multicast service, and ensuring normal reception of the multicast service by the terminal device as much as possible.

[0007] In a first aspect, the present application provides a communication method that can be performed by a first communication device. The first communication device can be a terminal-side device, for example, the first communication device is a terminal device or a component in the terminal device (such as a circuit, chip, or chip system). For ease of description, the following example uses the first communication device as an example.

[0008] The communication method includes: a terminal device receives an RRC release message, the RRC release message includes first indication information, the first indication information instructs or configures the terminal device to receive multicast in an RRC inactive state; if the terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state or cannot receive multicast data sent by the network device in the RRC inactive state, the terminal device sends an RRC recovery request; the terminal device receives the RRC recovery message, enters the RRC connection state to receive multicast, or the terminal device receives the RRC release message, and receives multicast in the RRC inactive state.

[0009] In this method, for a terminal device configured to receive multicast in an RRC inactive state, if it is unable to read the multicast configuration sent by the network device or unable to receive the multicast data sent by the network device in the RRC inactive state, it can request the network device to restore the RRC connection. For example, when the scheduling rate or scheduling method of the multicast data exceeds the processing capacity of the terminal device, that is, it is unable to receive the multicast data of the network device, it can request the network device to restore the RRC connection. On the one hand, the network device can restore the RRC connection of the terminal device according to the request of the terminal device, so that the terminal device can enter the RRC connected state to receive multicast. Compared with the situation where the terminal device currently in the RRC inactive state does not actively trigger the RRC recovery request due to the inability to read the multicast configuration sent by the network device or the inability to receive the multicast data sent by the network device, the occurrence of the terminal device being unable to receive the multicast service can be reduced, so as to ensure the normal reception of the multicast service by the terminal device as much as possible. Alternatively, on the other hand, the network device can continue to allow the terminal device to receive multicast in the RRC inactive state. For example, the network device sends an RRC release message and updates the multicast configuration information, multicast scheduling mode or scheduling rate to ensure that the terminal device can successfully receive multicast data. This can reduce the number of connected terminal devices, thereby alleviating network congestion, and save power consumption of the terminal devices.

[0010] In one implementation, the terminal device receives multicast in an RRC inactive state, including: the terminal device receives a multicast configuration, and receives the multicast according to the multicast configuration.

[0011] When the network device responds to the RRC recovery request of the terminal device and sends an RRC release message to the terminal device, the network device can update the multicast configuration information and / or update the multicast scheduling method or scheduling rate to ensure that the terminal device can successfully receive multicast data. The terminal device can receive the latest multicast configuration from the network device. The multicast configuration can be considered to be configured for the RRC inactive terminal device to receive multicast, so that the terminal device can receive the multicast sent by the network device in the RRC inactive state according to the multicast configuration.

[0012] In one implementation, the inability to read the multicast configuration sent by the network device in the RRC inactive state includes: an inability to obtain the multicast configuration due to limited capabilities. For example, the inability to read the system information block (SIB) 24 due to limited capabilities or the inability to receive the multicast / multicast control channel (MCCH) based on the SIB 24 due to limited capabilities.

[0013] It is understood that SIB24 contains the configuration information required to receive MCCH, such as MCCH frequency domain location and bandwidth information, as well as MCCH time domain location information. Terminal devices can obtain MCCH messages based on the MCCH configuration information, and then obtain the configuration required to receive multicast scheduling from the MCCH message. Therefore, if the terminal device is unable to read SIB24 due to limited capabilities, or can read SIB24 but cannot successfully receive the MCCH message based on the MCCH configuration information in SIB24, then it can be considered that the terminal device is unable to obtain the multicast configuration due to limited capabilities.

[0014] Furthermore, the capability limitation may be that the maximum receiving bandwidth of the terminal device is limited. For example, the maximum receiving bandwidth of the terminal device is less than the bandwidth required for receiving the SIB24 or MCCH. Accordingly, the system message block SIB24 cannot be read due to the capability limitation, including: the bandwidth required for receiving SIB24 exceeds the maximum receiving bandwidth of the terminal device. The MCCH cannot be read according to SIB24 due to the capability limitation, including: the bandwidth required for receiving MCCH exceeds the maximum receiving bandwidth of the terminal device. Similarly, the multicast data sent by the network device cannot be received in the RRC inactive state, including: the multicast data cannot be successfully received due to the capability limitation. For example, the number of physical resource blocks (PRBs) used for scheduling multicast data exceeds the maximum number of PRBs that the terminal device can process or the rate of scheduling multicast data exceeds the maximum receiving rate that the terminal device can withstand. Capacity limitation may cause the terminal device to be unable to correctly receive or decode relevant information when receiving configuration information or data scheduling that exceeds the maximum capability of the terminal device.

[0015] In one implementation, the RRC recovery request includes second indication information, and the second indication information is used to indicate the reason why the terminal device initiates the RRC connection recovery request.

[0016] In this method, the terminal device notifies the network device of the reason for requesting to restore the RRC connection, so that the network device can clearly understand the reason why the terminal device requests to restore the RRC connection, which helps the network device decide whether to restore the RRC connection of the terminal device.

[0017] In one implementation, the method further includes: the terminal device sends third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

[0018] In this method, the terminal device may indicate to the network device that its capabilities are limited. In this case, the network device may determine, based on the terminal device's indication, that the reason for initiating an RRC recovery request after the terminal device in the RRC inactive state is configured to receive multicast is limited capabilities, which helps the network device decide whether to resume the RRC connection request.

[0019] In one implementation, the third indication information is carried in message 1 or message 3 in the random access process.

[0020] For example, the third indication information may be carried in a reserved bit or a logical channel identifier (LCID) in a media access control (MAC) header of message 3. For another example, the third indication information may be represented by a special random access resource or a special random access preamble.

[0021] In a second aspect, the present application provides a communication method that can be performed by a second communication device. The second communication device can be a network-side device, for example, the second communication device is a network device or a component in the network device (such as a circuit, chip, or chip system). For ease of description, the following example uses the second communication device as a network device.

[0022] The communication method includes: a network device sends an RRC release message to a terminal device, the RRC release message includes first indication information, and the first indication information indicates that the terminal device receives multicast in an RRC inactive state; the network device receives an RRC recovery request from the terminal device; the network device determines that the reason for the RRC recovery request is that the terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state or cannot receive multicast data sent by the network device in the RRC inactive state, then sends an RRC recovery message to the terminal device, or sends an RRC release message to the terminal device, and updates the multicast configuration.

[0023] In one implementation, the RRC recovery request includes second indication information, and the second indication information is used to indicate the reason why the terminal device initiates the RRC connection recovery request.

[0024] In one implementation, the reasons why the terminal device initiates an RRC connection recovery request include: being unable to obtain multicast configuration due to limited capabilities; or being unable to successfully receive multicast data due to limited capabilities.

[0025] In one implementation, the inability to obtain the multicast configuration due to limited capabilities includes: an inability to read SIB24 due to limited capabilities; or an inability to receive the MCCH according to SIB24 due to limited capabilities.

[0026] In one implementation, the inability to read SIB24 due to limited capabilities includes: the bandwidth of the scheduled SIB24 exceeds the maximum receiving bandwidth of the terminal device. Alternatively, the inability to receive the MCCH according to SIB24 due to limited capabilities includes: the bandwidth of the MCCH included in the scheduled SIB24 exceeds the maximum receiving bandwidth of the terminal device.

[0027] In one implementation, the inability to successfully receive multicast data due to limited capabilities includes: the number of PRBs used for scheduling multicast data exceeds the maximum number of PRBs that the terminal device can process.

[0028] In one implementation, the method further includes: the network device receiving third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

[0029] The network device can determine the reason why the terminal device initiates the RRC connection recovery request based on the second indication information and / or the third indication information.

[0030] In one implementation, the third indication information is carried in message 1 or message 3 in the random access process.

[0031] Regarding the beneficial effects of the second aspect and its various implementations, reference may be made to the beneficial effects of the aforementioned first aspect and its various implementations, which will not be repeated here.

[0032] In a third aspect, the present application provides a communication method that can be performed by a second communication device. The second communication device can be a network-side device, for example, the second communication device is a network device or a component in the network device (such as a circuit, chip, or chip system). For ease of description, the following example uses the second communication device as a network device.

[0033] The communication method includes: a network device sending an RRC release message to a terminal device, receiving an RRC resume request from the terminal device, and when determining that the terminal device's capability is limited, sending an RRC resume message to the terminal device, or sending an RRC release message to the terminal device, and updating a multicast configuration. The RRC release message includes first indication information, the first indication information instructing the terminal device to receive multicast in an RRC inactive state.

[0034] In this solution, for a terminal device receiving multicast in an RRC inactive state, if the terminal device initiates an RRC connection recovery request, the network device can determine the specific reason for the terminal device to initiate the RRC connection recovery request and determine whether to restore the RRC connection based on the determination result. For example, if the terminal device initiates the RRC recovery request because it is unable to receive multicast in an inactive state according to the network device's existing configuration or scheduling method due to limited capabilities, the network device can allow the terminal device to continue in the RRC inactive state and update the multicast configuration or multicast scheduling method. This can not only reduce the number of connected terminal devices, thereby alleviating network congestion, but also save power consumption of the terminal device.

[0035] In one implementation, the method further includes: the network device receiving third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

[0036] In one implementation, the third indication information is carried in message 1 or message 3 in the random access process.

[0037] Regarding the beneficial effects of the third aspect and its various implementations, reference may be made to the beneficial effects of the aforementioned first aspect or second aspect and its various implementations, which will not be repeated here.

[0038] In a fourth aspect, an embodiment of the present application provides a communication method that can be performed by a first communication device and a second communication device. The first communication device has the function of implementing the behavior in the method instance of the first aspect. For example, the first communication device includes corresponding means (means) or modules or units for executing the method of the first aspect, and the modules or means or units can be implemented by software and / or hardware. The second communication device has the function of implementing the behavior in the method instance of any aspect of the second aspect. For example, the second communication device includes corresponding means (means) or modules or units for executing the method of the second aspect, and the modules or means or units can be implemented by software and / or hardware. Taking the first communication device as the terminal device itself and the second communication device as the network device itself as an example, the communication method includes:

[0039] The communication method includes: a network device sends an RRC release message to a terminal device, the RRC release message includes first indication information, and the first indication information indicates that the terminal device receives multicast in an RRC inactive state; the terminal device sends an RRC recovery request to the network device; the network device determines that the reason for the RRC recovery request is that the terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state or cannot receive multicast data sent by the network device in the RRC inactive state, sends an RRC recovery message to the terminal device, or sends an RRC release message to the terminal device, and updates the multicast configuration.

[0040] Regarding the beneficial effects of the fourth aspect, reference may be made to the beneficial effects of the first aspect and its various implementation methods, which will not be repeated here.

[0041] In the fifth aspect, an embodiment of the present application provides a communication device, which has the function of implementing the behavior in the method example of any aspect from the first aspect to the third aspect above. The beneficial effects can be found in the relevant description of the first aspect or the third aspect and will not be repeated here. For example, the communication device may be the terminal device in the first aspect, or the communication device may be a device that can support the terminal device to implement the functions required by the method provided in the first aspect, for example, the communication device may be a chip or chip system in the terminal device. For another example, the communication device may be the network device in the second aspect or the third aspect, or the communication device may be a device that can support the network device to implement the functions required by the method provided in the second aspect or the third aspect, for example, the communication device may be a chip or chip system in the network device.

[0042] In one possible design, the communication device includes a baseband device and a radio frequency device.

[0043] In one possible design, the communication device includes corresponding means (means) or modules for executing the method of any aspect of the first aspect to the third aspect. For example, the communication device includes a processing unit (sometimes also referred to as a processing module or processor) and / or a transceiver unit (sometimes also referred to as a transceiver module or transceiver). The transceiver unit can realize the sending function and the receiving function. When the transceiver unit realizes the sending function, it can be called a sending unit (sometimes also referred to as a sending module). When the transceiver unit realizes the receiving function, it can be called a receiving unit (sometimes also referred to as a receiving module). The sending unit and the receiving unit can be the same functional unit, which is called a transceiver unit, and the functional unit can realize the sending function and the receiving function; or, the sending unit and the receiving unit can be different functional units, and the transceiver unit is a general term for these functional units. These units (modules) can perform the corresponding functions in the method examples of the first aspect, the second aspect or the third aspect above. Please refer to the detailed description in the method examples for details, which will not be repeated here.

[0044] In a sixth aspect, an embodiment of the present application provides a communication device, which may be the communication device in the fifth aspect of the above embodiment, or a chip or chip system provided in the communication device in the fourth aspect. The communication device includes a communication interface and a processor, and optionally, also includes a memory. The memory is used to store computer programs or instructions or data, and the processor is coupled to the memory and the communication interface. When the processor reads the computer program or instructions or data, the communication device executes the method executed by the terminal device in the above method embodiment. For example, the communication device may be a terminal device or a functional module in the terminal device, such as a baseband chip and a radio frequency chip. Alternatively, when the processor reads the computer program or instructions or data, the communication device executes the method executed by the network device in the above method embodiment. For example, the communication device may be a network device or a functional module in the network device, such as a baseband chip and a radio frequency chip.

[0045] In the seventh aspect, an embodiment of the present application provides a chip system, which includes a processor and may also include a communication interface for implementing the method described in any of the first to third aspects. Optionally, the chip system also includes a memory. The memory is used to store computer programs (also referred to as codes, or instructions). The processor is used to call and run the computer program from the memory so that the device equipped with the chip system executes the method in any of the first to third aspects and any of its implementations. The chip system can be composed of chips, or it can include chips and other discrete devices.

[0046] In an eighth aspect, embodiments of the present application provide a communication device comprising an input / output interface and a logic circuit. The input / output interface is used to input and / or output information. The input / output interface can be an interface circuit, an output circuit, an input circuit, a pin, or related circuits. The logic circuit is used to execute the method described in any of aspects 1 to 3.

[0047] In a specific implementation, the communication device may be a chip, the input circuit may be an input pin, the output circuit may be an output pin, and the logic circuit may be a transistor, a gate circuit, a trigger, or various logic circuits. The input signal received by the input circuit may be, for example, but not limited to, received and input by a receiver, and the signal output by the output circuit may be, for example, but not limited to, output to and transmitted by a transmitter. The input circuit and the output circuit may be the same circuit, which functions as an input circuit and an output circuit, respectively, at different times. This application does not limit the specific implementation of the input and output interfaces and logic circuits.

[0048] In one implementation, when the communication apparatus is a wireless communication device, the wireless communication device may be a terminal device such as a mobile phone, or a network device such as a base station. The interface circuit may be a radio frequency processing chip in the wireless communication device, and the processing circuit may be a baseband processing chip in the wireless communication device.

[0049] In a ninth aspect, an embodiment of the present application provides a communication system, comprising a terminal device and a network device. The terminal device is configured to implement the functions of the method described in the first aspect, and the network device is configured to implement the functions of the method described in the second aspect. Alternatively, the terminal device is configured to implement the functions of the method described in the first aspect, and the network device is configured to implement the functions of the method described in the third aspect.

[0050] In the tenth aspect, an embodiment of the present application provides a computer-readable storage medium, which is used to store computer programs or instructions. When the computer-readable storage medium is executed, the method described in any aspect of the first to third aspects and any implementation method thereof is implemented.

[0051] In the eleventh aspect, an embodiment of the present application further provides a computer program product comprising instructions, which, when executed on a computer, enables the method described in any of the above-mentioned first to third aspects and any of their implementation methods to be implemented.

[0052] The beneficial effects of the above-mentioned fifth to eleventh aspects and their implementation methods can refer to the beneficial effects of the first aspect or the third aspect and any of their implementation methods, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] FIG1 is a schematic diagram of the architecture of a communication system applicable to an embodiment of the present application;

[0054] FIG2 is a schematic diagram of the architecture of the multicast service provided in an embodiment of the present application;

[0055] FIG3 is a flow chart of a communication method according to an embodiment of the present application;

[0056] FIG4 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0057] FIG5 is another schematic diagram of the structure of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] The technical solution provided by the embodiment of the present application can reduce the occurrence of situations where terminal devices cannot receive multicast services, and try to ensure normal reception of multicast services by terminal devices.

[0059] The technical solutions provided by the embodiments of the present application can be applied to various types of wireless communication systems. For example, the method provided by the embodiments of the present application can be applied to communication systems related to the 3rd Generation Partnership Project (3GPP), such as long term evolution (LTE), the sixth generation (5G) mobile communication system (such as a new radio (NR) communication system), or can also be applied to other next generation mobile communication systems, such as the sixth generation (6G) communication system, or other similar communication systems. Other similar communication systems may include wireless fidelity (WIFI), vehicle to everything (V2X), internet of things (IoT) system, narrowband internet of things (NB-IoT) system, and the like.

[0060] Please refer to Figure 1, which shows a communication system applicable to an embodiment of the present application. The communication system includes a radio access network 100 and a core network 200. Optionally, the communication system may also include the Internet.

[0061] The wireless access network 100 may include at least one network device and at least one terminal device. For example, the wireless access network 100 includes two network devices 110a and 110b and terminal devices 120a through 120j. The network architecture shown in FIG1 is merely illustrative, and the number of terminal devices and / or network devices may be fewer or greater. The communication system described in the embodiments of the present application is intended to more clearly illustrate the technical solutions of the embodiments of the present application and does not constitute a limitation on the communication systems to which the embodiments of the present application are applicable. For example, the communication system may also include other devices, such as wireless relay devices and wireless backhaul devices, which are not shown in FIG1. ​​Persons skilled in the art will appreciate that as network architecture evolves, the technical solutions provided in the embodiments of the present application will also be applicable to similar technical problems. When applying the technical solutions of the embodiments of the present application to other communication systems, the devices, components, modules, etc. in the embodiments may be replaced with corresponding devices, components, and modules in other communication systems without limitation.

[0062] The network devices involved in the embodiments of the present application are mainly access network devices. Therefore, in the following text, unless otherwise specified, the "network devices" referred to are radio access network (RAN) devices, which can be referred to as access network devices for short. RAN can be a 3GPP-related cellular system, for example, a 5G mobile communication system, or a future-oriented evolution system (such as a 6G mobile communication system). RAN can also be an open access network (open RAN, O-RAN or ORAN), a cloud radio access network (cloud radio access network, CRAN), or a virtualized radio access network (virtualized RAN, vRAN), etc. RAN can also be a communication system that is a fusion of two or more of the above systems. RAN devices can also be referred to as RAN nodes, RAN entities, or access nodes, etc.

[0063] In one possible scenario, a RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a next-generation base station in a 6G mobile communication system, or a base station in a future mobile communication system. A RAN node can be a macro base station, a micro base station, an indoor station, a relay node, a donor node / host node, or a wireless controller. A RAN node can also be a server, a wearable device, a vehicle, or an onboard device. For example, a RAN node in V2X technology can be a roadside unit (RSU).

[0064] In another possible scenario, the RAN node may be a module or unit that performs part of the functions of the base station; or multiple RAN nodes collaborate to assist terminal devices in achieving wireless access, and different RAN nodes respectively perform part of the functions of the base station. For example, the RAN node may be a centralized unit (CU), a distributed unit (DU), or a radio unit (RU). The functions of the CU may be implemented by one entity, or by different entities. For example, the functions of the CU may be further divided, that is, the control plane and the user plane may be separated and implemented by different entities, namely the control plane CU entity (i.e., CU-control plane (CP) entity) and the user plane CU entity (i.e., CU-user plane (UP) entity). The CU-CP entity and the CU-UP entity may be coupled with the DU to jointly perform the functions of the RAN node. The CU and DU may be set separately, or may be included in the same network element, such as the baseband unit (BBU).

[0065] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0066] The CU and DU can be configured according to the protocol layer functions of the wireless network they implement: for example, the CU is configured to implement the functions of the packet data convergence protocol (PDCP) layer and the protocol layers above it (such as the RRC layer and / or the service data adaptation protocol (SDAP) layer, etc.); the DU is configured to implement the functions of the protocol layers below the PDCP layer (such as the radio link control (RLC), MAC layer, and / or physical (PHY) layer, etc.). For another example, the CU is configured to implement the functions of the protocol layers above the PDCP layer (such as the RRC layer and / or the SDAP layer), and the DU is configured to implement the functions of the PDCP layer and the protocol layers below it (such as the RLC layer, the MAC layer, and / or the PHY layer, etc.). For a detailed description of each of the above protocol layers, please refer to the relevant technical specifications of 3GPP or the technical specifications of other applicable communication protocols. The above division of the processing functions of the CU and DU according to the protocol layer is only an example, and can also be divided in other ways, which is not limited by this application. For example, in one design, the CU or DU can be further divided into parts with partial processing functions of the protocol layer. In one design, part of the RLC layer functions and functions of the protocol layers above the RLC layer are set in the CU, and the remaining functions of the RLC layer and functions of the protocol layers below the RLC layer are set in the DU.

[0067] In the embodiments of the present application, the device for implementing the functions of the network device can be the network device itself, or a device that can support the network device to implement the functions, such as a chip system or a combination of devices or components that can implement the functions of the network device, and the device can be installed in the network device. The embodiments of the present application do not limit the specific technology and specific device form used by the network device.

[0068] Terminal devices, also known as terminals, user equipment (UE), mobile stations, or mobile terminals, etc. In the embodiments of the present application, anything that can communicate data with a base station can be considered a terminal device. Terminal devices can be widely used in various scenarios, such as D2D communication, V2X communication, machine-type communication (MTC), IoT, virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearable, smart transportation, or smart city. For example, terminal devices can be: mobile phones, computers, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, robotic arms, cameras, robots, or smart home devices (such as TVs, air conditioners, vacuum cleaners, speakers, set-top boxes), relays, customer premise equipment (CPE), vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, etc. The embodiments of the present application do not limit the specific technology and specific device form used by the terminal.

[0069] The various terminal devices introduced above, if located on a vehicle (for example, placed / installed in a vehicle), can all be considered as on-board terminal devices. The on-board terminal device can be an on-board module, on-board module, on-board component, on-board chip or on-board unit built into the vehicle as one or more components or units, and the vehicle can implement the method of the present application through the built-in on-board module, on-board module, on-board component, on-board chip or on-board unit. The on-board terminal device can be a complete vehicle device, an on-board module, a vehicle, an on-board unit (OBU), an RSU, a telematics box (T-box), a chip or a system on chip (SOC), etc. The above chip or SOC can be installed in a vehicle, an OBU, an RSU or a T-box.

[0070] In the embodiments of the present application, the device for implementing the functions of the terminal device can be the terminal device itself, or a device capable of supporting the terminal device in implementing the functions, such as a chip system or a combination of devices or components capable of implementing the functions of the terminal device, which can be installed in the terminal device. The embodiments of the present application do not limit the specific technology and specific device form used by the terminal device.

[0071] Terminals can be divided into multiple types based on their capabilities. For example, there are low-complexity or low-capability (REDuced CAPability, REDCAP) terminal devices and non-low-complexity or non-reduced-capability terminal devices. Non-low-complexity or non-reduced-capability terminal devices, such as enhanced mobile broadband (eMBB) terminal devices, can also be called normal terminal devices or legacy terminal devices. REDCAP terminal devices can also be called (NR light, NRL) terminals, which are lightweight versions of terminal devices. Compared to legacy terminal devices, REDCAP terminal devices are less complex than legacy terminal devices in terms of bandwidth, power consumption, number of antennas, etc.

[0072] It can be considered that there are at least two types of terminal devices in the embodiments of the present application, for example, there are first-type terminal devices and second-type terminal devices. The first-type terminal devices are low-complexity terminal devices, and the second-type terminal devices are terminal devices other than low-complexity terminal devices. The difference between the first-type terminal devices and the second-type terminal devices includes at least one of the following:

[0073] 1. Different bandwidth capabilities. The maximum bandwidth supported by Category 1 terminal devices may be smaller than the maximum bandwidth supported by Category 2 terminal devices. For example, Category 2 terminal devices can support simultaneous communication with network devices using a maximum of 100 MHz of frequency resources on a single carrier, while Category 1 terminal devices can support simultaneous communication with network devices using a maximum of 20 MHz or less of frequency resources on a single carrier.

[0074] 2. The number of transmitting and receiving antennas is different. The antenna configuration of the first type of terminal device can be less than the antenna configuration of the second type of terminal device. For example, the minimum antenna configuration supported by the first type of terminal device can be less than the maximum antenna configuration supported by the second type of terminal device. For example, the first type of terminal device can support 2 receive and 1 transmit (2 receive antennas and 1 transmit antenna), or 1 receive and 1 transmit (1 receive antenna and 1 transmit antenna). The second type of terminal device can support 4 receive and 2 transmit (4 receive antennas and 2 transmit antennas).

[0075] 3. Different uplink maximum transmit power: The uplink maximum transmit power of the first type of terminal equipment is lower than that of the second type of terminal equipment.

[0076] 4. Different protocol versions. The first category of terminal devices can be considered to be NR version 17 (Release-17, Rel-17) or later versions of NR Rel-17. The second category of terminal devices can be NR version 15 (Release-15, Rel-15) or NR version 16 (Release-16, Rel-16) terminal devices.

[0077] 5. Different carrier aggregation (CA) capabilities. For example, the first category of terminal devices may not support CA, while the second category of terminal devices may support CA. Another example is that the second category of terminal devices and the first category of terminal devices both support CA, but the maximum number of cells in CA supported by the first category of terminal devices is less than the maximum number of cells in CA supported by the second category of terminal devices.

[0078] 6. Different frequency division duplex (FDD) capabilities. For example, the first type of terminal equipment only supports half-duplex FDD, while the second type of terminal equipment supports full-duplex FDD.

[0079] 7. The data processing time capabilities are different. For example, the minimum delay between the first type of terminal device receiving downlink data and sending feedback on the downlink data is greater than the minimum delay between the second type of terminal device receiving downlink data and sending feedback on the downlink data.

[0080] 8. Different processing capabilities. For example, the baseband processing capability of the first type of terminal device is lower than that of the second type of terminal device. Baseband processing capability may include at least one of the following: the maximum number of MIMO layers supported by the terminal device for data transmission, the number of HARQ processes supported by the terminal device, and the maximum transmission block size (TBS) supported by the terminal device.

[0081] 9. Different uplink and / or downlink peak transmission rates. Peak transmission rate refers to the maximum data transmission rate that a terminal device can achieve per unit time (e.g., per second). The uplink peak rate supported by a first-category terminal device may be lower than the uplink peak rate supported by a second-category terminal device, and / or the downlink peak rate supported by a first-category terminal device may be higher than the downlink peak rate supported by a second-category terminal device.

[0082] 10. Different buffer sizes. The buffer size can be understood as the total Layer 2 (L2) buffer size, which is defined as the sum of the bytes buffered in the RLC transmit window, receive and reordering windows, and the bytes buffered in the PDCP reordering window for all radio bearers. Alternatively, the buffer size can be understood as the total number of soft channel bits available for Hybrid Automatic Repeat reQuest (HARQ) processing.

[0083] Of course, the above are just examples, and there may be other differences between the first and second category terminal devices. In addition to the above differences, there may be other differences, such as the first category terminal device supporting coverage enhancement, while the second category terminal device does not support coverage enhancement; or the first category terminal device supporting small packet transmission, while the second category terminal device does not support small packet transmission. I will not illustrate each example one by one here.

[0084] The above describes the network structure applicable to the embodiments of the present application. The following introduces some technical terms involved in the embodiments of the present application.

[0085] 1)RRC status.

[0086] There are three RRC states for terminal devices: RRC connected state, RRC idle state, and RRC inactive state.

[0087] RRC connection state (or, can also be simply referred to as connection state. In this article, "connection state" and "RRC connection state" are the same concept and the two names can be interchanged): the terminal device establishes an RRC connection with the network and can transmit data.

[0088] RRC idle state (or, can also be simply referred to as idle state. In this article, "idle state" and "RRC idle state" are the same concept and the two names can be interchanged): the terminal device has not established an RRC connection with the network, and the base station has not stored the context of the terminal device. If the terminal device needs to enter the RRC connected state from the RRC idle state, it needs to initiate the RRC connection establishment process.

[0089] RRC inactive state (or, it can also be called RRC inactive state, or simply inactive state or inactive state. In this article, "deactivated state", "inactive state", "deactivated state", "deactivated state", "inactive state", "RRC inactive state" or "RRC deactivated state", etc., are the same concept, and these names can be interchanged): the terminal device previously entered the RRC connected state at the anchor base station, and then the anchor base station released the RRC connection, but the anchor base station saved the context of the terminal device. If the terminal device needs to enter the RRC connected state again from the RRC inactive state, it is necessary to initiate an RRC connection recovery process (or RRC connection re-establishment process) at the base station where it is currently stationed. Because the terminal device may be in a mobile state, the base station where the terminal device is currently stationed and the anchor base station of the terminal device may be the same base station or a different base station. The RRC recovery process has a shorter delay and smaller signaling overhead than the RRC establishment process. However, the base station needs to save the context of the terminal device, which will occupy the storage overhead of the base station.

[0090] 2) Cell selection and cell reselection

[0091] The terminal device determines whether a cell is suitable for access based on the S criterion (i.e., cell selection criterion) by evaluating parameters such as cell reception power and quality. When a terminal device in the RRC connected state receives an RRC release message, the terminal device enters the RRC idle state or RRC inactive state and performs cell selection to select a suitable / acceptable cell to reside in.

[0092] The cell reselection process is the process in which a terminal device in the RRC idle / inactive state measures the signal quality of the serving cell and the neighboring cell. If the signal quality of the serving cell is poor, while the signal quality of the neighboring cell is good, the terminal device will actively reselect a cell with a higher priority or better signal quality as the serving cell.

[0093] 3) The RRC recovery process includes the following steps 1 to 4:

[0094] Step 1: The network device sends an RRC Release message to the terminal device. Correspondingly, the terminal device receives the RRC Release message from the network device.

[0095] The RRC Release message is used to configure the terminal device to enter the suspended state, or the RRC Release message releases the terminal device in the RRC connected state to the RRC active state. For example, when the terminal device has no business, the network device can configure the terminal device to enter the RRC active state to save power consumption of the terminal device.

[0096] Step 2: The terminal device sends an RRC resume request to the network device, and the network device receives the RRC resume request from the terminal device. The RRC resume request is used to request the restoration of the RRC connection of the terminal device.

[0097] For example, when the terminal device has a service, the terminal device initiates a process of restoring the RRC connection to the network device. Among them, the RRC recovery request can be carried in a message in the random access process. For example, in a 4-step random access process, the RRC recovery request can be carried in message 3 (Msg3) in the random access process, or in other words, Msg3 can include the RRC recovery request in the RRC recovery process. For another example, in a 2-step random access process, the RRC recovery request can be carried in message A (MsgA) in the random access process, or in other words, MsgA can include the RRC recovery request in the RRC recovery process. Message A is also called message 1, abbreviated as Msg1. In an embodiment of the present application, MsgA can be replaced with Msg1 or Msg3.

[0098] Step 3: The network device sends an RRC resume message to the terminal device, and the terminal device receives the RRC resume message from the network device.

[0099] The RRC recovery message may instruct the terminal device to restore the RRC connection, or instruct the terminal device to restore the connection with the network device.

[0100] Step 4: The terminal device sends an RRC resume complete message to the network device, and the network device receives the RRC resume complete message from the terminal device.

[0101] After resuming communication with the network device, the terminal device may send an RRC recovery completion message to the network device to inform the network device that the terminal device has restored the RRC connection.

[0102] 4) Multicast services, i.e., services targeting multiple terminal devices, such as live broadcasts and scheduled program broadcasts. In LTE, multicast services are also called multimedia broadcast multicast services (MBMS), and in NR, multicast services are also called multicast / multicast broadcast services (MBS).

[0103] Multicast can be targeted at a specific group of terminal devices, and the terminal devices may need to go through a "group joining process". Broadcast can provide the same service and / or the same content data to all terminal devices in a geographical area at the same time. Broadcast can be targeted at all terminal devices in an area. Multicast can provide the same service and / or the same content data to a group of dedicated terminal devices at the same time (that is, not all terminal devices within the coverage area are authorized to receive data). The "multicast" in the embodiments of the present application can also be replaced by terms such as "multicast", and correspondingly, the multicast service can also be replaced by a multicast service, and the identifier of the multicast service can also be replaced by a multicast service identifier. The multicast service can include / be replaced by / be understood as: a multicast session, or an MBS session, or an MBS service, or a multicast, or a multicast data.

[0104] Please refer to Figure 2 for a schematic diagram of the multicast service architecture. As shown in Figure 2, a server can provide service data to a terminal device. The server sends the multicast service data to a core network device, which then transmits the multicast service session to a base station. Finally, the base station sends the multicast service data to at least one terminal device that receives the multicast service data. Figure 2 uses the example of at least one terminal device, including terminals 1 through 4.

[0105] The core network device can perform group management for multicast services, that is, manage the terminal devices joining or leaving the group. The protocol data unit (PDU) session established between the core network device and the base station introduces the MBS QoS flow. The core network device sends the multicast service data to the base station through the PDU session, and the base station then sends it to at least one terminal device. Among them, the base station can send the multicast service data to the terminal device through a dedicated bearer point-to-point (PTP) transmission method established for the terminal device; it can also send the multicast service data to the terminal device through a dedicated bearer established for the multicast service in a point-to-multipoint (PTM) transmission method. In addition, the base station can also switch between PTP transmission mode and PTM transmission mode.

[0106] For MBS services, core network equipment can send MBS service data to the base station via a common transmission channel, an MBS session. Each MBS session includes at least one MBS QoS flow. The base station sends MBS service data to at least one terminal device via an MBS radio bearer. The base station can send MBS service data to at least one terminal device using either PTM transmission (such as terminal devices 1 through 3 in Figure 2) or PTP transmission (such as terminal device 4 in Figure 2).

[0107] 5) Process of receiving multicast by terminal devices

[0108] The network device will broadcast the multicast configuration through a broadcast message, and the terminal device will receive the multicast according to the received multicast configuration. The multicast configuration may include one or more of the following: an identifier of the multicast session (such as a temporary mobile group identity (TMGI), a multicast MRB configuration, a group radio network temporary identity (G-RNTI) of the MCCH used to descramble the multicast, and multicast transport channel (MTCH) scheduling information, etc. Among them, MCCH refers specifically to multicast MCCH when providing multicast, and refers specifically to broadcast MCCH when providing broadcast, and can also cover both multicast MCCH and broadcast MCCH.

[0109] The MCCH configuration is contained in SIB24. When a terminal device receives a multicast, it reads SIB24 to obtain the MCCH configuration. It then reads the MCCH message based on the MCCH configuration, obtains the configuration information of the multicast session of interest from the MCCH, and receives the multicast based on the configuration information of the multicast session.

[0110] 6) "At least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these more than ten items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or plural.

[0111] Furthermore, unless otherwise indicated, ordinal numbers such as "first" and "second" in the embodiments of this application are used to distinguish between multiple objects and are not used to define the order, timing, priority, or importance of multiple objects. For example, the first category and the second category are only used to distinguish different types and do not indicate a difference in priority or importance between the two types.

[0112] In the embodiments of this application, "when," "if," and "if" all indicate that the device will perform a corresponding action under certain objective circumstances. They do not limit the time, do not require the device to perform a judgment action when implemented, and do not imply any other limitations. Unless otherwise specified, "if" and "if" are interchangeable, and "when" and "under the circumstances" are interchangeable. "When" and "if" are interchangeable.

[0113] Words such as "exemplary" or "for example" are used to indicate examples, illustrations, or illustrations. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0114] Typically, multicast services are provided to terminal devices in the RRC Connected state, and base stations and core network equipment maintain information about the terminal devices corresponding to the multicast service group. However, due to the limited capacity of network equipment, the number of terminal devices that can be supported by network equipment in the RRC Connected state is limited. Therefore, it is desirable to enable terminal devices in the RRC Inactive state to receive multicast services. In other words, multicast services can also be provided to terminal devices in the RRC Inactive state. In this way, when the network equipment is insufficient to support the connected terminal devices, some terminal devices can be transferred from the RRC Connected state to the RRC Inactive state.

[0115] For a terminal device that has joined a multicast session, the network device can send an RRC Release message to the terminal device to release the terminal device in the RRC connected state to the RRC Inactive state. The RRC Release message includes an instruction for the terminal device to enter the RRC inactive state to receive the multicast session. The network device can provide multicast configuration for the terminal device in the RRC inactive state in the following two ways. Method one, that is, sending the multicast configuration for the RRC inactive state terminal device to receive the multicast session to the terminal device through the RRC Release message. The multicast configuration for the RRC inactive state terminal device to receive the multicast session is also called the inactive state multicast configuration. Method two, similar to the above-mentioned method of providing the MBS broadcast configuration, sends the inactive state multicast configuration to the terminal device through the MCCH message.

[0116] If the terminal device has started receiving a multicast session in the RRC connected state, the network device can instruct the terminal device to use the multicast configuration for receiving the multicast session in the RRC connected state to receive the multicast session in the RRC inactive state, or the multicast configuration provided by the above two methods can be used to receive the multicast session in the RRC inactive state. The multicast configuration provided by the above two methods can be the same as or different from the multicast configuration of the RRC connected state. Using the above method one, the RRC Release message may include the MCCH configuration of the cell for the terminal device to obtain the MCCH message. The MCCH configuration can also be sent through cell public signaling. For example, the MCCH configuration can be carried by a system message (such as SIB24). Accordingly, the terminal device obtains the multicast MCCH configuration by reading the system message, and then reads the multicast MCCH message of the cell, and then obtains the multicast configuration through the MCCH message.

[0117] When a terminal device receiving multicast in the RRC inactive state reselects a cell, the terminal device can obtain the inactive state multicast configuration of the cell through the MCCH message. For a terminal device that is receiving or wants to receive an active multicast session, if the terminal device cannot obtain the PTM configuration of the multicast session on the target cell, the terminal device can trigger RRC connection recovery and request to enter the RRC connected state. For example, when the cell reselected by the terminal device only supports the provision of multicast sessions for terminal devices in the RRC connected state, and does not support the provision of multicast sessions for terminal devices in the RRC inactive state, the terminal device can request to enter the RRC connected state to receive the multicast session. For another example, when the cell reselected by the terminal device does not support the provision of the multicast session, the terminal device can request the network device to provide the multicast session after entering the RRC connected state.

[0118] However, for terminal devices with limited capabilities (such as REDCAP UE), when the terminal device enters the RRC inactive state, it may not be able to receive multicast services in certain cells due to limited capabilities. For example, the bandwidth of the multicast service scheduled in a certain cell exceeds the maximum receiving bandwidth of the terminal device, and the terminal device cannot receive the multicast service in that cell.

[0119] In order to solve the above technical problems, a solution is provided in an embodiment of the present application. In an embodiment of the present application, when the terminal device is in an RRC inactive state and cannot receive the multicast sent by the network device, it triggers a request to restore the RRC connection. The network device may decide whether to restore the connection of the terminal device based on the reason why the terminal device requests to restore the RRC connection and / or the type of the terminal device. For example, the network device may restore the RRC connection of the terminal device, so as to avoid the terminal device from missing the multicast. For another example, the network device may allow the terminal device to continue to be in an RRC inactive state and update the multicast configuration so that the terminal device can still receive the multicast service and save the power consumption of the terminal device.

[0120] The solution provided by the embodiments of the present application is described below with reference to the accompanying drawings.

[0121] In the following introduction, the communication method provided in the embodiment of the present application is applied to the network architecture shown in Figure 1 or Figure 2 as an example, and is executed by a network device and a terminal device as an example. The steps executed by the network device can be implemented by the RAN device itself, or by components in the RAN device (such as a baseband chip, or other processing units or processor modules). For example, the network device can be an access network device in Figure 1, such as network 110a, or it can be a chip (system) in the access network device in Figure 1. The steps executed by the terminal device can be implemented by the terminal device itself, or by components in the terminal device (such as chips, processing units, or processor modules). The terminal device can be the terminal device 120a shown in Figure 1, or it can be a chip (system) in the terminal device in Figure 1.

[0122] Please refer to Figure 3, which is a flow chart of the communication method provided in an embodiment of the present application. Figure 2 introduces the method from the perspective of the interaction between a network device and a terminal device. It should be understood that the communication method can also be implemented by other devices, such as a chip or a communication device with communication functions. It should be noted that the embodiment of the present application only takes execution by a network device and a terminal device as an example, and is not limited to a network device and a terminal device. For example, the embodiment of the present application can also be executed by more terminal devices. When more terminal devices are involved, the execution process of each terminal device in these more terminal devices is the same. In an embodiment of the present application, the terminal device is a low-complexity or low-capability terminal device, for example, the terminal device is a REDCAP terminal device, and the terminal device is configured to receive multicast services in the RRC inactive state, or the terminal device is configured to allow the reception of multicast services in the RRC inactive state.

[0123] As shown in FIG3 , the communication method according to the embodiment of the present application includes the following steps.

[0124] S301. The network device sends an RRC release message to the terminal device. Correspondingly, the terminal device receives the RRC release message from the network device.

[0125] The RRC release message is used to configure the terminal device to enter the RRC inactive state. In an embodiment of the present application, a terminal device in the RRC inactive state is allowed to receive multicast. Accordingly, the RRC release message may also instruct the terminal device to receive multicast in the RRC inactive state. For example, the RRC release message may include first indication information, and the first indication information may instruct the terminal device to receive multicast in the RRC inactive state.

[0126] Typically, when a terminal device is in an RRC inactive state, or when the terminal device is in an RRC inactive state but has no data to send, the network device instructs the terminal device to suspend monitoring the corresponding G-RNTI. In an embodiment of the present application, the network device does not instruct the terminal device to stop monitoring the corresponding G-RNTI for a multicast session joined by a terminal device in an RRC inactive state. In this way, the terminal device monitors the corresponding G-RNTI in the RRC inactive state to receive multicasts.

[0127] S302. When specific conditions are met, the terminal device sends an RRC recovery request to the network device. Correspondingly, the network device receives the RRC recovery request from the terminal device.

[0128] The RRC recovery request is used to request the restoration of the RRC connection. The specific condition refers to that the terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state or the terminal device cannot receive the multicast data sent by the network device in the RRC inactive state. Accordingly, S302 can also be replaced by: when the terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state or the terminal device cannot receive the multicast data sent by the network device in the RRC inactive state, the terminal device sends an RRC recovery request to the network device. The terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state, and it can also be replaced by the terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state. The terminal device cannot receive the multicast data sent by the network device in the RRC inactive state, and it can also be replaced by the terminal device cannot receive the multicast data sent by the network device in the RRC inactive state.

[0129] Alternatively, the specific condition refers to the terminal device being unable to read the multicast configuration sent by the network device in the RRC inactive state or being unable to receive multicast data sent by the network device in the RRC inactive state due to limited capabilities. Accordingly, S302 may also be replaced by: if the terminal device is unable to read the multicast configuration sent by the network device in the RRC inactive state or the terminal device is unable to receive multicast data sent by the network device in the RRC inactive state due to limited capabilities, the terminal device sends an RRC recovery request to the network device.

[0130] The term "capacity limited" can be absolute or relative. For example, in the case of the first and second category terminal devices, the first category terminal devices are considered to have limited capabilities compared to the second category terminal devices. Alternatively, if a certain capability of a terminal device falls below a certain threshold, the terminal device is considered to have limited capabilities. For example, if the maximum receive bandwidth of a terminal device is less than the bandwidth scheduled by the network device, the terminal device is considered to have limited bandwidth capabilities.

[0131] In the embodiments of the present application, the specific conditions include one or more of the following conditions, which are introduced below.

[0132] Condition 1: The terminal device cannot obtain the multicast configuration, or the terminal device cannot obtain the multicast configuration due to limited capabilities.

[0133] As mentioned above, SIB24 contains the configuration information required to receive MCCH, such as MCCH frequency domain location and bandwidth information and MCCH time domain location information. The terminal device can obtain MCCH messages based on the MCCH configuration information, and then obtain the configuration required to receive multicast scheduling from the MCCH message.

[0134] If the terminal device cannot read SIB24, it is considered that the terminal device cannot obtain the multicast configuration. Accordingly, Condition 1 can be replaced with "The terminal device cannot read SIB24." Alternatively, Condition 1 includes Condition 11: The terminal device cannot read SIB24. From the perspective of limited capabilities, Condition 1 can be replaced with "The terminal device cannot read SIB24 due to limited capabilities." Alternatively, Condition 1 includes Condition 12: The terminal device cannot read SIB24 due to limited capabilities.

[0135] There are multiple situations in which a terminal device cannot read SIB24. For example, when the bandwidth of SIB24 exceeds the maximum receiving bandwidth of the terminal device, or the receiving bandwidth required to read SIB24 exceeds the maximum receiving bandwidth of the terminal device, the terminal device cannot read the system message block SIB24 due to limited capabilities. From this perspective, condition 1 can be replaced by: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device. Alternatively, condition 1 includes condition 13: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device.

[0136] Similarly, if the terminal device can read SIB24 but cannot successfully receive the MCCH message according to the MCCH configuration information of SIB24, it can also be considered that the terminal device cannot obtain the multicast configuration. Accordingly, condition 1 can be replaced with the terminal device being unable to receive MCCH according to SIB24. Alternatively, condition 1 includes condition 14: the terminal device is unable to receive MCCH according to SIB24. From the perspective of limited capabilities, condition 1 can be replaced with the terminal device being unable to receive MCCH according to SIB24 due to limited capabilities. Alternatively, condition 1 includes condition 15: the terminal device is unable to receive MCCH according to SIB24 due to limited capabilities.

[0137] There are many situations in which the terminal device cannot receive MCCH according to SIB24. For example, when the reception bandwidth of the MCCH included in the scheduling SIB24 exceeds the maximum reception bandwidth of the terminal device, or the reception bandwidth of the MCCH included in the reading SIB24 exceeds the maximum reception bandwidth of the terminal device, the terminal device cannot receive MCCH according to SIB24 due to limited capabilities. From this perspective, condition 1 can be replaced by: the bandwidth required to receive the MCCH included in SIB24 exceeds the maximum reception bandwidth of the terminal device. Alternatively, condition 1 includes condition 16: the bandwidth required to receive the MCCH included in SIB24 exceeds the maximum reception bandwidth of the terminal device.

[0138] Condition 2: The terminal device cannot successfully receive the multicast data, or the terminal device cannot successfully receive the multicast data due to limited capabilities.

[0139] When the transmission rate / transmission bandwidth used by the scheduled multicast data exceeds the maximum processing capability of the terminal device, the terminal device cannot successfully receive the multicast data. For example, when the number of PRBs used by the scheduled multicast data exceeds the maximum number of PRBs that the terminal device can process. For another example, the rate of the scheduled multicast data exceeds the maximum receiving rate that the terminal device can withstand. From this perspective, Condition 2 can also be replaced by: the transmission rate / transmission bandwidth used by the scheduled multicast data exceeds the maximum processing capability of the terminal device, or the number of PRBs used by the scheduled multicast data exceeds the maximum number of PRBs that the terminal device can process. Alternatively, Condition 2 includes Condition 21: the transmission rate / transmission bandwidth used by the scheduled multicast data exceeds the maximum processing capability of the terminal device, or the number of PRBs used by the scheduled multicast data exceeds the maximum number of PRBs that the terminal device can process, or the rate of the scheduled multicast data exceeds the maximum receiving rate that the terminal device can withstand.

[0140] When condition 1 or condition 2 is met, or any condition from conditions 11 to 16 is met, or condition 21 is met, the terminal device sends an RRC recovery request to the network device.

[0141] In order to make the network device clear about the reason why the terminal device initiated the RRC recovery request, the RRC recovery request also includes the reason why the terminal device initiated the RRC recovery request. For example, the RRC recovery request may include second indication information, and the second indication information may indicate the reason why the terminal device initiated the RRC connection recovery request. In an embodiment of the present application, the reason why the terminal device initiated the RRC connection recovery request may be any of the following first to ninth reasons. Among them, one reason corresponds to one or more of the aforementioned conditions (such as condition 1 or condition 2, etc.).

[0142] The first reason: The terminal device cannot read the multicast configuration sent by the network device in the RRC inactive state.

[0143] The second reason: the terminal device cannot receive multicast data sent by the network device in the RRC inactive state.

[0144] The third reason: the terminal device cannot obtain the multicast configuration, or the terminal device cannot obtain the multicast configuration due to limited capabilities.

[0145] Fourth reason: the terminal device cannot read SIB24, or the terminal device cannot read SIB24 due to limited capabilities.

[0146] Fifth reason: The bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device.

[0147] The sixth reason: the receiving bandwidth required to receive MCCH exceeds the maximum receiving bandwidth of the terminal device.

[0148] Seventh reason: The terminal device cannot successfully receive the multicast data, or the terminal device cannot successfully receive the multicast data due to limited capabilities.

[0149] Reason 8: The scheduling rate / transmission rate / transmission bandwidth of the multicast data exceeds the maximum receiving capability / processing capability of the terminal device.

[0150] Ninth reason: The number of PRBs used for scheduling multicast data exceeds the maximum number of PRBs that the terminal device can receive / process.

[0151] A cause value may be set corresponding to each of the above causes, and the cause values ​​corresponding to the nine causes may be newly defined values. The RRC recovery request may include a cause value corresponding to the reason why the terminal device requests to restore the RRC connection.

[0152] Optionally, the cause value carried by the RRC recovery request initiated by the terminal device to the network device may be a currently defined cause value, for example, the cause value may be MT-Access. In this case, when the network device receives the RRC recovery request and determines that the terminal device is in an RRC inactive state, the network device may determine whether the terminal device has limited capabilities. If the terminal device has limited capabilities, the network device may determine that the reason why the terminal device initiated the RRC recovery connection is that it is unable to receive the multicast configuration sent by the network device in the RRC inactive state due to limited capabilities, or it is unable to receive the multicast data sent by the network device in the RRC inactive state due to limited capabilities.

[0153] Optionally, the terminal device may send third indication information to the network device, where the third indication information may be used to indicate that the terminal device's capabilities are limited. Whether the terminal device's capabilities are limited can be characterized by the terminal device's type. For example, if the terminal device is a Class I terminal device, then the terminal device's capabilities are limited. Therefore, the third indication information may also be used to indicate the terminal device's type. Thus, the network device may determine whether the terminal device's capabilities are limited based on the third indication information.

[0154] The third indication information may be carried in a message during the random access process. For example, the third indication information may be carried in message 3 as the payload of the MAC protocol data unit (PDU) of message 3. Optionally, the third indication information is carried in a reserved bit or LCID in the MAC header of message 3. For another example, the third indication information may be implemented through message 1, or the third indication information may be message 1, for example, the third indication information may be represented by a special random access resource or a special random access preamble. For example, the random access resource is the first resource, and the third indication information / message 1 sent on the first resource indicates that the terminal device capability is limited. Alternatively, if message 1 (i.e., the random access preamble) is a specific sequence, then it indicates that the terminal device capability is limited.

[0155] The network device receives the RRC recovery request from the terminal device and may decide whether to restore the RRC connection of the terminal device based on the reason for the terminal device initiating the RRC recovery request. If the network device determines to restore the RRC connection of the terminal device, then S303A may be executed; if the network device determines to maintain the terminal device in the RRC inactive state, then S303B may be executed.

[0156] S303A: The network device sends an RRC recovery message to the terminal device. Correspondingly, the terminal device receives the RRC recovery message from the network device.

[0157] If the network device determines that the reason a terminal device sent an RRC resume request is due to an inability to obtain a multicast configuration sent by the network device in an RRC inactive state or an inability to receive a multicast session sent by the network device in an RRC inactive state, the network device may determine to have the terminal device resume its RRC connection. For example, the network device may send an RRC resume message to the terminal device to resume its RRC connection. In this case, the network device may configure a multicast configuration for the terminal device via dedicated signaling. This multicast configuration is independent of the multicast configurations of other terminal devices, thereby reducing the impact on the performance of other terminal devices.

[0158] The network device may determine the reason why the terminal device sends the RRC recovery request based on the cause value carried by the RRC recovery request, or may determine the reason why the terminal device sends the RRC recovery request based on the third indication information. Alternatively, the network device may determine the reason why the terminal device sends the RRC recovery request based on the cause value carried by the RRC recovery request and the third indication information.

[0159] S303B: The network device sends an RRC release message to the terminal device and updates the multicast configuration.

[0160] The network device determines that the terminal device cannot obtain the multicast configuration sent by the network device in the RRC inactive state or cannot receive the multicast session sent by the network device in the RRC inactive state, and may also determine to keep the terminal device in the RRC inactive state. For example, the network device may send an RRC release message to the terminal device, and the RRC release message may include indication information, which instructs the terminal device to continue to receive multicast in the RRC inactive state according to the latest multicast configuration.

[0161] In order to allow a terminal device in an RRC inactive state to successfully receive multicast sent by a network device, the network device may update the multicast configuration. The multicast configuration is configured according to the actual capabilities of the terminal device, or the multicast configuration is configured for a terminal device in an RRC inactive state to receive multicast. Updating the multicast configuration includes one or more of the following: updating the multicast configuration information, updating the multicast scheduling method, or updating the multicast scheduling rate. Accordingly, the terminal device receives an RRC release message, continues to stay in the RRC inactive state, and re-acquires the current multicast configuration from the network device, and receives multicast according to the acquired multicast configuration. It can be understood that the terminal device re-acquires the current multicast configuration, which is the multicast configuration updated by the network device. In this way, the terminal device does not need to establish an RRC connection and can continue to receive multicast in the RRC inactive state. On the one hand, it can reduce the number of connected terminal devices and thus alleviate network congestion. On the other hand, it can save power consumption of the terminal device.

[0162] In one implementation, the network device may update the multicast configuration via an RRC release message. For example, the RRC release message includes a multicast configuration for receiving a multicast session by a terminal device in the RRC inactive state. The terminal device receives the RRC release message, obtains the multicast configuration in the RRC release message, and receives multicast messages sent by the network device in the RRC inactive state based on the multicast configuration.

[0163] In another implementation, the network device may update the multicast configuration by broadcasting. For example, the network device may broadcast SIB1, the SIB1 includes SIB24, the SIB24 includes MCCH configuration, the MCCH configuration includes an MCCH message, and the MCCH message includes the multicast configuration.

[0164] Optionally, the terminal device has started receiving multicast in the RRC connected state, and the network device can instruct the terminal device to use the multicast configuration for receiving the multicast session in the RRC connected state to receive the multicast in the RRC inactive state.

[0165] It should be noted that S303A and S303B are two situations (ie, situation one and situation two). If S303A is executed, S303B does not need to be executed; if S303B is executed, S303A does not need to be executed.

[0166] In the communication method shown in Figure 3, for a terminal device configured / permitted to receive multicast in the RRC inactive state, if the terminal device is unable to receive multicast data sent by the network device, it can trigger a request to restore the RRC connection. For example, if the scheduling rate or scheduling method of multicast data exceeds the terminal device's processing capacity, meaning it is unable to receive the network device's multicast data, the terminal device can request to restore the RRC connection. The network device can determine whether to restore the terminal device's connection based on the reason for the terminal device's request to restore the RRC connection and / or the type of terminal device. On the one hand, the network device can restore the terminal device's RRC connection, allowing the terminal device to enter the RRC connected state and receive multicast. Compared to a terminal device currently in the RRC inactive state, where the terminal device does not actively trigger an RRC restoration request due to an inability to read the multicast configuration sent by the network device or to receive multicast data sent by the network device, this can reduce the occurrence of terminal devices being unable to receive multicast services, thereby minimizing the risk of the terminal device being unable to receive multicast services. On the other hand, the network device can allow the terminal device to continue receiving multicast services in the RRC inactive state. For example, the network device sends an RRC release message and updates the multicast configuration information, multicast scheduling mode or scheduling rate to ensure that the terminal device can successfully receive multicast data. This can reduce the number of connected terminal devices, thereby alleviating network congestion, and save power consumption of the terminal devices.

[0167] In the embodiments provided above, the methods provided in the embodiments of the present application are introduced by taking the execution of network devices and terminal devices as examples. In the present application, each embodiment can be implemented independently or in combination based on certain internal connections; in each embodiment, different implementation methods can be implemented in combination or independently. In order to implement the various functions of the methods provided in the embodiments of the present application, the steps performed by the terminal device can be implemented by different functional entities that constitute the terminal device. The steps performed by the network device can be implemented by different functional entities that constitute the network device. For example, the network device can be a CU-DU architecture, the CU can generate an RRC recovery message, and the DU can send an RRC recovery message. In order to implement the various functions of the methods provided in the embodiments of the present application, the terminal device and the network device can include hardware structures and / or software modules, and implement the above functions in the form of hardware structures, software modules, or hardware structures plus software modules. Whether one of the above functions is executed in the form of hardware structures, software modules, or hardware structures plus software modules depends on the specific application and design constraints of the technical solution.

[0168] Based on the same inventive concept as the method embodiment, the present embodiment provides a communication device. The following describes the communication device used to implement the above method in the present embodiment in conjunction with the accompanying drawings. The above content can be used in subsequent embodiments, and repeated content will not be repeated.

[0169] Figure 4 is a schematic block diagram of a communication device 400 provided in an embodiment of the present application. The communication device 400 may be a terminal device or a network device in the aforementioned embodiments. For example, the communication device 400 may be the terminal device in Figure 1 ; or, the communication device 400 may be a chip (system) in the terminal device; or, the communication device 400 may be a software module in the terminal device. The communication device 400 may implement the functions or steps implemented by the terminal device in the aforementioned method embodiments. For another example, the communication device 400 may be the network device in Figure 1 ; or, the communication device 400 may be a chip (system) in the network device; or, the communication device 400 may be a software module in the network device. The communication device 400 may implement the functions or steps implemented by the network device in the aforementioned method embodiments. The communication device 400 may include a processing module 410 and a transceiver module 420. Optionally, it may also include a storage module, which may be used to store instructions (code or programs) and / or data. The storage module may be, for example, a memory. The processing module 410 and the transceiver module 420 may be coupled to the storage module. For example, the processing module 410 can read instructions (codes or programs) and / or data in the storage module to implement the corresponding method. When the communication device 400 is a chip in a terminal device or a network device, the storage module can be a storage module in the chip, such as a register, a cache, etc. For example, the storage module can also be a storage module outside the chip in the terminal device or the network device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc. The above-mentioned units can be set independently or partially or fully integrated.

[0170] The processing module 410 can be a processor or controller, for example, a general-purpose central processing unit (CPU), a general-purpose processor, a digital signal processing (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It can implement or execute the various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, for example, including a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and so on. The transceiver module 420 is a transceiver, an interface circuit, a bus, a pin or other possible communication interface for receiving signals from other devices. For example, when the device is implemented in the form of a chip, the transceiver module 420 is an interface circuit for the chip to receive signals from other chips or devices, or it is an interface circuit for the chip to send signals to other chips or devices.

[0171] In one implementation, the communication device 400 can implement the behaviors and functions of the terminal device in the above-mentioned method embodiment. The communication device 400 can be a terminal device, or a component (such as a chip or circuit) used in a terminal device, or a chip or chipset in a network device, or a part of a chip used to perform the functions of the relevant method, or a software module capable of implementing the method performed by the terminal device in the above-mentioned method (as shown in Figure 3), without limitation. For details, please refer to the relevant content of the above-mentioned method embodiment, which will not be repeated here.

[0172] For example, the transceiver module 420 is configured to receive an RRC release message, the RRC release message including first indication information, the first indication information indicating that the terminal device is receiving multicast in the RRC inactive state; when the communication device 400 is unable to read the multicast configuration sent by the network device in the RRC inactive state or is unable to receive multicast data sent by the network device in the RRC inactive state, it sends an RRC recovery request; and receives the RRC recovery message, or receives the RRC release message, and receives multicast in the RRC inactive state. The processing module 410 is configured to determine that it is unable to read the multicast configuration sent by the network device in the RRC inactive state or is unable to receive multicast data sent by the network device in the RRC inactive state.

[0173] As an optional implementation, the transceiver module 420 receives the multicast in the RRC inactive state, including: the transceiver module 420 receives the multicast configuration, and receives the multicast according to the multicast configuration.

[0174] As an optional implementation, the inability to read the multicast configuration sent by the network device in the RRC inactive state includes: being unable to obtain the multicast configuration due to limited capabilities, such as being unable to read SIB24 due to limited capabilities or being unable to receive MCCH according to SIB24 due to limited capabilities.

[0175] As an optional implementation, the system information block SIB24 cannot be read due to limited capabilities, including: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device.

[0176] As an optional implementation, the MCCH cannot be read according to SIB24 due to limited capabilities, including: the bandwidth required to receive the MCCH included in SIB24 exceeds the maximum receiving bandwidth of the terminal device.

[0177] As an optional implementation, the inability to receive multicast data sent by a network device in an RRC inactive state includes the inability to successfully receive the multicast data due to limited capabilities. For example, the number of physical resource blocks (PRBs) used to schedule the multicast data exceeds the maximum number of PRBs that the terminal device can process.

[0178] As an optional implementation method, the RRC recovery request includes second indication information, and the second indication information is used to indicate the reason why the terminal device initiates the RRC connection recovery request.

[0179] As an optional implementation manner: the transceiver module 420 is further configured to send third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

[0180] As an optional implementation manner, the third indication information is carried in message 1 or message 3 in the random access process.

[0181] In one implementation, the communication device 400 can implement the behaviors and functions of the network device in the above-mentioned method embodiment. The communication device 400 can be a network device, or a component (such as a chip or circuit) used in a network device, or a chip or chipset in a terminal device, or a part of a chip used to perform the functions of the relevant method, or a software module capable of implementing the method performed by the network device in the above-mentioned method (such as the method shown in Figure 3), without limitation. For details, please refer to the relevant content of the above-mentioned method embodiment, which will not be repeated here.

[0182] For example, the transceiver module 420 is configured to send an RRC release message to a terminal device, the RRC release message including first indication information, the first indication information instructing the terminal device to receive multicast in an RRC inactive state; and receive an RRC resume request from the terminal device. The processing module 410 is configured to determine that the reason for the RRC resume request is that the terminal device is unable to read the multicast configuration sent by the communication device 400 in the RRC inactive state or is unable to receive multicast data sent by the communication device 400 in the RRC inactive state. The transceiver module 420 is further configured to send an RRC resume message to the terminal device, or send an RRC release message to the terminal device, and update the multicast configuration.

[0183] As an optional implementation method, the RRC recovery request includes second indication information, and the second indication information is used to indicate the reason why the terminal device initiates the RRC connection recovery request.

[0184] As an optional implementation method, the reasons why the terminal device initiates an RRC connection recovery request include: being unable to obtain multicast configuration due to limited capabilities; or being unable to successfully receive multicast data due to limited capabilities.

[0185] As an optional implementation, the inability to obtain the multicast configuration due to limited capabilities includes: the inability to read SIB24 due to limited capabilities; or the inability to receive the MCCH according to SIB24 due to limited capabilities.

[0186] As an optional implementation, the inability to read SIB24 due to capability limitations includes: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device. Alternatively, the inability to receive MCCH according to SIB24 due to capability limitations includes: the bandwidth required to receive MCCH included in SIB24 exceeds the maximum receiving bandwidth of the terminal device.

[0187] As an optional implementation, the inability to successfully receive multicast data due to limited capabilities includes: the number of PRBs used for scheduling multicast data exceeds the maximum number of PRBs that the terminal device can process.

[0188] As an optional implementation, the transceiver module 420 is further configured to receive third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

[0189] As an optional implementation manner, the third indication information is carried in message 1 or message 3 in the random access process.

[0190] For another example, the transceiver module 420 is used to send an RRC release message to a terminal device, receive an RRC recovery request from the terminal device, and when it is determined that the capability of the terminal device is limited, send an RRC recovery message to the terminal device, or send an RRC release message to the terminal device and update the multicast configuration. The RRC release message includes first indication information, and the first indication information instructs the terminal device to receive multicast in an RRC inactive state. The processing module 410 is used to determine that the capability of the terminal device is limited.

[0191] As an optional implementation, the transceiver module 420 is further configured to receive third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

[0192] As an optional implementation manner, the third indication information is carried in message 1 or message 3 in the random access process.

[0193] When the communication device 400 is a chip-type device or circuit, the transceiver module may be an input / output circuit and / or a communication interface; the processing module may be an integrated processor or microprocessor or integrated circuit.

[0194] Figure 5 is a schematic block diagram of a communication device 500 provided in an embodiment of the present application. The communication device 500 can be a terminal device or a network device in the above-mentioned embodiment. For example, the communication device 500 can be the terminal device in Figure 1 or a chip (system) in the terminal device. In the embodiment of the present application, the chip system can be composed of a chip, or it can include a chip and other discrete devices. For specific functions, please refer to the description in the above-mentioned method embodiment. For another example, the communication device 500 can be the network device in Figure 1 or a chip (system) in the network device. In the embodiment of the present application, the chip system can be composed of a chip, or it can include a chip and other discrete devices. For specific functions, please refer to the description in the above-mentioned method embodiment.

[0195] The communication device 500 includes one or more processors 501, which are used to implement or support the communication device 500 to implement the functions of the terminal device or network device in the method provided in the embodiment of the present application. Please refer to the detailed description in the method example for details, which will not be repeated here. The processor 501 can also be called a processing unit or processing module, which can implement certain control functions. The processor 501 can be a general-purpose processor or a dedicated processor. For example, it includes: a baseband processor, a central processing unit, an application processor, a modem processor, a graphics processor, an image signal processor, a digital signal processor, a video codec processor, a controller, a memory, and / or a neural network processor. The baseband processor can be used to process communication protocols and communication data. The central processing unit can be used to control the communication device 500 (such as a network device or terminal device), execute software programs and / or process data. Different processors can be independent devices or integrated into one or more processors, for example, integrated into one or more dedicated integrated circuits.

[0196] In one design, the processor 501 may include a program 503 (sometimes also referred to as code or instructions), which may be executed on the processor 501 to cause the communication device 500 to perform the methods described in the following embodiments. In another possible design, the communication device 500 includes circuitry (not shown in FIG5 ) configured to implement the functions of the terminal device or network device in the above embodiments.

[0197] In one design, the communication device 500 may include one or more memories 502 on which a program 504 (sometimes also referred to as code or instructions) is stored. The program 504 can be run on the processor 501 so that the communication device 500 performs the method described in the above method embodiment.

[0198] In one design, the processor 501 and / or the memory 502 may include an artificial intelligence (AI) module 507 and an AI module 508, each configured to implement AI-related functions. The AI ​​module may be implemented using software, hardware, or a combination of software and hardware. For example, the AI ​​module may include a RAN intelligent controller (RIC) module. For example, the AI ​​module may be a near real-time RIC or a non-real-time RIC.

[0199] In a possible design, data may also be stored in the processor 501 and / or the memory 502. The processor and the memory may be provided separately or integrated together.

[0200] In one possible design, the communication device 500 may further include a transceiver 505 and / or an antenna 506. The processor 501 may also be sometimes referred to as a processing unit, and controls the communication device 500. The transceiver 505 may also be sometimes referred to as a transceiver unit, a transceiver, a transceiver circuit, or a transceiver, and is configured to implement the transceiver functions of the communication device 500 through the antenna 506.

[0201] In one possible design, the communication device 500 may further include one or more of the following components: a wireless communication module, an audio module, an external memory interface, an internal memory, a universal serial bus (USB) interface, a power management module, an antenna, a speaker, a microphone, an input / output module, a sensor module, a motor, a camera, or a display screen, etc. It will be appreciated that in some embodiments, the communication device 500 may include more or fewer components, or some components may be integrated or separated. These components may be implemented in hardware, software, or a combination of software and hardware.

[0202] The communication device in the above embodiments can be a terminal device, a circuit, a chip used in a terminal device, or other devices or components combined with the above terminal devices. Alternatively, the communication device in the above embodiments can be a network device, a circuit, a chip used in a network device, or other devices or components combined with the above network devices. When the communication device is a terminal device or a network device, the transceiver module can be a transceiver, which can include an antenna and a radio frequency circuit, etc., and the processing module can be a processor, such as a CPU. When the communication device is a system-on-chip, the communication device can be an FPGA, a dedicated ASIC, a system-on-chip (SoC), a CPU, a network processor (NP), a DSP, a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated circuit. The processing module can be the processor of the system-on-chip. The transceiver module or communication interface can be the input / output interface or interface circuit of the system-on-chip. For example, the interface circuit can be a code / data read / write interface circuit. The interface circuit can be used to receive code instructions (the code instructions are stored in a memory and can be read directly from the memory or read from the memory via another device) and transmit them to the processor; the processor can be used to execute the code instructions to perform the method in the above method embodiment. For example, the interface circuit can also be a signal transmission interface circuit between a communication processor and a transceiver.

[0203] The present application also provides a communication system including at least one terminal device and at least one network device. The terminal device is configured to implement the functions associated with the method shown in FIG. 3 , and the network device is configured to implement the functions associated with the method shown in FIG. For details, please refer to the relevant description in the above method embodiment and will not be repeated here.

[0204] An embodiment of the present application also provides a computer-readable storage medium, including instructions, which, when executed on a computer, enables the computer to execute the method executed by the terminal device or network device in the communication method shown in Figure 3 above.

[0205] A computer program product is also provided in an embodiment of the present application, including computer program code. When the computer program code is executed, the computer executes the method executed by the terminal device or network device in the communication method shown in Figure 3 above.

[0206] An embodiment of the present application provides a chip system, which includes a processor and may also include a memory, for implementing the functions of the terminal device or network device in the communication method shown in Figure 3. The chip system can be composed of a chip or include a chip and other discrete devices.

[0207] To implement the functions of the communication device shown in Figures 4 and 5 above, embodiments of the present application further provide a chip including a processor for supporting the communication device in implementing the functions of the terminal device or network device in the above method embodiments. In one possible design, the chip is connected to or includes a memory, which is used to store computer programs, instructions, and data necessary for the communication device.

[0208] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean 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 the present application.

[0209] Those skilled in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0210] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0211] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0212] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0213] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the part that essentially contributes to the technical solution of the present application or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks or optical disks.

[0214] Obviously, those skilled in the art may make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include these modifications and variations.

Claims

1. A communication method, characterized in that: include: Receiving a radio resource control (RRC) release message, where the RRC release message includes first indication information, where the first indication information instructs the terminal device to receive multicast in an RRC inactive state; When the terminal device is unable to read the multicast configuration sent by the network device in the RRC inactive state or is unable to receive the multicast data sent by the network device in the RRC inactive state, an RRC recovery request is sent; Receive an RRC resume message, or receive an RRC release message, and receive multicast in an RRC inactive state.

2. The method according to claim 1, wherein Receiving multicast in RRC inactive state includes: Receive multicast configuration; The multicast is received according to the multicast configuration.

3. The method according to claim 1 or 2, wherein: Unable to read multicast configuration sent by network devices in RRC inactive state, including: unable to obtain multicast configuration due to limited capabilities; The inability to receive multicast data sent by the network device in the RRC inactive state includes: the inability to successfully receive multicast data due to limited capabilities.

4. The method according to claim 3, wherein The inability to obtain multicast configuration due to limited capabilities includes: Unable to read the system message block SIB24 due to limited capabilities; or, Due to limited capabilities, the multicast control channel MCCH cannot be received according to SIB24.

5. The method according to claim 4, wherein The system information block SIB24 cannot be read due to limited capabilities, including: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device; The inability to receive MCCH according to SIB24 due to limited capabilities includes: the bandwidth required to receive MCCH included in SIB24 exceeds the maximum receiving bandwidth of the terminal device.

6. The method according to claim 3, wherein Unable to successfully receive multicast data due to limited capabilities, including: The number of physical resource blocks (PRBs) used to schedule the multicast data exceeds the maximum number of PRBs that the terminal device can process.

7. The method according to any one of claims 1 to 6, wherein The RRC recovery request includes second indication information, and the second indication information is used to indicate the reason why the terminal device initiates the RRC connection recovery request.

8. The method according to any one of claims 1 to 7, wherein The method further comprises: Send third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

9. The method according to claim 8, wherein The third indication information is carried in message 1 or message 3 during the random access process.

10. A communication method, characterized in that: include: Sending a radio resource control (RRC) release message to a terminal device, where the RRC release message includes first indication information, where the first indication information instructs the terminal device to receive multicast in an RRC inactive state; Receiving an RRC recovery request from the terminal device; Determining that the reason for the RRC recovery request is that the terminal device is unable to read the multicast configuration sent by the network device in the RRC inactive state or is unable to receive multicast data sent by the network device in the RRC inactive state; Send an RRC resume message, or send an RRC release message, and update the multicast configuration.

11. The method according to claim 10, wherein The RRC recovery request includes second indication information, and the second indication information is used to indicate the reason why the terminal device initiates the RRC connection recovery request.

12. The method according to claim 10 or 11, wherein: The reason why the terminal device requests to restore the RRC connection includes: Unable to obtain multicast configuration due to limited capabilities; or Unable to successfully receive multicast data due to limited capabilities.

13. The method according to claim 12, wherein: The inability to obtain multicast configuration due to limited capabilities includes: Unable to read the system message block SIB24 due to limited capabilities; or, Due to limited capabilities, the multicast control channel MCCH cannot be received according to SIB24.

14. The method according to claim 13, wherein The system information block SIB24 cannot be read due to limited capabilities, including: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device; or The MCCH cannot be received according to SIB24 due to limited capabilities, including: the receiving bandwidth of the MCCH required for receiving SIB24 exceeds the maximum receiving bandwidth of the terminal device.

15. The method according to claim 12, wherein Unable to successfully receive multicast data due to limited capabilities, including: The number of physical resource blocks (PRBs) used to schedule the multicast data exceeds the maximum number of PRBs that the terminal device can process.

16. The method according to any one of claims 10 to 15, wherein: The method further comprises: Receive third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

17. The method according to claim 16, wherein The third indication information is carried in message 1 or message 3 during the random access process.

18. A communication method, characterized in that: include: Sending a radio resource control (RRC) release message to a terminal device, where the RRC release message includes first indication information, where the first indication information instructs the terminal device to receive multicast in an RRC inactive state; Receiving an RRC recovery request from the terminal device; determining that the capabilities of the terminal device are limited; Send an RRC resume message, or send an RRC release message, and update the multicast configuration.

19. The method according to claim 18, wherein The method further comprises: Receive third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

20. The method according to claim 19, wherein The third indication information is carried in message 1 or message 3 during the random access process.

21. A communication device, characterized in that: include: A transceiver module, configured to receive a radio resource control (RRC) release message, and when unable to read a multicast configuration sent by a network device in an RRC inactive state or unable to receive multicast data sent by a network device in an RRC inactive state, send an RRC recovery request; and receive an RRC recovery message, or receive an RRC release message, and receive multicast in an RRC inactive state; wherein the RRC release message includes first indication information, and the first indication information instructs the communication device to receive multicast in an RRC inactive state; A processing module is used to determine the RRC recovery request.

22. The device according to claim 21, wherein When receiving multicast in the RRC inactive state, the transceiver module is specifically used to: receive multicast configuration, and receive multicast according to the multicast configuration.

23. The device according to claim 21 or 22, characterized in that Unable to read multicast configuration sent by network devices in RRC inactive state, including: unable to obtain multicast configuration due to limited capabilities; The inability to receive multicast data sent by the network device in the RRC inactive state includes: the inability to successfully receive multicast data due to limited capabilities.

24. The device according to claim 23, wherein The inability to obtain multicast configuration due to limited capabilities includes: Unable to read the system message block SIB24 due to limited capabilities; or, Due to limited capabilities, the multicast control channel MCCH cannot be received according to SIB24.

25. The device according to claim 24, wherein The inability to read the system information block SIB24 due to limited capabilities includes: the bandwidth required to receive the SIB24 exceeds the maximum receiving bandwidth of the communication device; The inability to receive the MCCH according to SIB24 due to limited capability includes: a bandwidth required to receive the MCCH included in SIB24 exceeds a maximum receiving bandwidth of the communication device.

26. The device according to claim 23, wherein Unable to successfully receive multicast data due to limited capabilities, including: The number of physical resource blocks (PRBs) used for scheduling the multicast data exceeds the maximum number of PRBs that can be processed by the communication device.

27. The device according to any one of claims 21 to 26, characterized in that The RRC recovery request includes second indication information, where the second indication information is used to indicate a reason why the communication device initiates the RRC connection recovery request.

28. The device according to any one of claims 21 to 27, characterized in that The transceiver module is also used for: Send third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

29. The device according to claim 28, characterized in that The third indication information is carried in message 1 or message 3 during the random access process.

30. A communication device, characterized in that: include: a transceiver module, configured to send a radio resource control (RRC) release message to a terminal device and receive an RRC recovery request from the terminal device, wherein the RRC release message includes first indication information, and the first indication information instructs the terminal device to receive multicast in an RRC inactive state; a processing module, configured to determine that the reason for the RRC recovery request is that the terminal device is unable to read the multicast configuration sent by the communication device in the RRC inactive state or is unable to receive multicast data sent by the communication device in the RRC inactive state; The transceiver module is further used to send an RRC recovery message; or, the transceiver module is further used to send an RRC release message, and the processing module is further used to update the multicast configuration.

31. The device according to claim 30, wherein The reason why the terminal device requests to restore the RRC connection includes: Unable to obtain multicast configuration due to limited capabilities; or Unable to successfully receive multicast data due to limited capabilities.

32. The device according to claim 31, wherein The inability to obtain multicast configuration due to limited capabilities includes: Unable to read the system message block SIB24 due to limited capabilities; or, Due to limited capabilities, the multicast control channel MCCH cannot be received according to SIB24.

33. The device according to claim 32, wherein The system information block SIB24 cannot be read due to limited capabilities, including: the bandwidth required to receive SIB24 exceeds the maximum receiving bandwidth of the terminal device; or The MCCH cannot be received according to SIB24 due to limited capabilities, including: the receiving bandwidth of the MCCH required for receiving SIB24 exceeds the maximum receiving bandwidth of the terminal device.

34. The device according to claim 30, wherein Unable to successfully receive multicast data due to limited capabilities, including: The number of physical resource blocks (PRBs) used to schedule the multicast data exceeds the maximum number of PRBs that the terminal device can process.

35. The device according to any one of claims 30 to 34, characterized in that The transceiver module is also used for: Receive third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

36. The device according to claim 35, wherein The third indication information is carried in message 1 or message 3 during the random access process.

37. A communication device, characterized in that: include: a transceiver module, configured to send a radio resource control (RRC) release message to a terminal device and receive an RRC recovery request from the terminal device, wherein the RRC release message includes first indication information, and the first indication information instructs the terminal device to receive multicast in an RRC inactive state; a processing module, configured to determine that the capability of the terminal device is limited; The transceiver module is further used to send an RRC recovery message, or the transceiver module is further used to send an RRC release message, and the processing module is further used to update the multicast configuration.

38. The device according to claim 37, wherein The transceiver module is also used for: Receive third indication information, where the third indication information is used to indicate that the terminal capability is limited or the type of the terminal device.

39. The device according to claim 38, wherein The third indication information is carried in message 1 or message 3 during the random access process.

40. A communication device, characterized in that: The communication device includes a processor and a memory, the memory is used to store a computer program, and the processor is used to execute the computer program stored on the memory, so that the communication device performs the method according to any one of claims 1 to 9, or the communication device performs the method according to any one of claims 10 to 17, or the communication device performs the method according to any one of claims 18 to 20.

41. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store a computer program. When the computer program is run on a computer, the computer executes the method according to any one of claims 1 to 9, or the method according to any one of claims 10 to 17, or the method according to any one of claims 18 to 20.

42. A computer program product, characterized in that The computer program product includes a computer program, which, when executed on a computer, causes the computer to perform the method according to any one of claims 1 to 9, or causes the computer to perform the method according to any one of claims 10 to 17, or causes the computer to perform the method according to any one of claims 18 to 20.

43. A chip system, characterized in that: The chip system includes: A processor and an interface, the processor being configured to call and run instructions from the interface, wherein when the processor executes the instructions, the method according to any one of claims 1 to 9 is implemented, or the method according to any one of claims 10 to 17 is implemented, or the method according to any one of claims 18 to 20 is implemented.

Images