Multicast and broadcast service reliability indication

Abstract

A wireless transmit / receive unit and methods performed by the same associated with multicast broadcast services are disclosed, the WTRU comprising: a processor configured to transmit an indication of interest in receiving an MBS service in a radio resource control connected state; receive RRC release information, the RRC release information comprising one or more MBS reference signal received quality thresholds, wherein the RRC release information further indicates that multicast service reception is allowed for the WTRU in a RRC inactive state; enter the RRC inactive state based on the RRC release information; determine a RSRQ value of a serving cell in the RRC inactive state; and initiate a RRC connection resume procedure based on the RSRQ value of the serving cell and the one or more MBS RSRQ thresholds, wherein the processor is configured to transmit a RRC resume request, the RRC resume request indicating a resume cause associated with the initiation of the RRC connection resume procedure.

Description

[0001] This application is a divisional application of the invention patent application filed on August 2, 2022, with application number 202280059522.1 (international application number PCT / US2022 / 039122) and titled "Reliability Indicator for Multicast and Broadcast Services".

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 228,629, filed August 3, 2021, the entire disclosure of which is incorporated herein by reference. Background Technology

[0004] Mobile communications using wireless communication continue to evolve. The fifth-generation mobile radio access technology (RAT) can be referred to as 5G New Radio (NR). Previous-generation (traditional) mobile communication RATs could be, for example, fourth-generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0005] This article describes the systems, methods, and means associated with reliability indications for multicast and broadcast services (MBS).

[0006] Techniques associated with reliability monitoring and / or reliability indication are disclosed (e.g., those that can be implemented by or associated with a wireless transmit / receive unit (WTRU), such as those described herein). Reliability indication can be an indication associated with transmission reliability, such as that determined by the WTRU, for example, based on whether the WTRU receives a transmission (e.g., an MBS transmission, such as an MBS transport block). Reliability indication may include or indicate a reliability indicator (e.g., a reliability metric) and / or a determined value and / or range of the reliability indicator. One or more of the following may be applied.

[0007] The WTRU can receive MBS configuration information. MBS configuration information can be associated with an inactive state. For example, MBS configuration information can be received in messages such as RRC messages, such as RRC release messages that include a suspension configuration (e.g., SuspendConfig) indication, where SuspendConfig can be used as an example. The validity of the MBS configuration information and the SuspendConfig indication can be associated with different regions (e.g., logical regions), where, for example, the logical region could be an MBS region versus a Radio Access Network (RAN) region. MBS configuration information can include and / or indicate one or more of the following: multicast radio bearer (MRB) configuration information for an inactive state; one or more triggers for reliability indication; reliability metric configuration; or reliability indication configuration.

[0008] MRB configuration information for inactive states can be indicated by one or more of the following. For example, if MBS reception is permitted in an inactive state, the WTRU can (e.g., under conditions of entering an inactive state and / or under conditions of entering an inactive state) suspend point-to-point (PTP) tributaries and / or maintain point-to-multipoint (PTM) tributaries used to segment the MRB. The WTRU can keep one or more MBS bearers active after entering an inactive state. The WTRU can suspend other bearers (e.g., non-MBS bearers and / or MBS bearers different from one or more MBS bearers configured to be active in an inactive state).

[0009] Triggers for reliability indication can be associated with one or more of the following. Triggers for reliability indication can indicate whether reliability monitoring and / or reliability indication is periodic, event-triggered, polling-based, etc. For example, one or more triggers for reliability indication can be indicated in polling configuration information, event-based configuration information, and / or periodic configuration information. Polling configuration information can be associated with a multicast control channel (MCCH). Polling configuration information associated with the MCCH can instruct the WTRU to perform reliability indication, for example, for a specific MBS service, for example, by signaling an identifier associated with such an MBS service. For example, this identifier can be indicated by a Group Radio Network Identifier (GRNTI) associated with an MBS service for which the WTRU is expected to perform reliability monitoring. Event-based configuration information can instruct the performance of reliability indication, for example, if one or more thresholds associated with a reliability metric are met, etc. Triggers for performing reliability indication can be indicated in a periodic configuration, where, for example, periodic configuration information can be received every n modification periods, where n can be a fraction or greater than or equal to (>=) - (1).

[0010] Reliability metric configuration information may be associated with one or more of the following. Reliability metric configuration information may include (e.g., indicating) the type of reliability metric, which may include one or more of the statistics associated with the MBS Channel Quality Indicator (CQI) and / or Block Error Rate (BLER); the number of repetitions within the MCCH modification period relative to the expected (e.g., total) number of transmissions; etc.

[0011] Reliability indication configuration information may be associated with one or more of the following: Reliability indication configuration information may indicate one or more resources used for reliability indication, which may include one or more of the following: one or more random access (RA) preambles; random access channel (or procedure) (RACH) timing (RO) (e.g., related to MCCH modification boundaries); the association between RA resources and reliability metrics (e.g., their range); etc.

[0012] A WTRU can enter an inactive state, for example, based on a command from the network (e.g., when an RRC release with suspendConfig is received). A WTRU (e.g., in an inactive state) can, for example, receive MBS transmissions on one or more configured MRBs.

[0013] The WTRU can receive MCCH transmissions. MCCH transmissions may include or indicate polling requests for reliability indicators. According to GRNTI, MCCH transmissions may be received and / or include polling requests. MCCH transmissions may be received during time intervals (e.g., MCCH modification period n). Auxiliary information (e.g., additional auxiliary information) may be received for reliability monitoring. Auxiliary information may include, for example, the expected number of MBS transport blocks (TB) within the modification period. Activation and / or deactivation of periodic reliability indicators may be received, for example, via a Media Access Control (MAC) control element (CE).

[0014] WTRU can determine one or more reliability metrics associated with a received MBS transmission (e.g., an inactive MBS TB reception).

[0015] WTRU can monitor one or more reliability metrics, for example, during time intervals such as those associated with the MCCH modification cycle (e.g., MCCH modification cycle n+1).

[0016] The WTRU can determine the values ​​and / or ranges of reliability indicators (e.g., reliability metrics) and / or reliability indicators (e.g., reliability metrics), for example, based on met triggering conditions, such as receiving a polling request or other conditions described herein. The WTRU can select RA resources, for example, based on the determined values ​​and / or ranges of reliability indicators (e.g., reliability metrics), for example, based on the association and / or mapping between one or more pre-configured resources and the determined values ​​and / or ranges of reliability metrics.

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

[0018] The WTRU can monitor the Random Access Response (RAR) format (e.g., where the RAR format may be specific to the reliability indication transmission) in response to a response associated with a reliability indication transmission. The RAR format (e.g., a response in RAR format) may include one or more of the following: an indication of whether the WTRU should perform subsequent random access and recovery procedures; an indication of whether the WTRU should perform a two-step RA (e.g., to provide additional WTRU-specific information, such as an inactive RNTI (I-RNTI) transmission); and / or an indication of returning to and / or remaining in an inactive state.

[0019] Figure 2 An example of MBS reliability monitoring and reliability indication is shown. A common reference period (e.g., by the network and WTRU) can be used for reliability indication. The common reference period may include the MCCH modification period. The MCCH modification period may include multiple time slots. Figure 2 Two MCCH modification periods are shown, MCCH modification period n and MCCH modification period n+1. During MCCH modification period n, multiple MCCH transmissions can be sent (e.g., by the network). Some or all MCCH transmissions may include the same information (e.g., the same polling request). For example, an MCCH transmission may indicate the expected number of TBs to be sent (e.g., by the network) during the next MCCH modification period (e.g., MCCH modification period n+1). The WTRU can determine the number of TBs actually received and / or successfully decoded, and use the expected number of TBs to be sent during the next MCCH modification period and the number of TBs actually received to determine the ratio of received TBs to sent TBs. The value of the reliability indicator may include this ratio. MCCH transmissions can be sent for one (e.g., each) MCCH repetition period.

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

[0021] As an example, the WTRU can be configured to receive MBS configurations associated with an RRC inactive state while in an RRC connected state. The MBS configuration may include one or more triggers for reliability indication, a range of reliability metrics, and a mapping between UL resources for reliability metric indication. When entering an RRC inactive state, the WTRU may suspend PTP tributaries (if any) and start or continue PTM tributaries for MBS service. The WTRU may monitor one or more triggers for reliability indication, for example, via GRNTI. The WTRU may receive MCCH transmissions with polling requests for reliability indication during MCCH modification period n. The polling requests may be associated with a specific MBS bearer, providing supplementary information, such as the number of MBS transport blocks within modification period n+1. The WTRU may determine a reliability metric during a time interval associated with MCCH modification period n+1; for example, the reliability metric may be the ratio of the number of successfully received MBS transport blocks to the total number of MBS transport blocks transmitted within the modification period. The WTRU can determine the RA resources applicable to the reliability indication based on the reliability metric value. The WTRU can transmit RA preambles on identified RA resources, and can monitor the RAR format associated with the reliability indication. When a RAR matching the reliability indication is received, the WTRU can perform one or more of the following actions based on the received RAR: execute another RA procedure to initiate a recovery process or remain in RRC inactivity to receive MBS services.

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

