Lossless switching between PTP and PTM transmission and reception in MBS

Abstract

A wireless transmit / receive unit (WTRU) may receive an instruction to switch from a point-to-point (PTP) transmission mode to a point-to-multipoint (PTM) transmission mode or may decide to switch from the PTP transmission mode to the PTM transmission mode based on a reliability condition associated with the PTM mode. Based on the instruction or decision, the WTRU may switch from the PTP transmission mode to the PTM transmission mode. The WTRU may receive a first data packet. The WTRU may extend a data packet reception window by extending a boundary of the data packet reception window. The boundary may be extended based on a sequence number (SN) and an offset of the first data packet.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 135,930, filed January 11, 2021, the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0002] Mobile communications using wireless communication continues to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G new radio (NR). The previous (conventional) generation of mobile communications RAT may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Systems, methods, and means related to lossless switching between point-to-point (PTP) and point-to-multipoint (PTM) transmission and reception, for example in a multicast and broadcast service (MBS), are described herein. A wireless transmit-receive unit (WTRU) may receive an instruction to switch from using point-to-point (PTP) transmission (e.g., from a PTP transmission mode) to using point-to-multipoint (PTM) transmission (e.g., to a PTM transmission mode) or may decide to switch from using PTP transmission (e.g., from a PTP transmission mode) to using PTM transmission (e.g., to a PTM transmission mode) based on a reliability condition associated with the PTM mode. Based on the instruction or decision, the WTRU may switch from using PTP transmission (e.g., from a PTP transmission mode) to using PTM transmission (e.g., to a PTM transmission mode). The WTRU may receive a first data packet. The WTRU may extend the data packet receiving window by extending a boundary of the data packet receiving window. The boundary may be extended based on a sequence number (SN) and an offset of the first data packet. In some examples, the WTRU may receive a second data packet and add the second data packet to a receive buffer for processing, where the adding may be based on a second SN of the second data packet being within the extended portion of the extended data packet receiving window. In some examples, the boundary of the data packet receiving window may be a starting edge of the data packet receiving window, and extending the boundary of the data packet receiving window may include setting a first value of the starting edge to a second value that is lower than the SN of the first data packet by an offset. In some examples, the extended portion of the extended data packet receiving window may be a portion of the extended data packet receiving window that starts at the second value and ends at the SN of the first data packet.

[0004] The WTRU may receive the first data packet. The WTRU may decide to switch from using PTM transmission (e.g., from the PTM transmission mode) to using PTP transmission (e.g., to the PTP transmission mode) based on a reliability condition associated with the PTM transmission mode. Based on the decision, the WTRU may transmit a request to switch from using PTM transmission (e.g., from the PTM transmission mode) to using PTP transmission (e.g., to the PTP transmission mode). The WTRU may receive an indication to switch from using PTM transmission (e.g., from the PTM transmission mode) to using PTP transmission (e.g., to the PTP transmission mode). Based on the indication, the WTRU may switch from using PTM transmission (e.g., from the PTM transmission mode) to using PTP transmission (e.g., to the PTP transmission mode) and may transmit a data packet status report. The data packet status report may indicate that the first data packet has been received.

[0005] The WTRU may trigger MBS mode switch(es) (e.g., based on an indication, such as an indication received from the network, or based on a decision by the WTRU) as shown by example in Figure 3. The WTRU (e.g., see 304 in Figure 3) may be configured for MBS and may be configured with one or more multicast radio bearers (MRBs) (e.g., see 308 in Figure 3). The WTRU may receive configuration information from the network (e.g., see 306 in Figure 3), which may include parameters / thresholds (e.g., to be used) for triggering MBS mode switching. The parameters / thresholds may include signal levels / thresholds for the serving cell (e.g., reference signal received power (RSRP) level(s) / threshold(s), reference signal received quality (RSRQ) level(s) / threshold(s), received signal to noise indicator (RSNI) level(s) / threshold(s), etc.), HARQ failure / success rate(s) level(s) / threshold(s), MRB(s) level(s) / threshold(s), recount(s), etc. The WTRU may monitor performance of MBS operation (according to configuration information or WTRU implementation). The WTRU may decide to switch MBS modes. For example, the WTRU (e.g., when operating in PTM mode) may decide to switch to PTP mode when, for example, the signal level of the serving cell falls below a threshold and / or the HARQ failure rate / retransmission count exceeds a threshold (e.g., see 310 in FIG. 3). When the WTRU decides to switch the MBS mode, for example, from PTM to PTP or vice versa, it may send an MBS mode switch request (e.g., see 312 in FIG. 3).The request may include information such as packet data convergence protocol (PDCP) / RLC reception status report, affected MRBs (e.g., MRB(s) associated with the mode to which the WTRU requests to switch), etc. The PDCP / RLC reception status report may, for example, be sent separately from the request (e.g., see 314 in FIG. 3). The WTRU may receive an instruction from the network (e.g., see 306 in FIG. 3) to switch from PTM to PTP (e.g., at 313 in response to 312 as shown in FIG. 3). The WTRU may, for example, change its PDCCH transmission monitoring behavior (e.g., to monitor only the C-RNTI, to monitor only the G-RNTI, or to monitor both the C-RNTI and G-RNTI) before / during / after sending the MBS mode switch request.

[0006] In an example, a WTRU (e.g., see 304 in FIG. 3) may switch (e.g., implicitly switch) MBS modes (e.g., perform an implicit MBS mode switch). The WTRU may be configured for MBS and may be configured with one or more MRBs. The WTRU may receive configuration information from the network (e.g., see 306 in FIG. 3) that specifies WTRU behavior, e.g., when the WTRU is operating in PTP mode and an RLC PDU is received, e.g., when the RLC PDU is associated with a PTM mode, e.g., when an associated RLC entity is associated with a PTM mode. The WTRU (e.g., when operating in PTP mode) may receive an RLC PDU (e.g., a trigger PTM RLC PDU, e.g., an RLC PDU that triggers a switch to PTM), e.g., the RLC PDU is associated with a PTM mode, e.g., the associated RLC entity is associated with PTM. The WTRU may determine (e.g., consider) the reception of an RLC PDU (e.g., based on configuration information) as an implicit MBS mode switch request from the network (e.g., see 319 in FIG. 3). The WTRU may start a period (e.g., a timer). The value of the period (e.g., the timer) may be specified in the received configuration information. The WTRU may operate the PTM RLC entity in a mode (e.g., a special (e.g., RLC) mode) (e.g., for the period (e.g., while the timer is running)).The special RLC mode may be or may implement (e.g., indicated in the received configuration information or configured in another way) one or more of the following: preventing erasure of PDUs with a sequence number (SN) lower than the SN of the triggering PTM RLC PDU and forwarding the PDU to the PDCP layer; extending the RLC window size (e.g., see 320 in FIG. 3) by decrementing the receive RLC window left edge by an offset (e.g., a determined, selected or configured offset such as half the receive RLC window size); extending the RLC window size by incrementing the receive RLC window right edge by an offset (e.g., a determined, selected or configured offset such as half the receive RLC window size); operating the RLC in a windowless or transparent RLC-like mode, e.g., by forwarding the received PDUs (e.g., all received PDUs) to the PDCP layer; or operating the PTM RLC entity in a UM mode (e.g., normal UM mode), e.g., if a period of time has elapsed (e.g., a timer has expired).

[0007] In an example, a WTRU (e.g., see 304 in FIG. 3 ) may switch (e.g., explicitly switch) MBS modes (e.g., perform an explicit MBS mode switch). The WTRU may be configured for MBS and may be configured with one or more MRBs. The WTRU may receive a command (e.g., RRC reconfiguration, MAC CE, DCI, and / or the like) from the network (e.g., see 313 and 319 in FIG. 3 ). The command may indicate (e.g., specify) that the WTRU should switch MBS mode from PTM to PTP or vice versa. The command may include information (e.g., additional information) such as RLC state variables for an RLC entity associated with the MBS mode that the command indicates to switch to. The WTRU may, for example, update the RLC state variables of the RLC entity according to the indicated values. The WTRU may start operating in the MBS mode that the command indicates to switch to. For an MBS mode switch from PTP to PTM, the WTRU may monitor (e.g., start monitoring) the G-RNTI (e.g., the G-RNTI associated with the MRB associated with the PTM mode) in the transmission(s) on the PDCCH (e.g., if the WTRU is not monitoring). For an MBS mode switch from PTM to PTP, the WTRU may stop monitoring the C-RNTI in the transmission(s) on the PDCCH. For an MBS mode switch from PTM to PTP, the WTRU may monitor (e.g., start monitoring) the C-RNTI in the transmission(s) on the PDCCH (e.g., if the WTRU is not monitoring). For an MBS mode switch from PTM to PTP, the WTRU may stop monitoring the G-RNTI in the transmission(s) on the PDCCH. [Brief description of the drawings]

