Method and apparatus for multicast transmission

CN114390449BActive Publication Date: 2026-10-23BEIJING SAMSUNG TELECOM R&D CENT +1
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202011562841.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-10-21
Filing Date
2020-12-25
Publication Date
2026-10-23
Estimated Expiration
2040-12-25

AI Technical Summary

Benefits of technology

[0027]本发明给出的用于组播传输的方法及设备,能够实现组播传输切换。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114390449B_ABST
    Figure CN114390449B_ABST
Patent Text Reader

Abstract

The application provides a method and device for multicast transmission, wherein a first network device performs a method for multicast transmission, comprising: receiving a first message for requesting switching from a second network device; and sending a second message for responding to the first message to the second network device.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to wireless communication technology, and in particular to a method and apparatus for multicast transmission. Background Technology

[0002] To meet the increased demand for wireless data communication services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or near-5G communication systems. Therefore, 5G or near-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems".

[0003] Wireless communication is one of the most successful innovations in modern history. Recently, the number of subscribers to wireless communication services surpassed 5 billion and continues to grow rapidly. The demand for wireless data services is growing rapidly due to the increasing prevalence of smartphones and other mobile data devices (such as tablets, laptops, netbooks, e-book readers, and machine-type devices) among consumers and businesses. To meet the rapid growth of mobile data services and support new applications and deployments, improving the efficiency and coverage of wireless interfaces is crucial. Summary of the Invention

[0004] Technical issues

[0005] When a UE moves, if the UE is receiving a broadcast multicast service (MBS), a data forwarding mechanism for the MBS service is required.

[0006] Solution

[0007] According to one aspect of the present invention, a method for multicast transmission executed by a first network device is provided, comprising: receiving a first message from a second network device for requesting a handover; and sending a second message to the second network device in response to the first message.

[0008] According to an embodiment of the present invention, the first message includes: information about the SN of the multicast data packets transmitted by the second network device, and / or information about forwarding suggestions for multicast services.

[0009] According to an embodiment of the present invention, the information regarding the SN of the multicast data packets transmitted by the second network device includes: PDCP SN information and / or GTP-U SN information.

[0010] According to an embodiment of the present invention, the second message includes: SN information about the multicast data packets transmitted by the first network device, and / or information about an indication to accept forwarding.

[0011] According to an embodiment of the present invention, the information regarding the SN of the multicast data packets transmitted by the first network device includes: PDCP SN information and / or GTP-U SN information.

[0012] According to an embodiment of the present invention, the method further includes: receiving information about the SN of multicast data packets transmitted by the second network device from the second network device, wherein the SN information about the multicast data packets transmitted by the second network device includes: PDCP SN information and / or GTP-U SN information.

[0013] According to an embodiment of the present invention, the method further includes: determining the data to be forwarded by referring to one or more of the SN information of the multicast data packets transmitted by the first network device and the SN information of the multicast data packets transmitted by the second network device.

[0014] According to an embodiment of the present invention, the method further includes: deciding to stop data forwarding; and notifying a second network device to stop data forwarding.

[0015] According to another aspect of the present invention, a method for multicast transmission executed by a second network device is provided, comprising: sending a first message to a first network device for requesting a handover; and receiving a second message from the first network device for responding to the first message.

[0016] According to an embodiment of the present invention, the first message includes: information about the SN of the multicast data packets transmitted by the second network device, and / or information about forwarding suggestions for multicast services.

[0017] According to an embodiment of the present invention, the information regarding the SN of the multicast data packets of the second network device includes: PDCP SN information and / or GTP-U SN information.

[0018] According to an embodiment of the present invention, the second message includes: SN information about the multicast data packets transmitted by the first network device and / or information about an indication to accept forwarding.

[0019] According to an embodiment of the present invention, the information regarding the SN of the multicast data packets transmitted by the first network device includes: PDCP SN information and / or GTP-U SN information.

[0020] According to an embodiment of the present invention, the method further includes: determining the data to be forwarded by referring to one or more of the SN information of the multicast data packets transmitted by the first network device and the SN information of the multicast data packets transmitted by the second network device.

[0021] According to an embodiment of the present invention, it further includes: deciding to stop forwarding data.

[0022] According to an embodiment of the present invention, the method further includes: sending information about the SN of the multicast data packets transmitted by the second network device to the first network device, wherein the SN information about the multicast data packets transmitted by the second network device includes: PDCP SN information and / or GTP-U SN information.

[0023] According to another aspect of the present invention, a first network device for multicast transmission is provided, comprising: a transceiver configured to receive and transmit signals; and a controller configured to perform the methods described in various embodiments of the present invention.

[0024] According to another aspect of the present invention, a second network device for multicast transmission is provided, comprising: a transceiver configured to receive and transmit signals; and a controller configured to perform the methods described in various embodiments of the present invention.

[0025] According to another aspect of the present invention, a method is provided, comprising setting the SN information of PDCP based on the SN information of GTP-U according to one or more predetermined rules.

[0026] Technical effect

[0027] The method and apparatus for multicast transmission provided in this invention can realize multicast transmission switching. Attached Figure Description

[0028] Figure 1 A system architecture diagram for System Architecture Evolution (SAE);

[0029] Figure 2 This is a schematic diagram of the initial overall architecture of 5G;

[0030] Figure 3 This is a schematic diagram of method one of the present invention;

[0031] Figure 4 This is a schematic diagram of method two of the present invention;

[0032] Figure 5 This is a schematic diagram of Embodiment 1 of the present invention;

[0033] Figure 6 This is a schematic diagram of Embodiment 2 of the present invention;

[0034] Figure 7 This is a schematic diagram of Embodiment 3 of the present invention;

[0035] Figure 8 This is a schematic diagram of Embodiment 4 of the present invention;

[0036] Figure 9 This is a schematic diagram of Embodiment 5 of the present invention;

[0037] Figure 10A block diagram of the network device of the present invention; and

[0038] Figure 11 This is a schematic diagram of Embodiment Six of the present invention. Detailed Implementation

[0039] The following discussion Figures 1 to 10 The various embodiments used to describe the principles of this disclosure in this patent document are for illustrative purposes only and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0040] Figure 1 This is an exemplary system architecture 100 of System Architecture Evolution (SAE). User Equipment (UE) 101 is a terminal device used to receive data. Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 102 is a radio access network, including macro base stations (eNodeB / NodeB) that provide the UE with an interface to access the radio network. Mobility Management Entity (MME) 103 is responsible for managing the UE's mobility context, session context, and security information. Serving Gateway (SGW) 104 primarily provides user plane functions; MME 103 and SGW 104 may reside in the same physical entity. Packet Data Network Gateway (PGW) 105 is responsible for functions such as charging and lawful interception, and may also reside in the same physical entity as SGW 104. Policy and Charging Rules Function Entity (PCRF) 106 provides Quality of Service (QoS) policies and charging criteria. Universal Packet Radio Service Support Node (SGSN) 108 is a network node device in the Universal Mobile Telecommunications System (UMTS) that provides routing for data transmission. The Home Subscriber Server (HSS) 109 is the UE's home subsystem, responsible for protecting user information including the UE's current location, the address of the serving node, user security information, and the UE's packet data context.

[0041] Figure 2 This is an exemplary system architecture 200 according to various embodiments of the present disclosure. Other embodiments of the system architecture 200 can be used without departing from the scope of the present disclosure.

[0042] User Equipment (UE) 201 is the terminal equipment used to receive data. Next-Generation Radio Access Network (NG-RAN) 202 is the radio access network, which includes base stations (gNBs or eNBs connected to the 5G core network 5GC; eNBs connected to the 5GC are also called ng-gNBs) that provide the UE with an access radio network interface. Access Control and Mobility Management Function Entity (AMF) 203 is responsible for managing the UE's mobility context and security information. User Plane Function Entity (UPF) 204 primarily provides user plane functions. Session Management Function Entity (SMF) 205 is responsible for session management. Data Network (DN) 206 includes services such as operator services, internet access, and third-party services.

[0043] In the following embodiments, a 5G system is used as an example, the access network control plane is described using CU-CP (Centralized Unit-Control Plane) as an example, the access network user plane is described using CU-UP (Centralized Unit-User Plane) as an example, and the distributed unit is described using DU (Distributed Unit) as an example. The method is also applicable to corresponding entities in other systems.

[0044] When a UE moves, if it is receiving a Broadcast Multicast Service (MBS), the source base station will send the buffered data to the destination base station to reduce data loss. The data forwarding mechanism for MBS services differs from that for ordinary service data.

[0045] This invention provides a method and device for switching to receive multicast transmissions.

[0046] The method and device for multicast transmission provided by this invention can ensure service continuity during multicast transmission switching, avoid or reduce the additional overhead of multicast data transmission, improve the utilization efficiency of access network resources and / or air interface resources, reduce transmission latency, reduce data loss, reduce the latency caused by switching, and reduce unnecessary data transmission.

[0047] Method 1:

[0048] Figure 3 This is a schematic diagram of Method 1 of the present invention.