[0023] WTRU can be configured to initiate a transition from inactivity to connectivity, for example, based on a reliability metric value and / or range below a threshold.

[0024] Reliability monitoring can be performed on a shorter timescale, for example, based on a traceable duration (e.g., via a timer). In an example, the shorter timescale could be a time period shorter than the length of a modification cycle (e.g., the MCCH modification cycle). For example, the duration can be traced if / when the WTRU receives a poll (e.g., a timer can be started). For example, based on the termination of the duration (e.g., the termination of the timer), the WTRU can transmit a reliability indication on the earliest RO. Attached Figure Description

[0025] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments.

[0026] Figure 1B It is shown in the implementation plan. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown.

[0027] Figure 1C It is shown in the implementation plan. Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0028] Figure 1D It is shown in the implementation plan. Figure 1A The system diagram shown illustrates another exemplary RAN and another exemplary CN used within the communication system.

[0029] Figure 2 An example of MBS reliability monitoring and reliability indication is shown.

[0030] Figure 3 An example of the RRC recovery request process is shown.

[0031] Figure 4 An example of an MRB with a segmented bearer protocol architecture is shown. Detailed Implementation

[0032] This document describes systems, methods, and means for reliability indication of multicast and broadcast services (MBS). The WTRU can receive MBS configurations for inactive states (e.g., paused point-to-point (PTP) and sustained point-to-multipoint (PTM) for segmented multicast radio bearers (MRBs). MBS configurations and pause configurations can be associated with different areas (e.g., MBS area to radio access network (RAN) area). Configurations can indicate reliability indication triggering (e.g., polling, event-based, periodic), reliability metric configuration, and / or reliability indication configuration. The WTRU (e.g., in inactive) may, for example, receive MBS transmissions (e.g., on the MRB), receive the multicast control channel (MCCH) (e.g., with triggering for reliability indication during the MCCH modification period), determine the reliability metric associated with MBS transport block (TB) reception, monitor the reliability metric during the time interval of the MCCH modification period, select random access (RA) resources (e.g., each mapping between resources and reliability metric values / ranges), indicate the reliability metric (e.g., transmit the reliability indication via the selected preamble and random access channel (or procedure) (RACH) timing (RO), and / or monitor the random access response (RAR) format in response to the reliability indication transmission.

[0033] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0034] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should 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, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0035] The communication system 100 may also include base stations 114a and / or 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node Bs, evolved Node Bs, home Node Bs, home evolved Node Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0036] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable 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 embodiments, base station 114a may employ 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 desired spatial directions.

[0037] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

[0039] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0040] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can enable radio technology such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0041] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, implement LTE radio access and NR radio access together using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0042] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

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

[0044] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different 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 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0045] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0047] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0048] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0049] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0050] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0051] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capabilities. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0052] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. 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. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0053] 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 powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

[0055] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

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

[0058] RAN 104 may include evolved Node Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Node Bs while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Node Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0059] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0061] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0062] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0063] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0064] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0065] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0066] In a representative implementation, the other network 112 may be a WLAN.

[0067] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (STAs) associated with the AP. The AP may have an access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0068] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or 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 some representative implementations, such as in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, each STA (including the AP) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0069] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0070] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0071] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0072] WLAN systems supporting multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC-type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

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

[0074] Figure 1DThis is a system diagram illustrating RAN 113 and CN 115 according to one implementation scheme. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0075] RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation. Each gNB 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In another implementation, 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, while the remaining component carriers may be on licensed spectrum. In an implementation, gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0076] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0077] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0078] 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, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0080] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. The AMF162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as WiFi)).

[0081] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a 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. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0082] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0083] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 115 may provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c can be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and local data networks (DNs) 185a and 185b.

[0084] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, which may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0085] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may utilize over-the-air wireless communication to perform tests.

[0086] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0087] The configuration mentioned in this article (such as the configuration received at WTRU) can refer to configuration information.

[0088] This description is provided for illustrative purposes and does not in any way limit the applicability of the methods described herein to other wireless technologies. The term "network" may refer to one or more base stations (e.g., gNBs) that may be associated with one or more Transmit / Receive Points (TRPs), or any other node in a Radio Access Network (RAN). The states (e.g., RRC states) mentioned herein may refer to the operating conditions of a WTRU.

[0089] A WTRU can be configured to operate in a state (e.g., one of multiple states), which can be illustrated herein via RRC states. Radio Resource Control (RRC) can have multiple states, which can include an RRC inactive state. A WTRU in an idle state can conserve WTRU battery resources, for example, if the WTRU is inactive for a given period of time (e.g., no data is transmitted or received). In idle state, the WTRU can intermittently monitor the Physical Downlink Control Channel (PDCCH). For example, if the WTRU's data is intermittent (e.g., a smartphone frequently transmits small amounts of data), the WTRU alternating between connected and idle states can trigger control plane signaling in the network. For example, if the network does not have a WTRU context for an idle WTRU and / or does not know the (e.g., exact) location of the WTRU, the signaling used to transition the WTRU from an idle state to a connected state can involve the radio access network (e.g., gNB) and / or the core network (CN). For example, if the transition to a connected state is triggered by downlink (DL) data or a new voice call, the WTRU can be paged (e.g., via gNB / cell in the geographic area) in the geographic area where the WTRU is registered.

[0090] Frequent idle-to-connection transitions can have significant signaling overhead. WTRUs may have bearers that send data infrequently but may be latency-sensitive. If / when a WTRU is not actively (e.g., and frequently) sending or receiving data, transitioning or placing the WTRU into an idle state may be ineffective, counterproductive, and / or otherwise undesirable in some cases.

[0091] Intermediate states can be used (e.g., in 5G), where an example of an intermediate state can be referred to as an inactive state (e.g., and vice versa). A WTRU in an inactive state can have power-saving advantages, such as some of the power-saving advantages associated with an idle state (e.g., discontinuous monitoring of the PDCCH), and can return to a connected state faster than from an idle state. Intermediate states (e.g., inactive states) can be implemented, for example, by releasing the WTRU connection while maintaining the WTRU's context at both the RAN and the WTRU itself, e.g., without involving the CN (e.g., the CN can see a WTRU in an inactive state in the same or similar way as the CN can see a WTRU in a connected state).

[0092] The network can, for example, send an indication to the WTRU to transition to an inactive state by sending a message (e.g., an RRRCrease message) to the WTRU. This message may include a suspension configuration (e.g., it may be referred to as suspendConfig). SuspendConfig may include one or more of the following: a WTRU identifier (e.g., which may be used if / when a connection is restored), RAN area configuration, security information (e.g., which may be used to protect the recovery process), or paging configuration (e.g., for paging from the RAN, which may contrast with paging from the CN for the idle state). RAN area configuration may include, for example, a cell list (e.g., a physical cell ID (PCI)) or a tracking area code and / or a periodic RAN area update time / timer configuration. An inactive WTRU may perform cell reselection (e.g., similar to a WTRU performing reselection in the idle state). The WTRU may, for example, use configured RAN paging information to monitor the paging channel.

[0093] The WTRU can initiate a recovery process, for example, by sending an RRCResumeRequest message, which may include the WTRU recovery identifier and / or the reason for the connection recovery (e.g., a voice call initiated by a mobile party with a paging indication, a video call initiated by a mobile party, a call terminated by a mobile party, an emergency, a RAN area update due to reselection outside the current RAN area, or termination of duration, such as the termination of a timer).

[0094] The network (e.g., in the case of a RAN area update) may send the WTRU back to an inactive state, for example, by sending an RRCRelease message. The RRCRelease message may include, for example, a WTRU recovery identifier (e.g., a new WTRU recovery identifier), RAN area configuration, security and / or paging configuration.

[0095] For example, the network can (e.g., alternatively) send (e.g., respond) an RRCresume message to instruct the WTRU to restore the radio connection. Uplink and / or downlink (UL / DL) transmissions can continue (e.g., immediately afterward), for example, as Figure 3 As shown in the example. It can be... Figure 3 The signaling shown is compared with the signaling used to establish a connection from an idle state (e.g., as previously described). Recovery from an inactive state can save WTRU and network signaling. The CN may not be involved in this recovery. For example, from the WTRU's point of view, delays can be avoided.

