Lossless switching between PTP transmission / reception and PTM transmission / 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 on January 11, 2021, the disclosure of which is incorporated herein by reference in its entirety.

Background Art

[0002] Mobile communication using wireless communication has been continuously evolving. The fifth generation of mobile communication radio access technology (RAT) can be referred to as the new radio (NR) of 5G. Previous (conventional) generations of mobile communication RAT can be, for example, the fourth generation (4G) long - term evolution (LTE).

Summary of the Invention

[0003] For example, systems, methods, and means relating to 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) can receive instructions to switch from the use of point-to-point (PTP) transmission (e.g., from PTP transmission mode) to the use of point-to-multipoint (PTM) transmission (e.g., to PTM transmission mode), or can decide to switch from the use of PTP transmission (e.g., from PTP transmission mode) to the use of PTM transmission (e.g., to PTM transmission mode) based on reliability conditions associated with the PTM mode. Based on the instructions or decision, the WTRU can switch from the use of PTP transmission (e.g., from PTP transmission mode) to the use of PTM transmission (e.g., to PTM transmission mode). The WTRU can receive a first data packet. A WTRU can extend its data packet receive window by extending the boundaries of the data packet receive window. The boundaries may be extended based on the sequence number (SN) and offset of the first data packet. In some examples, a WTRU can receive a second data packet and add it to the receive buffer for processing, and this addition may be based on the second SN of the second data packet being within the extended portion of the extended data packet receive window. In some examples, the boundary of the data packet receive window may be the beginning of the data packet receive window, and extending the boundary of the data packet receive window may involve setting the first value of the beginning to a second value that is offset lower than the SN of the first data packet. In some examples, the extended portion of the extended data packet receive window may be the portion of the extended data packet receive window that begins at the second value and ends at the SN of the first data packet.

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

[0005] A WTRU can trigger MBS mode switching(s) (based on instructions, such as instructions received from the network, or based on decisions made by the WTRU), as illustrated in the example in Figure 3. A WTRU (see, e.g., 304 in Figure 3) may be configured for MBS and may be configured with one or more multicast radio bearers (MRBs) (see, e.g., 308 in Figure 3). A WTRU can receive configuration information from the network (see, e.g., 306 in Figure 3), which may include parameters / thresholds (e.g., to be used) for triggering MBS mode switching. Parameters / thresholds may include signal level / thresholds related to the serving cell (e.g., reference signal received power (RSRP) level / threshold, reference signal received quality (RSRQ) level / threshold, received signal to noise indicator (RSNI) level / threshold, etc.), HARQ failure / success rate level / threshold, MRB level / threshold), etc. The WTRU can monitor the performance of the MBS operation (according to the configuration information or WTRU implementation). The WTRU can decide to switch the MBS mode. For example, the WTRU (for example, when operating in PTM mode) may decide to switch to PTP mode if, for example, the serving cell signal level falls below a threshold and / or the HARQ failure rate / retransmission count exceeds a threshold (see, for example, 310 in Figure 3). The WTRU may send an MBS mode switch request when it decides to switch the MBS mode, for example, from PTM to PTP or vice versa (see, for example, 312 in Figure 3).The request may include information such as a Packet Data Convergence Protocol (PDCP) / RLC receive status report and the affected MRBs (e.g., MRBs associated with the mode the WTRU is requesting to switch to). The PDCP / RLC receive status report may be sent separately from the request (e.g., see 314 in Figure 3). The WTRU may receive instructions from the network (e.g., see 306 in Figure 3) to switch from PTM to PTP (e.g., in 313 in response to 312, as shown in Figure 3). The WTRU may change its PDCCH transmit monitoring behavior before, during, or after sending an MBS mode switching request (e.g., monitor only C-RNTI, monitor only G-RNTI, or monitor both C-RNTI and G-RNTI).

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

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

[0008] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This figure shows an example of a protocol architecture. [Figure 3] This figure shows an example related to switching in MBS mode. [Modes for carrying out the invention]

[0009] References to a timer in this specification may refer to time, period, tracking time, tracking a period, etc. References to timer expiration in this specification may refer to determining that time has occurred or that a period has expired. References to a timer operating 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 radio transmit / receive unit (WTRU) may be configured to trigger an MBS mode switching request to the network (e.g., from PTP to PTM, or vice versa) depending, for example, the performance of the current MBS mode (e.g., considering radio link signal level, hybrid automatic repeat request (HARQ) failure / success rate, retransmission count, etc.). The WTRU may be configured to switch the MBS mode from PTP to PTM (e.g., implicitly) based on (e.g., accordingly) the reception of a packet data unit (PDU) via a radio link control (RLC) entity associated with a PTM. The WTRU may be configured to switch the MBS mode from PTM to PTP (e.g., implicitly) based on (e.g., accordingly) the reception of a PDU via an RLC entity associated with a PTP. The WTRU may be configured to modify the behavior of the RLC receiver (e.g., window size, start and end signal-to-noise ratios of the receiver window, PDU erase behavior, etc.) based on, for example, switching the MBS mode (e.g., implicitly). The WTRU can receive messages from the network (e.g., radio resource control (RRC) reconfiguration, medium access control (MAC) control element (CE), and / or downlink control information (DCI)), switch the MBS mode (e.g., from PTP to PTM, or vice versa), and / or set the RLC status parameters to those indicated in the message.WTRU can, for example, change the physical downlink control channel (PDCCH) monitoring behavior before, during, or after MBS mode switching (e.g., monitor only the cell radio network temporary identifier (C-RNTI), monitor only the group RNTI (G-RNTI), or monitor both C-RNTI and G-RNTI).