[0049] Step 301: The source base station sends a handover request to the destination base station. The message carries the identifier of the MBS service that the UE is receiving or is interested in, the identifier of the radio bearer of the MBS service, and / or a forwarding suggestion for the MBS service. The message may also contain the SN information contained in the MBS data packet of the source base station.

[0050] Step 302: The destination base station decides whether MBS data forwarding is required. If so, the handover confirmation message sent by the destination base station to the source base station includes an indication to accept forwarding, and / or includes the SN information corresponding to the data already sent or being sent by the destination base station, or includes the SN corresponding to the forwarded data packet suggested by the destination base station.

[0051] In another implementation, the destination base station can send a separate message to the source base station, carrying the SN information corresponding to the data that the destination base station has already sent and / or is sending, or carrying the SN information corresponding to the forwarded data suggested by the destination base station.

[0052] Step 303: The source base station determines when to stop data forwarding based on the SN contained in the MBS data packets currently being sent (already sent and / or being sent) by the destination base station.

[0053] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0054] Method 2:

[0055] Figure 4 This is a schematic diagram of method two of the present invention.

[0056] Step 401: The source base station sends a handover request to the destination base station. The message carries the identifier of the MBS service that the UE is receiving or is interested in, the identifier of the radio bearer of the MBS service, and / or a forwarding suggestion for the MBS service.

[0057] Step 402: The destination base station decides whether it needs MBS data forwarding. If so, it includes an indication to accept forwarding in the handover confirmation message sent by the destination base station to the source base station.

[0058] In step 403, when the destination base station decides to stop forwarding, it sends a message to the source base station to notify it that data forwarding has stopped. Alternatively, when the destination base station decides to stop forwarding, it discards the forwarded data packets and begins sending data packets from the core network. The source base station then decides when to stop sending data.

[0059] In Method 1 and Method 2, the SN can be either a GTP-u SN or a PDCP SN. The PDCP SN and GTP-u SN have a corresponding relationship, either a one-to-one correspondence or a mapping of the GTP-u SN to the PDCP SN according to a predetermined rule.

[0060] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0061] Example 1

[0062] Figure 5 This is a schematic diagram of Embodiment 1 of the present invention.

[0063] When the UE switches Figure 5 An example of method one for maintaining business continuity is described, such as... Figure 5 As shown in Example 1. When a UE moves from a source base station to a destination base station, if the source base station is receiving MBS, the UE still needs to continue receiving MBS after moving to the destination base station. Ideally, no MBS data should be lost during the handover process, allowing the UE to continuously receive data. For unicast services, when a UE moves to the destination base station, the core network stops sending data to the source base station, notifying the source base station that data transmission has stopped, and a specific data packet is marked as the last data packet, indicating that data transmission has stopped. However, for an MBS service, the destination base station may already be sending data in point-to-multipoint transmission mode, while the source base station also needs to continue MBS transmission. Data transmission will not end simply because a UE moves away. Therefore, the source base station needs to continue receiving data from the core network and cannot obtain a data stop instruction from the core network. Thus, the source base station does not know when to end data forwarding. According to this example, when the source base station receives the SN information sent by the destination base station, it can forward the data packets that the destination base station has not yet sent to the destination base station based on the SN information and decide when to end data forwarding. This reduces data forwarding and ensures continuous data transmission and reception. Example 1 describes this process; detailed descriptions of steps unrelated to this invention are omitted here. Example 1 includes the following steps:

[0064] Step 501: The source base station sends a handover request message to the destination base station.

[0065] The message carries the session identifier of each requested PDU session, information on the QoS flows contained in the PDU session, DRB information, etc. If the UE is receiving MBS, the message also includes the MBS identifier, forwarding suggestions for the MBS service, or forwarding suggestions set for the radio bearer of each MBS. The message also includes the session identifier corresponding to the MBS, information on the QoS flows corresponding to the MBS, configuration information of the DRB transmitting the MBS, and the mapping configuration information of the QoS flows to the MRB of the MBS at the source base station. The message may also include the SN information of the source base station transmitting the MBS data; the SN information may include the PDCP SN and / or the GTP-U SN.

[0066] -PDCP SN. Specifically, it can be one or more of the following information:

[0067] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0068] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0069] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0070] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0071] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0072] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0073] -GTP-U SN. Specifically, it can be one or more of the following information:

[0074] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0075] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0076] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0077] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0078] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0079] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0080] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0081] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0082] The destination base station determines whether to send a message to the core network requesting MBS data transmission based on whether the destination cell is already transmitting MBS. If the destination cell has already received MBS from the core network, the destination base station sends a response message to the source base station.

[0083] If the destination cell on the destination base station has not yet received MBS data from the core network, the destination base station sends a message to the core network requesting the core network to send the MBS data. The process of establishing an MBS bearer is described in other embodiments. The destination base station sends a response message to the source base station.

[0084] Step 502: The destination sends a handover request response message. This message includes a destination-to-source transparent transmitter. The destination-to-source transparent transmitter contains the RRC message sent by the destination base station to the UE.

[0085] The message also includes information about a successfully established PDU session. This PDU session information includes the PDU session identifier, the identifier of a successfully established DRB, the identifier of a successfully established MBS, and the identifier of a successfully established MRB. If the destination base station is transmitting MBS services, either point-to-point or point-to-multipoint, the message also includes indications from the destination base station regarding whether MBS data forwarding is necessary, the PDCP SN information corresponding to the forwarded data suggested by the destination base station, and / or the GTP-U SN. The destination base station can refer to multiple pieces of information to decide whether data forwarding is necessary. For example, referring to the SN information of the source base station sending MBS data received from step 501, the destination base station can decide whether to forward the data. For instance, if the source base station's SN indicating the highest GTP-U SN currently being transmitted is 80, and the destination base station is currently transmitting a GTP-U SN of 100, then the destination base station decides that data forwarding is necessary.

[0086] Depending on whether the QoS flow mapping of the MBS service determined by the destination base station to the MRB (or DRB) is the same as that of the source base station, the destination base station can send different sequence numbers. For example, if the QoS flow mapping of the MBS service determined by the destination base station to the MRB (or DRB) is the same as that of the source base station, and the data packet content corresponding to the same PDCP SN of the destination and source base stations is the same, then the PDCP SN can be sent to the source base station; if the mapping configuration is different, and the data packet content corresponding to the same PDCP SN of the destination and source base stations is different, then the GTP-u SN can be sent. In implementation, for simplicity, a point-to-multipoint radio data bearer MRB can also be established for one MBS service, in which case the mapping between the source and destination base stations is the same.

[0087] Specifically, the PDCP SN information and / or GTP-U SN information can be one or more of the following:

[0088] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0089] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0090] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0091] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0092] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0093] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0094] ■ The PDCP SN set by the base station indicates the highest PDCP SN corresponding to the downlink PDCP data packet that needs to be forwarded;

[0095] ■ The PDCP SN list set by the base station indicates the list of PDCP SNs corresponding to the downlink PDCP data packets that need to be forwarded. It can also indicate a range of SNs, such as the lowest and highest PDCP SNs.

[0096] -GTP-U SN. Specifically, it can be one or more of the following information:

[0097] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0098] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0099] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0100] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0101] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0102] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0103] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0104] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0105] ■ The GTP-U SN set by the base station indicates the highest GTP-U SN corresponding to the downlink data packet that needs to be forwarded;

[0106] ■ The GTP-U SN list set by the base station indicates the GTP-U list corresponding to the downlink data packets that need to be forwarded. It can also indicate a range of SNs, such as the lowest and highest GTP-U SNs.

[0107] Step 503: The source base station sends a handover execution command to the UE via an RRC reconfiguration message.

[0108] The message carries information about the PDU session configuration that the UE needs to establish at the destination base station. It may also include the MBS service identifier received by the destination base station, the MBS channel mode indication information, and the MBS point-to-point channel configuration information and / or point-to-multipoint channel configuration information.

[0109] Step 504: The source base station sends the SN status transmission to the destination base station.

[0110] If step 501 does not include information about the PDCP SN corresponding to the MBS data received by the UE at the source base station, then step 503 can be used to send the PDCP SN and / or GTP-U SN corresponding to the MBS data in a separate message:

[0111] -PDCP SN. Specifically, it can be one or more of the following information:

[0112] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0113] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0114] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0115] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0116] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0117] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0118] -GTP-U SN. Specifically, it can be one or more of the following information:

[0119] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0120] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0121] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0122] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0123] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0124] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0125] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0126] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0127] Step 505: The source base station forwards MBS data to the destination base station. Based on the SN information corresponding to the forwarded data suggested by the destination base station (the SN information can be a PDCP SN or a GTP-u SN, as shown above), the source base station determines which data needs to be forwarded and when to end the forwarding process. For example, if the highest GTP-u SN suggested by the destination base station is set to 100, and the source base station is currently sending data packet 80, then the source base station forwards data packets 80 to 100 to the destination base station. To ensure continuous data reception, the destination base station can temporarily establish a point-to-point transmission mode for the UE, sending the forwarded data to the UE through a point-to-point channel. Afterwards, the UE can switch to point-to-multipoint mode to receive data. When data forwarding ends, the source base station can indicate the end of data forwarding on the user plane, or indicate that the forwarded data packet is the last data packet.