[0096] Figure 3 An example of the RRC recovery request process is shown.

[0097] Multimedia Broadcast Multicast System (MBMS) services can be delivered wirelessly. MBMS services can be provided using a variety of methods, including one or more of unicast cellular transmission (UC), multicast-broadcast single-frequency network (MBSFN), and / or single-cell point-to-multipoint (SC-PTM).

[0098] SC-PTM can support broadcast / multicast services on a single cell. The broadcast / multicast area can be adjusted cell-by-cell, for example, based on user distribution (e.g., dynamically). SC-PTM can deliver broadcast / multicast services, for example, using an LTE downlink shared channel (e.g., Physical Downlink Shared Channel (PDSCH)), which can be scheduled using a common RNTI for a group of users (e.g., group-RNTI). SC-PTM scheduling can be flexible. For example, radio resources can be allocated (e.g., dynamically allocated) in the time and frequency domains via PDCCH signaling based on real-time traffic load (e.g., per-transmission time interval (TTI)). SC-PTM is suitable for scenarios where broadcast / multicast services are delivered to (e.g., expected to be delivered to) a limited number of cells, for example, due to user interests. The cells of interest can change, for example, due to user movement (e.g., dynamically). SC-PTM can support (e.g., allow) efficient radio utilization and / or flexible deployment of applications (e.g., critical communications, vehicle traffic information, on-demand TV services, etc.).

[0099] For example, an MBSFN can provide transports from different cells arranged in the same and / or time-aligned manner, such that from the WTRU's perspective, transports from different cells appear as a single transport. For example, an MBSFN synchronization area can be defined to achieve time synchronization between eNBs. An MBSFN area can include a set of cells within the network's MBSFN synchronization area, which can be coordinated to enable MBSFN transports. The MBMS architecture can include (e.g., define) various logical entities to perform network functions suitable for MBMS transports. The Multi-Cell / Multicast Coordination Entity (MCE) can perform permission control, determining whether to use SC-PTM or MBSFN for MBMS services, suspending and resuming, etc. The MBMS Gateway (MBMS-GW) can perform session control signaling and / or forward MBMS user data to eNBs (e.g., via IP multicast).

[0100] MBMS can be implemented in wireless systems such as New Radio (NR). MBMS can also be referred to as Multicast and Broadcast Service (MBS). The terms MBMS and MBS are used interchangeably in this document.

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

[0102] The WTRU can be configured for the delivery of MBS services (e.g., configuration aspects of the WTRU can be configured for the transport of MBMS data services). Examples are provided without limiting the scope or applicability of similar delivery methods for MBS data and / or control information. The WTRU can be configured to operate in transport mode to exchange MBS-related data. The WTRU can have other (e.g., further) configuration aspects for delivering MBS services. Configurable aspects may include, for example, mappings of data (e.g., and / or signaling) bearers for the configured transport method to exchange MBS-related data (e.g., L2 bearer configuration for MBS). For example, the WTRU can be configured for mixed-mode transport (e.g., unicast and multicast), where MBS data delivery is performed using multicast and / or broadcast transport (e.g., multicast and / or broadcast transport only), while other services can be delivered via unicast (e.g., eMBB, URLLC). For example, a WTRU can be configured for mixed-mode transport (e.g., unicast and multicast), where unicast transport (e.g., referred to as point-to-point (PTP) transport / mode) and / or multicast transport (e.g., referred to as point-to-multipoint (PTM) transport / mode) are used to perform MBS data delivery, regardless of whether the WTRU is (e.g., using unicast transport, such as eMBB, URLLC) regarding other service activities.

[0103] MBS (e.g., NR MBS) can support one or more of the following use cases: V2X, sidelinks, and / or public safety (e.g., 3GPP systems can distribute information to a large number of WTRUs supporting V2X applications in a resource-efficient manner); Internet of Things (IoT), such as narrowband (NB) IoT and enhanced machine-type communication (eMTC) devices (e.g., for software updates), and / or smart grids / utilities; TV video and radio services (e.g., in 5G); push services (e.g., advertising and / or weather broadcasts); Ethernet broadcast / multicast (e.g., for factory automation); and / or extended reality and / or group gaming. TV video and radio services supported by MBS may include one or more of the following: linear TV, live TV, smart TV, managed and / or on-the-top (OTT) content distribution, and / or radio services, video distribution (e.g., if / when multiple users are watching the same live stream simultaneously); large spikes in concurrent consumption of OTT services (e.g., via unicast media streaming); and / or immersive six degrees of freedom (6DoF) volumetric streaming (e.g., much larger than traditional planar or even 360-degree video).

[0104] MBS services can support application-level retransmission. However, the reliability and efficiency trade-offs offered by the application-level approach can be costly (e.g., in terms of spectral efficiency). Application-level approaches may not support (e.g., may be insufficient to meet) lower latency requirements. Different MBS services can have different latency, efficiency, and reliability requirements. For example, grid distribution can be implemented with a 5ms latency and a 10⁻⁶ packet error rate. V2X can be implemented with a 20ms latency for information sharing between WTRUs and Roadside Units (RSUs). Mission-critical Talk-to-Talk (MCPTT) can be implemented using key performance indicators (KPIs), such as a 300ms mouth-to-ear latency.

[0105] WTRUs can be configured to receive MBS transmissions in RRC inactive states, for example, due to reduced power consumption and signaling overhead in inactive states. The network may not monitor and / or improve MBS service delivery for those WTRUs, for example, due to the lack of robust control / feedback loops in inactive states (e.g., no UL communication when the WTRU is inactive). The network (e.g., an NR network) can implement various MBS services with increased reliability compared to other (e.g., legacy) services on the MBS. MBS can be improved. For example, improved reliability can be provided in RRC states such as RRC inactive states (e.g., different from RRC connected states).

[0106] Wireless technologies / systems (e.g., New Radio (NR)) can support multiple (e.g., two) delivery modes for MBS. For example, a first delivery mode (e.g., delivery mode 1) can provide high Quality of Service (QoS) in terms of reliability, latency, and / or other criteria. A second delivery mode (e.g., delivery mode 2) can provide low (e.g., compared to delivery mode 1) QoS in terms of reliability, latency, and / or other criteria. In the example, delivery mode 1 can be supported for multicast services and / or delivery mode 2 can be supported for broadcast services. In the example (e.g., in terms of Radio Resource Control (RRC) states), delivery mode 1 can be supported for states (e.g., connected (CONN) states) and / or delivery mode 2 can be supported for multiple (e.g., all) RRC states. A WTRU with multicast capabilities can be enabled to enter an inactive state, which can support improved power consumption / overhead and / or can be used as a means of congestion mitigation. A WTRU in an inactive state may not (e.g., have means to) provide feedback (e.g., without significant overhead). One or more constraints may exist. Inactive WTRUs may not be uplink (UL) synchronized. The number of inactive WTRUs receiving MBS services can be quite large. Allocating WTRU-specific resources for feedback may be infeasible or undesirable.

[0107] Techniques associated with reliability monitoring and / or reliability indication (e.g., those that can be implemented by or associated with a WTRU) are disclosed, such as those described herein. A reliability indication can be an indication associated with transmission reliability, such as one determined by the WTRU, for example, based on whether the WTRU receives a transmission (e.g., an MBS transmission, such as an MBS transport block). A reliability indication may include or indicate a reliability indicator (e.g., a reliability metric) and / or a defined value and / or range of the reliability indicator. One or more of the following may be applied.

[0108] The WTRU can receive MBS configuration information. MBS configuration information can be associated with an inactive state. For example, MBS configuration information can be received in messages such as RRC messages, such as RRC release messages that include a pause configuration indication (e.g., SuspendConfig), where SuspendConfig can be used as an example. The validity of the MBS configuration information and the SuspendConfig indication can be associated with different regions (e.g., logical regions), where, for example, a logical region could be an MBS region versus a RAN region. MBS configuration information can include and / or indicate one or more of the following: multicast radio bearer (MRB) configuration information for an inactive state; one or more triggers for reliability indication; reliability metric configuration; or reliability indication configuration.

[0109] MRB configuration information for inactive states can be indicated by one or more of the following. For example, if MBS reception is permitted in an inactive state, the WTRU can (e.g., under conditions of entering an inactive state and / or under conditions of entering an inactive state) suspend point-to-point (PTP) tributaries and / or maintain point-to-multipoint (PTM) tributaries used to segment the MRB. The WTRU can keep one or more MBS bearers active after entering an inactive state. The WTRU can suspend other bearers (e.g., non-MBS bearers and / or MBS bearers different from one or more MBS bearers configured to be active in an inactive state).

