WO2025232472A1 - Communication method and related apparatus - Google Patents

Abstract

Provided in the present application are a communication method and a related apparatus. The method comprises: a first access network device establishing one or more pieces of MBS session resource information with a core network device; and requesting an MBS session resource for a second access network device, so that the second access network device receives MBS session data. By means of the technical solution provided in the present application, the time delay of data transmission can be reduced.

Description

Communication methods and related devices

This application claims priority to Chinese Patent Application No. 202410580027.6, filed on May 10, 2024, entitled "Communication Method and Related Apparatus", the entire contents of which are incorporated herein by reference.

Technical Field

This application relates to the field of wireless communication technology, and in particular to a communication method and related apparatus.

Background Technology

In satellite communication/non-terrestrial networks (NTN), when an access network device (such as a radio access network (RAN)) ceases to serve a given geographical area, the access network device and the core network need to perform NG-U resource release for a multicast/broadcast service (MBS) session. When the access network device begins to serve a given geographical area, the access network device and the core network need to perform NG-U resource establishment for an MBS session.

Due to the high mobility of satellites in NTN scenarios, cells serving specific areas frequently change. For example, if the first access network device leaves a specific area and a second access network device covers that area, it leads to frequent establishment and release of MBS session NG-U resources between the access network device and the core network, resulting in significant signaling and user data latency. Therefore, reducing data transmission latency is an urgent problem to be solved.

Summary of the Invention

This application provides a communication method and related apparatus that can reduce data transmission latency.

Firstly, this application provides a communication method that can be applied to a first access network device, or to a device within the first access network device (e.g., a chip, a chip system, or a circuit), or to a device compatible with the first access network device. The following description uses an application to a first access network device as an example. The method may include: the first access network device establishing one or more MBS session resource information with a core network device; and requesting MBS session resources from a second access network device to enable the second access network device to receive MBS session data.

In the solution provided in this application, one or more MBS session resource information can be established between the first access network device and the core network. The first access network device requests the MBS session resource of the second access network device, thereby enabling the sending of MBS session data to the second access network device. This eliminates the need to release the MBS session resource between the first access network device and the core network and establish the MBS session resource between the second access network device and the core network when the cell is replaced, thus avoiding a large amount of signaling overhead and reducing data transmission latency.

One possible implementation involves establishing one or more MBS session resources with the core network equipment, including: receiving first indication information from the core network equipment, the first indication information indicating one or more MBS session information, each MBS session information including at least one of MBS session identifier (ID), MBS service area, MBS area session ID, and cell identifier to which the forwarded data is sent; and sending second indication information to the core network equipment, the second indication information indicating the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions.

One possible implementation involves requesting MBS session resources from the second access network device by receiving an MBS session ID corresponding to one or more MBS sessions from the second access network device and Xn-U tunnel information associated with the MBS sessions. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device.

One possible implementation of the method may further include sending at least one of the following to the second access network device: an MBS session ID, an MBS area session ID, and an MBS service area corresponding to one or more MBS sessions.

One possible implementation of the method may further include: determining the second access network device requesting the establishment of MBS session resources based on the cell identifier to which the forwarded data is to be received in the first indication information of the core network device, or based on the area served or to be served by the second access network device.

One possible implementation of the method may further include sending a cell identifier for data forwarding to the core network device.

One possible implementation of the method may further include: sending cell-level, region-level, or beam-level packet data convergence protocol (PDCP) status information to the second access network device, wherein the PDCP status information is the sequence number information of the last PDCP data packet sent.

One possible implementation is that the beam-level PDCP status information is the PDCP sequence number information for each beam of each MBS radiobearer (MRB), or the PDCP sequence number information for each MRB of each beam; the area-level PDCP status information is the PDCP sequence number information for each area of each MRB, or the PDCP sequence number information for each MRB of each area.

One possible implementation is that the cell-level PDCP status information is the PDCP sequence number information for each MRB.

Secondly, this application provides a communication method that can be applied to a second access network device, or to a device within the second access network device (e.g., a chip, a chip system, or a circuit), or to a device compatible with the second access network device. The following description uses an application to a second access network device as an example. The method may include: the second access network device sending one or more MBS sessions corresponding to MBS session IDs and tunnel information associated with the MBS sessions; and receiving MBS session data.

In the solution provided in this application, the second access network device can indicate MBS session resource information, thereby enabling the second access network device to receive MBS session data without having to establish MBS session resources between the second access network device and the core network when the cell is changed, thus avoiding a large amount of signaling overhead and reducing data transmission latency.

It should be understood that the implementing entity of the second aspect can be the second access network device, the specific content of the second aspect corresponds to the content of the first aspect, and the corresponding features and beneficial effects of the second aspect can be referred to the description of the first aspect. To avoid repetition, detailed descriptions are appropriately omitted here.

One possible implementation of the method may further include: receiving at least one of the following from a first access network device: an MBS session ID, an MBS area session ID, and an MBS service area corresponding to one or more MBS sessions.

One possible implementation of the method may further include: receiving at least one of the following from the core network device: an identifier of the source cell, an MBS session ID corresponding to one or more MBS sessions, an MBS area session ID, and an MBS service area, wherein the source cell provides the current first access network device with the identifier information of the geographical area or cell corresponding to the MBS session.

One possible implementation involves sending the MBS session ID corresponding to one or more MBS sessions and the tunnel information associated with the MBS sessions, including sending the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS sessions to the first access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device.

One possible implementation involves sending the MBS session ID corresponding to one or more MBS sessions and the tunnel information associated with the MBS sessions to the core network equipment, including sending the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions.

One possible implementation of the method may further include: sending the identifier of the source cell managed by the first access network device to the core network device, for requesting the core network device to change the MBS session from the first access network device to the second access network device.

One possible implementation of the method may further include: receiving PDCP status information at the cell, region, or beam level from a first access network device, wherein the PDCP status information is the sequence number information of the last transmitted PDCP data packet; when serving a first region within an MBS service area corresponding to one or more MBS sessions, sending the MBS session data to a terminal device, wherein the PDCP data packet sequence number of the MBS session data is the PDCP data packet sequence number corresponding to the PDCP status information of the first region sent by the first access network device + 1; or, when serving a first beam within an MBS service area corresponding to one or more MBS sessions, sending the MBS session data to a terminal device, wherein the PDCP data packet sequence number of the MBS session data is the PDCP data packet sequence number corresponding to the PDCP status information of the first beam sent by the first access network device + 1.

One possible implementation is that the beam-level PDCP status information is the PDCP sequence number information for each beam of each MRB, or the PDCP sequence number information for each MRB of each beam; the region-level PDCP status information is the PDCP sequence number information for each region of each MRB, or the PDCP sequence number information for each MRB of each region.

One possible implementation is that the cell-level PDCP status information is the PDCP sequence number information for each MRB.

Thirdly, embodiments of this application provide a communication device, which can be a first access network device, a device within the first access network device (e.g., a chip, a chip system, or a circuit), or a logic module or software capable of implementing all or part of the functions of the first access network device. The communication device includes modules/units for executing any of the methods described in the first aspect and its possible implementations. The functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions. Beneficial effects can be found in the description of the first aspect, and will not be repeated here.

Fourthly, embodiments of this application provide a communication device, which can be a second access network device, or a device within the second access network device (e.g., a chip, a chip system, or a circuit), and can also be applied to a logic module or software capable of implementing all or part of the functions of the second access network device. The communication device includes modules/units for executing any of the methods described in the second aspect and its possible implementations. The functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. Beneficial effects can be found in the description of the second aspect, and will not be repeated here.

Fifthly, a communication device is provided, which may be a first access network device or a device within the first access network device (e.g., a chip, a chip system, or a circuit). The device may include a processor, a memory, an input interface, and an output interface. The input interface is used to receive information from other communication devices besides the communication device, and the output interface is used to output information to other communication devices besides the communication device. The processor invokes a computer program stored in the memory to execute the communication method provided in the first aspect or any embodiment of the first aspect.

In a sixth aspect, a communication device is provided, which may be a second access network device or a device (e.g., a chip, a chip system, or a circuit) within the second access network device. The device may include a processor, a memory, an input interface, and an output interface. The input interface is used to receive information from other communication devices besides the communication device, and the output interface is used to output information to other communication devices besides the communication device. The processor invokes a computer program stored in the memory to execute the communication method provided in the second aspect or any embodiment of the second aspect.

In a seventh aspect, this application provides a computer-readable storage medium storing computer instructions that, when the computer program or computer instructions are executed, cause the methods described in the first aspect and any possible implementation thereof, and the second aspect and any possible implementation thereof, to be performed.

Eighthly, this application provides a computer program product including executable instructions that, when the computer program product is run on a communication device, causes the methods described in the first aspect and any possible implementation thereof, and the second aspect and any possible implementation thereof, to be executed.

Ninthly, this application provides a communication device, which includes a processor and may further include a memory, for implementing the methods of the first aspect and any possible implementation thereof, and the second aspect and any possible implementation thereof. The communication device may be a chip system, which may be composed of chips or may include chips and other discrete devices.