[0128] Step 506: The UE sends an RRC reconfiguration complete message to the destination base station to indicate that the handover is complete.

[0129] Step 507: The destination base station sends a path switching request message to the core network.

[0130] When the UE is the first user to need to receive MBS at the destination base station, and the destination base station has not yet received MBS data from the core network, the destination base station can request the transmission of MBS data through the message in step 507. The message in step 507 carries MBS information, such as the MBS identifier, requesting the core network to send MBS data to the base station. In response to receiving the message in step 507, the core network begins sending an MBS service start message to the base station, and the base station sends a corresponding message to the core network. Afterwards, the core network can begin sending MBS data to the base station. The destination base station first sends the forwarded data received from the source base station, and then sends the new data received from the core network.

[0131] Step 508: The core network sends a path switching response message to the destination base station.

[0132] Step 509: The destination base station sends the UE context release to the source base station to release the UE context information on the source base station.

[0133] Example 1 can be used where the source base station transmits MBS data using a point-to-point channel or a point-to-multipoint channel, and the destination base station transmits MBS data using a point-to-multipoint channel. It can also be applied to other situations.

[0134] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0135] Example 2

[0136] Figure 6 This is a schematic diagram of Embodiment 2 of the present invention.

[0137] When the UE switches Figure 6 An example of method one for maintaining business continuity is described, such as... Figure 6 (Example 2) As shown. When the UE moves from the source base station to the destination base station, if it is receiving MBS at the source base station, it also needs to continue receiving MBS upon moving to the destination base station. Ideally, no MBS data should be lost during the handover process, allowing the UE to continuously receive data. In summary, this invention involves the destination base station sending a forwarding stop instruction to the source base station, causing the source base station to stop data forwarding. Alternatively, the destination base station determines which data to discard based on the SN corresponding to the forwarded data packet, and the source base station decides when to stop data forwarding based on its implementation, such as using a clock. This reduces data forwarding and ensures continuous data transmission and reception. Example 2 describes this process; detailed descriptions of steps unrelated to this invention are omitted here. The process includes the following steps:

[0138] Step 601: The source base station sends a handover request message to the destination base station.

[0139] The message carries the session identifier of each requested PDU session, QoS flow information contained in the PDU session, DRB information, etc. If the UE is receiving MBS, the message also includes the MBS identifier, forwarding suggestions for the MBS service, or forwarding suggestions set for the radio bearer of each MBS. The message also includes the session identifier corresponding to the MBS, QoS flow information corresponding to the MBS, DRB configuration information for transmitting the MBS, and the mapping configuration information of the QoS flow to the MRB of the MBS at the source base station. The message may also include the SN information of the source base station transmitting the MBS data; the SN information may include the PDCP SN and / or the GTP-U SN. For specific information, please refer to the description in Embodiment 1 above.

[0140] The destination base station determines whether to send a message to the core network requesting MBS data transmission based on whether the destination cell is already transmitting MBS. If the destination cell has already received MBS from the core network, the destination base station sends a response message to the source base station.

[0141] If the target cell on the target base station has not yet received MBS data from the core network, the target base station sends a message to the core network requesting the core network to send MBS data. The process of establishing an MBS bearer has been described in other embodiments and will not be repeated here. The target base station sends a response message to the source base station.

[0142] Step 602: The destination sends a handover request response message. This message includes a destination-to-source transparent transmitter. The destination-to-source transparent transmitter contains the RRC message sent by the destination base station to the UE.

[0143] The message also contains information about a successfully established PDU session. This PDU session information includes the PDU session identifier, the identifier of the successfully established DRB, the identifier of the successfully established MBS, and the identifier of the successfully established MRB. The message also includes indications from the destination base station regarding whether MBS data forwarding is necessary.

[0144] Step 603: The source base station sends a handover execution command to the UE via an RRC reconfiguration message.

[0145] The message carries information about the PDU session configuration that the UE needs to establish at the destination base station. It may also include the MBS service identifier received by the destination base station, the MBS channel mode indication information, and the MBS point-to-point channel configuration information and / or point-to-multipoint channel configuration information.

[0146] Step 604: The source base station sends the SN status transmission to the destination base station.

[0147] If step 601 does not include information about the PDCP SN corresponding to the MBS data received by the UE at the source base station, then step 604 can be used to send the PDCP SN and / or GTP-U SN corresponding to the MBS data in a separate message. For details, please refer to the description in Example 1 above. This step can also be omitted if needed.

[0148] Step 605: The source base station forwards MBS data to the destination base station. To send the forwarded data to the UE, the destination base station can establish a point-to-point transmission mode for the UE and send the forwarded data to the UE via a point-to-point channel. After all the forwarded data has been sent to the UE, the UE can switch to point-to-multipoint or continue receiving MBS data via the point-to-point channel, depending on further decisions made by the destination base station. When data forwarding ends, the source base station can indicate the end of data forwarding in the user plane, or indicate that the forwarded data packet is the last data packet.

[0149] Step 606: The UE sends an RRC reconfiguration complete message to the destination base station to indicate that the handover is complete.

[0150] Step 607: The destination base station sends a path switching request message to the core network.

[0151] When the UE is the first user to need to receive MBS at the destination base station, and the destination base station has not yet received MBS data from the core network, the destination base station can request the transmission of MBS data through the message in step 607. The message in step 607 carries MBS information, such as the MBS identifier, requesting the core network to send MBS data to the base station. In response to receiving the message in step 607, the core network begins sending an MBS service start message to the base station, and the base station sends a corresponding message to the core network. Afterwards, the core network can begin sending MBS data to the base station. The destination base station first sends the forwarded data received from the source base station, and then sends the new data received from the core network.

[0152] Step 608: The core network sends a path switching response message to the destination base station.

[0153] Step 609: The destination base station sends a message to the source base station indicating that data forwarding has stopped.

[0154] After step 607, the core network begins sending data to the destination base station. Upon receiving the data from the core network, the destination base station obtains the GTP-U SN contained in the packet header. Based on the SN in the header of the forwarded data packet and the GTP-U SN sent by the core network, it decides when forwarding is no longer necessary. Alternatively, upon receiving a handover request message from the UE, and having already received the MBS data packet from the core network, the destination base station can decide whether to stop data forwarding based on the SN in the header of the forwarded data packet and the GTP-U SN received from the core network. When the destination base station decides to stop forwarding, it sends a message to the source base station notifying it to stop data forwarding, and the source base station then stops forwarding data to the destination base station. Alternatively, the destination base station can send a data forwarding stop indication message to the source base station via the user plane.

[0155] Alternatively, based on the serial number (SN) included in the header of the forwarded data packets and the GTP-U SN received from the core network, the destination base station decides which forwarded data packets to drop and begins transmitting data packets from the core network. Depending on the implementation method used by the source base station, it determines when to stop data forwarding; for example, based on a predetermined data forwarding clock, the source base station stops forwarding data when the forwarding clock expires.

[0156] In step 610, the destination base station sends a UE context release message to the source base station to release the UE's context information on the source base station. Steps 609 and 610 can also be combined into a single message.

[0157] Example 2 can be used where the source base station transmits MBS data using a point-to-point channel or a point-to-multipoint channel, and the destination base station transmits MBS data using a point-to-multipoint channel. It can also be applied to other situations.

[0158] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0159] Example 3

[0160] Figure 7 This is a schematic diagram of Embodiment 3 of the present invention.

[0161] This invention also includes embodiments of a second method for maintaining service continuity during UE handover, such as... Figure 7 (Example 3) As shown. When the UE moves from the source base station to the destination base station, if it is receiving MBS at the source base station, it also needs to continue receiving MBS after moving to the destination base station. During the handover process, it is best that no MBS data is lost, and the UE can continuously receive data. In summary, the present invention involves the following steps: Step 1: The source base station notifies the destination base station of the sequence number (SN) corresponding to the packet sent by the source base station. The destination base station can decide whether to forward the data based on this. Step 2: The destination base station notifies the source base station to accept forwarding, and carries the SN information corresponding to the data already sent or being sent by the destination base station, or carries the SN information corresponding to the forwarded data suggested by the destination base station. Based on this, the source base station can decide which data needs to be forwarded, or when the data forwarding ends. Because for unicast services, when the UE moves to the destination base station, the core network will stop sending data to the source base station, notifying the source base station that data transmission has stopped, and a certain data packet is marked as the last data packet, indicating that data transmission has stopped. However, for an MBS service, the destination base station may already be sending data in point-to-multipoint transmission mode, while the source base station also needs to continue MBS transmission. Data transmission will not end simply because a UE leaves. Therefore, the source base station continues to receive data from the core network and cannot obtain an indication that data transmission has stopped from the core network. Consequently, the source base station does not know when to end data forwarding. According to this embodiment, when the source base station receives the SN information sent by the destination base station, it can forward the data packets that the destination base station has not yet sent to the destination base station according to the indication and decide when to end data forwarding. This reduces data forwarding and ensures continuous data transmission and reception. Embodiment 3 describes this process applied to a discrete architecture; detailed descriptions of steps unrelated to this invention are omitted here. Embodiment 3 includes the following steps:

[0162] Step 701: The source base station CU-CP initiates a handover request message to the destination base station CU-CP.

[0163] The message carries the session identifier of each requested PDU session, information on the QoS flows contained in the PDU session, DRB information, etc. If the UE is receiving an MBS, the message also includes the MBS identifier, forwarding suggestions for the MBS service, or forwarding suggestions set for the radio bearer of each MBS. The message also includes the session identifier corresponding to the MBS, information on the QoS flows corresponding to the MBS, mapping of QoS flows to MRB and / or QoS flows to DRB, configuration information of the MRB and / or DRB for transmitting the MBS, etc.

[0164] The destination base station determines whether to send a message to the core network requesting MBS data transmission based on whether the destination cell is already transmitting MBS. If the destination cell has already received MBS from the core network, the destination base station sends a response message to the source base station.

[0165] If the destination cell on the destination base station has not yet received MBS data from the core network, the destination base station sends a message to the core network requesting the core network to send the MBS data. The process of establishing an MBS bearer is described in other embodiments. The destination base station sends a response message to the source base station.

[0166] Step 702: The destination CU-CP initiates a bearer establishment request message to the destination CU-UP. Depending on whether the QoS flow mapping of the MBS service to the MRB (or DRB) determined by the destination CU-CP is the same as the QoS flow mapping to the MRB (or DRB) of the source base station, the destination CU-CP can instruct the CU-UP in this message which sequence number to send to the destination CU-CP. For example, if the mapping configuration is the same, and the data packet content corresponding to the same PDCP SN of the destination and source base stations is the same, then the CU-CP instructs the CU-UP to send the PDCP SN to the CU-CP; if the mapping configuration is different, then the CU-CP instructs the CU-UP to send the GTP-u SN to the CU-CP.

[0167] The message includes the MBS identifier, forwarding suggestions for MBS services, or forwarding suggestions for each MBS radio bearer. It also includes the session identifier corresponding to the MBS, QoS flow information for the MBS, and DRB configuration information for transmitting the MBS. The message may also contain the QoS flow mapping configuration information from the source base station to the MRB for the MBS. Depending on whether the QoS flow mapping from the destination CU-CP to the MRB (or DRB) for the MBS service is the same as the QoS flow mapping from the source base station to the MRB (or DRB), the destination CU-UP can decide which sequence number to send to the destination CU-CP.

[0168] Step 703: The destination CU-UP initiates a bearer establishment response message to the destination CU-CP.

[0169] The message carries information about a successfully established PDU session, including identifiers for a successfully established DRB, MBS, and MRB. It also contains indications from the destination CU-UP regarding whether MBS data forwarding is necessary, and information about the PDCP SN or GTP-U SN corresponding to the forwarded data suggested by the destination CU-UP. Specific SN information can be found in step 705.

[0170] Step 704: Establish the UE context between the target CU-CP and DU. This process is the same as that described in previous embodiments and is omitted here.

[0171] Step 705: The destination CU-CP sends a handover request confirmation message to the source CU-CP. This message includes a destination-to-source transparent transmitter. The destination-to-source transparent transmitter contains the RRC message sent by the destination base station to the UE.

[0172] The message also includes information about a successfully established PDU session. This PDU session information includes the PDU session identifier, the identifier of a successfully established DRB, the identifier of a successfully established MBS, and the identifier of a successfully established MRB. If the destination base station is transmitting MBS services, either point-to-point or point-to-multipoint, the message also includes indications from the destination base station regarding whether MBS data forwarding is necessary, and the PDCP SN information and / or GTP-U SN corresponding to the forwarded data suggested by the destination base station. Specifically, the PDCP SN information and / or GTP-U SN information can be one or more of the following:

[0173] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0174] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0175] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0176] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0177] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0178] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0179] ■ The PDCP SN set by the base station indicates the highest PDCP SN corresponding to the downlink PDCP data packet that needs to be forwarded;

[0180] ■ The PDCP SN list set by the base station indicates the list of PDCP SNs corresponding to the downlink PDCP data packets that need to be forwarded. It can also indicate a range of SNs, such as the lowest and highest PDCP SNs.

[0181] -GTP-U SN. Specifically, it can be one or more of the following information:

[0182] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0183] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0184] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0185] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0186] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0187] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0188] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0189] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0190] ■ The GTP-U SN set by the base station indicates the highest GTP-U SN corresponding to the downlink data packet that needs to be forwarded;

[0191] ■ The GTP-U SN list set by the base station indicates the list of GTP-U SNs corresponding to the downlink data packets that need to be forwarded. It can also indicate a range of SNs, such as the lowest and highest GTP-U SNs.

[0192] Step 706: A UE context modification process is performed between the source CU-CP and DU.

[0193] Step 707: The source CU-CP sends a bearer modification request message to the source CU-UP.

[0194] The message carries the PDCP SN information and / or GTP-U SN information corresponding to the forwarded data received from the destination CU-CP. For details of the SN, please refer to step 705 above.

[0195] Step 708: The source CU-UP sends a bearer modification response message to the source CU-CP.

[0196] The message carries information about the PDCP SN of the source base station or the GTP-U SN. See step 705 for details.

[0197] Step 709: The source CU-CP sends the SN status transmission to the destination CU-CP.

[0198] If step 701 does not include the PDCP SN information corresponding to the MBS data received by the UE at the source base station, then step 709 can be used to send the PDCP SN information corresponding to the MBS data and / or the SN information of the GTP-U in a separate message. For specific SN information, please refer to step 705 above.

[0199] Step 710: The source base station CU-CP sends a handover execution command to the UE via an RRC reconfiguration message.

[0200] The message carries information about the PDU session configuration that the UE needs to establish at the destination base station. It may also include the MBS service identifier received by the destination base station, the MBS channel mode indication information, and the MBS point-to-point channel configuration information and / or point-to-multipoint channel configuration information.

[0201] Step 711: The destination CU-CP sends a bearer modification request message to the destination CU-UP. The message may also include information about the PDCP SN or GTP-u SN received by the destination CP, such as the information received in step 709.

[0202] Step 712: The destination CU-UP sends a bearer modification response message to the destination CU-CP.

[0203] Step 713: The UE sends an RRC reconfiguration complete message to the destination base station to indicate that the handover is complete.

[0204] Step 714: The destination CU-CP sends a path switching request message to the core network.

[0205] When the UE is the first user to need to receive MBS at the destination base station, and the destination base station has not yet received MBS data from the core network, the destination base station can request the transmission of MBS data through the message in step 714. The message in step 714 carries MBS information, such as the MBS identifier, requesting the core network to send MBS data to the base station. In response to receiving the message in step 714, the core network begins sending an MBS service start message to the base station, and the base station sends a corresponding message to the core network. Afterwards, the core network can begin sending MBS data to the base station. The destination base station first sends the forwarded data received from the source base station, and then sends the new data received from the core network.

[0206] Step 715: The core network sends a path switching response message to the destination CU-CP.

[0207] Step 716: The destination CU-CP sends a UE context release message to the source CU-CP.

[0208] Step 717: The source CU-CP sends a bearer release command to the source CU-UP.

[0209] Step 718: The source CU-CP initiates the UE context release process between the CU and DU.

[0210] Step 719: The source CU-UP sends the bearer release completion message to the source CU-CP.

[0211] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0212] Example 4

[0213] Figure 8 This is a schematic diagram of Embodiment 4 of the present invention.

[0214] This invention also includes another embodiment of Method Two for maintaining service continuity during UE handover, such as... Figure 8As shown in Example 4, when a UE moves from a source base station to a destination base station, if it is receiving MBS at the source base station, it also needs to continue receiving MBS upon moving to the destination base station. Ideally, no MBS data should be lost during the handover process, allowing the UE to continuously receive data. In summary, this invention involves the destination base station sending a forwarding stop indication to the source base station, causing the source base station to stop data forwarding. Alternatively, the destination base station determines which data to discard based on the SN corresponding to the forwarded data packet, and the source base station decides when to stop data forwarding based on its implementation, such as using a clock. This reduces data forwarding and ensures continuous data transmission and reception. Example 4 describes this process; detailed descriptions of steps unrelated to this invention are omitted here. Example 4 includes the following steps:

[0215] Step 801: The source base station CU-CP initiates a handover request message to the destination base station CU-CP.

