Reliability Indication for Multicast and Broadcast Services

Abstract

Reliability monitoring and indication may be provided for multicast and broadcast services (MBS). The WTRU may receive an MBS configuration for an INACTIVE state (e.g., suspend PTP and maintain PTM for split MRBs). The MBS and suspend configurations may be associated with different areas (e.g., MBS area versus 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 receive an MBS transmission (e.g., on MRB(s)), receive an MCCH (e.g., due to trigger(s) for a reliability indication during an MCCH modification period), determine reliability metric(s) associated with the MBS TB reception, monitor the reliability metric(s) during time interval(s) of the MCCH modification period(s), select an RA resource (e.g., per mapping between resource and reliability metric value / range), indicate the reliability metric (e.g., transmit a reliability indication via a selected preamble and RO), and / or monitor an RAR format in response to the reliability indication transmission.

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 on August 3, 2021, the disclosure of which is incorporated herein by reference in its entirety.

Background Art

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

Summary of the Invention

[0003] Systems, methods, and means related to reliability indication of 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., can be implemented by or in relation to a wireless transmit / receive unit (WTRU)). The reliability indication can be, for example, an indication associated with transmission reliability determined by a WTRU, based on whether the WTRU receives transmissions (plural) (e.g., MBS transmissions (plural) such as MBS transport blocks (plural)). The reliability indication can include or indicate a reliability metric (e.g., a reliability metric) and / or a determined value and / or range of the reliability metric. One or more of the following can apply.

[0005] 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 an interruption configuration (e.g., SuspendConfig) indication, where SuspendConfig is 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 with respect to a radio access network (RAN) area. The MBS configuration information can include and / or indicate one or more of multicast radio bearer (MRB) configuration information for the INACTIVE state, one or more triggers for reliability indication, setting of reliability metrics, or setting of reliability indication.

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

[0007] Triggers for reliability indication may be associated with one or more of the following. Triggers for reliability indication may indicate whether the reliability monitoring and / or reliability indication is periodic, event-triggered, polling-based, etc. One or more triggers for reliability indication may be indicated, for example, in polling configuration information, event-based configuration information, and / or periodic configuration information. Polling configuration information may be associated with a multicast control channel (MCCH). Polling configuration information associated with the MCCH may indicate to the WTRU, for example, for a particular MBS service, to perform a reliability indication, such as by signaling identification information associated with such an 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. Event-based configuration information may indicate to perform a reliability indication, for example, when one or more thresholds associated with a reliability metric are met. Triggers for performing a reliability indication may be indicated in a periodic configuration. For example, the periodic configuration information may be received every n change periods (n may be a fraction or 1 or more (≥)).

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

[0009] The reliability indication setting information can be associated with one or more of the following. The reliability indication setting information can indicate one or more resources for reliability indication, which can include, for example, one or more random access (RA) preambles, opportunities (ROs) of a random access channel (or procedure) (RACH) (e.g., related to an MCCH change boundary), an association between an RA resource and a reliability metric (e.g., or within its scope), etc., one or more of which can be included.

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

[0011] The WTRU can receive an MCCH transmission. The MCCH transmission can include or indicate a polling request for reliability indication. The MCCH transmission is received according to a GRNTI and / or can include a polling request. The MCCH transmission can be received during a time interval (e.g., MCCH change period n). Support information (e.g., additional support information) can be received for reliability monitoring. The support information can include, for example, the expected number of MBS transport blocks (TBs) within a change period. Activation and / or deactivation of periodic reliability indication can be received, for example, via a media access control (MAC) control element (CE).

[0012] The WTRU can determine one or more reliability metrics associated with the received MBS transmission (e.g., MBS TB reception in the INACTIVE state).

[0013] The WTRU can monitor one or more reliability metrics during a time interval, such as a time interval associated with an MCCH change period (e.g., MCCH change period n+1).

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

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

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

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

[0018] An 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 an MCCH transmission that indicates a polling request. If the WTRU successfully decodes an MCCH transmission, the WTRU may be triggered to measure one or more values of a reliability metric based on the receipt of the polling request. For example, the measurement of one or more values of the reliability metric may be based on information included in the MCCH transmission. During an MCCH change period n+1, multiple MCCH transmissions may be sent (e.g., by the network) for example, for each repetition period. An MCCH transmission sent during an MCCH change period n+1 may, if successfully decoded, include a polling request that triggers the measurement of one or more values of a reliability metric during the next MCCH change period (e.g., MCCH change period n+2). The WTRU may be able to determine a PRACH resource for transmitting a preamble based on the determined value of the reliability metric. As shown in Figure 2, after an MCCH change period n+1, the value of the reliability metric may be indicated by transmitting a preamble using the determined PRACH resource.

[0019] As an example, a WTRU may be configured to receive MBS settings associated with the RRC INACTIVE state in the RRC CONNECTED state. The MBS settings may include one or more triggers for reliability indication, a mapping between a range of reliability metrics and UL resources for reliability metric indication. When entering the RRC INACTIVE state, the WTRU may interrupt 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 reliability indication, for example, via a GRNTI. The WTRU may receive an MCCH transmission having a polling request for reliability indication during an MCCH change period n. The polling request may be associated with a specific MBS bearer and may provide assistance information, for example, the number of MBS transport blocks within change period n+1. The WTRU may determine a reliability metric during a time interval associated with MCCH change period n+1. For example, the reliability metric may be a ratio of the number of properly received MBS transport blocks to the total number of MBS transport blocks transmitted during the change 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 an RAR format associated with the reliability indication. Upon receiving an RAR that matches the reliability indication, the WTRU may perform one or more actions, such as performing another RA procedure to initiate a resume procedure or remaining in RRC INACTIVE to receive the MBS service, based on the received RAR.

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

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

[0022] Reliability monitoring may be performed on a shorter time scale, for example, based on a duration that can be tracked (e.g., via a timer). In an example, the shorter time scale may be a time shorter than the length of a change period (e.g., an MCCH change period). For example, when / if the WTRU receives polling, the duration may be tracked (e.g., a timer may be started). The WTRU may be able to send a reliability indication on the earliest available RO, for example, based on expiration of the duration (e.g., expiration of a timer).

Brief Description of the Drawings

[0023]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Best Mode for Carrying Out the Invention

