Activation and deactivation of multicast broadcast service sessions in wireless networks

Abstract

Techniques related to multicast broadcast services are described. In one example aspect, a method includes receiving, by a first network node from a second network node, third information, and transmitting, by the first network node, fourth information associated with one or more multicast broadcast service (MBS) sessions.

Description

Technical Field

[0001] This patent document is generally concerned with wireless communication. Background Technology

[0002] Mobile communication technology is propelling the world towards an increasingly interconnected and networked society. The rapid growth and technological advancements in mobile communications have led to greater demands for capacity and connectivity. Other factors, such as energy consumption, equipment cost, spectrum efficiency, and latency, are also important for meeting the needs of various communication scenarios. Various technologies are currently under discussion, including new methods to provide higher service quality, longer battery life, and improved performance. Summary of the Invention

[0003] In one aspect, a method for data communication is disclosed. The method includes a first network node receiving first information from a second network node, and the first network node transmitting second information associated with one or more multicast broadcast service (MBS) sessions.

[0004] In another aspect, a method for data communication is disclosed. This method includes a first network node receiving third information from a second network node, and the first network node transmitting fourth information associated with one or more multicast broadcast service (MBS) sessions.

[0005] In another example, a wireless communication device is disclosed, including a processor configured to implement the methods described above.

[0006] In another example, a computer storage medium is disclosed that stores code for implementing the methods described above.

[0007] This document describes these and other aspects. Attached Figure Description

[0008] Figure 1 A wireless communication system based on some example embodiments of the disclosed technology is shown.

[0009] Figure 2 A block diagram of a portion of a radio system based on some example embodiments of the disclosed technology is shown.

[0010] Figure 3 An example of the format of a Medium Access Control (MAC) control element CE is shown.

[0011] Figure 4 Examples of processes for wireless communication based on some exemplary embodiments of the disclosed technology are shown.

[0012] Figure 5 Another example of a process for wireless communication based on some example embodiments of the disclosed technology is shown. Detailed Implementation

[0013] Examples of fifth-generation (5G) wireless protocols are used to describe certain characteristics. However, the applicability of the disclosed technologies is not limited to 5G wireless systems.

[0014] 5G systems (5G) include multicast / broadcast services. One aspect of these services is multicast discovery, as well as the initiation and termination of multicast services. User equipment (UE) can operate simultaneously using unicast (also known as unicast) and multicast services. When a UE moves from one radio access network (RAN) node to another RAN node, service continuity for both broadcast and multicast services is required. This document discloses techniques for providing service continuity for both broadcast and multicast services.

[0015] In some example embodiments, multicast service is a communication service in which the same service and the same content data are simultaneously provided to a group of authorized UEs (i.e., not all UEs within the multicast coverage area are authorized to receive the data). Broadcast service is a communication service in which the same service and the same content data are simultaneously provided to all UEs in a geographic area (i.e., all UEs within the broadcast coverage area are authorized to receive the data).

[0016] Figure 1 An example of a wireless communication system 100 is shown, in which techniques according to one or more embodiments of the present invention can be applied. The wireless communication system 100 can include one or more base stations (BS) 105a, 105b, one or more wireless devices 110a, 110b, 110c, 110d, and a core network 125. Base stations 105a, 105b can provide wireless services to wireless devices 110a, 110b, 110c, and 110d in one or more wireless sectors. In some embodiments, base stations 105a, 105b include directional antennas to generate two or more directional beams to provide wireless coverage in different sectors.

[0017] The core network 125 is capable of communicating with one or more base stations 105a, 105b. The core network 125 provides connectivity with other wireless communication systems and wired communication systems. The core network may include one or more service subscription databases for storing information related to subscribed wireless devices 110a, 110b, 110c, and 110d. The first base station 105a is capable of providing wireless services based on a first wireless access technology, while the second base station 105b is capable of providing wireless services based on a second wireless access technology. Base stations 105a and 105b may be located in the same location or may be installed separately in the field depending on the deployment scenario. Wireless devices 110a, 110b, 110c, and 110d are capable of supporting multiple different wireless access technologies. The technologies and embodiments described in this document can be implemented by base stations of the wireless devices described in this document.

[0018] Figure 2 This is a block diagram representation of a portion of a wireless station applicable according to one or more embodiments of the present technology. Wireless station 205, such as a base station or wireless device (or UE), may include processor electronics 210, such as a microprocessor implementing one or more wireless technologies proposed in this document. Wireless station 205 may include transceiver electronics 215 for transmitting and / or receiving wireless signals via one or more communication interfaces, such as antenna 220. Wireless station 205 may include other communication interfaces for transmitting and receiving data. Wireless station 205 may include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some embodiments, processor electronics 210 may include at least a portion of transceiver electronics 215. In some embodiments, wireless station 205 is used to implement at least some of the disclosed technologies, modules, or functions. In some embodiments, wireless station 205 may be configured to perform the methods described in this document. The network node described in this application may be implemented using the aforementioned wireless station or by using a hardware platform comprising a combination of one or more processors, one or more network interface hardware, and one or more memories for storing processor-executable code or data.

[0019] With the continuous development of 5G (fifth-generation mobile network, fifth-generation mobile communication technology), 5G solutions for various application scenarios are rapidly converging. Multicast broadcast service scenarios are traditional service scenarios designed to meet the needs of most users for the same service. Currently, the 5G-related technologies discussed and standardized in the industry mainly concern unicast service scenarios, namely the PTP (point-to-point) service mode. With the rapid growth in the number of users and the diversification of application scenarios, point-to-multipoint service models, such as multicast broadcast service (MBS), will become one of the most important service modes. In multicast broadcast scenarios, base stations will deactivate or activate some MBS services based on service priority, resource utilization, and user nodes. However, for base stations, especially those with CU (centralized unit, centralized network element) / DU (distributed unit, distributed network element) separation and CP (control plane, control plane) / UP (user plane) separation, how to activate and deactivate MBS services has not yet been discussed.

[0020] In this patent document, the terms "deactivate or suspend instruction," "deactivate instruction," and "suspend instruction" can be used to indicate any message or information indicating that an MBS session is "deactivated" or "suspended." Similarly, the term "activation instruction" can be used to indicate any message or information indicating that an MBS session is "activated" or "resumed."

[0021] In some embodiments of the disclosed technology, the MBS session is deactivated because no downlink (DL) data arrives at the CU-UP for an extended period of time.

[0022] Step 0: The CU-UP is configured with an inactive timer. At the CU-UP, all MBS sessions use the same inactive timer configuration. In one implementation, the inactive timer configuration is performed per MBS session. In another implementation, the CU-CP receives several sets of inactive timer configurations. In yet another implementation, the CU-CP receives one or more MBS session identifiers for each set of inactive timer configurations.