[0216] The message carries the session identifier of each requested PDU session, QoS flow information contained in the PDU session, DRB information, etc. If the UE is receiving an MBS, the message also includes the MBS identifier, forwarding suggestions for the MBS service, or forwarding suggestions set for the radio bearer of each MBS. The message also includes the session identifier corresponding to the MBS, QoS flow information corresponding to the MBS, mapping of QoS flow to MRB and / or QoS flow to DRB, and configuration information of the MRB and / or DRB for transmitting the MBS.

[0217] The destination base station determines whether to send a message to the core network requesting MBS data transmission based on whether the destination cell is already transmitting MBS. If the destination cell has already received MBS from the core network, the destination base station sends a response message to the source base station.

[0218] If the destination cell on the destination base station has not yet received MBS data from the core network, the destination base station sends a message to the core network requesting the core network to send the MBS data. The process of establishing an MBS bearer is described in other embodiments. The destination base station sends a response message to the source base station.

[0219] Step 802: The destination CU-CP initiates a bearer establishment request message to the destination CU-UP. Depending on whether the QoS flow mapping of the MBS service to the MRB (or DRB) determined by the destination CU-CP is the same as the QoS flow mapping to the MRB (or DRB) of the source base station, the destination CU-CP can instruct the CU-UP in this message which sequence number to send to the destination CU-CP. For example, if the mapping configuration is the same, and the data packet content corresponding to the same PDCP SN of the destination and source base stations is the same, then the CU-CP instructs the CU-UP to send the PDCP SN to the CU-CP. If the mapping configuration is different, then the CU-CP instructs the CU-UP to send the GTP-u SN to the CU-CP.

[0220] The message includes the MBS identifier, forwarding suggestions for MBS services, or forwarding suggestions for each MBS radio bearer. It also includes the session identifier corresponding to the MBS, QoS flow information for the MBS, and DRB configuration information for transmitting the MBS. The message may also contain the QoS flow mapping configuration information from the source base station to the MRB for the MBS. Depending on whether the QoS flow mapping from the destination CU-CP to the MRB (or DRB) for the MBS service is the same as the QoS flow mapping from the source base station to the MRB (or DRB), the destination CU-UP can decide which sequence number to send to the destination CU-CP.

[0221] Step 803: The destination CU-UP initiates a bearer establishment response message to the destination CU-CP.

[0222] The message carries information about a successfully established PDU session, a successfully established DRB identifier, a successfully established MBS identifier, and a successfully established MRB identifier. The message also includes indications from the destination CU-UP regarding whether MBS data forwarding is necessary.

[0223] Step 804: Establish the UE context between the target CU-CP and DU. This process is the same as that described in previous embodiments and is omitted here.

[0224] Step 805: The destination CU-CP sends a handover request response message to the source CU-CP. This message includes a destination-to-source transparent transmitter. The destination-to-source transparent transmitter contains the RRC message sent by the destination base station to the UE.

[0225] The message also contains information about a successfully established PDU session. This PDU session information includes the PDU session identifier, the identifier of the successfully established DRB, the identifier of the successfully established MBS, and the identifier of the successfully established MRB. The message also includes indications from the destination base station regarding whether MBS data forwarding is necessary.

[0226] Step 806: A UE context modification process is performed between the source CU-CP and DU.

[0227] Step 807: The source CU-CP sends a bearer modification request message to the source CU-UP.

[0228] The message carries the identifier of the MBS received from the destination CU-CP and the indication information required for the MBS to forward data.

[0229] Step 808: The source CU-UP sends a bearer modification response message to the source CU-CP.

[0230] The message carries information about the PDCP SN or GTP-U SN of the source base station. Specifically, the PDCP SN information and / or GTP-U SN information can be one or more of the following:

[0231] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0232] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0233] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0234] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0235] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0236] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0237] -GTP-U SN. Specifically, it can be one or more of the following information:

[0238] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0239] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0240] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0241] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0242] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0243] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0244] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0245] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0246] Step 809: The source CU-CP sends the SN status transmission to the destination CU-CP.

[0247] If step 801 does not include the PDCP SN information corresponding to the MBS data received by the UE at the source base station, then step 809 can be used to send the PDCP SN information corresponding to the MBS data and / or the SN information of the GTP-U in a separate message. For details of the SN, please refer to step 808 above.

[0248] Step 810: The source base station CU-CP sends a handover execution command to the UE via an RRC reconfiguration message.

[0249] The message carries information about the PDU session configuration that the UE needs to establish at the destination base station. It may also include the MBS service identifier received by the destination base station, the MBS channel mode indication information, and the MBS point-to-point channel configuration information and / or point-to-multipoint channel configuration information.

[0250] Step 811: The destination CU-CP sends a bearer modification request message to the destination CU-UP. The message may also include information about the PDCP SN or GTP-u SN received by the destination CP, such as the information received in step 809.

[0251] Step 812: The destination CU-UP sends a bearer modification response message to the destination CU-CP.

[0252] Step 813: The UE sends an RRC reconfiguration complete message to the destination base station to indicate that the handover is complete.

[0253] Step 814: The destination CU-CP sends a path switching request message to the core network.

[0254] When the UE is the first user to need to receive MBS at the destination base station, and the destination base station has not yet received MBS data from the core network, the destination base station can request the transmission of MBS data through the message in step 814. The message in step 814 carries MBS information, such as the MBS identifier, requesting the core network to send MBS data to the base station. In response to receiving the message in step 814, the core network begins sending an MBS service start message to the base station, and the base station sends a corresponding message to the core network. Afterwards, the core network can begin sending MBS data to the base station. The destination base station first sends the forwarded data received from the source base station, and then sends the new data received from the core network.

[0255] Step 815: The core network sends a path switching response message to the destination CU-CP.

[0256] Step 816: The source CU-UP forwards MBS data to the destination CU-UP. To send the forwarded data to the UE, the destination CU-UP can establish a point-to-point transmission mode for the UE, sending the forwarded data to the UE via a point-to-point channel. After all the forwarded data has been sent to the UE, the UE can switch to point-to-multipoint or continue receiving MBS data via the point-to-point channel, depending on further decisions made by the destination base station. When data forwarding ends, the source CU-UP can indicate the end of data forwarding in the user plane, or indicate that the forwarded data packet is the last data packet.

[0257] Step 817: The destination CU-UP sends a message to the destination CU-CP indicating that data forwarding has stopped.

[0258] After step 814, the core network begins sending data to the destination CU-UP. The destination base station receives the data from the core network and obtains the GTP-u SN contained in the packet header. Based on the SN contained in the header of the forwarded data packet and the GTP-u SN sent by the core network, it decides when forwarding is no longer necessary. Alternatively, upon receiving a bearer establishment message or bearer modification request message from the CU-CP, and after the destination CU-UP has received the MBS data packet from the core network, the destination CU-UP can decide whether to stop data forwarding based on the SN contained in the header of the forwarded data packet and the GTP-u SN received from the core network. When the destination CU-UP decides to stop forwarding, it sends a message to the destination CU-CP to notify it to stop data forwarding. The destination CU-CP then further notifies the source CU-CP, which in turn notifies the source CU-UP that data forwarding has stopped. The source CU-UP then stops forwarding data to the destination CU-UP. Alternatively, the destination CU-UP can send a data forwarding stop indication to the source CU-UP through the user plane. The user plane method is more direct and simpler.

[0259] Alternatively, based on the serial number (SN) included in the header of the forwarded data packets and the GTP-U SN received from the core network, the destination CU-UP decides which forwarded data packets to drop and begins sending data packets from the core network. Depending on the implementation method used by the source CU-UP, it determines when to stop data forwarding; for example, based on a predetermined data forwarding clock, the source CU-UP stops forwarding data when the forwarding clock expires.

[0260] Step 818: The destination CU-CP sends a UE context release message to the source CU-CP. The message contains an indication that data forwarding has stopped. When the destination CU-CP knows that MBS data is being forwarded, it needs to wait for the destination CU-UP to notify that data forwarding has stopped before sending the UE context release message to the source CU-CP.

[0261] Step 819: The source CU-CP sends a bearer release command to the source CU-UP. The message contains an indication that data forwarding has stopped.

[0262] Step 820: The source CU-CP initiates the UE context release process between the CU and DU.

[0263] Step 821: The source CU-UP sends the bearer release completion message to the source CU-CP.

[0264] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0265] Example 5

[0266] Figure 9 This is a schematic diagram of Embodiment 5 of the present invention.

[0267] Another embodiment of Method 1, which describes how to maintain service continuity during UE handover, is described, such as... Figure 9(Example 5) As shown. When a UE moves from a source base station to a destination base station, if it is receiving MBS at the source base station, it also needs to continue receiving MBS upon moving to the destination base station. Ideally, no MBS data should be lost during the handover process, allowing the UE to continuously receive data. For unicast services, when a UE moves to the destination base station, the core network stops sending data to the source base station, notifying it that data transmission has stopped, and a specific data packet is marked as the last data packet, indicating that data transmission has stopped. However, for an MBS service, the destination base station may already be sending data in point-to-multipoint transmission mode, while the source base station also needs to continue MBS transmission. Data transmission will not end simply because a UE moves away. Therefore, the source base station continues to receive data from the core network and cannot obtain an indication of data termination from the core network. Consequently, the source base station does not know when to end data forwarding. According to this embodiment, when the source base station receives the SN information sent by the destination base station, it can forward the data packets that the destination base station has not yet sent to the destination base station based on this information and decide when to end data forwarding. This reduces data forwarding and ensures continuous data transmission and reception. Example 5 describes this process; detailed descriptions of steps unrelated to this invention are omitted here. Example 5 includes the following steps:

[0268] Step 901: The source base station sends a handover request message to the destination base station.

[0269] The message carries the session identifier for each requested PDU session, QoS flow information contained in the PDU session, DRB information, etc. If the UE is receiving MBS, the message also includes the MBS identifier, forwarding suggestions for the MBS service, or forwarding suggestions set for the radio bearer of each MBS. The message also includes the session identifier corresponding to the MBS, QoS flow information corresponding to the MBS, DRB configuration information for transmitting the MBS, and the mapping configuration information of the MBS's QoS flow to the MRB at the source base station. The message may also include the SN information of the source base station transmitting the MBS data; the SN information may include the PDCP SN and / or the GTP-U SN.

[0270] -PDCP SN. Specifically, it can be one or more of the following information:

[0271] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0272] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0273] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0274] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0275] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0276] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0277] -GTP-U SN. Specifically, it can be one or more of the following information:

[0278] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0279] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0280] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0281] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0282] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0283] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0284] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0285] ■The SN in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE.

[0286] The destination base station determines whether to send a message to the core network requesting MBS data transmission based on whether the destination cell is already transmitting MBS. If the destination cell has already received MBS from the core network, the destination base station sends a response message to the source base station.

[0287] If the destination cell on the destination base station has not yet received MBS data from the core network, the destination base station sends a message to the core network requesting the core network to send the MBS data. The process of establishing an MBS bearer has been described in other embodiments. The destination base station sends a response message to the source base station.

[0288] Step 902: The destination sends a handover request response message. This message includes a destination-to-source transparent transmitter. The destination-to-source transparent transmitter contains the RRC message sent by the destination base station to the UE.

[0289] The message also contains information about a successfully established PDU session. This PDU session information includes the PDU session identifier, the identifier of a successfully established DRB, the identifier of a successfully established MBS, and the identifier of a successfully established MRB. If the destination base station is transmitting MBS services, either point-to-point or point-to-multipoint, the message also includes indications from the destination base station regarding whether MBS data forwarding is necessary.

[0290] Step 903: The source base station sends a handover execution command to the UE via an RRC reconfiguration message.

[0291] The message carries information about the PDU session configuration that the UE needs to establish at the destination base station. It may also include the MBS service identifier received by the destination base station, the MBS channel mode indication information, and the MBS point-to-point channel configuration information and / or point-to-multipoint channel configuration information.

[0292] Step 904: The source base station sends the SN status transmission to the destination base station.

[0293] If step 901 does not include information about the PDCP SN corresponding to the MBS data received by the UE at the source base station, then step 904 can be used to send the PDCP SN and / or GTP-U SN corresponding to the MBS data in a separate message:

[0294] -PDCP SN. Specifically, it can be one or more of the following information:

[0295] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0296] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0297] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0298] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0299] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0300] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0301] -GTP-U SN. Specifically, it can be one or more of the following information:

[0302] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0303] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0304] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0305] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0306] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0307] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0308] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0309] ■The SN in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE.

[0310] Step 905: The destination base station sends SN information to the source base station.

[0311] The message may contain the SN information corresponding to the data currently being sent or transmitted by the destination base station, or the PDCP SN information and / or GTP-U SN corresponding to the data suggested for forwarding by the destination base station. For example, if the destination base station is currently transmitting data with a GTP-U SN of 100, the destination base station notifies the source base station that the transmitted GTP-U SN is 100, and the source base station will only forward data with a GTP-U SN less than 100. Alternatively, to ensure no data loss, the destination base station notifies the source base station that the highest GTP-U SN corresponding to the data suggested for forwarding is 110, and the source base station will only forward data with a GTP-U SN less than 110. The destination base station can establish a point-to-point channel for the UE to receive MBS data. Once all the forwarded data has been sent to the UE, the UE can then switch to a point-to-multipoint channel to receive data if needed.

[0312] Specifically, the PDCP SN information and / or GTP-U SN information can be one or more of the following:

[0313] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0314] ■The highest PDCPSN corresponding to the downlink PDCP data packets that have been sent to the lower RLC layer;

[0315] ■ A list of PDCP SNs corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0316] ■ The highest PDCPSN corresponding to the downlink PDCP data packets that have been successfully sent to the UE in sequence;

[0317] ■ List of PDCP SNs corresponding to downlink PDCP data packets that have been successfully sent to the UE;

[0318] ■ The highest PDCP SN corresponding to the downlink PDCP data packet that has been successfully sent to the UE;

[0319] ■ The PDCP SN set by the base station indicates the highest PDCP SN corresponding to the downlink PDCP data packet that needs to be forwarded;

[0320] ■ The PDCP SN list set by the base station indicates the list of PDCP SNs corresponding to the downlink PDCP data packets that need to be forwarded. It can also indicate a range of SNs, such as the lowest and highest PDCP SNs.

[0321] -GTP-U SN. Specifically, it can be one or more of the following information:

[0322] ■ The SN of the highest GTP-u data packet corresponding to the data packet sent to the PDCP layer;

[0323] ■ The serial number (SN) of the highest GTP-u packet corresponding to the packet sent to the SDAP layer;

[0324] ■ The SN with the highest sequence number in the received GTP-u data packet; the list of SNs of GTP-U data packets corresponding to downlink PDCP data packets that have been sent to the lower RLC layer;

[0325] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet that has been sent to the lower RLC layer;

[0326] ■The SN in the header of the GTP-U data packet corresponding to the downlink PDCP data packet that has been successfully sent to the UE in sequence;

[0327] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0328] ■The SN in the GTP-U data packet header corresponding to the downlink PDCP data packet successfully sent to the UE;

[0329] ■The sequence number (SN) in the header of the GTP-U data packet with the highest sequence number corresponding to the downlink PDCP data packet successfully sent to the UE;

[0330] ■ The GTP-U SN set by the base station indicates the highest GTP-U SN corresponding to the downlink data packet that needs to be forwarded;

[0331] ■ The GTP-U SN list set by the base station indicates the GTP-U list corresponding to the downlink data packets that need to be forwarded. It can also indicate a range of SNs, such as the lowest and highest GTP-U SNs.

[0332] Step 905 does not necessarily occur after step 904; it can also occur before step 904. There is no absolute order between the two.

[0333] Step 906: The source base station forwards MBS data to the destination base station. Based on the SN information (which can be a PDCP SN or a GTP-u SN, as shown above) corresponding to the forwarded data suggested by the destination base station, the source base station determines which data needs to be forwarded and when to end the forwarding process. For example, if the destination base station sets the highest suggested forwarding SN to 100, and the source base station is currently sending data packets with a GTP-u SN of 80, then the source base station forwards data packets from GTP-u SN = 80 to SN = 100 to the destination base station. To ensure continuous data reception, the destination base station can temporarily establish a point-to-point transmission mode for the UE, sending the forwarded data to the UE via a point-to-point channel. Afterwards, the UE can switch to point-to-multipoint mode to receive data. When data forwarding ends, the source base station can indicate the end of data forwarding on the user plane, or indicate that the forwarded data packet is the last data packet.

[0334] Step 907: The UE sends an RRC reconfiguration complete message to the destination base station to indicate that the handover is complete.

[0335] Step 908: The destination base station sends a path switching request message to the core network.

[0336] When the UE is the first user to need to receive MBS at the destination base station, and the destination base station has not yet received MBS data from the core network, the destination base station can request the transmission of MBS data through the message in step 908. The message in step 908 carries MBS information, such as the MBS identifier, requesting the core network to send MBS data to the base station. In response to receiving the message in step 908, the core network begins sending an MBS service start message to the base station, and the base station sends a corresponding message to the core network. Afterwards, the core network can begin sending MBS data to the base station. The destination base station first sends the forwarded data received from the source base station, and then sends the new data received from the core network.

[0337] Step 909: The core network sends a path switching response message to the destination base station.

[0338] Step 910: The destination base station sends the UE context release to the source base station to release the UE context information on the source base station.

[0339] The method shown in this embodiment can also be used in a user-separated architecture. In this case, the destination CU-UP needs to include the SN information corresponding to the data that the destination CU-UP has already sent or is sending in the bearer establishment response or bearer modification response message, or include the PDCP SN information and / or GTP-U SN information corresponding to the forwarded data suggested by the destination base station. See step 905 for specific information. After receiving the information, the destination CU-CP sends the aforementioned SN information to the source CU-CP, and the source CU-CP sends the data SN information to the source CU-UP. Based on the received SN information (which can be a PDCP SN or a GTP-U SN), the source CU-UP determines which data needs to be forwarded and when to end the forwarding. When data forwarding ends, the source CU-UP can indicate the end of data forwarding in the user plane, or indicate that the forwarded data packet is the last data packet.