[0011] For example, systems, methods, and means relating to 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 transceiver unit (WTRU) can receive instructions to switch from the use of point-to-point (PTP) operation (e.g., from PTP transmit mode) to the use of point-to-multipoint (PTM) operation (e.g., to PTM transmit mode), or can decide to switch from the use of PTP operation (e.g., from PTP operating mode) to the use of PTM operation (e.g., to PTM transmit mode) based on reliability conditions associated with the PTM mode. Based on the instructions or decision, the WTRU can switch from the use of PTP operation (e.g., from PTP transmit mode) to the use of PTM operation (e.g., to PTM transmit mode). The WTRU can receive a first data packet. The WTRU can extend the data packet reception window by extending the boundary of the data packet reception window. The boundary may be extended based on the sequence number (SN) and offset of the first data packet. In some examples, a WTRU may receive a second data packet and add it to the receive buffer for processing, and this addition may be based on the second SN of the second data packet falling within the extended portion of the extended data packet receive window. In some examples, the boundary of the data packet receive window may be the beginning of the data packet receive window, and extending the boundary of the data packet receive window may involve setting the first value of the beginning to a second value that is offset lower than the SN of the first data packet. In some examples, the extended portion of the extended data packet receive window may be the portion of the extended data packet receive window that begins at the second value and ends at the SN of the first data packet.

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

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

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

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

[0016] Figure 1A shows an exemplary 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, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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 filtering OFDM, and filter bank multicarrier (FBMC).

[0017] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio 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 radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial radio networks, etc. WTRU102a, 102b, 102c, and 102d can all be referred to as UE for compatibility purposes.

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

[0019] Base station 114a may be part of 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), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectra, unlicensed spectra, or a combination of licensed and unlicensed spectra. Cells may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, the base station 114a may use multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0020] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio 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 described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA. For example, the base stations 114a within RAN 104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0022] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish air interface 116 using Long Term Evolution (LTE) and / or 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 can implement radio technologies such as NR radio access that can establish air interface 116 using New Radio (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, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by transmissions sent to / from multiple types of radio access technologies and / or 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 wireless technologies 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), etc.

[0026] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0027] RAN104 / 113 can communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 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 Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 / 113 or different RATs. For example, in addition to being connected to RAN104 / 113 which can utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0030] Figure 1B is a system diagram showing an exemplary WTRU102. As shown in Figure 1B, the WTRU102 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0031] The processor 118 may be a general-purpose processor, a dedicated 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 a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and 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) via 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, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0033] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize 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 radio signals via the air interface 116.

[0034] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0035] The processor 118 of the WTRU102 may be coupled to 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) and may receive user input from these. 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 any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. 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, and the like. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in such memory.

[0036] The processor 118 may receive power from the power supply 134, but may also be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0038] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, 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 peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0039] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., transmission) or downlink (e.g., reception)).

[0040] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0041] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

[0043] The CN106 shown in Figure 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 aforementioned elements is shown as part of CN106, 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 MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0045] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0046] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0047] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0049] In a typical 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 to or interfaces with another type of wired / wireless network that carries traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STA may reach and be delivered to the STA via the AP. Traffic originating from the STA to destinations outside the BSS may be sent to the AP and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via the AP; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, 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 Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

[0052] High-throughput (HT) STAs 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] Very High Throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels mentioned above may be formed by combining multiple consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data may pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to the media access control (MAC).

[0054] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier 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 the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, including support for specific and / or limited bandwidths (e.g., support only for that). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0055] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the 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 set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and 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 an STA (which only supports 1MHz operating mode) transmitting to the AP, a large portion of the frequency band may remain idle and could be considered busy, even if it were available.

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

[0057] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0058] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0059] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0060] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0061] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in 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 and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0062] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0063] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b can perform roles such as user authentication for WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 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 similar. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0064] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0065] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 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, and providing mobility anchoring.

[0066] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 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 one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0067] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0068] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or 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 network to test other devices in a communications 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 network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

