Multicast and broadcast services reliability indication

Abstract

To provide reliability monitoring and indication for MBS.SOLUTION: A WTRU may receive an MBS configuration for an INACTIVE state. The MBS configuration and suspend configuration may be associated with different areas, e.g., MBS area versus RAN area. Configurations may indicate reliability indication triggers, a reliability metric configuration, and / or a reliability indication configuration. A WTRU, e.g., in INACTIVE, may receive an MBS transmission, e.g., on MRB(s), receive an MCCH, e.g., with trigger(s) for reliability indication during MCCH modification period, determine reliability metric(s) associated with MBS TB reception, monitor reliability metric(s) during time interval(s) for MCCH modification period(s), select RA resources, indicate a reliability metric, and / or monitor RAR format responsive to the reliability indication transmission.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 228,629, filed August 3, 2021, the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

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

[0003] SUMMARY Systems, methods, and means related to reliability indication for multicast and broadcast services (MBS) are described herein.

[0004] For example, as described herein, techniques related to reliability monitoring and / or reliability indication are disclosed (e.g., may be implemented by or in association with a wireless transmit / receive unit (WTRU)). The reliability indication may be an indication associated with transmission reliability, e.g., determined by the WTRU based on whether the WTRU receives transmission(s) (e.g., MBS transmission(s) such as MBS transport block(s)). The reliability indication may include or indicate a reliability indicator (e.g., a reliability metric) and / or a determined value and / or range of the reliability indicator. One or more of the following may apply:

[0005] The WTRU may receive MBS configuration information. The MBS configuration information may be associated with an INACTIVE state. For example, the MBS configuration information may be received in a message (e.g., an RRC message such as an RRC release message that includes a suspend configuration (e.g., SuspendConfig) indication, where SuspendConfig may be used as an example). The validity of the MBS configuration information and the SuspendConfig indication may be associated with different areas (e.g., logical areas), for example, the logical area may be a radio access network (RAN) area versus an MBS area. The MBS configuration information may include and / or indicate one or more of multicast radio bearer (MRB) configuration information for the INACTIVE state, one or more triggers for a reliability indication, a reliability metric setting, or a reliability indication setting.

[0006] The MRB configuration information for the INACTIVE state may be indicated using one or more of the following: The WTRU may, for example, suspend a point-to-point (PTP) leg and / or maintain a point-to-multipoint (PTM) leg for split MRBs if MBS reception is allowed in the INACTIVE state (e.g., conditional and / or under the conditions of entering the INACTIVE state). The WTRU may keep one or more MBS bearers active after entering the INACTIVE state. The WTRU may suspend other bearers (e.g., non-MBS bearers and / or MBS bearers different from the one or more MBS bearers configured to be active in INACTIVE).

[0007] The trigger for the reliability indication may be associated with one or more of the following: The trigger for the reliability indication may indicate whether the reliability monitoring and / or the reliability indication is periodic, event-triggered, polling-based, etc. The one or more triggers for the reliability indication may be indicated in, for example, polling configuration information, event-based configuration information, and / or periodic configuration information. The polling configuration information may be associated with a multicast control channel (MCCH). The polling configuration information associated with the MCCH may indicate to the WTRU, for example, with respect to a particular MBS service, to implement the reliability indication, for example, by signaling identification information associated with such MBS service. For example, the identification information may be indicated by a group radio network identifier (GRNTI) associated with the MBS service(s) for which the WTRU is expected to implement reliability monitoring. The event-based configuration information may indicate to implement the reliability indication, for example, when one or more thresholds associated with a reliability metric are met. The trigger for implementing the reliability indication may be indicated in a periodic configuration, for example, periodic configuration information may be received every n change periods (n may be a fraction or ≥ 1).

[0008] The reliability metric configuration information may be associated with one or more of the following: The reliability metric configuration information may include (e.g., indicate) a type of reliability metric, which may include one or more of, for example, a statistic associated with an MBS channel quality indicator (CQI) and / or a block error rate (BLER), a number of repetitions relative to an expected (e.g., total) number of transmissions within an MCCH modification period, etc.

[0009] The reliability indication configuration information may be associated with one or more of the following: The reliability indication configuration information may indicate one or more resources for the reliability indication, which may include, for example, one or more random access (RA) preambles, random access channel (RACH) opportunities (ROs) (e.g., associated with MCCH change boundaries), an association between (e.g., or a range of) RA resources and reliability metrics, etc.

[0010] The WTRU may enter the INACTIVE state, for example, based on a command from the network (e.g., when receiving an RRC release via suspendConfig). A WTRU (e.g., in the INACTIVE state) may receive MBS transmissions, for example, on one or more configured MRBs.

[0011] The WTRU may receive an MCCH transmission. The MCCH transmission may include or indicate a polling request for a reliability indication. The MCCH transmission may be received according to the GRNTI and / or may include a polling request. The MCCH transmission may be received during a time interval (e.g., an MCCH modification period n). Assistance information (e.g., additional assistance information) may be received for reliability monitoring. The assistance information may include, for example, an expected number of MBS transport blocks (TBs) within the modification period. Activation and / or deactivation of the periodic reliability indication may be received, for example, via a Medium Access Control (MAC) Control Element (CE).

[0012] The WTRU may determine one or more reliability metrics associated with a received MBS transmission (eg, an MBS TB reception in an INACTIVE state).

[0013] The WTRU may monitor one or more reliability metrics during a time interval, such as, for example, a time interval associated with an MCCH modification period (eg, MCCH modification period n+1).

[0014] The WTRU may determine a reliability indicator (e.g., a reliability metric) and / or a value and / or range of the reliability indicator (e.g., a reliability metric) based on a trigger condition being met, such as, for example, receiving a polling request or other condition described herein. The WTRU may select RA resource(s) based on, for example, the determined value and / or range of the reliability indicator (e.g., a reliability metric), e.g., based on an association and / or mapping between one or more pre-configured resources and the determined value and / or range of the reliability metric.

[0015] The WTRU may indicate (e.g., implicitly indicate) a reliability metric and / or a value and / or range of the reliability metric. For example, the WTRU may send a reliability indication via a selected preamble and RO (e.g., the reliability indication may include or indicate a reliability indicator (e.g., a reliability metric) and / or a determined value and / or range of the reliability indicator), where, for example, the selected preamble and RO may implicitly indicate the reliability metric.

[0016] The WTRU may monitor a random access response (RAR) format for a response associated with the reliability instruction transmission (e.g., the RAR format may be specific to the reliability instruction transmission). The RAR format (e.g., a response in the RAR format) may include, for example, one or more of an indication of whether the WTRU should perform a subsequent random access and resumption procedure, an indication of whether the WTRU should perform a two-step RA (e.g., to provide additional WTRU-specific information such as an inactive RNTI (I-RNTI) transmission), and / or an indication to return to and / or remain in an INACTIVE state.

[0017] FIG. 2 shows an example of reliability monitoring and reliability indication for an MBS. A common reference period may be used for reliability indication (e.g., by the network and the WTRU). The common reference period may include an MCCH modification period. The MCCH modification period may include multiple slots. FIG. 2 shows two MCCH modification periods: MCCH modification period n and MCCH modification period n+1. During MCCH modification period n, multiple MCCH transmissions may be transmitted (e.g., by the network). Some or all of the MCCH transmissions may include the same information (e.g., the same polling request). For example, an MCCH transmission may indicate the expected number of TBs to be transmitted (e.g., by the network) during the next MCCH modification period (e.g., MCCH modification period n+1). The WTRU may determine the number of TBs actually received and / or successfully decoded and use the expected number of TBs to be transmitted during the next MCCH modification period and the number of TBs actually received to determine the ratio of received TBs to transmitted TBs. The reliability index value may include a ratio. An MCCH transmission may be sent in (eg, each) MCCH repetition period.

[0018] The MCCH transmission may indicate a polling request. For example, (e.g., each) MCCH transmission may include a polling request (e.g., each MCCH transmission may include the same polling request). The WTRU may or may not successfully decode the MCCH transmission indicating a polling request. If the WTRU successfully decodes the MCCH transmission, the WTRU may be triggered to measure one or more values ​​of a reliability indicator based on receipt of the polling request. For example, the measurement of the one or more values ​​of the reliability indicator may be based on information included in the MCCH transmission. During the MCCH modification period n+1, multiple MCCH transmissions may be transmitted (e.g., by the network), for example, for each repetition period. The MCCH transmission transmitted during the MCCH modification period n+1 may include a polling request that, if successfully decoded, triggers measurement of one or more values ​​of the reliability indicator during the next MCCH modification period (e.g., MCCH modification period n+2). The WTRU may determine a PRACH resource for transmitting the preamble based on the determined value of the reliability indicator. As shown in FIG. 2, after MCCH modification period n+1, the value of the reliability indicator may be indicated by transmitting a preamble using the determined PRACH resource.