[0340] Example 6

[0341] The above embodiments all require enhancement of the messages / processes between the source and destination base stations. In Embodiment Six, a method based on time-based data transmission or a method that does not add messages is proposed, based on not modifying the messages / processes between the source and destination base stations. The advantage of this method is minimal impact on the protocol; the disadvantage is that the forwarded data may be more or less than the actual required data. Specifically, Figure 11 Example six includes the following steps:

[0342] Step 1101: The source base station sends a handover request message to the destination base station.

[0343] Based on the UE's measurement report, the source base station decides to hand over the UE to the destination base station located in the destination cell. When the source base station decides to initiate the handover process, it begins to save / cache data that has not yet been sent to the UE, and also saves / caches newly received data from the core network. This data is all data that will be forwarded to the destination base station. The caching starts from the time the handover is initiated and ends when the source base station receives the release request message from the destination base station, or ends at a certain point in time after receiving the release request message from the destination base station. This point in time can be related to the implementation of...

[0344] The message carries the session identifier of each requested PDU session, information on the QoS flows contained in the PDU session, DRB information, etc. If the UE is receiving an MBS, the message also includes the MBS identifier, forwarding suggestions for the MBS service, or forwarding suggestions set for the radio bearer of each MBS. The message also includes the session identifier corresponding to the MBS, information on the QoS flows corresponding to the MBS, configuration information of the DRB for transmitting the MBS, and the mapping configuration information of the QoS flows of the MBS to the MRB at the source base station.

[0345] The message may also include the PDCP SN corresponding to the MBS data transmission of the source base station and the corresponding GTP-U SN, as described in Examples 1 to 6. The GTP-U SN is a sequence number contained in the data packet sent from the core network to the base station. It can be included in the GTP-U header or the extended GTP-U header. This SN can be for a PDU session, a QoS flow, or multiple QoS flows, such as multiple QoS flows mapped to the same radio bearer. For the same data packet, the GTP-U SN sent to different base stations is the same. Therefore, the destination base station can know the PDCP SN assigned to it by the source base station for data packets with the same GTP-U SN. Thus, the difference between the PDCP SN assigned by the destination base station and the PDCP SN assigned by the source base station can also be known; this difference is called the PDCP SN difference.

[0346] The destination base station determines whether to send a message to the core network requesting MBS data transmission based on whether the destination cell is already transmitting MBS. It can send a new message to the core network carrying MBS information, such as the MBS identifier, requesting the core network to send MBS data to that base station. If the destination cell has already received MBS from the core network, the destination base station sends a response message to the source base station.

[0347] If the destination cell on the destination base station has not yet received MBS data from the core network, the destination base station sends a message to the core network requesting the core network to send the MBS data. The destination base station then sends a response message to the source base station.

[0348] Step 1102: The destination sends a handover request response message. This message includes a destination-to-source transparent transmitter. The destination-to-source transparent transmitter contains the RRC message sent by the destination base station to the UE. The RRC message may contain the PDCP SN difference mentioned in step 1101, or the correspondence between the destination base station's PDCP SN and GTP-U SN. This is because for data packets corresponding to the same GTP-U SN, the source and destination base stations may assign different PDCP SNs. During handover, the PDCP SNs of the data received by the UE from the source base station and the data received from the destination base station may be discontinuous. The PDCP protocol layer at the UE needs to transmit data packets to the upper-layer protocol according to the SN order, requiring the PDCP SN to determine if data loss has occurred. If the UE obtains the PDCP SN difference, it can determine whether the data packets received from the destination base station are continuous with those received from the source base station. Based on this difference, the data packets can be sorted. If they are discontinuous, the UE can identify which data packets were lost and request retransmission of the lost data packets from the destination base station.

[0349] The message also includes information about the successfully established PDU session. The PDU session information includes the PDU session identifier, the identifier of the successfully established DRB, the identifier of the successfully established MBS, the identifier of the successfully established MRB, and the tunnel address for receiving and forwarding data.

[0350] Step 1103: The source base station sends a handover execution command to the UE via an RRC reconfiguration message.

[0351] The message carries information about the PDU session configuration that the UE needs to establish at the destination base station. It may also include the MBS service identifier received by the destination base station, the MBS channel mode indication information, and the MBS point-to-point channel configuration information and / or point-to-multipoint channel configuration information.

[0352] Step 1104: The source base station sends the SN status transmission to the destination base station.

[0353] The message contains the PDCP SN and / or GTP-U SN corresponding to the MBS data. Specific details are as described in Examples 1 to 6.

[0354] Step 1105: The source base station forwards MBS data to the destination base station.

[0355] The source base station sends the stored data to the destination base station.

[0356] Optionally, when data forwarding ends, the source base station may indicate the end of data forwarding in the user plane, or indicate that the forwarded data packet is the last data packet.

[0357] Step 1106: The UE sends an RRC reconfiguration complete message to the destination base station to indicate that the handover is complete.

[0358] Step 1107: The destination base station sends a path switching request message to the core network.

[0359] When the UE is the first user to need to receive MBS at the destination base station, and the destination base station has not yet received MBS data from the core network, the destination base station can request the transmission of MBS data through the message in step 1107. The message in step 1107 carries MBS information, such as the MBS identifier, requesting the core network to send MBS data to the base station. In response to receiving the message in step 1107, the core network begins sending an MBS service start message to the base station, and the base station sends a corresponding message to the core network. Afterwards, the core network can begin sending MBS data to the base station. The destination base station first sends the forwarded data received from the source base station, and then sends the new data received from the core network.

[0360] Step 1108: The core network sends a path switching response message to the destination base station.

[0361] Step 1109: The destination base station sends a UE context release message to the source base station to release the UE context information on the source base station.

[0362] This message can carry an indication that data forwarding has stopped. The destination base station receives data forwarded by the source base station. Based on the data it received from the core network and the status of its cached MBS data, the destination base station decides whether the source base station needs to continue forwarding data to it. If not, when the destination base station sends a UE context release message to the source base station, it carries an indication to stop data forwarding, or includes information about the SN (Signal Number) for data forwarding. The SN information can be the PDCP SN and / or the GTP-U SN corresponding to the MBS data, as described in Examples 1 to 6. Alternatively, the destination base station can wait until it no longer needs the source base station to forward data to it before sending the UE context release message to the source base station. Upon receiving the UE context release message, the source base station stops data forwarding. When stopping data forwarding, it can indicate the end of data forwarding in the forwarded data packet, or indicate that the forwarded data packet is the last data packet.

[0363] If the source base station receives a data forwarding stop indication message contained in the UE context release message, it will stop forwarding data to the destination base station. It can indicate the end of data forwarding in the forwarded data packet or indicate that the forwarded data packet is the last data packet.

[0364] If the source base station receives the SN information contained in the UE context release message, it determines when data forwarding should stop based on the SN information, and indicates the end of data forwarding in the forwarded data packet, or indicates that the forwarded data packet is the last data packet.

[0365] Example 7

[0366] In MBS transmission, to ensure data continuity and minimize data loss during handover, the PDCP SNs of multiple base stations need to be synchronized. There are two synchronization methods between the PDCP SN and the GTP-U SN: one is that the value of the PDCP SN is equal to the value of the GTP-U SN, and the other is that the value of the PDCP SN can be different from the value of the GTP-U SN, but the PDCP SN is generated by the GTP-U SN according to a fixed rule. For example, if the GTP-U SN corresponding to PDCP SN=0 is 10, then the GTP-U SN corresponding to PDCP SN=1 is 11, and so on.

[0367] Some base stations receive data from the core network relatively late. For example, during service operation, a user who is receiving MBS or needs to receive MBS moves to a cell that supports MBS service. The base station in that cell has not yet received the MBS service from the core network and requests service transmission from the core network. Only then does the core network send data to the base station. The first data packet received by this base station contains a SN of 100 in the GTP-U header. At this time, other base stations that receive MBS service from the beginning set their PDCP SN according to the SN contained in the GTP-U header. For data packets with a SN of 100 in the GTP-U header, the PDCP SN = 100. However, according to current regulations, the PDCP SN sequence number of base stations that receive data later needs to start from 1. This causes the PDCP SN asynchrony problem.

[0368] When multiple base stations receive data from the same MBS service from the core network, data loss may occur during transmission from the core network to the base stations. For example, if two base stations, base station 1 and base station 2, both receive the same MBS service data from the core network, and the data packet sent to base station 1 is lost while the data packet sent to base station 2 is not lost, then if the base station's PDCP SN is synchronized with the GTP-U SN, a desynchronization will occur in the event of data loss.

[0369] When the above situation occurs, the relationship between the PDCP SN and the GTP-U SN is disrupted. In this case, resynchronization is performed using the following methods.

