Multicast reception in wireless access network sharing

Abstract

Techniques for supporting multicast reception in a shared Radio Access Network (RAN) implementation are described. The disclosed embodiments provide methods, systems, and apparatus for supporting multicast services for inactive wireless devices. An example wireless communication method includes: a first core network transmitting first information to a network node, the first information being associated with multicast reception at the network node; and receiving second information from the network node, the second information being associated with establishing a transmission tunnel for multicast reception. In this example, both the first and second core networks are configured to share one or more RAN resources, including the network node.

Description

Technical Field

[0001] This disclosure generally relates to digital wireless communications. Background Technology

[0002] Mobile telecommunications technologies are driving the world toward an increasingly interconnected and networked society. Compared to existing wireless networks, next-generation systems and wireless communication technologies will need to support a wider range of use case characteristics and provide more complex and granular access requirements and flexibility.

[0003] Long Term Evolution (LTE) is a wireless communication standard developed by the 3rd Generation Partnership Project (3GPP) for mobile devices and data terminals. LTE Advanced (LTE-A) is a wireless communication standard that enhances the LTE standard. The fifth-generation wireless system (known as 5G) advances the LTE and LTE-A wireless standards and aims to support higher data rates, massive connectivity, ultra-low latency, high reliability, and other emerging service requirements. Summary of the Invention

[0004] Techniques for supporting multicast reception in shared radio access networks (RAN) scenarios are disclosed. 5G Multicast and Broadcast Services (MBS) are point-to-multipoint services that can improve network efficiency and user experience when transmitting the same content to multiple users. The described embodiments advantageously improve the resource efficiency of MBS multicast transmission in RAN-shared scenarios.

[0005] In one example, a wireless communication method includes: a first core network transmitting first information to a network node, the first information being associated with multicast reception at the network node; and receiving second information from the network node, the second information being associated with establishing a transmission tunnel for multicast reception. In this example, both the first core network and the second core network are configured to share one or more radio access network resources, including the network node.

[0006] In another example, a wireless communication method includes: a network node receiving first information from a first core network, the first information being associated with multicast reception by the network node, and then transmitting second information to the first core network, the second information being associated with establishing a transmission tunnel for multicast reception. In this example, both the first and second core networks are configured to share one or more radio access network resources, including the network node.

[0007] In yet another example, the above-described method is embodied in processor-executable code and stored in a non-transitory computer-readable storage medium. When executed by a processor, the code contained in the computer-readable storage medium causes the processor to implement the method described in this patent document.

[0008] In yet another example, an apparatus configured or operable to perform the methods described above is disclosed.

[0009] The above and other aspects and their embodiments are described in more detail in the accompanying drawings, description and claims. Attached Figure Description

[0010] Figure 1 A flowchart of an example wireless communication method is shown.

[0011] Figure 2 A flowchart of another example wireless communication method is shown.

[0012] Figure 3 An exemplary block diagram is shown, which may be part of a network device or a communication device.

[0013] Figure 4 Examples of wireless communication based on some implementations of the disclosed technology are shown, including a base station (BS) and a user equipment (UE). Detailed Implementation

[0014] Multicast and Broadcast Services (MBS) are considered one of the most important use cases for 5G NR, providing reliable, low-latency, and resource-efficient transmission for multiple devices that need to receive the same content. Its primary use cases involve congested areas such as concert halls, stadiums, and racetracks. In some situations, video needs to be synchronized with the devices, while in others, multiple viewpoints are required. In another example, MBS is well-suited when a large number of users in the same cell are simultaneously watching a virtual reality (VR) live stream (e.g., in an emergency). However, these deployments of MBS can potentially require significant investment.

[0015] Network sharing mechanisms allow operators to reduce the high costs associated with initial deployment, capital expenditures (CAPEX), and operating expenditures (OPEX). A network sharing architecture allows multiple operators to share the resources of a single shared network based on mutually agreed allocation schemes. The shared network includes the radio access network (RAN), and the shared resources include radio resources.

[0016] In 5G NR, multicast / broadcast transmission is provided. In RAN-shared deployment scenarios, if the same multicast / broadcast service is provided separately by two (or more) operators, the service is considered to have a separate Temporary Mobile Group Identities (TMGI) because it consumes duplicate point-to-multipoint (PTM) radio resources in the same cell to transmit the same content. This operation, for example, demonstrates the necessity of improving resource efficiency in RAN-shared scenarios.

[0017] In Rel-18 NR MBS, several solutions were introduced to improve the resource efficiency of MBS broadcast transmission in RAN-shared scenarios. However, how to enhance MBS multicast transmission processes to improve resource efficiency in RAN-shared scenarios has never been discussed. Embodiments of the disclosed technology provide methods, systems, and apparatus for improving the resource efficiency of MBS multicast transmission in RAN-shared scenarios.

[0018] The example headings in the following sections are for ease of understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Therefore, one or more features of one example section may be combined with one or more features of another example section. Furthermore, for clarity, the term "5G" is used, but the technologies disclosed in this document are not limited to 5G technology and can also be used in wireless systems implementing other protocols.

[0019] 1. Example of the first UE joining a multicast session in a RAN-shared scenario In some embodiments, to improve the resource efficiency of multicast transmission in RAN-shared scenarios, some NGAP, E1AP, and F1AP signaling interactions are updated. These signaling interactions are used for multicast MBS session context establishment, where the UE joining the multicast session is used as the first UE to join its serving gNB. The following aspects are considered when updating the signaling interactions.

[0020] Identify the same MBS service In existing implementations, the gNB lacks access to information that enables it to determine whether two or more MBS services are identical (e.g., carrying the same content). Embodiments of the disclosed technology enable the identification of identical MBS services, which advantageously allows the gNB to allocate the same set of resources to avoid duplication.

[0021] In some embodiments, the core network (CN) sends a session identifier associated with the MBS, which can be used to identify MBS sessions with the same content from different PLMNs. The session identifier associated with the MBS can be carried through PDU session resource establishment request messages, PDU session resource modification request messages, or distribution establishment response messages.