In a tenth aspect, this application provides a communication system comprising at least one first access network device and at least one second access network device, wherein when at least one of the aforementioned first access network devices and at least one of the aforementioned second access network devices are operating in the communication system, they are used to perform any of the communication methods described in the first to second aspects.

Attached Figure Description

To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

Figure 1 is a schematic diagram of a communication system provided in an embodiment of this application;

Figure 2 is a base station-side NR protocol stack and network element module provided in an embodiment of this application;

Figure 3 is a schematic diagram of an O-RAN architecture provided in an embodiment of this application;

Figures 4-7 are schematic diagrams of an NTN-based RAN architecture provided in an embodiment of this application;

Figure 8 is a schematic diagram of a 5G MBS downlink data forwarding mechanism provided in an embodiment of this application;

Figure 9 is a schematic diagram of a multicast service control and transmission process provided in an embodiment of this application;

Figure 10 is a schematic diagram of a broadcast service control and transmission process provided in an embodiment of this application;

Figure 11 is a flowchart illustrating a communication method provided in an embodiment of this application;

Figure 12 is an interactive schematic diagram of a communication method provided in an embodiment of this application;

Figure 13 is an interactive schematic diagram of another communication method provided in an embodiment of this application;

Figure 14 is an interactive schematic diagram of another communication method provided in an embodiment of this application;

Figure 15 is an interactive schematic diagram of another communication method provided in an embodiment of this application;

Figures 16 and 17 are schematic diagrams of the structure of a communication device provided in an embodiment of this application.

Detailed Implementation

The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings.

The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

In this application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three or more, and "and/or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and/or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. The character "/" generally indicates that the related objects before and after are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

In this application, "sending information" can be understood as one device sending information to another device, or it can also be understood as one logical module within a device sending information to another logical module. For example, "access network device sending information" can be understood as the access network device sending information to another device (such as a terminal), or it can be understood as logical module 1 in the access network device sending information to logical module 2 in the access network device.

In this application, "receiving information" can be understood as one device receiving information from another device, or it can also be understood as a logical module within a device receiving information from another logical module. For example, "access network device receiving information" can be understood as the access network device receiving information from another device (such as a terminal), or it can be understood as logical module 1 in the access network device receiving information from logical module 2 in the access network device.

In this application, "sending information to... (e.g., a terminal)" can be understood as the destination of the information being the terminal. This can include sending information to the terminal directly or indirectly. "Receiving information from... (e.g., a terminal)" or "receiving information from... (e.g., a terminal)" can be understood as the source of the information being the terminal, and can include receiving information from the terminal directly or indirectly. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood in a similar way, and will not be elaborated further here.

The network architecture applicable to the embodiments of this application will be described below as an example.

This application's embodiments can be applied to communication systems such as satellite communication, including satellite base stations, ground stations, and terminal device network elements. The satellite base station provides communication services to the terminal device, transmitting downlink data to the terminal device. This data is encoded using channel coding, and the channel-coded data is then modulated by constellation before being transmitted to the terminal device. The terminal device transmits uplink data to the satellite base station, which can also be encoded using channel coding. The encoded data is then modulated by constellation before being transmitted to the satellite base station. The wireless communication system may include one or more network devices and one or more terminal devices.

The following explanation uses the system architecture shown in Figure 1 as an example. The communication method provided in this application embodiment can be applied to NTN communication systems. As shown in Figure 1, the communication system includes a radio access network (RAN) 100, a core network (CN) 200, and an Internet 300. RAN 100 includes at least one RAN node (110a and 110b in Figure 1, collectively referred to as 110) and at least one terminal (120a-120j in Figure 1, collectively referred to as 120). RAN may also include other RAN nodes, such as wireless relay devices and/or wireless backhaul devices (not shown in Figure 1). Terminal 120 is wirelessly connected to RAN node 110. RAN node 110 is wirelessly or wired connected to core network 200. The core network device in core network 200 and RAN node 110 in RAN 100 can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions.

RAN 100 can be a cellular system related to the 3rd Generation Partnership Project (3GPP), such as 4G, 5G mobile communication systems, NTN (non-terrestrial network) systems, or future-oriented evolution systems (such as 6G mobile communication systems). RAN 100 can also be an open access network (open RAN, O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system, or a communication system that integrates two or more of the above systems.

In this embodiment, RAN100 is an NTN (non-terrestrial network) system. RAN100 can be in transparent mode or regenerative mode, earth fixed cell or earth moving cell.

The embodiments of this application mainly involve terminal equipment 120, RAN node 110 and core network equipment.

The terminal device 120 can also be referred to as user equipment (UE), mobile station (MS), mobile terminal (MT), etc., or a device used to provide voice or data connectivity to users, or an Internet of Things (IoT) device. For example, terminal devices include handheld devices with wireless connectivity, vehicle-mounted devices, etc. Currently, terminal devices can include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, etc.), in-vehicle equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, virtual reality (VR) devices, augmented reality (AR) devices, smart point-of-sale (POS) machines, customer-premises equipment (CPE), wireless terminal devices in industrial control, smart home devices (such as refrigerators, televisions, air conditioners, electricity meters, etc.), smart robots, robotic arms, workshop equipment, wireless terminal devices in autonomous driving, wireless terminal devices in telemedicine, wireless terminal devices in smart grids, wireless terminal devices in transportation safety, wireless terminal devices in smart cities, or wireless terminal devices in smart homes, and flying equipment (such as smart robots, hot air balloons, drones, airplanes), etc. The terminal device can also be other devices with terminal device functions. For example, the terminal device can also be a device that performs the terminal device function in D2D communication.

The embodiments of this application do not limit the device form of the terminal device. The device used to implement the function of the terminal device can be the terminal device itself; it can also be a device that supports the terminal device in implementing the function, such as a chip system. The device can be installed in the terminal device or used in conjunction with the terminal device. In the embodiments of this application, the chip system can be composed of chips or can include chips and other discrete components.

RAN node 110, sometimes referred to as a radio access network device, RAN entity, or access node, constitutes part of the communication system and assists terminals in achieving wireless access. Multiple RAN nodes 110 in communication system 1000 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal 120 are relative. For example, network element 120i in Figure 1 can be a helicopter or drone, which can be configured as a mobile base station. For terminals 120j accessing RAN 100 through network element 120i, network element 120i is a base station; however, for base station 110a, network element 120i is a terminal. RAN node 110 and terminal 120 are sometimes both referred to as communication devices. For example, network elements 110a and 110b in Figure 1 can be understood as communication devices with base station functions, while network elements 120a-120j can be understood as communication devices with terminal functions.

In one possible scenario, a RAN node can be an access network device (RAN), a base station, an evolved NodeB (eNodeB), a transmitting and receiving point (TRP), a transmitting point (TP), a next-generation NodeB (gNB), a next-generation base station in a 6th-generation (6G) mobile communication system, a base station in a future mobile communication system, a satellite, an integrated access and backhaul (IAB) node, or a network device in a mobile switching center non-terrestrial network (NTN) communication system, i.e., it can be deployed on a high-altitude platform or satellite. A RAN node can be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a radio controller in a CRAN scenario. A RAN node can also function as a base station in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, and machine-to-machine (M2M) communication. Optionally, RAN nodes can also be servers, wearable devices, vehicles, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU).

In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, with different RAN nodes each implementing some of the base station's functions. For example, RAN nodes can be central units (CUs), distributed units (DUs), CUs (control planes, CPs), CUs (user planes, UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). The CU and DU nodes separate the gNB's protocol layers; some protocol layer functions are centrally controlled by the CU, while the remaining partial or complete protocol layer functions are distributed in the DU, which is centrally controlled by the CU.

Please refer to Figure 2, which illustrates a base station-side NR protocol stack and network element module provided in an embodiment of this application. As shown in Figure 2, in one implementation, the CU deploys the Radio Resource Control (RRC) layer, PDCP layer, and Service Data Adaptation Protocol (SDAP) layer in the protocol stack; the DU deploys the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and Physical Layer (PHY) in the protocol stack. Thus, the CU has the processing capabilities for RRC, PDCP, and SDAP. The DU has the processing capabilities for RLC, MAC, and PHY. It is understood that the above functional division is merely an example and does not constitute a limitation on the CU and DU. RU can be included in radio frequency equipment or radio frequency units, such as in remote radio units (RRU), active antenna units (AAU), or remote radio heads (RRH).

In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

Please refer to Figure 3, which is a schematic diagram of an O-RAN architecture provided in an embodiment of this application. As shown in Figure 3, O-RAN aims to realize an intelligent and open access network. The main feature of the O-RAN architecture is the separation of software and hardware, realizing the virtualization of network functions and the standardization of hardware. In addition, O-RAN also introduces artificial intelligence (AI).

The table below shows the correspondence between ORAN access network equipment (network element modules) and their implemented protocol layer functions:

Core network equipment refers to equipment in the core network (CN) that provides service support to terminals. Examples of core network equipment include: Access and Mobility Management Function (AMF) entities, Session Management Function (SMF) entities, User Plane Function (UPF) entities, etc., which will not be listed here. The AMF entity is responsible for terminal access management and mobility management; the SMF entity is responsible for session management, such as user session establishment; and the UPF entity can be a user plane functional entity, primarily responsible for connecting to external networks. It should be noted that in this application, entities can also be referred to as network elements or functional entities. For example, an AMF entity can also be called an AMF network element or an AMF functional entity, and similarly, an SMF entity can also be called an SMF network element or an SMF functional entity.