[0110] Triggers for reliability indication can be associated with one or more of the following. Triggers for reliability indication can indicate whether reliability monitoring and / or reliability indication is periodic, event-triggered, polling-based, etc. For example, one or more triggers for reliability indication can be indicated in polling configuration information, event-based configuration information, and / or periodic configuration information. Polling configuration information can be associated with a multicast control channel (MCCH). Polling configuration information associated with the MCCH can instruct the WTRU to perform reliability indication, for example, for a specific MBS service, for example, by signaling an identifier associated with such an MBS service. For example, this identifier can be indicated by a Group Radio Network Identifier (GRNTI) associated with an MBS service for which the WTRU is expected to perform reliability monitoring. Event-based configuration information can instruct the performance of reliability indication, for example, if one or more thresholds associated with a reliability metric are met, etc. Triggers for performing reliability indication can be indicated in a periodic configuration, where, for example, periodic configuration information can be received every n modification periods, where n can be a fraction or greater than or equal to (>=) - (1).

[0111] Reliability metric configuration information may be associated with one or more of the following. Reliability metric configuration information may include (e.g., indicating) the type of reliability metric, which may include one or more of the statistics associated with the MBS Channel Quality Indicator (CQI) and / or Block Error Rate (BLER); the number of repetitions within the MCCH modification period relative to the expected (e.g., total) number of transmissions; etc.

[0112] Reliability indication configuration information may be associated with one or more of the following: Reliability indication configuration information may indicate one or more resources used for reliability indication, which may include one or more of the following: one or more random access (RA) preambles; random access channel (or procedure) (RACH) timing (RO) (e.g., related to MCCH modification boundaries); the association between RA resources and reliability metrics (e.g., their range); etc.

[0113] A WTRU can enter an inactive state, for example, based on a command from the network (e.g., when an RRC release with suspendConfig is received). A WTRU (e.g., in an inactive state) can, for example, receive MBS transmissions on one or more configured MRBs.

[0114] The WTRU can receive MCCH transmissions. MCCH transmissions may include or indicate polling requests for reliability indicators. According to GRNTI, MCCH transmissions may be received and / or include polling requests. MCCH transmissions may be received during time intervals (e.g., MCCH modification period n). Auxiliary information (e.g., additional auxiliary information) may be received for reliability monitoring. Auxiliary information may include, for example, the expected number of MBS transport blocks (TB) within the modification period. Activation and / or deactivation of periodic reliability indicators may be received, for example, via a Media Access Control (MAC) control element (CE).

[0115] WTRU can determine one or more reliability metrics associated with a received MBS transmission (e.g., an inactive MBS TB reception).

[0116] WTRU can monitor one or more reliability metrics, for example, during time intervals such as those associated with the MCCH modification cycle (e.g., MCCH modification cycle n+1).

[0117] The WTRU can determine the values ​​and / or ranges of reliability indicators (e.g., reliability metrics) and / or reliability indicators (e.g., reliability metrics), for example, based on met triggering conditions, such as receiving a polling request or other conditions described herein. The WTRU can select RA resources, for example, based on the determined values ​​and / or ranges of reliability indicators (e.g., reliability metrics), for example, based on the association and / or mapping between one or more pre-configured resources and the determined values ​​and / or ranges of reliability metrics.

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

[0119] The WTRU can monitor the Random Access Response (RAR) format (e.g., where the RAR format may be specific to the reliability indication transmission) in response to a response associated with a reliability indication transmission. The RAR format (e.g., a response in RAR format) may include one or more of the following: an indication of whether the WTRU should perform subsequent random access and recovery procedures; an indication of whether the WTRU should perform a two-step RA (e.g., to provide additional WTRU-specific information, such as an inactive RNTI (I-RNTI) transmission); and / or an indication of returning to and / or remaining in an inactive state.

[0120] Figure 2 An example of MBS reliability monitoring and reliability indication is shown. A common reference period (e.g., by the network and WTRU) can be used for reliability indication. The common reference period may include the MCCH modification period. The MCCH modification period may include multiple time slots. Figure 2 Two MCCH modification periods are shown, MCCH modification period n and MCCH modification period n+1. During MCCH modification period n, multiple MCCH transmissions can be sent (e.g., by the network). Some or all MCCH transmissions may include the same information (e.g., the same polling request). For example, an MCCH transmission may indicate the expected number of TBs to be sent (e.g., by the network) during the next MCCH modification period (e.g., MCCH modification period n+1). The WTRU can determine the number of TBs actually received and / or successfully decoded, and use the expected number of TBs to be sent during the next MCCH modification period and the number of TBs actually received to determine the ratio of received TBs to sent TBs. The value of the reliability indicator may include this ratio. MCCH transmissions can be sent for one (e.g., each) MCCH repetition period.

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

[0122] As an example, the WTRU can be configured to receive MBS configurations associated with an RRC inactive state while in an RRC connected state. The MBS configuration may include one or more triggers for reliability indication, a range of reliability metrics, and a mapping between UL resources for reliability metric indication. When entering an RRC inactive state, the WTRU may suspend PTP tributaries (if any) and start or continue PTM tributaries for MBS service. The WTRU may monitor one or more triggers for reliability indication, for example, via GRNTI. The WTRU may receive MCCH transmissions with polling requests for reliability indication during MCCH modification period n. The polling requests may be associated with a specific MBS bearer, providing supplementary information, such as the number of MBS transport blocks within modification period n+1. The WTRU may determine a reliability metric during a time interval associated with MCCH modification period n+1; for example, the reliability metric may be the ratio of the number of successfully received MBS transport blocks to the total number of MBS transport blocks transmitted within the modification period. The WTRU can determine the RA resources applicable to the reliability indication based on the reliability metric value. The WTRU can transmit RA preambles on identified RA resources, and can monitor the RAR format associated with the reliability indication. When a RAR matching the reliability indication is received, the WTRU can perform one or more of the following actions based on the received RAR: execute another RA procedure to initiate a recovery process or remain in RRC inactivity to receive MBS services.

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

[0124] WTRU can be configured to initiate a transition from inactivity to connectivity, for example, based on a reliability metric value and / or range below a threshold.

[0125] Reliability monitoring can be performed on a shorter timescale, for example, based on a traceable duration (e.g., via a timer). In an example, the shorter timescale could be a time period shorter than the length of a modification cycle (e.g., the MCCH modification cycle). For example, the duration can be traced if / when the WTRU receives a poll (e.g., a timer can be started). For example, based on the termination of the duration (e.g., the termination of the timer), the WTRU can transmit a reliability indication on the earliest RO.

[0126] This document describes the characteristics associated with MBS reliability indicators. The example characteristics described herein are based on the transmission and delivery of MBS services. The described characteristics are not limited to the example scenarios, systems, and services. The characteristics described herein can be applied to other types (e.g., any type) of transmission and / or services, such as, but not limited to, V2X, extended reality, gaming, IoT / MTC, industrial use cases, etc.

[0127] A WTRU configured to receive MBS data can be configured with a data radio bearer (DRB), such as an MRB (multicast radio bearer). A DRB can be dedicated to MBS reception. For example, from an L2 and L3 perspective, MBS service and MRB can be used interchangeably (e.g., considered equivalent). MBS service can be configured with zero, one, or more MRBs.

[0128] The term “inactive” or “inactive state” can refer to a WTRU performing or configured to perform one or more of the following (e.g., a set of): monitoring short messages transmitted on downlink control information (DCI) along with paging RNTI (P-RNTI); monitoring paging channels for CN paging (e.g., using 5GS Temporary Mobile Subscriber Identity (5G-S-TMSI)) and / or RAN paging (e.g., using full I-RNTI); performing neighbor cell measurements and WTRU control based on network (NW) configuration (e.g., cell (re)selection); performing RAN-based notification area updates periodically and / or if / when moving outside a configured RAN-based notification area; or obtaining system information and / or sending SI requests (e.g., if configured).

[0129] Example features can be described in this document without restriction based on the inactive state. The techniques described herein are applicable to other RRC states (e.g., idle state, connected state, etc.).

[0130] One or more information elements and / or configuration parameters can be described in various examples according to the RRC configuration without limitation. The techniques described herein are applicable to other configurations (e.g., any configuration), default configurations, specified configurations, broadcast configurations (e.g., signaled notification via system information), group-specific configurations (e.g., multicast group-specific), area-specific configurations (e.g., MBS area, RAN area, etc.), and / or WTRU-specific configurations (e.g., signaled notification via RRC, MAC, DCI, or Layer 1 signaling).

[0131] Bearer configurations and / or architectures can be provided for inactive MBS. WTRUs (e.g., configured to receive data from the MBS) can be configured with data radio bearers (DRBs), which can be dedicated to MBS reception (e.g., via multicast radio bearers (MRBs)). For example, from an L2 and L3 perspective, MBS services and MRBs can be used interchangeably (e.g., considered equivalent). MBS services can be configured with zero, one, or more MRBs.