[0022] In some examples, the core network transmits the session identifier and MBS session ID associated with the MBS as part of the PDU session resource establishment process for multicast reception. For example, the session identifier associated with the MBS is added to the MBS session ID in the PDU session resource establishment request message. Based on the session identifier associated with the MBS, the gNB can identify that MBS sessions with different session IDs (e.g., TMGI or IP multicast addresses) are serving the same MBS service at the application layer. If the gNB can identify which sessions correspond to the same MBS service, it can avoid allocating duplicate resources to these sessions.

[0023] In some examples, the core network transmits the session identifier associated with the MBS and the MBS session ID as part of the PDU session resource modification process received via multicast. For example, the session identifier associated with the MBS is added to the MBS session ID in the PDU session resource modification request message. Based on the session identifier associated with the MBS, the gNB can identify that MBS sessions with different session IDs (e.g., TMGI or IP multicast addresses) are serving the same MBS service at the application layer. If the gNB can identify which sessions correspond to the same MBS service, it can avoid allocating duplicate resources to these sessions.

[0024] In some examples, the core network delivers the session identifier and MBS session ID associated with the MBS as part of the multicast reception distribution setup process. For instance, the session identifier associated with the MBS is added to the MBS session ID in the distribution setup response message. Based on the session identifier associated with the MBS, the gNB can identify that MBS sessions with different session IDs (e.g., TMGI or IP multicast addresses) are serving the same MBS service at the application layer. If the gNB can identify which sessions correspond to the same MBS service, it can avoid allocating duplicate resources to these sessions.

[0025] Building an NG-U tunnel In existing implementations, there are two RAN sharing scenarios: - Multiple Operator Core Network (MOCN) scenario, in which multiple operators share a gNB, which includes gNB-CU (centralized unit) and gNB-DU (distributed unit). - Multi-cell ID scenario, where multiple operators share a common gNB-DU, but have separate (and different) gNB-CUs.

[0026] Embodiments of the disclosed technology advantageously enable the establishment of NG-U tunnels for multicast reception in RAN-shared scenarios. In an example where multiple operators share a single gNB, only one NG-U tunnel is used for multicast reception, thereby avoiding the allocation of duplicate resources for the same service. That is, it is not necessary to establish separate NG-U tunnels for each operator, and the establishment of the NG-U tunnels is based on the gNB implementation.

[0027] Here, NG-RAN tunnel information is provided by gNB CU-UP, and therefore there are two possible solutions for establishing shared NG-U tunnels: 1. The gNB CU-CP determines the establishment of a shared NG-U tunnel, or 2. gNB CU-UP decides to establish a shared NG-U tunnel.

[0028] In some examples, if the gNB CU-CP decides to establish a shared NG-U tunnel, it notifies the gNB CU-UP of this decision as part of the MC bearer context establishment process. For example, it adds an indication of whether to establish an NG-U tunnel to the MC bearer context establishment request message. Based on this indication, the gNB CU-UP allocates resources for the shared NG-U tunnel. If the gNB CU-CP notifies the gNB CU-UP that it will not establish an NG-U tunnel for the multicast session, the gNB CU-UP will not allocate resources for the shared NG-U tunnel. However, if the gNB CU-CP notifies the gNB CU-UP that it will establish an NG-U tunnel for the multicast session, the gNBCU-UP will allocate resources for the shared NG-U tunnel and notify the gNB CU-CP of the corresponding NG-RAN Transport Network Layer (TNL) information.

[0029] In some examples, the gNB CU-CP transmits the session identifier associated with the MBS along with the MBS session ID as part of the MC bearer context establishment process; for example, by adding the session identifier associated with the MBS to the MC bearer context establishment 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).

[0030] In some examples, if the gNB CU-UP decides to establish a shared NG-U tunnel, the gNB CU-CP transmits the session identifier associated with the MBS and the MBS session ID to the gNB CU-UP as part of the MC bearer context establishment procedure. For example, the session identifier associated with the MBS is added to the MC bearer context establishment request message. Based on this indication, the gNB CU-UP allocates resources for the shared NGAP tunnel. If the session identifier associated with the MBS is present in the MC bearer context establishment request message, and the gNB CU-UP decides to establish an NG-U tunnel for that multicast session, the corresponding NG-RAN TNL information is notified to the gNB CU-CP. However, if the gNB CU-UP decides not to establish an NG-U tunnel for that multicast session, it can carry an indication not to establish an NG-U tunnel through the MC bearer context establishment response message.

[0031] In some embodiments, the gNB notifies the core network of its decision regarding whether to establish an NG-U tunnel. In one example, an NGAP-distributed Establish Request message carries an indication of whether to establish an NG-U tunnel. If the gNB decides not to establish an NG-U tunnel, there is no information about a shared NG-U tunnel, but the distributed Establish Request message carries an indication of not establishing an NG-U tunnel (e.g., a 1-bit indication). Based on this indication, the core network establishes the NG-U tunnel. However, if there is no information about an NG-U tunnel, and an indication of not establishing an NG-U tunnel exists, the core network will not establish the corresponding NG-U tunnel for that multicast session.

[0032] Construct the F1-U tunnel In some embodiments, the gNB CU-CP establishes a multicast context at the DU. During this process, it is determined whether to establish a logical F1 connection associated with the MBS for each multicast session, even if the multicast sessions are for the same service at the application layer. Furthermore, it is determined whether to establish an F1-U tunnel for each multicast session in a RAN-shared scenario.

[0033] In some embodiments, for MOCN scenarios, since there is only one shared CU and DU, only one NG-U tunnel and one F1-U tunnel can be established for multicast sessions that provide the same service at the application layer. For multi-cell ID scenarios, since there are multiple CUs, they can establish separate NG-U tunnels for the same multicast service. In this scenario, existing implementations do not provide how to establish F1-U tunnels; for example, should only one F1-U tunnel be established for the same multicast service, or should multiple F1-U tunnels be established for multiple CUs?

[0034] In some examples, for each multicast session that is the same session at the application layer, a separate logical F1 connection associated with the MBS is established, but only one shared F1-U tunnel is established for these multicast sessions. To achieve this, the session identifier associated with the MBS is carried from the gNB CU-CP to the gNB DU, for example, by adding the session identifier associated with the MBS to the F1AP multicast context establishment request message, the F1AP UE context establishment request message, or the F1AP UE context modification request message.