Please refer to Figures 4-7, which are schematic diagrams of an NTN-based NG-RAN architecture provided in this application embodiment. Figure 4 shows a transparent satellite architecture. In this transparent satellite scenario, the satellite's role is radiofrequency filtering, frequency conversion, and amplification. That is, the satellite primarily acts as an L1 relay, regenerating physical layer signals without any other higher protocol layers. Figure 5 shows a regenerative satellite without inter-satellite links (gNB-processed payload), where ISL refers to inter-satellite links. In this architecture, the satellite can act as a base station. Figure 6 shows a regenerative satellite with inter-satellite links and gNB-processed payload (regenerative satellite without ISL). In this architecture, the satellite can also act as a base station. The difference from the architecture shown in Figure 5 is that this architecture has ISL. Figure 7 shows a regenerative satellite with gNB-DU processing capabilities (NG-RAN with a regenerative satellite based on gNB-DU). In this architecture, the satellite can act as a DU.

When describing the technical solutions provided in the embodiments of this application below, it can be understood that when applying the solutions provided in the embodiments of this application to a terrestrial communication system, the actions performed by the satellite can be applied to the base station or network equipment for execution. Furthermore, the aforementioned satellites can be geostationary satellites, non-geostationary satellites, artificial satellites, low-Earth orbit satellites, medium-Earth orbit satellites, and high-Earth orbit satellites, etc., and the embodiments of this application do not specifically limit them.

The following are definitions of technical terms that may appear in the embodiments of this application. The terms used in the implementation section of this application are only used to explain the specific embodiments of this application and are not intended to limit this application.

(1) Beam

A major problem with high-frequency communication is that signal energy decreases sharply with transmission distance, resulting in short transmission ranges. To overcome this problem, high-frequency communication employs analog beamforming technology, which uses a large-scale antenna array to weight the signal energy and concentrate it into a smaller area, forming a beam-like signal (called an analog beam, or simply a beam), thereby increasing the transmission distance.

A beam is a communication resource. A beam can be wide, narrow, or other types. The technology used to form a beam can be beamforming or other techniques. Beamforming technology can specifically be digital beamforming, analog beamforming, or hybrid digital/analog beamforming. Different beams can be considered different resources. The same or different information can be transmitted through different beams. Optionally, multiple beams with the same or similar communication characteristics can be considered as a single beam. A beam can be formed by one or more antenna ports and used to transmit data channels, control channels, and detection signals, etc. The one or more antenna ports forming a beam can be considered as a set of antenna ports.

A beam consists of a transmit beam and a receive beam. The transmit beam refers to the distribution of signal strength in different directions in space after a signal is transmitted through an antenna, while the receive beam refers to the distribution of wireless signal strength received by an antenna array in different directions in space, either strengthening or weakening the signal.

Beamforming can be represented by quasi-colocation (QCL) relationships at antenna ports. Specifically, two signals in the same beam share a QCL relationship with respect to spatial Rx parameters, i.e., QCL-Type D:{Spatial Rx parameter} in the protocol. Beamforming can be specifically represented in the protocol by various signal identifiers, such as the resource index of the channel state information reference signal (CSI-RS), the index of the synchronous signal/physical broadcast channel block (SS/PBCH block, or SSB), the resource index of the sounding reference signal (SRS), and the resource index of the tracking reference signal (TRS).

In addition, generally, a beam corresponds to a DMRS port, a transmission configuration index (TCI), a TRP, or a sounding reference signal resource indicator (SRS resource indicator, SRI) (for uplink data transmission). Therefore, different beams can also be represented by different DMRS ports, TCIs, TRPs, or SRIs.

(2)NTN

Because traditional terrestrial networks (TN) cannot provide seamless coverage for terminal devices, especially in areas where base stations cannot be deployed, such as oceans, deserts, and the air, non-terrestrial networks (NTNs) have been introduced into IoT, 5G systems, and subsequent system architectures such as 6G. They provide seamless coverage for terminal devices and improve system reliability by deploying base stations or some base station functions on high-altitude platforms or satellites. This application uses satellites as an example. According to their operating modes, satellites are generally divided into two main categories: the first is transparent relay, where the satellite relays the radio frequency signals of base stations located on the ground. The satellite's role is to filter, convert, and amplify radio frequencies, regenerating physical layer signals. The second is regenerative relay, where the satellite has all or part of the functions of a base station, meaning the base station or some of its functions are deployed on the satellite. According to satellite altitude, i.e., satellite orbital altitude, satellite systems can be divided into the following two categories:

High-orbit satellites, also known as geostationary satellites or geosynchronous orbit (GEO) satellites, move at the same speed as the Earth's rotation system. Therefore, the satellite remains stationary relative to the ground, and correspondingly, the cell of a GEO satellite is also stationary. GEO satellite cells have a large coverage area, typically with a cell diameter of 500 km.

Medium and low Earth orbit satellites: Satellites move relatively fast relative to the ground, so the service coverage area provided by medium and low Earth orbit satellites also moves accordingly.

Therefore, for low and medium Earth orbit satellites, the coverage areas provided by the satellites can be divided into two types:

Quasi-earth-fixed cell: A moving satellite forms a cell by adjusting its beam, and the cell remains stationary on the ground for a certain period of time.

Earth-moving cell: The satellite does not dynamically adjust its beam direction; the cell covered by the satellite's beam moves as the satellite moves.

(3) MBS

3GPP Rel-17 introduced NR MBS, a new data distribution/transmission method that allows the simultaneous distribution/transmission of the same service content to multiple terminals, such as live streaming, public safety services, and batch software updates, achieving efficient utilization of NR resources. For Broadcast Service, the same service and specific content data are simultaneously provided to all terminal devices within a geographic area (all terminal devices within the broadcast service area are authorized to receive this data). Broadcast Service is delivered to terminal devices through a broadcast session. Terminal devices in RRC Idle, RRC Inactive, and RRC Connected states can all receive broadcast services. Only PTM (Point-to-Multipoint) delivery mechanism is supported; HARQ is not supported. For multicast services, the same service and specific content data are simultaneously provided to a dedicated group of terminal devices (i.e., not all terminal devices in the MBS service area are authorized to receive data). Multicast services are delivered to terminal devices through multicast sessions (MBS sessions). Terminal devices in RRC connected state can receive multicast services using mechanisms such as PTP (point-to-point) and/or PTM (point-to-multipoint). HARQ feedback/retransmission can be applied to PTP and PTM transmissions. For unicast services, NG-RAN, which does not support MBS, delivers MBS session data to terminal devices via unicast. The Rel-18 protocol enhances the MBS mechanism, supporting RRC inactive terminal devices to receive multicast services.

(4) MBS supporting NTN (MBS over NTN)

NTN cells cover a large geographical area, and the distribution of terminal devices in different geographical areas is uneven. The demand for MBS broadcast service content also varies greatly among terminal devices in different areas. The current discussion on supporting MBS data only applies to a specific area of the cell. This specific area can be one or more geographical areas of the cell, or one or more SSB beams of the cell. The definition of the specific area is not limited, i.e., it is a beam-level or area-level MBS session.

It should be understood that the definitions of the above technical terms are merely illustrative. For example, as technology continues to develop, the scope of the above definitions may also change, and the embodiments of this application are not intended to limit the scope.

First, in order to facilitate understanding of the embodiments of this application, the technical problems that this application specifically aims to solve will be further analyzed and proposed.

Please refer to Figure 8, which is a schematic diagram of a 5G MBS downlink data forwarding mechanism provided in an embodiment of this application. As shown in Figure 8, the MBS service originates from a data server. First, the data server sends the MBS data to the core network equipment. Then, the core network equipment sends the MBS data to the base station. Finally, the base station sends the MBS data to at least one terminal device receiving the MBS service. Specifically, the core network equipment can be an MB-UPF (multicast/broadcast user plane function), which distributes the data stream to the NR RAN node in two ways:

The first possible implementation: When the NR RAN node supports MBS, a 5GC shared transmission channel is used. The MB-UPF and NR RAN directly establish a shared transmission channel to provide MBS session data to the RAN. Each MBS session can contain at least one MBS QoS stream. The RAN then distributes/transmits the data to the terminal equipment in the form of broadcast or multicast services. When sending data from the base station to the terminal equipment, the data packets are transmitted through the MBS radio bearer. For an MBS radio bearer, there are two transmission modes: the first can be PTM (point to multi-point) transmission mode; the second can be PTP (point to point) transmission mode.

The second possible implementation: When the NR RAN node does not support MBS, a 5GC independent transmission channel is used. 5GC independent transmission involves the MB-UPF sending data to the UPF, which then sends the data to each NR RAN node in unicast mode according to user granularity. The NR RAN then sends the MBS service data to the terminal device via unicast.

Currently, there are various technical solutions for implementing MBS data forwarding. The RAN side has implemented different designs for multicast/broadcast service session management, configuration distribution to data reception, and mobility. Two examples are listed below:

Option 1: Multicast service.