[0069] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test laboratory test scenarios, and / or in undeployed (e.g., test) wired and / or wireless communication networks, to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by 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 (for example, to other wireless technologies). The term "network" may refer to one or more gNBs that can 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 a wireless network by several means, including, 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, for example, support broadcast / multicast services on a single cell. The broadcast / multicast area may be adjusted per cell (e.g., dynamically) according to user distribution. SC-PTM may forward broadcast / multicast services using downlink channels (e.g., LTE downlink shared channels such as PDSCH) which can be scheduled using RNTIs for groups of users (e.g., common RNTIs such as group-RNTIs). SC-PTM scheduling may be agile. Radio resources may be allocated (e.g., dynamically) in the time domain and / or frequency domain by PDCCH based on the Real-Time Traffic Load Transmission Time Interval (TTI) (e.g., in integer multiples of one or more symbols). SC-PTM may be applied, for example, when broadcast / multicast services are delivered (e.g., expected to be delivered) to a limited number of cells (e.g., due to user interest), and the cells may change (e.g., dynamically) (e.g., due to user movement). SC-PTM can enable efficient wireless use and / or flexible deployment in several applications, such as critical communications, traffic information for automobiles, and on-demand TV services.

[0073] MBSFN can arrange transmissions from different cells (e.g., to be identical and / or time-aligned) so that they appear as a single transmission from a WTRU perspective. Time synchronization between base stations (e.g., eNBs) can be enabled, for example, by an MBSFN synchronization area (concept). 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 MBMS transmissions. A multi-cell / multicast coordinating entity (MCE) may perform admission control, determine whether to use SC-PTM or MBSFN, suspend and resume for MBMS services, and / or similar. An MBMS gateway (MBMS-GW) may perform session control signaling, forward MBMS user data to the eNB (e.g., via IP multicast), and / or similar.

[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) bandwidth (BW), frequency domain resource allocation may not be supported, which can be inefficient in deployments with high bandwidth.

[0075] MBMS is sometimes referred to as MBS (Multicast and Broadcast Services) in newer radio (NR) technologies, for example. The terms MBMS and MBS can be used interchangeably.

[0076] A WTRU may be configured in transmit mode (e.g., if an MBS is configured). The transmit mode may include one or more transmission methods, such as unicast, multicast (e.g., SC-PTM), broadcast (e.g., SFN), and mixed mode (e.g., the WTRU can receive unicast, multicast, and / or broadcast). The transmit mode is not limited in scope and applicability (e.g., a transmit mode may be applicable to similar wireless distribution methods). One or more non-unicast modes may include receive-only mode (ROM). The transmit mode may include a sidelink interface (e.g., for direct inter-WTRU communication). The transmit mode may be used for the distribution of services with different quality of service (QoS), such as high-speed high-capacity (eMBB), ultra-high reliability and low-latency communication (URLLC), and / or MBS services. The transmit mode may be used for the distribution of services to one receiver (e.g., via unicast) or to 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 transmit mode may refer to the transmit mode of a WTRU (e.g., used to refer to the transmit mode of a WTRU).