[0035] In some examples, for these multicast sessions that are the same session at the application layer, there is only one F1-U tunnel in a RAN-shared scenario. To achieve this, the same F1-U tunnel information is carried from the gNB DU to the gNB CU-CP, for example, the same F1-U tunnel information in the multicast distribution establishment request message. If the same F1-U tunnel information is carried from the gNB DU, then in response, the same F1-U tunnel address information is provided from the gNB CU. For example, the same gNB DU F1-U tunnel information is carried for these multicast sessions via the F1AP multicast distribution establishment request message and the E1AP MC bearer context modification request, and the same gNB CU F1-U tunnel information is carried for these multicast sessions via the F1AP multicast distribution establishment response message and the E1AP MC bearer context modification response message.

[0036] In some examples, for multicast sessions that are the same session at the application layer, there is only one F1-U tunnel in a RAN-shared scenario. To achieve this, F1-U tunnel information is carried from the gNB DU only when the context of the first multicast session is established in the DU. For other multicast sessions that are the same service at the application layer, no F1-U tunnel information is carried from the gNB-DU. In this case, when the first multicast session is established in the DU, the gNB-CU also only carries the corresponding F1-U tunnel information to the gNB DU. That is, F1-U tunnel information will be carried for the first session during the F1AP multicast distribution establishment and E1AP MC bearer context modification procedures. For other multicast sessions that are the same service as the first session at the application layer, no F1-U tunnel information is carried during the F1AP multicast distribution establishment and E1AP MC bearer context modification procedures.

[0037] In some examples, in multi-cell ID scenarios, for each multicast session that is the same session at the application layer, the multicast session establishes its own logical F1 connection associated with the MBS, but establishes an F1-U tunnel for each CU. For example, the gNB-CU sends the session identifier associated with the MBS and its respective cell ID to the gNB-DU in an F1AP multicast context establishment request message, an F1 AP UE context establishment request message, or an F1 AP UE context modification request message. If the same MBS associated session has multiple cell IDs, the gNB-DU will establish multiple F1-U tunnels. The F1-U tunnel information for the gNB-DU will be carried for these multicast sessions in the F1AP multicast distribution establishment response message and the E1APMC bearer context establishment / modification response message.

[0038] In some examples, in multi-cell ID scenarios, for each multicast session that is the same session at the application layer, the multicast session establishes its own logical F1 connection associated with the MBS, but only one shared F1-U tunnel is established for these multicast sessions. For example, the gNB-CU sends the session identifier associated with the MBS and its respective cell ID to the gNB-DU in the F1AP multicast context establishment request message, F1AP UE context establishment request message, or F1AP UE context modification request message. Even if multiple cell IDs exist, the gNB-DU will establish only one F1-U tunnel. The same gNB-DU F1-U tunnel information is carried for these multicast sessions through the F1AP multicast distribution establishment request message and the E1AP MC bearer context modification request, and the same gNB-DU F1-U tunnel information is carried for these multicast sessions through the F1AP multicast distribution establishment response message and the E1AP MC bearer context establishment / modification response message.

[0039] In some examples, in multi-cell ID scenarios, if multiple NG-U tunnels exist but only one F1-U tunnel, the gNB-CU can decide to release some NG-U tunnels after the F1-U tunnel is established. For instance, the indication information of the NG-U tunnels to be released is carried from the gNB to the core network via a PDU session resource modification indication message or a distribution modification request message. The core network will release the NG-U tunnel based on this information, but the other context of the session will still be preserved. A PDU session resource modification confirmation message or a distribution modification response message will be sent to confirm the result of the request from the core network to the gNB.

[0040] 2. Examples of other UEs joining a multicast session in a RAN-shared scenario In some embodiments, in a RAN-shared scenario, for multiple multicast sessions serving the same service at the application layer, the gNB may establish only one NG-U tunnel. If the network establishes an NG-U tunnel when the first UE joins the session, then when a UE from another operator requests to join the same session, the NG-U tunnel will not be established again. An indication that no NG-U tunnel has been established is sent from the gNB to the core network via an NGAP-distributed establishment request message. Based on this information, the core network will not establish a (duplicate) NG-U tunnel for that session.

[0041] 3. Example of NG-U tunnel handover in RAN sharing scenario If all UEs belonging to an operator that has joined a session leave the current gNB, or if the operator releases the session, embodiments of the disclosed technology provide techniques for handling resources associated with that session (e.g., NG-U tunnels, F1-U tunnels, etc.).

[0042] Handling NG-U tunnels As previously described, in a RAN-shared scenario, for multiple multicast sessions serving the same service at the application layer, the gNB can establish only one NG-U tunnel. The NG-U tunnel can be released when a UE belonging to the operator that established the NG-U tunnel for it leaves the current gNB or is no longer interested in the multicast session. However, because there are other sessions from other operators serving the same service at the application layer that need to be transmitted, the gNB should establish a new NG-U tunnel in the RAN-shared scenario. In this case, the described embodiment determines whether the gNB CU-UP should release the NG-RAN NG-U tunnel resources and how to establish a new NG-U tunnel for another operator.

[0043] E1AP Signaling Interaction In some examples, when a gNB in ​​a legacy system releases a multicast session, the corresponding context, including NG-U tunnel information, should be released. However, in RAN-shared scenarios, NG-U tunnel resources for NG-RAN may not be released because they are being shared by other multicast sessions serving the same service at the application layer. The E1AP MC bearer context release command message carries an indication not to release the corresponding NG-U tunnel resources for NG-RAN. The gNB CU-UP will only release all associated signaling and multicast radio bearer (MRB) resources, but not NG-U tunnel resources, such as the GPRS Tunneling Protocol (GTP) downlink (DL) tunnel endpoint identifier (TEID). To confirm the reservation of NG-U tunnel resources for NG-RAN, the E1AP MC bearer context release completion message carries an indication regarding the NG-U tunnel reservation.