Please refer to Figure 9, which is a schematic diagram of a multicast service control and transmission process provided in an embodiment of this application. As shown in Figure 9, multicast services are designed for services with high QoS requirements and require group management. They can provide the same QoS level as unicast services. Specifically, for multicast services, the core network needs to manage the joining and leaving of terminal devices. The transmission between the core network and the base station relies on PDU sessions, introducing a new MBS QoS flow. For the RAN, it supports sending data to terminal devices via PTP and PTM transmission methods, and supports dynamic switching between PTP and PTM controlled by the RAN. Multicast services can be provided to RRC connected terminal devices and RRC inactive terminal devices. The gNB and CN need to maintain the terminal device information corresponding to the multicast service group. The gNB provides PTM configuration information and multicast service information that the terminal device continues to receive in the RRC inactive state in the RRC release message. At the same time, multicast services also support MBS session deactivation/activation triggered by the core network. The terminal device is unaware of the service status. When there is data transmission or session activation, the RAN notifies the terminal device through the group notification mechanism.

The specific process is as follows: The terminal device instructs the core network to join the MBS multicast session ID via a PDU session modification request/establishment message. The core network instructs the RAN to indicate the MBS session ID and corresponding QoS flow that the terminal device has joined. The RAN determines the PDU session associated with the MBS session based on the MBS session ID. The RAN decides to establish a shared channel (tunnel) between the RAN and MB-UPF for the MBS session. The RAN sends an MBS session NG-U transmission establishment request message to the AMF to instruct the AMF to provide at least one of the following: MBS session ID, MBS area session ID, and NG-U tunnel information associated with the MBS PDU session. The acknowledgment message sent by the AMF to the RAN includes at least one of the following: MBS session ID, MBS area session ID, MBS QoS flow list, MBS session status (active/deactivated), and MBS service area. If the MBS session is active, the RAN establishes the air interface resources for the MBS session and configures the terminal device to receive the MBS multicast session. The NG-U tunnel information is NG user plane transport layer information.

Option 2: Broadcast service.

Please refer to Figure 10, which is a schematic diagram of a broadcast service control and transmission process provided in an embodiment of this application. As shown in Figure 10, in the NGAP broadcast session resource establishment process triggered by the AMF, the AMF forwards the MBS session resource establishment request message to all NG-RANs supporting MBS within the MBS service area. This message may contain at least one of the following: MBS session ID, 5G QoS Profile, and MBS service area. The NG-RAN establishes a broadcast MBS session context and stores the TMGI and QoS profile in the MBS session context. When the NG-RAN successfully establishes the corresponding MBS session in at least one cell, it sends the MBS session ID and the NG-U tunnel information associated with the MBS PDU session to the AMF to report the successful establishment of the MBS session resource. The NG-RAN sends the relevant service configuration in the MCCH message, and the terminal device receives the broadcast service data based on the service configuration information.

Terminal devices can receive MBS broadcast session data in RRC idle, RRC inactive, and RRC connected states. The gNB needs to configure the MRB corresponding to the MBS broadcast session for the terminal device to perform MBS broadcast data transmission. If the terminal device wants to receive broadcast services, it obtains the parameters required to receive the MCCH (MBS Control Channel) through system messages, and obtains MBS broadcast configuration information (e.g., parameters required to receive MTCH) by receiving the MCCH, thereby receiving broadcast service data on the MTCH. Specifically, the MBS broadcast configuration information sent on the MCCH includes the list of broadcast services in ongoing sessions transmitted on the MTCH (MBS Traffic Channel). The broadcast service list information includes the MBS session ID, MTCH scheduling information related to the G-RNTI (Group RNTI), and neighbor cell information providing certain MBS sessions. The terminal device receives MBS broadcast data on the MTCH based on the g-RNTI and MTCH scheduling information. When performing cell reselection, terminal devices in RRC idle and inactive states may consider MBS frequency layer priorities, specifically as follows: The terminal device can obtain the frequency information corresponding to the MBS broadcast service through one or a combination of USD (User Service Description) and SIB21 (System Information Block). During cell reselection, the terminal device will prioritize the frequency of the MBS broadcast service that supports the service it is currently receiving or is interested in receiving. If the terminal device finds that a neighboring cell does not support a certain MBS broadcast service, it can set the frequency of that neighboring cell to the lowest priority. When the reselected cell does not support the MBS broadcast session, the terminal device enters connected state to request unicast reception to ensure the continuity of broadcast service reception.

In addition, RRC_CONNECTED state terminal devices can also provide frequency information of broadcast services they are interested in, MBS service information, and unicast and broadcast service reception priority information by sending MBS Interest Indication (MII) messages.

Disadvantages of Schemes 1 and 2: When an NTN cell leaves the designated area, the RAN and core network need to perform NG-U resource release for the MBS session; when an NTN cell starts serving (moves to) the designated area, the RAN and core network need to perform NG-U resource establishment for the MBS session. In the NTN scenario, due to the high mobility of satellites, frequent NTN cell changes can lead to the following for terminal devices in the designated area:

1. Frequent establishment and release of NG-U resources in MBS sessions between the RAN and the core network cause significant delays in NG signaling and NG user data.

2. When supporting regional/beam-level MBS sessions, frequent NTN cell switching can compromise the service continuity of MBS services, thus reducing user experience.

Therefore, the technical problems to be solved by this application may include the following:

1. Resolve the frequent establishment and release of NG-U resources in MBS sessions between the RAN and the core network, avoiding significant delays in NG signaling and NG user data;

2. When supporting regional/beam-level MBS sessions, ensure the service continuity of MBS services when NTN cells are frequently switched.

This application proposes a communication method, which will be described below through various embodiments. It should be understood that these communication methods can be used in combination with each other.

It should be understood that the forwarding of MBS session data may change as the technical solutions evolve, and the technical solutions provided in this application are not limited to the process described below. Furthermore, the scenario descriptions in the embodiments of this application are merely illustrative and do not limit the solutions of the embodiments of this application to only the described scenarios, but are also applicable to scenarios with similar problems.

This application proposes a communication method, which will be described below through various embodiments. In the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and/or descriptions between different embodiments are consistent and can be referenced mutually. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

In this application embodiment (as shown in Figures 11-15 below), the access network device can be the wireless access network device 110 in the network architecture shown in Figure 1. The functions performed by the access network device in this embodiment can also be performed by a device (e.g., a chip, a chip system, or a circuit) within the access network device. The core network device in this embodiment can be the core network 200 in the network architecture shown in Figure 1. The functions performed by the core network device in this embodiment can also be performed by a device (e.g., a chip, a chip system, or a circuit) within the core network device. The first access network device in this embodiment can be understood as the source access network device/old access network device, and the second access network device can be understood as one or more candidate access network devices. This application embodiment is described uniformly here and will not be repeated hereafter.

It should be noted that Figures 11-15 illustrate the example of a first access network device forwarding MBS session data to one or more second access network devices. This embodiment is not limited to one first access network device. The MBS session data forwarding and subsequent processes of multiple first access network devices can all refer to the flowcharts shown in Figures 11-15.

Based on the network architecture described above, a communication method provided by an embodiment of this application will be described below. Please refer to Figure 11, which is a schematic flowchart of a communication method provided by an embodiment of this application. As shown in Figure 11, the communication method may include S1101-S1102.

S1101: The first access network device establishes one or more MBS session resource information with the core network device.

MBS session resource information can be understood as the resource information required for the first access network device to receive MBS session data from the core network. Possible implementations for the first access network device and the core network device to establish one or more MBS session resource information are as follows: The core network sends a first indication message to the first access network device. This first indication message indicates one or more MBS session information (or may also be called an MBS session information list). Each MBS session information includes at least one of the following: MBS session identifier ID, MBS service area, MBS area session ID, and cell identifier to which the data is forwarded. The first access network device sends a second indication message to the core network. This second indication message indicates the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with that MBS session, thereby enabling the first access network device to receive MBS session data from the core network through the tunnel information associated with the MBS session.

The MBS service area can be one or more cell identifiers, one or more tracking area identifiers, or a specific area within a cell. A specific area can be one or more geographical regions, or one or more beams. A geographical region can be a circular area represented by a reference point and radius, or it can be represented by a polygon or boundary line; there are no restrictions. The MBS area session ID is used to identify area-related content data and, together with the MBS session ID, identifies the MBS session data of an MBS service area. The cell identifiers in the cell identifier list to which data is forwarded can be represented by one of the following: the corresponding cell ID (mapped cell ID), physical cell identifier (PCI), cellglobal identifier (CGI), or geographical area information. Each mapped cell ID corresponds to a fixed geographical location. In addition to the above representation methods, geographical area information can also include a region ID.

S1102: The first access network device requests the MBS session resource of the second access network device so that the second access network device can receive MBS session data.

The first access network device can request MBS session resources from the second access network device in any of the following possible implementations:

In a first possible implementation, the first access network device sends at least one of the following to the second access network device: an MBS session ID, an MBS area session ID, and an MBS service area corresponding to one or more MBS sessions, to request the second access network device to establish MBS session resources. The second access network device then sends the MBS session ID and Xn-U tunnel information associated with one or more MBS sessions to the first access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device, thereby enabling the first access network device to forward MBS session data to the second access network device.