[0024] Systems, methods, and means for multicast and broadcast service (MBS) reliability indication are described herein. A WTRU can receive an MBS configuration for an INACTIVE state (e.g., interrupt point-to-point (PTP) for a split multicast radio bearer (MRB) and maintain point-to-multipoint (PTM)). The MBS configuration and interruption configuration can be associated with different areas (e.g., an MBS area for a radio access network (RAN) area). The configuration can 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) can, for example, receive an MBS transmission (e.g., on an MRB(s)), receive a multicast control channel (MCCH) (e.g., by a trigger(s) for reliability indication during an MCCH change period), determine a reliability metric(s) associated with MBS transport block (TB) reception, monitor the reliability metric(s) during a time interval(s) of an MCCH change period(s), select a random access (RA) resource (e.g., for each mapping between a resource and a reliability metric value / range), indicate the reliability metric (e.g., transmit a reliability indication via a selected preamble and a random access channel (or procedure) (RACH) opportunity (RO)), and / or monitor a random access response (RAR) format in response to the reliability indication transmission.

[0025] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of 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 Filter-Type OFDM, Filter Bank Multi Carrier (FBMC).

[0026] As shown in FIG. 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, a 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 the WTRUs 102a, 102b, 102c, 102d can 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, which may all be referred to as "stations" and / or "STAs", can be configured to transmit and / or receive wireless signals and can be user equipment (UE), mobile stations, fixed or mobile telephone subscriber units, subscriber-based units, pager, mobile telephone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable, head-mounted display (HMD), vehicle, drone, medical device and application (e.g., for remote surgery), industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), home appliance device, device operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0028] Base station 114a may be part of RAN 104 / 113 and may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), a relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals at 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 coverage for wireless services in a particular geographic area that may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may use multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0029] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via 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.). Air interface 116 may be established using any suitable radio access technology (RAT).

[0030] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0031] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can 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 radio technologies such as NR radio access, which can 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 implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by transmissions to / from multiple types of radio access technologies and / or 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 wireless technologies such as IEEE802.11 (i.e., Wireless Fidelity (WiFi)), IEEE802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0035] The base station 114b in Fig. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (e.g., for use by a drone), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 can implement a wireless 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in Fig. 1A, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

[0037] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, and these networks and devices use a common communication protocol 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 that may employ the same RAT as the RAN104 / 113 or a different RAT.

[0038] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may use cellular-based wireless technology and a base station 114b that may use IEEE802 wireless technology.

[0039] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0040] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120 which may be coupled to the transmit / receive element 122. Although Figure 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 a base station (e.g., base station 114a) via the air interface 116 or receive signals from the base station (e.g., base station 114a). For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0042] The transmit / receive element 122 is illustrated in FIG. 1B as a single element, but the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via 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 noted 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 the speaker / microphone 124, keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) from which it may receive data input by a user. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the 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, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0047] Processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 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 / Augmented Reality (VR / AR) device, an activity tracker, etc. The peripheral devices 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 in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both 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 for reducing and / or substantially eliminating self-interference either through hardware (e.g., choke) or signal processing via a processor (e.g., via a separate processor (not shown) or via processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio for the transmission and reception of some or all of any of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

[0051] Each of 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 UL and / or DL. As shown in Figure 1C, eNode-Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0052] CN 106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is shown as part of 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 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 may perform roles such as authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions 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 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. Generally, the SGW 164 can route and transfer user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNode Bs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and the function of managing and storing the context of the WTRUs 102a, 102b, 102c.

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

[0056] CN106 can facilitate communication with other networks. For example, CN106 may provide access to a circuit-switched network such as the PSTN 108 to the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and the PSTN 108. Additionally, CN106 may provide the WTRUs 102a, 102b, 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0057] The WTRU is described as a wireless terminal in FIGS. 1A-1D, but in certain representative embodiments, it is contemplated that such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a 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 an interface to another type of wired / wireless network that carries traffic entering and / or exiting the Distribution System (DS) or BSS. Traffic destined for an STA that originates outside the BSS may reach and be delivered to the STA through the AP. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and delivered to their respective destinations. Traffic between STAs within the BSS may, for example, be sent through the AP, where the source STA may send the traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent with a Direct Link Setup (DLS) directly between the source STA and the destination STA (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have 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 the "ad hoc" communication mode.

[0060] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA 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) can be implemented. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0061] High Throughput (HT) STAs can use a 40 MHz wide channel for communication, and this 40 MHz wide channel can be formed, for example, via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

[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 a plurality of consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels, which may be referred to as an 80 + 80 configuration. In the case of 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 for 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 above - described operations for the 80 + 80 configuration may be reversed and the combined data may be transmitted to the Medium Access Control (MAC).

[0063] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro coverage area. The MTC device may have limited capabilities, including specific capabilities, e.g., support for a specific and / or limited bandwidth (e.g., support only therefor). The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0064] A WLAN system that can support a plurality of channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In the example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only that) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA transmitting to the AP (supporting only the 1 MHz operation mode), the entire available frequency band may be considered busy even though most of the frequency band remains idle and available.

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

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

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

[0068] WTRU 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable numerical structure. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using sub-frames or Transmission Time Intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0069] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (such as eNode-Bs 160a, 160b, and 160c). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNode-Bs 160a, 160b, and 160c may function as a mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, and 102c.

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

[0071] As shown in FIG. 1D, CN 115 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is shown as part of CN 115, it should be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

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

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

[0074] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, processing user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0075] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN115 and the PSTN 108. Additionally, CN115 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] Referring to FIGS. 1A - 1D and the corresponding descriptions thereof, one or more of the functions described herein with respect to one or more of the WTRUs 102a - d, base stations 114a - b, eNode - Bs 160a - c, MME 162, SGW 164, PGW 166, gNBs 180a - c, AMFs 182a - b, UPFs 184a - b, SMFs 183a - b, DNs 185a - b, and / or any other device(s) described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

[0078] One or more emulation devices can perform one or more functions, including all, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to perform tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by an emulation device to transmit and / or receive data.

[0079] Settings (plural) referred to in this specification, such as settings received in a WTRU, can refer to setting information.

[0080] This specification is provided for illustrative purposes and is not intended to limit in any way 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 nodes within 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 that may be exemplified by an RRC state (e.g., one of a plurality of states). Radio resource control (RRC) may have a plurality of states that may include the RRC INACTIVE state. A WTRU in the IDLE state may be able to conserve the WTRU's battery resources, e.g., if the WTRU has not been active for a given period of time (e.g., data has not been transmitted or received). In IDLE, the WTRU cannot continuously monitor the physical downlink control channel (PDCCH). Transitioning the WTRU between the CONNECTED state and the IDLE state may cause control plane signaling in the network, e.g., if the WTRU's data is intermittent (e.g., if a smartphone transmits small amounts of data frequently). Signaling to transition the WTRU from the IDLE state to the CONNECTED state may involve a radio access network (e.g., gNB) and / or a core network (CN), e.g., 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 across the geographical area (e.g., the entire geographical area) in which the WTRU is registered (e.g., via a gNB / cell within the geographical area), e.g., if the transition to the CONNECTED state is triggered by downlink (DL) data or an incoming voice call.