[0008] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]1 is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 1 illustrates an example of a protocol architecture. [Diagram 3] FIG. 13 illustrates an example related to MBS mode switching. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] References herein to a timer may refer to a time, a period, keeping track of time, keeping track of a period, etc. References herein to a timer expiry may refer to determining that the time has occurred or that a period has expired. References to a timer running may refer to determining that it is within a period.

[0010] Systems, methods, and means for lossless switching between point-to-point (PTP) and point-to-multipoint (PTM) transmission and reception in multicast and broadcast services (MBS) are described herein. A wireless transmit / receive unit (WTRU) may be configured to trigger an MBS mode switch request (e.g., from PTP to PTM, or vice versa) to a network, for example, depending on the performance of the current MBS mode (e.g., taking into account radio link signal levels, hybrid automatic repeat request (HARQ) failure / success rates, retransmission counts, etc.). The WTRU may be configured to (e.g., implicitly) switch the MBS mode from PTP to PTM, for example, based on (e.g., in response to) receiving a packet data unit (PDU) via a radio link control (RLC) entity associated with the PTM. The WTRU may be configured to (e.g., implicitly) switch the MBS mode from PTM to PTP, for example, based on (e.g., in response to) receiving a PDU via an RLC entity associated with the PTP. The WTRU may be configured to modify RLC receiver behavior (e.g., window size, start and end SN of receiver window, PDU erasure behavior, etc.) based on, for example, switching MBS mode (e.g., implicitly). The WTRU may receive a message (e.g., radio resource control (RRC) reconfiguration, medium access control (MAC) control element (CE) and / or downlink control information (DCI)) from the network and may switch MBS mode (e.g., from PTP to PTM or vice versa) and / or set RLC state parameters to those indicated in the message.The WTRU may, for example, change its physical downlink control channel (PDCCH) monitoring behavior (e.g., to monitor only the cell radio network temporary identifier (C-RNTI), to monitor only the group RNTI (G-RNTI), or to monitor both the C-RNTI and the G-RNTI) before / during / after an MBS mode switch.

[0011] Systems, methods, and means related to lossless switching between point-to-point (PTP) and point-to-multipoint (PTM) transmission and reception, for example in multicast and broadcast services (MBS), are described herein. A wireless transmit / receive unit (WTRU) may receive an instruction to switch from using point-to-point (PTP) operation (e.g., from a PTP transmission mode) to using point-to-multipoint (PTM) operation (e.g., to a PTM transmission mode) or may decide to switch from using PTP operation (e.g., from a PTP operation mode) to using PTM operation (e.g., to a PTM transmission mode) based on a reliability condition associated with the PTM mode. Based on the instruction or decision, the WTRU may switch from using PTP operation (e.g., from a PTP transmission mode) to using PTM operation (e.g., to a PTM transmission mode). The WTRU may receive a first data packet. The WTRU may extend a data packet reception window by extending a boundary of the data packet reception window. The boundary may be extended based on a sequence number (SN) and an offset of the first data packet. In some examples, the WTRU may receive a second data packet and add the second data packet to a receive buffer for processing, where the adding may be based on a second SN of the second data packet being within the extended portion of the extended data packet receiving window. In some examples, the boundary of the data packet receiving window may be a starting edge of the data packet receiving window, and extending the boundary of the data packet receiving window may include setting a first value of the starting edge to a second value that is an offset lower than the SN of the first data packet. In some examples, the extended portion of the extended data packet receiving window may be a portion of the extended data packet receiving window that starts at the second value and ends at the SN of the first data packet.

[0012] The WTRU may receive the first data packet. The WTRU may decide to switch from using PTM operation (e.g., from PTM transmission mode) to using PTP operation (e.g., to PTP transmission mode) based on a reliability condition associated with using PTM operation (e.g., PTM transmission mode). Based on the decision, the WTRU may transmit a request to switch from using PTM operation (e.g., from PTM transmission mode) to using PTP operation (e.g., to PTP transmission mode). The WTRU may receive an indication to switch from using PTM operation (e.g., from PTM transmission mode) to using PTP operation (e.g., to PTP transmission mode). Based on the indication, the WTRU may switch from using PTM operation (e.g., from PTM transmission mode) to using PTP operation (e.g., to PTP transmission mode) and may transmit a data packet status report. The data packet status report may indicate that the first data packet has been received.

[0013] The WTRU may trigger MBS mode switch(es) (e.g., based on an indication, such as an indication received from the network, or based on a decision by the WTRU) as shown by example in Figure 3. The WTRU (e.g., see 304 in Figure 3) may be configured for MBS and may be configured with one or more multicast radio bearers (MRBs) (e.g., see 308 in Figure 3). The WTRU may receive configuration information from the network (e.g., see 306 in Figure 3), which may include parameters / thresholds (e.g., to be used) for triggering MBS mode switching. The parameters / thresholds may include signal levels / thresholds (e.g., Reference Signal Received Power (RSRP) level(s) / threshold(s), Reference Signal Received Quality (RSRQ) level(s) / threshold(s), Received Signal to Noise Indicator (RSNI) level(s) / threshold(s), etc.) for the serving cell, HARQ failure / success rate(s) level(s) / threshold(s), MRB(s) level(s) / threshold(s)) recount(s). The WTRU may monitor (according to configuration information or WTRU implementation) performance of MBS operation. The WTRU may decide to switch MBS modes. For example, the WTRU (e.g., when operating in PTM mode) may decide to switch to PTP mode, e.g., when the signal level of the serving cell falls below a threshold and / or the HARQ failure rate / retransmission count is above a threshold (e.g., see 310 in FIG. 3). When the WTRU decides to switch the MBS mode, e.g., from PTM to PTP or vice versa, it may send an MBS mode switch request (e.g., see 312 in FIG. 3). The request may include information such as a Packet Data Convergence Protocol (PDCP) / RLC reception status report, affected MRBs (e.g., MRB(s) associated with the mode to which the WTRU requests to switch), etc. The PDCP / RLC reception status report may be sent, for example, separately from the request (e.g., see 314 in FIG. 3).The WTRU may receive an instruction from the network (e.g., see 306 in FIG. 3) to switch from PTM to PTP (e.g., as shown in FIG. 3, at 313 in response to 312). The WTRU may change its PDCCH transmission monitoring behavior (e.g., to monitor only the C-RNTI, to monitor only the G-RNTI, or to monitor both the C-RNTI and the G-RNTI), for example, before / during / after transmitting the MBS mode switch request.

[0014] In an example, a WTRU (e.g., see 304 in FIG. 3) may switch (e.g., implicitly switch) MBS modes (e.g., perform an implicit MBS mode switch). The WTRU may be configured for MBS and may be configured with one or more MRBs. The WTRU may receive configuration information from the network (e.g., see 306 in FIG. 3) that specifies WTRU behavior, e.g., when the WTRU is operating in PTP mode and an RLC PDU is received, e.g., when the RLC PDU is associated with a PTM mode, e.g., when an associated RLC entity is associated with a PTM mode. The WTRU (e.g., when operating in PTP mode) may receive an RLC PDU (e.g., a trigger PTM RLC PDU, e.g., an RLC PDU that triggers a switch to PTM), e.g., the RLC PDU is associated with a PTM mode, e.g., the associated RLC entity is associated with PTM. The WTRU may determine (e.g., consider) the reception of an RLC PDU (e.g., based on configuration information) as an implicit MBS mode switch request from the network (e.g., see 319 in FIG. 3). The WTRU may start a period (e.g., a timer). The value of the period (e.g., the timer) may be specified in the received configuration information. The WTRU may operate the PTM RLC entity in a mode (e.g., a special (e.g., RLC) mode) (e.g., for the period (e.g., while the timer is running)).The special RLC mode may be or may implement (e.g., indicated in the received configuration information or configured in another way) one or more of the following: preventing erasure of PDUs with a sequence number (SN) lower than the SN of the triggering PTM RLC PDU and forwarding the PDU to the PDCP layer; extending the RLC window size (e.g., see 320 in FIG. 3) by decrementing the receive RLC window left edge by an offset (e.g., a determined, selected or configured offset such as half the receive RLC window size); extending the RLC window size by incrementing the receive RLC window right edge by an offset (e.g., a determined, selected or configured offset such as half the receive RLC window size); operating the RLC in a windowless or transparent RLC-like mode, e.g., by forwarding the received PDUs (e.g., all received PDUs) to the PDCP layer; or operating the PTM RLC entity in a UM mode (e.g., normal UM mode), e.g., if a period of time has elapsed (e.g., a timer has expired).