[0077] A WTRU may be configured for the delivery (e.g., transmission) of MBMS data services. A WTRU may be configured to operate in transmit mode to exchange MBS-related data and / or control information (e.g., and / or other data and / or control information). A WTRU may be configured for the delivery of MBS services (e.g., further). For example, a WTRU may be configured for the mapping of data bearers and / or signaling bearers for configured transmission methods to exchange MBS-related data (e.g., L2 bearer configuration for MBS). In some examples, a WTRU may be configured for mixed-mode transmission (e.g., unicast and multicast) with the delivery of MBS data performed using multicast transmission and / or broadcast transmission (e.g., using only multicast) and / or other services transmitted via unicast (e.g., eMBB, URLLC). In some examples, a WTRU may be configured for mixed-mode transmission (e.g., unicast and multicast) with the delivery of MBS data performed using unicast (e.g., called point-to-point (PTP) transmission / mode) and / or multicast transmission (e.g., called 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 used in a variety of configurations 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 grids / utilities, television (TV) video and radio services in 5G (e.g., linear TV, live, smart TV, OTT (managed and over-the-top) content delivery, radio services), which may include video delivery, large peaks in concurrent consumption of OTT services via unicast media streams, and / or immersive 6DoF (six degrees of freedom) volume streaming, push services (e.g., advertising and weather forecasts), Ethernet broadcast / multicast for factory automation, extended reality, group games, 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. Changes in service may be triggered by, for example, one or more of the following: WTRU mobility, user activity, WTRU density, or link state. WTRU mobility can 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 can include different handover scenarios, such as one or more of the following: inter-area cell mobility within an eNB / MBS, inter-area cell mobility between eNBs / MBS, inter-area mobility between MBSs, inter-RAT mobility with a change in transmit mode, or inter-RAT mobility without a change in transmit mode. Changes triggered in service (e.g., due to WTRU mobility) may occur with or without lossy or lossless service continuity. One of the issues in WTRU mobility is enabling service continuity for idle / inactive WTRUs.

[0080] User activity (for example, as a trigger for change in a service) may include one or more of the following: user control over a media stream (e.g., a user may interact with playback functionality and have some control over the media stream), or end-user interaction with live or shared content via uplink channels 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 the 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 increase by changing the MBS transmission mode), or V2X proximity / WTRU range within the area. Link conditions (e.g., as a trigger for a change in the service) may include: different characteristics of resources between multicast and unicast transmissions to WTRUs (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 specific times of day; fluctuations / changes in on-demand MBS services (e.g., in services with uplink data support or with regard to higher reliability support); or target areas for group communications and live video may be based on specific areas or locations, or may be triggered by events, and areas may change (e.g., due to the mobility of interested users). Changes in MBS areas may lag behind (e.g., in terms of time scale) the adjustment of resources between unicast (UC) / multicast broadcast (MB) / broadcast (BC).

[0083] Transmission reliability can be implemented / improved (e.g., in NR). MBS services can support application-level retransmission. Application-level methods may have a trade-off between reliability and efficiency, which can be costly in terms of spectral 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 a sharp Doppler degradation, which can make it difficult to use MBS services in high-speed environments. For example, power grid distribution (e.g., in NR) may be implemented with a latency of 5ms and a packet error rate of 10⁻⁶. V2X (e.g., in NR) may be implemented with a latency of up to 20ms for information sharing between WTRUs and roadside units (RSUs). Mission-critical push-to-talk (MCPTT) (e.g., in NR) may be implemented with a latency of up to 300ms (e.g., for mouse-to-year latency).

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

[0085] The Radio Link Control (RLC) protocol can include a Layer 2 protocol between the Packet Data Convergence Protocol (PDCP) and the Media Access Control (MAC) protocol, facilitating data transfer between the two layers. RLC protocol functions (e.g., tasks) may include one or more of the following: That is, transferring upper-layer protocol data units (PDUs) in one of several (e.g., three) modes (e.g., acknowledged mode (AM), unacknowledged mode (UM), and transparent mode (TM)), error correction (e.g., through 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) can be implemented multiple times (e.g., twice) by, for example, concatenating an RLC SDU from a logical channel to an RLC PDU in the RLC layer, and by multiplexing an RLC PDU from a different logical channel to a MAC PDU in the MAC layer. The MAC PDU can carry information about the same data fields in the RLC and MAC(sub) headers. RLC concatenation may include input from MAC layer scheduling (e.g., interaction with MAC may be used to construct an RLC PDU of the appropriate size for each UL grant). RLC concatenation may be performed (e.g., within one scheduling cycle) 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 preprocessing without grant information (e.g., before receiving grant information). The inability to preprocess without grant information (e.g., before grant information is received) may limit very high data rates and low latency requirements (e.g., in NR). In some cases, the concatenation procedure may not occur at the NR RLC layer. The RLC may send a PDCP packet to the MAC in response to a header addition (for example, immediately). The MAC layer may concatenate / multiplex data from multiple RLC PDUs, for example, by sending the data over the air interface in response to the MAC layer receiving scheduling permission and transport block size (TBS) instructions.

[0087] RLC (e.g., LTE RLC) may have a reordering function. Reordering may be performed by a PDCP layer that may have a reordering function (e.g., in NR). Performing reordering by the PDCP layer can improve latency; for example, delivering out-of-order RLC packets to the PDCP layer can enable faster decoding of out-of-order packets.

[0088] RLC UM operation can use state variables, constants, and timers. A transmitting UM RLC entity (e.g., each transmitting UM RLC entity) can maintain a state variable called TX_Next (e.g., a UM transmit state variable). The TX_Next state variable can hold the value of SN that is assigned to the next (e.g., newly) generated unacknowledged response mode data (UMD) PDU having segments. TX_Next may be initially set to 0. TX_Next may be updated, for example, in response to a UM RLC entity transmitting a UMD PDU to a lower layer that may contain the last segment of an RLC SDU.

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

[0090] RX_Next_Reassembly (e.g., the UM receive status variable) may hold the earliest SN value that can be considered for reassembly (e.g., still). In some examples, RX_Next_Reassembly may be initially set to 0. In some examples (e.g., for groupcasts and broadcasts in NR sidelink communications), RX_Next_Reassembly may initially be set to the SN of the first received UMD PDU, which includes the SN. PDUs with lower SNs may be considered received and / or lost.

[0091] The RX_Timer_Trigger (e.g., the UM t-Reassembly state variable) can hold the value of SN following the SN that triggered (e.g., initiated) the t-Reassembly described herein.

[0092] RX_Next_Highest (e.g., the UM receive state variable) can hold the 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 groupcasts and broadcasts in NR sidelink communications), RX_Next_Highest may initially be set to the SN of the first received UMD PDU that contains the SN.