[0132] An MRB (e.g., similar to a DRB) with several QoS flows can be multiplexed within an MRB (e.g., given an MRB). An MRB can employ a segmented bearer protocol architecture, for example, with one Packet Data Convergence Protocol (PDCP) entity and two Radio Link Control (RLC) entities. For example, as... Figure 4 As shown in the example, the first RLC entity can be used for PTM, while the second RLC entity can be used for PTP operation.

[0133] Figure 4 An example of an MRB with a segmented bearer protocol architecture is shown.

[0134] like Figure 4 As shown, the Cell Radio Network Identifier (C-RNTI) can identify (e.g., uniquely identify) the RRC connection of a WTRU within a cell, while the Group RNTI (G-RNTI) can identify a group of WTRUs participating in multicast. MRBs are configured (e.g., according to...) Figure 4The WTRU (in the example architecture shown) can monitor DL ​​scheduling for the MRB on C-RNTI and / or G-RNTI. In the example, the RLC entity associated with PTM can operate in unacknowledged mode (UM), while the RLC entity associated with PTP can operate in acknowledged mode (AM). The techniques (e.g., methods) disclosed herein can be applied to other operating modes (e.g., PTM operating in transparent mode (TM) or AM, or PTP operating in TM or UM). In the example, the WTRU can be configured to suspend PTP operation while transitioning to an inactive state while maintaining PTM operation. For example, the WTRU can (e.g., under conditions of moving to an inactive state) reconfigure the MRB bearer, for example, from split bearer MBS operation to PTM bearer operation. The WTRU can release the RLC entity associated with the PTP RLC entity of the MRB. For example, if (e.g., only if) NW indicates that MBS reception is allowed in the inactive state, the WTRU can reconfigure the MRB (e.g., implicitly reconfigure) to PTM.

[0135] An inactive WTRU (e.g., as can be referred to herein as an inactive WTRU) can initiate a recovery procedure, such as to indicate to the network a request from the WTRU for MBS service (e.g., reliable MBS service). For example, the recovery procedure can be performed by sending an RRC Resume Request, which may include a reason for recovery (e.g., mbs-call-interest) and / or information about the MBS session identifier (e.g., in the case of several active MBS sessions). In the example, the inactive WTRU may include a preference indication that indicates whether the WTRU wants to remain inactive or transition to a connected state for MBS service delivery. In the example, the inactive WTRU (e.g., having already sent a recovery request) can receive a response message from the network to restore the connection (e.g., RRC Resume). The WTRU may (e.g., thereafter) receive an RRC reconfiguration message to configure the MRB (e.g., the desired MRB).

[0136] An inactive WTRU (e.g., one that has sent a recovery request, such as a request to resume) can receive a response message from the network to restore the connection (e.g., RRRCResume). The response message may include the configuration of the MRB (e.g., the required MRB). The WTRU can apply the MRB configuration (e.g., the required MRB configuration). The WTRU can remain inactive. The WTRU can receive MBS data, for example, according to the MRB configuration.

[0137] A connected WTRU with an MRB configuration (e.g., where the MRB may or may not be active at this time) can be transitioned (e.g., sent) to an inactive state (e.g., via a network message, such as an RRC release message). An indication to the WTRU to continue receiving MBS data while in an inactive state (e.g., in the RRC release message) can be provided / received. In the example, the RRC release message may include a new or updated MRB configuration, for example, if / when a connected WTRU is sent to an inactive state.

[0138] A WTRU can indicate its interest in receiving or joining an MBS session while in a connected state and can be released to an inactive state. In the example, the MBS session has not yet started, and the network and / or the WTRU can indicate (to the network) whether and / or when the MBS session becomes active. For example, the WTRU can send a request for an MBS session while in a connected state. The WTRU (e.g., in an inactive state) can receive an indication (e.g., an indication of an MBS session), such as whether / when the MBS session becomes active. This indication can be, or may be included in, one or more of the following: RAN paging; MBS session start indication in the multicast control channel (MCCH); MBS session start indication in the SIB; etc. The WTRU can, for example, initiate MBS service (e.g., reception of MBS service) based on receiving an indication (e.g., the MBS session is active).

[0139] Inactive WTRUs (e.g., MRBs configured with split bearer configurations, such as an RLC AM entity associated with C-RNTI and another RLC UM entity associated with G-RNTI) can suspend the RLC tributary associated with C-RNTI for PTP transmission, stop monitoring C-RNTI on PDCCH, and monitor G-RNTI on PDCCH (e.g., G-RNTI only) for MBS data reception.

[0140] The WTRU can be configured with licenses for receiving MBS data when in an inactive state. For example, a periodic license configuration can indicate which radio resources (e.g., time and / or frequency) include data for MBS sessions. In the example, when the WTRU is in a connected state, licenses for MBS reception can be provided. The license configuration can be provided based on (e.g., in an RRC release message) a transition to an inactive state (e.g., as part of it).

[0141] Features associated with reliability monitoring and / or reliability indication are described herein and may be associated with inactive states. Reliability indicators (e.g., reliability metrics) may be associated with reliability indications (e.g., reliability indicators may be provided or indicated in reliability indications). The term "configured to" as used herein may indicate (e.g., include) an associated device (e.g., a WTRU) performing the configured action.

[0142] Reliability metrics can be based on Channel Quality Indicators (CQIs). The WTRU can be configured to monitor the CQI associated with MBS reception. The WTRU can be configured to derive MBS CQI indices. For example, one (e.g., each) MBS CQI index can be associated with one or more combinations of modulation schemes, target code rates, and transport block sizes. In the example, the WTRU can be configured to derive a reliability metric corresponding to the highest MBS CQI index, such that transport blocks associated with MBS transmissions can be received with a transport block error probability not exceeding a pre-configured value, wherein the received transport blocks can have a combination of modulation schemes, target code rates, and transport block sizes associated with that MBS CQI index. And transport blocks received with a transport block error probability not exceeding a pre-configured value can be determined by the WTRU as corresponding to CQI indices occupying a set of downlink physical resource blocks (e.g., MBS reference resources). MBS reference resources can be pre-configured within a portion of the MBS bandwidth (e.g., having a specific digital scheme). For example, the WTRU can be pre-configured with transport block error probabilities (e.g., specifically for MBS CQI calculation). This configuration can be specific to the MBS service. The WTRU can be configured with a CQI table (e.g., specific to reliability indicators). For example, the CQI index (e.g., each CQI index) can be four (4) bits and / or can be mapped to (e.g., specific) modulation and coding rates (e.g., for a given MBS block error rate (BLER) configuration). In the example, the WTRU can be configured to use a subset of the CQI table (e.g., a conventional CQI table). For example, the WTRU can be configured with CQI indices from 0 to 7, where CQI indices from 0 to 6 can correspond to (e.g., a conventional) CQI table, and CQI index 7 can indicate a CQI value greater than 6 (e.g., any CQI value greater than 6).

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

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

[0145] Reliability metrics can be based on HARQ status. A WTRU can be configured to repeat (e.g., receive its indication) a number of times for an MBS transport block. A WTRU can be configured to repeatedly perform incremental redundancy combinations across MBS transport blocks. A WTRU can be configured to disable HARQ feedback, for example, when in an inactive state (e.g., under inactive conditions). A WTRU can be configured (e.g., for the purpose of calculating reliability metrics) to maintain statistics related to the number of generated NACKs, for example, until the transport block is successfully decoded. A WTRU can be configured to measure statistics related to the number of NACKs within a pre-configured time interval.

[0146] WTRU can be configured to monitor statistics associated with the number of repetitions related to the successful decoding of MBS transport blocks.

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

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

[0149] WTRU can be configured to monitor the median and / or pattern of the number of repetitions for successful decoding of MBS transport blocks.

[0150] Reliability metrics can be based on the Multicast Channel Block Error Rate (MCH BLER). The WTRU can be configured to monitor the results of PDSCH decoding associated with MBS reception. For example, the WTRU can be configured to count the number of Cyclic Redundancy Check (CRC) errors associated with MBS reception (e.g., within a time interval). For example, a reliability metric can be defined based on the number of CRC errors (e.g., within a time interval).

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

[0152] In the example, WTRU can define the reliability metric as the ratio between the number of successful MBS PDSCHs received within a time interval and the number of successful MBS PDCCHs received.

