Multicast reception in radio access network sharing
By updating signaling interactions and establishing shared transport tunnels, the solution addresses the inefficiencies in multicast receptions in RAN sharing scenarios, enhancing resource efficiency and network performance for 5G MBS.
Patent Information
- Application Number
- PCT/CN2023/136876
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-12-06
- Publication Date
- 2025-06-12
AI Technical Summary
Current technologies face challenges in efficiently managing multicast receptions in Radio Access Network (RAN) sharing scenarios, leading to resource duplication and inefficiencies in 5G Multicast and Broadcast Services (MBS).
The proposed solution involves updating NGAP, E1AP, and F1AP signaling interactions to recognize and manage MBS sessions with the same content across different PLMNs, and establishing shared transport tunnels like NG-U and F1-U tunnels to avoid resource duplication.
This approach enhances resource efficiency for MBS multicast transmissions by avoiding duplicated resource allocation, improving network performance, and reducing operational costs in RAN sharing scenarios.
Smart Images

Figure CN2023136876_12062025_PF_FP_ABST
Abstract
Description
MULTICAST RECEPTION IN RADIO ACCESS NETWORK SHARINGTECHNICAL FIELD
[0001] This disclosure is directed generally to digital wireless communications.BACKGROUND
[0002] Mobile telecommunication technologies are moving the world toward an increasingly connected and networked society. In comparison with the existing wireless networks, next generation systems and wireless communication techniques will need to support a much wider range of use-case characteristics and provide a more complex and sophisticated range of access requirements and flexibilities.
[0003] Long-Term Evolution (LTE) is a standard for wireless communication for mobile devices and data terminals developed by 3rd Generation Partnership Project (3GPP) . LTE Advanced (LTE-A) is a wireless communication standard that enhances the LTE standard. The 5th generation of wireless system, known as 5G, advances the LTE and LTE-A wireless standards and is committed to supporting higher data-rates, large number of connections, ultra-low latency, high reliability and other emerging business needs.SUMMARY
[0004] Techniques are disclosed for supporting multicast reception in Radio Access Network (RAN) sharing scenarios. 5G Multicast and Broadcast Services (MBS) is a point-to-multipoint service that can improve the network efficiency and user experience when transmitting the same content to multiple users. The described embodiments advantageously improve the resource efficiency for MBS multicast transmissions in RAN sharing scenarios.
[0005] In an example aspect, a wireless communication method includes transmitting, by a first core network to a network node, a first information associated with a multicast reception at the network node, and then receiving, from the network node, a second information associated with an establishment of a transport tunnel for the multicast reception. In this example, both the first core network and a second core network are configured to share one or more radio access network resources including the network node.
[0006] In another example aspect, a wireless communication method includes receiving, by a network node from a first core network, a first information associated with a multicast reception at the network node, and then transmitting, to the first core network, a second information associated with an establishment of a transport tunnel for the multicast reception. In this example, both the first core network and a second core network are configured to share one or more radio access network resources including the network node.
[0007] In yet another example aspect, the above-described methods are embodied in the form of processor-executable code and stored in a non-transitory computer-readable storage medium. The code included in the computer readable storage medium when executed by a processor, causes the processor to implement the methods described in this patent document.
[0008] In yet another example aspect, a device that is configured or operable to perform the above-described methods is disclosed.
[0009] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.
[0010] BRIEF DESCRIPTION OF THE DRAWING
[0011] FIG. 1 shows a flowchart of an example wireless communication method.
[0012] FIG. 2 shows a flowchart of another example wireless communication method.
[0013] FIG. 3 shows an exemplary block diagram of a hardware platform that may be a part of a network device or a communication device.
[0014] FIG. 4 shows an example of wireless communication including a base station (BS) and user equipment (UE) based on some implementations of the disclosed technology.DETAILED DESCRIPTION
[0015] Multicast and Broadcast Services (MBS) , which is considered to be one of the most prominent use cases of 5G NR, provides reliable, low-latency, and resource-efficient transmissions to multiple terminals that need to receive the same content. Its main use case scenarios are those involving crowded areas, such as concerts, sport stadiums, and racing tracks. On the one hand, there are situations where the video needs to be synchronized to the terminal, whereas in other situations, multiple viewing angles are required. In another example, MBS is well suited when a large number of users in the same cell are watching virtual reality (VR) live broadcasts at the same time, e.g., in emergency situations. However, these deployments of MBS would likely require significant investments.
[0016] Network sharing is a mechanism for operators to cut the heavy costs involved in initial roll-out, capital expenditure (CAPEX) , and operational expenditure (OPEX) . A network sharing architecture allows multiple operators to share resources of a single shared network based on mutually agreed upon allocation schemes. The shared network includes a radio access network (RAN) , and the shared resources include radio resources.
[0017] In 5G NR, Multicast / Broadcast transmissions are provided. In RAN sharing deployment scenarios, if the same Multicast / Broadcast service is provided by two (or more) operators separately, the service is regarded as having separate Temporary Mobile Group Identities (TMGIs) because duplicated point to multipoint (PTM) radio resources were consumed in the same cell for the transmission of the same content. This operation, for example, justifies improving resource efficiency in RAN sharing scenarios.
[0018] In Rel-18 NR MBS, some solutions to improve the resource efficiency for MBS broadcast transmission in RAN sharing scenarios were introduced. However, how to enhance the procedure of MBS multicast transmissions to improve the resource efficiency in RAN sharing scenarios was never discussed. Embodiments of the disclosed technology provide methods, systems, and devices that improve the resource efficiency for MBS multicast transmission in RAN sharing scenarios.
[0019] The example headings for the various sections below are used to facilitate the understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Accordingly, one or more features of one example section can be combined with one or more features of another example section. Furthermore, 5G terminology is used for the sake of clarity of explanation, but the techniques disclosed in the present document are not limited to 5G technology only, and may be used in wireless systems that implemented other protocols.
[0020] 1 Examples of a first UE joining a multicast session in RAN sharing scenarios
[0021] In some embodiments, and to improve the resource efficiency for multicast transmissions in RAN sharing scenarios, certain NGAP, E1AP and F1AP signaling interactions are updated. These signaling interactions are for Multicast MBS Session Context Establishment with a UE joining the multicast session as the first UE joining in its serving gNB, and the following aspects are considered when updating the signaling interactions.
[0022] Recognizing the same MBS service
[0023] In existing implementations, a gNB does not have access to information that enables it to determine whether two or more MBS services are the same, e.g., carrying the same content. Embodiments of the disclosed technology enable the same MBS service to be recognized, which advantageously enables the gNB to allocate the same set of resources to avoid duplication.
[0024] In some embodiments, the core network (CN) sends a session identifier associated with the MBS, and which can be used to identify MBS sessions with the same content from different PLMNs. The MBS-associated session identifier can be carried in a PDU Session Resource Setup Request message, a PDU Session Resource Modify Request message, or a Distribution Setup Response message.
[0025] In some examples, an MBS-associated session identifier is delivered with the MBS Session ID from a Core Network as part of the PDU Session Resource Setup procedure for multicast reception, e.g., an MBS-associated session identifier is added to the MBS Session ID in a PDU Session Resource Setup Request message. Based on the MBS-associated session identifier, the gNB can recognize that MBS sessions with different session IDs, e.g., TMGI or IP multicast address, are the same MBS service in the application layer. If the gNB can identify which sessions correspond to the same MBS service, allocating duplicated resources for these sessions can be avoided.
[0026] In some examples, an MBS-associated session identifier is delivered with the MBS Session ID from a Core Network as part of the PDU Session Resource Modify procedure for multicast reception, e.g., an MBS- associated session identifier is added to the MBS Session ID in a PDU Session Resource Modify Request message. Based on the MBS-associated session identifier, the gNB can recognize that MBS sessions with different session IDs, e.g., TMGI or IP multicast address, are the same MBS service in the application layer. If the gNB can identify which sessions correspond to the same MBS service, allocating duplicated resources for these sessions can be avoided.
[0027] In some examples, an MBS-associated session identifier is delivered with the MBS Session ID from a Core Network as part of the Distribution Setup procedure for multicast reception, e.g., an MBS-associated session identifier is added to the MBS Session ID in a Distribution Setup Response message. Based on the MBS-associated session identifier, the gNB can recognize that MBS sessions with different session IDs, e.g., TMGI or IP multicast address, are the same MBS service in the application layer. If the gNB can identify which sessions correspond to the same MBS service, allocating duplicated resources for these sessions can be avoided.
[0028] Establishing the NG-U tunnel
[0029] In existing implementations, there are two RAN sharing scenarios:
[0030] – Multiple Operator Core Network (MOCN) scenario, in which multiple operators share one gNB including the gNB-CU (centralized unit) and gNB-DU (distributed unit) ;
[0031] – multiple cell-ID scenario, in which multiple operators share a common gNB-DU, but have separate (and distinct) gNB-CUs.
[0032] Embodiments of the disclosed technology advantageously enable the establishment of the NG-U tunnel for multicast reception in RAN sharing scenarios. In the example of one gNB being shared by multiple operators, this is achieved by using only one NG-U tunnel for multicast reception, thereby avoiding the allocation of duplicated resources for the same service. That is, there is no need to establish each NG-U tunnel for each operator, and the establishment of the NG-U tunnel is based on the implementation of the gNB.
[0033] Herein, the NG-RAN tunnel information is provided by gNB CU-UP, and thus, there are two possible solutions for shared NG-U tunnel establishment:
[0034] 1. gNB CU-CP makes the decision on shared NG-U tunnel establishment, or
[0035] 2. gNB CU-UP makes the decision on shared NG-U tunnel establishment.
[0036] In some examples, if the gNB CU-CP makes the decision on shared NG-U tunnel establishment, the gNB CU-CP informs the gNB CU-UP of this decision as part of the MC Bearer Context Setup procedure, e.g., an indication of whether to establish the NG-U tunnel is added to the MC Bearer Context Setup Request message. Based on this indication, the gNB CU-UP allocates the resource (s) for a shared NG-U tunnel. If gNB CU-CP informs gNB CU-UP that no NG-U tunnel will be established for this multicast session, gNB CU-UP will not allocate the resource (s) for a shared NG-U tunnel. However, if gNB CU-CP informs gNB CU-UP that an NG-U tunnel will be established for this multicast session, gNB CU-UP will allocate the resource (s) for a shared NG-U tunnel, and the corresponding NG-RAN Transport Network Layer (TNL) information will be informed to gNB CU-CP.
[0037] In some examples, an MBS-associated session identifier is delivered with the MBS Session ID from gNB CU-CP as part of the MC Bearer Context Setup procedure, e.g., an MBS-associated session identifier is added to the MC Bearer Context Setup Request message. Based on this identifier, the gNB CU-UP will know how to manage the corresponding resources in the gNB CU-UP (e.g., NG-U tunnel resources and F1-U tunnel resources) .
[0038] In some examples, if the gNB CU-UP makes the decision on shared NG-U tunnel establishment, the gNB CU-CP transfers the MBS-associated session identifier and the MBS Session ID to the gNB CU-UP as part of the MC Bearer Context Setup procedure, e.g., the MBS-associated session identifier is added to the MC Bearer Context Setup Request message. Based on this indication, gNB CU-UP allocates the resource (s) for a shared NGAP tunnel. If there is an MBS-associated session identifier in the MC Bearer Context Setup Request message, and if gNB CU-UP decides to establish a NG-U tunnel for this multicast session, the corresponding NG-RAN TNL information is informed to gNB CU-CP. However, if gNB CU-UP decides not to establish a NG-U tunnel for this multicast session, an indication for not establishing the NG-U tunnel may be carried in the MC Bearer Context Setup Response message.
[0039] In some embodiments, the gNB informs the Core Network of the decision on whether to establish a NG-U tunnel. In one example, an indication of whether to establish the NG-U tunnel is carried in the NGAP Distribution Setup Request message. If gNB decides not to establish a NG-U tunnel, there is no information about a shared NG-U tunnel, but an indication of no NG-U tunnel establishment (e.g., a 1-bit indication) is carried in a Distribution Setup Request message. Based on the indication, the Core Network performs the establishment of NG-U tunnel. However, if there is no information about NG-U tunnel, and an indication of no NG-U tunnel establishment, Core Network will not establish the corresponding NG-U tunnel for this multicast session.
[0040] Establishing the F1-U tunnel
[0041] In some embodiments, the gNB CU-CP establishes a Multicast Context at the DU. In this process, whether to establish a MBS-associated logical F1-connection for each multicast session, even if they are the same service in the application layer, is determined. Additionally, whether to establish a F1-U tunnel for each multicast session in RAN sharing scenario is also determined.
[0042] In some embodiment, and for the MOCN scenario, since there is only one shared CU and DU, it is possible to establish only one NG-U tunnel and F1-U tunnel for these multicast sessions that are the same service in the application layer. For the multiple cell-ID scenario, since there are multiple CUs, they may establish separate NG-U tunnels for the same multicast service. In this scenario, existing implementations do not provide how to establish F1-U tunnel; e.g., whether only one F1-U tunnel should be established for the same multicast service, or whether multiple F1-U tunnels for multiple Cus should be established.
[0043] In some examples, for each multicast session that is the same session in the application layer, its own MBS-associated logical F1-connection is established, but only one shared F1-U tunnel for these multicast sessions is established. To achieve this goal, the MBS-associated session identifier is carried from gNB CU-CP to gNB DU, e.g., an MBS-associated session identifier is added to an F1AP Multicast Context Setup Request message, an F1AP UE Context Setup Request message, or an F1AP UE Context Modification Request message.
[0044] In some examples, for these multicast sessions that are the same session in the application layer, there is only one F1-U tunnel in the RAN sharing scenario. To achieve this goal, the same F1-U tunnel information will be carried from gNB DU to gNB CU-CP, e.g., the same F1-U tunnel information in Multicast Distribution Setup Request message. If the same F1-U tunnel information is carried from gNB DU, the same F1-U tunnel address information will be provided from gNB CU in return. For example, the same F1-U tunnel information at gNB DU is carried for these multicast sessions in F1AP Multicast Distribution Setup Request message and in E1AP MC Bearer Context Modification Request message, and the same F1-U tunnel information at gNB CU is carried for these multicast sessions in F1AP Multicast Distribution Setup Response message and in E1AP MC Bearer Context Modification Response message.
[0045] In some examples, for these multicast sessions that are the same session in the application layer, there is only one F1-U tunnel in the RAN sharing scenario. To achieve this goal, the F1-U tunnel information will only be carried from gNB DU when the context of the first multicast session is established in the DU. For other multicast sessions that are the same service in the application layer, there is no F1-U tunnel information carried from gNB-DU. In this case, gNB-CU will also only carry the corresponding F1-U tunnel information to the gNB DU when the first multicast session is established in the DU. That is, the F1-U tunnel information will be carried for the first session in the procedure of F1AP Multicast Distribution Setup and E1AP MC Bearer Context Modification. For other multicast sessions that are the same service in the application layer as the first session, there is no F1-U tunnel information during F1AP Multicast Distribution Setup procedure and E1AP MC Bearer Context Modification procedure.
[0046] In some examples, in the multiple cell-ID scenario, for each multicast session that is the same session in the application layer, a multicast session establishes its own MBS-associated logical F1-connection, but establishes a F1-U tunnel for each CU. For example, gNB-CU sends the MBS associated session identifier and its own cell ID to gNB-DU in an F1AP Multicast Context Setup Request message, and F1 AP UE Context Setup Request message, or an F1AP UE Context Modification Request message.gNB-DU will establish multiple F1-U tunnels if there are multiple cell IDs for the same MBS associated session. This F1-U tunnel information at gNB DU will be carried for these multicast sessions in an F1AP Multicast Distribution Setup Response message and in an E1AP MC Bearer Context Setup / Modification Response message.
[0047] In some examples, in the multiple cell-ID scenario, for each multicast session that is the same session in the application layer, a multicast session establishes its own MBS-associated logical F1-connection, but only establishes one shared F1-U tunnel for these multicast sessions. For example, gNB-CU sends the MBS-associated session identifier and its own cell ID to gNB-DU in an F1AP Multicast Context Setup Request message, an F1AP UE Context Setup Request message, or an F1AP UE Context Modification Request message. gNB-DU will establish only one F1-U tunnel even if there are multiple cell IDs. The same F1-U tunnel information at gNB DU is carried for these multicast sessions in F1AP Multicast Distribution Setup Request message and in E1AP MC Bearer Context Modification Request message, and the same F1-U tunnel information at gNB DU is carried for these multicast sessions in F1AP Multicast Distribution Setup Response message and in E1AP MC Bearer Context Setup / Modification Response message.
[0048] In some examples, in the multiple cell-ID scenario, if there are multiple NG-U tunnels but only one F1-U tunnel, gNB-CU can decide to release some NG-U tunnels after the F1-U tunnel is established. For example, an indication information about the NG-U tunnel being released is carried from gNB to Core Network in a PDU SESSION RESOURCE MODIFY INDICATION message or a DISTRIBUTION MODIFICATION REQUEST message. The Core Network will release this NG-U tunnel based on this information, but other contexts of this session will be still maintained. A PDU SESSION RESOURCE MODIFY CONFIRM message or a DISTRIBUTION MODIFICATION RESPONSE message will be sent to confirm the outcome of the request from the Core Network to gNB.
[0049] 2 Examples of other UE joining the multicast session in RAN sharing scenarios
[0050] In some embodiments, the gNB may only establish one NG-U tunnel for several multicast sessions that are the same service in the application layer in RAN sharing scenarios. If the network establishes an NG-U tunnel when the first UE joins the session, the NG-U tunnel will not be repeatedly established when UEs from other operators request to join the same session. An indication that the NG-U tunnel is not established will be sent from gNB to Core Network in an NGAP Distribution Setup Request message. Based on this information, the Core Network will not establish a (duplicative) NG-U tunnel for this session.
[0051] 3 Examples of NG-U tunnel switching in RAN sharing scenarios
[0052] If all the UEs belonging to a certain operator that joined a session leave the current gNB, or an operator releases the session, embodiments of the disclosed technology provide techniques to handle resources related to this session, e.g., an NG-U tunnel, an F1-U tunnel, etc.
[0053] Handling the NG-U tunnel
[0054] As previously discussed, a gNB may only establish one NG-U for several multicast sessions that are the same service in the application layer in RAN sharing scenarios. When the UEs belonging to the operator for which the NG-U tunnel is established have left the current gNB or are no longer interested in the multicast session, the NG-U tunnel may be released. But since there are other sessions from other operators of the same service in the application layer that need to be transmitted, gNB should establish a new NG-U tunnel in the RAN sharing scenario. In this case, the described embodiments determine whether gNB CU-UP should release NG-U tunnel resources at NG-RAN, and how to establish a new NG-U tunnel to another operator.
[0055] E1AP signaling interaction. In some examples, when a multicast session is released by gNB in a legacy system, the corresponding context including NG-U tunnel information should be released. However, in RAN sharing scenarios, the NG-U tunnel resources at NG-RAN may not be released because they are being shared by other multicast sessions that are the same service in the application layer. An indication for not releasing the corresponding NG-U tunnel resources at NG-RAN is carried in the E1AP MC Bearer Context Release Command message. gNB CU-UP will only release all related signaling and Multicast Radio Bearer (MRB) resources, but not release the NG-U tunnel resources, e.g., a GPRS Tunnelling Protocol (GTP) Downlink (DL) Tunnel Endpoint Identifier (TEID) . To confirm the reservation of NG-U tunnel resources at NG-RAN, an indication about the reservation of NG-U tunnel is carried in E1AP MC Bearer Context Release Complete message.
[0056] NGAP signaling interaction. In some examples, to support the NG-U tunnel switching in RAN sharing scenarios, a new procedure (e.g., an NGAP Distribution Modification procedure) is defined to modify the establishment of the NG-U tunnel after the first UE joins the multicast session. Herein, gNB sends a NGAP Distribution Modification Request message to request the Core Network to establish a new NG-U tunnel for the multicast session in the RAN sharing scenario. In an example, the session identifier, NG-U tunnel information at NG-RAN, an indication about NG-U tunnel establishment are contained in the request message. The Core Network allocates the NG-U tunnel resource for this session, and puts this information in the NGAP Distribution Modification Response message.
[0057] Handling the F1-U tunnel
[0058] In some embodiments, and as discussed previously, gNB may only establish one F1-U for several multicast sessions that are the same service in the application layer in RAN sharing scenarios. When one of the multicast sessions is released by gNB in a legacy system, the corresponding context and F1-U tunnel resources will be released as part of a Multicast Context Release procedure. But since there are other sessions from other operators of the same service in the application layer that need to be transmitted, gNB should keep the F1-U tunnel in the RAN sharing scenarios. Embodiments of the disclosed technology provide techniques for retaining F1-U tunnel resources while releasing the session context.
[0059] F1AP signaling interaction. In some examples, an indication for not releasing the corresponding F1-U tunnel resources at NG-RAN is carried in the F1AP Multicast Context Release Command message.gNB DU will only release all related signaling and MRB resources, but not release the F1-U tunnel resources. To confirm the reservation of F1-U tunnel resources at NG-RAN, an indication about the reservation of F1-U tunnel is carried in F1AP Multicast Context Release Complete message.
[0060] E1AP signaling interaction. In some examples, an indication for not releasing the corresponding F1-U tunnel resources at NG-RAN is carried in the E1AP MC Bearer Context Release Command message.gNB DU will only release all related signaling and MRB resources, but not release the F1-U tunnel resources. To confirm the reservation of F1-U tunnel resources at NG-RAN, an indication about the reservation of F1-U tunnel is carried in E1AP MC Bearer Context Release Complete message.
[0061] Lossless guarantee when switching NG-U tunnel
[0062] In some embodiments, for a multicast service in RAN sharing scenarios, the switching of an NG-U tunnel is possible, but if different tunnels deliver multicast data from different UPFs, there may be different implementations of DL MBS QoS Flow Identifier (QFI) Sequence Number and MBS QoS Flows. In this case, embodiments of the disclosed technology can still guarantee lossless switching.
[0063] In some examples, to support multicast data lossless in RAN sharing scenarios, multiple Core Networks deliver data from multiple UPFs for the same multicast service in the same shared gNB, and separate NG-U and F1-U tunnels are established for each UPF. To achieve this goal, a global unique UPF ID will be delivered from Core Network to gNB. For example, a global unique UPF ID is carried in the PDU Session Resource Setup request message.gNB will establish the corresponding NG-U tunnel based on this information. If gNB CU-CP decides to establish the NG-U tunnel, the decision of NG-U tunnel establishment will be carried in E1AP MC Bearer Context Setup Request message, and gNB CU-UP will allocate the corresponding NG-U tunnel resources (e.g., GTP DL TEID) . If gNB CU-UP decides to establish the NG-U tunnel, the MBS-associated session identifier and the corresponding UPF ID will be carried in E1AP MC Bearer Context Setup Request message and gNB will allocate the corresponding NG-U tunnel resources (e.g., GTP DL TEID) .
[0064] In some examples, the establishment of F1-U tunnel is also based on this information. For example, an indication about establishment of whether to establish an F1-U tunnel for this session is carried in the F1AP Multicast Context Setup Request message.gNB DU will allocate the resources of F1-U tunnel based on this indication and inform gNB CU the information of F1-U tunnel by F1AP Multicast Distribution Setup Request message. Then, gNB CU will allocate the corresponding F1-U tunnel resources based on this information.
[0065] In some examples, to support lossless multicast data in RAN sharing scenarios (and for the same multicast services in the application layer) , all operators use the same implementations of DL MBS QFI Sequence Number and MBS QoS Flows. An indication about this information will be carried in the PDU Session Resource Setup request message. If Core Network indicates that all operators use the same implementations of DL MBS QFI Sequence Number and MBS QoS Flows, gNB will only establish a shared NG-U tunnel for these multicast sessions that are the same service in the application layer. Otherwise, if there is no such indication in the PDU Session Resource Setup request message, gNB will process it as a normal session, e.g., establish its own NG-U tunnel for each session.
[0066] In some examples, no data loss is not supported for multicast reception when switching NG-U tunnel in RAN sharing scenarios. Typically, it is up to the NG-RAN node implementation as to how different implementations of DL MBS QFI Sequence Number and MBS QoS Flows received for the same shared service from different PLMNs (i.e., with the same associated Session ID) are handled. When a tunnel switch occurs, and if the implementations of DL MBS QFI Sequence Number and MBS QoS Flows are different from a previous implementation, a configuration update may be performed, e.g., an E1AP MC Bearer Context Modification procedure, an F1AP Multicast Context Modification procedure, or RRC Reconfiguration procedure may be performed.
[0067] 4 Examples of mobility in RAN sharing scenarios
[0068] In some embodiments, two cases are considered with regard to guaranteeing lossless handover for multicast reception in RAN sharing scenarios.
[0069] Case 1. The implementations of DL MBS QFI Sequence Number and MBS QoS Flows in Core Network used in the source gNB and the target gNB are the same, e.g., the NG-U tunnels used in the source and target gNB are from the same UPF / Core Network, or the operators adopt the same implementation universally.
[0070] Case 2. The implementations of DL MBS QFI Sequence Number and MBS QoS Flows in Core Network used in the source gNB and the target gNB are different, e.g., the NG-U tunnels used in the source and target gNB are from different UPF / Core Network.
[0071] For case 1, no data loss can be supported during handover period. To support a lossless handover, some information is transferred from the source gNB to the target gNB. For case 2, no data loss cannot be supported during handover period.
[0072] In some examples, the UPF information associated with the NG-U tunnel that is used for this multicast reception is delivered from the source gNB. For example, the UPF ID and MBS-associated session identifier, together with MBS Session ID, are carried in HANDOVER REQUEST message. If the UPF ID carried from the source gNB is the same as the UPF ID used in the target gNB, the target gNB will establish a data forwarding tunnel between the source gNB and target gNB, and perform data forwarding to achieve a lossless handover.
[0073] In some examples, and for case 1, no data loss can be supported during a handover period. To support a lossless handover, the information of Core Network associated with the NG-U tunnel that is used for this multicast reception is delivered from the source gNB. For example, the PLMN ID and MBS-associated session identifier, together with MBS Session ID, are carried in HANDOVER REQUEST message. If the PLMN ID carried from the source gNB is the same as the PLMN ID used for multicast reception in the target gNB, the target gNB will establish a data forwarding tunnel between the source gNB and target gNB, and perform data forwarding to achieve a lossless handover.
[0074] In some examples, and for case 1, no data loss can be supported during a handover period. To support a lossless handover, an indication that all operators are using the same implementations of DL MBS QFI Sequence Number and MBS QoS Flows for this multicast service is delivered from the source gNB. For example, an indication of all operators using the same implementations for this session and MBS-associated session identifier, together with the MBS Session ID, are carried in HANDOVER REQUEST message. Based on this indication, the target gNB will establish a data forwarding tunnel between the source gNB and target gNB, and perform data forwarding to achieve a lossless handover.
[0075] In some examples, and to avoid allocating duplicated resources to such sessions, the MBS-associated session identifier is sent to the target gNB as part of a procedure during the handover preparation phase. For example, the MBS-associated session identifier and the corresponding MBS Session ID are carried in HANDOVER REQUEST message. Based on this indication, the target gNB can check whether the NG-U tunnel and F1-U tunnel have been established for the session. If so, they can be reused. If not, they need to be re-established.
[0076] 5 Methods and implementations of the disclosed technology
[0077] FIG. 1 shows a flowchart of an example wireless communication method 100. The method 100 includes, at operation 110, transmitting, by a first core network to a network node, a first information associated with a multicast reception at the network node.
[0078] The method 100 includes, at operation 120, receiving, from the network node, a second information associated with an establishment of a transport tunnel for the multicast reception. In this example, each of the first core network and a second core network is configured to share one or more radio access network resources including the network node.
[0079] FIG. 2 shows a flowchart of an example wireless communication method 200. The method 200 includes, at operation 210, receiving, by a network node from a first core network, a first information associated with a multicast reception at the network node.
[0080] The method 200 includes, at operation 220, transmitting, to the first core network, a second information associated with an establishment of a transport tunnel for the multicast reception. In this example, each of the first core network and a second core network is configured to share one or more radio access network resources including the network node.
[0081] The described features can be implemented to further provide one or more of the following technical solutions:
[0082] A1. A wireless communication method, comprising transmitting, by a first core network to a network node, a first information associated with a multicast reception at the network node, and receiving, from the network node, a second information associated with an establishment of a transport tunnel for the multicast reception, wherein each of the first core network and a second core network is configured to share one or more radio access network resources including the network node.
[0083] A2. A wireless communication method, comprising receiving, by a network node from a first core network, a first information associated with a multicast reception at the network node, and transmitting, to the first core network, a second information associated with an establishment of a transport tunnel for the multicast reception, wherein each of the first core network and a second core network is configured to share one or more radio access network resources including the network node.
[0084] A3. The method of solution A1 or A2, wherein the first core network is a 5G Core Network, wherein the network node is a gNodeB, and wherein the transport tunnel is an NG-U tunnel. In some examples, the method of solution 3 corresponds to establishing the NG-U tunnel, as described in Section 1.
[0085] A4. The method of solution A3, wherein the first information comprises a session identifier for a Multicast and Broadcast Service (MBS) session associated with the multicast reception, and wherein the session identifier is used to identify MBS sessions with a same content from different Public Land Mobile Networks (PLMNs) . In some example, the method of solution 4 corresponds to recognizing the same MBS service, as described in Section 1.
[0086] A5. The method of solution A4, wherein the first information is carried in a Protocol Data Unit (PDU) Session Resource Setup Request message, a PDU Session Resource Modify Request message, or a Distribution Setup Response message.
[0087] A6. The method of solution A3, wherein the network node is configured to transmit, to the first core network, an indication that indicates whether to establish the transport tunnel.
[0088] A7. The method of solution A6, wherein the indication is carried in a NG Application Protocol (NGAP) Distribution Setup Request message.
[0089] A8. The method of solution A6, wherein modifying resources associated with the transport tunnel for the multicast reception is based on a NG Application Protocol (NGAP) Distribution Modification procedure, and wherein the indication is carried in an NGAP Distribution Modification Request message.
[0090] A9. The method of any of solutions A6 to A8, wherein the first core network is configured to perform, based on the indication, the establishment of the transport tunnel.
[0091] A10. The method of solution A4, wherein the first information is sent from a control plane of the network node to a user plane of the network node.
[0092] A11. The method of solution A10, wherein the first information comprises an indication of whether to establish the transport tunnel and / or the session identifier.
[0093] A12. The method of solution A11, wherein the first information is carried in an MC Bearer Context Setup Request message or an MC Bearer Context Modification Request message.
[0094] A13. The method of solution A11, wherein the user plane is configured, based on the indication or the session identifier, to allocate a resource for a shared transport tunnel, and wherein a transport layer information corresponding to the shared transport tunnel is sent from the user plane to the control plane.
[0095] A14. The method of solution A13, wherein the transport layer information is NG-RAN NG-U Transport Network Layer (TNL) information that is carried in an MC Bearer Context Setup Response message or an MC Bearer Context Modification Response message.
[0096] A15. The method of any of solutions A10 to A14, wherein the control plane comprises a gNB-CU-Control Plane (gNB-CU-CP) , and wherein the user plane comprises a gNB-CU-User Plane (gNB-CU-UP) .
[0097] A16. The method of solution A3, wherein the second information is carried in a NG Application Protocol (NGAP) Distribution Modification Request message, and wherein the first core network is configured, upon allocating resources for the transport tunnel, to transmit information related to the resources in a NGAP Distribution Modification Response message.
[0098] A17. The method of solution A1 or A2, wherein the first core network is a 5G Core Network, wherein the network node is a gNodeB, wherein the transport tunnel is an F1-U tunnel, wherein a session identifier for a Multicast and Broadcast Service (MBS) session is associated with the multicast reception, and wherein the session identifier is used to identify MBS sessions with a same content from different Public Land Mobile Networks (PLMNs) . In some examples, the method of solution 17 corresponds to establishing the F1-U tunnel, as described in Section 1.
[0099] A18. The method of solution A17, wherein the session identifier is carried in an F1AP Multicast Context Setup Request message, an F1AP UE Context Setup Request message, or an F1AP UE Context Modification Request message.
[0100] A19. The method of solution A17, wherein the transport tunnel is a single transport tunnel for the MBS sessions from the different PLMNs, wherein information associated with the transport tunnel for only a first session of the MBS sessions is carried in an F1AP Multicast Distribution Setup procedure message or an F1AP UE Context Modification Request message.
[0101] A20. The method of solution A17, wherein the session identifier and an identifier of the network node are sent from a centralized unit (CU) of the network node to a distributed unit (DU) of the network node in an F1AP Multicast Context Setup Request message.
[0102] A21. The method of solution A17, wherein the session identifier is associated with multiple cell identifiers, wherein a distributed unit (DU) of the network node is configured to establish multiple transport tunnels, and wherein each of the multiple transport tunnels is associated with a corresponding cell identifier of the multiple cell identifiers.
[0103] A22. The method of solution A17, wherein an indication for refraining from releasing the transport tunnel is carried in an F1AP Multicast Context Release Command message, and wherein an indication for reserving resources for the transport tunnel is carried in an F1AP Multicast Context Release Complete message.
[0104] A23. The method of solution A3 or A17, wherein an indication for refraining from releasing the transport tunnel is carried in an E1AP MC Bearer Context Release Command message.
[0105] A24. The method of solution A3 or A17, wherein an indication for reserving resources for the transport tunnel is carried in an E1AP MC Bearer Context Release Complete message.
[0106] A25. The method of solution A4 or A17, wherein multiple core networks deliver data from multiple user plane functions (UPFs) to the network node for the multicast reception, wherein a global unique UPF identifier is carried in a Protocol Data Unit (PDU) Session Resource Setup Request message, and wherein the transport tunnel is established for each of the multiple UPFs.
[0107] A26. The method of solution A25, wherein the transport tunnel is the NG-U tunnel, wherein the session identifier and a corresponding UPF identifier are carried in an E1AP MC Bearer Context Setup Request message.
[0108] A27. The method of solution A26, wherein an indication of the establishment of the transport tunnel for the corresponding UPF identifier is carried in the PDU Session Resource Setup Request message or a NG Application Protocol (NGAP) Distribution Setup Response message.
[0109] A28. The method of solution A3 or A17, wherein, for an operator associated with the indication, the indication being set to “1” indicates the operator using a common implementation of the multicast reception, and the indication being set to “0” indicates the operator using a distinct implementation for the multicast reception.
[0110] A29. The method of solution A28, wherein all operators associated with the indication being set to “1” are configured to establish one shared tunnel.
[0111] A30. The method of solution A28, wherein each operator associated with the indication being set to “0” is configured to establish a separate transport tunnel.
[0112] A31. The method of solution A4 or A17, wherein the session identifier and an MBS Session ID are carried in a Handover Request message, and wherein a target network node is configured to determine, based on the session identifier and the MBS Session ID, whether the transport tunnel has been established. In some examples, the method of solution 31 corresponds to the embodiments described in Section 4.
[0113] A32. The method of solution A31, wherein the transport tunnel is the NG-U tunnel, wherein the Handover Request message further includes an additional identifier associated with the NG-U tunnel, wherein the target network node is configured to: establish, upon determining that the additional identifier is identical for both the target network node and the network node, a data forwarding tunnel between the target network node and the network node; and perform data forwarding to achieve a lossless handover of a wireless device from the network node to the target network node, and wherein the additional identifier is a user plane function (UPF) identifier, a Public Land Mobile Network (PLMN) identifier, or an indication that all core networks, including the first core network and the second core network, are using a common implementation for the multicast reception.
[0114] A33. An apparatus for wireless communication comprising a processor, configured to implement a method recited in one or more of solutions A1 to A32.
[0115] A34. A non-transitory computer readable program storage medium having code stored thereon, the code, when executed by a processor, causing the processor to implement a method recited in one or more of solutions A1 to A32.
[0116] The described features can be implemented to further provide one or more of the following technical solutions:
[0117] B1. The core network sends some associated info about multicast reception to gNB in RAN sharing scenarios, and receives the info about the NG-U tunnel establishment from gNB in RAN sharing scenarios.
[0118] B2. The associated info contains the MBS associated session id which could be used to identify the MBS sessions with the same content from different PLMNs, and can be carried in PDU Session Resource Setup Request message / PDU Session Resource Modify Request message / Distribution Setup Response message.
[0119] B3. The indication on whether to establish a NG-U tunnel is sent from gNB to core network. The indication can be carried in the NGAP Distribution Setup Request message, or in a new NGAP signaling procedure, e.g., NGAP Distribution Modification procedure. According to the indication, core network performs the establishment of NG-U tunnel.
[0120] B4. Some associated info about multicast reception in RAN sharing scenarios can be sent from gNB-CU-CP to gNB-CU-UP. The associated info contains an indication of whether to establish the NG-U tunnel or not and / or the MBS associated session id. The associated info is added to the MC Bearer Context Setup Request message. According to the indication of whether to establish the NG-U tunnel or not, gNB CU-UP allocates the resource for a shared NGAP tunnel, and the corresponding NG-RAN TNL information will be carried in the MC Bearer Context Setup Response message. According to the MBS associated session id, gNB CU-UP decides whether to allocate the resource for a shared NGAP tunnel, and the corresponding NG-RAN TNL information will be carried in the MC Bearer Context Setup Response message.
[0121] B5. An MBS associated session id is added in F1AP Multicast Context Setup Request message / F1AP UE Context Setup Request message / F1AP UE Context Modification Request message. In an example, the same F1-U tunnel information at gNB DU is carried for these multicast sessions in F1AP Multicast Distribution Setup Request message / F1AP UE Context Modification Request message. In another example, the same F1-U tunnel information at gNB CU is carried for these multicast sessions in F1AP Multicast Distribution Setup Response message / F1AP UE Context Modification Response message.
[0122] B6. The F1-U tunnel information will be carried for the first session in the procedure of F1AP Multicast Distribution Setup / F1AP UE Context Modification Request message. For other multicast sessions that belong to the same service at the application layer as the first session, there is no F1-U tunnel information during F1AP Multicast Distribution Setup procedure / F1AP UE Context Modification Response.
[0123] B7. gNB-CU sends the MBS associated session id and its own cell ID to gNB-DU in a F1AP Multicast Context Setup Request message, a F1AP UE Context Setup Request message, or F1AP UE Context Modification Request message. gNB-DU establishes multiple F1-U tunnels if there are multiple cell IDs for the same MBS associated session. This F1-U tunnel information at gNB DU will be carried for these multicast sessions in F1AP Multicast Distribution Setup Response message. And these F1-U tunnel information at gNB DU will be carried for these multicast sessions in E1AP MC Bearer Context Modification Response message.
[0124] B8. An indication for not releasing the corresponding NG-U tunnel resources (or the corresponding F1-U tunnel resources) at NG-RAN is carried in the E1AP MC Bearer Context Release Command message. To confirm the reservation of NG-U tunnel resources (or F1-U tunnel resources) at NG-RAN, an indication about the reservation of NG-U tunnel is carried in E1AP MC Bearer Context Release Complete message.
[0125] B9. gNB sends a NGAP Distribution Modification Request message to request Core Network to establish a new NG-U tunnel for the multicast session in RAN sharing scenario (the session id, NG-U tunnel information at NG-RAN, an indication about NG-U tunnel establishment will be contained in the request message) . Core Network will allocate the NG-U tunnel resource for this session, and put this information in the NGAP Distribution Modification Response message.
[0126] B10. An indication for not releasing the corresponding F1-U tunnel resources at NG-RAN is carried in the F1AP Multicast Context Release Command message. To confirm the reservation of F1-U tunnel resources at NG-RAN, an indication about the reservation of F1-U tunnel is carried in F1AP Multicast Context Release Complete message.
[0127] B11. A global unique UPF ID is carried in the PDU Session Resource Setup request message. If multiple Core Networks deliver data from multiple UPFs for the same multicast service in the same shared gNB, separate NG-U and F1-U tunnels are established for each UPF.
[0128] B12. If gNB CU-UP decides the establishment of NG-U tunnel, the MBS associated session id and the corresponding UPF ID will be carried in E1AP MC Bearer Context Setup Request message. An indication about this information is carried in the PDU Session Resource Setup request message. If Core Network indicates all operators use the same implementations of DL MBS QFI Sequence Number and MBS QoS Flows, gNB will only establish a shared NG-U tunnel for these multicast sessions which are the same service at the application layer.
[0129] B13. MBS associated session id together with MBS Session ID are carried in HANDOVER REQUEST message. Based on this indication, the target gNB can check whether the NG-U tunnel and F1-U tunnel have been established for the session.
[0130] B14. The UPF ID and MBS associated session id together with MBS Session ID are carried in HANDOVER REQUEST message. If the UPF ID carried from the source gNB is the same as the UPF ID used in the target gNB, the target gNB will establish data forwarding tunnel between the source and target gNBs and perform data forwarding to achieve lossless handover.
[0131] B15. The PLMN ID and MBS associated session id together with MBS Session ID are carried in HANDOVER REQUEST message. If the PLMN ID carried from the source gNB is the same with the PLMN ID used for multicast reception in the target gNB, the target gNB will establish data forwarding tunnel between the source gNB and target gNB and perform data forwarding to achieve lossless handover.
[0132] B16. An indication of all operators using the same implementation for this session and MBS associated session id together with MBS Session ID are carried in HANDOVER REQUEST message. Based on this indication, target gNB will establish data forwarding tunnel between the source and target gNBs and perform data forwarding to achieve lossless handover.
[0133] FIG. 3 shows a block diagram of an example hardware platform 300 that may be a part of a network device (e.g., base station) or a communication device (e.g., a user equipment (UE) ) . The hardware platform 300 includes at least one processor 310 and a memory 305 having instructions stored thereupon. The instructions upon execution by the processor 310 configure the hardware platform 300 to perform the operations described in FIGS. 1 and 2 and in the various embodiments described in this patent document. The transmitter 315 transmits or sends information or data to another device. For example, a network device transmitter can send a message to a user equipment. The receiver 320 receives information or data transmitted or sent by another device. For example, a user equipment can receive a message from a network device.
[0134] The implementations as discussed above will apply to a wireless communication. FIG. 4 shows an example of a wireless communication system (e.g., a 5G or NR cellular network) that includes a base station 420 and one or more user equipment (UE) 411, 412 and 413. In some embodiments, the UEs access the BS (e.g., the network) using a communication link to the network (sometimes called uplink direction, as depicted by dashed arrows 431, 432, 433) , which then enables subsequent communication (e.g., shown in the direction from the network to the UEs, sometimes called downlink direction, shown by arrows 441, 442, 443) from the BS to the UEs. In some embodiments, the BS send information to the UEs (sometimes called downlink direction, as depicted by arrows 441, 442, 443) , which then enables subsequent communication (e.g., shown in the direction from the UEs to the BS, sometimes called uplink direction, shown by dashed arrows 431, 432, 433) from the UEs to the BS. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, an Internet of Things (IoT) device, and so on.
[0135] Some of the embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM) , Random Access Memory (RAM) , compact discs (CDs) , digital versatile discs (DVD) , etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.
[0136] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and / or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware or firmware. The connectivity between the modules and / or components within the modules may be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.
[0137] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.
[0138] Only a few implementations and examples are described. and other implementations, enhancements and variations can be made based on what is described and illustrated in this disclosure.
Claims
1.A wireless communication method, comprising:transmitting, by a first core network to a network node, a first information associated with a multicast reception at the network node, andreceiving, from the network node, a second information associated with an establishment of a transport tunnel for the multicast reception,wherein each of the first core network and a second core network is configured to share one or more radio access network resources including the network node.2.A wireless communication method, comprising:receiving, by a network node from a first core network, a first information associated with a multicast reception at the network node, andtransmitting, to the first core network, a second information associated with an establishment of a transport tunnel for the multicast reception,wherein each of the first core network and a second core network is configured to share one or more radio access network resources including the network node.3.The method of claim 1 or 2, wherein the first core network is a 5G Core Network, wherein the network node is a gNodeB, and wherein the transport tunnel is an NG-U tunnel.4.The method of claim 3, wherein the first information comprises a session identifier for a Multicast and Broadcast Service (MBS) session associated with the multicast reception, and wherein the session identifier is used to identify MBS sessions with a same content from different Public Land Mobile Networks (PLMNs) .5.The method of claim 4, wherein the first information is carried in a Protocol Data Unit (PDU) Session Resource Setup Request message, a PDU Session Resource Modify Request message, or a Distribution Setup Response message.6.The method of claim 3, wherein the network node is configured to transmit, to the first core network, an indication that indicates whether to establish the transport tunnel.7.The method of claim 6, wherein the indication is carried in a NG Application Protocol (NGAP) Distribution Setup Request message.8.The method of claim 6, wherein modifying resources associated with the transport tunnel for the multicast reception is based on a NG Application Protocol (NGAP) Distribution Modification procedure, and wherein the indication is carried in an NGAP Distribution Modification Request message.9.The method of any of claims 6 to 8, wherein the first core network is configured to perform, based on the indication, the establishment of the transport tunnel.10.The method of claim 4, wherein the first information is sent from a control plane of the network node to a user plane of the network node.11.The method of claim 10, wherein the first information comprises an indication of whether to establish the transport tunnel and / or the session identifier.12.The method of claim 11, wherein the first information is carried in an MC Bearer Context Setup Request message or an MC Bearer Context Modification Request message.13.The method of claim 11, wherein the user plane is configured, based on the indication or the session identifier, to allocate a resource for a shared transport tunnel, and wherein a transport layer information corresponding to the shared transport tunnel is sent from the user plane to the control plane.14.The method of claim 13, wherein the transport layer information is NG-RAN NG-U Transport Network Layer (TNL) information that is carried in an MC Bearer Context Setup Response message or an MC Bearer Context Modification Response message.15.The method of any of claims 10 to 14, wherein the control plane comprises a gNB-CU-Control Plane (gNB-CU-CP) , and wherein the user plane comprises a gNB-CU-User Plane (gNB-CU-UP) .16.The method of claim 3, wherein the second information is carried in a NG Application Protocol (NGAP) Distribution Modification Request message, and wherein the first core network is configured, upon allocating resources for the transport tunnel, to transmit information related to the resources in a NGAP Distribution Modification Response message.17.The method of claim 1 or 2, wherein the first core network is a 5G Core Network, wherein the network node is a gNodeB, wherein the transport tunnel is an F1-U tunnel, wherein a session identifier for a Multicast and Broadcast Service (MBS) session is associated with the multicast reception, and wherein the session identifier is used to identify MBS sessions with a same content from different Public Land Mobile Networks (PLMNs) .18.The method of claim 17, wherein the session identifier is carried in an F1AP Multicast Context Setup Request message, an F1AP UE Context Setup Request message, or an F1AP UE Context Modification Request message.19.The method of claim 17, wherein the transport tunnel is a single transport tunnel for the MBS sessions from the different PLMNs, wherein information associated with the transport tunnel for only a first session of the MBS sessions is carried in an F1AP Multicast Distribution Setup procedure message or an F1AP UE Context Modification Request message.20.The method of claim 17, wherein the session identifier and an identifier of the network node are sent from a centralized unit (CU) of the network node to a distributed unit (DU) of the network node in an F1AP Multicast Context Setup Request message.21.The method of claim 17, wherein the session identifier is associated with multiple cell identifiers, wherein a distributed unit (DU) of the network node is configured to establish multiple transport tunnels, and wherein each of the multiple transport tunnels is associated with a corresponding cell identifier of the multiple cell identifiers.22.The method of claim 17, wherein an indication for refraining from releasing the transport tunnel is carried in an F1AP Multicast Context Release Command message, and wherein an indication for reserving resources for the transport tunnel is carried in an F1AP Multicast Context Release Complete message.23.The method of claim 3 or 17, wherein an indication for refraining from releasing the transport tunnel is carried in an E1AP MC Bearer Context Release Command message.24.The method of claim 3 or 17, wherein an indication for reserving resources for the transport tunnel is carried in an E1AP MC Bearer Context Release Complete message.25.The method of claim 4 or 17, wherein multiple core networks deliver data from multiple user plane functions (UPFs) to the network node for the multicast reception, wherein a global unique UPF identifier is carried in a Protocol Data Unit (PDU) Session Resource Setup Request message, and wherein the transport tunnel is established for each of the multiple UPFs.26.The method of claim 25, wherein the transport tunnel is the NG-U tunnel, wherein the session identifier and a corresponding UPF identifier are carried in an E1AP MC Bearer Context Setup Request message.27.The method of claim 26, wherein an indication of the establishment of the transport tunnel for the corresponding UPF identifier is carried in the PDU Session Resource Setup Request message or a NG Application Protocol (NGAP) Distribution Setup Response message.28.The method of claim 3 or 17, wherein, for an operator associated with the indication, the indication being set to “1” indicates the operator using a common implementation of the multicast reception, and the indication being set to “0” indicates the operator using a distinct implementation for the multicast reception.29.The method of claim 28, wherein all operators associated with the indication being set to “1” are configured to establish one shared tunnel.30.The method of claim 28, wherein each operator associated with the indication being set to “0” is configured to establish a separate transport tunnel.31.The method of claim 4 or 17, wherein the session identifier and an MBS Session ID are carried in a Handover Request message, and wherein a target network node is configured to determine, based on the session identifier and the MBS Session ID, whether the transport tunnel has been established.32.The method of claim 31, wherein the transport tunnel is the NG-U tunnel, wherein the Handover Request message further includes an additional identifier associated with the NG-U tunnel, wherein the target network node is configured to:establish, upon determining that the additional identifier is identical for both the target network node and the network node, a data forwarding tunnel between the target network node and the network node; andperform data forwarding to achieve a lossless handover of a wireless device from the network node to the target network node, andwherein the additional identifier is a user plane function (UPF) identifier, a Public Land Mobile Network (PLMN) identifier, or an indication that all core networks, including the first core network and the second core network, are using a common implementation for the multicast reception.33.An apparatus for wireless communication comprising a processor, configured to implement a method recited in one or more of claims 1 to 32.34.A non-transitory computer readable program storage medium having code stored thereon, the code, when executed by a processor, causing the processor to implement a method recited in one or more of claims 1 to 32.
Citation Information
Patent Citations
Session establishment method and device
CN115484555A
Tunnel reuse for multicast and broadcast services
CN115669189A
Communication method and apparatus
WO2022228177A1
Base station, network node, first core network node, second core network node, and methods performed by them
WO2023120174A1
Method and device for providing broadcast service in wireless communication system
WO2023191389A1