[0093] UM_Window_Size can be a constant. UM_Window_Size can be used by a receiving UM RLC entity to define the SN of a UMD SDU that can be received without causing the receive window to advance. 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 can be considered to be the SN between RLC_Next_Reassembly and RLC_Next_Reassembly+UM_Window_Size. RX_Next_Reassembly can be considered to be the left edge, start edge, or bottom edge of the RLC receive window. RX_Next_Reassembly+UM_Window_Size can be considered to be the right edge, end edge, or top edge of the RLC receive window.

[0094] t-Reassembly can be a timer. t-Reassembly may be used, for example, by the receiver of an AM RLC entity and the receiving UM RLC entity to detect RLC PDU loss at a lower layer. For example, if the first t-Reassembly is running, the second t-Reassembly does not need to be started. In some examples, only one t-Reassembly per RLC entity may be running at a time (e.g., 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, if the 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 variable, reconstruct the RLC SDU and transmit it to the upper layer, and start / stop t-Reassembly (for example, as necessary). The UM RLC receiving entity can update the state variable, discard the RLC SDU segment, and start t-Reassembly (for example, as necessary) if, for example, t-Reassembly expires.

[0097] The 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 the 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 the receive buffer. The receiving UM RLC entity, for example, if a byte segment with SN=x (e.g., all byte segments) is received, can reconstruct an RLC SDU from the byte segment with SN=x (e.g., all byte segments) (based on the UMD PDU with SN=x placed in the receive buffer), remove the RLC header, and propagate the reconstructed RLC SDU to the upper layer. The receiving UM RLC entity, for example, if x=RX_Next_Reassembly, can update RX_Next_Reassembly (e.g., based on the UMD PDU with SN=x placed in the receive buffer) to an SN of a first SN that is greater (e.g., >) than the (e.g., current) RX_Next_Reassembly that has not been reconstructed and has not been delivered to the upper layer.

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

[0100] A received UM RLC entity can stop and reset t-Reassembly if, for example, t-Reassembly is in progress and one or more of the following are true (for example, based on a UMD PDU with SN=x located in the receive buffer): RX_Timer_Trigger <= RX_Next_Reassembly, RX_Timer_Trigger is outside the reassembly window and 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 the received segments of the RLC SDU (for example, all received segments).

[0101] A received UM RLC entity may initiate t-Reassembly (for example, based on a UMD PDU with SN=x located in the receive buffer) and / or set RX_Timer_Trigger to RX_Next_Highest if, for example, t-Reassembly has not been executed (including, for example, if 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 the received segment of this RLC SDU (for example, all received segments).

[0102] The timer t-Reassembly may expire. A receiving UM RLC entity may update RX_Next_Reassembly (e.g., based on t-Reassembly expiration) to the SN of a first SN that is greater than or equal to (e.g., ≥) the unreassembled RX_Timer_Trigger, or erase segments (e.g., all segments) that have an SN less than (e.g., <) the updated RX_Next_Reassembly. A 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 if, for example, RX_Next_Highest > RX_Next_Reassembly + 1, and / 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 the received segment of the RLC SDU (e.g., all received segments).

[0103] In the MBS example, the WTRU may be able to participate in multicast if a session is initiated, or the WTRU may be able to initiate a session in PTP mode and then switch to PTM mode (e.g., later) due to mobility to a cell that supports PTM mode (e.g., PTM mode only) due to improved radio conditions, which may enable the WTRU to receive multicast sessions via the broadbeam used for PTM mode.

[0104] State variables(s) that control the RLC receive window (e.g., RX_Next_Reassembly and / or RX_Next_Highest) may be initialized (e.g., to 0) when a UM RLC entity is established. State variables(s) that control 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) in the case of NR sidelink groupcast / broadcast communication (e.g., because a WTRU can join a groupcast / broadcast after the session has started).

[0105] In the example of PTM mode, a WTRU can switch from PTP mode to PTM mode, or join an MBS session in PTM mode. State variables(s) can be initialized to the SN of the first received PDU in response to switching to PTM mode (e.g., PTM RLC mode). This technique may not be suitable for lossless switching to PTM mode, for example. For example, the first RLC PDUs that can be received (e.g., if switching to PTM mode after the session has started, or joining an MBS session in PTM mode) may be out of order, for example, having SN x. An RLC receiver can, for example, initialize the start of an RLC receive window to the SN of the first received PDU, and if missing RLC packets (e.g., RLC packets with SN xn) are received (e.g., later) out of order, it can erase the first received RLC PDU.

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

[0107] Methods for lossless switching of MBS operating modes are illustrated by examples (may be more) based on the transmission and / or delivery of MBS services. The methods described herein are not limited to the examples (may be more) (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, and industrial use cases. The methods described herein may be implemented individually or in combination (e.g., within any MBS system).

[0108] A WTRU (e.g., configured for receiving data for MBS) (see, for example, step 304 in Figure 3) may be configured with a data radio bearer (DRB) (e.g., a multicast radio bearer (MRB)), the DRB may be dedicated to MBS reception (see, for example, step 308 in Figure 3). The MBS service and the MRB may be considered the same (e.g., when described in terms of L2 and / or L3). The MBS service may consist of 0, 1 or more MRBs.

[0109] Multiple (e.g., several) QoS flows can be multiplexed within an MRB (e.g., similar to a DRB (e.g., a standard DRB)).

[0110] Figure 2 shows an example of a protocol architecture (see also step 302 in Figure 3). As shown in Figure 2 (and step 308 in Figure 3), the MRB may employ a split-bearer-like configuration having, for example, 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) can (for example, uniquely) identify the RRC connections of WTRUs within a cell. A Group RNTI (G-RNTI) can identify a group of WTRUs participating in multicast. A WTRU (for example, composed of an MRB according to the exemplary architecture shown in Figure 2) can monitor DL ​​scheduling for the MRB on the C-RNTI and / or G-RNTI. The method described herein can assume that the RLC entities associated with the PTM are operating in unacknowledged mode (UM) and the RLC entities associated with the PTP are operating in acknowledged mode (AM). The method disclosed herein may be applied to other operating modes (e.g., a PTM operating in transparent mode (TM) or AM, or a PTP operating in 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 types of switching (e.g., PTM to PTP). In the examples described herein, the terms left end, start end, and bottom end may be used interchangeably to indicate the start SN of the RLC receive window. In the examples described herein, the terms right end, end end, and top end may be used interchangeably to indicate the end SN of the RLC receive window. In some examples (e.g., legacy operation), it may be assumed that PDUs with SNs outside the RLC receive window may be dropped by the receiver.

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

[0114] In some cases (e.g., legacy operation), a PDCP status PDU may be transmitted for a DRB operating in AM during, for example, 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 also be transmitted during, for example, DAPS uplink data switching (e.g., only during that time) (e.g., in the case of a UM DRB). In some cases, a WTRU may transmit a PDCP status PDU for an MRB without meeting the legacy conditions for a PDCP status report (e.g., when the WTRU detects that PTM operation is degrading / meeting threshold conditions, such as being detected based on, for example, frequent (e.g., above threshold) HARQ failures / retransmissions, and / or serving cell signal levels falling below a certain threshold) (see, for example, 310 in Figure 3). The network (see, for example, 306 in Figure 3) may interpret a PDCP status report (e.g., sent without meeting legacy triggering conditions) as an implicit request from the WTRU to switch to MBS mode (see, for example, 313 in Figure 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., 306 in Figure 3) based on the WTRU's detection (e.g., based solely on) that the PTM operation is degraded / meets one or more threshold conditions described herein (e.g., 312 in Figure 3 may not be performed).

[0115] In some cases, flags / fields may be implemented / used in the PDCP status report to indicate (e.g., explicitly) a request to switch MBS modes.

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

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

[0118] In some cases, a WTRU can send a switching request to request a switch from PTP to PTM (see, e.g., 318 in Figure 3). A WTRU can request a switch to PTM mode if, for example, one or more of the following conditions are true (see, e.g., 316 in Figure 3): there are no HARQ retransmissions for a certain amount of time (e.g., a threshold time) that can be configured by the network, or the signal level of the serving cell exceeds a threshold (e.g., a configurable threshold). The amount of time without HARQ retransmissions (e.g., based on a threshold, criterion and / or other triggers) may occur, for example, when the number of successful decodings of initial transmissions of transport blocks associated with the MBS within a time window exceeds a threshold. In some cases, the criterion may be when the number of ACKs transmitted within a time window exceeds a threshold, or when the number of NACKs transmitted within a time window falls below a threshold. In some cases, the WTRU may decide to switch from PTP mode to PTM mode without sending a request to the network (e.g., 306 in Figure 3) based on, for example, the WTRU's detection that the PTM operation is reliable / meets one or more conditions described herein (e.g., based solely on that), (e.g., 318 in Figure 3 may not be performed).

[0119] Examples and variations thereof described herein may be implemented. In the examples, the reception of instructions while the WTRU's MBS is operating in PTM mode may be interpreted by the network as a request from the WTRU to switch to PTP. The reception of instructions 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, where the value of the field / flag is 0 to indicate a switch from PTP to PTM, or where the value of the field / flag is 1 to indicate a switch from PTM to PTP (or vice versa).

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

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

[0122] Extended window mode may be provided (e.g., configured, implemented, and run). The WTRU may operate / be configured to operate in extended window mode. A WTRU (e.g., operating in extended window mode) can maintain a larger receive window than the receive window in normal operation (e.g., in normal mode). Normal mode and extended window mode may refer to the first and second modes, and may be used interchangeably with each other, or vice versa. The extended window may be determined by using, for example, one or more offset values ​​(e.g., half the receive window size, or a pre-configured value(s)) (see, for example, 320 in Figure 3). For example, the first offset may be applied to the left edge of the window, and the second offset may be applied to the right edge of the window. The receive window size may be extended by, for example, the first offset + the second offset. The WTRU may be configured to place the received PDU into the receive buffer if, for example, the SN of the received PDU is within the extended window. The WTRU may be configured to erase a PDU, for example, if the received PDU's SN is not within the extended window.

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

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

[0125] In some cases, windowless mode can be implemented by disabling the PDU erase function.

[0126] In some examples, windowless RLC mode can be implemented (e.g., modeled) by disabling the RLC window associated with a UM RLC entity. Disabling can be triggered by one or more of the following: switching from PTP to PTM, network commands (e.g., explicit network commands), or in response to the receipt of a PDU delivered based on scheduling via GRNTI.

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

[0128] Windowless operation may result in duplicate PDUs being delivered to the PDCP layer. Duplicate PDUs can be erased at the PDCP layer, for example, through a duplicate detection function. WTRUs can apply windowless mode in response to instructions (e.g., explicit instructions) from the network, which can be via DCI, MAC CE, or RRC, for example. These instructions (e.g., explicit instructions) can activate or deactivate the operation.

[0129] Cell-level switching may be provided (e.g., configured, implemented, and performed). Cell-level switching may include switching WTRUs involved in an MBS session (e.g., all WTRUs) from PTM to PTP, which can 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 sent from the network (e.g., the first RLC packet) after, for example, cell-level switching to PTM operation. A WTRU may receive a packet containing the RLC header. In response to receiving a packet containing the RLC header, a WTRU may, for example, set the SN of the received packet as the start of the receive window for PTM RLC. Any PDUs received before the PDU containing the indicator (e.g., if any) may be forwarded to the PDCP layer.

[0130] In some cases, RLC PDUs containing indicators (e.g., cell-level switching) may be lost (e.g., HARQ retransmission(s) may fail to retrieve the MAC PDU containing the RLC PDU). For example, a period (e.g., a timer) can be implemented to avoid the case where a WTRU waits for a PDU with an indicator that may not arrive. For example, a WTRU may start a timer (e.g., t_switching timer) in response to the reception of a first RLC PDU, for example, after switching to PTM mode. The WTRU may store the SN (e.g., first_SN) of the first RLC PDU received. During the period (e.g., if the timer is running), if a PDU with an indicator is received, the WTRU may start a UM RLC state variable for the PDU's SN, stop the timer, and / or pass the PDU to the PDCP layer to start operating in normal UM mode. If no PDU with an indicator is received during the period (e.g., if the timer is running), the WTRU may pass a PDU without an indicator to the PDCP layer. WTRU can initiate the UM RLC state variable for first_SN and / or, if it is outside the period (e.g., the timer has expired), it can operate in normal UM mode (e.g., start operation).

[0131] In some cases, the network may indicate to one or more WTRUs within a cell (e.g., all WTRUs) that it wants to switch MBS operation from PTM to PTP (or vice versa) (e.g., via instructions in system information).

[0132] Explicit switching may be provided (e.g., configured, implemented, executed) (see, for example, Figures 313 and 319). Explicit switching can be implemented, for example, via RRC reconfiguration. In some examples, a WTRU can switch to PTM mode in response to receiving an RRC reconfiguration message. The RRC reconfiguration message may contain information about UM state variables such as RX_next_reassambly and / or RX_next_highest. A WTRU can initiate a PTM RLC entity based on the RRC reconfiguration message to switch to PTM mode, for example. The RRC reconfiguration message may contain information about multiple MRBs.

[0133] In some examples, information elements (IEs) may be included in the RLC UM configuration. IEs may indicate (e.g., specify) initial SNs that can be used for UM state variables, as shown in the example in Table 1.

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

[0135] The CellGroupConfig IE can 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., the 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 can be used to configure links between RLC entities, corresponding logical channels in MACs, and / or PDCP entities (e.g., served radio bearers). Table 2 shows an example of an RLC bearer configuration IE.

[0138] [Table 2]

[0139] The RLC-Config IE can be used to specify the RLC configuration for SRBs and / or DRBs. Table 3 shows an example of an RLC configuration IE.

[0140] [Table 3-1]

[0141] [Table 3-2]

[0142] [Table 3-3]

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

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

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

[0146] Explicit switching via MAC control elements may be provided (e.g., configured, implemented, and executed). In some examples, a network may send a MAC CE to a WTRU if it decides to indicate to the WTRU (e.g., to the WTRU) that it wants to switch the MBS operation from PTP mode to PTM mode. The MAC CE configuration may include one or more of the following: information about which MRB the MAC CE refers to (e.g., bearer ID, logical channel ID, G-RNTI, etc.) or information about the SN used to initialize the PTM RLC state variables.

[0147] In some examples, MAC CE may contain information about one or more (e.g., several) MRBs (e.g., a list containing information about each of several MRBs, such as that described herein).

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

[0149] In some cases, a MAC CE without information about an MRB could be interpreted (for example, understood) as indicating 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, and executed). In some examples, a network may send a DCI to a WTRU if it decides to indicate to the WTRU (e.g., to the WTRU) that it wants to switch the MBS operation from PTP mode to PTM mode. A DCI configuration may include one or more of the following: information about which MRB the DCI refers to (e.g., bearer ID, logical channel ID, G-RNTI, etc.), or information about the SN used to initialize the PTM RLC state variables. Information about which MRB the DCI refers to may be implicit or explicit. For example, in the case of implicit information, the reception of a DCI in a PDCCH transmission may be associated with a G-RNTI, and the associated G-RNTI may identify the associated MRB(s).

[0151] PDCCH transmit monitoring behavior for MBS mode switching can be provided (e.g., configured, implemented, and executed). In some examples, a WTRU may initiate monitoring of PDCCH transmits for C-RNTI, for example, in response to the receipt of a mode switching command indicating a switch from PTM to PTP (e.g., by the methods described herein, such as RRC reconfiguration messages, MAC CE, DCI, etc.) or in response to the transmission of an MBS mode switching request indicating a request for a switch from PTM to PTP.

[0152] WTRU can apply the control resource set (CORESET) and / or search space configuration associated with C-RNTI (if configured, for example).

[0153] In some cases, the WTRU may stop monitoring transmissions in the PDCCH for G-RNTI related to MRB(m)

[0154] In some cases, the WTRU may initiate monitoring of transmissions in the PDCCH for G-RNTI related to MRB(m)

[0155] The WTRU can apply CORESET and / or search space configuration information associated with G-RNTI (if configured). The WTRU can monitor (for example, separately) the transmission(s) within the PDCCH for search space configuration information associated with G-RNTI and / or C-RNTI within the CORESET.

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

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

[0158] While 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, while 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 be further applicable to other wireless systems.

[0159] The processes described above can be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via 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, internal hard disks, and removable disks, as well as magnetic media, magneto-optical media, and / or optical media such as compact discs (CD)-ROMs and / or digital versatile disks (DVDs). A processor associated with the software can be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transceiver unit (WTRU), Upon receiving an instruction to switch from the first transmission mode to the second transmission mode, Based on the above instruction, switch from the first transmission mode to the second transmission mode, The data packet reception window is extended by extending the boundary of the data packet reception window, and the boundary is extended by an offset. Receive data packets, The data packet is added to the receive buffer, and the addition is based on the fact that the signal-to-noise ratio (SN) of the data packet is within the extended portion of the extended data packet receive window. A WTRU equipped with a processor configured as such.

2. The first transmission mode is associated with the first RNTI, the second transmission mode is associated with the second RNTI, and the processor is Based on the switching from the first transmission mode to the second transmission mode, monitoring is performed for PDCCH transmission via the use of the second RNTI. The WTRU according to claim 1, further configured as follows.

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

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

5. The WTRU according to 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 according to claim 5, wherein the instruction is based on the reception 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 aforementioned processor, G-RNTI is received, Based on the reception of the G-RNTI, it is determined that the WTRU is permitted to participate in multicast operation. The WTRU according to claim 2, further configured as follows.

8. The WTRU according to claim 1, wherein the boundary of the data packet reception window is extended based on a state variable, the state variable includes RX_next_reassemblely and RX_next_highest.

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

10. The WTRU according to claim 9, wherein the message is an RRC reconstruction message.

11. A method performed by a wireless transceiver unit (WTRU), Receiving an instruction to switch from the first transmission mode to the second transmission mode, Based on the above instruction, the system switches from the first transmission mode to the second transmission mode, Extending the data packet reception window by extending the boundary of the data packet reception window, wherein the boundary is extended based on an offset. Receiving data packets and, The process involves adding the data packet to the receive buffer, wherein the addition is based on the fact that the signal-to-noise ratio (SN) of the data packet falls within the extended portion of the extended data packet receive window. A method that includes [a certain feature].

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

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

14. The method according to claim 13, wherein the extended portion of the extended data packet reception window is the portion of the extended data packet reception window that starts at the second value and ends at the SN.

15. The method according to 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. The method according to claim 15, wherein the instruction is based on receiving radio link control (RLC) data packets via an RLC entity associated with the PTM transmission mode, and the WTRU is operating in the PTP transmission mode.

17. The aforementioned method, Receiving G-RNTI and Based on the reception of the G-RNTI, it is determined that the WTRU is permitted to participate in multicast operation, The method according to claim 11, further comprising:

18. The method according to claim 11, wherein the boundary of the data packet reception window is extended based on a state variable, the state variable includes RX_next_reassemblely and RX_next_highest.

19. The method according to claim 18, wherein RX_next_reassemblely and RX_next_highest are received in a message, and the instruction to switch from the first transmission mode to the second transmission mode is indicated via the message.

20. The method according to claim 19, wherein the message is an RRC reconstruction message.

Images