[0023] In another implementation, the inactive timer can be configured by the CU-CP. The CU-CP sends the configuration to the CU-UP via an E1AP (E1 Application Protocol) message.

[0024] In another implementation, the inactive timer is configured by 5GC. In one example, 5GC sends the configuration to CU-CP via NGAP (NG Application Protocol) message, and CU-CP forwards the configuration to CU-UP via E1AP message.

[0025] Step 1: When an inactive timer is detected to have expired, the CU-UP sends its MBS session information to the CU-CP, such as the MBS session ID or Protocol Data Unit (PDU) session ID, or an indication of the expiration of an inactive timer associated with the MBS session.

[0026] Step 2: When the inactive timer expires as received from CU-UP, CU-CP determines whether to disable the MBS session.

[0027] Step 3: If the MBS session is not disabled, the CU-CP can send the following information to the CU-UP via E1AP message:

[0028] In one implementation, the CU-CP can send an indication to the CU-UP that the MBS session has not been disabled. The CU-UP can then ignore expired inactive timers or restart inactive timers.

[0029] In another implementation, the CU-CP can send an indication to request the CU-UP to ignore expired inactive timers.

[0030] In another implementation, the CU-CP can send an instruction to request the CU-UP to restart an expired inactive timer.

[0031] In another implementation, the CU-CP can send information about when to deactivate the MBS session, for example, after a few seconds, the MBS session should be deactivated.

[0032] Step 4: If the MBS session is deactivated, the CU-CP can retain the F1 UL TEID or F1 DL TEID or F1 UL transport layer address or F1 DL transport layer address.

[0033] Step 4-1: The CU-CP can send the identifier of the MBS session to be deactivated to the CU-UP, such as the MBS session ID, PDU session ID, or Temporary Mobile Group Identifier (TMGI), along with a deactivation instruction used to notify the CU-UP of the MBS session deactivation. The CU-UP sends a message to the CU-CP that includes, for example, the PDCP DL status required for data volume reporting. The CU-UP maintains the Multicast Resource Bearer (MRB) context, logical E1 connection, and NG-U-related resources (e.g., NG-U DL TEID). The CU-UP may maintain the F1 UL TEID, F1 DL TEID, F1 UL transport layer address, or F1 DL transport layer address.

[0034] Step 4-2: CU-CP can send the following information to DU:

[0035] In one implementation, the CU-CP can send an identifier of the MBS session to be deactivated, such as TMGI.

[0036] In another implementation, the CU-CP can send a deactivation or suspension instruction for the MBS session.

[0037] In another implementation, the CU-CP can send the identifier of the MRB associated with the MBS session to be deactivated.

[0038] In another implementation, the CU-CP can send a deactivation or suspension instruction for the MRB.

[0039] In another implementation, the CP can send an RRC container containing an RRC message. The RRC message may include the following information:

[0040] In another implementation, the RRC message may include an identifier of the MBS session to be deactivated, such as TMGI.

[0041] In another implementation, the RRC message may include a deactivation or suspension indication for the MBS session.

[0042] In another implementation, the RRC message may include an identifier of the MRB associated with the MBS session to be deactivated.

[0043] In another implementation, the RRC message may include a deactivation or suspension indication of the MRB.

[0044] In another implementation, the CU-CP can send an instruction to the DU, which is used to instruct the DU to maintain the context and configuration associated with the MBS session to be deactivated.

[0045] Step 4-2-1: DU can maintain all context or configuration related to the MBS session or MBS bearer, such as TMGI, MRB ID, MRB QoS information, QoS flow parameters, RLC mode, optional group membership information (including UE ID, or index, or RNTI), LCID, and F1 UL / DL UP TNL information.

[0046] In some implementations, the DU can generate a Media Access Control Layer Control Element (MAC CE) to notify the UE of disabled logical channels. In another implementation, the DU can send a disabled MBS session identifier, such as a TMGI or a deactivation indication, via a System Information Block (SIB) or MCCH. If an RRC container is received from the CU, the DU should send the RRC container to the UE.

[0047] Step 4-2-2: When the MBS session or MRB is known to be deactivated, DU can completely release the context associated with the MBS session or MRB based on the implementation method.

[0048] In another implementation, the DU can release the context associated with the MBS session or MRB, in addition to TMGI, MRB ID, MRB QoS information, QoS flow parameters, RLC mode, optional group membership information (including UE ID, or index, or RNTI), LCID, and F1 UL UP TNL information.

[0049] In another implementation, DU can release only the UM mode RLC entity for the MRB to be deactivated. This is because the UM RLC entity is only used for DL ​​MBS data transmission.

[0050] In another implementation, DU may release only the logical channel corresponding to the PTM transmission.

[0051] If an RRC container is received from the CU, the DU should send the RRC container to the UE.

[0052] In some implementations, steps 4-1 and 4-2 can be performed in parallel.

[0053] Step 4-3: When the UE knows that the MBS session or MRB is deactivated, it may not monitor the MBS session identifier. In one implementation, the UE may cancel all pending SRs that are only related to the MBS session, or cancel all BSRs triggered that are only related to the MBS session, or release the RLC entity related to the MBS session or MRB.

[0054] In another implementation, the UE can release the UM mode RLC entity for the MRB to be deactivated.

[0055] In another implementation, the UE can release the logical channel corresponding to the PTM transmission.

[0056] In another implementation, the UE can suspend the PDCP. Alternatively, the PDCP entity can be delayed and suspended until all UL packets are received.

[0057] In another implementation, the UE can indicate a PDCP suspension to the lower layer of the relevant MRB, or indicate a MBS session suspension to the upper layer.

[0058] Step 4-4: CU-CP sends the 5GC information discussed below.

[0059] In one implementation, the CU-CP sends the identifier of the MBS session to be deactivated to the 5GC, such as the MBS session ID, PDU session ID, or TMGI.

[0060] In another implementation, the CU-CP sends a 5GC deactivation indication, which may be associated with an MBS session to be deactivated.

[0061] In another implementation, the CU-CP sends a reason to the 5GC reflecting the reason for disabling the MBS session, such as an inactivity timer expiring.

[0062] In some embodiments of the disclosed technology, the MBS session can be activated when DL data arrives at the CU-UP.

[0063] Step 1: Upon detecting the arrival of DL data, CU-UP sends the MBS session ID or PDU session ID, or information about the arrival of DL data, to CU-CP.

[0064] Step 2: Upon receiving a data arrival indication from CU-UP, CU-CP determines to activate the MBS session.

[0065] Step 3: The CU-CP sends information to the DU about the MBS session to be activated:

[0066] In one implementation, the information includes an MBS session identifier, such as TMGI.

[0067] In another implementation, the information includes an activation indication of the MBS session.

[0068] In another implementation, the information includes the identifier of the MRB associated with the MBS session to be activated.