[0044] NGAP signaling interaction In some examples, to support NG-U tunnel handover in RAN-shared scenarios, a new procedure (e.g., the NGAP distribution modification procedure) is defined to modify the establishment of the NG-U tunnel after the first UE joins the multicast session. Here, the gNB sends an NGAP distribution modification request message to request the core network to establish a new NG-U tunnel for the multicast session in the RAN-shared scenario. In one example, the request message includes the session identifier, NG-U tunnel information for the NG-RAN, and instructions regarding the establishment of the NG-U tunnel. The core network allocates NG-U tunnel resources for the session and places this information in the NGAP distribution modification response message.

[0045] Handling F1-U tunnel In some embodiments, as described above, in a RAN-shared scenario, for multiple multicast sessions serving the same service at the application layer, the gNB may establish only one F1-U. When the gNB releases one of the multicast sessions in a legacy system, it releases the corresponding context and F1-U tunnel resources as part of the multicast context release procedure. However, because other sessions from other operators serving the same service at the application layer need to be transmitted, the gNB should retain the F1-U tunnel in a RAN-shared scenario. The disclosed embodiments provide a technique for retaining F1-U tunnel resources while releasing the session context.

[0046] F1AP Signaling Interaction In some examples, the F1AP multicast context release command message carries an indication not to release the corresponding F1-U tunnel resources on the NG-RAN. The gNB DU will only release all associated signaling and MRB resources, but not the F1-U tunnel resources. To confirm the reservation of F1-U tunnel resources on the NG-RAN, the F1AP multicast context release completion message carries an indication regarding the reservation of F1-U tunnels.

[0047] E1AP Signaling Interaction In some examples, the E1AP MC bearer context release command message carries an indication not to release the F1-U tunnel resources corresponding to the NG-RAN. The gNB DU will only release all associated signaling and MRB resources, but not the F1-U tunnel resources. To confirm the reservation of F1-U tunnel resources for the NG-RAN, the E1AP MC bearer context release completion message carries an indication regarding the reservation of F1-U tunnels.

[0048] Lossless guarantee when switching NG-U tunnels In some embodiments, NG-U tunnel handover is possible for multicast services in RAN-shared scenarios. However, if different tunnels transmit multicast data from different UPFs, the DL MBS QoS Flow Identifier (QFI) sequence number and MBS QoS flow may differ. In this case, embodiments of the disclosed technology can still guarantee lossless handover.

[0049] In some examples, to support lossless multicast data in RAN-shared scenarios, multiple core networks transmit data from multiple UPFs to the same multicast service in the same shared gNB, establishing separate NG-U and F1-U tunnels for each UPF. To achieve this, a globally unique UPF ID is delivered from the core network to the gNB. For example, the globally unique UPF ID is carried via a PDU session resource establishment request message. The gNB establishes the corresponding NG-U tunnel based on this information. If the gNB CU-CP decides to establish an NG-U tunnel, the decision is carried via an E1AP MC bearer context establishment request message, and gNBCU-UP allocates the corresponding NG-U tunnel resources (e.g., GTP DL TEID). If the gNB CU-UP decides to establish an NG-U tunnel, the session identifier associated with the MBS and the corresponding UPF ID are carried via an E1AP MC bearer context establishment request message, and the gNB allocates the corresponding NG-U tunnel resources (e.g., GTP DL TEID).

[0050] In some examples, the establishment of an F1-U tunnel is also based on this information. For instance, an F1AP multicast context establishment request message carries an indication of whether to establish an F1-U tunnel for the session. The gNB DU allocates F1-U tunnel resources based on this indication and notifies the gNB CU of the F1-U tunnel information via an F1AP multicast distribution establishment request message. The gNB CU then allocates the corresponding F1-U tunnel resources based on this information.

[0051] In some examples, to support lossless multicast data in RAN-shared scenarios (and the same multicast services at the application layer), all operators use the same DL MBS QFI sequence number and MBS QoS flow. This information is indicated via the PDU Session Resource Establishment Request message. If the core network instructs all operators to use the same DL MBS QFI sequence number and MBS QoS flow, the gNB will establish a shared NG-U tunnel only for these multicast sessions that provide the same service at the application layer. Otherwise, if there is no such indication in the PDU Session Resource Establishment Request message, the gNB treats it as a normal session, for example, establishing a separate NG-U tunnel for each session.

[0052] In some examples, no data loss during multicast reception is not supported when switching NG-U tunnels in a RAN-shared scenario. Typically, how different DLMBS QFI sequence numbers and MBS QoS flows received from different PLMNs for the same shared service (i.e., with the same associated session ID) depends on the NG-RAN node implementation. When a tunnel switch occurs, and if the DLMBS QFI sequence number and MBS QoS flow differ from the previous one, a configuration update can be performed, for example, through an E1APMC bearer context modification procedure, an F1AP multicast context modification procedure, or an RRC reconfiguration procedure.

[0053] 4. Examples of mobility in RAN sharing scenarios In some embodiments, two scenarios are considered regarding lossless handover of multicast reception in RAN-sharing scenarios.

[0054] Case 1 。 The DL MBS QFI sequence number and MBS QoS flow used in the core network of the source gNB and the target gNB are the same. For example, the NG-U tunnel used in the source gNB and the target gNB comes from the same UPF / core network, or the operators generally use the same implementation.

[0055] Case 2 。 The DL MBS QFI sequence numbers and MBS QoS flows used in the core networks of the source gNB and the target gNB are different. For example, the NG-U tunnels used in the source gNB and the target gNB come from different UPF / core networks.

[0056] For scenario 1, no data loss can be supported during handover. To support lossless handover, some information is transmitted from the source gNB to the target gNB. For scenario 2, no data loss can be supported during handover.

[0057] In some examples, the source gNB delivers UPF information associated with the NG-U tunnel received via multicast. For instance, this might be achieved by carrying the UPF ID and the session identifier associated with the MBS, as well as the MBS session ID, in the handover request message. If the UPF ID carried by 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 and target gNBs and perform data forwarding to achieve a lossless handover.

[0058] In some examples, for case 1, lossless handover can be supported. To support lossless handover, the source gNB transmits core network information associated with the NG-U tunnel used for multicast reception. For example, this is carried in the handover request message carrying the PLMN ID, the session identifier associated with the MBS, and the MBS session ID. 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 establishes a data forwarding tunnel between the source and target gNBs and performs data forwarding to achieve lossless handover.