[0153] Reliability metrics can be based on one or more reference signals (RS). A WTRU can (e.g., be configured to) determine a reliability metric based on one or more reference signal measurements. For example, a WTRU can (e.g., be configured to) measure the MBSFN reference signal received power (MBSFN RSRP). For example, the MBS RSRP can be defined (e.g., and / or determined) as a (e.g., linear) average of the power contribution (e.g., in watts (W)) of the resource element carrying the MBS reference signal within the considered measurement frequency bandwidth. For example, the MBS RSRP measurement can assume an RS transmission with an antenna port configured for MBS transmission.

[0154] For example, the WTRU can be configured to measure MBS reference signal reception quality (RSRQ). For example, MBSRSRQ can be defined (e.g., and / or determined) as a ratio N × MBS RSRP / (MBS carrier reference signal strength indicator (RSSI)), where, for example, N can be the number of RBs in the MBS carrier RSSI measurement bandwidth. Measurements in the numerator and denominator can be performed on the same set of resource blocks. For example, the MBS carrier RSSI can include (e.g., defined and / or calculated as) a linear average of the total received power (e.g., in W) observed in Orthogonal Frequency Division Multiplexing (OFDM) symbols over N number of resource blocks, including reference symbols (e.g., within a pre-configured MBS measurement bandwidth) for an antenna port configured for MBS transmission. This power can include power from one or more (e.g., all) sources, such as co-channel serving and non-serving cells, adjacent channel interference, thermal noise, etc.

[0155] Reliability monitoring can be associated with reliability indications. A WTRU can be configured to perform a reliability monitoring process, which may include one or more of the following: measuring one or more reliability metrics; maintaining counters associated with the reliability metrics; determining statistics associated with the reliability metrics; monitoring the value of one or more reliability metrics and comparing that metric or value to one or more thresholds (e.g., pre-configured thresholds); or triggering the transmission of a reliability indication to the network (e.g., based on a metric or value that meets a threshold condition (e.g., a trigger condition)). The WTRU can be configured to perform the monitoring process at pre-configured time intervals. Time intervals can be configured (e.g., explicitly configured). Time intervals can be specific to the MBS service. Time intervals can be based on time (e.g., a timer) (e.g., defined / tracked). For example, the duration (e.g., the value of a timer) can be part of the MBS configuration. In the example, the time interval can be implicit. In the example, the time interval can correspond to an MCCH repetition cycle. In the example, the time interval can correspond to an MCCH modification cycle. In the example, the time interval can be defined with respect to the MCCH modification cycle. In the example, this relationship can be represented by an offset. In the example, the time interval can be defined with respect to the RAN paging interval. WTRU can be configured as a transmission reliability indicator, which can implicitly or explicitly indicate a reliability metric. Different time intervals can be specified for different triggering conditions.

[0156] In this example, the evaluation of conditions can continue for an evaluation period. For example, the WTRU can be configured to evaluate the average CQI (e.g., over the evaluation duration). The WTRU can continue measuring the CQI for a period of time, averaging the measured CQIs, and comparing the average to a provided threshold. In this example, the WTRU can be provided with a scaling factor that can be used to calculate and / or aggregate these conditions. For example, values ​​measured at the beginning of the evaluation period can be assigned a higher weight than values ​​measured near the end of the evaluation period.

[0157] The evaluation of conditions can be stopped before the end of the evaluation period, for example, if criteria have been met. For example, the WTRU can be configured to detect whether more than a certain number of faults have been detected (e.g., configured, determined, set, or selected). For example, if the WTRU detects a configured number of faults before the end of the evaluation period, the WTRU can stop monitoring the number of faults.

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

[0159] In the example, the WTRU can be configured to perform reliability monitoring in an inactive state, for example, if / when the WTRU receives a reliability poll (e.g., a polling request) from the network. Reliability polling can be received in MCCH transports. Reliability polling can be received in MCCH change notifications. Reliability polling can be received in RAN paging messages. Reliability polling can indicate whether reliability monitoring is requested for one (e.g., a specific) multicast group or multiple (e.g., all) multicast groups. The WTRU can be configured to activate or deactivate reliability monitoring, for example, via MAC CE.

[0160] Based on the reliability poll received during the MCCH modification period n, the WTRU can initiate reliability monitoring during, for example, a time window corresponding to modification period n+1. In the example, the WTRU can be configured to initiate / track the duration (e.g., via a timer) and / or perform reliability monitoring based on the received poll (e.g., as long as the tracked duration has not terminated, e.g., the timer is running).

[0161] In the example, the WTRU can be configured to perform reliability monitoring for MBS services (e.g., a specific MBS service) and / or MBS radio bearers (e.g., a specific MBS radio bearer). For example, reliability monitoring can be configured via RRC configuration, MAC CE, etc. MBS radio bearers and / or MBS services can be identified, for example, via group identifiers, RNTIs, etc. The WTRU can measure reliability metrics, for example, for MBS transport blocks associated with the MBS service (e.g., only for MBS transport blocks associated with the MBS service). For example, transport blocks can be scheduled via a configured group RNTI.

[0162] In the example, the WTRU can be configured to release and / or stop the reliability monitoring and / or reliability indication process based on leaving an inactive state (e.g., entering a connected state or an idle state) (e.g., under the condition of leaving an inactive state).

[0163] In the example, the WTRU can be configured to release and / or stop the reliability monitoring and / or reliability indication process based on one or more of the following (e.g., under one or more of the following conditions): reselect to a cell outside the MBS area configured for the WTRU; reselect to a cell outside the current RAN area that can be applied to an inactive state; reselect to a cell that does not support MBS services; reselect to a cell that does not support MBS services that the WTRU can currently be configured with; or reselect to a cell that does not support the reliability monitoring and / or indication process.

[0164] One or more triggers can be provided for the transmission of reliability indications (e.g., the WTRU is triggered to send a reliability indication under certain conditions). The WTRU can initiate the transmission of reliability indications (e.g., transmit a reliability indication) based on one or more trigger conditions, which can be configured to be WTRU-specific or MBS service-specific (e.g., as disclosed herein). The triggers for reliability indications can be one or more of the following (e.g., a combination): polling-based, event-triggered, and / or periodic. The WTRU can (e.g., if / when more than one trigger type is configured) prioritize polling-based indications, followed by event-triggered indications, and then periodic indications.

[0165] Reliability indication triggering can be based on, for example, polling during MCCH transmission. The WTRU can trigger reliability indication transmission based on polling information during MCCH transmission. For example, the WTRU can (e.g., be configured to) monitor the MCCH at each MCCH repetition period within the MCCH modification period. For example, an MCCH transmission received during modification period n can notify the WTRU of the action to be performed in a subsequent MCCH modification period (e.g., longer than period n (>n)). The WTRU can be configured to perform reliability monitoring in modification period n+k. The WTRU can be configured to perform reliability indication transmission in modification period n+I, where I>k (e.g., k=1 and I=2).

[0166] The WTRU can receive reliability indication polling during a transmission (e.g., in an MCCH transmission, which can be used as an example). The MCCH transmission (e.g., reliability indication polling within an MCCH transmission) can instruct the WTRU to transmit a reliability indication in an upcoming modification cycle (e.g., the next modification cycle, a subsequent modification cycle of the identifier, etc.). The MCCH transmission can instruct (e.g., configure) a filtering criterion for the reliability indication. For example, the filtering criterion can specify the highest reliability metric applicable to the reliability indication. For example, the WTRU can transmit a reliability indication if / when (e.g., only if) the measured reliability metric is lower than or equal to the configured filtering criterion. For example, the WTRU can skip a reliability indication transmission if the reliability metric is higher than the configured filtering criterion.

[0167] The WTRU can receive reliability indication polling specific to MBS radio bearers and / or MBS services. For example, if (e.g., only if) the WTRU is configured for an MBS radio bearer and / or MBS service (e.g., a specific MBS radio bearer and / or MBS service), the WTRU can trigger a reliability indication (e.g., determine to send a reliability indication). For example, polling information received via the MCCH based on group RNTI scheduling can activate a reliability indication from a WTRU configured for an MBS radio bearer (e.g., and / or MBS service) associated with a group RNTI. In the example, the WTRU can perform a reliability indication for one or more MBS bearers configured with reliability monitoring.

[0168] The WTRU can receive MCCH transmissions with polling requests associated with a GRNTI (e.g., a pre-configured GRNTI). The WTRU can receive information indicating the number of MBS transport blocks within a modification period n (e.g., the expected number of MBS transport blocks within modification period n). The WTRU can use this information to determine reliability metrics (e.g., the ratio of successfully received transport blocks to the total number of MBS transport blocks within the modification period, the number of successfully received transport blocks within the modification period, etc.). The WTRU can determine the average number of retransmissions and / or duplicates (e.g., required) of successfully received MBS transport blocks.

[0169] Polling via MCCH can be achieved, for example, using polling instructions in RAN paging.