[0019] As an example, in the RRC CONNECTED state, the WTRU may be configured to receive an MBS configuration associated with the RRC INACTIVE state. The MBS configuration may include one or more triggers for reliability indication, a mapping between a reliability metric range and UL resources for the reliability metric indication. Upon entering the RRC INACTIVE state, the WTRU may suspend the PTP leg (if any) and start or continue the PTM leg for the MBS service. The WTRU may monitor one or more triggers for the reliability indication, for example, via a GRNTI. The WTRU may receive an MCCH transmission with a polling request for reliability indication during the MCCH modification period n. The polling request may be associated with a particular MBS bearer and may provide assistance information, for example, the number of MBS transport blocks within the modification period n+1. The WTRU may determine a reliability metric during a time interval associated with the MCCH modification period n+1; for example, the reliability metric may be the ratio of the number of successfully received MBS transport blocks to the total number of MBS transport blocks transmitted within the modification period. The WTRU may determine RA resources applicable to the reliability indication as a function of the reliability metric value. The WTRU may transmit an RA preamble on the determined RA resources. The WTRU may monitor the RAR format associated with the reliability indication. Upon receiving an RAR that matches the reliability indication, the WTRU may perform one or more of the following actions based on the received RAR: perform another RA procedure to initiate a resumption procedure or remain in RRC INACTIVE to receive the MBS service.

[0020] The WTRU may be configured to receive RAN paging with reliable polling (e.g., instead of MCCH polling).

[0021] The WTRU may be configured to initiate a transition from INACTIVE to CONNECTED based on, for example, the value and / or range of the reliability metric falling below a threshold.

[0022] The reliability monitoring may be performed on a shorter time scale, for example, based on a duration that may be tracked (e.g., via a timer). In an example, the shorter time scale may be a time that is shorter than the length of a modification period (e.g., an MCCH modification period). For example, the duration may be tracked (e.g., a timer may be started) if / when the WTRU receives a poll. The WTRU may send a reliability indication on the earliest RO, for example, based on expiration of the duration (e.g., expiration of the timer). [Brief explanation of the drawings]

[0023] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 shows an example of reliability monitoring and reliability indication for an MBS. [Figure 3] 1 illustrates an example of an RRC resume request procedure. [Figure 4] 1 illustrates an example of an MRB having a split bearer protocol architecture. DETAILED DESCRIPTION OF THE INVENTION

[0024]

[0003] Systems, methods, and means for multicast and broadcast service (MBS) reliability indication are described herein. A WTRU may receive an MBS configuration for an INACTIVE state (e.g., suspend point-to-point (PTP) and maintain point-to-multipoint (PTM) for a split multicast radio bearer (MRB). The MBS configuration and suspend configuration may be associated with different areas (e.g., an MBS area versus a radio access network (RAN) area). The configuration may indicate a reliability indication trigger (e.g., polling, event-based, periodic), a reliability metric configuration, and / or a reliability indication configuration. A WTRU (e.g., in INACTIVE) may, for example, receive MBS transmissions (e.g., on MRB(s)), receive a multicast control channel (MCCH) (e.g., via trigger(s) for reliability indication during MCCH modification period), determine reliability metric(s) associated with MBS transport block (TB) reception, monitor the reliability metric(s) during time interval(s) of the MCCH modification period(s), select random access (RA) resources (e.g., per mapping between resources and reliability metric values / ranges), indicate the reliability metric (e.g., transmit a reliability indication via a selected preamble and opportunity (RO) on a random access channel (or procedure) (RACH)), and / or monitor a random access response (RAR) format in response to the reliability indication transmission.

[0025] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), Zero-Tail Unique-Word DFT-Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multi Carrier (FBMC), etc.

[0026] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, Public Switched Telephone Network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

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

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

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

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

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

[0033] 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 jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

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

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

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

[0037] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which 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. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

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

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

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

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

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

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

[0045] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., Nickel-Cadmium (NiCd), Nickel-Zinc (NiZn), Nickel Metal Hydride (NiMH), Lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

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

[0048] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference 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, the WTRU 102 may include a half-duplex radio for transmission and reception of either some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

[0052] 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is illustrated as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

[0058] In a representative embodiment, the other network 112 may be a WLAN.

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

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

[0061] High Throughput (HT) STAs may use 40 MHz wide channels 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.

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

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

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

[0065] 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.

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

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

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

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

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

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

[0072] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 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.

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

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

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

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

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

[0078] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to perform 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 (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0079] The configuration(s) referred to herein, such as the configuration received at the WTRU, may refer to configuration information.

[0080] This specification is provided for illustrative purposes and does not limit the applicability of the methods described herein to other wireless technologies. The term network may refer to one or more base stations (e.g., gNBs) that may be associated with one or more transmission / reception points (TRPs) or any other node in a radio access network (RAN). One or more states (e.g., RRC states) referred to herein may refer to the operating condition(s) of a WTRU.

[0081] A WTRU may be configured to operate in a state (e.g., one of multiple states) that may be exemplified herein by an RRC state. Radio resource control (RRC) may have multiple states that may include an RRC INACTIVE state. A WTRU in the IDLE state may conserve its battery resources, for example, if the WTRU has not been active (e.g., no data has been transmitted or received) for a given period of time. In IDLE, the WTRU cannot continuously monitor the physical downlink control channel (PDCCH). Moving a WTRU back and forth between the CONNECTED and IDLE states may cause control plane signaling in the network, for example, if the WTRU's data is intermittent (e.g., if a smartphone frequently transmits small amounts of data). The signaling to transition the WTRU from the IDLE state to the CONNECTED state may involve the radio access network (e.g., gNB) and / or the core network (CN), for example, if the network does not have a WTRU context for the IDLE WTRU and / or does not know the (e.g., exact) location of the WTRU. The WTRU may be paged over the geographical area in which it is registered (e.g., the entire geographical area) (e.g., via gNBs / cells within the geographical area), for example, if the transition to the CONNECTED state is triggered by downlink (DL) data or an incoming voice call.

[0082] Frequent IDLE-to-CONNECTED transitions can have significant signaling overhead. The WTRU may have bearers that transmit data infrequently, but may be latency sensitive. Transitioning or placing the WTRU in the IDLE state may, in some cases, be ineffective, counterproductive, and / or otherwise undesirable if / when the WTRU is not actively (e.g., and frequently) transmitting or receiving data.

[0083] An intermediate state (e.g., in 5G) may be used, e.g., one example of an intermediate state may be referred to as an INACTIVE state (e.g., vice versa). A WTRU in the INACTIVE state may have power saving advantages, such as some of the power saving advantages associated with the IDLE state (e.g., not continuously monitoring the PDCCH), and may return to the CONNECTED state more quickly from the IDLE state. For example, an intermediate state (e.g., the INACTIVE state) may be implemented by releasing the WTRU connection while preserving the WTRU's context in the RAN and the WTRU without involving the CN (e.g., the CN may recognize a WTRU in the INACTIVE state in the same or similar manner as the CN recognizes a WTRU in the CONNECTED state).

[0084] The network may send an instruction to the WTRU to transition to the INACTIVE state, for example, by sending a message (e.g., an RRCRelease message) to the WTRU, which may include a suspend configuration (e.g., which may be referred to as suspendConfig). The suspendConfig may include, for example, one or more of a WTRU identifier (e.g., which may be used when resuming / resumeing the connection), a RAN area configuration, security information (e.g., which may be used to secure the resume procedure), or paging configuration (e.g., for paging from the RAN, which may be contrasted with paging from the CN for the IDLE state). The RAN area configuration may include, for example, a list of cells (e.g., physical cell ID (PCI)) or tracking area code, and / or a periodic RAN area update time / timer configuration. A WTRU in INACTIVE may perform cell reselection (e.g., in the same way as a WTRU in IDLE state performs reselection). The WTRU may monitor a paging channel, for example, using the configured RAN paging information.

[0085] The WTRU may initiate the resumption procedure, for example, by sending an RRCResumeRequest message, which may include the WTRU resumption identification and / or the reason for the connection resumption (e.g., mobile-originated voice call, mobile-originated video call, mobile-terminated call indicated by paging, emergency situation, RAN area update due to reselection outside the current RAN area, or expiration of a duration, e.g., timer expiration, etc.).

[0086] The network (e.g., in the case of a RAN area update) may signal (e.g., immediately send) the WTRU back to the INACTIVE state, for example, by sending an RRCRelease message, which may include, for example, a WTRU resumption identity (e.g., a new WTRU resumption identity), RAN area configuration, security, and / or paging configuration.

[0087] The network may (e.g., alternatively) send (e.g., respond to) an RRCResume message to, for example, indicate to the WTRU to resume the radio connection. Uplink and / or downlink (UL / DL) transmission may proceed (e.g., immediately thereafter), for example, as shown by the example of FIG. 3. The signaling shown in FIG. 3 may be compared to signaling for setting up a connection from an IDLE state (e.g., as previously described). Resumption from an INACTIVE state may save WTRU and network signaling. The CN may not be involved in the resumption. Latency may be avoided, for example, from the WTRU's perspective.

[0088] FIG. 3 illustrates an example of an RRC resume request procedure.

[0089] Multimedia broadcast multicast system (MBMS) services may be delivered over the air. MBMS services may be provided according to several methods, which may include, for example, one or more of unicast cellular (UC), multicast-broadcast single frequency network (MBSFN), and / or single cell point to multipoint (SC-PTM).