[0059] In some examples, for case 1, no data loss can be supported during handover. To support lossless handover, an indication is delivered from the source gNB that all operators use the same DL MBS QFI sequence number and MBS QoS flow for this multicast service. For example, this is carried in a handover request message, along with an indication that all operators use the same implementation for this session, the session identifier associated with the MBS, and the MBS session ID. Based on this indication, the target gNB establishes a forwarding tunnel between the source and target gNBs and performs data forwarding to achieve lossless handover.

[0060] In some examples, to avoid allocating duplicate resources for such sessions, the session identifier associated with the MBS is sent to the target gNB as part of the process during the handover preparation phase. For example, this could be done via a handover request message carrying the session identifier associated with the MBS and the corresponding MBS session ID. Based on this indication, the target gNB can check if an NG-U tunnel and an F1-U tunnel have already been established for the session. If so, they can be reused. If not, they need to be re-established.

[0061] 5. Methods and implementation methods of the disclosed technologies Figure 1 A flowchart of an example wireless communication method 100 is shown. Method 100 includes operation 110, in which a first core network transmits first information to a network node, the first information being associated with multicast reception by the network node.

[0062] Method 100 includes operation 120, receiving second information from a network node, the second information being associated with establishing a transport tunnel for multicast reception. In this example, each of the first core network and the second core network is configured to share one or more radio access network resources, including the network node.

[0063] Figure 2 A flowchart of an example wireless communication method 200 is shown. Method 200 includes operation 210, in which a network node receives first information from a first core network, the first information being associated with multicast reception by the network node.

[0064] Method 200 includes operation 220, transmitting second information to a first core network, the second information being associated with establishing a transport tunnel for multicast reception. In this example, each of the first and second core networks is configured to share one or more radio access network resources, including the network node.

[0065] The described features can be implemented to further provide one or more of the following technical solutions: A1. A wireless communication method, comprising: a first core network transmitting first information to a network node, the first information being associated with multicast reception of the network node; and receiving second information from the network node, the second information being associated with establishing a transmission tunnel for multicast reception, wherein each of the first core network and the second core network is configured to share one or more radio access network resources, the radio access network resources including the network node.

[0066] A2. A wireless communication method, comprising: a network node receiving first information from a first core network, the first information being associated with multicast reception of the network node; and transmitting second information to the first core network, the second information being associated with establishing a transmission tunnel for 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, the radio access network resources including the network node.

[0067] A3. The method described in scheme A1 or A2, wherein the first core network is a 5G core network, the network node is a gNodeB, and the transport tunnel is an NG-U tunnel. In some examples, the method of scheme 3 corresponds to the establishment of an NG-U tunnel described in Section 1.

[0068] A4. The method of scheme A3, wherein the first information includes a session identifier of a multicast broadcast service (MBS) session associated with the multicast reception, and wherein the session identifier is used to identify MBS sessions with the same content from different public land mobile networks (PLMNs). In some examples, the method of scheme 4 corresponds to the identification of the same MBS service described in Section 1.

[0069] A5. The method described in scheme A4, wherein the first information is carried through a Protocol Data Unit (PDU) session resource establishment request message, a PDU session resource modification request message, or a distribution establishment response message.

[0070] A6. The method as described in scheme A3, wherein the network node is configured to transmit an indication to the first core network for indicating whether to establish the transmission tunnel.

[0071] A7. The method described in scheme A6, wherein the indication is carried by distributing an establishment request message via the NG Application Protocol (NGAP).

[0072] A8. The method as described in scheme A6, wherein the resource associated with the transport tunnel for multicast reception is modified based on the NG Application Protocol (NGAP) distribution modification procedure, and wherein the indication is carried by distributing a modification request message via NGAP.

[0073] A9. The method of any one of schemes A6 to A8, wherein the first core network is configured to establish the transmission tunnel based on the instruction.

[0074] A10. The method as described in scheme A4, wherein the first information is sent from the control plane of the network node to the user plane of the network node.

[0075] A11. The method as described in scheme A10, wherein the first information includes an indication of whether to establish the transport tunnel and / or the session identifier.

[0076] A12. The method described in scheme A11, wherein the request message is established through the MC bearer context or the request message is modified by the MC bearer context to carry the first information.

[0077] A13. The method as described in scheme A11, wherein the user plane is configured to allocate resources for the shared transport tunnel based on the indication or the session identifier, and wherein transport layer information corresponding to the shared transport tunnel is sent from the user plane to the control plane.

[0078] A14. The method described in scheme A13, wherein the transport layer information is the NG-RAN NG-U transport network layer (TNL) information carried by the MC bearer context to establish a response message or modify the response message through the MC bearer context.

[0079] A15. The method of any one of schemes A10 to A14, wherein the control plane includes gNB-CU-control plane (gNB-CU-CP), and wherein the user plane includes gNB-CU-user plane (gNB-CU-UP).

[0080] A16. The method as described in scheme A3, wherein the modification request message is distributed via NG Application Protocol (NGAP) to carry the second information, and wherein the first core network is configured to transmit information related to the resource in the NGAP distribution modification response message when the resource is allocated for the transport tunnel.

[0081] A17. The method as described in scheme A1 or A2, wherein the first core network is a 5G core network, the network node is a gNodeB, the transport tunnel is an F1-U tunnel, a session identifier of a multicast broadcast service (MBS) session is associated with the multicast reception, and the session identifier is used to identify MBS sessions with the same content from different Public Land Mobile Networks (PLMNs). In some examples, the method of scheme 17 corresponds to the establishment of an F1-U tunnel as described in Section 1.

[0082] A18. The method described in scheme A17, wherein the session identifier is carried by an F1AP multicast context establishment request message, an F1AP UE context establishment request message, or an F1AP UE context modification request message.

[0083] A19. The method as described in scheme A17, wherein the transport tunnel is a single transport tunnel for MBS sessions from different PLMNs, wherein an establishment procedure message or an F1AP UE context modification request message is distributed via F1AP multicast to carry information associated with the transport tunnel used only for the first session in the MBS session.

[0084] A20. The method as described in scheme A17, wherein the session identifier and the identifier of the network node are sent from the centralized unit (CU) of the network node to the distributed unit (DU) of the network node via an F1AP multicast context establishment request message.