[0015] In an example, a WTRU (e.g., see 304 in FIG. 3 ) may switch (e.g., explicitly switch) MBS modes (e.g., perform an explicit MBS mode switch). The WTRU may be configured for MBS and may be configured with one or more MRBs. The WTRU may receive a command (e.g., RRC reconfiguration, MAC CE, DCI, and / or the like) from the network (e.g., see 313 and 319 in FIG. 3 ). The command may indicate (e.g., specify) that the WTRU should switch MBS mode from PTM to PTP or vice versa. The command may include information (e.g., additional information) such as RLC state variables for an RLC entity associated with the MBS mode that the command indicates to switch to. The WTRU may, for example, update the RLC state variables of the RLC entity according to the indicated values. The WTRU may start operating in the MBS mode that the command indicates to switch to. For an MBS mode switch from PTP to PTM, the WTRU may monitor (e.g., start monitoring) the G-RNTI (e.g., the G-RNTI associated with the MRB associated with the PTM mode) in the transmission(s) on the PDCCH (e.g., if the WTRU is not monitoring). For an MBS mode switch from PTM to PTP, the WTRU may stop monitoring the C-RNTI in the transmission(s) on the PDCCH. For an MBS mode switch from PTM to PTP, the WTRU may monitor (e.g., start monitoring) the C-RNTI in the transmission(s) on the PDCCH (e.g., if the WTRU is not monitoring). For an MBS mode switch from PTM to PTP, the WTRU may stop monitoring the G-RNTI in the transmission(s) on the PDCCH.

[0016] 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0017] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0018] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode-B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0019] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

[0020] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0021] More specifically, as noted above, the communications system 100 may be a multiple access system and may use one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0022] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-Advanced, LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0023] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology, such as New Radio (NR) radio access, which may establish the air interface 116 using NR technology.

[0024] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0026] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a location of a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0027] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a public switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may use a cellular-based wireless technology, and a base station 114b, which may use an IEEE 802 wireless technology.

[0030] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0033] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0034] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0035] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0036] The processor 118 may receive power from the power source 134, but may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0037] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding a current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0038] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0039] The WTRU 102 may include a full-duplex radio where the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio for the transmission and reception of either some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0040] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0041] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0042] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG 1C, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0043] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is shown as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0044] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0045] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0046] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0047] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0049] In an exemplary embodiment, the other network 112 may be a WLAN.

[0050] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be transmitted, for example, through the AP, where the source STA may transmit traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be viewed and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between the source STA and the destination STA (e.g., directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

[0051] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) with collision avoidance may be implemented. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0052] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0053] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz wide channels may be formed by combining multiple contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be transmitted to the Medium Access Control (MAC).

[0054] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., support only for) specific and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0055] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy due to STAs (that only support the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain idle and available for use.

[0056] In the United States, the available frequency bands that can be used by 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz depending on the country code.

[0057] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to one embodiment. As mentioned above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 113 may also communicate with the CN 115.

[0058] The RAN 113 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a, for example, using multiple antennas. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or gNB 180c).

[0059] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0060] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0061] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0062] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is shown as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0064] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0065] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0066] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0067] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0068] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial wireless communication.

[0069] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0070] For example, the disclosed systems, methods, and means, including non-limiting examples, do not limit the applicability of the systems, methods, and means described herein (e.g., to other wireless technologies). The term network may refer to one or more gNBs, which may be associated with one or more transmit / receive points (TRPs) and / or any other nodes in a radio access network (RAN).

[0071] Multimedia Broadcast Multicast System (MBMS) services may be delivered over wireless networks according to (e.g., via) a number of methods, which may include, for example, one or more of the following: Unicast Cellular Transmission (UC), Multicast Broadcast Single Frequency Network (MBSFN), or Single Cell Point-to-Multipoint (SC-PTM).

[0072] SC-PTM can support broadcast / multicast services, for example, on a single cell. The broadcast / multicast area can be adjusted (e.g., dynamically) per cell, for example, according to user distribution. SC-PTM can transfer broadcast / multicast services, for example, using a downlink channel (e.g., an LTE downlink shared channel such as PDSCH), which can be scheduled using an RNTI for a group of users (e.g., a common RNTI such as group-RNTI). SC-PTM scheduling can be agile. Radio resources can be allocated (e.g., dynamically) in the time domain and / or frequency domain, for example, by PDCCH based on real-time traffic load transmission time interval (TTI) per TTI (e.g., at an integer multiple of one or more symbols). SC-PTM can be applied, for example, when a broadcast / multicast service is distributed (e.g., expected to be distributed) to a limited number of cells (e.g., due to user interest), and the cells can change (e.g., dynamically) (e.g., due to user movement). SC-PTM may enable efficient radio utilization and / or flexible deployment for several applications, such as critical communications, traffic information for automobiles, and on-demand TV services.

[0073] The MBSFN may arrange (e.g., to be identical and / or time aligned) transmissions from different cells to appear as a transmission (e.g., a single transmission) from the perspective of the WTRU. Time synchronization between base stations (e.g., eNBs) may be enabled, for example, by (the concept of) MBSFN synchronization areas. An MBSFN area may include a group of cells within an MBSFN synchronization area of ​​a network coordinated to achieve MBSFN transmissions. The MBMS architecture may include (e.g., define) various logical entities for performing network functions applicable to the MBMS transmission(s). A multi-cell / multicast coordination entity (MCE) may perform admission control, determine whether to use SC-PTM or MBSFN, suspend and resume for MBMS services, and / or the like. An MBMS Gateway (MBMS-GW) may perform session control signaling, forward MBMS user data to the eNBs (e.g., via IP multicast), and / or the like.

[0074] MBMS (e.g., in LTE) can support unicast, SC-PTM, and / or MBSFN transmissions. For example, if MBMS transmissions consume too much (e.g., all) of the bandwidth (BW), frequency domain resource allocation may not be supported, which may be inefficient in deployments with large bandwidths.

[0075] MBMS may be referred to as Multicast and Broadcast Service (MBS) in, for example, New Radio (NR). The terms MBMS and MBS may be used interchangeably.

[0076] A WTRU may be configured with a transmission mode (e.g., if MBS is configured). The transmission mode may include one or more transmission methods, such as unicast, multicast (e.g., SC-PTM), broadcast (e.g., SFN), mixed mode (e.g., WTRU can receive unicast as well as multicast and / or broadcast). The transmission modes are non-limiting in scope and applicability (e.g., a transmission mode may be applicable to similar over-the-air delivery methods). One or more non-unicast modes may include a receive-only mode (ROM). The transmission modes may include a sidelink interface (e.g., for direct WTRU-to-WTRU communication). The transmission modes may be used for delivery of services with different Quality of Service (QoS), such as enhanced Multimedia Broadcast (eMBB), Ultra Reliable and Low Latency Communications (URLLC) and / or MBS services. The transmission modes may be used for delivery of services to one receiver (e.g., via unicast) or multiple receivers (e.g., via multicast, groupcast, or broadcast). Examples of services to multiple users may include vehicle-to-everything (V2X) services (e.g., groupcast) and MBS services (e.g., multicast, broadcast). MBS mode and / or MBS transmission mode may refer to (e.g., used to refer to) a transmission mode of a WTRU.

[0077] The WTRU may be configured for delivery (e.g., transmission) of MBMS data services. The WTRU may be configured to operate in a transmit mode to exchange MBS-related data and / or control information (e.g., and / or other data and / or control information). The WTRU may be (e.g., further) configured for delivery of MBS services. For example, the WTRU may be configured for mapping of data bearers and / or signaling bearers for the configured transmission method(s) to exchange MBS-related data (e.g., L2 bearer configuration for MBS). In some examples, the WTRU may be configured for delivery of MBS data performed using (e.g., only using) multicast and / or broadcast transmissions, and / or mixed mode transmissions (e.g., unicast and multicast) with other services transmitted via unicast (e.g., eMBB, URLLC). In some examples, the WTRU may be configured for mixed mode transmission (e.g., unicast and multicast), with delivery of MBS data performed using unicast (e.g., referred to as point-to-point (PTP) transmission / mode) and / or multicast transmission (e.g., referred to as point-to-multipoint (PTP) transmission / mode), regardless of whether the WTRU is active in other services such as unicast transmission (e.g., eMBB, URLLC).