[0069] In another implementation, the information includes an activation indication of the MRB.

[0070] In another implementation, the information includes the MRB's UL TNL or UL TEID information.

[0071] In some implementations, the CP may send an RRC container containing an RRC message to the DU. This RRC message may include the following:

[0072] In one implementation, the RRC message includes an identifier of the MBS session to be activated, such as TMGI.

[0073] In another implementation, the RRC message includes an activation indication for the MBS session.

[0074] In another implementation, the RRC message includes an identifier of the MRB associated with the MBS session to be activated.

[0075] In another implementation, the RRC message includes an activation indication of the MRB.

[0076] Step 3-1: The DU can generate a MAC CE to notify the UE of the activated logical channel, where the MAC CE includes the LCID of the activated LCH. Alternatively, it can only generate a MAC CE to notify the UE of deactivated logical channels. Upon receiving such a MAC CE, the UE can know that the deactivated LCH has now been reactivated because the LCID of the reactivated LCH is not included in the MAC CE. In another implementation, the DU can broadcast activated MBS session information, such as TMGI, via the System Information Block (SIB) / MCCH. If an RRC container is received from the CU, the DU sends the RRC container to the UE.

[0077] If the lower-level configuration is modified, the DU will send the modified configuration to the CU-CP.

[0078] Step 3-2: DU can create the following content.

[0079] In another implementation, a new MRB is created based on the stored configuration.

[0080] In another implementation, a UM-mode Radio Link Control (RLC) entity is established for the MRB to be activated, and the CU-CP is responded to with an LCID, F1-U DL TEID, or TNL address.

[0081] In another implementation, a logical channel corresponding to PTM mode transmission is established, and CU-CP is responded to with LCID.

[0082] Step 4: gNB-CU-CP sends a message to CU-UP, which includes the identifier of the MBS session to be activated, such as MBS session ID, PDU session ID, or TMGI, or an activation instruction to notify CU-UP to activate the MBS session, or DL ​​TNL information of one or more related MRBs.

[0083] Step 5: When the UE knows that an active MBS session is active, it can resume monitoring TMGI, apply DRX, or monitor MCCH or SIB. The UE can either resume the relevant MRB or indicate to the upper layer that the suspended MBS session has been resumed.

[0084] Step 6: CU-CP sends the following information to 5GC.

[0085] In one implementation, the MBS session identifier of the MBS session to be activated.

[0086] In another implementation, the MBS session activation indication.

[0087] In some embodiments of the disclosed technology, MBS sessions are deactivated because no DL data arrives at CU-UP for an extended period of time, where CU-UP determines whether to deactivate one or more MBS sessions.

[0088] Step 0: The CU-UP is configured with an inactive timer. At the CU-UP, all MBS sessions use the same inactive timer configuration. In another implementation, different MBS sessions may have different inactive timer configurations. In another implementation, the CU-CP receives several sets of inactive timer configurations. In yet another implementation, the CU-CP receives one or more MBS session identifiers for each set of inactive timer configurations.

[0089] In one implementation, the inactive timer can be configured by the CU-CP. In one example, the CU-CP sends the configuration to the CU-UP via an E1AP message.

[0090] In another implementation, the inactive timer is configured by the 5GC. In one example, the 5GC sends the configuration to the CU-CP via an NGAP message, and the CU-CP forwards the configuration to the CU-UP via an E1AP message.

[0091] Step 1: Upon detecting the expiration of an inactivity timer, the CU-UP determines to disable one or more MBS sessions. It then sends the identifier of the MBS session to be disabled to the CU-CP, such as the MBS session ID, PDU session ID, or TMGI, along with an indication of the inactivity timer's expiration or a disable indication, which is used to notify the CU-CP to disable the MBS session. The CU-UP sends a message to the CU-CP including, for example, the PDCP DL status required for volume reporting. The CU-UP maintains the MRB context, logical E1 connection, and NG-U related resources (e.g., NG-U DL TEID). The CU-UP may also maintain the F1 UL TEID, F1DL TEID, F1UL transport layer address, or F1 DL transport layer address.

[0092] Step 2: When a message is received from CU-UP, CU-CP can retain the F1 UL TEID or F1 DL TEID or F1 UL transport layer address or F1 DL transport layer address.

[0093] Step 3: The CU-CP can send the following information to the DU: the identifier of the MBS session to be deactivated, for example, TMGI; the deactivation or suspension indication of the MBS session; the identifier of the MRB associated with the MBS session to be deactivated; the deactivation or suspension indication of the MRB; and the RRC container containing the RRC message.

[0094] RRC messages can include the following information:

[0095] In one implementation, the RRC message may include an identifier of the MBS session to be deactivated, such as TMGI.

[0096] In another implementation, the RRC message may include a deactivation or suspension indication for the MBS session.

[0097] In another implementation, the RRC message may include an identifier of the MRB associated with the MBS session to be deactivated.

[0098] In another implementation, the RRC message may include a deactivation or suspension indication of the MRB.

[0099] In some implementations, the CU-CP can send an indication to the DU, which is used by the DU to maintain the context and configuration associated with the MBS session to be deactivated.

[0100] Step 3-1: DU can maintain all context and configuration related to MBS session / MBS bearer, such as TMGI, MRB ID, MRB QoS information, QoS flow parameters, RLC mode, optional group membership information (including UE ID, or index, or RNTI), LCID and F1 UL / DL UP TNL information.

[0101] The DU can generate a MAC CE to notify the UE of deactivated logical channels. The DU can broadcast deactivated MBS session information, such as TMGI, via System Information Block (SIB) or MCCH. If an RRC container is received from the CU, the DU will send the RRC container to the UE.

[0102] Step 3-2: When the MBS session or MRB is known to be deactivated, the DU can release the following content.

[0103] In one implementation, DU can completely release the context associated with the MBS session or MRB.

[0104] In another implementation, the DU can release the context associated with the MBS session or MRB, in addition to TMGI, MRB ID, MRB QoS information, QoS flow parameters, RLC mode, optional group membership information (including UE ID, or index, or RNTI), LCID, and F1 UL UP TNL information.

[0105] In another implementation, DU can release only the UM mode RLC entity for the MRB to be deactivated. This is because the UM RLC entity is only used for DL ​​MBS data transmission.

[0106] In another implementation, DU may release only the logical channel corresponding to the PTM transmission.

[0107] If an RRC container is received from the CU, the DU will send the RRC container to the UE.

[0108] Step 4: When the UE knows that the MBS session or MRB is deactivated, it can choose not to monitor the MBS session identifier and can perform the following operations.

[0109] In one implementation, the UE can cancel all pending SRs that are only related to the MBS session, or cancel all BSRs triggered that are only related to the MBS session, delete the MAC cell group configuration, or release the RLC entity related to the MBS session or MRB.