[0082] Frequent transitions from IDLE to CONNECTED may have significant signaling overhead. The WTRU may have a bearer that infrequently transmits data 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 the WTRU is not actively (e.g., and frequently) transmitting or receiving data.

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

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

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

[0086] (For example, in the case of a RAN area update) The network can transmit (e.g., immediately transmit) the WTRU back to the INACTIVE state, for example, by transmitting an RRC Release message. The RRC Release message may include, for example, WTRU resume identification information (e.g., new WTRU resume identification information), RAN area configuration, security, and / or paging configuration.

[0087] The network can transmit (e.g., in response thereto), for example, an RRC Resume message (alternatively) to indicate to the WTRU to resume the radio connection. Uplink and / or downlink (UL / DL) transmissions can proceed (e.g., immediately thereafter), for example, as shown in the example of Figure 3. The signaling shown in Figure 3 can be compared to the signaling for setting up a connection from the IDLE state (e.g., as previously described). Resuming from the INACTIVE state can save WTRU and network signaling. The CN may not be involved in the resume. Latency can be avoided, for example, from the perspective of the WTRU.

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

[0089] A Multimedia Broadcast Multicast System (MBMS) service can be delivered via wireless. The MBMS service can be provided according to several methods that can 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) per cell according to, for example, the user distribution. SC-PTM can use, for example, a common RNTI (e.g., group-RNTI) for a group of users to transfer broadcast / multicast services using an LTE downlink shared channel (e.g., physical downlink shared channel (PDSCH)). SC-PTM scheduling can be agile. Radio resources can be allocated (e.g., dynamically allocated) in the time domain and frequency domain by PDCCH signaling based on, for example, the real-time traffic load (e.g., per transmission time interval (TTI)). SC-PTM may be suitable for scenarios where broadcast / multicast services are distributed (e.g., expected to be distributed) to a limited number of cells due to, for example, user interest. The relevant cells may change (e.g., change dynamically) due to, for example, user movement. SC-PTM can support (e.g., enable) efficient radio utilization and / or flexible deployment for some applications (e.g., critical communication, traffic information for vehicles, on-demand TV services, etc.).

[0091] MBSFN can provide transmissions from different cells that are configured to be the same and / or time-aligned, such that, for example, transmissions from different cells appear as a single transmission from the perspective of the WTRU. An MBSFN synchronization area can be defined, for example, to enable time synchronization between eNBs. An MBSFN area can include a group of cells within the MBSFN synchronization area of the network that can be coordinated to achieve MBSFN transmissions. The MBMS architecture can include (e.g., define) various logical entities for implementing network functions applicable to MBMS transmissions. A multi-cell / multi-cast coordination entity (MCE) can perform admission control, determine whether to use SC-PTM or MBSFN, and perform functions such as suspension and resumption for MBMS services. An MBMS gateway (MBMS-GW) can perform session control signaling and transfer MBMS user data to the eNB (e.g., via IP multicast).

[0092] MBMS can be implemented in a radio system such as New Radio (NR). MBMS can be referred to as Multi-cast and Broadcast Services (MBS). The terms MBMS and MBS can be used interchangeably herein.

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

[0094] A WTRU may be configured for the delivery of MBS services (e.g., the configuration of the WTRU may be set for the 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 transmission mode to exchange MBS-related data. The WTRU may have other (e.g., further) configuration aspects for the delivery of MBS services. The configurable aspects may include, for example, the mapping of data (e.g., and / or signaling) bearers for the set transmission method(s) (if any) for exchanging MBS-related data (e.g., L2 bearer settings for MBS). For example, the WTRU may be configured for mixed mode transmission (e.g., unicast and multicast) using the delivery of MBS data implemented using multicast transmission and / or broadcast transmission (e.g., multicast transmission 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) using the delivery of MBS data implemented using unicast transmission (e.g., so-called point-to-point (PTP) transmission / mode) and / or multicast transmission (e.g., so-called 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).

[0095] MBS (e.g., NR MBS) can support one or more of the use cases such as V2X, sidelink, and / or public safety (e.g., a 3GPP system may distribute information to a large number of WTRUs supporting V2X applications in a resource-efficient manner), Internet of Things (IoT) for devices 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., advertisements and / or weather forecasts), Ethernet broadcast / multicast (e.g., for factory automation), and / or augmented reality and / or group games. The TV video and radio services supported by MBS can include, for example, linear TV, live, smart TV, managed and / or over-the-top (OTT) content delivery, and / or radio services, video delivery (e.g., when multiple users watch the same live streaming simultaneously), large peaks in the 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 conventional flat video, or even 360-degree video).

[0096] The MBS service can support application-level retransmission. The reliability and efficiency trade-off provided by the application-level method may be costly (e.g., from the perspective of spectral efficiency). The application-level method may not support lower latency requirements (e.g., it may be insufficient to meet this requirement). Different MBS services may have different latency, efficiency, and reliability requirements. For example, power grid distribution can be implemented with a 5 ms delay and a packet error rate of 10~6. V2X can be implemented to have a 20 ms latency for information sharing between the WTRU and the road side unit (RSU). Mission critical push-to-talk (MCPTT) can be implemented using key performance indicators (KPIs) such as a 300 ms mouth-to-ear latency.

[0097] The WTRU can 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 the MBS service delivery to those WTRUs, for example, due to the 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., the NR network) can implement various MBS services with increased reliability compared to other (e.g., conventional) services via MBS. The MBS performance can be improved. For example, the improved reliability may be provided in RRC states such as the RRC INACTIVE state (e.g., other than the RRC CONNECTED state).