[0170] Reliability indicators can be periodic, for example, relative to the MCCH modification cycle. WTRUs can be configured to periodically transmit reliability indicators. Periodicity can be configured, for example, according to the modification cycle (e.g., at each modification cycle boundary and / or at RACH timings offset from the modification cycle boundary). For example, the periodicity of reliability indicators can be configured as a multiple of the modification cycle (e.g., every n modification cycles, where n can be greater than or equal to one (>=1)). In the example, n can be a fraction, which can mean that multiple reliability indicators can exist within a modification cycle.

[0171] The WTRU can receive periodicity messages indicating the modification period (e.g., RRC configuration). Different periodicities can be configured for reliability indicators associated with different MBS radio bearers. The WTRU can be configured to activate and / or deactivate the periodic reliability indicators via MAC CE. Periodic reporting can be selectively activated or deactivated, for example, on a per-MBS radio bearer basis.

[0172] WTRU can (for example, be configured to) transmit reliability indications based on one or more (pre-)configured events. For example, the triggering condition for transmitting a reliability indication can be based on a reliability metric being higher or lower than a (pre-)configured threshold. For example, a WTRU may transmit a reliability indication if / when one or more of the following conditions are met: the average number of repetitions for successful MBS transport block reception within a pre-configured time interval meets (e.g., above) a threshold, or different statistics, such as the median or number of patterns of repetitions for successful MBS transport block reception within a pre-configured time interval, meet (e.g., above) a threshold; the minimum CQI associated with MBS reception within a pre-configured time interval meets (e.g., below) a threshold; the ratio of the number of MBS transport block repetitions to the total number of MBS transport blocks within a pre-configured time interval meets (e.g., above) a threshold; the number of transport blocks that failed to be successfully received (e.g., exceeding the maximum number of repetitions before successful decoding) meets (e.g., above) a threshold; a statistic associated with MCH BLER within the time interval meets (e.g., above) a threshold; the number of NACKs associated with MBS transport blocks counted by the WTRU within the time interval meets (e.g., above) a threshold; the average MBS RSRP within the time interval meets (e.g., below) a threshold; and / or the average MBS RSRQ within the time interval meets (e.g., below) a threshold.

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

[0174] A reliability indication can be transmitted. An association can exist between a reliability metric and a UL resource. The WTRU can be (pre-)configured with rules for determining the UL resource to which the reliability indication is transmitted. For example, these rules can be based on the value or range of the reliability metric. The WTRU can be configured with multiple UL resources. UL resources can be mapped to values ​​or ranges of the reliability metric (e.g., each UL resource can be mapped to a corresponding value or range of the reliability metric). For example, the WTRU can be configured with a set of UL resources for transmitting a reliability indication and an association between a specific UL resource and the value or range of the reliability metric. The WTRU can (e.g., if / when one or more of the triggering conditions are met) select the UL resource associated with the value or range of the reliability metric, and the WTRU can transmit a reliability indication that can indicate a reliability indicator (e.g., a reliability metric and / or a reliability metric range).

[0175] In the example, UL resources can be random access (RA) resources. The terms RA resources and Physical Random Access Channel (PRACH) resources are used interchangeably. RA resources can refer to time resources, frequency resources, spatial resources, RACH timing (RO), preamble format, etc. The preamble format can be configured, for example, according to the total preamble duration, sequence type, sequence length, guard duration, cyclic prefix length, etc.

[0176] An association can exist between CQI indices and RA resources. A WTRU can be configured with a mapping between CQI indices (e.g., or their ranges) and preambles and / or RACH timings (e.g., a mapping between each corresponding CQI index and the corresponding preamble and / or RACH timing). A WTRU can be configured with a mapping between CQI indices (e.g., or their ranges) and PRACH configuration indices that identify RA resources (e.g., a mapping between each corresponding CQI index and the corresponding PRACH configuration index that identifies the corresponding RA resource). The WTRU can determine the mapped RA resource (e.g., preamble x and RACH timing y) and transmit preamble x in RACH timing y, for example, if / when a reliability indication is triggered, for example, by a CQI value n. RA resources can be specific to CQI ranges (e.g., and can be non-WTRU specific), which can reduce collisions and resource overhead.

[0177] In the example, the WTRU can be configured with a UL resource for reliability indication (e.g., only one UL resource). For example, if the CQI is below a (pre-)configured threshold, the WTRU can be configured to transmit a preamble on that resource.

[0178] Different associations can be configured for different reliability metrics (e.g., similar to the CQI example). WTRU can be configured with a mapping between RA resources and a statistic or range of values ​​associated with the number of repetitions (e.g., over time intervals) for successful MBS transport block reception. WTRU can be configured with a mapping between RA resources and the ratio of the number of MBS transport block repetitions to the number of MBS transport blocks (e.g., total number) (e.g., over time intervals). WTRU can be configured with a mapping between RA resources and the number of transport blocks that failed to be received successfully (e.g., over time intervals). WTRU can be configured with a mapping between RA resources and a statistic associated with MCH BLER (e.g., over time intervals). WTRU can be configured with a mapping between RA resources and the number of negative acknowledgment responses (NACKs) associated with MBS transport blocks (e.g., over time intervals). WTRU can be configured with a mapping between RA resources and a range of average MBS RSRP / RSRQ values ​​(e.g., over time intervals).

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

[0180] The mapping between reliability metrics and UL resources can be specific to the MBS service / MRB. For example, a WTRU can receive multiple reliability metrics associated with a RA resource. For example, a WTRU can be configured such that the RACH timing does not overlap with the MBS service when the WTRU is configured to be inactive.

[0181] Configurations relating to the mapping between reliability metrics and UL resources can be applied to multiple cells (e.g., all cells) within a logical region (e.g., MBS region, RAN region, etc.). The mapping can be configured to be effective only for the current cell (e.g., only for the current cell). WTRUs can release their configurations, for example, based on reselection to a different cell when inactive (e.g., under its conditions).

[0182] Different types of reliability indications can be provided (e.g., configured and / or sent) for different ranges of reliability indicators (e.g., reliability metrics). In the example, the WTRU can be configured with different actions based on the value or range of the reliability metric. For example, if the reliability metric is in a first range, the WTRU can use (pre-)configured RA resources to perform a reliability indication procedure. For example, if the reliability metric is in a second range, the WTRU can initiate a recovery procedure. For example, if the reliability metric is in a second range, the WTRU can initiate a WTRU identifier transmission procedure (e.g., the WTRU can transmit a unique WTRU identifier associated with an inactive state). For example, if the reliability metric is in a second range, the WTRU can initiate a periodic RAN update procedure. In the example, the second range can be lower than the first range. In the example, the second range can correspond to a reliability lower than the reliability associated with the first range. In the example, polling indications in MCCH transmissions can instruct the WTRU whether to perform a reliability indication procedure and / or a recovery procedure. In the example, the WTRU can be configured to monitor multiple reliability metrics and associated triggering conditions. The WTRU can be configured with different actions, for example, based on specific reliability metrics that satisfy these triggering conditions. WTRU can be configured to have which actions apply to (e.g., each) the reliability metrics of the configuration.

[0183] This document discloses the processing associated with a Random Access Response (RAR) and a reliability indication. The WTRU can be configured to monitor the RAR, for example, after transmitting a reliability indication (e.g., a reliability indicator of a reliability indicator, such as a reliability metric). For example, if the WTRU transmits a pre-configured preamble for the reliability indication and / or if the WTRU transmits a pre-configured pre-configured RO for the reliability indication, the WTRU can be configured to begin the RA response window (e.g., ra-ResponseWindow) using a value associated with the reliability indication configuration, a value configured as part of RACH-ConfigCommon, or a default value. In the example, the WTRU can be configured to monitor an RNTI (e.g., a specific RNTI) to receive the RAR associated with the transmitted reliability indication. The RNTI (e.g., a specific RNTI) can be configured with a default RNTI, a (pre-)configured RNTI, or can be configured relative to (e.g., specific to) a multicast group. For example, alternatively and / or without configuration, the WTRU can use the RA-RNTI to monitor the RAR.

[0184] For example, if the ra-ResponseWindow configured for the reliability indication terminates and / or if no RAR including a Random Access Preamble Identifier (RAPID) matching the preamble associated with the reliability indication is received, the WTRU may consider (e.g., determine) that the RAR reception was unsuccessful. For example, if a valid downlink allocation has been received on the PDCCH used for RA-RNTI and / or if the RAR includes a MAC sub-PDU with a fallback indicator, the WTRU may consider the RAR reception unsuccessful. The WTRU may retry the transmission of the reliability indication, for example, for a (pre-)configured number of attempts. For example, if the RAR reception is unsuccessful, for example, after the maximum number of attempts, the WTRU may be configured to initiate a recovery procedure. The WTRU may be configured to initiate a recovery procedure, for example, requesting a transition from an inactive state to a connected state. The WTRU may be configured with an access class for the recovery procedure, for example, based on the MBS service type, for example, as part of the MBS configuration. The WTRU may initiate the transmission of an RCResumeRequest message. WTRU can be configured as an instance (e.g., a new instance) to initiate a RACH procedure for the transmission of RRCResumeRequest messages.