In a second possible implementation, the core network sends at least one of the following to the second access network device: the identifier of the source cell, the MBS session ID corresponding to one or more MBS sessions, the MBS area session ID, and the MBS service area. This requests the second access network device to establish MBS session resources. The source cell is the geographical area or cell corresponding to the MBS session provided by the current first access network device. The identifier of the source cell can be the identifier information of the geographical area, such as the mapped cell ID, or it can be the identifier of the cell, such as PCI, CGI, etc., without limitation. The second access network device sends the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS sessions to the first access network device, thereby enabling the first access network device to forward MBS session data to the second access network device.

In a third possible implementation, the first access network device sends at least one of the following to the second access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions, in order to request the second access network device to establish MBS session resources. The second access network device then sends the MBS session ID and the NG-U tunnel information associated with one or more MBS sessions to the core network device, thereby enabling the core network to send MBS session data to the second access network device.

In this embodiment, one or more MBS session resource information can be established between the first access network device and the core network. The first access network device requests the MBS session resource of the second access network device, thereby enabling the sending of MBS session data to the second access network device. This eliminates the need to release the MBS session resource between the first access network device and the core network and establish the MBS session resource between the second access network device and the core network when the cell is changed, thus avoiding a large amount of signaling overhead and reducing data transmission latency.

For the method embodiment shown in Figure 11, specific implementation methods and beneficial effects can be referred to the description in Figures 12-14 below. That is to say, the embodiments shown in Figures 12-14 are specific implementations of the embodiment shown in Figure 11. To avoid redundancy, they will not be described again in the embodiment of Figure 11. Among them, the method embodiment in Figure 12 can correspond to the first possible implementation of the first access network device requesting the MBS session resources of the second access network device in step S1102 above; the method embodiment in Figure 13 can correspond to the second possible implementation of the first access network device requesting the MBS session resources of the second access network device in step S1102 above; and the method embodiment in Figure 14 can correspond to the third possible implementation of the first access network device requesting the MBS session resources of the second access network device in step S1102 above.

In the embodiments of this application (as shown in Figures 12-14 below), the method can be illustrated by taking a first access network device, a second access network device, and a core network device as the execution subjects for interaction. The first access network device can be understood as a source access network device/old access network device, the second access network device can be understood as one or more candidate access network devices, and the core network device can include access and mobility management function (AMF) entities (e.g., AMF network elements) and multicast/broadcast user plane entities (e.g., MB-UPF network elements). The following description uses AMF network elements, MB-UPF network elements, etc., as examples, but does not substantially limit the names of these network elements.

Another communication method provided by an embodiment of this application will be described below. Please refer to FIG12, which is an interactive schematic diagram of a communication method provided by an embodiment of this application. As shown in FIG12, the communication method may include S1201-S1205.

S1201: The AMF network element sends a first indication message to the first access network device. The first indication message is used to indicate one or more MBS session information. Correspondingly, the first access network device receives the first indication message from the AMF network element.

The AMF network element can send first indication information to the first access network device. That is, the AMF network element can indicate one or more MBS session information (or a list of MBS session information) to the first access network device. Each MBS session information in the one or more MBS session information includes at least one of the following: MBS session identifier ID, MBS service area, MBS area session ID, and the cell identifier to which the forwarded data is sent. For a detailed description, please refer to the description in S1101 above; it will not be repeated here.

S1202: The first access network device sends a second indication message to the AMF network element. The second indication message indicates the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions. Correspondingly, the AMF network element receives the second indication message from the first access network device.

After receiving the first indication information from the AMF network element, the first access network device can send the second indication information to the AMF network element. That is, the first access network device can indicate one or more MBS session resource information (or may be called a list of MBS session resource information) to the AMF network element. Each MBS session information may include the MBS session ID and the NG-U tunnel information associated with the MBS session PDU. The NG-U tunnel information is used by the core network device to transmit MBS session data to the first access network device. For example, the first access network device can receive MBS session data from the MB-UPF network element.

It should be noted that the execution order of steps S1201 and S1202 described above is not limited in this embodiment. For example, in the case of broadcast service, the AMF network element can initiate an MBS session resource establishment process to request the first access network device to establish an MBS session resource and receive a response message from the first access network device; in the case of multicast service, the first access network device can initiate an MBS session NG-U transmission establishment request message to the AMF network element and receive an acknowledgment message from the AMF network element.

S1203: The first access network device sends at least one of the following to the second access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions. Correspondingly, the second access network device receives at least one of the following from the first access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions.

The first access network device may send at least one of the following to the second access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions. This can be sent via the NG port or the Xn port to request the second access network device to establish MBS session resources.

One possible implementation is that the first access network device can determine the second access network device requesting the establishment of MBS session resources based on the cell identifier to which the forwarded data is sent in the first indication information of the AMF network element in step S1201 above. Another possible implementation is that the first access network device can determine the second access network device requesting the establishment of MBS session resources based on the area served or to be served by the second access network device. After determining the second access network device, at least one of the following is sent to these second access network devices: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions. This can be understood as the AMF network element or the first access network device determining that the area served or to be served by the second access network device overlaps with the MBS service area, and requesting the second network device to establish MBS session resources so that the second network device can receive MBS data from the core network and send MBS data to the terminal device.

S1204: The second access network device sends the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS sessions to the first access network device. Correspondingly, the first access network device receives the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS sessions from the second access network device.

After receiving at least one of the MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions from the first access network device, the second access network device may send the MBS session ID and Xn-U tunnel information associated with the MBS sessions to the first access network device. Optionally, after receiving at least one of the MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions from the first access network device, if the second access network device accepts one or more MBS sessions, it may send the MBS session ID and Xn-U tunnel information associated with the MBS sessions to the first access network device.

Among them, the Xn-U tunnel information is the Xn user plane transport layer information, which can be used by the first access network device to transmit MBS session data to the second access network device.

S1205: The first access network device sends the cell identifier for data forwarding to the AMF network element.

After the first access network device receives the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS session from the second access network device in step S1204 above, or when the first access network device decides to forward data to the second access network device, the first access network device may send the cell identifier for data forwarding to the AMF network element.

When the second access network device is serving the first area/first beam in the MBS service area corresponding to one or more MBS sessions, it can receive MBS session data from the first access network device and send MBS session data to the terminal devices in that area.

In this embodiment, the first access network device and the core network can establish one or more MBS session resource information. The first access network device and the second access network device negotiate whether to support data forwarding, and indicate candidate cells for data forwarding to the core network. The first access network device forwards data to the second access network device to provide MBS session data. This avoids the establishment of NG-U resources between the core network and the second access network device and the release of NG-U resources between the core network and the first access network device, avoids a large amount of signaling overhead, and reduces data transmission latency.

The following describes another communication method provided by an embodiment of this application. Please refer to FIG13, which is an interactive schematic diagram of another communication method provided by an embodiment of this application. As shown in FIG13, the communication method may include S1301-S1305.

S1301: The AMF network element sends a first indication message to the first access network device. The first indication message is used to indicate one or more MBS session information. Correspondingly, the first access network device receives the first indication message from the AMF network element.

The AMF network element can send first indication information to the first access network device. That is, the AMF network element can indicate one or more MBS session information (or a list of MBS session information) to the first access network device. Each MBS session information in the one or more MBS session information includes at least one of the following: MBS session identifier ID, MBS service area, and MBS area session ID. For a detailed description, please refer to the description in S1101 above; it will not be repeated here.

S1302: The first access network device sends a second indication message to the AMF network element. The second indication message indicates the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions. Correspondingly, the AMF network element receives the second indication message from the first access network device.

After receiving the first indication information from the AMF network element, the first access network device can send the second indication information to the AMF network element. That is, the first access network device can indicate one or more MBS session resource information (or may be called a list of MBS session resource information) to the AMF network element. Each MBS session information may include the MBS session ID and the NG-U tunnel information associated with the MBS session PDU. The NG-U tunnel information is used by the core network device to transmit MBS session data to the first access network device. For example, the first access network device can receive MBS session data from the MB-UPF network element.

It should be noted that the execution order of steps S1201 and S1202 described above is not limited in this embodiment. For example, in the case of broadcast service, the AMF network element can initiate an MBS session resource establishment process to request the first access network device to establish an MBS session resource and receive a response message from the first access network device; in the case of multicast service, the first access network device can initiate an MBS session NG-U transmission establishment request message to the AMF network element and receive an acknowledgment message from the AMF network element.

S1303: The AMF network element sends at least one of the following to the second access network device: the identifier of the source cell, the MBS session ID corresponding to one or more MBS sessions, the MBS area session ID, and the MBS serving area. Correspondingly, the second access network device receives at least one of the following from the AMF network element: the identifier of the source cell, the MBS session ID corresponding to one or more MBS sessions, the MBS area session ID, and the MBS serving area.

An AMF network element can send at least one of the following to a second access network device: the identifier of the source cell, the MBS session ID corresponding to one or more MBS sessions, the MBS area session ID, and the MBS service area, to request the second access network device to establish MBS session resources. The source cell is the cell corresponding to the geographical area or cell identifier information provided by the current first access network device for the MBS session. The source cell identifier can be one of the following: a mapped cell ID, PCI, CGI, or geographical area information, representing the geographical area or cell identifier information provided by the current first access network device for the MBS session. Each mapped cell ID corresponds to a fixed geographical location. In addition to the above representation methods, the geographical area information can also include an area ID.