[0110] In another implementation, the UE can release the UM mode RLC entity for the MRB to be deactivated.

[0111] In another implementation, the UE can release the logical channel corresponding to the PTM transmission.

[0112] In another implementation, the UE can suspend the PDCP. Alternatively, the PDCP entity may be delayed or suspended until all UL packets are received.

[0113] In another implementation, the UE may indicate to the lower layer of the relevant MRB that the PDCP is suspended, or indicate to the upper layer that the MBS session is suspended.

[0114] Step 5: CU-CP sends the following information to 5GC.

[0115] In one implementation, the CU-CP sends an identifier of the MBS session to be deactivated, such as the MBS session ID, PDU session ID, or TMGI.

[0116] In another implementation, the CU-CP sends a deactivation instruction, which may be associated with the MBS session to be deactivated.

[0117] In another implementation, the CU-CP sends a reason reflecting why the MBS session is deactivated, such as an inactivity timer expiring.

[0118] In some embodiments of the disclosed technology, the MBS session can be activated when DL data arrives at the CU-UP, where the CU-UP determines the activation of the MBS session.

[0119] Step 1: Upon detecting the arrival of DL data, CU-UP sends a message to CU-CP. This message includes the identifier of the MBS session to be activated, such as the MBS session ID, PDU session ID, or TMGI, or an indication of the arrival of DL data, or an activation indication used to notify CU-CP of the MBS session activation.

[0120] Step 2: Upon receiving a message from CU-UP, CU-CP sends information to DU about the MBS session to be activated.

[0121] In one implementation, the information includes an MBS session identifier, such as TMGI.

[0122] In another implementation, the information includes an activation indication of the MBS session.

[0123] In another implementation, the information includes the MRB identifier.

[0124] In another implementation, the information includes an activation indication of the MRB.

[0125] In another implementation, the information includes the UL TNL / TEID information of the relevant MRB.

[0126] In some implementations, the CP can send an RRC container containing RRC messages to the DU.

[0127] In one implementation, the RRC message may include an identifier of the MBS session to be activated, such as TMGI.

[0128] In another implementation, the RRC message may include an activation indication of the MBS session.

[0129] In another implementation, the RRC message may include an identifier of the MRB associated with the MBS session to be activated.

[0130] In another implementation, the RRC message may include an activation indication of the MRB.

[0131] Step 3-1: The DU can generate a MAC CE to notify the UE of the activated logical channel, where the MAC CE includes the LCID of the activated LCH. Alternatively, it can remove the LCID of a deactivated LCH from the MAC CE, where the MAC CE includes the LCID of the deactivated LCH, and thus the UE can identify the reactivated LCH. In another implementation, the DU can broadcast the activated MBS session, e.g., TMGI, via the System Information Block (SIB) / MCCH. If an RRC container is received from the CU, the DU should send the RRC container to the UE.

[0132] If the lower-level configuration is modified, the DU will send the modified configuration to the CU-CP.

[0133] Step 3-2: DU can create the following content.

[0134] In one implementation, the DU can create a new MRB based on the stored configuration.

[0135] In another implementation, the DU can create a UM mode RLC entity for the MRB to be activated and respond to the CU-CP with the LCID and F1-U DL TEID and / or TNL address.

[0136] In another implementation, the DU can establish a logical channel corresponding to the PTM (DL) and respond to the CU-CP with LCID.

[0137] Step 4: gNB-CU-CP can send a message to CU-UP including DL TNL information for the relevant MRB.

[0138] Step 5: Upon knowing that the MBS session has been reactivated, the UE can continue monitoring TMGI, applying DRX, and monitoring MCCH / SIB. The UE restores the relevant MRB and optionally indicates to the upper layer that the suspended MBS session has been restored.

[0139] Step 6: CU-CP sends the following information to 5GC.

[0140] In one implementation, the CU-CP sends the MBS session ID or the PDU session ID.

[0141] In another implementation, the CU-CP sends an activation instruction.

[0142] In some embodiments of the disclosed technology, MBS sessions can be deactivated based on CU-CP decisions (e.g., ARP or counts).

[0143] Step 1: CU-CP determines to disable one or more MBS sessions.

[0144] Step 2: The CU-CP can retain the F1 UL TEID and / or F1 DL TEID and / or F1 UL transport layer address and / or F1 DL transport layer address.

[0145] Step 3: The CU-CP can send the identifier of the MBS session to be deactivated to the CU-UP, such as the MBS session ID, PDU session ID, or TMGI, along with a deactivation instruction used to notify the CU-UP of the deactivation of the MBS session. The CU-UP sends a message to the CU-CP that includes, for example, the PDCP DL status required for data volume reporting. The CU-UP maintains the MRB context, logical E1 connection, and NG-U related resources (e.g., NG-U DL TEID). The CU-UP may maintain the F1 UL TEID and / or F1 DL TEID and / or F1 UL transport layer address and / or F1 DL transport layer address.

[0146] Step 4: CU-CP can send the following information to DU.

[0147] In one implementation, the CU-CP can send an identifier of the MBS session to be deactivated, such as TMGI.

[0148] In another implementation, the CU-CP can send a deactivation or suspension instruction for the MBS session.

[0149] In another implementation, the CU-CP can send the identifier of the MRB associated with the MBS session to be deactivated.

[0150] In another implementation, the CU-CP can send a deactivation or suspension instruction for the MRB.

[0151] In some implementations, the CP can send an RRC container containing RRC messages to the DU.

[0152] In one implementation, the RRC message may include an identifier of the MBS session to be deactivated, such as TMGI.

[0153] In one implementation, the RRC message may include a deactivation or suspension indication for the MBS session.

[0154] In one implementation, the RRC message may include an identifier of the MRB associated with the MBS session to be deactivated.

[0155] In one implementation, the RRC message may include a deactivation or suspension indication of the MRB.

[0156] In some implementations, the CU-CP can send an indication to the DU, which is used by the DU to maintain the context and configuration associated with the MBS session to be deactivated.

[0157] Step 4-1: DU can maintain all context and configuration related to MBS session / MBS bearer, such as TMGI, MRB ID, MRB QoS information, QoS flow parameters, RLC mode, optional group membership information (including UE ID, or index, or RNTI), LCID and F1 UL / DL UP TNL information.

[0158] The DU can generate a MAC CE to notify the UE of disabled logical channels. The DU can broadcast disabled MBS session information, such as TMGI, via System Information Block (SIB) or MCCH. If an RRC container is received from the CU, the DU should send the RRC container to the UE.

[0159] Step 4-2: When the MBS session or MRB is known to be deactivated, the DU can release the following content.

[0160] In one implementation, DU can completely release the context associated with the MBS session or MRB.