[0090] SC-PTM can support broadcast / multicast services on a single cell. The broadcast / multicast area can be adjusted (e.g., dynamically adjusted) for each cell, for example, according to user distribution. SC-PTM can transmit broadcast / multicast services using, for example, an LTE downlink shared channel (e.g., a physical downlink shared channel (PDSCH)), which can be scheduled using a common RNTI (e.g., group-RNTI) for a group of users. SC-PTM scheduling can be agile. Radio resources can be allocated (e.g., dynamically allocated) in the time and frequency domains by PDCCH signaling, for example, based on real-time traffic load (e.g., per transmission time interval (TTI)). SC-PTM can be suitable for scenarios in which broadcast / multicast services are distributed (e.g., expected to be distributed) to a limited number of cells, for example, due to user interest. The involved cells can change (e.g., dynamically change), for example, due to user mobility. SC-PTM may support (eg, enable) efficient radio utilization and / or flexible deployment for several applications (eg, critical communications, traffic information for automobiles, on-demand TV services, etc.).

[0091] An MBSFN may provide transmissions from different cells that are configured to be identical and / or time-aligned, e.g., so that the transmissions from different cells appear as a single transmission from the perspective of a WTRU. An MBSFN synchronization area may be defined, e.g., to enable time synchronization between eNBs. An MBSFN area may include a group of cells within an MBSFN synchronization area of ​​a network that may be coordinated to achieve MBSFN transmissions. An MBMS architecture may include (e.g., define) various logical entities for performing network functions applicable to MBMS transmissions. A multi-cell / multicast coordination entity (MCE) may perform admission control, decide whether to use SC-PTM or MBSFN, perform suspend and resume for MBMS services, etc. An MBMS gateway (MBMS-GW) may perform session control signaling and / or forward MBMS user data to the eNBs (e.g., via IP multicast).

[0092] MBMS may be implemented in wireless systems such as New Radio (NR). MBMS may also be referred to as Multicast and Broadcast Service (MBS). The terms MBMS and MBS may be used interchangeably herein.

[0093] The WTRU may be configured to operate according to a transmission mode (e.g., a WTRU configuration aspect), for example, if / when an MBS is configured. The transmission mode and other terms are described without limiting the scope or applicability to other (e.g., similar) wireless delivery methods. The transmission mode may include multiple transmission methods, such as unicast, multicast (e.g., SC-PTM), broadcast (e.g., SFN), and / or mixed mode (e.g., a WTRU may receive unicast and / or multicast or broadcast). Receive-only mode (ROM) may be a version (e.g., a special case) of a non-unicast mode. For example, a sidelink interface for direct WTRU-to-WTRU communication may be a version (e.g., a special case) of a transmission mode. The transmission modes may be used for delivery of services with different QoS, such as eMBB, URLLC, and / or MBS services. The transmission modes may be used for delivery of a service to one receiver (e.g., unicast) or to multiple receivers (e.g., multicast, groupcast, or broadcast). The services provided to multiple users may include, for example, vehicular communication (e.g., V2x) services (e.g., groupcast) and / or MBS services (e.g., multicast, broadcast). An MBS mode or an MBS transmission mode may refer to (e.g., may be used to refer to) a transmission mode of a WTRU.

[0094] The WTRU may be configured for delivery of MBS services (e.g., configuration aspects of the WTRU may be set for transmission of MBMS data services). Examples are provided without limiting the scope or applicability to similar delivery methods for MBS data and / or control information. The WTRU may be configured to operate in a transmit mode to exchange MBS-related data. The WTRU may have other (e.g., additional) configuration aspects for delivery of MBS services. Configurable aspects may include, for example, mapping of data (e.g., and / or signaling) bearers for the configured transmission method(s) to exchange MBS-related data (e.g., L2 bearer setup for MBS). For example, the WTRU may be configured for mixed-mode transmission (e.g., unicast and multicast), with delivery of MBS data performed using multicast and / or broadcast transmission (e.g., multicast and / or broadcast transmission only), and other services may be transmitted via unicast (e.g., eMBB, URLLC). For example, the WTRU may be configured for mixed mode transmission (e.g., unicast and multicast), with delivery of MBS data performed using unicast transmission (e.g., referred to as point-to-point (PTP) transmission / mode) and / or multicast transmission (e.g., referred to as point-to-multipoint (PTM) transmission / mode), regardless of whether the WTRU is active in other services (e.g., using unicast transmission, such as eMBB, URLLC, etc.).

[0095] An MBS (e.g., NR MBS) can support one or more of the following use cases: V2X, sidelink, and / or public safety (e.g., a 3GPP system may distribute information in a resource-efficient manner to a large number of WTRUs supporting V2X applications), Internet of Things (IoT) such as narrowband (NB) IoT and enhanced machine type communication (eMTC) devices (e.g., for software updates), and / or smart grid / utilities, TV video and radio services (e.g., in 5G), push services (e.g., advertising and / or weather forecasts), Ethernet broadcast / multicast (e.g., for factory automation), and / or augmented reality and / or group gaming. TV video and radio services supported by MBS may include, for example, one or more of linear TV, live, smart TV, managed and / or over-the-top (OTT) content distribution and / or radio services, video distribution (e.g., when multiple users watch the same live streaming at the same time), large peaks in simultaneous consumption of OTT services (e.g., via unicast media streams), and / or immersive six degrees of freedom (6DoF) volumetric streaming (e.g., much larger than traditional flat video or even 360-degree video).

[0096] MBS services may support application-level retransmissions. The tradeoff between reliability and efficiency offered by application-level methods may be costly (e.g., in terms of spectral efficiency). Application-level methods may not support lower latency requirements (e.g., may be insufficient to meet this requirement). Different MBS services may have different latency, efficiency, and reliability requirements. For example, power grid distribution may be implemented with a 5 ms delay and a 10-6 packet error rate. V2X may be implemented with a 20 ms latency for information sharing between WTRUs and road side units (RSUs). Mission-critical push-to-talk (MCPTT) may be implemented with a key performance indicator (KPI), such as a 300 ms mouth-to-ear latency.

[0097] WTRUs may be configured to receive MBS transmissions in the RRC INACTIVE state, for example, due to reduced power consumption and signaling overhead in the INACTIVE state. The network may not monitor and / or improve MBS service delivery to those WTRUs, for example, due to a lack of a tight control / feedback loop in the INACTIVE state (e.g., no UL communication while the WTRU is INACTIVE). The network (e.g., an NR network) may implement various MBS services with increased reliability compared to other (e.g., legacy) services over MBS. MBS performance may be improved. For example, improved reliability may be provided in an RRC state (e.g., other than the RRC CONNECTED state), such as the RRC INACTIVE state.

[0098] A radio technology / system (e.g., New Radio (NR)) may support multiple (e.g., two) distribution modes for MBS. For example, a first distribution mode (e.g., distribution mode 1) may provide high quality of service (QoS), e.g., in terms of reliability, latency, and / or other criteria. A second distribution mode (e.g., distribution mode 2) may provide lower QoS (e.g., compared to distribution mode 1), e.g., in terms of reliability, latency, and / or other criteria. In an example, distribution mode 1 may be supported for multicast services and / or distribution mode 2 may be supported for broadcast services. In an example (e.g., with respect to radio resource control (RRC) states), distribution mode 1 may be supported for a state (e.g., connected (CONN) state) and / or distribution mode 2 may be supported for multiple (e.g., all) RRC states. A WTRU with multicast may be allowed to enter an INACTIVE state, which may support improved power consumption / overhead and / or may be used as a means to mitigate congestion. A WTRU in INACTIVE state may not provide (e.g., have the means to provide) feedback (e.g., without significant overhead). One or more constraints may exist: WTRUs in INACTIVE may not be uplink (UL) synchronized; The number of WTRUs in INACTIVE receiving MBS services may be significant; Allocating WTRU-specific resources for feedback may not be feasible or desirable.

[0099] For example, as described herein, techniques related to reliability monitoring and / or reliability indication are disclosed (e.g., may be implemented by or in association with a WTRU). The reliability indication may be an indication associated with transmission reliability, e.g., determined by the WTRU based on whether the WTRU receives transmission(s) (e.g., MBS transmission(s) such as MBS transport block(s)). The reliability indication may include or indicate a reliability indicator (e.g., a reliability metric) and / or a determined value and / or range of the reliability indicator. One or more of the following may apply:

[0100] The WTRU may receive MBS configuration information. The MBS configuration information may be associated with the INACTIVE state. For example, the MBS configuration information may be received in a message (e.g., an RRC message such as an RRC release message that includes a suspend configuration (e.g., SuspendConfig) indication, where SuspendConfig may be used as an example). The validity of the MBS configuration information and the SuspendConfig indication may be associated with different areas (e.g., logical areas), for example, the logical area may be an MBS area as opposed to a RAN area. The MBS configuration information may include and / or indicate one or more of multicast radio bearer (MRB) configuration information for the INACTIVE state, one or more triggers for a reliability indication, a reliability metric setting, or a reliability indication setting.

[0101] The MRB configuration information for the INACTIVE state may be indicated using one or more of the following: The WTRU may, for example, suspend a point-to-point (PTP) leg and / or maintain a point-to-multipoint (PTM) leg for split MRBs if MBS reception is allowed in the INACTIVE state (e.g., conditional and / or under the conditions of entering the INACTIVE state). The WTRU may keep one or more MBS bearers active after entering the INACTIVE state. The WTRU may suspend other bearers (e.g., non-MBS bearers and / or MBS bearers different from the one or more MBS bearers configured to be active in INACTIVE).