S1304: The second access network device sends the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS sessions to the first access network device. Correspondingly, the first access network device receives the MBS session ID corresponding to one or more MBS sessions and the Xn-U tunnel information associated with the MBS sessions from the second access network device.

It is understood that S1304 corresponds to S1204 above. For details, please refer to the description of S1204 above. It will not be repeated here.

When the second access network device is serving the first area/first beam in the MBS service area corresponding to one or more MBS sessions, it can receive MBS session data from the first access network device and send MBS session data to the terminal devices in that area.

In this embodiment, one or more MBS session resource information can be established between the first access network device and the core network. The core network and the second access network device negotiate whether to support data forwarding. The second access network device provides tunnel information to the first access network device to request data forwarding. The first access network device forwards data to the second access network device to provide MBS session data. This avoids the establishment of NG-U resources between the core network and the second access network device and the release of NG-U resources between the core network and the first access network device, avoids a large amount of signaling overhead, and reduces data transmission latency.

The following describes another communication method provided by an embodiment of this application. Please refer to FIG14, which is an interactive schematic diagram of another communication method provided by an embodiment of this application. As shown in FIG14, the communication method may include S1401-S1405.

S1401: The AMF network element sends a first indication message to the first access network device. The first indication message is used to indicate one or more MBS session information. Correspondingly, the first access network device receives the first indication message from the AMF network element.

It is understood that S1401 corresponds to S1301 above. For details, please refer to the description of S1301 above. It will not be repeated here.

S1402: The first access network device sends a second indication message to the AMF network element. The second indication message indicates the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions. Correspondingly, the AMF network element receives the second indication message from the first access network device.

It is understood that S1402 corresponds to S1302 above. For details, please refer to the description of S1302 above. It will not be repeated here.

S1403: The first access network device sends at least one of the following to the second access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions. Correspondingly, the second access network device receives at least one of the following from the first access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions.

The first access network device may send at least one of the following to the second access network device: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions. This can be sent via the NG port or the Xn port to request the second access network device to establish MBS session resources.

Optionally, the first access network device may determine the second access network device requesting the establishment of MBS session resources based on the area served or to be served by the second access network device. After determining the second access network device, the first access network device sends at least one of the following to these second access network devices: the MBS session ID, the MBS area session ID, and the MBS service area corresponding to one or more MBS sessions.

S1404: The second access network device sends the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions to the AMF network element. Correspondingly, the AMF network element receives the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions from the second access network device.

The NG-U tunnel information is used by the core network equipment to transmit MBS session data to the first access network equipment. For example, the first access network equipment can receive MBS session data from the MB-UPF network element.

Optionally, the second access network device may also send the identifier of the source cell managed by the first access network device to the AMF network element to request the AMF network element to change the MBS session from the first access network device to the second access network device.

The AMF network element notifies the MB-UPF network element, which then sends MBS session data to the second access network device, thereby enabling the second access network device to receive MBS session data.

In this embodiment, one or more MBS session resource information can be established between the first access network device and the core network. The first access network device requests the establishment of MBS session resources from the second access network device, the second access network device indicates MBS session tunnel information to the core network, and the core network forwards data to the second access network device to provide MBS session data. The second access network device and the core network can establish NG-U resources in a timely and efficient manner to enable the second access network device to receive MBS session data, reducing the latency of the second access network device sending MBS session data to the terminal device.

The following describes another communication method provided by an embodiment of this application. Please refer to FIG15, which is an interactive schematic diagram of another communication method provided by an embodiment of this application. As shown in FIG15, the communication method may include S1501-S1503.

In the embodiments of this application (such as the embodiment corresponding to Figure 15 below), the method can be illustrated by taking a first access network device, a second access network device, a terminal device, and a core network device as the execution subjects for interaction. The first access network device can be understood as the source access network device/old access network device, the second access network device can be understood as one or more candidate access network devices, and the core network device can include multicast/broadcast user plane entities (e.g., MB-UPF network elements). The following description uses MB-UPF network elements as examples, but the names of these network elements are not actually limited.

S1501: The first access network device sends MBS session data to the terminal device. Correspondingly, the terminal device receives MBS session data from the first access network device.

The cell corresponding to the first access network device supports cell-level, beam-level, or area-level MBS sessions. Cell-level MBS sessions refer to MBS sessions that are universal for terminal devices within the cell. Within the cell's coverage area, terminal devices interested in receiving the MBS session can receive it. Beam-level or area-level MBS sessions refer to MBS sessions sent by the first access network device that are applicable to terminal devices in a specific area or with a specific beam.

S1502: The first access network device sends cell-level, area-level, or beam-level PDCP status information to the second access network device. Correspondingly, the second access network device receives cell-level, area-level, or beam-level PDCP status information from the first access network device.

The PDCP status information is the sequence number of the last PDCP data packet sent.

Beam-level PDCP status information includes the PDCP sequence number for each beam of each MRB, or the PDCP sequence number for each MRB of each beam. Area-level PDCP status information includes the PDCP sequence number for each area of each MRB, or the PDCP sequence number for each MRB of each area. Cell-level PDCP status information includes the PDCP sequence number for each MRB.

Optionally, the first access network device can send cell-level, area-level, or beam-level PDCP status information to the second access network device via the NG port or Xn port.

S1503: The second access network device sends MBS session data to the terminal device.

When the second access network device is in the first area of the MBS service area corresponding to the MBS session, it sends MBS session data to the terminal device. The PDCP packet sequence number of the MBS session data is the PDCP packet sequence number corresponding to the PDCP status information of the first area sent by the first access network device + 1. Alternatively, when the second access network device is in the first beam of the MBS service area corresponding to the MBS session, it sends MBS session data to the terminal device. The PDCP packet sequence number of the MBS session data is the PDCP packet sequence number corresponding to the PDCP status information of the first beam sent by the first access network device + 1.

The MBS session data can be sent from the first access network device to the second access network device (for example, the implementation shown in the method embodiments of Figures 12 and 13 above), or it can be sent from the MB-UPF network element to the second access network device (for example, the implementation shown in the method embodiment of Figure 14 above).

Further optionally, the method embodiment shown in Figure 15 can be combined with any of the method embodiments shown in Figures 12-14. For example, the MBS session data sent by the second access network device to the terminal device in step S1503 can originate from the first access network device (corresponding to the method embodiments shown in Figures 12 and 13) or the core network (corresponding to the method embodiment shown in Figure 14), thereby not only reducing data transmission latency in MBS session data forwarding but also ensuring the continuity of MBS services.

In this embodiment, the first access network device indicates cell-level, area-level, or beam-level PDCP status information to the second access network device. When the second access network device sends MBS session data to the terminal device, it ensures the continuity of the PDCP sequence number. Thus, after a cell change, the MBS session data provided to the terminal device by the new cell is continuous with the MBS session data received by the terminal device in the old cell, thereby ensuring the continuity of MBS services and guaranteeing a lossless user experience.

The method embodiments provided in this application have been described above. The apparatus embodiments related to this application will be described below. It is understood that, in order to implement the functions in the above embodiments, the first access network device and the second access network device include hardware structures and/or software modules corresponding to each function. Those skilled in the art should readily recognize that, based on the units and method steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

Please refer to Figures 16 and 17, which are schematic diagrams of the structure of a communication device provided in an embodiment of this application. These communication devices can be used to implement the functions of the first access network device or the second access network device in the above method embodiments, and therefore can also achieve the beneficial effects of the above method embodiments. The communication device can be the first access network device or the second access network device. The communication device includes modules or units corresponding one-to-one to the methods/operations/steps/actions performed by the first access network device or the second access network device in the above method embodiments. These units can be hardware circuits, software, or a combination of hardware circuits and software. In the embodiments of this application, the communication device can be the access network device shown in Figure 1, or it can be a module (such as a chip) applied to the access network device.

As shown in Figure 16, the communication device 1600 may include a processing unit 1601 and a transceiver unit 1602. The communication device 1600 is used to implement the functions of the first access network device or the second access network device in the method embodiments shown in Figures 11-15 above.

When the communication device 1600 is used to implement the function of the first access network device in the method embodiment shown in FIG11:

Transceiver unit 1602 is used to establish one or more MBS session resource information with core network equipment;

The transceiver unit 1602 is also used to request MBS session resources from the second access network device so that the second access network device can receive MBS session data.

One possible implementation is that the transceiver unit 1602 establishes one or more MBS session resources with the core network equipment, specifically for:

Receive first indication information from core network equipment. The first indication information is used to indicate one or more MBS session information. Each MBS session information includes at least one of the following: MBS session identifier (ID), MBS service area, MBS area session ID, and cell identifier to which the forwarded data is sent.

Send a second indication message to the core network equipment. The second indication message indicates the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS session.

In one possible implementation, the transceiver unit 1602 requests MBS session resources from the second access network device, specifically for: receiving MBS session IDs corresponding to one or more MBS sessions from the second access network device and Xn-U tunnel information associated with the MBS sessions, wherein the Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device.