[0098] Wireless technologies / systems (e.g., new radio (NR)) may support multiple (e.g., two) delivery modes for MBS. For example, a first delivery mode (e.g., delivery mode 1) may provide high quality of service (QoS) in terms of, e.g., reliability, latency, and / or other criteria. A second delivery mode (e.g., delivery mode 2) may provide low QoS (e.g., compared to delivery mode 1) in terms of, e.g., reliability, latency, and / or other criteria. In an example, delivery mode 1 may be supported for multicast services and / or delivery mode 2 may be supported for broadcast services. In an example (e.g., with respect to the radio resource control (RRC) state), delivery mode 1 may be supported for a state (e.g., the connected (CONN) state) and / or delivery mode 2 may be supported for multiple (e.g., all) RRC states. A WTRU with multicast may be made capable of entering the INACTIVE state, which can support improved power consumption / overhead and / or can be used as a means to reduce congestion. A WTRU in the INACTIVE state may not provide feedback (e.g., have no means to provide it) (e.g., without significant overhead). There may be one or more constraints. A WTRU in INACTIVE may not be uplink (UL) synchronized. The number of WTRUs in INACTIVE receiving MBS services may be significant. It may not be feasible or desirable to allocate WTRU-specific resources for feedback.

[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 relation to a WTRU). The reliability indication may be an indication associated with transmission reliability, determined, for example, by a WTRU, based on whether the WTRU receives one or more transmissions (e.g., MBS transmissions such as MBS transport blocks). The reliability indication may include or indicate a reliability metric (e.g., a reliability metric) and / or a determined value and / or range of the reliability metric. 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 an interruption configuration (e.g., SuspendConfig) indication, where SuspendConfig is 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), where, for example, the logical area may be an MBS area relative to a RAN area. The MBS configuration information can include and / or indicate one or more of multicast radio bearer (MRB) configuration information for the INACTIVE state, one or more triggers for reliability indication, reliability metric configuration, or reliability indication configuration.

[0101] The MRB configuration information regarding the INACTIVE state can be indicated using one or more of the following. For example, if MBS reception is permitted in the INACTIVE state, the WTRU may interrupt the point-to-point (PTP) leg (e.g., conditional on entering the INACTIVE state and / or under that condition), and / or maintain the point-to-multipoint (PTM) leg for split MRB. After entering the INACTIVE state, the WTRU may keep one or more MBS bearers active. The WTRU may interrupt other bearers (e.g., non-MBS bearers and / or MBS bearers different from one or more MBS bearers configured to be active in the INACTIVE state).

[0102] Triggers for reliability indication may be associated with one or more of the following. Triggers for reliability indication may indicate whether reliability monitoring and / or reliability indication is periodic, whether it is of an event trigger type, whether it is polling-based, etc. One or more triggers for reliability indication may be indicated, for example, in polling configuration information, event-based configuration information, and / or periodic type configuration information. Polling configuration information may be associated with a multicast control channel (MCCH). Polling configuration information associated with the MCCH may indicate to the WTRU to perform a reliability indication, for example, by signaling identification information associated with a particular MBS service, such as for such an 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. Event-based configuration information may indicate to perform a reliability indication, for example, when one or more thresholds associated with a reliability metric are met. Triggers for performing a reliability indication may be indicated in a periodic type configuration. For example, the periodic type configuration information may be received every n change periods (n may be a fraction or 1 or more (≥)).

[0103] Reliability metric configuration information may be associated with one or more of the following. Reliability metric configuration information may include, for example, one or more of the type of reliability metric, such as statistical values associated with an MBS channel quality indicator (CQI) and / or a block error rate (BLER), the number of repetitions relative to the expected (e.g., total) number of transmissions within an MCCH change period.

[0104] The reliability indication setting information can be associated with one or more of the following. The reliability indication setting information can indicate one or more resources for the reliability indication, which can include, for example, one or more random access (RA) preambles, an opportunity (RO) of a random access channel (or procedure) (RACH) (e.g., related to an MCCH change boundary), an association between an RA resource and a reliability metric (e.g., or within its scope), etc., including one or more of them.

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

[0106] The WTRU can receive an MCCH transmission. The MCCH transmission can include or indicate a polling request for the reliability indication. The MCCH transmission is received according to a GRNTI and / or can include a polling request. The MCCH transmission can be received during a time interval (e.g., MCCH change period n). Support information (e.g., additional support information) can be received for reliability monitoring. The support information can include, for example, the expected number of MBS transport blocks (TBs) within the change period. Activation and / or deactivation of periodic reliability indication can be received, for example, via a media access control (MAC) control element (CE).

[0107] The WTRU can determine one or more reliability metrics associated with the received MBS transmission (e.g., MBS TB reception in the INACTIVE state).

[0108] The WTRU can monitor one or more reliability metrics during a time interval, such as a time interval associated with an MCCH change period (e.g., MCCH change period n+1).

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

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

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

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