[0102] The trigger for the reliability indication may be associated with one or more of the following: The trigger for the reliability indication may indicate whether the reliability monitoring and / or the reliability indication is periodic, event-triggered, polling-based, etc. The one or more triggers for the reliability indication may be indicated in, for example, polling configuration information, event-based configuration information, and / or periodic configuration information. The polling configuration information may be associated with a multicast control channel (MCCH). The polling configuration information associated with the MCCH may indicate to the WTRU, for example, with respect to a particular MBS service, to implement the reliability indication, for example, by signaling identification information associated with such MBS service. For example, the identification information may be indicated by a group radio network identifier (GRNTI) associated with the MBS service(s) for which the WTRU is expected to perform reliability monitoring. The event-based configuration information may indicate to implement the reliability indication, for example, when one or more thresholds associated with a reliability metric are met. The trigger for implementing the reliability indication may be indicated in a periodic configuration, for example, periodic configuration information may be received every n change periods (n may be a fraction or ≥ 1).

[0103] The reliability metric configuration information may be associated with one or more of the following: The reliability metric configuration information may include (e.g., indicate) a type of reliability metric, which may include one or more of, for example, a statistic associated with an MBS channel quality indicator (CQI) and / or a block error rate (BLER), a number of repetitions relative to an expected (e.g., total) number of transmissions within an MCCH modification period, etc.

[0104] The reliability indication configuration information may be associated with one or more of the following: The reliability indication configuration information may indicate one or more resources for the reliability indication, which may include, for example, one or more random access (RA) preambles, random access channel (RACH) opportunities (ROs) (e.g., associated with MCCH change boundaries), an association between (e.g., or a range of) RA resources and reliability metrics, etc.

[0105] The WTRU may enter the INACTIVE state, for example, based on a command from the network (e.g., when receiving an RRC release via suspendConfig). A WTRU (e.g., in the INACTIVE state) may receive MBS transmissions, for example, on one or more configured MRBs.

[0106] The WTRU may receive an MCCH transmission. The MCCH transmission may include or indicate a polling request for a reliability indication. The MCCH transmission may be received according to the GRNTI and / or may include a polling request. The MCCH transmission may be received during a time interval (e.g., an MCCH modification period n). Assistance information (e.g., additional assistance information) may be received for reliability monitoring. The assistance information may include, for example, an expected number of MBS transport blocks (TBs) within the modification period. Activation and / or deactivation of the periodic reliability indication may be received, for example, via a Medium Access Control (MAC) Control Element (CE).

[0107] The WTRU may determine one or more reliability metrics associated with a received MBS transmission (eg, an MBS TB reception in an INACTIVE state).

[0108] The WTRU may monitor one or more reliability metrics during a time interval, such as, for example, a time interval associated with an MCCH modification period (eg, MCCH modification period n+1).

[0109] The WTRU may determine a reliability indicator (e.g., a reliability metric) and / or a value and / or range of the reliability indicator (e.g., a reliability metric) based on a trigger condition being met, such as, for example, receiving a polling request or other condition described herein. The WTRU may select RA resource(s) based on, for example, the determined value and / or range of the reliability indicator (e.g., a reliability metric), e.g., based on an association and / or mapping between one or more pre-configured resources and the determined value and / or range of the reliability metric.

[0110] The WTRU may indicate (e.g., implicitly indicate) a reliability metric and / or a value and / or range of the reliability metric. For example, the WTRU may send a reliability indication via a selected preamble and RO (e.g., the reliability indication may include or indicate a reliability indicator (e.g., a reliability metric) and / or a determined value and / or range of the reliability indicator), where, for example, the selected preamble and RO may implicitly indicate the reliability metric.

[0111] The WTRU may monitor a random access response (RAR) format for a response associated with the reliability instruction transmission (e.g., the RAR format may be specific to the reliability instruction transmission). The RAR format (e.g., a response in the RAR format) may include, for example, one or more of an indication of whether the WTRU should perform a subsequent random access and resumption procedure, an indication of whether the WTRU should perform a two-step RA (e.g., to provide additional WTRU-specific information such as an inactive RNTI (I-RNTI) transmission), and / or an indication to return to and / or remain in an INACTIVE state.

[0112] FIG. 2 shows an example of reliability monitoring and reliability indication for an MBS. A common reference period may be used for the reliability indication (e.g., by the network and the WTRU). The common reference period may include an MCCH modification period. The MCCH modification period may include multiple slots. FIG. 2 shows two MCCH modification periods, MCCH modification period n and MCCH modification period n+1. During MCCH modification period n, multiple MCCH transmissions may be transmitted (e.g., by the network). Some or all of the MCCH transmissions may include the same information (e.g., the same polling request). For example, an MCCH transmission may indicate the expected number of TBs to be transmitted (e.g., by the network) during the next MCCH modification period (e.g., MCCH modification period n+1). The WTRU may determine the number of TBs actually received and / or successfully decoded and use the expected number of TBs to be transmitted during the next MCCH modification period and the number of TBs actually received to determine the ratio of received TBs to transmitted TBs. The reliability indicator value may include a ratio. An MCCH transmission may be sent in (eg, each) MCCH repetition period.

[0113] The MCCH transmission may indicate a polling request. For example, (e.g., each) MCCH transmission may include a polling request (e.g., each MCCH transmission may include the same polling request). The WTRU may or may not successfully decode the MCCH transmission indicating a polling request. If the WTRU successfully decodes the MCCH transmission, the WTRU may be triggered to measure one or more values ​​of a reliability indicator based on receipt of the polling request. For example, the measurement of the one or more values ​​of the reliability indicator may be based on information included in the MCCH transmission. During the MCCH modification period n+1, multiple MCCH transmissions may be transmitted (e.g., by the network), for example, for each repetition period. The MCCH transmission transmitted during the MCCH modification period n+1 may include a polling request that, if successfully decoded, triggers measurement of one or more values ​​of the reliability indicator during the next MCCH modification period (e.g., MCCH modification period n+2). The WTRU may determine a PRACH resource for transmitting the preamble based on the determined value of the reliability indicator. As shown in FIG. 2, after MCCH modification period n+1, the value of the reliability indicator may be indicated by transmitting a preamble using the determined PRACH resource.

[0114] As an example, in the RRC CONNECTED state, the WTRU may be configured to receive an MBS configuration associated with the RRC INACTIVE state. The MBS configuration may include one or more triggers for reliability indication, a mapping between a reliability metric range and UL resources for the reliability metric indication. Upon entering the RRC INACTIVE state, the WTRU may suspend the PTP leg (if any) and start or continue the PTM leg for the MBS service. The WTRU may monitor one or more triggers for the reliability indication, for example, via a GRNTI. The WTRU may receive an MCCH transmission with a polling request for reliability indication during the MCCH modification period n. The polling request may be associated with a particular MBS bearer and may provide assistance information, for example, the number of MBS transport blocks within the modification period n+1. The WTRU may determine a reliability metric during a time interval associated with the MCCH modification period n+1; for example, the reliability metric may be the ratio of the number of successful MBS transport blocks received to the total number of MBS transport blocks transmitted within the modification period. The WTRU may determine RA resources applicable to the reliability indication as a function of the reliability metric value. The WTRU may transmit an RA preamble on the determined RA resources. The WTRU may monitor the RAR format associated with the reliability indication. Upon receiving an RAR that matches the reliability indication, the WTRU may perform one or more of the following actions based on the received RAR: perform another RA procedure to initiate a resumption procedure or remain in RRC INACTIVE to receive the MBS service.

[0115] The WTRU may be configured to receive RAN paging with reliable polling (e.g., instead of MCCH polling).

[0116] The WTRU may be configured to initiate a transition from INACTIVE to CONNECTED based on, for example, the value and / or range of the reliability metric falling below a threshold.

[0117] The reliability monitoring may be performed on a shorter time scale, for example, based on a duration that may be tracked (e.g., via a timer). In an example, the shorter time scale may be a time that is shorter than the length of a modification period (e.g., an MCCH modification period). For example, the duration may be tracked (e.g., a timer may be started) if / when the WTRU receives a poll. The WTRU may send a reliability indication on the earliest RO, for example, based on the expiration of a duration (eg, expiration of a timer).

[0118] Features related to MBS reliability indication are described herein. Example features described herein may be based on transmission and delivery of MBS services. The described features are not limited to example scenarios, systems, and services. The features described herein may be applicable to other types (e.g., any type) of transmissions and / or services, including, for example, but not limited to, V2X, augmented reality, gaming, IoT / MTC, industrial use cases, etc.

[0119] A WTRU configured for receiving data for an MBS may be configured with a data radio bearer (DRB), such as a multicast radio bearer (MRB). A DRB may be dedicated to receiving MBS. MBS service and MRB may be used interchangeably (e.g., may be considered equivalent), for example, from the perspective of L2 and L3. An MBS service may be configured with zero, one, or two or more MRBs.

[0120] The term "INACTIVE" or "INACTIVE state" may refer to the WTRU performing, or being configured to perform, one or more (e.g., or a set of): monitoring short messages sent with a paging RNTI (P-RNTI) on downlink control information (DCI); monitoring a paging channel for CN paging (e.g., using a 5G S temporary mobile subscriber identity (5G-S-TMSI)) and / or RAN paging (e.g., using the full I-RNTI); performing neighbor cell measurements and WTRU-controlled mobility based on network (NW) configuration (e.g., cell (re)selection); performing RAN-based notification area updates periodically and / or when / if moving outside a configured RAN-based notification area; or obtaining system information and / or sending an SI request (e.g., if configured).