In one possible implementation, the transceiver unit 1602 is further configured to send to the second access network device at least one of the MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions.

One possible implementation is that the processing unit 1601 is used to determine the second access network device that requests to establish MBS session resources based on the cell identifier to which the forwarded data is sent in the first indication information of the core network device, or based on the area served or to be served by the second access network device.

In one possible implementation, the transceiver unit 1602 is also used to send the cell identifier for data forwarding to the core network device.

In one possible implementation, the transceiver unit 1602 is further configured to send cell-level, region-level, or beam-level PDCP status information to the second access network device, wherein the PDCP status information is the sequence number information of the last PDCP data packet sent.

One possible implementation is that the beam-level PDCP status information is the PDCP sequence number information for each beam of each MRB, or the PDCP sequence number information for each MRB of each beam; the region-level PDCP status information is the PDCP sequence number information for each region of each MRB, or the PDCP sequence number information for each MRB of each region.

One possible implementation is that the cell-level PDCP status information is the PDCP sequence number information for each MRB.

When the communication device 1600 is used to implement the function of the second access network device in the method embodiment shown in FIG11:

The transceiver unit 1602 is used to send the MBS session ID corresponding to one or more MBS sessions and the tunnel information associated with the MBS session;

The transceiver unit 1602 is also used to receive MBS session data.

In one possible implementation, the transceiver unit 1602 is further configured to receive at least one of the MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions from the first access network device.

In one possible implementation, the transceiver unit 1602 is further configured to receive at least one of the following from the core network device: the identifier of the source cell, the MBS session ID corresponding to one or more MBS sessions, the MBS area session ID, and the MBS service area. The source cell provides the geographical area or cell corresponding to the MBS session for the current first access network device.

One possible implementation is that the transceiver unit 1602 sends one or more MBS session IDs and associated tunnel information corresponding to the MBS sessions, specifically for sending one or more MBS session IDs and associated Xn-U tunnel information corresponding to the MBS sessions to the first access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device.

One possible implementation is that the transceiver unit 1602 sends the MBS session ID corresponding to one or more MBS sessions and the tunnel information associated with the MBS sessions, specifically for sending the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions to the core network equipment.

In one possible implementation, the transceiver unit 1602 is further configured to send the identifier of the source cell managed by the first access network device to the core network device, in order to request the core network device to change the MBS session from the first access network device to the second access network device.

In one possible implementation, the transceiver unit 1602 is also used for:

Receive PDCP status information at the cell, region, or beam level from the first access network device, wherein the PDCP status information is the sequence number information of the last PDCP data packet sent;

When serving the first area within an MBS service area corresponding to one or more MBS sessions, the MBS session data is sent to the terminal device, wherein the PDCP packet sequence number of the MBS session data is the PDCP packet sequence number corresponding to the PDCP status information of the first area sent by the first access network device + 1; or...

When serving the first beam in the MBS service area corresponding to one or more MBS sessions, the MBS session data is sent to the terminal device. The PDCP data packet sequence number of the MBS session data is the PDCP data packet sequence number corresponding to the PDCP status information of the first beam sent by the first access network device + 1.

One possible implementation is that the beam-level PDCP status information is the PDCP sequence number information for each beam of each MRB, or the PDCP sequence number information for each MRB of each beam; the region-level PDCP status information is the PDCP sequence number information for each region of each MRB, or the PDCP sequence number information for each MRB of each region.

One possible implementation is that the cell-level PDCP status information is the PDCP sequence number information for each MRB.

For a more detailed description of the above-mentioned processing unit 1601 and transceiver unit 1602, please refer to the relevant description in the method embodiment shown in FIG11.

As shown in Figure 17, a communication device 1700 is provided to implement the functions of the aforementioned first access network device or second access network device. This device can be a communication device or a device used within a communication device. The communication device can be either the first access network device or the second access network device. The device used within the communication device can be a chip system or a chip within the communication device. The chip system can be composed of chips or can include chips and other discrete components.

The communication device 1700 includes at least one processor 1710 for implementing the processing functions of the device (e.g., a first access network device or a second access network device) in the method provided in this application embodiment. The communication device 1700 may also include a communication interface 1720 for implementing the transmit and receive operations of the device (e.g., a first access network device or a second access network device) in the method provided in this application embodiment. In this application embodiment, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface for communicating with other devices via a transmission medium. For example, the communication interface 1720 enables the device in the communication device 1700 to communicate with other devices. The processor 1710 uses the communication interface 1720 to transmit and receive data and is used to implement the methods described in the above method embodiments.

The communication device 1700 may further include at least one memory 1730 for storing program instructions and/or data. The memory 1730 is coupled to the processor 1710. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and may be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 1710 may operate in conjunction with the memory 1730. The processor 1710 may execute program instructions stored in the memory 1730. At least one of the at least one memory may be included in the processor.

This embodiment does not limit the specific connection medium between the communication interface 1720, processor 1710, and memory 1730. In Figure 17, the memory 1730, processor 1710, and communication interface 1720 are connected via a bus, indicated by a thick line. The connection methods between other components are merely illustrative and not intended to be limiting. The bus can be categorized as an address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 17, but this does not imply that there is only one bus or one type of bus.

When the communication device 1700 is specifically a device used for equipment (e.g., a first access network device or a second access network device), for example, when the communication device 1700 is specifically a chip or chip system, the communication interface 1720 can output or receive baseband signals. When the communication device 1700 is specifically a device (e.g., a first access network device or a second access network device), the communication interface 1720 can output or receive radio frequency signals. In the embodiments of this application, the processor can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, which can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

It should be noted that the aforementioned communication interface 1720 can be used to perform the functions of the aforementioned transceiver unit 1602, and the aforementioned processor 1710 can be used to perform the functions of the aforementioned processing unit 1601, which will not be elaborated further here.

When the aforementioned communication device is a chip applied to a first access network device, the first access network device chip implements the functions of the first access network device in the above method embodiment, and the first access network device chip receives information from other network elements; or, the first access network device chip sends information to other network elements.

When the aforementioned communication device is a chip applied to a second access network device, the second access network device chip implements the functions of the second access network device in the above method embodiments. The second access network device chip receives information from other network elements; or, the second access network device chip sends information to other network elements.

It is understood that the processor in the embodiments of this application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in an access network device or terminal. Alternatively, the processor and storage medium can exist as discrete components in the terminal or access network device.

In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a DVD; or it can be a semiconductor medium, such as a solid-state disk (SSD).

In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and/or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed, the method executed by the first access network device or the second access network device in the above method embodiments is implemented.

This application also provides a computer program product, which includes a computer program that, when executed, causes the method executed by the first access network device or the second access network device in the above method embodiments to be implemented. If the constituent modules of the aforementioned devices are implemented as software functional units and sold or used as independent products, they can be stored in the computer-readable storage medium.

This application also provides a chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform some or all of the steps described in any of the method embodiments corresponding to Figures 11-15 above. This chip system may be composed of chips or may include chips and other discrete devices.

This application also provides a communication system, which includes a first access network device or a second access network device. For a detailed description, please refer to the communication method shown in Figures 11-15.

It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

The descriptions of the various embodiments provided in this application can be referenced mutually. Each embodiment has its own emphasis, and parts not described in detail in a certain embodiment can be referred to the relevant descriptions of other embodiments. For the sake of convenience and brevity, for example, the functions and execution steps of the various devices and equipment provided in the embodiments of this application can be referred to the relevant descriptions of the method embodiments of this application. The method embodiments and the device embodiments can also be referenced, combined or cited from each other.

It should be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be a hard disk drive (HDD), a solid-state drive (SSD), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). Memory is any other medium capable of carrying or storing desired program code having the form of instructions or data structures and accessible by a computer, but is not limited thereto. The memory in the embodiments of this application may also be circuitry or any other means capable of implementing storage functions for storing program instructions and/or data.

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

It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor.

It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.

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

Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments provided herein can be implemented in 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. Those skilled in the art can 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.

Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

If the aforementioned functions are implemented as 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 technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

The modules/units in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims (41)