[0085] A21. The method as described in scheme A17, wherein the session identifier is associated with multiple cell identifiers, wherein the distributed unit (DU) of the network node is configured to establish multiple transmission tunnels, and wherein each of the multiple transmission tunnels is associated with a corresponding cell identifier among the multiple cell identifiers.

[0086] A22. The method as described in scheme A17, wherein the F1AP multicast context release command message bearer indicates an indication to avoid releasing the transport tunnel, and wherein the F1AP multicast context release completion message bearer indicates an indication to reserve resources for the transport tunnel.

[0087] A23, the method as described in scheme A3 or A17, wherein the E1AP MC bearer context release command message carries an indication to avoid releasing the transport tunnel.

[0088] A24. The method described in schemes A3 or A17, wherein the E1AP MC bearer context release completes the message bearer's indication for reserving resources for the transport tunnel.

[0089] A25. The method described in schemes A4 or A17, wherein multiple core networks transmit data from multiple User Plane Functions (UPFs) to the network nodes receiving multicast data, wherein a globally unique UPF identifier is carried by a Protocol Data Unit (PDU) Session Resource Establishment Request message, and wherein the transmission tunnel is established for each of the multiple UPFs.

[0090] A26. The method described in scheme A25, wherein the transmission tunnel is the NG-U tunnel, wherein the E1AP MC carries the session identifier and the corresponding UPF identifier through the context establishment request message.

[0091] A27. The method as described in scheme A26, wherein the PDU session resource establishment request message or the NG application protocol NGAP distribution establishment response message carries an indication for establishing the transmission tunnel for the corresponding UPF identifier.

[0092] A28. The method as described in scheme A3 or A17, wherein, for the operator associated with the indication, the indication is set to "1" to indicate that the operator uses a general implementation of multicast reception, and the indication is set to "0" to indicate that the operator uses a differentiated implementation of multicast reception.

[0093] A29. The method described in scheme A28, wherein all operators associated with the indication set to "1" are configured to establish a shared tunnel.

[0094] A30, as described in scheme A28, wherein each operator associated with the indication set to "0" is configured to establish a separate transmission tunnel.

[0095] A31. The method as described in schemes A4 or A17, wherein the session identifier and MBS session ID are carried by a switching request message, and wherein the target network node is configured to determine whether the transport tunnel has been established based on the session identifier and the MBS session ID. In some examples, the method of scheme 31 corresponds to the embodiment described in Section 4.

[0096] A32. The method of scheme A31, wherein the transmission 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 a data forwarding tunnel between the target network node and the network node if it is determined that the additional identifier of the target network node and the network node are the same; and perform data forwarding to achieve lossless handover of the 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 for indicating that all core networks use a common implementation of multicast reception, all core networks including the first core network and the second core network.

[0097] A33. A device for wireless communication, including a processor configured to implement one or more of the methods described in schemes A1 to A32.

[0098] A34. A non-transitory computer-readable program storage medium having code stored thereon, which, when executed by a processor, causes the processor to perform one or more of the methods described in schemes A1 to A32.

[0099] The described features can be implemented to further provide one or more of the following technical solutions: B1. In the RAN sharing scenario, the core network sends some related information about multicast reception to the gNB, and receives information about establishing an NG-U tunnel from the gNB in ​​the RAN sharing scenario.

[0100] B2. The associated information includes the MBS associated session ID, which can be used to identify MBS sessions with the same content from different PLMNs, and can be carried in the PDU session resource establishment request message / PDU session resource modification request message / distribution establishment response message.

[0101] B3. The gNB sends an indication to the core network regarding whether to establish an NG-U tunnel. This indication can be carried in an NGAP distribution establishment request message or in a new NGAP signaling procedure, such as an NGAP distribution modification procedure. Based on this indication, the core network establishes the NG-U tunnel.

[0102] B4. In shared scenarios, some related information regarding RAN multicast reception can be sent from gNB-CU-CP to gNB-CU-UP. This related information includes an indication of whether to establish an NG-U tunnel and / or the session ID associated with the MBS. This related information is added to the MC bearer context establishment request message. Based on the indication of whether to establish an NG-U tunnel, gNB CU-UP allocates resources for the shared NGAP tunnel and carries the corresponding NG-RAN TNL information in the MC bearer context establishment response message. Based on the session ID associated with the MBS, gNB CU-UP determines whether to allocate resources for the shared NGAP tunnel and carries the corresponding NG-RAN TNL information in the MC bearer context establishment response message.

[0103] B5. Add the session ID associated with the MBS to the F1AP multicast context establishment request message / F1AP UE context establishment request message / F1AP UE context modification request message. In the example, the same F1-U tunnel information at the gNB DU is carried for these multicast sessions via the F1AP multicast distribution establishment request message / F1AP UE context modification request message. In another example, the same F1-U tunnel information at the gNB CU is carried for these multicast sessions via the F1AP multicast distribution establishment response message / F1AP UE context modification response message.

[0104] B6. During the F1AP multicast distribution establishment / F1AP UE context modification request message process, F1-U tunnel information is carried for the first session. For other multicast sessions that belong to the same service as the first session at the application layer, no F1-U tunnel information is provided during the F1AP multicast distribution establishment process / F1AP UE context modification response.

[0105] B7. The gNB-CU sends the MBS associated session ID and its own cell ID to the gNB-DU via an F1AP multicast context establishment request message, an F1AP UE context establishment request message, or an F1AP UE context modification request message. If multiple cell IDs exist for the same MBS associated session, the gNB-DU establishes multiple F1-U tunnels. The F1AP multicast distribution establishment response message carries the F1-U tunnel information at the gNB-DU for these multicast sessions. Furthermore, the E1AP MC bearer context modification response message carries the F1-U tunnel information at the gNB-DU for these multicast sessions.

[0106] B8. The E1AP MC bearer context release command message carries an indication not to release the corresponding NG-U tunnel resource (or corresponding F1-U tunnel resource) at NG-RAN. To confirm the reservation of NG-U tunnel resources (or F1-U tunnel resources) in NG-RAN, the E1AP MC bearer context release completion message carries an indication regarding the reservation of NG-U tunnels.