[0121] Exemplary features may be described herein without limitation with respect to the INACTIVE state. The techniques described herein may be applicable to other RRC states (eg, IDLE state, CONNECTED state, etc.).

[0122] The one or more information elements and / or configuration parameters may be described in various examples without limitation with respect to an RRC configuration. The techniques described herein may be applicable to other configurations (e.g., any configuration), default configurations, designated configurations, broadcast configurations (e.g., signaled via system information), group-specific configurations (e.g., specific to a multicast group), area-specific configurations (e.g., MBS area, RAN area, etc.), and / or WTRU-specific configurations (e.g., signaled via RRC, MAC, DCI, or Layer 1 signaling).

[0123] A bearer setup and / or architecture may be provided for MBS in INACTIVE. A WTRU (e.g., configured for receiving data for an MBS) may be setup with a Data Radio Bearer (DRB) that may be dedicated to MBS reception (e.g., via a Multicast Radio Bearer (MRB)). MBS service and MRB may be used interchangeably (e.g., may be considered equivalent), e.g., from an L2 and L3 perspective. An MBS service may not be setup with an MRB, or may be setup with one or more MRBs.

[0124] MRBs (e.g., similar to DRBs) with several QoS flows may be multiplexed within an MRB (e.g., a given MRB). An MRB may employ a split bearer protocol architecture with, for example, one packet data convergence protocol (PDCP) entity and two radio link control (RLC) entities. For example, as shown by the example of Figure 4, a first RLC entity may be for PTM and a second RLC entity may be for PTP operation.

[0125] FIG. 4 illustrates an example of an MRB having a split bearer protocol architecture.

[0126] As shown in FIG. 4, a cell radio network identifier (C-RNTI) may identify (e.g., uniquely identify) an RRC connection of a WTRU within a cell, and a group RNTI (G-RNTI) may identify a group of WTRUs participating in multicast. A WTRU configured with an MRB (e.g., according to the example architecture shown in FIG. 4) may monitor DL ​​scheduling for the MRB on the C-RNTI and / or G-RNTI. In an example, an RLC entity associated with a PTM may operate in unacknowledged mode (UM), while an RLC entity associated with a PTP may operate in acknowledged mode (AM). Techniques (e.g., methods) disclosed herein may be applied to other modes of operation (e.g., a PTM operating in transparent mode (TM) or AM, or a PTP operating in TM or UM). In an example, a WTRU may be configured to suspend PTP operation while transitioning to an INACTIVE state while maintaining PTM operation. For example, the WTRU may reconfigure an MRB bearer, e.g., from split bearer MBS operation to PTM bearer operation (e.g., under the condition of transitioning to the INACTIVE state). The WTRU may release the RLC entity associated with the PTP RLC entity of the MRB. The WTRU may reconfigure (e.g., implicitly reconfigure) the MRB to PTM, e.g., if (e.g., only if) the NW indicates that MBS reception is allowed in the INACTIVE state.

[0127] An INACTIVE WTRU (e.g., which may refer to a WTRU in INACTIVE herein) may initiate a resumption procedure, e.g., to indicate a request from the WTRU to the network for an MBS service (e.g., a reliable MBS service). The resumption procedure may be performed, e.g., by sending an RRCResumeRequest, which may include a resumption reason (e.g., mbs-call-interest) and / or information about MBS session identification (e.g., if several MBS sessions are active simultaneously). In an example, an INACTIVE WTRU may include a preference indication, which may indicate whether the WTRU wants to remain in the INACTIVE state or whether it wants to transition to the CONNECTED state for MBS service delivery. In an example, an INACTIVE WTRU (e.g., that sent a request to be resumed) may receive a response message from the network to resume the connection (e.g., RRCResume). The WTRU may (e.g., subsequently) receive an RRC reconfiguration message to configure MRB(s) (e.g., required MRB(s)).

[0128] An INACTIVE WTRU (e.g., that sent a resume request, e.g., a request to be resumed) may receive a response message from the network to resume the connection (e.g., RRCResume). The response message may include MRB(s) settings (e.g., requested MRB(s)). The WTRU may apply the MRB settings (e.g., required MRB settings). The WTRU may remain in the INACTIVE state. The WTRU may, for example, receive MBS data according to the MRB settings.

[0129] A WTRU in CONNECTED state with an MRB configuration (e.g., the MRB may or may not be active at the time) may be transitioned (e.g., sent) to the INACTIVE state (e.g., via a network message, e.g., an RRC release message). An indication (e.g., in the RRC release message) may be provided / received indicating that the WTRU continues to receive MBS data while in the INACTIVE state. In an example, the RRC release message may include new or updated MRB configuration, for example, if / when a WTRU in CONNECTED state is moved to the INACTIVE state.

[0130] A WTRU may indicate interest in receiving or participating in an MBS session while in the CONNECTED state and may be released to the INACTIVE state. In an example, the MBS session has not been started and the network and / or the WTRU may indicate (to the network) if and / or when the MBS session will become active. For example, the WTRU may send a request for an MBS session in the CONNECTED state. A WTRU (e.g., in the INACTIVE state) may receive, for example, an indication (e.g., indicating the MBS session) if / when the MBS session will become active. This indication may be or may be included in one or more of RAN paging, an MBS session start indication on a multicast control channel (MCCH), an MBS session start indication in a SIB, etc. The WTRU may start the MBS service (e.g., receiving the MBS service), for example, based on receiving the indication (e.g., that the MBS session is active).

[0131] An INACTIVE WTRU (e.g., configured with an MRB having a split bearer configuration, such as one RLC AM entity associated with the C-RNTI and another RLC UM entity associated with the G-RNTI) may suspend the RLC leg associated with the C-RNTI for PTP transmission, stop monitoring the C-RNTI on the PDCCH, and monitor the G-RNTI (e.g., only the G-RNTI) on the PDCCH for MBS data reception.

[0132] The WTRU may be configured with configured grants that may be used for reception of MBS data while in the INACTIVE state. For example, a periodic grant configuration may indicate which radio resources (e.g., time and / or frequency) contain data for the MBS session(s). In an example, configured grants for MBS reception may be provided while the WTRU is in the CONNECTED state. The configured grants may be provided based on (e.g., as part of) a transition to the INACTIVE state (e.g., in an RRC release message).

[0133] Features associated with reliability monitoring and / or the reliability indication are described herein and may be associated with the INACTIVE state. A reliability indicator (e.g., a reliability metric) may be associated with the reliability indication (e.g., the reliability indicator may be provided or indicated in the reliability indication). As used herein, the term "configuring to" may refer to (e.g., may include) an associated device (e.g., a WTRU) performing a configured action.

[0134] The reliability metric may be based on a channel quality indicator (CQI). The WTRU may be configured to monitor the CQI associated with the MBS reception. The WTRU may be configured to derive an MBS CQI index. For example, (e.g., each) MB CQI index may be associated with one or more combinations of modulation scheme(s), target coding rate(s), and transport block size(s). In an example, the WTRU may be configured to derive a reliability metric corresponding to the highest MBS CQI index such that a transport block associated with the MBS transmission can be received with a transport block error probability not exceeding a preset value, and the received transport block may have a combination of modulation scheme, target coding rate, and transport block size associated with that MBS CQI index. The transport block received with a transport block error probability not exceeding the preset value may then be determined by the WTRU to correspond to a CQI index occupying a group of downlink physical resource blocks (e.g., an MBS reference resource). The MBS reference resource may be preconfigured within the MBS bandwidth portion (e.g., using a specific numerical structure). For example, the WTRU may be pre-configured with a transport block error probability (e.g., specifically for the calculation of the MBS CQI). This configuration may be specific to the MBS service. The WTRU may be configured with a CQI table (e.g., specific to a reliability indication). For example, a CQI index (e.g., each CQI index) may be 4 bits and / or may map to a (e.g., specific) modulation and coding rate (e.g., for a given MBS block error rate (BLER) configuration). In an example, the WTRU may be configured to use a subset of a CQI table (e.g., a conventional CQI table). For example, the WTRU may be configured with CQI indices 0 to 7, where, e.g., CQI indices 0 to 6 may correspond to a (e.g., conventional) CQI table and a CQI index of 7 may indicate a CQI value greater than 6 (e.g., any CQI value greater than 6).

[0135] The WTRU may be configured to measure the MBS CQI within pre-set ranges of CQI values, for example, a first CQI range may be set as CQI indexes 1 to 6, a second CQI range may be set as CQI indexes 7 to 9, a third CQI range may be set as CQI indexes 10 to 15, etc.

[0136] In an example, the WTRU may be configured to measure (e.g., and / or determine) whether the MBS CQI is less than or equal to a CQI index. For example, the WTRU may be configured to determine whether the measured CQI value is less than CQI index 7.

[0137] The reliability metric may be based on the HARQ status. The WTRU may be configured with (e.g., receive an indication of) the number of repetitions of the MBS transport block. The WTRU may be configured to perform incremental redundancy combining over the repetitions of the MBS transport block. The WTRU may be configured to disable HARQ feedback, for example, while in an INACTIVE state (e.g., under the condition of being in an INACTIVE state). The WTRU may be configured to maintain statistics related to the number of generated NACKs (e.g., for the purpose of calculating a reliability metric), for example, until a transport block is successfully decoded. The WTRU may be configured to measure statistics related to the number of NACKs within a preconfigured time interval.