A communication method, characterized in that it is applied to a first access network device, the method comprising: Establish one or more multicast broadcast service (MBS) session resource information with core network equipment; Request MBS session resources from the second access network device so that the second access network device can receive MBS session data. According to the method of claim 1, the step of establishing one or more MBS session resources with the core network equipment includes: Receive first indication information from the core network device. The first indication information is used to indicate one or more MBS session information. Each MBS session information includes at least one of MBS session identifier ID, MBS service area, MBS area session ID, and cell identifier to which the forwarded data is sent. Send a second indication message to the core network device, the second indication message indicating the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS session. According to the method of claim 1 or 2, the MBS session resources requested from the second access network device include: The first access network device receives one or more MBS sessions corresponding to MBS sessions and Xn-U tunnel information associated with the MBS sessions from the second access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device. The method according to claim 3, characterized in that the method further comprises: Send to the second access network device at least one of the following: MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions. The method according to claim 3 or 4, characterized in that the method further comprises: Based on the cell identifier to which the forwarded data is sent in the first instruction information of the core network device, or based on the area served or to be served by the second access network device, the second access network device requesting the establishment of MBS session resources is determined. The method according to any one of claims 1-5, characterized in that the method further comprises: Send the cell identifier for data forwarding to the core network equipment. The method according to any one of claims 1-6, characterized in that the method comprises: Send cell-level, area-level, or beam-level packet data aggregation protocol (PDCP) status information to the second access network device. The PDCP status information is the sequence number information of the last PDCP data packet sent. According to the method of claim 7, the beam-level PDCP status information is the PDCP sequence number information of each beam for each MRB, or the PDCP sequence number information of each MRB for each beam; the region-level PDCP status information is the PDCP sequence number information of each region for each MRB, or the PDCP sequence number information of each MRB for each region. The method according to claim 7 or 8 is characterized in that the cell-level PDCP status information is the PDCP sequence number information of each MRB. A communication method, characterized in that it is applied to a second access network device, the method comprising: Send the MBS session identifier ID corresponding to one or more multicast broadcast service MBS sessions and the tunnel information associated with the MBS session; Receive MBS session data. The method according to claim 10, characterized in that the method further comprises: Receive at least one of the following from the first access network device: MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions. The method according to claim 10, characterized in that the method further comprises: The device receives at least one of the following from the core network equipment: the identifier of the source cell, the MBS session ID corresponding to one or more MBS sessions, the MBS area session ID, and the MBS service area. The source cell provides the geographical area or cell identifier information corresponding to the MBS session for the current first access network equipment. The method according to claim 11 or 12, characterized in that, sending the MBS session ID corresponding to one or more MBS sessions and the tunnel information associated with the MBS session includes: Send one or more MBS session IDs and Xn-U tunnel information associated with the MBS sessions to the first access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device. According to the method of claim 11, the step of sending the MBS session ID corresponding to one or more MBS sessions and the tunnel information associated with the MBS session includes: Send the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions to the core network equipment. The method according to claim 10 or 11, characterized in that the method further comprises: Send the identifier of the source cell managed by the first access network device to the core network device to request the core network device to change the MBS session from the first access network device to the second access network device. The method according to any one of claims 10-13, characterized in that the method further comprises: Receive packet data aggregation protocol PDCP status information from the cell-level, area-level, or beam-level of the first access network device, wherein the PDCP status information is the sequence number information of the last sent PDCP data packet; When serving the first area within an MBS service area corresponding to one or more MBS sessions, the MBS session data is sent to the terminal device, wherein the PDCP packet sequence number of the MBS session data is the PDCP packet sequence number corresponding to the PDCP status information of the first area sent by the first access network device + 1; or... When serving the first beam in the MBS service area corresponding to one or more MBS sessions, the MBS session data is sent to the terminal device. The PDCP data packet sequence number of the MBS session data is the PDCP data packet sequence number corresponding to the PDCP status information of the first beam sent by the first access network device + 1. According to the method of claim 16, the beam-level PDCP status information is the PDCP sequence number information of each beam for each MRB, or the PDCP sequence number information of each MRB for each beam; the region-level PDCP status information is the PDCP sequence number information of each region for each MRB, or the PDCP sequence number information of each MRB for each region. The method according to claim 16 or 17 is characterized in that the cell-level PDCP status information is the PDCP sequence number information of each MRB. A communication device, characterized in that it comprises: The transceiver unit is used to establish one or more multicast broadcast service (MBS) session resource information with core network equipment; The transceiver unit is also used to request MBS session resources from the second access network device so that the second access network device can receive MBS session data. The apparatus according to claim 19, characterized in that the transceiver unit establishes one or more multicast broadcast service (MBS) session resource information with the core network equipment, specifically for: Receive first indication information from the core network device. The first indication information is used to indicate one or more MBS session information. Each MBS session information includes at least one of MBS session identifier ID, MBS service area, MBS area session ID, and cell identifier to which the forwarded data is sent. Send a second indication message to the core network device, the second indication message indicating the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS session. The apparatus according to claim 19 or 20, wherein the transceiver unit requests MBS session resources from the second access network device, specifically for: The first access network device receives one or more MBS sessions corresponding to MBS sessions and Xn-U tunnel information associated with the MBS sessions from the second access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device. The apparatus according to claim 21 is characterized in that the transceiver unit is further configured to send at least one of the MBS session ID, MBS area session ID and MBS service area corresponding to one or more MBS sessions to the second access network device. The apparatus according to claim 21 or 22, characterized in that the apparatus further comprises: The processing unit is configured to determine the second access network device requesting the establishment of MBS session resources based on the cell identifier to which the forwarded data is to be received in the first indication information of the core network device, or based on the area served or to be served by the second access network device. The apparatus according to any one of claims 19-23 is characterized in that the transceiver unit is further configured to send a cell identifier for data forwarding to the core network equipment. The apparatus according to any one of claims 19-24 is characterized in that the transceiver unit is further configured to send cell-level, region-level, or beam-level packet data convergence protocol (PDCP) status information to the second access network device, wherein the PDCP status information is the sequence number information of the last PDCP data packet sent. The apparatus according to claim 25 is characterized in that the beam-level PDCP status information is the PDCP sequence number information of each beam for each MRB, or the PDCP sequence number information of each MRB for each beam; the region-level PDCP status information is the PDCP sequence number information of each region for each MRB, or the PDCP sequence number information of each MRB for each region. The apparatus according to claim 25 or 26 is characterized in that the cell-level PDCP status information is the PDCP sequence number information of each MRB. A communication device, characterized in that it comprises: The transceiver unit is used to send the MBS session identifier ID corresponding to one or more multicast broadcast service MBS sessions and the tunnel information associated with the MBS session; The transceiver unit is also used to receive MBS session data. The apparatus according to claim 28, wherein the transceiver unit is further configured to receive at least one of the MBS session ID, MBS area session ID, and MBS service area corresponding to one or more MBS sessions from the first access network device. The apparatus according to claim 28, wherein the transceiver unit is further configured to receive at least one of the following from the core network device: an identifier of a source cell, an MBS session ID corresponding to one or more MBS sessions, an MBS area session ID, and an MBS service area, wherein the source cell provides the current first access network device with the identifier information of the geographical area or cell corresponding to the MBS session. The apparatus according to claim 29 or 30, characterized in that the transceiver unit transmits one or more MBS session IDs corresponding to MBS sessions and tunnel information associated with the MBS sessions, specifically for: Send one or more MBS session IDs and Xn-U tunnel information associated with the MBS sessions to the first access network device. The Xn-U tunnel information is used by the first access network device to transmit MBS session data to the second access network device. The apparatus according to claim 29, wherein the transceiver unit transmits one or more MBS session IDs corresponding to MBS sessions and tunnel information associated with the MBS sessions, specifically for: Send the MBS session ID corresponding to one or more MBS sessions and the NG-U tunnel information associated with the MBS sessions to the core network equipment. The apparatus according to claim 28 or 29 is characterized in that the transceiver unit is further configured to send the identifier of the source cell managed by the first access network device to the core network device, for requesting the core network device to change the MBS session from the first access network device to the second access network device. The apparatus according to any one of claims 28-33, wherein the transceiver unit is further configured to: Receive packet data aggregation protocol PDCP status information from the cell-level, area-level, or beam-level of the first access network device, wherein the PDCP status information is the sequence number information of the last sent PDCP data packet; When serving the first area within an MBS service area corresponding to one or more MBS sessions, the MBS session data is sent to the terminal device, wherein the PDCP packet sequence number of the MBS session data is the PDCP packet sequence number corresponding to the PDCP status information of the first area sent by the first access network device + 1; or... When serving the first beam in the MBS service area corresponding to one or more MBS sessions, the MBS session data is sent to the terminal device. The PDCP data packet sequence number of the MBS session data is the PDCP data packet sequence number corresponding to the PDCP status information of the first beam sent by the first access network device + 1. The apparatus according to claim 34 is characterized in that the beam-level PDCP status information is the PDCP sequence number information of each beam for each MRB, or the PDCP sequence number information of each MRB for each beam; the region-level PDCP status information is the PDCP sequence number information of each region for each MRB, or the PDCP sequence number information of each MRB for each region. The method according to claim 34 or 35 is characterized in that the cell-level PDCP status information is the PDCP sequence number information of each MRB. A communication device, characterized in that it includes a processor, a memory, an input interface, and an output interface, wherein the input interface is used to receive information from other communication devices besides the communication device, the output interface is used to output information to other communication devices besides the communication device, and when a stored computer program stored in the memory is invoked by the processor, the method described in any one of claims 1-18 is implemented. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program or computer instructions, which, when executed by a processor, cause the method as described in any one of claims 1-18 to be implemented. A computer program product, characterized in that the computer program product includes instructions that, when executed by a processor, cause the method as described in any one of claims 1-18 to be implemented. A chip system, characterized in that it includes at least one processor, a memory, and an interface circuit, wherein the memory, the interface circuit, and the at least one processor are interconnected via circuits, and the at least one memory stores instructions that, when executed by the processor, cause the method described in any one of claims 1-18 to be implemented. A communication system, characterized in that it includes a first access network device and a second access network device, wherein the first access network device is used to implement the method as described in any one of claims 1-9, and the second access network device is used to implement the method as described in any one of claims 10-18.