[0370] Method 1: The PDCP sequence number of the base station does not have to start from 1, but can start from the SN contained in the header of the first received GTP-U data packet. For example, when the base station receives the first GTP-U data packet, the header carries SN=100, then the PDCP SN=100. At this time, the base station needs to tell the UE through the PDCP header or PDCP control information that PDCP SN=100 is the first data packet, or notify the UE of the starting value of the PDCP SN.

[0371] Method 2: The base station can detect data loss through the GTP-U SN. The GTP-U SN can be for a single session or a QoS flow and is continuously encoded in the core network. Therefore, the base station can detect data loss from the GTP-U SN. If data loss is detected, the base station can generate a fake PDCP packet and assign a PDCP SN to this fake packet to ensure synchronization between the PDCP SN and the GTP-U SN.

[0372] Method 3: Even when the base station detects data loss, it still allocates the PDCP SN based on the GTP-U SN. For example, if the first synchronization method is used, GTP-U SN = PDCP SN. If the base station receives a data packet with GTP-U SN = 9, it assigns PDCP SN = 9 to that packet. If a data packet with GTP-U SN = 10 is lost during transmission from the core network to the base station, the base station doesn't receive the packet with GTP-U SN = 10 but instead receives the packet with GTP-U SN = 11. The corresponding PDCP SN jumps directly from 9 to 11, resulting in discontinuous PDCP SNs in the data packets sent by the base station. The UE needs to sort the data based on the PDCP SN. If the UE doesn't receive the packet with PDCP SN = 10, it will assume the packet with PDCP SN = 10 was not successfully transmitted and may request a retransmission. To avoid this, the base station can notify the UE that PDCP SN 10 will no longer be transmitted, and the next consecutively received PDCP SN will be 11. The UE can be notified via an RRC message sent by the base station, for example, by notifying the lost PDCP SN number, or by informing the UE through user plane control information. For example, the control information contained in the PDCP SN=11 data packet can inform the UE that the SN number of the previous data packet was PDCP SN=9. In this way, the UE will not assume that the PDCP SN=10 data packet has been lost and thus request the base station to retransmit it.

[0373] Method 4: When a base station generates a PDCP SN from the GTP-U SN using a fixed rule, a new rule will be adopted when data is lost. This new rule can then be communicated to the UE via an RRC message or to other base stations via the Xn interface. For example, before data loss, if the base station receives a data packet with GTP-U=10, it assigns PDCP SN=1, and the rule is PDCP SN=GTP-U SN-9. When the data packet with GTP-U=11 is lost, and the base station receives a data packet with GTP-U=12, it assigns PDCP SN=2 for that data packet, and the new rule is PDCP SN=GTP-U SN-10. The new rule, such as {PDCP SN=2, GTP-U SN=10}, is then communicated to neighboring base stations via the method in Example 6 or through a new message.

[0374] According to the method of the present invention, during multicast transmission switching, service continuity can be guaranteed, additional overhead of multicast data transmission can be avoided or reduced, the utilization efficiency of access network resources and / or air interface resources can be improved, transmission delay can be reduced, data loss can be reduced, delay caused by switching can be reduced, and unnecessary data transmission can be reduced.

[0375] Figure 10 This is a block diagram of a network device according to the present invention.

[0376] Network devices can be used to implement the DU, CU-UP, CU-CP, base station, source base station, destination base station, source DU, source CU-UP, source CU-CP, destination DU, destination CU-UP, destination CU-CP, etc. of this invention. (Reference) Figure 10 The network device according to the present invention includes a transceiver 1010, a controller 1020, and a memory 1030. The transceiver 1010, controller 1020, and memory 1030 are configured to perform operations according to embodiments one through five of the present invention. Although the transceiver 1010, controller 1020, and memory 1030 are shown as separate entities, they can be implemented as a single entity, such as a single chip. The transceiver 1010, controller 1020, and memory 1030 can be electrically connected or coupled to each other. The transceiver 1010 can transmit signals to and receive signals from other network entities, such as UEs, base stations, or core network nodes. The controller 1020 may include one or more processing units and can control the network device to perform operations and / or functions according to one of the above embodiments. The memory 1030 may store instructions for implementing the operations and / or functions of one of the above embodiments.

[0377] This completes the method and device for multicast transmission of the present invention. During multicast transmission switching, it can ensure service continuity, avoid or reduce the additional overhead of multicast data transmission, improve the utilization efficiency of access network resources and / or air interface resources, reduce transmission delay, reduce data loss, reduce the delay caused by switching, and reduce unnecessary data transmission.

Claims

1. A method for broadcast multicast service (MBS) during a handover from a second network device to a first network device, the method being performed by the first network device and comprising: A handover request message is received from the second network device, wherein the handover request message includes identifier information for the radio bearer of the MBS and first packet data aggregation protocol sequence number (SN) information for the first data packet that has been transmitted to the user equipment (UE) for the MBS. Based on the first PDCP SN information of the first data packet already transmitted to the UE for MBS, determine whether to apply data forwarding to MBS; and A handover request response message is sent to a second network device, wherein the handover request response message includes second PDCP SN information for second data packets available to the first network device for MBS, and wherein the second PDCP SN information enables the second network device to determine when to stop data forwarding for MBS.

2. The method according to claim 1, wherein, The first PDCP SN information includes the highest PDCP SN of the data packets that have been successfully sent to the UE for MBS.

3. The method according to claim 1, wherein, The handover request response message also includes identifier information for the radio bearer used in the MBS.

4. The method according to claim 1, wherein, The second PDCP SN information includes the PDCP SN of the data packets to be sent by the first network device to the UE for MBS.

5. A method for broadcast multicast service (MBS) during a handover from a second network device to a first network device, the method being performed by the second network device and comprising: A handover request message is sent to a first network device, wherein the handover request message includes identifier information of the radio bearer for MBS and first packet data aggregation protocol sequence number (PDCP) information of the first data packet that has been delivered to user equipment (UE) for MBS, wherein the first PDCP SN information enables the first network device to determine whether to apply data forwarding to MBS. A handover request response message is received from a first network device, wherein the handover request response message includes second PDCP SN information for MBS in a second data packet available to the first network device; and Based on the second PDCP SN information of the second data packets available for MBS in the first network device, it is determined when to stop data forwarding for MBS.

6. The method according to claim 5, wherein, The first PDCP SN information includes the highest PDCP SN of the data packets that have been successfully sent to the UE for MBS.

7. The method according to claim 5, wherein, The handover request response message also includes identifier information for the radio bearer used in the MBS.

8. The method according to claim 5, wherein, The second PDCP SN information includes the PDCP SN of the data packets to be sent by the first network device to the UE for MBS.

9. A first network device for broadcast multicast service (MBS) during handover from a second network device to a first network device, the first network device comprising: transceiver; as well as At least one processor, coupled to the transceiver, is configured to: A handover request message is received from the second network device, wherein the handover request message includes identifier information for the radio bearer of the MBS and first packet data aggregation protocol sequence number (SN) information for the first data packet that has been transmitted to the user equipment (UE) for the MBS. Based on the first PDCP SN information of the first data packet already transmitted to the UE for MBS, determine whether to apply data forwarding to MBS; and A handover request response message is sent to a second network device, wherein the handover request response message includes second PDCP SN information for second data packets available to the first network device for MBS, wherein the second PDCP SN information enables the second network device to determine when to stop data forwarding for MBS.

10. The first network device according to claim 9, wherein, The first PDCP SN information includes the highest PDCP SN of the data packets that have been successfully sent to the UE for MBS.

11. The first network device according to claim 9, wherein, The handover request response message also includes identifier information for the radio bearer used in the MBS.

12. The first network device according to claim 9, wherein, The second PDCP SN information includes the PDCP SN of the data packets to be sent by the first network device to the UE for MBS.

13. A second network device for broadcast multicast service (MBS) during handover from a second network device to a first network device, the second network device comprising: transceiver; as well as At least one processor, coupled to the transceiver, is configured to: A handover request message is sent to a first network device, wherein the handover request message includes identifier information of the radio bearer for MBS and first packet data aggregation protocol sequence number (PDCP) information of the first data packet that has been delivered to user equipment (UE) for MBS, wherein the first PDCP SN information enables the first network device to determine whether to apply data forwarding to MBS. A handover request response message is received from a first network device, wherein the handover request response message includes second PDCP SN information for MBS in a second data packet available to the first network device; and Based on the second PDCP SN information of the second data packets available for MBS in the first network device, it is determined when to stop data forwarding for MBS.

14. The second network device according to claim 13, wherein, The first PDCP SN information includes the highest PDCP SN of the data packets that have been successfully sent to the UE for MBS.

15. The second network device according to claim 13, wherein, The handover request response message also includes identifier information for the radio bearer used in the MBS.

16. The second network device according to claim 13, wherein, The second PDCP SN information includes the PDCP SN of the data packets to be sent by the first network device to the UE for MBS.

Citation Information

Patent Citations

  • Data transmission method during process of movement, and terminal and base station

    WO2018126905A1