[0107] B9 and gNB send an NGAP distribution modification request message to request the core network to establish a new NG-U tunnel for the multicast session in the RAN shared scenario (the request message includes the session ID, NG-U tunnel information at the NG-RAN, and instructions regarding NG-U tunnel establishment). The core network will allocate NG-U tunnel resources for the session and include this information in the NGAP distribution modification response message.

[0108] B10. The F1AP multicast context release command message carries an indication not to release the corresponding F1-U tunnel resource at NG-RAN. To confirm the reservation of F1-U tunnel resources in NG-RAN, the F1AP multicast context release completion message carries an indication regarding the reservation of F1-U tunnels.

[0109] B11. Establish a request message bearing a globally unique UPF ID through PDU session resources. If multiple core networks deliver data from multiple UPFs for the same multicast service in the same shared gNB, then establish separate NG-U and F1-U tunnels for each UPF.

[0110] B12. If the gNB CU-UP decides to establish an NG-U tunnel, it uses the E1AP MC bearer context establishment request message to carry the session ID associated with the MBS and the corresponding UPF ID. The PDU session resource establishment request message carries an indication of this information. If the core network instructs all operators to use the same DL MBS QFI sequence number and MBS QoS flow implementation, the gNB will only establish a shared NG-U tunnel for these multicast sessions that provide the same service at the application layer.

[0111] B13. The handover request message carries the ID associated with the MBS and the MBS session ID. Based on this indication, the target gNB can check whether an NG-U tunnel and an F1-U tunnel have been established for this session.

[0112] B14. The handover request message carries the UPF ID, the session ID associated with the MBS, and the MBS session ID. If the UPF ID carried by 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 the target gNB and perform data forwarding to achieve lossless handover.

[0113] B15. The handover request message carries the PLMN ID, the session ID associated with the MBS, and the MBS session ID. 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 the target gNB and perform data forwarding to achieve lossless handover.

[0114] B16. The handover request message carries an indication that all operators use the same implementation for this session, along with the session ID associated with the MBS and the MBS session ID. Based on this indication, the target gNB will establish a data forwarding tunnel between the source gNB and the target gNB, and perform data forwarding to achieve a lossless handover.

[0115] Figure 3 A block diagram of an example hardware platform 300, which may be part of a network device (e.g., a base station) or a communication device (e.g., a user equipment (UE)), is shown. The hardware platform 300 includes at least one processor 310 and a memory 305 storing instructions thereon. When executed by the processor 310, the instructions configure the hardware platform 300 to perform the various embodiments described in this patent document. Figure 1 and Figure 2 The operation described above. 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. 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.

[0116] The implementation methods discussed above will be applied to wireless communication. Figure 4 An example of a wireless communication system (e.g., a 5G or NR cellular network) including a base station 420 and one or more user equipments (UEs) 411, 412, and 413 is shown. In some embodiments, the UE accesses the BS (e.g., the network) using a communication link to the network (sometimes referred to as the uplink direction, as shown by dashed arrows 431, 432, and 433), which then enables subsequent communication from the BS to the UE (e.g., the direction from the network to the UE, sometimes referred to as the downlink direction, as shown by arrows 441, 442, and 443). In some embodiments, the BS sends information to the UE (sometimes referred to as the downlink direction, as shown by arrows 441, 442, and 443), which then enables subsequent communication from the UE to the BS (e.g., the direction from the UE to the BS, sometimes referred to as the uplink direction, as shown by dashed arrows 431, 432, and 433). The UE can be, for example, a smartphone, tablet, mobile computer, machine-to-machine (M2M) device, Internet of Things (IoT) device, etc.

[0117] Some embodiments described herein are described in the general context of methods or processes that 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, that are executed by a computer in a networked environment. Computer-readable media may include removable and non-removable storage devices, including but not limited to read-only memory (ROM), random access memory (RAM), optical disc (CD), digital versatile optical disc (DVD), etc. Therefore, computer-readable media may include non-transitory storage media. Typically, program modules may include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. Computer-executable or processor-executable instructions, associated data structures, and program modules represent examples of program code for performing steps of the methods disclosed herein. A particular sequence of such executable instructions or associated data structures represents examples of corresponding actions for implementing the functionality described in such steps or processes.

[0118] Some disclosed embodiments may be implemented as devices or modules using hardware circuitry, software, or a combination thereof. For example, hardware circuitry implementations may include discrete analog and / or digital components integrated, for example, as part of a printed circuit board. Alternatively or additionally, the disclosed components or modules may be implemented as application-specific integrated circuits (ASICs) and / or field-programmable gate arrays (FPGAs). Some implementations may additionally or alternatively include digital signal processors (DSPs) as dedicated microprocessors, whose architecture is optimized for the operational requirements of digital signal processing associated with the disclosed functions of this application. Similarly, the various components or sub-components within each module may be implemented using software, hardware, or firmware. Interconnections between modules and / or between components within a module may be provided using any connection methods and media known in the art, including but not limited to communication via the Internet, wired, or wireless networks using appropriate protocols.

[0119] While this document contains numerous details, these details should not be construed as limiting the scope of the claimed invention or any possible claims, but rather as descriptions of features specific to particular embodiments. Certain features described herein in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, while features may be described above as functioning in a particular combination and even initially claimed in this way, in some cases one or more features of the claimed combination may be removed from the combination, and the claimed combination may involve sub-combinations or variations thereof. Similarly, while operations are depicted in a specific order in the figures, this should not be construed as requiring such operations to be performed in the specific or sequential order shown, or that all shown operations must be performed to achieve the desired result.

[0120] Only a few implementations and examples have been described, and other implementations, enhancements and modifications can be made based on the content described and illustrated in this disclosure.

Claims

1. A wireless communication method, comprising: The first core network transmits first information to network nodes, the first information being associated with the multicast reception of the network nodes, and Receive second information from the network node, the second information being associated with establishing a transmission tunnel for multicast reception. Each of the first core network and the second core network is configured to share one or more radio access network resources, the radio access network resources including the network nodes.

2. A wireless communication method, comprising: A network node receives first information from a first core network, the first information being associated with the network node's multicast reception, and The second information is transmitted to the first core network. This second information is associated with establishing a transmission tunnel for multicast reception. Each of the first core network and the second core network is configured to share one or more radio access network resources, the radio access network resources including the network nodes.