[0078] MBMS (e.g., in NR) may be utilized in various deployments and may support one or more of the following: V2X, sidelink, public safety, IoT (e.g., narrowband (NB) IoT and enhanced machine type communication (eMTC)) devices (e.g., for software updates), smart grid / utility, television (TV) video and radio services in 5G (e.g., linear TV, Live, smart TV, managed and over-the-top (OTT) content delivery, radio services), which may include video delivery, large peaks in concurrent consumption of OTT services over unicast media streams, and / or immersive six degrees of freedom (6DoF) volumetric streaming, push services (e.g., advertising and weather), Ethernet broadcast / multicast for factory automation, extended reality, group gaming, etc.

[0079] Various MBS-related enabling capabilities (e.g., enablers) may be provided (e.g., for NR). Service switching may occur between PTP, PTM, and mixed mode operation. A change in service may be triggered, for example, due to one or more of the following: WTRU mobility, user activity, WTRU density, or link conditions. WTRU mobility may include different scenarios for mode switching, such as one or more of the following: PTP to PTP, PTP to PTM, PTP to PTM+PTP, PTM to PTP, PTM to PTM, PTM to PTM+PTP, PTM+PTP to PTP, PTM+PTP to PTM, and / or PTM+PTP to PTM+PTP. WTRU mobility may include different handover scenarios, such as one or more of the following: intra-eNB / intra-MBS area inter-cell mobility, inter-eNB / intra-MBS area inter-cell mobility, inter-MBS area mobility, inter-RAT mobility with or without a change in transmission mode. Triggered changes in services (e.g., due to WTRU mobility) may occur with or without service continuity, which may be lossy or lossless. WTRU mobility issues may include enabling service continuity for IDLE / INACTIVE WTRUs.

[0080] User activity (e.g., as a trigger for a change in the service) may include one or more of the following: user control over a media stream (e.g., a user may interact with a playback function and have some control over a media stream), or end-user interaction with live or shared content over an uplink channel for user engagement and / or monetization (e.g., video distribution, advertising and / or public safety).

[0081] WTRU density (e.g., as a trigger for a change in service) may include one or more of the following: a change in the number of users acquiring and receiving the MBS service (e.g., a threshold may be met, in which case system efficiency may be increased by changing the MBS transmission mode), or V2X proximity / WTRU range in the area. Link conditions (e.g., as a trigger for a change in service) may include: different characteristics for resources between multicast and unicast transmissions to the WTRU (e.g., quality may be lower for a first resource compared to a second resource).

[0082] Dynamic control of transmission resources and / or distribution areas may be implemented (e.g., in NR). Dynamic control of transmission resources and / or distribution areas may be based on (e.g., motivated by) one or more of the following: local TV / radio services occur at certain times of the day, fluctuations / changes in on-demand MBS services (e.g., in services with uplink data support or for higher reliability support), or target areas for group communication and live video may be based on a specific area or location or may be triggered by an event, where the area may change (e.g., due to mobility of interested users). Changes in MBS areas may be slower (e.g., in terms of time scales) than adjusting resources between unicast (UC) / multicast-broadcast (MB) / broadcast (BC).

[0083] Reliability of transmission may be implemented / improved (e.g., in NR). MBS services may support application-level retransmission. Application-level methods may have a trade-off between reliability and efficiency, which may be costly in terms of spectrum efficiency. Application-level methods may not meet lower latency requirements. Different MBS services may have different latency, efficiency, and / or reliability requirements. In some examples, MBS services may experience severe Doppler drops, which may make it difficult to use MBS services in high-velocity environments. In examples, power grid distribution (e.g., in NR) may be implemented to have a 5 ms latency and a 10-6 packet error rate. V2X (e.g., in NR) may be implemented to have a maximum latency of 20 ms for information sharing between WTRUs and road side units (RSUs). Mission critical push to talk (MCPTT) (e.g., in NR) may be implemented to have a maximum latency of 300 ms (e.g., for mouth-to-ear latency).

[0084] Devices that may be deployed as MBS receivers (e.g., in NR) may range from read-only mode (ROM) WTRUs (e.g., devices that are not capable of and / or are not expected to perform uplink transmissions to acquire and receive MBS transmissions) to WTRUs that implement more complex functionality (e.g., including functions and procedures that utilize uplink transmissions). Some (e.g., more complex) WTRUs may support carrier aggregation, dual connectivity, multiple concurrently active air interfaces, and / or operation across (e.g., in parallel) different frequency ranges (e.g., FR1 and FR2).

[0085] The Radio Link Control (RLC) protocol may include a Layer 2 protocol that resides between the Packet Data Convergence Protocol (PDCP) and the Medium Access Control (MAC) protocol and may facilitate the transfer of data between the two layers. RLC protocol functions (e.g., tasks) may include one or more of the following: That is, forwarding upper layer protocol data units (PDUs) in one of multiple (e.g., three) modes (e.g., acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM)), error correction (e.g., via automatic repeat request (ARQ), which may be for AM data transfer (e.g., only for AM data transfer)), segmentation and / or reassembly of RLC service data units (SDUs) (e.g., for UM and / or AM), resegmentation of RLC data PDUs (e.g., for AM), duplicate detection (e.g., for AM), RLC SDU erasure (e.g., for UM and AM), RLC re-establishment, and / or protocol error detection (e.g., for AM).

[0086] Data multiplexing (e.g., in LTE) may be implemented multiple times (e.g., twice), for example, by concatenating RLC SDUs from a logical channel into an RLC PDU in the RLC layer and by multiplexing RLC PDUs from different logical channels into a MAC PDU in the MAC layer. The MAC PDUs may carry information about the same data fields in the RLC and MAC (sub)headers. RLC concatenation may include input from the MAC layer scheduling (e.g., interaction with the MAC may be used to construct an RLC PDU with an appropriate size for each UL grant). RLC concatenation may be performed (e.g., within one scheduling cycle), for example, in response to receiving a scheduling decision (e.g., uplink grant size) and performing an LCP procedure in the MAC layer. The RLC concatenation process may imply that the RLC and MAC layers may not perform pre-processing without grant information (e.g., before receiving grant information). The inability to pre-process without grant information (e.g., before grant information is received) may be limiting for very high data rates and low latency requirements (e.g., in NR). In some examples, the concatenation procedure may not take place at the NR RLC layer. The RLC may send a PDCP packet to the MAC in response to (e.g., immediately in response to) the header addition. The MAC layer may concatenate / multiplex data from multiple RLC PDUs and transmit the data over the air interface, for example, in response to the MAC layer receiving a scheduling grant and a transport block size (TBS) indication.

[0087] The RLC (e.g., LTE RLC) may have a reordering function. The reordering may be performed by the PDCP layer (e.g., in NR), which may have a reordering function. The performance of the reordering by the PDCP layer may improve latency, e.g., delivering out-of-order RLC packets to the PDCP layer may enable faster decryption of the out-of-order packets.

[0088] RLC UM operations may use state variable(s), constant(s), and timer(s). A transmitting UM RLC entity (e.g., each transmitting UM RLC entity) may maintain a state variable, TX_Next (e.g., a UM transmit state variable). The TX_Next state variable may hold the value of the SN to be assigned to the next (e.g., newly) generated unacknowledged mode data (UMD) PDU having segment(s). TX_Next may be initially set to 0. TX_Next may be updated, for example, in response to the UM RLC entity transmitting a UMD PDU to the lower layer, which may include the last segment of the RLC SDU.

[0089] A receiving UM RLC entity (e.g., each receiving UM RLC entity) may maintain one or more of the following state variables: RX_Next_Reassembly (e.g., a UM receiving state variable), RX_Timer_Trigger (e.g., a UM t-Reassembly state variable), or RX_Next_Highest (e.g., a UM receiving state variable).

[0090] RX_Next_Reassembly (e.g., a UM reception state variable) may hold the value of the earliest SN that can (e.g., still) be considered for reassembly. In some examples, RX_Next_Reassembly may be initially set to 0. In some examples (e.g., for groupcast and broadcast of NR sidelink communications), RX_Next_Reassembly may be initially set to the SN of the first received UMD PDU that contains the SN. PDUs with lower SNs may be considered as received and / or lost.

[0091] RX_Timer_Trigger (eg, a UM t-Reassembly state variable) may hold a value of a SN following the SN that triggered (eg, started) the t-Reassembly described herein.