[0138] The WTRU may be configured to monitor statistics associated with the number of iterations associated with successful decoding of an MBS transport block.

[0139] The WTRU may be configured to monitor the average number of iterations for successful decoding of an MBS transport block. The WTRU (e.g., alternatively and / or additionally) can determine (e.g., be configured to determine) a repetition (e.g., total repetitions) ratio to the number of transport blocks (e.g., required) for successful decoding of an MBS transport block (e.g., within a time interval). The WTRU may receive an indication of the total number of MBS transport blocks that have been scheduled or are expected to be scheduled (e.g., within a time interval), for example, to enable determination of the total number of transport blocks. This indication may be transmitted on the MCCH. This indication may be in configuration information associated with the MBS service (e.g., configuration information received via RRC).

[0140] The WTRU may be configured to monitor the maximum number of iterations (e.g., used, required, etc.) for successful decoding of an MBS transport block. The WTRU may (e.g., alternatively and / or additionally) be configured to calculate a reliability metric based on the maximum number, e.g., if the number of transport blocks (e.g., requiring the maximum number of repetitions) exceeds a threshold. For example, the ratio of the number of transport blocks (e.g., requiring the maximum number of repetitions) to the actual number of transport blocks (e.g., within a time interval) may exceed a threshold.

[0141] The WTRU may be configured to monitor the median number of iterations and / or the mode for successful decoding of the MBS transport block.

[0142] The reliability metric may be based on a multicast channel block error rate (MCH BLER). The WTRU may be configured to monitor the results of PDSCH decoding associated with MBS reception. For example, the WTRU may be configured to count the number of cyclic redundancy check (CRC) errors associated with MBS reception (e.g., within a time interval). The reliability metric may be defined, for example, as a function of the number of CRC errors (e.g., within a time interval).

[0143] The WTRU may be configured to determine the MCH BLER estimate based on, for example, an evaluation of the status of a CRC check result associated with the MBS transport block. In an example, the BLER may be calculated (e.g., over a measurement period) as the ratio between the number of received MBS transport blocks that result in CRC errors and the total number of MBS transport blocks received (e.g., expected to be received) (e.g., within the same measurement period). The measurement period may correspond to a time interval. In an example, the time interval may be defined (e.g., configured or set) relative to an MCCH modification period. In an example, the time interval may be tracked, for example, based on a pre-configured timer.

[0144] In an example, the WTRU may determine a reliability metric as the ratio between the number of successful MBS PDSCHs received and the number of successful MBS PDCCHs received within a time interval.

[0145] The reliability metric may be based on one or more reference signal (RS) measurements. The WTRU may determine (e.g., be configured to determine) the reliability metric based on the one or more reference signal measurements. For example, the WTRU may measure (e.g., be configured to measure) MBSFN reference signal received power (MBSFN RSRP). The MBS RSRP may be defined (e.g., and / or determined) as, for example, a (e.g., linear) average over the power contributions (e.g., in units of watts (W)) of resource elements carrying the MBS reference signal within the considered measurement frequency bandwidth. For example, the MBS RSRP measurement may assume an RS transmission with an antenna port configured for MBS transmission.

[0146] For example, the WTRU may be configured to measure the MBS reference signal received quality (RSRQ). The MBS RSRQ may be defined (e.g., and / or determined) as, for example, the ratio N × MBS RSRP / (MBS carrier reference signal strength indicator (RSSI)) (e.g., N may be the number of RBs in the MBS carrier RSSI measurement bandwidth). The measurements in the numerator and denominator may be made on the same set of resource blocks. The MBS carrier RSSI may include (e.g., may be defined and / or calculated as) a linear average of the total received power (e.g., in units of W) observed in orthogonal frequency-division multiplexing (OFDM) symbols containing reference symbols for antenna ports configured for MBS transmissions (e.g., within the pre-configured MBS measurement bandwidth), for example, across N resource blocks. The power may include power from one or more (e.g., all) sources, such as co-channel serving and non-serving cells, adjacent channel interference, thermal noise, etc.

[0147] Reliability monitoring may be associated with a reliability indication. The WTRU may be configured to perform a reliability monitoring procedure, which may include one or more of: measuring one or more reliability metrics; maintaining counters associated with the reliability metrics; determining statistics associated with the reliability metrics; monitoring value(s) of the one or more reliability metrics and comparing the metric(s) or value(s) with one or more thresholds (e.g., pre-configured thresholds); or triggering transmission of a reliability indication to the network (e.g., based on the metric(s) or value(s) satisfying a threshold condition (e.g., a trigger condition)). The WTRU may be configured to perform the monitoring procedure for a pre-configured time interval. The time interval may be configured (e.g., explicitly set). The time interval may be specific to the MBS service. The time interval may be based on (e.g., defined / tracked) a time (e.g., a timer). For example, the duration (e.g., the value of the timer) may be part of the MBS configuration. In an example, the time interval may be implicit. In an example, the time interval may correspond to an MCCH repetition period. In an example, the time interval may correspond to an MCCH modification period. In an example, the time interval may be defined relative to the MCCH modification period. In an example, this relationship may be expressed in terms of an offset. In an example, the time interval may be defined relative to a RAN paging interval. The WTRU may be configured to send a reliability indication, which may implicitly or explicitly indicate a reliability metric. Different time intervals may be specified for different trigger conditions.

[0148] In an example, the evaluation of the condition may continue over the evaluation period. For example, the WTRU may be configured to evaluate an average CQI (e.g., over the evaluation period). The WTRU may continue measuring the CQI over the duration, average the measured CQI, and compare the average to a provided threshold. In an example, the WTRU may be provided with a scaling factor that may be used to calculate and / or aggregate the condition. For example, values ​​measured at the beginning of the evaluation period may be assigned a higher weight than values ​​measured near the end of the evaluation period.

[0149] The evaluation of the condition may stop before the evaluation period ends, for example, if the criteria have already been met. For example, the WTRU may be configured to detect whether more than a certain (e.g., configured, determined, set, or selected) number of failures are detected. The WTRU may stop monitoring the number of failures, for example, if the WTRU detects the set number of failures before the evaluation period ends.

[0150] The WTRU may be configured to perform reliability monitoring, for example, if / when at least one MRB is active (e.g., configured to be active) while in the INACTIVE state. In an example, the WTRU may receive a configuration associated with reliability monitoring as part of the MRB configuration or as part of the INACTIVE configuration (e.g., suspendConfig). The WTRU may be configured to apply the reliability configuration, for example, based on (e.g., based on) entering the INACTIVE state and / or based on (e.g., based on) applying the suspend configuration, for example, if / when at least one MRB is active (e.g., configured to be active).

[0151] In an example, the WTRU may be configured to perform reliability monitoring in the INACTIVE state, for example, if / when the WTRU receives a reliability poll (e.g., a poll request) from the network. The reliability poll may be received in an MCCH transmission. The reliability poll may be received in an MCCH change notification. The reliability poll may be received in a RAN paging message. The reliability poll may indicate whether reliability monitoring is requested for one (e.g., a specific) multicast group or for more (e.g., all) multicast groups. The WTRU may be configured to activate or deactivate reliability monitoring, for example, via the MAC CE.

[0152] The WTRU may initiate reliability monitoring, e.g., during a time window corresponding to modification period n+1, based on receiving a reliability poll during MCCH modification period n. In an example, the WTRU may be configured to start / track a duration (e.g., via a timer) based on receiving a poll and / or to perform reliability monitoring (e.g., as long as the tracked duration has not expired, e.g., as long as the timer is running).

[0153] In an example, a WTRU may be configured to perform reliability monitoring of an MBS service (e.g., a specific MBS service) and / or an MBS radio bearer (e.g., a specific MBS radio bearer). The reliability monitoring may be configured, for example, via an RRC configuration, a MAC CE, etc. The MBS radio bearer and / or the MBS service may be identified, for example, by a group identity, an RNTI, etc. The WTRU may, for example, measure reliability metrics for MBS transport blocks associated with the MBS service (e.g., only for MBS transport blocks associated with the MBS service). The transport blocks may be scheduled, for example, via the RNTI of the configured group.

[0154] In an example, the WTRU may be configured to release and / or stop reliability monitoring and / or reliability indication procedures based on (e.g., based on the condition) leaving the INACTIVE state (e.g., entering the CONNECTED state or the IDLE state).

[0155] In an example, the WTRU may be configured to release and / or stop the reliability monitoring and / or reliability indication procedures based on one or more of (e.g., based on one or more of) the following: reselecting to a cell outside the MBS area configured for the WTRU; reselecting to a cell outside the current RAN area applicable to the INACTIVE state; reselecting to a cell that does not support the MBS service; reselecting to a cell that does not support the MBS service for which the WTRU may currently be configured; or reselecting to a cell that does not support the reliability monitoring and / or indication procedures.

[0156] One or more triggers may be provided for transmitting a reliability indication (e.g., under a condition that the trigger occurs, the WTRU is triggered to transmit a reliability indication). The WTRU may initiate transmission of a reliability indication (e.g., transmit a reliability indication) based on one or more trigger conditions, which may be configured, for example, as WTRU-specific or specific to an MBS service (e.g., as disclosed herein). The trigger for the reliability indication may be one or more of (e.g., a combination thereof): polling-based, event-triggered, and / or periodic. The WTRU may prioritize a polling-based indication, followed by an event-triggered indication, followed by a periodic indication (e.g., if / when two or more trigger types are configured).