[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 the polling request. If the WTRU successfully decodes the MCCH transmission, the WTRU may be triggered to measure one or more values of a reliability metric based on the receipt of the polling request. For example, the measurement of one or more values of the reliability metric may be based on information included in the MCCH transmission. During the MCCH change period n+1, multiple MCCH transmissions may be transmitted (e.g., by the network) for each repetition period, for example. The MCCH transmission transmitted during the MCCH change period n+1 may include, if successfully decoded, a polling request that triggers the measurement of one or more values of the reliability metric during the next MCCH change period (e.g., MCCH change period n+2). The WTRU may be able to determine a PRACH resource for transmitting a preamble based on the determined value of the reliability metric. As shown in Figure 2, after the MCCH change period n+1, the value of the reliability metric may be indicated by transmitting a preamble using the determined PRACH resource.

[0114] As an example, the WTRU may be configured to receive MBS settings associated with the RRC INACTIVE state in the RRC CONNECTED state. The MBS settings may include a mapping between one or more triggers for reliability indication, a range of reliability metrics, and UL resources for reliability metric indication. When entering the RRC INACTIVE state, the WTRU may interrupt 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 reliability indication, for example, via a GRNTI. The WTRU may receive an MCCH transmission having a polling request for reliability indication during an MCCH change period n. The polling request may be associated with a specific MBS bearer and may provide assistance information, for example, the number of MBS transport blocks within change period n+1. The WTRU may determine a reliability metric during a time interval associated with MCCH change period n+1. For example, the reliability metric may be the ratio of the number of received normal MBS transport blocks to the total number of MBS transport blocks transmitted during the change 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 an RAR format associated with the reliability indication. Upon receiving an RAR that matches the reliability indication, the WTRU may perform one or more actions, such as performing another RA procedure to initiate a resume procedure or remaining in RRC INACTIVE to receive the MBS service, based on the received RAR.

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

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

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

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

[0119] A WTRU configured for receiving data for MBS may have a data radio bearer (DRB), such as a multicast radio bearer (MRB), set up. The DRB may be dedicated for MBS reception. The MBS service and the MRB may be used interchangeably (e.g., considered equivalent), for example, from the perspectives of L2 and L3. The MBS service may have 0, 1, or two or more MRBs set up.

[0120] The terms "INACTIVE" or "INACTIVE state" can refer to the WTRU performing one or more (e.g., or a set) of the following: monitoring short messages transmitted with the paging radio network temporary identifier (P-RNTI) on downlink control information (DCI); monitoring the paging channel for CN paging (e.g., using the 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 control mobility based on network (NW) configuration (e.g., cell (re)selection); performing RAN-based notification area updates periodically and / or when moving out of a set RAN-based notification area; or obtaining system information and / or transmitting SI requests (e.g., when set).

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

[0122] One or more information elements and / or set parameters can be described herein without limitation in various examples with respect to RRC configuration. The techniques described herein can be applicable to other configurations (e.g., any configuration), default configurations, specified 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 signals).

[0123] The bearer configuration and / or architecture can be provided for MBS in INACTIVE. A WTRU (e.g., configured for receiving data for MBS) can have a data radio bearer (DRB) that can be dedicated to MBS reception (e.g., via a multicast radio bearer (MRB)). The MBS service and the MRB can be used interchangeably (e.g., considered equivalent) from, for example, the L2 and L3 perspectives. The MBS service can be such that no MRB can be configured, or one or more MRBs can be configured.

[0124] MRBs having several QoS flows (e.g., similar to DRBs) can be multiplexed within an MRB (e.g., a given MRB). The MRB can adopt a split bearer protocol architecture having, for example, one packet data convergence protocol (PDCP) entity and two radio link control (RLC) entities. For example, as shown by the example of FIG. 4, the first RLC entity can be for PTM, and the second RLC entity can 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) can identify (e.g., uniquely identify) the RRC connection of a WTRU within a cell, and a group RNTI (G-RNTI) can identify the group of WTRUs participating in a multicast. (E.g., according to the exemplary architecture shown in FIG. 4) A WTRU with an MRB configured can monitor DL scheduling for the MRB on the C-RNTI and / or G-RNTI. In the example, the RLC entity associated with PTM can operate in the unacknowledged mode (UM), while the RLC entity associated with PTP can operate in the acknowledged mode (AM). The techniques (e.g., methods) disclosed herein can be applied to other operating modes (e.g., PTM operating in the transparent mode (TM) or AM, or PTP operating in TM or UM). In the example, the WTRU can be configured to interrupt PTP operation while transitioning to the INACTIVE state while maintaining PTM operation. For example, the WTRU can 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 can release the RLC entity associated with the PTP RLC entity of the MRB. The WTRU can reconfigure (e.g., implicitly reconfigure) the MRB to PTM, e.g., if the NW indicates that MBS reception is permitted in the INACTIVE state (e.g., only in that case).

[0127] An INACTIVE WTRU (which can refer to a WTRU that is INACTIVE in the present specification, for example) can initiate a resume procedure to indicate, for example, a request from the WTRU to the network for an MBS service (for example, a reliable MBS service). The resume procedure can be implemented by transmitting an RRCResumeRequest that can include, for example, a resume reason (for example, mbs - call - interest) and / or information about MBS session identification (for example, when several MBS sessions are active simultaneously). In an example, the INACTIVE WTRU can include a preference indication that can indicate whether the WTRU desires to remain in the INACTIVE state or desires to transition to the CONNECTED state for MBS service delivery. In an example, the INACTIVE WTRU (which transmitted the request to be resumed, for example, the resumed request) can receive a response message from the network and resume the connection (for example, RRCResume). The WTRU can receive an RRC re - configuration message (for example, thereafter) and configure the MRB(s) (for example, the required MRB(s)).

[0128] (For example, the resumed request, for example, the INACTIVE WTRU that transmitted the request to be resumed) can receive a response message from the network and resume the connection (for example, RRCResume). The response message can include the configuration of the MRB(s) (for example, the requested MRB(s)). The WTRU can apply the MRB configuration (for example, the required MRB configuration). The WTRU can remain in the INACTIVE state. The WTRU can receive MBS data, for example, according to the MRB configuration.