[0092] RX_Next_Highest (e.g., a UM reception state variable) may hold a value of the next SN of the UMD PDU with the highest SN among the received UMD PDUs. In some examples, RX_Next_Highest may be initially set to 0. In some examples (e.g., for groupcast and broadcast NR sidelink communications), RX_Next_Highest may be initially set to the SN of the first received UMD PDU that contains an SN.

[0093] UM_Window_Size may be a constant. UM_Window_Size may be used by the receiving UM RLC entity to define, for example, the SN of UMD SDUs that may be received without causing the advancement of the receive window. In some examples, UM_Window_Size may be equal to 32, for example, if a 6-bit SN is configured. In some examples, UM_Window_Size may be equal to 2048, for example, if a 12-bit SN is configured. The RLC receive window may be considered to be the SN between RLC_Next_Reassembly and RLC_Next_Reassabmly+UM_Window_Size. RX_Next_Reassembly may be considered to be the left edge, start edge, or bottom edge of the RLC receive window. RX_Next_Reassembly+UM_Window_Size may be considered to be the right edge, end edge, or top edge of the RLC receive window.

[0094] t-Reassembly may be a timer. t-Reassembly may be used by the receiving side of the AM RLC entity and the receiving UM RLC entity, for example, to detect loss of RLC PDUs at lower layers. For example, if a first t-Reassembly is running, a second t-Reassembly may not be started. In some examples, only one t-Reassembly per RLC entity may be running at a time (e.g., at a given time).

[0095] A reception operation can be executed. The receiving UM RLC entity can maintain a reassembly window, for example, according to the state variable RX_Next_Highest. The SN can be within the reassembly window if, for example, (RX_Next_Highest - UM_Window_Size) <= SN < RX_Next_Highest. The SN can be outside the reassembly window if, for example, otherwise.

[0096] The UM RLC receiving entity can remove the RLC header after receiving a UMD PDU (for example, when the UMD PDU is received from the lower layer), then transmit the received UMD PDU to the upper layer, discard the received UMD PDU, or place the received UMD PDU in the receive buffer. For example, when a UMD PDU is received from the lower layer and the received UMD PDU is placed in the receive buffer, the UM RLC receiving entity can update the state variables, reconstruct the RLC SDU and transmit it to the upper layer, and start / stop t-Reassembly (if necessary). The UM RLC receiving entity can update the state variables, discard the RLC SDU segments, and start t-Reassembly (if necessary), for example, when t-Reassembly expires.

[0097] A UMD PDU can be received by the UM RLC entity from the lower layer. The receiving UM RLC entity can remove the RLC header and transmit the RLC SDU to the upper layer if, for example, the UMD PDU header does not contain an SN (for example, when the UMD PDU is received from the lower layer). The receiving UM RLC entity can discard the received UMD PDU if, for example, (RX_Next_Highest - UM_Window_Size) <= SN < RX_Next_Reassembly. The receiving UM RLC entity can place the received UMD PDU in the receive buffer if, for example, otherwise.

[0098] The UMD PDU may be placed in a receive buffer. The receiving UM RLC entity may, for example, if a byte segment (e.g., all byte segments) with SN=x is received, reconstruct an RLC SDU from the byte segment (e.g., all byte segments) with SN=x (e.g., based on the UMD PDU with SN=x placed in the receive buffer), remove the RLC header, and convey the reconstructed RLC SDU to upper layers. The receiving UM RLC entity may, for example, if x=RX_Next_Reassembly (e.g., based on the UMD PDU with SN=x placed in the receive buffer), update RX_Next_Reassembly to the SN of the first SN that is greater (e.g., >) than the (e.g., current) RX_Next_Reassembly that has not been reconstructed and delivered to upper layers.

[0099] The receiving UM RLC entity may update RX_Next_Highest to x+1 (e.g., based on a UMD PDU with SN=x placed in a receive buffer) and / or erase UMD PDUs with SNs that are outside the reassembly window (e.g., any UMD PDUs), e.g., if x is outside the reassembly window. The receiving UM RLC entity may, e.g., set RX_Next_Reassembly (e.g., based on a UMD PDU with SN=x placed in a receive buffer) to the first SN that is greater than or equal to (e.g., >=) (RX_Next_Highest-UM_Window_Size) that has not been reassembled and delivered to upper layers, e.g., if RX_Next_Reassembly is outside the reassembly window.

[0100] The receiving UM RLC entity may, for example, stop and reset t-Reassembly (e.g., based on a UMD PDU with SN=x being placed in the receive buffer) if t-Reassembly is running and one or more of the following are true: RX_Timer_Trigger<=RX_Next_Reassembly, RX_Timer_Trigger is outside the reassembly window, RX_Timer_Trigger is not equal to RX_Next_Highest, or RX_Next_Highest=RX_Next_Reassembly+1 and there are no missing byte segments of the RLC SDU associated with SN=RX_Next_Reassembly before the last byte of a received segment of the RLC SDU (e.g., all received segments).

[0101] The receiving UM RLC entity may, for example, start t-Reassembly (e.g., based on a UMD PDU with SN=x being placed in the receive buffer) and / or set RX_Timer_Trigger to RX_Next_Highest if t-Reassembly is not being performed (including, for example, when t-Reassembly is stopped as described herein) and one or more of the following are true: RX_Next_Highest>RX_Next_Reassembly+1, or RX_Next_Highest=RX_Next_Reassembly+1 and there is at least one missing byte segment of the RLC SDU associated with SN=RX_Next_Reassembly before the last byte of a received segment (e.g., all received segments) of this RLC SDU.

[0102] The timer t-Reassembly may expire. The receiving UM RLC entity may update RX_Next_Reassembly (e.g., based on t-Reassembly expiration) to the SN of the first SN that is not reconfigured or greater (e.g., ≧) than the RX_Timer_Trigger, or erase segments (e.g., all segments) that have an SN less than (e.g., <) the updated RX_Next_Reassembly. The receiving UM RLC entity may start t-Reassembly (e.g., based on t-Reassembly expiration) and / or set RX_Timer_Trigger to RX_Next_Highest, e.g., if RX_Next_Highest>RX_Next_Reassembly+1 and / or if RX_Next_Highest=RX_Next_Reassembly+1 and there is at least one missing byte segment of an RLC SDU associated with SN=RX_Next_Reassembly before the last byte of a received segment (e.g., all received segments) of the RLC SDU.

[0103] In an MBS example, the WTRU may join the multicast when the session starts, or the WTRU may start the session in PTP mode and switch (e.g., later) to PTM mode, e.g., due to improved radio conditions, e.g., due to mobility to a cell that supports PTM mode (e.g., only PTM mode), thereby enabling the WTRU to receive the multicast session via the broad beam used for PTM mode.

[0104] The state variable(s) controlling the RLC receive window (e.g., RX_Next_Reassembly and / or RX_Next_Highest) may be initialized (e.g., to 0) when, for example, a UM RLC entity is established. The state variable(s) controlling the RLC receive window may be set to the SN of the first received UMD PDU (e.g., if the first received UMD PDU contains an SN), for example, in the case of NR sidelink groupcast / broadcast communication (e.g., because the WTRU can join the groupcast / broadcast after the session starts).

[0105] In an example of a PTM mode, the WTRU may switch from a PTP mode to a PTM mode or join an MBS session in a PTM mode. The state variable(s) may be initialized to the SN of the first received PDU in response to switching to a PTM mode (e.g., a PTM RLC mode). This approach may not be suitable for lossless switching to a PTM mode, for example. For example, the first RLC PDU that may be received (e.g., when switching to a PTM mode after a session has started or joining an MBS session in a PTM mode) may be out of order, e.g., with a SN of x. The RLC receiver may erase the first RLC PDU received, for example, if the starting edge of the RLC receive window is initialized to the SN of the first received PDU and a missing RLC packet (e.g., an RLC packet with SN xn) is received out of order (e.g., later).

[0106] RLC UM operation may be improved, for example, to enable lossless switching from PTP mode operation to PTM mode operation in the MBS.

[0107] Methods for lossless switching of MBS operation modes are described by example(s) based on transmission and / or distribution of MBS services. The methods described herein are not limited to the example(s) (e.g., systems and services) described herein. The methods described herein may be applicable to two or more types (e.g., any type) of transmission and / or services, including but not limited to V2X, augmented reality, gaming, IoT / MTC, industrial use cases, etc. The methods described herein may be implemented alone or in combination (e.g., in any MBS system).

[0108] A WTRU (e.g., configured for receiving data for an MBS) (e.g., see 304 in FIG. 3) may be configured with a data radio bearer (DRB) (e.g., a multicast radio bearer (MRB)), which may be dedicated to receiving the MBS (e.g., see step 308 in FIG. 3). An MBS service and an MRB may be considered to be the same (e.g., when described from an L2 and / or L3 perspective). An MBS service may be configured with zero, one, or multiple MRBs.