[0157] The triggering of the reliability indication may be based on, for example, polling in the MCCH transmission. The WTRU can trigger the transmission of the reliability indication based on the polling information in the MCCH transmission. For example, the WTRU may monitor (e.g., be configured to monitor) the MCCH, for example, in each MCCH repetition period within an MCCH modification period. For example, an MCCH transmission received during modification period n may inform the WTRU about an action to take in a subsequent MCCH modification period (e.g., greater than period n (>n)). The WTRU may be configured to perform reliability monitoring in modification period n+k. The WTRU may be configured to perform a reliability indication transmission in modification period n+l, where l>k (e.g., k=1 and l=2).

[0158] The WTRU may receive a reliability indication poll in a transmission (e.g., in an MCCH transmission, which may be used as an example). The MCCH transmission (e.g., the reliability indication poll in the MCCH transmission) may indicate that the WTRU will transmit a reliability indication in the next modification period (e.g., the next modification period, a specified subsequent modification period, etc.). The MCCH transmission may indicate (e.g., set) a filtering criterion for the reliability indication. For example, the filtering criterion may specify the highest reliability metric applicable to the reliability indication. For example, the WTRU may transmit a reliability indication if / when (e.g., only if) the measured reliability metric is less than or equal to the set filtering criterion. The WTRU may skip the reliability indication transmission, for example, if the reliability metric is greater than the set filtering criterion.

[0159] The WTRU may receive a reliability indication poll specific to an MBS radio bearer and / or MBS service. The WTRU may trigger a reliability indication (e.g., decide to send a reliability indication) if (e.g., only if) the WTRU is configured for an MBS radio bearer and / or MBS service (e.g., a particular MBS radio bearer and / or MBS service). For example, polling information received via an MCCH scheduled based on a group RNTI may activate a reliability indication from the WTRU configured for an MBS radio bearer (e.g., and / or MBS service) associated with the group RNTI. In an example, the WTRU may implement reliability indication for one or more MBS bearers for which reliability monitoring is configured.

[0160] The WTRU may receive an MCCH transmission with a polling request associated with a GRNTI (e.g., a pre-configured GRNTI). The WTRU may receive information indicating the number of MBS transport blocks within modification period n (e.g., the expected number of MBS transport blocks within modification period n). The WTRU may use the information to determine a reliability metric (e.g., the ratio of the number of successfully received transport blocks to the total number of MBS transport blocks within the modification period, the number of successfully received transport blocks within the modification period, etc.). The WTRU may determine the average number of retransmissions and / or repetitions for (e.g., required for) successful MBS transport block reception.

[0161] Polling over the MCCH may be achieved, for example, using a polling indication in RAN paging.

[0162] The reliability indication may be periodic, for example, with respect to the MCCH modification period. The WTRU may be configured to transmit the reliability indication periodically. The periodicity may be set, for example, as a function of the modification period (e.g., at every modification period boundary and / or at RACH opportunities at an offset from the modification period boundary). For example, the periodicity of the reliability indication may be set to be a multiple of the modification period (e.g., every n modification periods, where n may be greater than or equal to 1). In an example, n may be a fraction, which may mean that there may be multiple reliability indications within a modification period.

[0163] The WTRU may receive a message (e.g., RRC configuration) indicating the periodicity of the modification period. Different periodicities may be configured for reliability indications associated with different MBS radio bearers. The WTRU may be configured to activate and / or deactivate the periodic reliability indication via the MAC CE. Periodic reporting may be selectively activated or deactivated, for example, per MBS radio bearer.

[0164] The WTRU may transmit (e.g., may be configured to transmit) a reliability indication based on one or more (pre-)configured events. For example, a trigger condition for transmitting a reliability indication may be based on a reliability metric being above or below a (pre-)configured threshold. The WTRU may, for example, determine whether the average number of repetitions for successful MBS transport block reception within a pre-configured time interval meets a threshold (e.g., above a threshold), or a different statistic such as the median repetition or number of repetition modes for successful MBS transport block reception within a pre-configured time interval meets a threshold (e.g., above a threshold), the minimum CQI associated with MBS reception over a pre-configured time interval meets a threshold (e.g., below a threshold), the ratio of the number of repetitions of an MBS transport block to the total number of MBS transport blocks within a pre-configured time interval meets a threshold (e.g., above a threshold), the number of transport blocks that failed to be successfully received (e.g., exceeded the maximum number of repetitions before successful decoding) meets a threshold (e.g., above a threshold), a statistic associated with the MCH BLER within the time interval meets a threshold (e.g., above a threshold), the number of NACKs associated with MBS transport blocks counted by the WTRU within the time interval meets a threshold (e.g., above a threshold), the average MBS RSRP within the time interval meets a threshold (e.g., below a threshold), and / or ... A reliability indication may be sent if / when one or more of the following conditions are met: the RSRQ meets a threshold (eg, is below a threshold).

[0165] One or more reliability metrics (e.g., as described herein) may be measured specific to the MBS radio bearer. The WTRU may trigger a reliability indication at the end of a monitoring time interval. The WTRU may trigger a reliability indication if (e.g., as soon as) evaluation criteria are met for one or more of the monitored trigger conditions.

[0166] A reliability indication may be transmitted. There may be an association between a reliability metric and an UL resource. The WTRU may be (pre-)configured with a rule for determining the UL resource for transmitting the reliability indication. For example, the rule may be based on a reliability metric value or a reliability metric range. The WTRU may be configured with multiple UL resources. The UL resources may be mapped to reliability metric values ​​or ranges (e.g., each UL resource may be mapped to a respective reliability metric value or range). For example, the WTRU may be configured with an UL resource set for transmitting a reliability indication, and an association between a particular UL resource and a reliability metric value or range. The WTRU may select an UL resource associated with a reliability metric value or range (e.g., if / when one or more of the trigger conditions are met), and the WTRU may transmit a reliability indication that may indicate a reliability indicator (e.g., a reliability metric and / or a reliability metric range).

[0167] In an example, the UL resource may be a random access (RA) resource. The terms RA resource and physical random access channel (PRACH) resource may be used interchangeably. RA resource may refer to time resource, frequency resource, spatial resource, RACH opportunity (RO), preamble format, etc. The preamble format may be configured, for example, with respect to total preamble duration, sequence type, sequence length, guard time duration, cyclic prefix length, etc.

[0168] There may be an association between the CQI index and the RA resource. The WTRU may be configured with a mapping between the CQI index (e.g., or its range) and the preamble and / or RACH opportunity (e.g., a mapping between each corresponding CQI index and each preamble and / or RACH opportunity). The WTRU may be configured with a mapping between the CQI index (e.g., or its range) and the PRACH configuration index that identifies the RA resource (e.g., a mapping between each corresponding CQI index and each PRACH configuration index that identifies each RA resource). The WTRU may determine the mapped RA resource (e.g., preamble x and RACH opportunity y) and, for example, transmit preamble x in RACH opportunity y if / when a reliability indication is triggered by a CQI value of, for example, n. The RA resource may be specific to the CQI range (e.g., not specific to the WTRU), which may reduce collisions and resource overhead.

[0169] In an example, the WTRU may be configured with an UL resource (e.g., only one UL resource) for reliability indication, and the WTRU may be configured to transmit a preamble on the resource if, for example, the CQI is lower than a (pre-)configured threshold.

[0170] Different associations may be configured for different reliability metrics (e.g., similar to the CQI example). A WTRU may be configured with a mapping between RA resources and a statistic or value range associated with the number of repetitions for successful MBS transport block reception (e.g., over a time interval). A WTRU may be configured with a mapping between RA resources and a ratio of the number of MBS transport block repetitions to the number (e.g., total number) of MBS transport blocks (e.g., over a time interval). A WTRU may be configured with a mapping between RA resources and a statistic associated with MCH BLER (e.g., over a time interval). A WTRU may be configured with a mapping between RA resources and a number of negative acknowledgments (NACKs) associated with MBS transport blocks (e.g., over a time interval). A WTRU may be configured with a mapping between RA resources and a range of average MBS RSRP / RSRQ values ​​(e.g., over a time interval).

[0171] The WTRU may be configured with an association between each trigger condition (e.g., referring to a reliability indication based on one or more (pre-)configured events) and each UL resource, which may be specific to each trigger condition. The UL resource may identify (e.g., uniquely identify) the trigger condition.

[0172] The mapping between reliability metrics and UL resources may be MBS service / MRB specific. For example, the WTRU may receive multiple reliability metrics for RA resource associations. The WTRU may be configured such that RACH opportunities do not overlap in time, for example, for simultaneous MBS services for which the WTRU is configured for INACTIVE state.

[0173] A configuration related to a mapping between reliability metrics and UL resources may be applicable in multiple cells (e.g., all cells) within a logical area (e.g., MBS area, RAN area, etc.). The mapping may be configured to be valid with (e.g., with only) the current cell. The WTRU may release the configuration, for example, based on (e.g., conditionally) reselection to a different cell while in the INACTIVE state.