3. The method as described in claim 1 or 2, wherein, The first core network is a 5G core network, wherein the network node is a gNodeB, and wherein the transmission tunnel is an NG-U tunnel.

4. The method of claim 3, wherein, The first information includes a session identifier of a multicast broadcast service (MBS) session associated with the multicast reception, wherein the session identifier is used to identify MBS sessions with the same content from different public land mobile networks (PLMNs).

5. The method of claim 4, wherein, The first information is carried by a Protocol Data Unit (PDU) session resource establishment request message, a PDU session resource modification request message, or a dispatch establishment response message.

6. The method of claim 3, wherein, The network node is configured to transmit an indication to the first core network indicating whether to establish the transmission tunnel.

7. The method of claim 6, wherein, The instruction is carried by a setup request message distributed via the NG Application Protocol (NGAP).

8. The method of claim 6, wherein, Based on the NGAP distribution modification process, the resources associated with the transport tunnel used for multicast reception are modified, wherein the indication is carried by an NGAP distribution modification request message.

9. The method according to any one of claims 6 to 8, wherein, The first core network is configured to establish the transmission tunnel based on the instruction.

10. The method of claim 4, wherein, The first information is sent from the control plane of the network node to the user plane of the network node.

11. The method of claim 10, wherein, The first information includes an indication of whether to establish the transmission tunnel and / or the session identifier.

12. The method of claim 11, wherein, The request message is established through the MC bearer context or the request message is modified to carry the first information through the MC bearer context.

13. The method of claim 11, wherein, The user plane is configured to allocate resources for a shared transport tunnel based on the indication or the session identifier, and wherein 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 the NG-RAN NG-U transport network layer TNL information carried by the MC bearer context to establish a response message or modify the response message through the MC bearer context.

15. The method according to any one of claims 10 to 14, wherein, The control plane includes gNB-CU-control plane gNB-CU-CP, and the user plane includes gNB-CU-user plane gNB-CU-UP.

16. The method of claim 3, wherein, The second information is carried by a NGAP distribution modification request message, wherein the first core network is configured to transmit information related to the resources in an NGAP distribution modification response message when resources are allocated for the transport tunnel.

17. The method as claimed in claim 1 or 2, wherein, The first core network is a 5G core network, wherein the network node is a gNodeB, wherein the transmission tunnel is an F1-U tunnel, wherein the session identifier of the multicast broadcast service MBS session is associated with the multicast reception, and wherein the session identifier is used to identify MBS sessions with the same content from different public terrestrial mobile networks (PLMNs).

18. The method of claim 17, wherein, The session identifier is carried by an F1AP multicast context establishment request message, an F1AP UE context establishment 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 used for MBS sessions from different PLMNs, wherein an establishment procedure message or an F1AP UE context modification request message is distributed via F1AP multicast to carry information associated with the transport tunnel used only for the first session in the MBS session.

20. The method of claim 17, wherein, The session identifier and the identifier of the network node are sent from the centralized unit (CU) of the network node to the distributed unit (DU) of the network node via an F1AP multicast context establishment request message.

21. The method of claim 17, wherein, The session identifier is associated with multiple cell identifiers, wherein the distributed unit (DU) of the network node is configured to establish multiple transmission tunnels, and each of the multiple transmission tunnels is associated with a corresponding cell identifier among the multiple cell identifiers.

22. The method of claim 17, wherein, The F1AP multicast context release command message bearer indicates an instruction to avoid releasing the transport tunnel, and wherein the F1AP multicast context release completion message bearer indicates an instruction to reserve resources for the transport tunnel.

23. The method of claim 3 or 17, wherein, The E1AP MC bearer context release command message carries an indication to avoid releasing the transport tunnel.

24. The method of claim 3 or 17, wherein, The E1AP MC bearer context release completes the message bearer's indication of reserving resources for the transport tunnel.

25. The method of claim 4 or 17, wherein, Multiple core networks transmit data from multiple User Plane Functions (UPFs) to the network nodes receiving multicast data, wherein a globally unique UPF identifier is carried by a Protocol Data Unit (PDU) Session Resource Establishment Request message, and wherein a transmission tunnel is established for each of the multiple UPFs.

26. The method of claim 25, wherein, The transmission tunnel is an NG-U tunnel, in which the session identifier and the corresponding UPF identifier are carried by the E1AP MC bearer context establishment request message.

27. The method of claim 26, wherein, The PDU session resource establishment request message or the NG application protocol NGAP distribution establishment response message carries an indication for establishing the transmission tunnel for the corresponding UPF identifier.

28. The method of claim 3 or 17, wherein, For the operator associated with the indication, the indication being set to "1" indicates that the operator uses a common implementation of multicast reception, and the indication being set to "0" indicates that the operator uses a differentiated implementation of multicast reception.

29. The method of claim 28, wherein, All operators associated with the instruction set to "1" are configured to establish a shared tunnel.

30. The method of claim 28, wherein, Each operator associated with an indication set to "0" is configured to establish a separate transport tunnel.

31. The method of claim 4 or 17, wherein, The switch request message carries the session identifier and MBS session ID, wherein the target network node is configured to determine whether the transport tunnel has been established based on the session identifier and the MBS session ID.

32. The method of claim 31, wherein, The transmission tunnel is an NG-U tunnel, wherein the handover request message further includes an additional identifier associated with the NG-U tunnel, and the target network node is configured as follows: If the target network node and the network node's additional identifier are determined to be the same, a data forwarding tunnel is established between the target network node and the network node; and Perform data forwarding to enable lossless handover of the wireless device from the network node to the target network node, and The additional identifier is a User Plane Function (UPF) identifier, a Public Land Mobile Network (PLMN) identifier, or an indication that all core networks use a common implementation of multicast reception, including the first core network and the second core network.

33. An apparatus for wireless communication, comprising a processor configured to implement the method as described in one or more of claims 1 to 32.

34. A non-transitory computer-readable program storage medium having code stored thereon, which, when executed by a processor, causes the processor to perform the method as described in one or more of claims 1 to 32.

Images