[0161] In another implementation, the DU can release the context associated with the MBS session or MRB, in addition to TMGI, MRB ID, MRB QoS information, QoS flow parameters, RLC mode, optional group membership information (including UE ID, or index, or RNTI), LCID, and F1 UL UP TNL information.

[0162] In another implementation, DU can release only the UM mode RLC entity for the MRB to be deactivated. This is because the UM RLC entity is only used for DL ​​MBS data transmission.

[0163] In another implementation, DU may release only the logical channel corresponding to PTM(DL).

[0164] If an RRC container is received from the CU, the DU will send the RRC container to the UE.

[0165] In some implementations, steps 3 and 4 can be performed in parallel.

[0166] Step 5: When the UE knows that the MBS session or MRB is deactivated, it can stop monitoring TMGI and perform the following operations.

[0167] In one implementation, the UE can cancel all pending SRs that are only related to the MBS session, cancel all BSRs triggered that are only related to the MBS session, delete the MAC cell group configuration, and release the RLC entity related to the MBS session or MRB.

[0168] In another implementation, the UE can release the UM mode RLC entity for the MRB to be deactivated.

[0169] In another implementation, the UE can release the logical channel corresponding to the PTM (DL).

[0170] In another implementation, the UE can suspend the PDCP. Alternatively, the PDCP entity may be delayed or suspended until all UL packets are received.

[0171] In another implementation, the UE may indicate to the lower layer of the relevant MRB that the PDCP is suspended, and optionally indicate to the upper layer that the MBS session is suspended.

[0172] Step 6: CU-CP sends the following information to 5GC.

[0173] In one implementation, the CU-CP sends the MBS session ID or the PDU session ID.

[0174] In another implementation, the CU-CP sends a deactivation indication, which may reflect the reason for deactivating the MBS session, such as ARP or count.

[0175] In some embodiments of the disclosed technology, the MBS session can be reactivated based on a CP decision (e.g., ARP or count).

[0176] Step 1: CU-CP determines whether one or more MBS sessions are active.

[0177] Step 2: The CU-CP sends information to the DU about the MBS session to be activated.

[0178] In one implementation, the information includes an MBS session identifier, such as TMGI.

[0179] In another implementation, the information includes an activation indication of the MBS session.

[0180] In another implementation, the information includes the MRB identifier.

[0181] In another implementation, the information includes an activation indication of the MRB.

[0182] In another implementation, the information includes the UL TNL / TEID information of the relevant MRB.

[0183] In some implementations, the CP can send an RRC container containing RRC messages to the DU.

[0184] In one implementation, the RRC message may include an identifier of the MBS session to be activated, such as TMGI.

[0185] In another implementation, the RRC message may include an activation indication of the MBS session.

[0186] In another implementation, the RRC message may include an identifier of the MRB associated with the MBS session to be activated.

[0187] In another implementation, the RRC message may include an activation indication of the MRB.

[0188] Step 2-1: The DU can generate a MAC CE to notify the UE of the activated logical channel, where the MAC CE includes the LCID of the activated LCH. Alternatively, it can remove the LCID of a deactivated LCH from the MAC CE, where the MAC CE includes the LCID of the deactivated LCH, and thus the UE can identify the reactivated LCH. In another implementation, the DU can broadcast the activated MBS session, e.g., TMGI, via the System Information Block (SIB) / MCCH. If an RRC container is received from the CU, the DU should send the RRC container to the UE.

[0189] If the lower-level configuration is modified, the DU will send the modified configuration to the CU-CP.

[0190] Step 2-2: DU can create the following content.

[0191] In one implementation, the DU can create a new MRB based on the stored configuration.

[0192] In another implementation, the DU can create a UM mode RLC entity for the MRB to be activated and respond to the CU-CP with the LCID and F1-U DL TEID and / or TNL address.

[0193] In another implementation, the DU can establish a logical channel corresponding to the PTM (DL) and respond to the CU-CP with LCID.

[0194] Step 3: gNB-CU-CP sends a message to CU-UP, which includes the identifier of the MBS session to be activated, such as MBS session ID, PDU session ID, or TMGI, as well as an activation instruction used to notify CU-UP to activate the MBS session, and optionally along with the DL TNL information of the relevant MRB.

[0195] Step 4: Upon knowing that the MBS session has been reactivated, the UE can continue monitoring TMGI, applying DRX, and monitoring MCCH / SIB. The UE restores the relevant MRB and optionally indicates to the upper layer that the suspended MBS session has been restored.

[0196] Step 5: CU-CP sends the following information to 5GC.

[0197] In one implementation, the CU-CP sends the MBS session ID or the PDU session ID.

[0198] In another implementation, the CU-CP sends an activation instruction.

[0199] In some embodiments of the disclosed technology, the MBS session can be deactivated or activated, wherein this determination is made by 5GC.

[0200] Discontinued

[0201] The CU-CP can send an identifier or indication of an MBS session to the 5GC. This indication may reflect the expiration of an inactive timer for the MBS session, or it may indicate that the CU-CP wants to deactivate the MBS session.

[0202] Upon receiving a message from CU-CP, 5GC determines to deactivate the MBS session. 5GC sends an MBS session identifier, such as TMGI, or a deactivation instruction for the MBS session to CU-CP.

[0203] activation

[0204] The CU-CP can send an identifier or indication of an MBS session to the 5GC. This indication reflects when the CU-CP wants to activate an MBS session.

[0205] Upon receiving a message from CU-CP, 5GC determines that the MBS session is to be activated. 5GC sends an MBS session identifier, such as TMGI, or an activation indication for the MBS session to CU-CP.

[0206] Figure 3 An example of the format of the Media Access Control (MAC) control element CE is shown.

[0207] In some implementations, the CU-CP notifies the 5GC of its capability to support MBS session deactivation. In some implementations, the DU reports to the CU-CP its capability to support MBS session deactivation. In some implementations, the DU reports to the CU-CP its capability to support deactivating multicast resource bearers (MRBs).

[0208] In some implementations, the CU-CP notifies the 5GC of its capability to support MBS session activation. In some implementations, the DU reports to the CU-CP its capability to support MBS session activation. In some implementations, the DU reports to the CU-CP its capability to support activating multicast resource bearers (MRBs).

[0209] In some implementations, the 5GC sends a list of MBS sessions that can be activated to the CU-CP. In some implementations, the 5GC sends a list of MBS sessions that can be deactivated to the CU-CP.

[0210] In some implementations, the CU-CP sends a list of MBS sessions that can be activated to the CU-UP. In some implementations, the 5GC sends a list of MBS sessions that can be deactivated to the CU-CP.

[0211] The MAC control element used to notify the UE to activate / deactivate an MBS session is identified by a MAC PDU subheader with the LCID described below. This control element has a variable size.

[0212] In some implementations, the following fields are included:

[0213] (1) LCID: This field indicates the logical channel ID. LCID x…x+y should be equal to LCID 1…n or a subset thereof;

[0214] (2)S: This field indicates that the transmission of the corresponding LCH should be disabled.

[0215] In another implementation, the S field can indicate the LCH to be activated.

[0216] Figure 4 An example method 400 for wireless communication based on some example embodiments of the disclosed technology is illustrated. At 410, the method includes receiving first information from a second network node by a first network node. At 420, the method includes transmitting second information associated with one or more multicast broadcast service (MBS) sessions by the first network node.

[0217] Figure 5Another example method 500 for wireless communication, based on some example embodiments of the disclosed technology, is illustrated. At 510, the method includes receiving third information from a second network node by a first network node. At 520, the method includes transmitting fourth information associated with one or more multicast broadcast service (MBS) sessions by the first network node.

[0218] It should be understood that this document discloses techniques that can be implemented in various embodiments to establish and manage multicast sessions in various scenarios. The disclosed and other embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or combinations thereof. The disclosed embodiments and other embodiments can be implemented as one or more computer program products, i.e., modules of one or more computer program instructions encoded on a computer-readable medium for execution by or control of the operation of a data processing apparatus. A computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a storage device, a composition of substances affecting machine-readable propagation signals, or one or more combinations thereof. The term "data processing apparatus" includes all means, devices, and machines for processing data, such as a programmable processor, a computer, or a plurality of processors or computers. In addition to hardware, the apparatus can also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof. A propagation signal is an artificially generated signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[0219] A computer program (also referred to as a program, software, software application, script, or code) can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinating files (e.g., a file storing one or more modules, subroutines, or code sections). A computer program can be deployed to execute on a single computer or on multiple computers located at a site or distributed across multiple sites and interconnected by a communication network.

[0220] The processes and logic flows described in this document can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating output. The processes and logic flows can also be executed by dedicated logic circuitry, and the devices can also be implemented using dedicated logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).

[0221] For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors in any type of digital computer. Typically, a processor receives instructions and data from read-only memory or random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include, or be operatively coupled to, receiving data from or transferring data to one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data. However, a computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM optical disks. The processor and memory may be supplemented or incorporated therein by dedicated logic circuitry.

[0222] Some embodiments may preferably implement one or more of the following solutions listed in the terms format. The following terms are supported and further described in the foregoing examples and this document. As used in the following terms and claims, a wireless terminal may be a user equipment, a mobile station, or any other wireless terminal including a fixed node such as a base station. A network node includes a base station, which includes a next-generation node B (gNB), an enhanced node B (eNB), or any other device used as a base station. A resource range may refer to a range of time-frequency resources or blocks.

[0223] Clause 1. A method of wireless communication, comprising: receiving first information from a second network node by a first network node; and transmitting second information associated with one or more multicast broadcast service (MBS) sessions by the first network node.

[0224] Clause 2, the method described in Clause 1, wherein the first information includes information associated with one or more multicast broadcast service (MBS) sessions.

[0225] Clause 3, the method described in Clause 1, wherein the second information includes a multicast broadcast service (MBS) session identifier.

[0226] Clause 4. The method according to Clause 1, wherein, upon detecting that an inactivity timer has expired, the second network node transmits to the first network node first information associated with at least one MBS session in the MBS session whose inactivity timer has expired.

[0227] Clause 5. The method described in Clause 4, wherein the first information includes at least one of the MBS session identifier and information regarding the expiration of an inactive timer.

[0228] Clause 6. The method described in Clause 1, wherein the second information includes at least one of the following: an identifier of the MBS session, a deactivation or suspension indication of the multicast broadcast service session, an identifier of the multicast resource bearer (MRB), or a deactivation or suspension indication of the MRB.

[0229] Clause 7. The method according to Clause 1, wherein the second information includes an RRC container that includes a Radio Resource Control (RRC) message.

[0230] Clause 8. The method described in Clause 7, wherein the RRC message includes at least one of the following: an identifier of the MBS session, a deactivation or suspension indication of the multicast broadcast service session, an identifier of the multicast resource bearer (MRB), or a deactivation or suspension indication of the MRB.

[0231] Clause 9. The method described in Clause 1, wherein the second information includes at least one of an MBS session identifier and a deactivation or suspension indication for a multicast service session.

[0232] Clause 10. The method described in Clause 1, wherein the first information includes the Packet Data Convergence Protocol (PDCP) downlink (DL) status.

[0233] Clause 11. The method according to Clause 1, wherein the second information includes at least one of the following: an indication to notify the second network node that the MBS session has not been deactivated, or an indication to request the second network node to ignore the expired inactive timer, or an indication to request the first network node to restart the expired inactive timer.

[0234] Clause 12. The method described in Clause 1, wherein, when determining to deactivate an MBS session, the first network node retains multicast broadcast service information associated with the MBS session to be deactivated.

[0235] Clause 13. The method described in Clause 11, wherein the multicast service information includes at least one of F1 UL TEID, F1 DLTEID, F1 UL transport layer address, and F1 DL transport layer address.

[0236] Clause 14. The method according to Clause 1, wherein the second network node receives the inactive timer configuration from the first network node via an E1AP message.

[0237] Clause 15, the method described in Clause 14, wherein the second network receives a set of inactive timer configurations.

[0238] Clause 16, the method described in Clause 14, wherein the inactive timer configuration is performed on a per MBS session basis.

[0239] Clause 17, the method according to Clause 14, wherein the second network receives two or more sets of inactive timer configurations.

[0240] Clause 18, the method according to Clause 17, wherein the second network is configured to receive one or more MBS session identifiers for each set of inactive timers.

[0241] Clause 19. The method described in Clause 14, wherein the 5GC transmits the inactive timer configuration to the first network node via an NGAP message.

[0242] Clause 20, the method described in Clause 19, wherein the first network receives a set of inactive timer configurations.

[0243] Clause 21, the method described in Clause 19, wherein the inactive timer configuration is performed on a per MBS session basis.

[0244] Clause 22, the method according to Clause 19, wherein the first network receives two or more sets of inactive timer configurations.

[0245] Clause 23, the method according to Clause 21, wherein the first network is configured to receive one or more MBS session identifiers for each set of inactive timers.

[0246] Clause 24. The method described in Clause 1, wherein the second information is transmitted to the distributed unit.

[0247] Clause 25, the method according to Clause 24, wherein the second information includes an indication for notifying the distributed unit to maintain context or configuration information related to the MBS session to be deactivated.

[0248] Clause 26. The method according to Clause 24, wherein the distributed unit generates a Media Access Control Layer Control Element (MAC CE) for notifying the wireless device of a disabled logical channel.