[0174] Different types of reliability indications may be provided (e.g., configured and / or transmitted) for different ranges of a reliability indicator (e.g., a reliability metric). In an example, a WTRU may be configured with different actions based on the value or range of the reliability metric. For example, the WTRU may perform a reliability indication procedure using a (pre-)configured RA resource if the reliability metric is within a first range. For example, the WTRU may initiate a restart procedure if the reliability metric is within a second range. For example, the WTRU may initiate a WTRU identity transmission procedure (e.g., the WTRU may transmit a unique WTRU identity associated with an INACTIVE state) if the reliability metric is within the second range. For example, the WTRU may initiate a periodic RAN update procedure if the reliability metric is within the second range. In an example, the second range may be lower than the first range. In an example, the second range may correspond to a lower reliability than the reliability associated with the first range. In an example, a polling indication in an MCCH transmission may indicate whether the WTRU performs a reliability indication procedure and / or a restart procedure. In an example, a WTRU may be configured to monitor multiple reliability metrics and associated trigger conditions. The WTRU may be configured with different actions based on, for example, the particular reliability metric(s) meeting the trigger condition(s). The WTRU may be configured with which action(s) are applicable for (e.g., each) configured reliability metric.

[0175] Disclosed herein is a process associated with a random access response (RAR) associated with a reliability indication. A WTRU may be configured to monitor the RAR, for example, after transmitting a reliability indication (e.g., a reliability indication indicating a reliability indicator such as a reliability metric). The WTRU may be configured to start the RA response window (e.g., ra-ResponseWindow) using a value associated with the reliability indication setting, a value configured as part of RACH-ConfigCommon, or a default value, for example, when the WTRU transmits a pre-configured preamble for reliability indication and / or when the WTRU transmits a preamble in a pre-configured RO for reliability indication. In an example, the WTRU may be configured to monitor an RNTI (e.g., a specific RNTI) to receive an RAR associated with the transmitted reliability indication. The RNTI (e.g., a specific RNTI) may be set to a default RNTI, a (pre-)configured RNTI, or may be set relative to (e.g., specifically) a multicast group. The WTRU may use the RA-RNTI to monitor the RAR, for example, alternatively and / or in the absence of configuration.

[0176] The WTRU may consider (e.g., determine) that the RAR reception has failed, for example, if the ra-ResponseWindow configured for the reliability indication expires and / or if an RAR containing a random access preamble identifier (RAPID) matching the preamble associated with the reliability indication has not been received. The WTRU may consider the RAR reception to have failed, for example, if a valid downlink allocation is received on the PDCCH for the RA-RNTI and / or if the RAR contains a MAC sub-PDU with a back-off indicator. The WTRU may retry transmitting the reliability indication, for example, for a (pre-)configured number of attempts. The WTRU may be configured to initiate a resumption procedure, for example, if the RAR reception has failed, e.g., after a maximum number of attempts. The WTRU may be configured to initiate a resumption procedure, e.g., requesting a transition from an INACTIVE state to a CONNECTED state. The WTRU may be configured with an access category for the resumption procedure, e.g., based on the MBS service type, e.g., as part of the MBS configuration. The WTRU may initiate transmission of an RRCResumeRequest message. The WTRU may be configured to initiate an instance (eg, a new instance) of the RACH procedure for transmission of the RRCResumeRequest message.

[0177] The WTRU may consider the RAR reception successful, for example, if a valid downlink allocation is received on the PDCCH for the RA-RNTI and / or if the random access response contains a MAC sub-PDU with a RAPID corresponding to the transmitted preamble for reliability indication.

[0178] The WTRU may take subsequent actions (eg, if the RAR reception is successful) based, for example, on the MAC sub-PDU (eg, its content).

[0179] For example, if the WTRU receives a random access response including a MAC sub-PDU with RAPID (e.g., with only RAPID), and the RAPID corresponds to a transmitted preamble associated with a reliability indication, the WTRU may consider the reliability indication complete and return to the INACTIVE state. The WTRU may interpret the RAR with the RAPID field (e.g., with only the RAPID field) as an indication (e.g., an implicit indication) that the WTRU can continue to act in accordance with the INACTIVE state and the MBS configuration. The WTRU may support (e.g., guarantee) the QoS requirements for MBS delivery, assuming that the NW does not require other (e.g., additional) information from the WTRU. In an example, the WTRU may be configured with an indication (e.g., an explicit indication) in the RAR that the reliability indication procedure is complete. The WTRU may return to the INACTIVE state and continue to use the MBS configuration (e.g., based on an indication, e.g., an explicit indication). The indication (eg, an explicit indication) may be part of the MAC subheader (eg, a field (eg, a new field) or a reserved field set to 1) and / or part of the RAR payload.

[0180] The WTRU may be configured to receive a random access response including a MAC sub-PDU with a RAPID field corresponding to the reliability indication and an associated RAR payload. The RAR payload format may be specific to the reliability indication. A reserved bit R in the RAR payload may be set (e.g., to 1) to indicate a different format. The timing advance field, UL grant field, and / or temporary CRNTI field may be interpreted differently, for example, when included in the RAR payload in response to a reliability indication. The RAR payload for a reliability indication response may include one or more fields (e.g., along with the performance of a corresponding WTRU action): an indication of whether the WTRU initiates a resumption procedure and / or an indication that the WTRU provides WTRU identity information.

[0181] The WTRU may be configured to initiate (e.g., or not initiate) a resume procedure based on (e.g., based on the condition) receiving an indication (e.g., in the RAR payload) of whether the WTRU should initiate the resume procedure. The WTRU may receive an indication (e.g., whether to initiate a resume procedure) if, for example, the network determines (e.g., based on a reliability indication) that the WTRU should (e.g., needs to) enter the CONNECTED state to meet the QoS requirements of the MBS service. The WTRU may initiate sending an RRCResumeRequest message.

[0182] The WTRU may be configured to provide a WTRU-specific identity to the network (e.g., the WTRU may transmit an I-RNTI), e.g., based on an indication that the WTRU provides a WTRU identity. The I-RNTI value may be used to identify a suspended WTRU context for a WTRU in RRC_INACTIVE. The WTRU may be configured to transmit a shortened version of the I-RNTI (e.g., a shorter I-RNTI value). For example, the NW may determine (e.g., based on a reliability indication) that there is at least one WTRU with an associated reliability metric, but the exact number of WTRUs may be unclear. The NW may determine or be informed of the number of WTRUs, e.g., to determine a scheduling strategy. For example, the NW may adopt or adapt a more conservative approach (e.g., conservative MCS and / or recurrence) for group scheduling and / or the NW may move and / or transition WTRUs to a CONNECTED state for a tighter control and feedback loop. The WTRU may transmit WTRU-specific identification information (e.g., I-RNTI) to enable the NW to determine the number of WTRUs by reliability metric or its range (e.g., a particular reliability metric or its range), for example.

[0183] The WTRU may initiate a procedure, e.g., a procedure following or as a result of a reliability indication procedure. For example, such a procedure may be a restart procedure or a procedure for a WTRU-specific transmission (e.g., as described herein). The WTRU may assume that an RAR received in response to a reliability indication is not WTRU-specific. The WTRU may ignore a timing advance and / or UL grant received in the RAR (e.g., assumed to be not WTRU-specific). The WTRU may be configured to acquire UL resources using a RACH procedure (e.g., if / when the WTRU initiates the procedure). The WTRU may be configured (e.g., as part of the procedure) with respect to the type of RACH procedure to use (e.g., contention-based or contention-free, and / or two-step or four-step RACH procedure). The WTRU may be configured to reset one or more variables associated with the RACH procedure. The one or more variables may be changed, for example, due to the reliability indication transmission. The WTRU may reset variables specific to the RACH procedure (e.g., before sending a resume request message), including, for example, one or more of the following: the type of RACH procedure, a variable indicating 2-step RA or 4-step RA, a preamble transmission counter, power ramping associated with preamble transmission, a scaling factor for backoff, etc.

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

[0185] While the implementations described herein may consider 3GPP-specific protocols, it will be 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 consider LTE, LTE-A, new radio (NR), or 5G-specific protocols, it will be understood that the solutions described herein are not limited to this scenario and may also be applicable to other wireless systems.

[0186] The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium 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, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact discs (CD)-ROM disks and / or digital versatile discs (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

[Claim 1] 1. A wireless transmit / receive unit (WTRU) associated with a multicast broadcast service (MBS), comprising: In a Radio Resource Control (RRC) connected state, sending an indication of interest in receiving the MBS service; receiving RRC release information including one or more MBS Reference Signal Received Quality (RSRQ) thresholds and one or more MBS Reference Signal Received Power (RSRP) thresholds, the RRC release information further indicating that multicast service reception is allowed for the WTRU in an RRC inactive state; Entering the RRC inactive state based on the RRC release information; In the RRC inactive state, determining an RSRQ value for a serving cell and an RSRP value for the serving cell; determining that the RSRQ value of the serving cell is lower than an MBS RSRQ threshold of the one or more MBS RSRQ thresholds and that the RSRP value of the serving cell is lower than an MBS RSRP threshold of the one or more MBS RSRP thresholds; After the determination, initiating an RRC connection resumption procedure, the RRC connection resumption procedure including transmitting an RRC resumption request indicating a resumption reason associated with the initiation of the RRC connection resumption procedure. WTRU comprising a processor configured to:

Images