[0185] For example, if a valid downlink allocation and / or random access response, including a MAC subPDU with a RAPID corresponding to the transmitted preamble for reliability indication, has been received on the PDCCH for RA-RNTI, the WTRU can consider the RAR reception successful.

[0186] The WTRU can (e.g., if RAR reception is successful) perform subsequent actions, such as based on the MAC sub-PDU (e.g., its content).

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

[0188] The WTRU can be configured to receive a random access response, which includes a MAC sub-PDU with a RAPID field corresponding to a reliability indication and an associated RAR payload. The RAR payload format can be specific to the reliability indication. Reserved bits R in the RAR payload can be set (e.g., to 1) to indicate a different format. Timing advance fields, UL clearance fields, and / or temporary CRNTI fields can be interpreted differently, for example, if the response to the reliability indication is included in the RAR payload. The RAR payload for the reliability indication response can include one or more of the following fields (e.g., corresponding performance of WTRU action): an indication of whether the WTRU intends to initiate a recovery procedure and / or an indication that the WTRU intends to provide WTRU identification information.

[0189] For example, based on (e.g., in the RAR payload) receiving an indication whether the WTRU should initiate a recovery procedure (e.g., under its conditions), the WTRU can be configured to initiate (e.g., or not initiate) a recovery procedure. For instance, if the network determines (e.g., based on a reliability indication) that the WTRU will (e.g., needs to) enter a connected state to meet the QoS requirements of the MBS service, the WTRU can receive an indication (e.g., whether to initiate a recovery procedure). The WTRU can then initiate the transmission of an RRCResumeRequest message.

[0190] A WTRU can be configured to provide a WTRU-specific identifier to the network, for example, based on an indication that the WTRU will provide WTRU identification information (e.g., the WTRU can transmit an I-RNTI). The I-RNTI value can be used to identify the suspended WTRU context in RRC_INACTIVE. A WTRU can be configured to transmit a truncated version of the I-RNTI (e.g., a shorter I-RNTI value). For example, the NW can determine (e.g., based on a reliability indication) the existence of at least one WTRU with an associated reliability metric, but the exact number of WTRUs may be unclear. The NW can determine or be informed of the number of WTRUs, for example, to determine a scheduling policy. For example, the NW can adopt or adapt a more conservative approach for group scheduling (e.g., conservative MCS and / or repetition), and / or the NW can move and / or transition WTRUs to a connected state for more stringent control and feedback loops. WTRUs can transmit a WTRU-specific identifier (e.g., an I-RNTI), for example, to enable the NW to determine the number of WTRUs with a reliability metric or its range (e.g., a specific reliability metric or its range).

[0191] The WTRU can initiate a process, such as a process following or as a result of a reliability indication process. For example, such a process could be a recovery process or a process for a WTRU-specific transmission (e.g., as described herein). The WTRU can assume that the RAR received in response to a reliability indication is not WTRU-specific. The WTRU can ignore timing advances and / or UL clearances received in the RAR (e.g., assumed not to be WTRU-specific). The WTRU can be configured to use a RACH process to acquire UL resources (e.g., if / when the WTRU initiates the process). The WTRU can be configured (e.g., as part of the process) to have a type of RACH process to use (e.g., contention-based or contention-free, and / or a 2-step or 4-step RACH process). The WTRU can be configured to reset one or more variables associated with the RACH process. For example, one or more variables can be modified due to a reliability indication transmission. WTRU can reset variables specific to the RACH procedure (e.g., before transmitting a recovery request message), which includes one or more of the following: the type of RACH procedure; variables indicating a 2-step RA or a 4-step RA; a preamble transmission counter; a power ramp associated with the preamble transmission; a scaling factor for backoff; etc.

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

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

[0194] The processes described above can be implemented in computer programs, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and / or digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU) associated with a multicast broadcast service (MBS), the WTRU comprising: Memory; as well as Processor, the processor being configured to: In the Radio Resource Control (RRC) connection state, an indication of interest in receiving MBS services is sent; Receive RRC release information, wherein the RRC release information indicates that multicast service reception is allowed for WTRUs in an RRC inactive state; Based on the RRC release information, the system enters the RRC inactive state. In the RRC inactive state, the reference signal reception quality (RSRQ) value of the serving cell is determined; and An RRC connection recovery procedure is initiated based on the RSRQ value of the serving cell and one or more MBS RSRQ thresholds, wherein the processor is configured to send an RRC recovery request indicating a recovery reason associated with the initiation of the RRC connection recovery procedure.

2. The WTRU according to claim 1, wherein, The processor is also configured to: The RSRQ value of the serving cell is determined to be lower than the MBS RSRQ threshold among the one or more MBS RSRQ thresholds, wherein the RRC connection recovery process is initiated based on the determination that the RSRQ value of the serving cell is lower than the MBS RSRQ threshold.

3. The WTRU according to claim 1, wherein, The processor is also configured to: In the RRC inactive state, the reference signal received power (RSRP) value of the serving cell is determined; as well as The RSRP value of the serving cell is determined to be lower than one of the MBS RSRP thresholds, wherein the RRC connection recovery process is initiated based on the determination that the RSRP value of the serving cell is lower than the MBS RSRP threshold.

4. The WTRU according to claim 1, wherein, The processor is also configured to receive MBS configuration information associated with the RRC inactive state.

5. The WTRU according to claim 4, wherein, The MBS configuration information is received after the RRC release information is received.

6. The WTRU according to claim 4, wherein, The RRC release information indicates the MBS configuration information.

7. The WTRU according to claim 1, wherein, The processor is also configured to receive an RRC recovery message that instructs the WTRU to switch from the RRC inactive state to the RRC connected state.

8. The WTRU according to claim 1, wherein, The reason for the recovery was set to "mbs-call-interest".

9. The WTRU according to claim 1, wherein, The RRC release information is received in the RRC connection state.

10. The WTRU according to claim 1, wherein, The processor is also configured to receive multicast transmissions associated with the MBS session in the RRC inactive state, and the serving cell is associated with the MBS session.

11. A method performed by a wireless transmit / receive unit (WTRU) associated with a multicast broadcast service (MBS), the method comprising: In the Radio Resource Control (RRC) connection state, an indication of interest in receiving MBS services is sent; Receive RRC release information, wherein the RRC release information indicates that multicast service reception is allowed for WTRUs in an RRC inactive state; Based on the RRC release information, the system enters the RRC inactive state. In the RRC inactive state, the reference signal reception quality (RSRQ) value of the serving cell is determined; and The method further includes initiating an RRC connection recovery process based on the RSRQ value of the serving cell and one or more MBS RSRQ thresholds, wherein the method also includes sending an RRC recovery request indicating a recovery reason associated with the initiation of the RRC connection recovery process.

12. The method of claim 11, further comprising: The RSRQ value of the serving cell is determined to be lower than the MBS RSRQ threshold among the one or more MBS RSRQ thresholds, wherein the RRC connection recovery process is initiated based on the determination that the RSRQ value of the serving cell is lower than the MBS RSRQ threshold.

13. The method of claim 11, further comprising: In the RRC inactive state, the reference signal received power (RSRP) value of the serving cell is determined; as well as The RSRP value of the serving cell is determined to be lower than one of the MBS RSRP thresholds, wherein the RRC connection recovery process is initiated based on the determination that the RSRP value of the serving cell is lower than the MBS RSRP threshold.

14. The method of claim 11, further comprising receiving MBS configuration information associated with the RRC inactive state.

15. The method according to claim 14, wherein, The MBS configuration information is received after the RRC release information is received.

16. The method of claim 14, wherein, The RRC release information indicates the MBS configuration information.

17. The method of claim 11, further comprising receiving an RRC recovery message, the RRC recovery message instructing the WTRU to switch from the RRC inactive state to the RRC connected state.

18. The method according to claim 11, wherein, The reason for the recovery was set to "mbs-call-interest".

19. The method of claim 11, further comprising: During the first multicast control channel (MCCH) modification period, an MCCH transmission is received, wherein the MCCH transmission includes a polling request for an indication of the RSRQ value; and Measurements are performed during a second MCCH modification period based on the received MCCH transmissions, wherein the second MCCH modification period is temporally after the first MCCH modification period, and wherein the RSRQ value is determined based on measurements taken during the second MCCH modification period.

Images