[0249] Clause 27. The method according to Clause 24, wherein the distributed unit transmits the deactivated MBS session identifier via a System Information Block (SIB) message or a Multicast Control Channel (MCCH).

[0250] Clause 28. The method described in Clause 24, wherein the distributed unit transmits a deactivation indication via a System Information Block (SIB) message or a Multicast Control Channel (MCCH).

[0251] Clause 29. The method described in Clause 1, wherein the second information is transmitted to 5GC.

[0252] Clause 30, the method described in accordance with Clause 29, wherein the second information includes the MBS session identifier.

[0253] Clause 31, the method described in Clause 30, wherein the second information includes a deactivation instruction.

[0254] Clause 32, the method described in Clause 30, wherein the second information includes an indication reflecting the expiration of an inactivity timer for an MBS session or a request or decision by a first network node to deactivate one or more MBS sessions.

[0255] Clause 33, the method described in Clause 1, wherein the first network node notifies the 5GC of its ability to disable MBS sessions.

[0256] Clause 34, the method described in Clause 1, wherein the distributed unit reports to the first network node its ability to support MBS session deactivation.

[0257] Clause 35, the method described in Clause 1, wherein the distributed unit reports to the first network node its ability to disable multicast resource bearers (MRBs).

[0258] Clause 36, the method described in Clause 1, wherein the 5GC transmits to the first network node a list including MBS sessions that can be disabled.

[0259] Clause 37. The method described in Clause 1, wherein the first network node transmits to the second network node a list including MBS sessions that can be disabled.

[0260] Clause 38. A method of wireless communication, comprising: receiving third information from a second network node by a first network node; and transmitting fourth information associated with one or more multicast broadcast service (MBS) sessions by the first network node.

[0261] Clause 39. The method described in Clause 38, wherein the third information includes information associated with one or more multicast broadcast service (MBS) sessions.

[0262] Clause 40, the method according to Clause 38, wherein the third information includes at least one of the following: an MBS session identifier, information indicating to the first network node that DL data of the detected MBS session has arrived.

[0263] Clause 41. The method according to Clause 38, wherein the fourth information includes at least one of the following: an identifier of the MBS session, an activation indication of the MBS session, an identifier of the multicast resource bearer (MRB), and an activation indication of the MRB.

[0264] Clause 42, the method according to Clause 38, wherein the fourth information includes an RRC container that includes a Radio Resource Control (RRC) message.

[0265] Clause 43. The method according to Clause 42, wherein the RRC message includes at least one of the following: an identifier of the MBS session, an activation indication of the MBS session, an identifier of the multicast resource bearer (MRB), and an activation indication of the MRB.

[0266] Clause 44, the method described in Clause 38, wherein the fourth information is transmitted to the distributed unit.

[0267] Clause 45. The method according to Clause 44, wherein the distributed unit generates a Media Access Control Layer Control Element (MAC CE) for notifying the wireless device of the activated logical channel.

[0268] Clause 46. The method according to Clause 44, wherein the distributed unit transmits the active MBS session identifier via a System Information Block (SIB) message or a Multicast Control Channel (MCCH).

[0269] Clause 47. The method according to Clause 44, wherein the distributed unit transmits the activation indication via a System Information Block (SIB) message or a Multicast Control Channel (MCCH).

[0270] Clause 48, the method according to Clause 38, wherein the fourth information includes at least one of F1-DL TEID or F1DL transport layer address.

[0271] Clause 49. The method described in Clause 38, wherein the fourth information includes at least one of an identifier of the MBS session and an activation indication.

[0272] Clause 50, the method described in Clause 38, wherein the fourth information is transmitted to 5GC.

[0273] Clause 51, the method described in Clause 50, wherein the fourth information includes the MBS session identifier.

[0274] Clause 52, the method described in Clause 50, wherein the fourth information includes an activation instruction.

[0275] Clause 53, the method described in Clause 50, wherein the fourth information includes an instruction instructing the first network node to request / determine to activate one or more MBS sessions.

[0276] Clause 54. The method described in any of Clauses 50-53, wherein the 5GC transmits the MBS session identifier.

[0277] Clause 55, the method according to Clause 50, wherein the 5GC transmits an activation indication to the first network node.

[0278] Clause 56, the method described in Clause 38, wherein the first network node notifies the 5GC of its ability to support MBS session activation.

[0279] Clause 57, the method described in Clause 38, wherein the distributed unit reports to the first network node its ability to support MBS session activation.

[0280] Clause 58, the method described in Clause 38, wherein the distributed unit reports to the first network node its ability to support the activation of the Multicast Resource Bearer (MRB).

[0281] Clause 59, the method described in Clause 38, wherein the 5GC transmits to the first network node a list including MBS sessions that can be activated.

[0282] Clause 60, the method described in Clause 38, wherein the first network node transmits to the second network node a list including MBS sessions that can be activated.

[0283] Clause 61. The method according to any one of Clauses 1-58, wherein the first network node includes a centralized cell control plane (CU-CP) and the second network node includes a centralized cell user plane (CU-UP).

[0284] Clause 62. An apparatus for wireless communication, comprising a memory and a processor, wherein the processor reads code from the memory and performs the method described in any one of Clauses 1 to 61.

[0285] Clause 63. A computer-readable program storage medium having code stored thereon, which, when executed by a processor, causes the processor to perform the method described in any one of Clauses 1 to 61.

[0286] Although this patent document contains numerous details, these details should not be construed as limiting the scope of any invention or the content that may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular invention. Certain features described in this patent document in the context of individual embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although the foregoing features may be described as functioning in certain combinations, or even initially claimed to be so, in some cases one or more features from the claimed combination may be removed from that combination, and the claimed combination may be for sub-combinations or variations thereof.

[0287] Similarly, although operations are described in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order or sequence shown, or requiring all illustrated operations to achieve the desired result. Furthermore, the separation of various system components in the embodiments described in this patent document should not be construed as requiring such separation in all embodiments.

[0288] Only some implementation methods and examples have been described. Other implementation methods, improvements and variations can be made based on the content described and explained in this patent document.

Claims

1. A method for wireless communication, comprising: A first network node, including a centralized cell control plane (CU-CP), receives first information from a second network node, including a centralized cell user plane (CU-UP), the first information including information associated with one or more multicast broadcast service MBS sessions; as well as The first network node transmits second information associated with the one or more MBS sessions to the distributed unit. The second information includes at least one of the following: the identifier of the one or more MBS sessions, the deactivation or suspension indication of the one or more MBS sessions, the identifier of the multicast resource bearer (MRB), and the deactivation or suspension indication of the MRB.

2. The method according to claim 1, wherein, The second piece of information includes the MBS session identifier.

3. The method according to claim 1, wherein, When an inactivity timer is detected to have expired, the second network node transmits first information to the first network node that is associated with at least one MBS session in the MBS session whose inactivity timer has expired.