[0129] A WTRU in the CONNECTED state with MRB configuration (e.g., the MRB may or may not be active at that time) may transition (e.g., transmit) to the INACTIVE state (e.g., via a network message, e.g., an RRC release message). An indication (e.g., within 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 a new or updated MRB configuration when, for example, a WTRU in the CONNECTED state is put into the INACTIVE state.

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

[0131] (An INACTIVE WTRU having a split bearer configuration, such as one RLC AM entity associated with a C-RNTI and another RLC UM entity associated with a G-RNTI, etc., may interrupt 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] A configured permission that can be used for reception of MBS data while the WTRU is in the INACTIVE state may be set. For example, a periodic permission setting may indicate which radio resources (e.g., time and / or frequency) contain data for the MBS session(s). In an example, the configured permission for MBS reception may be provided while the WTRU is in the CONNECTED state. The configured permission may be provided (e.g., as part of it) based on the transition to the INACTIVE state (e.g., within the RRC release message).

[0133] Features associated with reliability monitoring and / or reliability indication are described herein and may be associated with the INACTIVE state. A reliability metric (e.g., a reliability metric) may be associated with the reliability indication (e.g., the reliability metric may be provided or indicated in the reliability indication). The term "configured to" herein may indicate (e.g., may include) that the associated device (e.g., the WTRU) performs the 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 MBS reception. The WTRU may be configured to derive an MBS CQI index. For example, each MBS 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 MBS transmission can be received with a transport block error probability not exceeding a pre-set 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. And a transport block received with a transport block error probability not exceeding a pre-set value may be determined by the WTRU to correspond to the CQI index that occupies a group of downlink physical resource blocks (e.g., MBS reference resource). The MBS reference resource may be pre-set within the MBS bandwidth part (e.g., using a specific numerical structure). For example, the transport block error probability may be pre-set for the WTRU (e.g., especially for the calculation of MBS CQI). This setting may be specific to the MBS service. The WTRU may have a CQI table set (e.g., specific to the reliability indication). For example, the CQI index (e.g., each CQI index) may be 4 bits and / or may be mapped to a specific modulation and coding rate (e.g., for a given MBS block error rate (BLER) setting). 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 CQI index from 0 to 7 may be set for the WTRU. For example, the CQI index from 0 to 6 may correspond to a (e.g., conventional) CQI table, and the CQI index of 7 may indicate a CQI value exceeding 6 (e.g., any CQI value exceeding 6).

[0135] The WTRU may be configured to measure the MBS CQI within a pre-set range of CQI values. For example, the first CQI range may be set as CQI indices 1 to 6, the second CQI range may be set as CQI indices 7 to 9, the third CQI range may be set as CQI indices 10 to 15, and so on.

[0136] In an example, the WTRU may be configured to measure (e.g., and / or determine) whether the MBS CQI is below 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 number of repetitions of the MBS transport block may be set for the WTRU (e.g., the WTRU may receive an indication of the number of repetitions). The WTRU may be configured to perform an incremental redundancy combination over the repetitions of the MBS transport block. The WTRU may be configured to disable HARQ feedback, for example, while in the INACTIVE state (e.g., under the condition of being in the INACTIVE state). The WTRU may be configured to maintain statistics related to the number of generated NACKs, for example, for the purpose of calculating a reliability metric, until the transport block is successfully decoded. The WTRU may be configured to measure a statistical value related to the number of NACKs within a pre-set time interval.

[0138] The WTRU may be configured to monitor a statistical value associated with the number of repetitions associated with the successful decoding of the MBS transport block.

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

[0140] The WTRU may be configured to monitor a maximum number of repetitions for successful decoding of MBS transport blocks (e.g., used, required, etc.). The WTRU may (alternatively and / or additionally, for example) be configured to calculate a reliability metric based on the maximum number if, for example, 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 the threshold.

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

[0142] The reliability metric may be based on the 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 as a function of the number of CRC errors (e.g., within a time interval), for example.

[0143] The WTRU may be configured to determine an MCH BLER estimate based on an evaluation of the status of the CRC check results 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 a CRC error and the total number of received (e.g., expected to be received) MBS transport blocks (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) in relation to the MCCH change period. In an example, the time interval may be tracked based on, for example, a pre-set timer.

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

[0145] A reliability metric can be based on one or more reference signal (RS) measurements. A WTRU can determine (e.g., be configured to determine) a reliability metric based on one or more reference signal measurements. For example, the WTRU may measure (e.g., be configured to measure) the MBSFN reference signal received power (MBSFN RSRP). The MBS RSRP can be defined (e.g., and / or determined) as, for example, a (e.g., linear) average over the power contribution of the resource elements carrying the MBS reference signal within the measurement frequency bandwidth being considered (e.g., in units of Watts (W)). 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 can be defined (e.g., and / or determined) as, for example, the ratio N×MBS RSRP / (MBS carrier reference signal strength indicator (RSSI)) (e.g., where N may be the number of resource blocks in the MBS carrier RSSI measurement bandwidth). The measurements in the numerator and denominator can be made on the same set of resource blocks. The MBS carrier RSSI can include, for example, 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 the antenna port configured for MBS transmission over N resource blocks (e.g., within a pre-set MBS measurement bandwidth). The power can include power from one or more (e.g., all) sources such as the serving and non-serving cells of the same channel, adjacent channel interference, thermal noise, etc.

[0147] Reliability monitoring may be associated with a reliability indication. A WTRU may be configured to perform a reliability monitoring procedure, which may include one or more of: measuring one or more reliability metrics; maintaining a counter associated with the reliability metric; determining a statistical value associated with the reliability metric; monitoring the value(s) of one or more reliability metrics and comparing the metric(s) or value(s) to one or more thresholds (e.g., pre-set thresholds); or triggering the transmission of a reliability indication to the network (e.g., based on the metric(s) or value(s) meeting a threshold condition, such as a trigger condition). The WTRU may be configured to perform the monitoring procedure over a pre-set time interval. The time interval may be set (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 by) 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 the MCCH repetition period. In an example, the time interval may correspond to the MCCH change period. In an example, the time interval may be defined in relation to the MCCH change period. In an example, this relationship may be expressed in terms of an offset. In an example, the time interval may be defined in relation to the RAN paging interval. The WTRU may be configured to transmit 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 can continue over an evaluation period. For example, the WTRU may be configured to evaluate an average CQI (e.g., over an evaluation period). The WTRU can continue to measure the CQI over a duration, average the measured CQIs, and compare the average value to a provided threshold. In an example, the WTRU may be provided with a scaling factor that can be used to calculate and / or aggregate the condition. For example, a value measured at the start of the evaluation period may be assigned a higher weight than a value 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 criterion has already been met. For example, the WTRU may be configured to detect whether more than a particular (e.g., configured, determined, set, or selected) number of failures are detected. The WTRU can stop monitoring the number of failures, for example, if the WTRU detects a set number of failures before the evaluation period ends.

[0150] The WTRU may be configured to perform reliability monitoring, for example, when at least one MRB is active (e.g., set to be active) during an INACTIVE state. In an example, the WTRU can receive settings associated with the reliability monitoring as part of the MRB settings or as part of the INACTIVE settings (e.g., suspendConfig). The WTRU may be configured to apply the reliability settings, for example, when at least one MRB is active (e.g., set to be active), based on, for example, entering the INACTIVE state (e.g., based thereon) and / or based on applying an interruption setting (e.g., based thereon).

[0151] In an example, the WTRU may be configured to perform reliability monitoring in the INACTIVE state when, for example, the WTRU receives a reliability polling (e.g., a polling request) from the network. The reliability polling may be received in an MCCH transmission. The reliability polling may be received in an MCCH change notification. The reliability polling may be received in a RAN paging message. The reliability polling 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 a MAC CE.

[0152] Based on receiving a reliability polling during an MCCH change period n, the WTRU may, for example, start reliability monitoring during a time window corresponding to change period n+1. In an example, the WTRU may be configured to start / track a duration based on receiving the polling (e.g., via a timer) 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, the 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 via, for example, RRC configuration, MAC CE, etc. The MBS radio bearer and / or the MBS service may be identified, for example, by group identification information, RNTI, etc. The WTRU may be able to measure a reliability metric for, for example, an MBS transport block associated with the MBS service (e.g., only for the MBS transport block associated with the MBS service). The transport block may be scheduled, for example, via a configured group's RNTI.

[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., conditional upon) the WTRU exiting 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 reliability monitoring and / or reliability indication procedures based on (e.g., conditional upon) one or more of: reselection to a cell outside of the MBS area configured for the WTRU; reselection to a cell outside of the current RAN area applicable to the INACTIVE state; reselection to a cell that does not support MBS services; reselection to a cell that does not support an MBS service that the WTRU may currently be configured for; or reselection to a cell that does not support reliability monitoring and / or indication procedures.

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

[0157] The trigger for the reliability indication may be based on, for example, polling in an MCCH transmission. The WTRU may trigger the transmission of a 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 during each MCCH repetition period within an MCCH change period. For example, an MCCH transmission received during change period n may notify the WTRU about actions to be performed in a subsequent MCCH change period (e.g., a period greater than (>n) period n). The WTRU may be configured to perform reliability monitoring in change period n + k. The WTRU may be configured to perform reliability indication transmission in change period n + l (l>k (e.g., k = 1 and l = 2)).

[0158] The WTRU may receive a reliability indication polling in a transmission (e.g., in an MCCH transmission that may be used as an example). The MCCH transmission (e.g., the reliability indication polling in the MCCH transmission) may indicate that the WTRU is to transmit a reliability indication in the next change period (e.g., the next change period, a specified subsequent change period, etc.). The MCCH transmission may indicate (e.g., set) filtering criteria for the reliability indication. For example, the filtering criteria may specify the highest reliability metric applicable to the reliability indication. For example, the WTRU may transmit a reliability indication if and when (e.g., only if) the measured reliability metric is below the set filtering criteria. The WTRU may be able to skip reliability indication transmission, for example, if the reliability metric exceeds the set filtering criteria.

[0159] The WTRU can receive reliability indication polling specific to the MBS radio bearer and / or MBS service. The WTRU can trigger (e.g., determine to send) a reliability indication, for example, if and only if the WTRU is configured for the MBS radio bearer and / or MBS service (e.g., a specific 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 the MBS radio bearer (e.g., and / or MBS service) associated with the group RNTI. In an example, the WTRU can perform a reliability indication for one or more MBS bearers for which reliability monitoring is configured.

[0160] The WTRU can receive an MCCH transmission having a polling request associated with a GRNTI (e.g., a pre-configured GRNTI). The WTRU can receive information indicating the number of MBS transport blocks within a change period n (e.g., the expected number of MBS transport blocks within a change period n). The WTRU can use 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 a change period, the number of successfully received transport blocks within a change period, etc.). The WTRU can determine the average number of retransmissions and / or repetitions required for successful MBS transport block reception (e.g., required for reception).

[0161] Polling via the MCCH can be implemented, for example, using a polling indication in RAN paging.

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

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

[0164] The WTRU can (e.g., be configured to) send a reliability indication based on one or more (pre-)set events. For example, the trigger condition for sending a reliability indication may be based on whether a reliability metric exceeds or falls below a (pre-)set threshold. The WTRU, for example, may send a reliability indication when one or more of the following conditions are met: the average number of repeated normal MBS transport block receptions within a pre-set time interval meets (e.g., exceeds) a threshold; a different statistical value such as the median number of repetitions or the mode number of repetitions for normal MBS transport block receptions within a pre-set time interval meets (e.g., exceeds) a threshold; the minimum value of the CQI associated with MBS reception over a pre-set time interval meets (e.g., falls below) a threshold; the ratio of the number of repetitions of MBS transport blocks to the total number of MBS transport blocks within a pre-set time interval meets (e.g., exceeds) a threshold; the number of transport blocks that have failed normal reception (e.g., exceeded the maximum number of repetitions before normal decoding) meets (e.g., exceeds) a threshold; a statistical value associated with the MCH BLER within a time interval meets (e.g., exceeds) a threshold; the number of NACKs associated with MBS transport blocks counted by the WTRU within a time interval meets (e.g., exceeds) a threshold; the average MBS RSRP within a time interval meets (e.g., falls below) a threshold; and / or the average MBS RSRQ within a time interval meets (e.g., falls below) a threshold.

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

[0166] A reliability indication may be transmitted. There may be an association between a reliability metric and a UL resource. A WTRU may have a rule (set in advance) regarding the determination of the UL resource for transmitting the reliability indication. For example, this rule may be based on the value or range of the reliability metric. A plurality of UL resources may be set for the WTRU. The UL resources may be mapped to the value or range of the reliability metric (e.g., each UL resource may be mapped to a respective value or range of the reliability metric). For example, a WTRU may have a set of UL resources for transmitting the reliability indication and an association between a particular UL resource and the value or range of the reliability metric. The WTRU may select the UL resource associated with the value or range of the reliability metric (e.g., when one or more of the trigger conditions are met), and the WTRU may transmit a reliability indication that can 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. The RA resource may refer to a time resource, a frequency resource, a spatial resource, a random access opportunity (RO), a preamble format, etc. The preamble format may be set, for example, with respect to the total preamble duration, sequence type, sequence length, guard time duration, cyclic prefix length, etc.

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

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

[0170] (For example, similar to the CQI example), different associations may be set for different reliability metrics. The WTRU may have a mapping configured between an RA resource and a statistical value or range of values associated with the number of repetitions for successful reception of normal MBS transport blocks (e.g., over a certain time interval). The WTRU may have a mapping configured between an RA resource and the ratio of the number of repetitions of MBS transport blocks to the number of MBS transport blocks (e.g., total number) (e.g., over a certain time interval). The WTRU may have a mapping configured between an RA resource and the number of transport blocks that failed reception normally (e.g., over a certain time interval). The WTRU may have a mapping configured between an RA resource and a statistical value associated with MCH BLER (e.g., over a certain time interval). The WTRU may have a mapping configured between an RA resource and a number of negative acknowledgements (NACKs) associated with MBS transport blocks (e.g., over a certain time interval). The WTRU may have a mapping configured between an RA resource and a range of average MBS RSRP / RSRQ values (e.g., over a certain time interval).

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

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

[0173] Settings related to the mapping between reliability metrics and UL resources can be applicable in multiple cells (e.g., all cells) within a logical area (e.g., MBS area, RAN area, etc.). The mapping can be set to be valid using the current cell (e.g., using only the current cell). The WTRU can release the settings, for example, based on reselection to different cells while in the INACTIVE state (e.g., based on those conditions).

[0174] For different ranges of a reliability indicator (e.g., reliability metric), different types of reliability indications can be provided (e.g., set and / or transmitted). In an example, the WTRU can have different actions set based on the value or range of the reliability metric. The WTRU can, for example, perform a reliability indication procedure using a (previously) set RA resource when the reliability metric is within a first range. The WTRU can, for example, start a resume procedure when the reliability metric is within a second range. The WTRU can, for example, start a WTRU identification information transmission procedure when the reliability metric is within a second range (e.g., the WTRU can transmit unique WTRU identification information associated with the INACTIVE state). The WTRU can, for example, start a periodic RAN update procedure when the reliability metric is within a second range. In an example, the second range can be lower than the first range. In an example, the second range can correspond to a lower reliability than the reliability associated with the first range. In an example, the polling indication in MCCH transmission can indicate whether the WTRU performs a reliability indication procedure and / or a resume procedure. In an example, the WTRU can be configured to monitor multiple reliability metrics and associated trigger conditions. The WTRU can, for example, have different actions set based on specific reliability metrics (s) that meet the trigger condition(s). For each (e.g., each) set reliability metric, it can be set which action(s) are applicable.

[0175] Techniques associated with a random access response (RAR) associated with a reliability indication are disclosed herein. A WTRU may be configured to monitor for an RAR, for example, after transmission of a reliability indication (e.g., a reliability indication indicating a reliability metric such as a reliability indicator). The WTRU may be configured to start a RA response window (e.g., ra-ResponseWindow) using a value associated with a reliability indication configuration, a value configured as part of RACH-ConfigCommon, or a default value, for example, if the WTRU transmits a preamble preconfigured for the reliability indication and / or if the WTRU transmits a preamble in a RO preconfigured for the reliability indication. In an example, the WTRU may be configured to monitor for 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 a default RNTI, a (pre-)configured RNTI, or may be configured relative to (e.g., specifically for) a multicast group. The WTRU may monitor for an RAR using the RA-RNTI, for example, alternatively, and / or in the absence of a configuration.

[0176] The WTRU can consider (e.g., determine) that the RAR reception has failed if, for example, the ra-ResponseWindow set for reliability indication has expired and / or no RAR containing a random access preamble identifier (RAPID) that matches the preamble associated with the reliability indication has been received. The WTRU can consider that the RAR reception has failed if, for example, a valid downlink assignment has been received on the PDCCH for the RA-RNTI and / or the RAR contains a MAC sub-PDU with a backoff indicator. The WTRU can retry transmitting the reliability indication, for example, over a (pre)-configured number of attempts. The WTRU can be configured to start a resume procedure, for example, after the maximum number of attempts if, for example, the RAR reception has failed. The WTRU can be configured to start requesting a transition from the INACTIVE state to the CONNECTED state, for example, as part of the resume procedure. The WTRU can have an access category for the resume procedure configured, for example, based on the MBS service type, for example, as part of the MBS configuration. The WTRU can start transmitting an RRCResumeRequest message. The WTRU can be configured to start an instance (e.g., a new instance) of a RACH procedure for transmitting the RRCResumeRequest message.

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

[0178] The WTRU can perform subsequent actions, for example, based on the MAC sub-PDU (e.g., its content) if, for example, the RAR reception has been successful.

[0179] For example, if the WTRU receives a random access response that includes a MAC sub-PDU having a RAPID (e.g., having only a RAPID), and the RAPID corresponds to a transmitted preamble that is associated with a reliability indication, the WTRU may consider the reliability indication to be complete and return to the INACTIVE state. The WTRU may interpret a RAR having a RAPID field (e.g., only the RAPID field) as an indication (e.g., an implicit indication) that the WTRU can continue actions according to the INACTIVE state and the MBS configuration. The WTRU may support (e.g., guarantee) QoS requirements for MBS delivery, assuming that the NW does not require additional information from the WTRU. In an example, an indication (e.g., an explicit indication) in the RAR that the reliability indication procedure is complete may be set. 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 (e.g., an explicit indication) may be part of the MAC sub-header (e.g., a field (e.g., 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 that includes a MAC sub-PDU having a RAPID field corresponding to a reliability indication and an associated RAR payload. The RAR payload format may be specific to the reliability indication. Reserved bits R within the RAR payload may be set (e.g., to 1) to indicate different formats. The timing advance field, UL grant field, and / or temporary CRNTI field may be interpreted differently if included in the RAR payload, e.g., in response to the reliability indication. The RAR payload for the reliability indication response may include one or more fields of an indication of whether the WTRU should start a resume procedure and / or an indication that the WTRU should provide WTRU identification information (e.g., along with the implementation of corresponding WTRU actions).

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

[0182] The WTRU may be configured to provide the network with WTRU - specific identification information, for example, based on an indication that the WTRU should provide WTRU identification information (e.g., the WTRU may transmit an I - RNTI). The I - RNTI value can be used to identify the interrupted WTRU context of 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 are at least one WTRU with an associated reliability metric, but the exact number of WTRUs may be unclear. The NW may be able to determine the number of WTRUs or be notified of the number of WTRUs, for example, to determine a scheduling strategy. For example, the NW may employ or adapt a more conservative approach (e.g., a conservative MCS and / or repetition) for group scheduling and / or the NW may move and / or transition the WTRU to the CONNECTED state for a more tight control and feedback loop. The WTRU may transmit WTRU - specific identification information (e.g., an I - RNTI), for example, to enable the NW to determine the number of WTRUs by a reliability metric or a range thereof (e.g., a specific reliability metric or a range thereof).

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

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

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

[0186] The process described above may be implemented in a computer program, software, and / or firmware incorporated into 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 a wired connection and / or a wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM disks and / or Digital Versatile Disk (DVD). A radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer may be implemented using a processor associated with the software.

Claims

1. A wireless transmit / receive unit (WTRU) associated with a multicast broadcast service (MBS), in a radio resource control (RRC) connected state, transmits an indication of interest in receiving an MBS service, receives 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 permitted for the WTRU in an RRC inactive state, enters the RRC inactive state based on the RRC release information, in the RRC inactive state, determines an RSRQ value for a serving cell and an RSRP value for the serving cell, determines 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 determining, initiates an RRC connection re - establishment procedure, the RRC connection re - establishment procedure including transmitting an RRC re - establishment request indicating a re - establishment reason associated with the initiation of the RRC connection re - establishment procedure A WTRU comprising a processor configured as such.

2. The WTRU of claim 1, wherein the processor is further configured to receive MBS configuration information associated with the RRC inactive state.

3. The WTRU of claim 2, wherein the MBS configuration information is received after the RRC release information is received.

4. The WTRU of claim 2, wherein the RRC release information indicates the MBS configuration information.

5. The WTRU of claim 1, wherein the processor is further configured to receive an RRC re - establishment message indicating to the WTRU to switch from the RRC inactive state to an RRC connected state.

6. The WTRU of claim 1, wherein the indication of interest in receiving the MBS service is transmitted in the RRC connected state.

7. The WTRU of claim 1, wherein the RRC release information is received in the RRC connected state.

8. The processor is further configured to receive multicast transmissions associated with the MBS session in the RRC inactive state, and the serving cell is the WTRU of claim 1 associated with the MBS session.

Images