[0109] Multiple (eg, several) QoS flows may be multiplexed within an MRB (eg, similar to a DRB (eg, a normal DRB)).

[0110] Figure 2 shows an example of a protocol architecture (see also 302 in Figure 3). As shown in Figure 2 (and step 308 in Figure 3), the MRB can adopt a split bearer-like configuration (e.g., having a PDCP entity and multiple (e.g., two) RLC entities. The first RLC entity may be for PTM operation, and the second RLC entity may be for PTP operation.

[0111] A Cell Radio Network Identifier (C-RNTI) may (e.g., uniquely) identify an RRC connection of a WTRU in a cell. A Group RNTI (G-RNTI) may identify a group of WTRUs participating in multicast. A WTRU (e.g., configured with an MRB according to the example architecture shown in FIG. 2) may monitor DL ​​scheduling for the MRB on the C-RNTI and / or G-RNTI. In the methods described herein, it may be assumed that an RLC entity associated with a PTM operates in an unacknowledged mode (UM) and an RLC entity associated with a PTP operates in an acknowledged mode (AM). The methods disclosed herein may be applied to other operating modes (e.g., a PTM operating in a transparent mode (TM) or AM, or a PTP operating in a TM or UM).

[0112] The methods described herein may be applicable to switching from PTP to PTM. The methods described herein may be applicable to other type(s) of switching (e.g., PTM to PTP). In the examples described herein, the terms left edge, start edge, and bottom edge may be used interchangeably to indicate a starting SN of an RLC receiving window. In the examples described herein, the terms right edge, end edge, and top edge may be used interchangeably to indicate an ending SN of an RLC receiving window. In some examples (e.g., legacy operation), it may be assumed that PDUs with SNs outside the RLC receiving window may be dropped by the receiver.

[0113] MBS mode switching may be triggered (see, e.g., 312 and 318 in FIG. 3). In some examples, the WTRU may send information about the need to switch from PTM to PTP (see, e.g., 312 in FIG. 3). The information may be sent in an RRC message (e.g., MBSModeSwitchRequest message) or an information element (IE) may be included in the RRC message (e.g., IE in WTRUAssistanceInformation message). The WTRU may include in the request (e.g., IE in MBSModeSwitchRequest message or WTRUAssistanceInformation message) receiver status (e.g., in PDCP and / or RLC entities) for associated MRBs (e.g., concerned MRBs) (see, e.g., 314 in FIG. 3). In some examples, the WTRU may send a request to switch operation modes for multiple MRBs. In some examples, the WTRU may include in the request (see, e.g., steps in FIG. 3) status reports (e.g., PDCP status report, RLC status report) corresponding to the MRBs (e.g., each MRB) (see, e.g., steps in FIG. 3).

[0114] In some examples (e.g., legacy operation), a PDCP status PDU may be transmitted for a DRB operating in AM, e.g., during PDCP re-establishment, PDCP data recovery, and / or dual active protocol stack (DAPS) handover (e.g., in the case of uplink data switching or when DAPS is released). A PDCP status PDU may be transmitted, e.g., during (e.g., only during) DAPS uplink data switching (e.g., in the case of UM DRB). In some examples, the WTRU may transmit a PDCP status PDU for an MRB without meeting a legacy condition for a PDCP status report (e.g., when the WTRU detects that PTM operation is degraded / meets a threshold condition, as detected based on frequent (e.g., above a threshold) HARQ failures / retransmissions and / or the serving cell's signal level dropping below a certain threshold, etc.) (e.g., see 310 of FIG. 3). The network (e.g., see 306 in FIG. 3) may interpret the PDCP status report (e.g., sent without meeting a legacy triggering condition) as, e.g., an implicit request by the WTRU to switch to MBS mode (e.g., see 313 in FIG. 3). In some examples, the WTRU may decide to switch from PTM mode to PTP mode without sending a request to the network (e.g., see 306 in FIG. 3) (e.g., 312 in FIG. 3 may not be performed), e.g., based on (e.g., based only on) the WTRU detecting that PTM operation is degraded / meets one or more threshold conditions described herein.

[0115] In some examples, a flag / field may be implemented / utilized in the PDCP status report to indicate (eg, explicitly) a request to switch MBS modes.

[0116] In some examples, the switch request may be sent via an RLC control PDU (e.g., an RLC status PDU). In some examples (e.g., legacy RLC), the status report may be applicable to (e.g., only to) the AM mode. In some examples, the status report may be implemented / utilized for the UM mode. The status report (e.g., for the UM mode) may be triggered, for example, when the WTRU decides to switch from the PTM mode to the PTP mode.

[0117] In some examples, a MAC Control element (eg, a new MAC Control element) or an information element within an existing MAC Control element (eg, a new information element) may be used by the WTRU to request a MBS mode switch.

[0118] In some examples, the WTRU may transmit a switch request to request a switch from PTP to PTM (e.g., see 318 in FIG. 3). The WTRU may request a switch to PTM mode, for example, if one or more of the following conditions are true (e.g., see 316 in FIG. 3): there are no HARQ retransmissions for an amount of time (e.g., a threshold amount of time), which may be configured by the network, or the signal level of the serving cell is above a threshold (e.g., a configurable threshold). The amount of time without HARQ retransmissions (e.g., based on a threshold, criteria, and / or other trigger(s)) may occur, for example, if the number of successful decodings of initial transmissions of transport blocks associated with the MBS within a time window is above a threshold. In some examples, the criteria may be if the number of ACKs transmitted within the time window is above a threshold or if the number of NACKs transmitted within the time window is below a threshold. In some examples, the WTRU may decide to switch from PTP mode to PTM mode (e.g., 318 of FIG. 3 may not be performed) without sending a request to the network (e.g., 306 of FIG. 3), e.g., based on (e.g., based only on) the WTRU detecting that PTM operation is reliable / meets one or more conditions described herein.

[0119] Examples described herein and variations thereof may be implemented. In examples, receipt of an indication while the WTRU's MBS is operating in PTM mode may be interpreted by the network as a request by the WTRU to switch to PTP. Receipt of an indication while the WTRU's MBS is operating in PTP may be interpreted as a request to switch to PTM. In some examples, information about the switch may be indicated (e.g., explicitly). For example, a Boolean field / flag may be included to indicate a switch from PTP to PTM if the field / flag value is 0, or to indicate a switch from PTM to PTP if the field / flag value is 1 (or vice versa).

[0120] The switch (e.g., MBS mode switching) may be implicit (e.g., see 313 and 319 in FIG. 3). In some examples (e.g., see 319 in FIG. 3), a WTRU operating in PTP may determine (e.g., consider or assume) that the MBS mode is switched from PTP to PTM, e.g., in response to receiving, e.g., via an RLC entity, an RLC PDU associated with the PTM mode. In some examples (e.g., see 313 in FIG. 3), a WTRU operating in PTM may determine (e.g., consider or assume) that the MBS mode is switched from PTM to PTP, e.g., in response to receiving, e.g., via an RLC entity, an RLC PDU associated with the PTP mode. The MBS mode switch may affect (e.g., only affect) the MRB associated with the received PDU (e.g., the MRB to which the received PDU belongs), and the operation modes of other MRBs may not be affected (e.g., the other MRBs may remain in PTP mode if they are operating in PTP mode, or may remain in PTM mode if they are operating in PTM mode). The MBS mode switch may affect multiple MRBs (e.g., all MRBs). The MBS mode switch may affect MRBs (e.g., all MRBs) associated with the same G-RNTI as the MRB to which the received PDU belongs.

[0121] Some examples may be based on a timer. In some examples, the WTRU may be configured with a time period (e.g., a timer that may be a t_switching timer). The time period (e.g., a timer) may be started, for example, in response to receiving an RLC PDU (e.g., a first RLC PDU) via an RLC entity associated with the PTM mode. PDUs received with a lower SN than the SN of the first received RLC PDU may be forwarded (e.g., immediately) to the PDCP layer (e.g., instead of being erased) during the time period (e.g., if the timer is running). The PTM RLC may operate (e.g., start operating) in a UM mode (e.g., normal UM mode) and may erase PDUs that are outside the reception window, for example, if the time period has elapsed (e.g., the timer has expired).

[0122] An extended window mode may be provided (e.g., configured, implemented, executed). The WTRU may operate / configured to operate in the extended window mode. The WTRU (e.g., operating in the extended window mode) may maintain a larger receiving window than the receiving window in normal operation (e.g., in the normal mode). The normal mode and the extended window mode may refer to the first and second modes and may be used interchangeably therewith, or vice versa. The extended window may be determined, for example, by using one or more offset values ​​(e.g., preconfigured value(s), such as half the receiving window size) (e.g., see 320 in FIG. 3). For example, a first offset may be applied to the left edge of the window and a second offset may be applied to the right edge of the window. The receiving window size may be extended, for example, by the first offset + the second offset. The WTRU may be configured, for example, to place a received PDU in a receiving buffer if the SN of the received PDU is within the extended window. The WTRU may be configured, for example, to erase a PDU if the SN of the received PDU is not within the extended window.

[0123] The WTRU may be configured to operate in (e.g., apply) the extended window mode (e.g., see 320 in FIG. 3) based on, for example, one or more of the following conditions: when a PTP to PTM switch is triggered (e.g., see 318 in FIG. 3), during a period of time (e.g., when a timer (e.g., t_switching timer) is running), when an MBS bearer is associated with multiple (e.g., two) configured and / or activated RLC entities (e.g., a PTM RLC and a PTP RLC), and / or in response to an indication (e.g., explicit indication) from the network (e.g., 306 in FIG. 3), which may be via a DCI, a MAC CE, and / or an RRC (e.g., see 319 in FIG. 3). The indication (e.g., explicit indication) may activate or deactivate the operation.

[0124] A windowless RLC mode may be provided (e.g., configured, implemented, performed). In some examples, the WTRU may be configured to perform data reception for MBS services, e.g., using an RLC entity in an RLC mode. For example, the RLC mode may be a windowless mode. The windowless RLC entity may perform one or more of the following: reconstructing an RLC SDU from a received UMD PDU (e.g., in response to an RLC SDU being available) or delivering an RLC SDU to upper layers. An RLC entity operating in a windowless mode may, for example, deliver an RLC SDU to upper / upper layer(s) even if the PDU is outside the RLC reception window. In some examples, the windowless mode may be implemented (e.g., modeled) as a transparent mode for delivery of PDUs to upper layer(s) and / or an RLC function that behaves like a UM mode for handling reassembly and PDU processing.

[0125] In some examples, the windowless mode may be implemented by disabling the PDU clearing function.

[0126] In some examples, the windowless RLC mode may be implemented (e.g., modeled) by invalidating an RLC window associated with a UM RLC entity. The invalidation may be triggered, for example, by one or more of a PTP to PTM switch, a network command (e.g., an explicit network command), in response to receiving a PDU delivered based on scheduling via the GRNTI, etc.

[0127] The WTRU may be configured, for example, to apply the windowless RLC mode during a certain period of time (e.g., when a timer, which may be a t_switching timer, is running). The WTRU may be configured, for example, to apply the windowless RLC mode when an MBS bearer is configured. The WTRU may apply the windowless mode, for example, when an MBS bearer is associated with multiple (e.g., two) configured and / or activated RLC entities (e.g., a PTM RLC and a PTP RLC).

[0128] Windowless operation may result in duplicate PDUs being delivered to the PDCP layer. The duplicate PDUs may be eliminated at the PDCP layer, for example, via a duplicate detection function. The WTRU may apply the windowless mode in response to an indication (e.g., an explicit indication) from the network, which may be, for example, via a DCI, MAC CE, or RRC. The indication (e.g., an explicit indication) may activate or deactivate the operation.

[0129] Cell level switching may be provided (e.g., configured, implemented, performed). The cell level switching may include switching WTRUs (e.g., all WTRUs) involved in the MBS session from PTM to PTP, which may be done simultaneously. A flag / IE / indicator (e.g., indicating cell level switching) may be provided in the RLC header. The flag / IE / indicator (e.g., indicating cell level switching) may be included in an RLC packet (e.g., the first RLC packet) sent from the network, e.g., after cell level switching to PTM operation. The WTRU may receive a packet including an RLC header. The WTRU may, e.g., in response to receiving the packet including the RLC header, set the SN of the received packet as the start of the receive window for the PTM RLC. PDUs (e.g., if any) received before the PDU including the indicator may be forwarded to the PDCP layer.

[0130] In some examples, an RLC PDU that includes an indicator (e.g., indicating cell-level switching) may be lost (e.g., HARQ retransmission(s) may not be able to retrieve the MAC PDU that includes the RLC PDU). For example, a period (e.g., a timer) may be implemented to avoid cases where the WTRU waits for a PDU with an indicator that may never arrive. For example, the WTRU may start a timer (e.g., a t_switching timer) in response to receiving a first RLC PDU, e.g., after switching to a PTM mode. The WTRU may store the SN (e.g., first_SN) of the first received RLC PDU. If a PDU with the indicator is received during the period (e.g., when the timer is running), the WTRU may start a UM RLC state variable for the SN of the PDU, may stop the timer, and / or may pass the PDU to the PDCP layer and start operating in normal UM mode. If a PDU with the indicator is not received during the period (e.g., when the timer is running), the WTRU may pass a PDU without the indicator to the PDCP layer. The WTRU may initiate UM RLC state variables for first_SN and / or may operate (e.g., start operating) in normal UM mode, for example, if the time period is out (e.g., a timer has expired).

[0131] In some examples, the network may indicate to one or more WTRUs (e.g., all WTRUs) in a cell to switch MBS operation from PTM to PTP (or vice versa) (e.g., via an indication in system information).

[0132] An explicit switch may be provided (e.g., configured, implemented, performed) (e.g., see 313 and 319 in FIG. 3). The explicit switch may be implemented, for example, via an RRC reconfiguration. In some examples, the WTRU may switch to PTM mode in response to receiving an RRC reconfiguration message. The RRC reconfiguration message may include information regarding UM state variable(s), such as RX_next_reassambly and / or RX_next_highest. The WTRU may initiate a PTM RLC entity, for example, based on the RRC reconfiguration message to switch to PTM mode. The RRC reconfiguration message may include information regarding multiple MRBs.

[0133] In some examples, an information element (IE) may be included in the RLC UM configuration. The IE may indicate (e.g., specify) an initial SN that may be used for UM state variables, for example, as shown by the example in Table 1.

[0134] The RRC reconfiguration message may include a cellGroupConfig, which may include a list of RLC bearers (e.g., rlc-Bearers) to be added to the rlc-BearerToAddModList. The rlc-BearerConfig (e.g., each rlc-BearerConfig) may include the configuration of the RLC entity (e.g., in addition to other related configurations linking the RLC entity with the PDCP entity and MAC logical channels).

[0135] The CellGroupConfig IE may be used to configure a master cell group (MCG) or a secondary cell group (SCG). A cell group may include, for example, a MAC entity (e.g., one MAC entity), a set of logical channels (e.g., with associated RLC entities), a primary cell (e.g., a primary cell (SPCell) of a master or secondary cell group), and / or one or more secondary cells (SCells). Table 1 shows an example of a Cell Group Configuration IE.

[0136] [Table 1]

[0137] The RLC-BearerConfig IE may be used to configure the link to the RLC entity, the corresponding logical channel in the MAC and / or the PDCP entity (e.g., the served radio bearer). Table 2 shows an example of the RLC Bearer Configuration IE.

[0138] [Table 2]

[0139] The RLC-Config IE may be used to specify the RLC configuration of the SRB and / or the DRB. Table 3 shows an example of the RLC Configuration IE.

[0140] [Table 3-1]

[0141] [Table 3-2]

[0142] [Table 3-3]

[0143] In some examples, the WTRU may switch to the PTP mode, for example, in response to receiving an RRC reconfiguration message.

[0144] In some examples, the WTRU may receive an MBS configuration (e.g., an explicit MBS configuration) that may be associated with a target cell during a mobility event. For example, the MBS configuration may be associated with one or more of an RRC reconfiguration with synchronization, a conditional RRC reconfiguration, etc. For example, the WTRU may be configured with an MBS mode of the target cell, which may differ from the source cell. The WTRU may perform one or more actions (e.g., as described herein) based on, for example, the MBS mode configuration of the target cell relative to the source cell.

[0145] The WTRU may be configured with behavior(s) / action(s) (e.g., additional behavior(s) / action(s)) based, for example, on a relationship between the MBS mode configuration at the source and the MBS mode configuration at the target (e.g., one compared to the other). The WTRU may be configured to send a PDCP status report to the target, for example, when switching from PTM mode at the source to PTP mode at the target. The WTRU may be configured to send a PDCP status report to the target, for example, when configured in PTP mode at the target (e.g., regardless of MBS mode at the source). The WTRU may be configured to send an indication of MBS mode switching to the target, for example, based on one or more conditions for MBS mode switching (e.g., as described herein).

[0146] Explicit switching via a MAC Control element may be provided (e.g., configured, implemented, performed). In some examples, the network may send a MAC CE to the WTRU, for example, when the network determines that it indicates (e.g., wants the WTRU to) switch MBS operation from PTP mode to PTM mode. The MAC CE configuration may include one or more of information regarding which MRB the MAC CE refers to (e.g., bearer ID, logical channel ID, G-RNTI, etc.) or information regarding the SN used to initialize the PTM RLC state variables.

[0147] In some examples, the MAC CE may include information about one or more (e.g., a plurality of, several) MRBs (e.g., a list including information, e.g., as described herein, for each of a plurality of MRBs).

[0148] In some examples, the MAC CE may include an identity associated with the MBS service / session. For example, the MAC CE may include a temporary mobile group identity (TMGI) associated with the MBS service. For example, the MAC CE may include a G-RNTI associated with the MBS service.

[0149] In some examples, a MAC CE without information about an MRB may be considered (e.g., may be interpreted) as an indication that the information is applicable to multiple MRBs (e.g., all MRBs) and / or MBS services (all MBS services).

[0150] Explicit switching via DCI may be provided (e.g., configured, implemented, performed). In some examples, the network may send a DCI to the WTRU, for example, when the network determines that it indicates to the WTRU (e.g., wants the WTRU to switch MBS operation from PTP mode to PTM mode). The DCI configuration may include one or more of information regarding which MRB the DCI refers to (e.g., bearer ID, logical channel ID, G-RNTI, etc.) or information regarding the SN used to initialize the PTM RLC state variables. The information regarding which MRB the DCI refers to may be implicit or explicit. For example, in case of implicit information, the reception of the DCI in a PDCCH transmission may be associated with a G-RNTI, and the associated G-RNTI may identify the associated MRB(s).

[0151] A PDCCH transmission monitoring behavior for MBS mode switching may be provided (e.g., configured, implemented, executed). In some examples, the WTRU may start monitoring transmission(s) on the PDCCH for a C-RNTI, for example, in response to receiving a mode switch command indicating a switch from PTM to PTP (e.g., via an RRC reconfiguration message, MAC CE, DCI, etc., as described herein) or in response to transmitting an MBS mode switch request indicating a request to switch from PTM to PTP.

[0152] The WTRU may apply a control resource set (CORESET) and / or search space configuration associated with the C-RNTI (eg, if configured).

[0153] In some examples, the WTRU may stop monitoring transmission(s) on the PDCCH for the G-RNTI associated with the MRB(s), e.g., in response to receiving a mode switch command indicating a switch from PTM to PTP (e.g., via an RRC reconfiguration message, MAC CE, DCI, etc., as described herein) or in response to transmitting an MBS mode switch request indicating a request to switch from PTM to PTP.

[0154] In some examples, the WTRU may begin monitoring transmission(s) on the PDCCH for the G-RNTI associated with the MRB(s), e.g., in response to receiving a mode switch command indicating a switch from PTP to PTM (e.g., via an RRC reconfiguration message, MAC CE, DCI, etc., as described herein) or in response to transmitting an MBS mode switch request indicating a request to switch from PTP to PTM.

[0155] The WTRU may apply the CORESET and / or search space configuration information associated with the G-RNTI (e.g., if configured). The WTRU may (e.g., otherwise) monitor the transmission(s) in the PDCCH for search space configuration information associated with the G-RNTI and / or C-RNTI in the CORESET.

[0156] In some examples, the WTRU may stop monitoring transmission(s) on the PDCCH for the C-RNTI, for example, in response to receiving a mode switch command indicating a switch from PTP to PTM (e.g., via an RRC reconfiguration message, MAC CE, DCI, etc., as described herein) or in response to sending an MBS mode switch request indicating a request to switch from PTP to PTM.

[0157] Although the above-described features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or may be used in various combinations with or without the other features and elements.

[0158] Although the implementations described herein may take into account 3GPP specific protocols, it is understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein take into account LTE, LTE-A, new radio (NR), or 5G specific protocols, it is understood that the solutions described herein are not limited to this scenario and may also be applicable to other wireless systems.

[0159] The above described processes may be implemented in a computer program, software, and / or firmware embodied in a computer readable medium for execution by a computer and / or a processor. Examples of computer readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, an RNC, and / or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: receiving an instruction to switch from a first transmission mode to a second transmission mode; switching from the first transmission mode to the second transmission mode based on the instruction; Expanding a data packet receiving window by expanding a boundary of the data packet receiving window, the boundary being expanded by an offset; Receive a data packet, adding the data packet to a receive buffer for processing, said adding being based on the SN of the data packet being within the extended portion of the extended data packet receive window. A WTRU comprising a processor configured to:

2. the first transmission mode is associated with a first RNTI and the second transmission mode is associated with a second RNTI, and the processor monitoring for a PDCCH transmission via use of the second RNTI based on the switching from the first transmission mode to the second transmission mode. The WTRU of claim 1 , further configured to:

3. 3. The WTRU of claim 2, wherein the boundary of the data packet receiving window is a starting edge of the data packet receiving window, and extending the boundary of the data packet receiving window includes setting a first value of the starting edge to a second value that is lower than a sequence number (SN) associated with received data by the offset.

4. The WTRU of claim 3 , wherein the extended portion of the extended data packet receiving window is a portion of the extended data packet receiving window that starts at the second value and ends at the SN.

5. The WTRU of claim 1 , wherein the first transmission mode is a point-to-point (PTP) transmission mode and the second transmission mode is a point-to-multipoint (PTM) transmission mode.

6. The WTRU of claim 5 , wherein the indication is based on receipt of a Radio Link Control (RLC) data packet via an RLC entity associated with the PTM transmission mode, and the WTRU is operating in the PTP transmission mode.

7. The processor, Receives G-RNTI; determining, based on the reception of the G-RNTI, that the WTRU is authorized to participate in multicast operations; The WTRU of claim 2 , further configured to:

8. The WTRU of claim 1 , wherein the boundaries of the data packet reception window are extended based on state variables, the state variables including RX_next_reassembly and RX_next_highest.

9. The WTRU of claim 8 , wherein RX_next_reassembly and RX_next_highest are received in a message, and the indication to switch from the first transmission mode to the second transmission mode is indicated via the message.

10. The WTRU of claim 9 , wherein the message is an RRC reconfiguration message.

11. 1. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving an instruction to switch from a first transmission mode to a second transmission mode; switching from the first transmission mode to the second transmission mode based on the instruction; Expanding a data packet receiving window by expanding a boundary of the data packet receiving window, the boundary being expanded based on an offset; and Receiving a data packet; adding the data packet to a receive buffer for processing, the adding being based on the data packet's SN being within an extended portion of the extended data packet receive window; A method comprising:

12. The first transmission mode is associated with a first RNTI and the second transmission mode is associated with a second RNTI, and the method further comprises: monitoring for a PDCCH transmission via use of the second RNTI based on the switching from the first transmission mode to the second transmission mode; The method of claim 11 further comprising:

13. 13. The method of claim 12, wherein the boundary of the data packet receiving window is a starting edge of the data packet receiving window, and extending the boundary of the data packet receiving window includes setting a first value of the starting edge to a second value that is lower than a sequence number (SN) associated with received data by the offset.

14. 14. The method of claim 13, wherein the extended portion of the extended data packet receiving window is a portion of the extended data packet receiving window that begins at the second value and ends at the SN.

15. 12. The method of claim 11, wherein the first transmission mode is a point-to-point (PTP) transmission mode and the second transmission mode is a point-to-multipoint (PTM) transmission mode.

16. 16. The method of claim 15, wherein the indication is based on receiving a radio link control (RLC) data packet via an RLC entity associated with the PTM transmission mode, and the WTRU is operating in the PTP transmission mode.

17. The method comprises: Receiving a G-RNTI; and determining, based on the reception of the G-RNTI, that the WTRU is authorized to participate in multicast operations; The method of claim 11 further comprising:

18. The method of claim 11 , wherein the boundaries of the data packet receiving window are expanded based on state variables, the state variables including RX_next_reassembly and RX_next_highest.

19. 20. The method of claim 18, wherein RX_next_reassembly and RX_next_highest are received in a message, and the indication to switch from the first transmission mode to the second transmission mode is indicated via the message.

20. 20. The method of claim 19, wherein the message is an RRC reconfiguration message.

Images