4. The method according to claim 3, wherein, The first information also includes at least one of the MBS session identifier and information about the expiration of the inactive timer.

5. The method according to claim 1, wherein, The second information includes a Radio Resource Control (RRC) container, which includes RRC messages.

6. The method according to claim 5, wherein, The RRC message includes at least one of the following: an identifier of the one or more MBS sessions, a deactivation or suspension indication of the one or more MBS sessions, an identifier of the MRB, and a deactivation or suspension indication of the MRB.

7. The method according to claim 1, wherein, The first information includes the Packet Data Convergence Protocol (PDCP) downlink (DL) status.

8. The method according to claim 1, wherein, The second information includes at least one of the following: an indication to the second network node that the MBS session in the one or more MBS sessions has not been deactivated, or an indication to the second network node to ignore the expired inactive timer, or an indication to the second network node to restart the expired inactive timer.

9. The method according to claim 1, wherein, When it is determined that the MBS session will be deactivated, the first network node retains the multicast broadcast service information associated with the MBS session to be deactivated.

10. The method according to claim 9, wherein, The multicast service information includes at least one of F1 UL TEID, F1 DLTEID, F1 UL transport layer address, and F1 DL transport layer address.

11. The method according to claim 1, wherein, The second network node receives the inactive timer configuration from the first network node via an E1AP message.

12. The method according to claim 11, wherein, The second network receives a set of inactive timer configurations.

13. The method according to claim 11, wherein, The inactive timer configuration is performed on a per MBS session basis.

14. The method according to claim 11, wherein, The second network receives two or more sets of inactive timer configurations.

15. The method according to claim 14, wherein, The second network is configured to receive one or more MBS session identifiers for each group of inactive timers.

16. The method according to claim 11, wherein, 5GC transmits the inactive timer configuration to the first network node via NGAP messages.

17. The method according to claim 16, wherein, The first network receives a set of inactive timer configurations.

18. The method according to claim 16, wherein, The inactive timer configuration is performed on a per MBS session basis.

19. The method of claim 16, wherein, The first network receives two or more sets of inactive timer configurations.

20. The method according to claim 19, wherein, The first network is configured to receive one or more MBS session identifiers for each group of inactive timers.

21. The method according to claim 1, wherein, The second information includes an indication to notify the distributed unit to maintain context or configuration information related to the MBS session to be deactivated.

22. The method according to claim 1, wherein, The distributed unit generates a Media Access Control Layer Control Element (MAC CE) for notifying wireless devices of disabled logical channels.

23. The method according to claim 1, wherein, The distributed unit transmits the deactivated MBS session identifier via System Information Block (SIB) messages or Multicast Control Channel (MCCH).

24. The method according to claim 1, wherein, The distributed unit transmits the deactivation instruction via System Information Block (SIB) messages or Multicast Control Channel (MCCH).

25. The method according to claim 1, wherein, The second information is transmitted to 5GC.

26. The method of claim 25, wherein, The second piece of information includes the MBS session identifier.

27. The method according to claim 26, wherein, The second information includes a deactivation instruction.

28. The method according to claim 26, wherein, The second information includes an indication that an inactive timer for an MBS session has expired, or that the first network node has requested or decided to deactivate one or more MBS sessions.

29. The method according to claim 1, wherein, The first network node notifies 5GC of its ability to disable MBS sessions.

30. The method according to claim 1, wherein, The distributed unit reports its ability to disable MBS sessions to the first network node.

31. The method according to claim 1, wherein, The distributed unit reports to the first network node whether it supports disabling MRB.

32. The method according to claim 1, wherein, 5GC transmits a list of MBS sessions that can be disabled to the first network node.

33. The method according to claim 1, wherein, The first network node transmits a list of MBS sessions that can be disabled to the second network node.

34. A method for wireless communication, comprising: A third information is received by a first network node including a centralized cell control plane (CU-CP) from a second network node including a centralized cell user plane (CU-UP), the third information including information associated with one or more multicast broadcast service MBS sessions; as well as The first network node transmits fourth information associated with the one or more MBS sessions to the distributed unit. The fourth information includes at least one of the following: the identifier of the one or more MBS sessions, the activation indication of the one or more MBS sessions, the identifier of the multicast resource bearer (MRB), and the activation indication of the MRB.

35. The method according to claim 34, wherein, The third information also includes at least one of the following: MBS session identifier, and information indicating to the first network node that DL data of the MBS session has been detected to have arrived.

36. The method according to claim 34, wherein, The fourth piece of information includes a Radio Resource Control (RRC) container, which includes RRC messages.

37. The method of claim 36, wherein, The RRC message includes at least one of the following: the identifier of the one or more MBS sessions, the activation indication of the one or more MBS sessions, the identifier of the MRB, and the activation indication of the MRB.

38. The method according to claim 34, wherein, The distributed unit generates a Media Access Control Layer Control Element (MAC CE) for notifying wireless devices of the activated logical channel.

39. The method according to claim 34, wherein, The distributed unit transmits the active MBS session identifier via System Information Block (SIB) messages or Multicast Control Channel (MCCH).

40. The method of claim 34, wherein, The distributed unit transmits the activation indication via System Information Block (SIB) messages or Multicast Control Channel (MCCH).

41. The method according to claim 34, wherein, The fourth piece of information includes at least one of F1 DL TEID or F1 DL transport layer address.

42. The method according to claim 34, wherein, The fourth piece of information was transmitted to 5GC.

43. The method according to claim 42, wherein, The fourth piece of information includes the MBS session identifier.

44. The method according to claim 42, wherein, The fourth piece of information includes an activation instruction.

45. The method according to claim 42, wherein, The fourth piece of information includes an indication that the first network node requests / decides to activate one or more MBS sessions.

46. ​​The method according to any one of claims 42-45, wherein, The 5GC transmits the MBS session identifier.

47. The method according to claim 42, wherein, The 5GC transmits an activation instruction to the first network node.

48. The method according to claim 34, wherein, The first network node notifies 5GC of its ability to support MBS session activation.

49. The method of claim 34, wherein, The distributed unit reports to the first network node its ability to support MBS session activation.

50. The method of claim 34, wherein, The distributed unit reports to the first network node whether it supports the ability to activate MRB.

51. The method according to claim 34, wherein, 5GC transmits a list of MBS sessions that can be activated to the first network node.

52. The method according to claim 34, wherein, The first network node transmits a list of MBS sessions that can be activated to the second network node.

53. An apparatus for wireless communication, comprising a memory and a processor, wherein the processor reads code from the memory and implements the method according to any one of claims 1 to 52.

54. A computer-readable program storage medium having code stored thereon, which, when executed by a processor, causes the processor to perform the method according to any one of claims 1 to 52.

Images