WO2024096048A1 - 通信方法 - Google Patents

通信方法 Download PDF

Info

Publication number
WO2024096048A1
WO2024096048A1 PCT/JP2023/039401 JP2023039401W WO2024096048A1 WO 2024096048 A1 WO2024096048 A1 WO 2024096048A1 JP 2023039401 W JP2023039401 W JP 2023039401W WO 2024096048 A1 WO2024096048 A1 WO 2024096048A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
rrc
network
mbs
frequency
Prior art date
Application number
PCT/JP2023/039401
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
光孝 秦
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Publication of WO2024096048A1 publication Critical patent/WO2024096048A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions

Definitions

  • This disclosure relates to a communication method used in a mobile communication system.
  • the 3rd Generation Partnership Project (3GPP) has defined technical specifications for NR (New Radio), a fifth-generation (5G) wireless access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) wireless access technology, NR has features such as high speed, large capacity, high reliability, and low latency. 3GPP has defined technical specifications for 5G/NR multicast/broadcast services (MBS) (see, for example, Non-Patent Document 1).
  • MBS multicast/broadcast services
  • the communication method is a communication method executed by a user device in a mobile communication system that provides a multicast/broadcast service (MBS), and includes the steps of: performing multicast reception in a radio resource control (RRC) inactive state based on a multicast setting received from a network by dedicated signaling; determining, in response to determining that an update of the multicast setting is necessary, to access the network for the update; and determining, based on setting information from the network, whether to apply or skip access control for restricting the access.
  • RRC radio resource control
  • the communication method according to the second aspect is a communication method executed by a user device in a mobile communication system that provides a multicast/broadcast service (MBS), and includes the steps of performing multicast reception in a radio resource control (RRC) inactive state based on a multicast setting received from a network, and regarding, in the RRC inactive state, the frequency to which the cell that transmitted the multicast setting belongs as the highest priority for cell reselection.
  • RRC radio resource control
  • the communication method is a communication method executed by a user device in a mobile communication system that provides a multicast/broadcast service (MBS), and includes the steps of receiving dedicated signaling from a network, the dedicated signaling including designation information that designates a frequency, receiving multicast in a radio resource control (RRC) inactive state, and determining a frequency priority for the cell reselection based on the designation information in the RRC inactive state, without applying a process that considers the frequency determined by the user device as the highest priority for cell reselection.
  • MMS multicast/broadcast service
  • FIG. 1 is a diagram showing a configuration of a mobile communication system according to an embodiment.
  • FIG. 2 is a diagram showing a configuration of a UE (user equipment) according to an embodiment.
  • FIG. 1 is a diagram for explaining a general cell reselection procedure.
  • FIG. 1 illustrates a schematic flow diagram of a typical cell reselection procedure.
  • FIG. 11 is a diagram showing an example of operation of a mobile communication system according to a first operation pattern.
  • FIG. 11 is a diagram showing a first operation example of a mobile communication system according to a second operation pattern.
  • FIG. 11 is a diagram showing a second operation example of the mobile communication system according to the second operation pattern.
  • FIG. 13 is a diagram showing an example of a gap pattern of MBS.
  • FIG. 1 is a diagram showing the configuration of the mobile communication system 1 according to an embodiment.
  • the mobile communication system 1 complies with the 5th generation system (5GS: 5th Generation System) of the 3GPP standard.
  • 5GS will be taken as an example, but an LTE (Long Term Evolution) system may be applied at least in part to the mobile communication system.
  • a sixth generation (6G) system may be applied at least in part to the mobile communication system.
  • the mobile communication system 1 has a user equipment (UE) 100, a 5G radio access network (NG-RAN: Next Generation Radio Access Network) 10, and a 5G core network (5GC: 5G Core Network) 20.
  • UE user equipment
  • NG-RAN Next Generation Radio Access Network
  • 5GC 5G Core Network
  • the NG-RAN 10 may be simply referred to as the RAN 10.
  • the 5GC 20 may be simply referred to as the core network (CN) 20.
  • the RAN 10 and the CN 20 constitute the network of the mobile communication system 1.
  • UE100 is a mobile wireless communication device.
  • UE100 may be any device that is used by a user.
  • UE100 is a mobile phone terminal (including a smartphone) and/or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE).
  • NG-RAN10 includes base station (referred to as "gNB” in the 5G system) 200.
  • gNB200 are connected to each other via an Xn interface, which is an interface between base stations.
  • gNB200 manages one or more cells.
  • gNB200 performs wireless communication with UE100 that has established a connection with its own cell.
  • gNB200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as “data”), a measurement control function for mobility control and scheduling, etc.
  • RRM radio resource management
  • Cell is used as a term indicating the smallest unit of a wireless communication area.
  • Cell is also used as a term indicating a function or resource for performing wireless communication with UE100.
  • One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").
  • gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE.
  • EPC Evolved Packet Core
  • LTE base stations can also be connected to 5GC.
  • LTE base stations and gNBs can also be connected via a base station-to-base station interface.
  • 5GC20 includes AMF (Access and Mobility Management Function) and UPF (User Plane Function) 300.
  • AMF performs various mobility controls for UE100.
  • AMF manages the mobility of UE100 by communicating with UE100 using NAS (Non-Access Stratum) signaling.
  • UPF controls data forwarding.
  • AMF and UPF are connected to gNB200 via the NG interface, which is an interface between a base station and a core network.
  • FIG. 2 is a diagram showing the configuration of a UE 100 (user equipment) according to an embodiment.
  • the UE 100 has a receiving unit 110, a transmitting unit 120, and a control unit 130.
  • the receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200.
  • the receiving unit 110 performs various types of reception under the control of the control unit 130.
  • the receiving unit 110 includes an antenna and a receiver.
  • the receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.
  • the transmitting unit 120 performs various transmissions under the control of the control unit 130.
  • the transmitting unit 120 includes an antenna and a transmitter.
  • the transmitter converts the baseband signal (transmission signal) output by the control unit 130 into a radio signal and transmits it from the antenna.
  • the control unit 130 performs various controls and processes in the UE 100. Such processes include the processes of each layer described below. The operations of the UE 100 described above and below may be operations under the control of the control unit 230.
  • the control unit 130 includes at least one processor and at least one memory.
  • the memory stores programs executed by the processor and information used in the processing by the processor.
  • the processor may include a baseband processor and a CPU (Central Processing Unit).
  • the baseband processor performs modulation/demodulation and encoding/decoding of baseband signals.
  • the CPU executes programs stored in the memory to perform various processes.
  • FIG. 3 is a diagram showing the configuration of a gNB 200 (base station) according to an embodiment.
  • the gNB 200 has a transmitting unit 210, a receiving unit 220, a control unit 230, and a backhaul communication unit 240.
  • the transmitting unit 210 and the receiving unit 220 constitute a wireless communication unit that performs wireless communication with the UE 100.
  • the backhaul communication unit 240 constitutes a network communication unit that performs communication with the CN 20.
  • the transmitting unit 210 performs various transmissions under the control of the control unit 230.
  • the transmitting unit 210 includes an antenna and a transmitter.
  • the transmitter converts the baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits it from the antenna.
  • the receiving unit 220 performs various types of reception under the control of the control unit 230.
  • the receiving unit 220 includes an antenna and a receiver.
  • the receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.
  • the control unit 230 performs various controls and processes in the gNB 200. Such processes include the processes of each layer described below.
  • the operations of the gNB 200 described above and below may be operations under the control of the control unit 230.
  • the control unit 230 includes at least one processor and at least one memory.
  • the memory stores programs executed by the processor and information used in the processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor performs modulation/demodulation and encoding/decoding of baseband signals.
  • the CPU executes programs stored in the memory to perform various processes.
  • the backhaul communication unit 240 is connected to adjacent base stations via an Xn interface, which is an interface between base stations.
  • the backhaul communication unit 240 is connected to the AMF/UPF 300 via an NG interface, which is an interface between a base station and a core network.
  • the gNB 200 may be composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally divided), and the two units may be connected via an F1 interface, which is a fronthaul interface.
  • Figure 4 shows the protocol stack configuration of the wireless interface of the user plane that handles data.
  • the user plane radio interface protocol has a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.
  • PHY physical
  • MAC medium access control
  • RLC radio link control
  • PDCP packet data convergence protocol
  • SDAP service data adaptation protocol
  • the PHY layer performs encoding/decoding, modulation/demodulation, antenna mapping/demapping, and resource mapping/demapping. Data and control information are transmitted between the PHY layer of UE100 and the PHY layer of gNB200 via a physical channel.
  • the PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH).
  • DCI downlink control information
  • PDCCH physical downlink control channel
  • RNTI radio network temporary identifier
  • the DCI transmitted from gNB200 has CRC (Cyclic Redundancy Code) parity bits scrambled by the RNTI added.
  • the MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of UE100 and the MAC layer of gNB200 via a transport channel.
  • the MAC layer of gNB200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to UE100.
  • MCS modulation and coding scheme
  • the RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the RLC layer on the receiving side. Data and control information are transmitted between the RLC layer of UE100 and the RLC layer of gNB200 via logical channels.
  • the PDCP layer performs header compression/decompression, encryption/decryption, etc.
  • the SDAP layer maps IP flows, which are the units for which the core network controls QoS (Quality of Service), to radio bearers, which are the units for which the AS (Access Stratum) controls QoS. Note that if the RAN is connected to the EPC, SDAP is not necessary.
  • Figure 5 shows the configuration of the protocol stack for the wireless interface of the control plane that handles signaling (control signals).
  • the protocol stack of the radio interface of the control plane has an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer instead of the SDAP layer shown in Figure 4.
  • RRC Radio Resource Control
  • NAS Non-Access Stratum
  • RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200.
  • the RRC layer controls logical channels, transport channels, and physical channels in response to the establishment, re-establishment, and release of radio bearers.
  • RRC connection connection between the RRC of UE100 and the RRC of gNB200
  • UE100 is in an RRC connected state.
  • RRC connection no connection between the RRC of UE100 and the RRC of gNB200
  • UE100 is in an RRC idle state.
  • UE100 is in an RRC inactive state.
  • the NAS layer (also simply referred to as "NAS") located above the RRC layer performs session management, mobility management, etc.
  • NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF300A.
  • UE100 also has an application layer, etc.
  • AS layer also simply referred to as "AS”
  • the mobile communication system 1 can perform resource-efficient distribution by using a multicast/broadcast service (MBS).
  • MBS multicast/broadcast service
  • a multicast communication service also called “MBS multicast”
  • MBS multicast the same service and the same specific content data are provided simultaneously to a specific set of UEs. That is, not all UEs 100 in a multicast service area are allowed to receive the data.
  • the multicast communication service is delivered to the UEs 100 using a multicast session, which is a type of MBS session.
  • the UEs 100 can receive the multicast communication service in the RRC connected state using mechanisms such as Point-to-Point (PTP) and/or Point-to-Multipoint (PTM) delivery.
  • PTP Point-to-Point
  • PTM Point-to-Multipoint
  • the UEs 100 may receive the multicast communication service in the RRC inactive (or RRC idle) state.
  • Such a delivery mode is also called "Delivery Mode 1".
  • broadcast communication service also referred to as "MBS broadcast”
  • MBS broadcast the same service and the same specific content data are provided simultaneously to all UEs 100 in a geographical area. That is, all UEs 100 in the broadcast service area are allowed to receive the data.
  • the broadcast communication service is delivered to the UEs 100 using a broadcast session, which is a type of MBS session.
  • the UEs 100 can receive the broadcast communication service in any of the following states: RRC idle state, RRC inactive state, and RRC connected state.
  • Such a delivery mode is also referred to as "delivery mode 2".
  • the main logical channels used for MBS distribution are the Multicast Traffic Channel (MTCH), the Dedicated Traffic Channel (DTCH), and the Multicast Control Channel (MCCH).
  • the MTCH is a PTM downlink channel for transmitting MBS data of either a multicast session or a broadcast session from the network 10 to the UE 100.
  • the DTCH is a PTP channel for transmitting MBS data of a multicast session from the network 10 to the UE 100.
  • the MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from the network 10 to the UE 100.
  • UE100 in RRC idle state, RRC inactive state, or RRC connected state receives PTM settings for the broadcast session (e.g., parameters required for MTCH reception) via MCCH.
  • the parameters required for MCCH reception (MCCH settings) are provided via system information.
  • system information block type 20 SIB20
  • SIB type 21 SIB21 includes information on service continuity for MBS broadcast reception.
  • MCCH provides a list of all broadcast services including ongoing sessions transmitted on MTCH, and the related information for the broadcast session includes MBS session identifiers (e.g., TMGI (Temporary Mobile Group Identity)), related MTCH scheduling information, and information on neighboring cells providing a particular service on MTCH.
  • MBS session identifiers e.g., TMGI (Temporary Mobile Group Identity)
  • TMGI Temporal Mobile Group Identity
  • UE100 can only receive data of a multicast session in the RRC connected state.
  • gNB200 transmits an RRC reconfiguration message including a PTM configuration for the multicast session to UE100.
  • PTM configuration is also referred to as a multicast radio bearer (MRB) configuration, MTCH configuration, or multicast configuration.
  • MRB multicast radio bearer
  • the MRB configuration includes an MBS session identifier (mbs-SessionId), an MRB identifier (mrb-Identity), and other parameters such as a PDCP configuration (pdcp-Config) for the MRB (multicast MRB) to be configured in UE100.
  • MBS session identifier mbs-SessionId
  • MRB identifier mrb-Identity
  • pdcp-Config a PDCP configuration for the MRB (multicast MRB) to be configured in UE100.
  • Figure 6 shows an overview of the operation.
  • Possible solutions for a UE 100 in an RRC inactive state to receive multicast include a delivery mode 1 based solution shown in FIG. 6(a) and a delivery mode 2 based solution shown in FIG. 6(b).
  • step S1 the gNB 200 sends an RRC Reconfiguration message including MBS settings (multicast settings) for the multicast session to the UE 100 in the RRC connected state.
  • the UE 100 receives multicast data on the MTCH via the multicast session (multicast MRB) based on the multicast settings received in the RRC Reconfiguration message.
  • step S2 gNB200 transmits an RRC Release message to UE100 in the RRC Connected state to transition UE100 to the RRC Inactive state.
  • the RRC Release message includes a setting (Suspend Config.) for the RRC Inactive state.
  • step S3 UE 100 transitions from the RRC connected state to the RRC inactive (INACTIVE) state in response to receiving the RRC Release message in step S2.
  • step S4 UE 100 in the RRC inactive state continues to use the multicast settings of step S1 to receive multicast data on the MTCH via the multicast session.
  • multicast configuration may also be performed using an RRC Release message.
  • the RRC Reconfiguration message and the RRC Release message are both RRC messages that are transmitted individually to a UE on a dedicated control channel (DCCH), and are hereinafter also referred to as dedicated RRC messages.
  • DCCH dedicated control channel
  • step S11 the gNB 200 transmits an RRC Release message to the UE 100 in the RRC connected state to transition the UE 100 to the RRC inactive state.
  • the RRC Release message includes a setting (Suspend Config.) for the RRC inactive state.
  • step S12 UE 100 transitions to the RRC inactive (INACTIVE) state in response to receiving the RRC Release message in step S11.
  • step S13 gNB200 transmits an MCCH including an MBS setting (multicast setting) for the multicast session.
  • UE100 receives the MCCH.
  • UE100 receives SIB20 prior to receiving the MCCH, and receives the MCCH based on SIB20.
  • MCCH transmission (and reception) may be performed prior to step S11, or may be performed simultaneously with step S11.
  • step S14 UE 100 in the RRC inactive state receives multicast data on the MTCH via a multicast session based on the multicast setting received on the MCCH in step S13. This enables UE 100 in the RRC inactive state to perform multicast reception.
  • FIG. 7 is a diagram for explaining a general cell reselection procedure.
  • the UE 100 in the RRC idle state or the RRC inactive state performs a cell reselection procedure to move from the current serving cell (cell #1) to a neighboring cell (any of cells #2 to #4) as it moves.
  • the UE 100 identifies a neighboring cell on which the UE 100 should camp by the cell reselection procedure, and reselects the identified neighboring cell.
  • the frequency (carrier frequency) of the current serving cell and the neighboring cell is the same, it is called an intra-frequency, and when the frequency (carrier frequency) of the current serving cell and the neighboring cell is different, it is called an inter-frequency.
  • the current serving cell and the neighboring cell may be managed by the same gNB 200.
  • the current serving cell and the neighboring cell may be managed by different gNBs 200.
  • Figure 8 shows the general flow of a typical cell reselection procedure.
  • step S10 the UE 100 performs frequency prioritization processing based on the priority for each frequency (also referred to as "absolute priority” or “cell reselection priority” or “dedicated priority”) specified by the gNB 200, for example, by a system information block (SIB) or an RRC release message. Specifically, the UE 100 manages the frequency priority specified by the gNB 200 for each frequency.
  • SIB system information block
  • RRC release message Specifically, the UE 100 manages the frequency priority specified by the gNB 200 for each frequency.
  • UE100 performs a measurement process to measure the radio quality of each of the serving cell and the neighboring cell.
  • UE100 measures the reception power and reception quality of the reference signals transmitted by each of the serving cell and the neighboring cell, specifically, the CD-SSB (Cell Defining-Synchronization Signal and PBCH block).
  • CD-SSB Cell Defining-Synchronization Signal and PBCH block.
  • UE100 always measures the radio quality for frequencies having a higher priority than the priority of the frequency of the current serving cell, and for frequencies having a priority equal to or lower than the priority of the frequency of the current serving cell, UE100 measures the radio quality of the frequency having the same priority or lower priority when the radio quality of the current serving cell falls below a predetermined quality.
  • step S30 UE100 performs a cell reselection process to reselect a cell on which UE100 will camp based on the measurement result in step S20.
  • UE100 may perform cell reselection to a neighboring cell if the frequency priority of the neighboring cell is higher than the priority of the current serving cell and the neighboring cell satisfies a predetermined quality standard (i.e., a minimum required quality standard) for a predetermined period of time.
  • a predetermined quality standard i.e., a minimum required quality standard
  • UE100 may rank the wireless quality of the neighboring cell and perform cell reselection to a neighboring cell having a higher rank than the rank of the current serving cell for a predetermined period of time if the frequency priority of the neighboring cell is lower than the priority of the current serving cell and the wireless quality of the current serving cell is lower than a certain threshold and the wireless quality of the neighboring cell is higher than another threshold for a predetermined period of time.
  • UE100 may perform cell reselection to the neighboring cell if the frequency priority of the neighboring cell is lower than the priority of the current serving cell and the wireless quality of the current serving cell is lower than a certain threshold and the wireless quality of the neighboring cell is higher than another threshold.
  • UEs 100 in RRC idle or RRC inactive state that support MBS apply the cell reselection described above with the following modifications. Specifically, UEs 100 that are receiving or are interested in receiving MBS broadcast services via Point-to-Multipoint (PTM) are allowed to make a frequency that offers these MBS broadcast services the highest priority (higher than the priority of other network settings) when they can only receive these MBS broadcast services by camping on that frequency.
  • PTM Point-to-Multipoint
  • UE100 will no longer prioritize that frequency. Also, UE100 that is receiving or is interested in receiving MBS broadcast services via PTM is permitted to give the frequencies on which it cannot receive those MBS broadcast services the lowest priority (lower than the priority of other network settings).
  • the mobile communication system 1 supports access control called UAC (Unified Access Control).
  • UAC Unified Access Control
  • Such access control can prevent, for example, congestion of the network 5. Details of UAC are specified in Chapter 5.3.14 of the 3GPP technical specification: TS38.331, but an overview of UAC will be described here.
  • UAC can perform access restriction for UE100 in all RRC states (RRC idle state, RRC inactive state, and RRC connected state).
  • Each communication request in UE100 is associated with one access category (Access Category) and one or more access identifiers (Access Identity).
  • gNB200 can perform restriction for each of these combinations.
  • An access category is an identifier for a service type.
  • An access identifier is an identifier for a call type.
  • gNB200 notifies UE100 of the access identifier and parameter value to be restricted for each access category.
  • UE100 determines whether or not restriction is necessary based on the access category and access identifier, and if restriction is necessary, performs restriction operation according to the parameter value.
  • a scenario is mainly assumed in which a UE 100 in an RRC inactive state receives multicast using a distribution mode 1-based solution.
  • a distribution mode 2-based solution may be applied.
  • a scenario is assumed in which a UE 100 in an RRC inactive state performs multicast reception
  • a scenario in which a UE 100 in an RRC idle state performs multicast reception may also be assumed.
  • the RRC idle state in the description of the following embodiment may be read as the RRC inactive state.
  • UE 100 in the RRC inactive state accesses network 5 by transmitting an RRC Resume Request message to network 5.
  • UE 100 that transmitted an RRC Resume Request message to network 5 receives an RRC Release message including new PTM settings from network 5 in response to the RRC Resume Request message, UE 100 can acquire the new PTM settings without transitioning to the RRC connected state.
  • access control by the UAC is normally applied before transmitting an RRC Resume Request message to the network 5. If access is restricted by access control, the UE 100 cannot transmit an RRC Resume Request message to the network 5.
  • UE 100 performing multicast reception in an RRC inactive state accesses the network 5 to update the PTM settings, it may be possible to skip the UAC. If unicast communication is not performed but only PTM settings are updated, the load on the network 5 does not increase, so it is reasonable to not be restricted by access control.
  • one of the motivations for multicast reception in an RRC inactive state is to reduce network congestion, and it is not desirable for a large number of UEs 100 to access the network 5 by skipping the UAC during network congestion. Therefore, in this operation pattern, it is possible to set from the network 5 whether to apply or skip the UAC when UE 100 performing multicast reception in an RRC inactive state accesses the network 5 to update the PTM settings.
  • UE 100 performs multicast reception in the RRC inactive state based on the multicast setting (PTM setting) received from network 5 by dedicated signaling. Second, UE 100 decides to access network 5 for updating in response to determining that the multicast setting needs to be updated. Third, UE 100 determines whether to apply or skip access control (UAC) for restricting access based on setting information from network 5 (also referred to as "UAC skip availability information").
  • UAC skip access control
  • the network 5 can configure whether to apply or skip UAC when the UE 100 receiving multicast in the RRC inactive state accesses the network 5 to update the PTM settings.
  • the network 5 gNB 200
  • the network 5 can configure the UE 100 to apply UAC when the network is congested, and to skip UAC when the network is not congested.
  • UE100 receives the setting information from network 5 (gNB200).
  • the setting information is information for setting whether UE100 is permitted to skip access control (UAC) when accessing network 5 for the sole purpose of updating multicast settings (PTM settings). This allows gNB200 to notify and set UE100 as to whether UAC may be skipped when only updating PTM settings.
  • UAC skip access control
  • PTM settings multicast settings
  • FIG. 9 shows an example of the operation of the mobile communication system 1 according to this operation pattern.
  • step S101 UE 100 in an RRC connected state joins a specific multicast session (here, multicast session #1).
  • step S102 gNB200 transmits dedicated signaling including the PTM settings required for receiving multicast session #1 to UE100 in the RRC connected state.
  • the dedicated signaling may be an RRC Reconfiguration message.
  • the dedicated signaling may include UAC skip enable/disable information described below.
  • UE100 stores the received PTM settings.
  • step S103 gNB200 transmits an RRC Release message (specifically, an RRC Release message including Suspend Config.) to UE100 in the RRC connected state to transition UE100 to the RRC inactive state.
  • Step S103 may be performed simultaneously with step S102.
  • the RRC Release message may include the above-mentioned PTM setting and/or UAC skip enable/disable information.
  • step S104 UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S103.
  • step S105 UE100 receives (or waits for) multicast data of multicast session #1 in the RRC inactive state.
  • gNB200 may transmit UAC skip capability information to UE100 indicating whether UAC can be skipped in the case of only PTM setting update.
  • UE100 receives the UAC skip capability information.
  • the UAC skip capability information is transmitted in either a system information block (SIB), a paging message, or an MCCH.
  • the UAC skip permission information may be, for example, "UAC skip permission", "UAC skip not permitted", or "whether UAC may be skipped".
  • the UAC skip permission information may be notified for each multicast session (for example, for each TMGI). For example, a set of the UAC skip permission information and the corresponding TMGI (or MRB ID) may be transmitted and received.
  • the gNB 200 may notify the UE 100 that UAC skip is not possible using the UAC skip possibility information.
  • the gNB 200 may notify the UE 100 that UAC skip is permitted using the UAC skip possibility information.
  • gNB200 transmits a notification of the PTM setting update to UE100.
  • UE100 receives the notification.
  • the notification may be a paging message including the TMGI of the multicast session in which the PTM setting is updated.
  • gNB200 notifies the PTM setting update for multicast session #1.
  • UE100 decides to access gNB200 (RRC resume processing) to update the PTM setting.
  • step S108 when UE100 performs RRC resume only for the purpose of updating the PTM settings, it determines whether to apply or skip UAC based on the UAC skip permission information.
  • UE100 determines to skip UAC, it may consider that access due to PTM setting update is prioritized over UAC.
  • UE100 also detects other triggers for RRC resume (e.g., occurrence of uplink data), it may determine to apply UAC regardless of the UAC skip permission information.
  • it determines to skip UAC (step S108: YES)
  • step S109 UE100 applies the above-mentioned UAC and determines whether access to gNB200 is permitted or prohibited (restricted). If it is determined that access to gNB200 is prohibited, UE100 refrains from accessing gNB200.
  • the explanation will proceed assuming that access to gNB200 is permitted.
  • step S110 UE100 accesses gNB200 and transmits an RRC Resume Request message to gNB200.
  • the RRC Resume Request message may include information indicating a PTM setting update.
  • step S111 gNB200 transmits the updated new PTM settings for multicast session #1 to UE100.
  • UE100 receives and stores the new PTM settings.
  • UE100 may determine whether to apply or skip UAC based on the UAC skip availability information (step S108). That is, when UE100 expects to receive an RRC Release message including new PTM settings after transmitting an RRC Resume Request, that is, when UE100 expects to be able to acquire new PTM settings without transitioning to the RRC connected state, UE100 may perform the determination of step S108. For example, in the case of a multicast session in which only reception is performed in UE100 (for example, a multicast session such as a television broadcast), UE100 may expect to receive an RRC Release. On the other hand, in the case of a multicast session involving UL transmission, such as a group call, UE100 may expect to receive the multicast session in the RRC connected state.
  • MBS multicast is receivable in the RRC inactive state
  • UE100 if UE100 camps on a cell that cannot receive MBS multicast, UE100 cannot receive the multicast.
  • MBS multicast is different in that it is premised on full control of gNB200, and that UE100's MBS interest does not change in RRC inactive state (specifically, if interest changes, UE100 must transition to RRC connected state and leave or join the session in NAS). Therefore, it may be possible to control the frequency from gNB200 using the UE context held in gNB200 in RRC connected state. Therefore, in the case of MBS multicast, a frequency priority handling process (priority handling) different from that of MBS broadcast may be required.
  • UE100 regards the frequency of the serving cell when it receives the PTM setting (or receives an RRC Release) as the highest priority for cell reselection. That is, UE100 performs multicast reception in the RRC inactive state based on the multicast setting (PTM setting) received from network 5. In the RRC inactive state, UE100 regards the frequency to which the cell that transmitted the PTM setting belongs as the highest priority for cell reselection.
  • the frequency of the cell that transmitted the PTM setting to UE100 is a frequency that supports multicast.
  • gNB200 does not need to explicitly specify that frequency to UE100, and an increase in signaling load can be suppressed. Therefore, if no frequency is specified by gNB200, UE100 can autonomously wait for a frequency that can receive multicast as the highest priority.
  • FIG. 10 shows a first example of operation of the mobile communication system 1 according to this operation pattern.
  • step S201 UE 100 in an RRC connected state joins a multicast session (here, multicast session #1).
  • step S202 gNB200 transmits dedicated signaling including the PTM settings required for receiving multicast session #1 to UE100 in the RRC connected state.
  • the dedicated signaling may be an RRC Reconfiguration message.
  • UE100 stores the received PTM settings.
  • step S203 UE100 stores the frequency to which the cell that transmitted the PTM setting in step S202 belongs.
  • step S204 gNB200 transmits an RRC Release message (specifically, an RRC Release message including Suspend Config.) to UE100 in the RRC connected state to transition UE100 to the RRC inactive state.
  • Step S204 may be performed simultaneously with step S202.
  • the RRC Release message may include the above-mentioned PTM setting.
  • UE 100 may confirm that the RRC Release does not include frequency priority information (such as dedicated priority). UE 100 may recognize that it will receive (or wait for) multicast session #1 in the RRC inactive state.
  • frequency priority information such as dedicated priority
  • step S206 UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S204.
  • step S207 UE100 regards the frequency stored in step S203, i.e., the frequency to which the serving cell belongs when the PTM setting (or RRC Release) is received, as the highest priority. This makes it easier for UE100 to maintain a state in which it is camped on the cell that supports multicast session #1.
  • step S208 UE100 receives (or waits for) multicast data from multicast session #1 in the RRC inactive state.
  • gNB200 does not explicitly specify to UE100 the frequency to be prioritized in cell reselection.
  • UE100 does not autonomously determine the frequency to be regarded as the highest priority. Therefore, in this operation pattern, when a frequency is specified by dedicated signaling (dedicated priority and/or de-prioritization request, etc.), UE100 does not apply the process of regarding the frequency identified by the UE itself as the highest priority.
  • UE 100 receives dedicated signaling including designation information (also referred to as "frequency designation information") that designates a frequency from network 5, and performs multicast reception in the RRC inactive state.
  • designation information also referred to as "frequency designation information”
  • UE 100 determines the frequency priority for cell reselection based on the designation information, without applying a process that considers the frequency determined by UE 100 to be the highest priority for cell reselection.
  • the operation of determining the frequency priority for cell reselection based on the designation information is a frequency prioritization process similar to that of the conventional method.
  • FIG. 11 is a diagram showing a second operation example of the mobile communication system 1 according to this operation pattern. Explanations of operations that overlap with those described above will be omitted.
  • step S301 UE100 joins the multicast session.
  • step S302 gNB200 transmits PTM settings to UE100 in the RRC connected state.
  • UE100 receives the PTM settings in the RRC connected state.
  • step S303 gNB200 transmits an RRC Release message to UE100 in the RRC connected state to transition UE100 to the RRC inactive state.
  • UE100 receives the RRC Release message and transitions to the RRC inactive state.
  • Step S303 may be performed simultaneously with step S302.
  • the RRC Release message may include the PTM setting described above.
  • the RRC Release message in step S303 includes frequency designation information that designates a frequency.
  • the frequency designation information is at least one of the following information: Dedicated priority: an information element that specifies cell reselection priority; De-prioritization request: an information element that specifies the frequency or radio access technology (RAT) to be given the lowest priority; Redirected Carrier Info: An information element that specifies a frequency or RAT to camp on.
  • Dedicated priority an information element that specifies cell reselection priority
  • De-prioritization request an information element that specifies the frequency or radio access technology (RAT) to be given the lowest priority
  • Redirected Carrier Info An information element that specifies a frequency or RAT to camp on.
  • the frequency designation information may be a new information element for designating a multicast frequency.
  • the new information element may be, for example, "multicast reception frequency.”
  • the new information element may be for each TMGI (linked to the TMGI).
  • the RRC Release message in step S303 may further include an information element indicating whether the frequency designation information is mandatory or optional. If it is "mandatory”, proceed to the process below. On the other hand, if it is "optional”, processing may be performed that considers it to be the highest priority, as in existing specifications.
  • step S304 UE100 recognizes that a frequency (frequency priority) has been explicitly specified by gNB200.
  • step S305 UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S303.
  • UE100 does not perform a process of regarding a certain frequency (so-called MBS frequency) identified by UE100 as the highest priority, but applies the frequency priority specified by gNB200.
  • UE100 may also regard the frequency specified by gNB200 ("multicast reception frequency") as the highest priority.
  • UE100 may also regard the frequency specified by gNB200 (de-prioritization request) as the lowest priority. This makes it easier for UE100 to maintain a state of camping on a cell that supports multicast session #1.
  • step S307 UE100 receives (or waits for) multicast data from multicast session #1 in the RRC inactive state.
  • UE100 may consider the frequency of the cell currently transmitting multicast session #1 to be the highest priority.
  • the above "information indicating compulsory/optional" does not have to be limited to multicast reception in an RRC inactive state.
  • the information may be applied in an RRC idle state, or when there is no interest in multicast reception.
  • the UE 100 can perform unicast reception and MBS broadcast reception with the same hardware.
  • the gNB 200 needs to schedule unicast in consideration of the processing capacity of the UE 100.
  • the UE 100 can report information regarding the processing capacity related to the MBS broadcast reception to the gNB 200.
  • the information regarding the processing capacity includes at least information on the frequency, subcarrier interval, and bandwidth of the MBS broadcast.
  • the information regarding the processing capacity may be reported in an MBS interest information message.
  • the MBS interest information message may include information on the TMGI of interest, frequency, and priority of the unicast MBS broadcast.
  • notification from the UE 100 is not necessary.
  • the gNB 200 may notify the UE 100 of information regarding the necessity of information regarding the processing capacity.
  • the information on the necessity may be notified depending on whether the MBS broadcast is a session provided by the same PLMN (Public Land Mobile Network) or a session provided by another PLMN.
  • the UE 100 can identify whether the session is provided by the same PLMN by comparing the PLMN ID included in the TMGI of interest with the current serving PLMN.
  • the information on the necessity may be notified by the TMGI.
  • the gNB 200 may notify that the report is unnecessary for the TMGI that already has information on the processing capability notified from another UE 100.
  • each of the above-mentioned operation flows is not limited to being performed separately and independently, but can be performed by combining two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed.
  • the base station is an NR base station (gNB)
  • the base station may be an LTE base station (eNB) or a 6G base station.
  • the base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node.
  • the base station may be a DU of an IAB node.
  • the UE 100 may also be an MT (Mobile Termination) of an IAB node.
  • network node primarily refers to a base station, but may also refer to a core network device or part of a base station (CU, DU, or RU).
  • a program may be provided that causes a computer to execute each process performed by UE100 or gNB200.
  • the program may be recorded on a computer-readable medium.
  • the computer-readable medium on which the program is recorded may be a non-transient recording medium.
  • the non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.
  • circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).
  • the terms “based on” and “depending on/in response to” do not mean “based only on” or “only in response to” unless otherwise specified.
  • the term “based on” means both “based only on” and “based at least in part on”.
  • the term “in response to” means both “only in response to” and “at least in part on”.
  • the terms “include”, “comprise”, and variations thereof do not mean including only the recited items, but may include only the recited items or may include additional items in addition to the recited items.
  • the term “or” as used in this disclosure is not intended to mean an exclusive or.
  • RRC Radio Resource Control
  • (Appendix 2) receiving the configuration information from the network;
  • the communication method according to claim 1, wherein the setting information is information for setting whether or not to permit the user device to skip the access control when the access is made only for the purpose of updating.
  • a communication method performed by a user equipment in a mobile communication system providing a multicast/broadcast service comprising: performing multicast reception in a radio resource control (RRC) inactive state based on a multicast configuration received from a network; In the RRC inactive state, a frequency to which the cell that transmitted the multicast configuration belongs is considered to be the highest priority for cell reselection.
  • RRC radio resource control
  • RRC radio resource control
  • broadcast mode 1 for multicast sessions
  • broadcast mode 2 for broadcast sessions.
  • the configuration to receive MTCH is provided by RRC reconfiguration only for UEs connected in broadcast mode 1, but by MCCH for UEs in all RRC states of broadcast mode 2.
  • RAN2#119e has identified that these delivery modes are candidates for inactive multicast reception, namely option 1 and option 2. As a result, a "mix" of these options is also listed in the table.
  • Option 1 Dedicated signalling
  • Option 2 Solution based on SIB+MCCH A "Mix" of the options is not excluded.
  • PTM Configuration Delivery Option 1 The following general description is taken as a baseline for PTM Configuration Delivery Option 1.
  • (1-a) PTM configurations of one or more multicast sessions for at least one cell are provided to the UE via dedicated RRC signaling.
  • the RRC messages for this purpose include RRCReconfiguration and/or RRCRelease and/or RRCResume (details require further discussion).
  • PTM configuration i.e., configuration used for multicast reception in RRC inactive
  • MCCH-like channel ame or different as the one used for MBS broadcast
  • SIB dedicated signaling
  • the UE can receive such configuration when it is in RRC inactive. Whether it is allowed or necessary to receive it when the UE is in RRC connected needs further study.
  • option 1 is superior to option 2 in terms of signaling overhead, which directly impacts network congestion. In other words, from a motivation point of view, it does not make sense to allow additional signaling overhead due to SIB20 and MCCH transmissions when the network encounters congestion.
  • an inactive UE From the perspective of an inactive UE, it performs DRX for paging monitoring to reduce power consumption. If option 2 is selected for inactive multicast reception, the UE needs to perform additional DRX activity, i.e., MCCH monitoring, which will result in additional power consumption. Therefore, this is not consistent with the UE's power saving motivation.
  • MCCH monitoring activity incurs additional UE power consumption during RRC inactivity.
  • option 1 requires the UE to initiate an RRC Resume procedure when the MBS configuration is provided or updated.
  • RRC Resume procedure when the MBS configuration is provided or updated.
  • RAN2#119e agrees that "multicast service continuity after cell reselection in RRC inactive state (i.e. without resuming RRC connection) is supported (if the new cell configuration is available to the UE).” Therefore, there should be no major issues with regard to network congestion and UE power consumption.
  • option 1 is the easiest for delivering PTM settings.
  • Proposal 1 RAN2 should agree that PTM configuration will be provided by dedicated signaling, i.e. option 1.
  • Multicast Session Deactivation/Release RAN2#119bis-e has agreed that the UE will be informed when a multicast session is deactivated and Rel-17 mechanisms will be applied when the multicast session is released. If the UE is in RRC inactive and configured to receive a multicast session in RRC inactive, the UE can be notified when the multicast session is deactivated, in a manner that requires further study (e.g., via group paging, MCCH, or other methods). The Rel-17 mechanism (NAS-based indication) is applied to release the multicast session. Further study is required on the case where extension is required.
  • NAS-based indication NAS-based indication
  • the multicast session is considered to be inactivated or released, and the gNB may stop transmitting PTM/MTCH accordingly. In this case, there is no reason for the UE to continue monitoring the MTCH, but the UE needs to continue monitoring unless the PTM configuration is deleted. From the perspective of UE power saving, it is desirable to stop monitoring the MTCH as soon as possible.
  • the UE behavior upon multicast session deactivation That is, the UE must be able to stop monitoring the MTCH upon receiving a notification of multicast session deactivation, regardless of the notification method. Also, the UE must remain RRC inactive upon receiving such a notification.
  • Proposal 2 RAN2 should agree that the UE can stop monitoring the MTCH upon receiving the deactivation of the multicast session.
  • the SC-PTM Stop Indication MAC CE is introduced to inform the UE to stop monitoring the PDCCH of the G-RNTI, and the MAC CE is multiplexed onto the SC-MTCH associated with the G-RNTI.
  • This lightweight signaling may work under the restriction of one-to-one mapping between TMGI and G-RNTI.
  • NRM BS many-to-one mapping between TMGI and G-RNTI is allowed, so if MAC CE is introduced, it is necessary to indicate the deactivated TMGI. Since the MAC CE is transmitted together with the MTCH, it is expected to minimize the delay between the reception of the last multicast data and the stop of MTCH monitoring.
  • Group paging is used to page multiple UEs in a group simultaneously, using TMGI instead of UE-ID. Since the existing paging group list (i.e., list of TMGI) is applicable to legacy UEs, group paging needs to add a new TMGI list for deactivation notification to avoid impacting legacy UEs. Group paging is sent at paging opportunities, i.e., there is some delay between receiving the last multicast data and stopping MTCH monitoring, based on the I-DRX cycle.
  • the third option is to reuse the MCCH.
  • the MCCH needs to be updated, so an MCCH change notification needs to be sent to the UE in advance. This increases the delay between receiving the last multicast data and stopping MTCH monitoring.
  • the UE needs to wake up to acquire the MCCH, which causes one MCCH change boundary in addition to the MTCH occasions and I-DRX, resulting in higher power consumption compared to the other options mentioned above.
  • Proposal 3 RAN2 should agree to choose either a new MACCE or an extended group paging to notify multicast session invalidation.
  • the Rel-17 NAS-based notification agreed by RAN2 applies, which may be "Multicast session release requested by network or MBS session release".
  • This procedure assumes that the UE is paged by the gNB and transitions to RRC connected to communicate with the AMF.
  • This procedure assumes that the existing group paging (or conventional individual paging) can be reused.
  • the gNB can send a MAC CE to allow the UE to stop monitoring the MTCH, and then use legacy dedicated paging to distribute the timing of pages to the UE to avoid signaling storms due to simultaneous RRC state transitions.
  • Proposal 4 RAN2 should agree that no enhancements specific to multicast session release are required, i.e. UEs will transition to RRC Connected via existing (group) paging.
  • Sub-case 2 Selective Transition RAN2#119e has reached the following agreement for sub-case 2: It is the gNB that decides whether a UE can receive a multicast session inactively. Further consideration is required as to what information to provide the gNB to make such a decision (related to the discussion of SA2). A gNB is supported to transmit one multicast session to both connected and inactive UEs in the same cell, how the gNB configures this needs further study. It is assumed that the network can select which UEs receive in RRC Inactive and which UEs receive in RRC Connected, and can move UEs between states for multicast service reception.
  • the gNB can select which UE to release based on UE capabilities, UE assistance information, and/or CN assistance information (if specified), etc., in the same way as today, i.e., by RRCRelease with Suspend Config. Therefore, no enhancements regarding selective transition of UEs are expected for the RRCRelease message.
  • RAN2#119bis-e agreed to the following text: When a Rel-18 session becomes active, inactive UEs can be notified (details need to be further explored). As a baseline, group paging can be used to inform Rel-18 UEs of session activation (details such as UE behavior upon receiving such a group notification require further study). How to determine whether a UE can receive a multicast session in RRC inactive when the session is activated is described in the considerations, taking into account the following solutions (the description can be further updated as necessary, and multiple solutions may be required): 1.
  • the UE can receive the multicast session in RRC Inactive if the PTM configuration used in RRC Inactive for the session is available to the UE and the UE is already in the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), otherwise it returns to RRC Connected to receive the multicast session.
  • the UE is indicated by group paging whether it can receive the multicast session in RRC inactive (detailed signaling needs further study).
  • the UE is configured by dedicated signaling whether it can receive the multicast session in RRC inactive before the UE is released. When the multicast session becomes active, the UE stays in RRC inactive or resumes the RRC connection accordingly (detailed signaling needs further study).
  • Proposal 5 RAN2 should ensure that group paging can be used to notify Rel-18 UEs of session activation.
  • RAN2 After review, RAN2 has identified three options for the UE's behavior upon receiving a multicast activation notification, as mentioned above.
  • option 1 the UE can receive a multicast session in inactive mode if it has a valid PTM configuration. Since an inactive UE cannot receive a multicast session without a PTM configuration, this can be considered as the baseline for all other UE behavior. Therefore, option 1 should be agreed upon.
  • Proposal 6 RAN2 shall consider the following UE behavior: Option 1: When a multicast session is activated, the UE can receive the multicast session in RRC inactive if the PTM configuration used in RRC inactive for the session is available to the UE and the UE is already part of the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH).
  • Option 1 When a multicast session is activated, the UE can receive the multicast session in RRC inactive if the PTM configuration used in RRC inactive for the session is available to the UE and the UE is already part of the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH).
  • the UE indicates in advance, by RRC reconfiguration or RRC Release, whether it should receive the multicast session inactively.
  • option 2 In the case of network congestion, it is expected that the cell load will change from moment to moment.
  • option 2 a notification is sent within the group paging, so the gNB can take the latest load situation into account when deciding whether to keep the UE inactive.
  • option 3 the gNB predicts future load when notifying the UE, so the cell load may change when the gNB actually sends the group paging. Therefore, there is a risk that an increase in UEs will transition to connected even if congestion worsens, or that an increase in UEs will remain inactive even if congestion is resolved. Therefore, option 2 is desirable for efficiently controlling the RRC state of the UE.
  • the UE power saving case assumes the introduction of some kind of "power saving preference" in the UE Assistance Information. Such a preference notification can only be sent from a connected UE.
  • the gNB can then indicate to the UE whether the UE was allowed to receive a multicast session in inactive state when it was last connected. If such a preference notification is not introduced, the gNB does not know whether the UE prefers power saving or not, and so the gNB can send this notification at any time. In other words, there is no difference between option 2 and option 3.
  • option 2 is considered to be more efficient and can cover the usage of option 3. Therefore, RAN2 should at least agree to option 2.
  • Proposal 7 RAN2 should agree to UE behavior option 2: "When a multicast session becomes active, the UE is indicated by group paging whether it can receive the multicast session in RRC inactive (detailed signaling is to be further explored)."
  • the current specification specifies the UE behavior upon receiving a group paging, i.e., all UEs initiate an RRC Resume procedure if the paging message contains a TMGI of interest, so if selective paging is required in option 2, the gNB cannot include the TMGI in the paging message. If the gNB only includes a UE-ID for selective paging (i.e., legacy individual paging without TMGI to page selected Rel-18 UEs), it cannot page Rel-17 UEs that are inactive and waiting for multicast activation. Furthermore, it is inefficient in terms of signaling overhead.
  • the current paging group list is set in the group paging message to page at least Rel-17 UEs
  • Rel-18 UEs will also be paged due to their interested TMGI. Therefore, to prevent selected UEs from transitioning to connected, it is conceivable to define a new list of UE-IDs, the "pagingcancelllist" (or “inactiveallowedlist”), that will remain inactive so that UEs listed in this list can receive the multicast session.
  • RAN2 should discuss how to enhance group paging to page a subset of UEs.
  • Proposal 8 RAN2 should discuss how to enhance group paging to page a subset of UEs, for example using a new UE-ID list that remains inactive for multicast session reception.
  • Sub-case 3 QoS Enforcement RAN2 #119e has reached the following agreements related to sub-case 3: In RRC inactive multicast reception, HARQ feedback and PTP are not supported.
  • inactive multicast reception is the same as MBS broadcast reception (so-called distribution mode 2) defined in Rel-17.
  • MBS broadcasting is based on a best-effort basis.
  • RAN2Q1-a When there is a large difference in quality and reliability of MBS data reception between UEs in RRC connected state and UEs in RRC inactive state: The quality and reliability of MBS data reception between a UE in RRC connected state and a UE in RRC inactive state may differ since HARQ feedback and PTP transmission are not supported and seamless/lossless mobility is not required for multicast reception in RRC inactive.
  • the quality and reliability of MBS data reception between a UE in RRC connected state and a UE in RRC inactive state may differ since HARQ feedback and PTP transmission are not supported and seamless/lossless mobility is not required for multicast reception in RRC inactive.
  • Multicast sessions should ensure certain QoS requirements even when the UE is inactive.
  • the RSRP threshold since NRMBS is assumed to be a single-cell transmission method, it is considered necessary for the UE to always transition to connected whenever it moves to the cell edge or performs cell reselection. This may not be optimal behavior depending on the deployment in terms of network congestion and UE power saving.
  • Proposal 9 RAN2 should agree that an inactive UE should transition to connected if the reception quality becomes worse than a threshold (e.g., RSRP or BLER).
  • a threshold e.g., RSRP or BLER
  • Sub-case 4 Mobility and Service Continuity RAN2 #119e has agreed to the following description for sub-case 4: Continuation of multicast services after cell reselection in RRC inactive state (i.e. without resuming RRC connection) is supported (if new cell configuration is available to the UE). Further study is required as to whether there are cases where the UE needs to resume connection. Further study is also required for the impact of inter-GNB mobility on RAN3. If a cell reselection to a neighbouring cell occurs during an active multicast session, the UE needs to resume the RRC connection to obtain the multicast MRB configuration if the session configuration is not available for the inactive UE in the new cell.
  • PTM Configuration Delivery Option 1 (1-a) PTM configurations (i.e., configurations used for multicast reception in RRC inactivity) of one or more multicast sessions of at least one cell are provided to the UE via dedicated RRC signaling. (1-b) The RRC messages for this purpose include RRC Reconfiguration and/or RRC Release and/or RRC Resume (details need to be further discussed). (1-c) The UE stores the received configuration while in RRC inactivity, and if some or all of the configuration needs to be updated, the UE is notified of such changes and can trigger a Resume of RRC connection to obtain the updated configuration. If mobility occurs during RRC inactivity, the UE triggers a Resume of RRC connection if the session configuration is not available in the new cell.
  • PTM configurations i.e., configurations used for multicast reception in RRC inactivity
  • the RRC messages for this purpose include RRC Reconfiguration and/or RRC Release and/or RRC Resume (details need to be further discussed).
  • the PTM configuration is provided by the RRC Reconfiguration message, so the UE must always be connected to receive the PTM configuration.
  • the UE sends an RRC Resume Request message and the gNB responds with an RRC Release that includes the PTM configuration. Therefore, the UE does not need to transition to connected to be provided with the updated PTM configuration.
  • Such a procedure can be used during cell reselection (i.e., a UE-initiated procedure when the PTM configuration is not available in the new cell) and RAN paging (i.e., a network-initiated procedure when the PTM configuration needs to be updated).
  • Proposal 10 RAN2 should agree that RRC release be enhanced to provide PTM configuration.
  • PTM setting application area i.e., whether to introduce a mechanism whereby the PTM settings acquired by a UE are applied to a specific area (i.e., a set of cells rather than a single cell).
  • the PTM configuration for delivery mode 1 is only valid in the cell where the UE is configured.
  • the target cell reconfigures the UE to the new PTM configuration.
  • an inactive UE performs idle mobility, it can be considered as the starting point when the existing PTM configuration is no longer valid in the reselected cell (i.e. the new cell).
  • the simplest solution with minimal impact on the specifications would be to require that an inactive UE always transition to Connected (e.g., before or after performing cell reselection) so that the UE can be handed over from the serving cell to the target cell or reconfigured by the reselected cell.
  • the PTM configuration is valid in the RNA, so the gNB should ensure that the same configuration is applied in the RNA of each UE.
  • the advantage of this approach is that inactive UEs do not need to be reconfigured and can continue to receive MTCH in the RNA. On the other hand, this adds more complexity to the network, as the RNA is UE specific.
  • the gNB can provide a cell list in the configuration, with the configuration being considered valid in the cells included in the list.
  • the cell list can be configured to be cell-specific, DU/CU-related, UE cell list-related, MRB area-specific, or MBS service area-specific, depending on the NW implementation.
  • RAN2 should discuss whether to introduce area scoping for such settings.
  • Proposal 11 RAN2 should discuss whether the configuration for receiving MTCH is valid for the serving cell or for the area (RNA, cell list, etc.).
  • Appendix 3 The work item on enhanced MBS (eMBS) includes the objective of supporting UE shared processing for MBS broadcast and unicast as follows: - Specify Uu signaling extensions to enable UE to use shared processing for MBS broadcast and unicast reception, including reporting UE capabilities and related assistance information for simultaneous unicast reception in RRC Connected and MBS broadcast reception from the same or different operators.
  • eMBS enhanced MBS
  • the gNB can allocate unicast resources to the UE under the condition that the UE's processing capability does not exceed its capacity. Since the processing capability is assumed to be common for intra- and inter-PLMNs, whether the extended MBS Interest Indication (MII) should be reported depends on whether the serving cell has knowledge about the MBS broadcast configurations provided in different frequencies and/or different PLMNs. In this sense, a new IE in SIB1 needs to indicate whether the UE should report the extended MII only in the inter-PLMN case or also in the intra-PLMN case. The UE checks (from TMGI) whether there is a difference between the serving PLMN and the MBS PLMN and follows the indication in SIB1. Therefore, RAN2 should discuss whether a single bit of notification is sufficient (i.e., for the case of the extended MII ON/OFF) or whether multiple bits of notification are required (i.e., for the inter- and/or intra-PLMN cases).
  • MII extended MBS Interest Indication
  • Proposal 1 RAN2 should discuss whether a new IE in SIB1 should control whether UE reports Extended MBS Interest Indication for shared processing only in inter-PLMN case or also in intra-PLMN case.
  • UE capability signaling is not required, and the extended MII is considered as implicit capability signaling. Therefore, RAN2 should agree on the principles of UE capability signaling.
  • Proposal 2 RAN2 should agree that UE capability signaling is not required for shared processing.
  • the UE can use the same receiver for MBS broadcast and unicast.
  • MBS services may be provided by different operators and therefore on different frequencies. If one receiver is used for different frequencies, the UE needs to tune its RF chain to these frequencies in TDD mode. Therefore, shared operation requires an additional gap for MBS broadcast reception. During this gap, the gNB avoids scheduling DL transmissions for unicast, so that the UE can receive the MBS broadcast of interest on another frequency/operator. This is similar to either a measurement gap for inter-frequency measurements or a MUSIM gap for inter-PLMN operation.
  • the UE can tune its RF chain to a frequency different from the MBS frequency while the gNB is not scheduling unicast transmission or reception.
  • the question is whether existing MUSIM gaps can be reused for MBS reception.
  • it is possible to extend the MUSIM gap for MBS reception.
  • the MUSIM gap is limited to MUSIM purposes as follows. It is clear that the current MUSIM gap is not intended to be used for MBS reception.
  • the network can provide one or more per-UE MUSIM gap patterns for simultaneous monitoring of all frequency layers for MUSIM via MUSIM-GapConfig.
  • the MUSIM gap was introduced in Rel-17 separately from the existing measurement gaps. Therefore, it is desirable to introduce an additional gap specific to inter-frequency/inter-PLMN MBS reception that is different from the MUSIM gap.
  • Proposal 3 RAN2 should agree to introduce an additional gap, specifically for inter-PLMN reception of MBS broadcasts in RRC Connected, i.e., an "MBS gap".
  • the gNB needs to configure the UE with MBS gaps, but the gNB does not know what gap pattern the UE needs. Therefore, the UE needs to send assistance information to inform the gNB of the required gap details, which is intended for the purpose of this WI. Since the current network (i.e., the selected PLMN) does not know the details of the MBS broadcast configuration of different operators, such as MTCH scheduling information, this assistance information is considered useful, especially when the MBS broadcast of interest is provided by different operators. This is similar to the MUSIM assistance introduced in the UAI.
  • Proposal 4 RAN2 should agree to introduce additional assistance information from the UE in MBS gap configuration, especially when the MBS broadcast of interest is provided by another PLMN.
  • Proposal 4 can be agreed, it is worth considering what kind of assistance information will be required.
  • the UE can inform the gNB of the MII, which includes the TMGI, frequency, and priority of MBS broadcast and unicast.
  • RAN2 has agreed to an extended MII, which includes additional information such as subcarrier spacing and bandwidth. If the same operator provides the MBS broadcasts of interest, the MII could work well if the gNB knows the MTCH scheduling information for a particular TMGI provided on a different frequency.
  • the UE Since the gNB of the selected network does not know the MBS broadcast settings of different networks, the UE needs to provide a gap pattern to the gNB if different operators provide the desired MBS broadcast.
  • the gap pattern should be based on the MTCH scheduling information of different operators, but the reference should be based on the selected network.
  • the RF tuning time can also be included, and it is up to the UE implementation how to set the gap pattern.
  • Proposal 5 In particular, for inter-PLMN MBS reception, RAN2 needs to agree on the UE requesting a gap pattern from the gNB, so that the gap pattern can cover the RF tuning times and MTCH scheduling periods of different PLMNs.
  • One simple way to allow a UE to use one of its receivers for MBS reception is for the gNB to deconfigure or inactivate one of the SCells currently active in the UE.
  • the gNB may not know if/when the UE prefers to deconfigure/inactivate the SCell, it is worth discussing whether additional assistance information for deconfiguring/inactivating the SCell for MBS reception, in addition to the MBS gaps mentioned above, would be useful. If recognized as useful, it should be discussed whether the current MII contents, i.e., frequency and priority, work for this purpose.
  • Proposal 6 RAN2 should further discuss whether the UE is allowed to inform the gNB of the priority regarding reconfiguration or deactivation of the SCell for MBS reception from different PLMNs.
  • Mobile communication system 10 RAN 20: C.N. 100: UE (user equipment) 110: Receiving unit 120: Transmitting unit 130: Control unit 200: gNB (base station) 210: Transmitter 220: Receiver 230: Controller 240: Backhaul Communication Unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、デディケイテッドシグナリングによりネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、前記マルチキャスト設定の更新が必要であると判定したことに応じて、前記更新のために前記ネットワークへのアクセスを行うことを決定するステップと、前記アクセスを規制するためのアクセス制御を適用するか又はスキップするかを、前記ネットワークからの設定情報に基づいて判定するステップと、を有する。

Description

通信方法
　本開示は、移動通信システムで用いる通信方法に関する。
　３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）において、第５世代（５Ｇ）の無線アクセス技術であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）の技術仕様が規定されている。ＮＲは、第４世代（４Ｇ）の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。３ＧＰＰにおいて、５Ｇ／ＮＲのマルチキャスト／ブロードキャストサービス（ＭＢＳ）の技術仕様が規定されている（例えば、非特許文献１参照）。
３ＧＰＰ技術仕様書：ＴＳ　３８．３００　Ｖ１７．２．０
　第１の態様に係る通信方法は、マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、デディケイテッドシグナリングによりネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、前記マルチキャスト設定の更新が必要であると判定したことに応じて、前記更新のために前記ネットワークへのアクセスを行うことを決定するステップと、前記アクセスを規制するためのアクセス制御を適用するか又はスキップするかを、前記ネットワークからの設定情報に基づいて判定するステップと、を有する。
　第２の態様に係る通信方法は、マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、ネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、前記ＲＲＣインアクティブ状態において、前記マルチキャスト設定を送信したセルが属する周波数をセル再選択の最高優先度とみなすステップと、を有する。
　第３の態様に係る通信方法は、マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、周波数を指定する指定情報を含むデディケイテッドシグナリングをネットワークから受信するステップと、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、前記ＲＲＣインアクティブ状態において、前記ユーザ装置が決定した周波数をセル再選択の最高優先度とみなす処理を適用せずに、前記指定情報に基づいて前記セル再選択の周波数優先度を決定するステップと、を有する。
実施形態に係る移動通信システムの構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うことを可能とする動作の概要を示す図である。 一般的なセル再選択プロシージャについて説明するための図である。 一般的なセル再選択プロシージャの概略フローを示す図である。 第１動作パターンに係る移動通信システムの動作例を示す図である。 第２動作パターンに係る移動通信システムの第１動作例を示す図である。 第２動作パターンに係る移動通信システムの第２動作例を示す図である。 ＭＢＳのギャップパターンの例を示す図である。
　図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（１）システム構成
　まず、実施形態に係る移動通信システム１の構成について説明する。図１は、実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ　Ｇｅｎｅｒａｔｉｏｎ　Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。移動通信システムには第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
　移動通信システム１は、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ　Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）２０とを有する。以下において、ＮＧ－ＲＡＮ１０を単にＲＡＮ１０と称することがある。また、５ＧＣ２０を単にコアネットワーク（ＣＮ）２０と称することがある。ＲＡＮ１０及びＣＮ２０は、移動通信システム１のネットワークを構成する。
　ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）及び／又はタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ　ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ　ＵＥ）である。
　ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と称される）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数（以下、単に「周波数」と称する）に属する。
　なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。
　５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。
　図２は、実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を有する。受信部１１０及び送信部１２０は、ｇＮＢ２００との無線通信を行う無線通信部を構成する。
　受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
　送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１３０は、ＵＥ１００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。上述及び後述のＵＥ１００の動作は、制御部２３０の制御による動作であってもよい。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　図３は、実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を有する。送信部２１０及び受信部２２０は、ＵＥ１００との無線通信を行う無線通信部を構成する。バックホール通信部２４０は、ＣＮ２０との通信を行うネットワーク通信部を構成する。
　送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
　制御部２３０は、ｇＮＢ２００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。上述及び後述のｇＮＢ２００の動作は、制御部２３０の制御による動作であってもよい。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　バックホール通信部２４０は、基地局間インターフェイスであるＸｎインターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ　Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がフロントホールインターフェイスであるＦ１インターフェイスで接続されてもよい。
　図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。なお、ＵＥ１００のＰＨＹレイヤは、ｇＮＢ２００から物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される下りリンク制御情報（ＤＣＩ）を受信する。具体的には、ＵＥ１００は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＰＤＣＣＨのブラインド復号を行い、復号に成功したＤＣＩを自ＵＥ宛てのＤＣＩとして取得する。ｇＮＢ２００から送信されるＤＣＩには、ＲＮＴＩによってスクランブルされたＣＲＣ（Ｃｙｃｌｉｃ　Ｒｅｄｕｎｄａｎｃｙ　Ｃｏｄｅ）パリティビットが付加されている。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化等を行う。
　ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。
　図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤを有する。
　ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間にコネクション（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態である。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間にコネクション（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態である。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間のコネクションがサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態である。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤ（単に「ＮＡＳ」とも称する）は、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＡのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。また、ＮＡＳレイヤよりも下位のレイヤをＡＳレイヤと称する（単に「ＡＳ」とも称する）。
　（２）ＭＢＳ
　移動通信システム１は、マルチキャスト／ブロードキャストサービス（ＭＢＳ）によりリソース効率の高い配信を行うことができる。
　マルチキャスト通信サービス（「ＭＢＳマルチキャスト」とも称する）の場合、同じサービスと同じ特定のコンテンツデータが特定のＵＥセットに同時に提供される。すなわち、マルチキャストサービスエリア内のすべてのＵＥ１００がデータの受信を許可されているわけではない。マルチキャスト通信サービスは、ＭＢＳセッションの一種であるマルチキャストセッションを用いてＵＥ１００に配信される。ＵＥ１００は、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及び／又はＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）配信等のメカニズムを用いて、ＲＲＣコネクティッド状態でマルチキャスト通信サービスを受信できる。ＵＥ１００は、ＲＲＣインアクティブ（又はＲＲＣアイドル）状態でマルチキャスト通信サービスを受信してもよい。このような配信モードは、「配信モード１」とも称される。
　ブロードキャスト通信サービス（「ＭＢＳブロードキャスト」とも称する）の場合、同じサービスと同じ特定のコンテンツデータが地理的エリア内のすべてのＵＥ１００に同時に提供される。すなわち、ブロードキャストサービスエリア内のすべてのＵＥ１００がデータの受信を許可される。ブロードキャスト通信サービスは、ＭＢＳセッションの一種であるブロードキャストセッションを用いてＵＥ１００に配信される。ＵＥ１００は、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態、及びＲＲＣコネクティッド状態のいずれの状態でも、ブロードキャスト通信サービスを受信できる。このような配信モードは、「配信モード２」とも称される。
　ＭＢＳ配信に用いられる主な論理チャネルは、マルチキャストトラフィックチャネル（ＭＴＣＨ）、デディケイテッドトラフィックチャネル（ＤＴＣＨ）、及びマルチキャスト制御チャネル（ＭＣＣＨ）である。ＭＴＣＨは、マルチキャストセッション又はブロードキャストセッションのいずれかのＭＢＳデータをネットワーク１０からＵＥ１００に送信するためのＰＴＭ下りリンクチャネルである。ＤＴＣＨは、ネットワーク１０からＵＥ１００にマルチキャストセッションのＭＢＳデータを送信するためのＰＴＰチャネルである。ＭＣＣＨは、１つ又は複数のＭＴＣＨに対応付けられたＭＢＳブロードキャスト制御情報をネットワーク１０からＵＥ１００に送信するためのＰＴＭ下りリンクチャネルである。
　ＭＢＳブロードキャストにおける設定に関し、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態、又はＲＲＣコネクティッド状態のＵＥ１００は、ＭＣＣＨを介して、ブロードキャストセッションのためのＰＴＭ設定（例えば、ＭＴＣＨ受信に必要なパラメータ）を受信する。ＭＣＣＨの受信に必要なパラメータ（ＭＣＣＨ設定）は、システム情報を介して提供される。具体的には、システム情報ブロック・タイプ２０（ＳＩＢ２０）は、ＭＣＣＨ設定を含む。なお、ＳＩＢタイプ２１（ＳＩＢ２１）は、ＭＢＳブロードキャスト受信のサービス継続性に関する情報を含む。ＭＣＣＨは、ＭＴＣＨで送信される進行中のセッションを含むすべてのブロードキャストサービスのリストを提供し、ブロードキャストセッションの関連情報には、ＭＢＳセッション識別子（例えば、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｇｒｏｕｐ　Ｉｄｅｎｔｉｔｙ））、関連するＭＴＣＨスケジューリング情報、及びＭＴＣＨで特定のサービスを提供する隣接セルに関する情報が含まれる。
　一方、ＭＢＳマルチキャストに関し、現在の３ＧＰＰの技術仕様では、ＵＥ１００は、ＲＲＣコネクティッド状態でのみマルチキャストセッションのデータを受信できる。マルチキャストセッションに参加したＵＥ１００がＲＲＣコネクティッド状態にあり、マルチキャストセッションがアクティブ化されている場合、ｇＮＢ２００は、当該マルチキャストセッションに関するＰＴＭ設定を含むＲＲＣ再設定（Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージをＵＥ１００に送信する。このようなＰＴＭ設定は、マルチキャスト無線ベアラ（ＭＲＢ）設定、ＭＴＣＨ設定、又はマルチキャスト設定とも称される。ＭＲＢ設定（ＭＲＢ－ＴｏＡｄｄＭｏｄ）は、ＵＥ１００に設定するＭＲＢ（マルチキャストＭＲＢ）について、ＭＢＳセッション識別子（ｍｂｓ－ＳｅｓｓｉｏｎＩｄ）と、ＭＲＢ識別子（ｍｒｂ－Ｉｄｅｎｔｉｔｙ）と、ＰＤＣＰ設定（ｐｄｃｐ－Ｃｏｎｆｉｇ）等の他のパラメータとを含む。
　以下の実施形態では、ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うことを可能とする動作について主として説明する。図６は、当該動作の概要を示す図である。
　ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うためのソリューションとして、図６（ａ）に示す配信モード１ベースのソリューションと、図６（ｂ）に示す配信モード２ベースのソリューションとが考えられる。
　図６（ａ）に示す配信モード１ベースのソリューションでは、ステップＳ１において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、マルチキャストセッションに関するＭＢＳ設定（マルチキャスト設定）を含むＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信する。ＵＥ１００は、当該ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージで受信したマルチキャスト設定に基づいて、マルチキャストセッション（マルチキャストＭＲＢ）を介してマルチキャストデータをＭＴＣＨ上で受信する。
　ステップＳ２において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、ＵＥ１００をＲＲＣインアクティブ状態へ遷移させるためのＲＲＣ解放（Ｒｅｌｅａｓｅ）メッセージを送信する。当該ＲＲＣ　Ｒｅｌｅａｓｅメッセージは、ＲＲＣインアクティブ状態のための設定（Ｓｕｓｐｅｎｄ　Ｃｏｎｆｉｇ．）を含む。
　ステップＳ３において、ＵＥ１００は、ステップＳ２のＲＲＣ　Ｒｅｌｅａｓｅメッセージの受信に応じて、ＲＲＣコネクティッド状態からＲＲＣインアクティブ（ＩＮＡＣＴＩＶＥ）状態に遷移する。
　ステップＳ４において、ＲＲＣインアクティブ状態のＵＥ１００は、ステップＳ１のマルチキャスト設定を継続して用いて、マルチキャストセッションを介してマルチキャストデータをＭＴＣＨ上で受信する。
　これにより、ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うことが可能である。なお、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いてマルチキャスト設定を行う一例を説明したが、ＲＲＣ　Ｒｅｌｅａｓｅメッセージを用いてマルチキャスト設定を行ってもよい。
　ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ及びＲＲＣ　Ｒｅｌｅａｓｅメッセージはいずれもデディケイテッド制御チャネル（ＤＣＣＨ）上でＵＥ個別に伝送されるＲＲＣメッセージであり、以下においてデディケイテッドＲＲＣメッセージとも称する。
　一方、図６（ｂ）に示す配信モード２ベースのソリューションでは、ステップＳ１１において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、ＵＥ１００をＲＲＣインアクティブ状態へ遷移させるためのＲＲＣ　Ｒｅｌｅａｓｅメッセージを送信する。当該ＲＲＣ　Ｒｅｌｅａｓｅメッセージは、ＲＲＣインアクティブ状態のための設定（Ｓｕｓｐｅｎｄ　Ｃｏｎｆｉｇ．）を含む。
　ステップＳ１２において、ＵＥ１００は、ステップＳ１１のＲＲＣ　Ｒｅｌｅａｓｅメッセージの受信に応じて、ＲＲＣインアクティブ（ＩＮＡＣＴＩＶＥ）状態に遷移する。
　ステップＳ１３において、ｇＮＢ２００は、マルチキャストセッションに関するＭＢＳ設定（マルチキャスト設定）を含むＭＣＣＨを送信する。ＵＥ１００は、当該ＭＣＣＨを受信する。なお、ＵＥ１００は、ＭＣＣＨの受信に先立ってＳＩＢ２０を受信し、ＳＩＢ２０に基づいてＭＣＣＨを受信する。なお、ＭＣＣＨ送信（及び受信）はステップＳ１１よりも前に行われてもよく、ステップＳ１１と同時に行われてもよい。
　ステップＳ１４において、ＲＲＣインアクティブ状態のＵＥ１００は、ステップＳ１３のＭＣＣＨで受信したマルチキャスト設定に基づいて、マルチキャストセッションを介してマルチキャストデータをＭＴＣＨ上で受信する。これにより、ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うことが可能である。
　（３）セル再選択
　図７は、一般的なセル再選択プロシージャについて説明するための図である。ＲＲＣアイドル状態又はＲＲＣインアクティブ状態にあるＵＥ１００は、移動に伴って、現在のサービングセル（セル＃１）から隣接セル（セル＃２乃至セル＃４のいずれか）に移行するためにセル再選択プロシージャを行う。具体的には、ＵＥ１００は、自身がキャンプオンすべき隣接セルをセル再選択プロシージャにより特定し、特定した隣接セルを再選択する。現在のサービングセルと隣接セルとで周波数（キャリア周波数）が同じである場合をイントラ周波数と呼び、現在のサービングセルと隣接セルとで周波数（キャリア周波数）が異なる場合をインター周波数と呼ぶ。現在のサービングセル及び隣接セルは、同じｇＮＢ２００により管理されていてもよい。当該現在のサービングセル及び当該隣接セルは、互いに異なるｇＮＢ２００により管理されていてもよい。
　図８は、一般的なセル再選択プロシージャの概略フローを示す図である。
　ステップＳ１０において、ＵＥ１００は、例えばシステム情報ブロック（ＳＩＢ）又はＲＲＣ解放メッセージによりｇＮＢ２００から指定される周波数ごとの優先度（「絶対優先度」又は「セル再選択優先度」又は「ｄｅｄｉｃａｔｅｄ　ｐｒｉｏｒｉｔｙ」とも称される）に基づいて周波数優先度付け処理を行う。具体的には、ＵＥ１００は、ｇＮＢ２００から指定された周波数優先度を周波数ごとに管理する。
　ステップＳ２０において、ＵＥ１００は、サービングセル及び隣接セルのそれぞれについて無線品質を測定する測定処理を行う。ＵＥ１００は、サービングセル及び隣接セルのそれぞれが送信する参照信号、具体的には、ＣＤ－ＳＳＢ（Ｃｅｌｌ　Ｄｅｆｉｎｉｎｇ－Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ　Ｓｉｇｎａｌ　ａｎｄ　ＰＢＣＨ　ｂｌｏｃｋ）の受信電力及び受信品質を測定する。例えば、ＵＥ１００は、現在のサービングセルの周波数の優先度よりも高い優先度を有する周波数については常に無線品質を測定し、現在のサービングセルの周波数の優先度と等しい優先度又は低い優先度を有する周波数については、現在のサービングセルの無線品質が所定品質を下回った場合に、等しい優先度又は低い優先度を有する周波数の無線品質を測定する。
　ステップＳ３０において、ＵＥ１００は、ステップＳ２０での測定結果に基づいて、自身がキャンプオンするセルを再選択するセル再選択処理を行う。例えば、ＵＥ１００は、隣接セルの周波数の優先度が現在のサービングセルの優先度よりも高い場合であって、当該隣接セルが所定期間に亘って所定品質基準（すなわち、必要最低限の品質基準）を満たす場合、当該隣接セルへのセル再選択を行ってもよい。ＵＥ１００は、隣接セルの周波数の優先度が現在のサービングセルの優先度と同じである場合、隣接セルの無線品質のランク付けを行い、所定期間に亘って現在のサービングセルのランクよりも高いランクを有する隣接セルへのセル再選択を行ってもよい。ＵＥ１００は、隣接セルの周波数の優先度が現在のサービングセルの優先度よりも低い場合であって、現在のサービングセルの無線品質がある閾値よりも低く、且つ、隣接セルの無線品質が別の閾値よりも高い状態を所定期間にわたって継続した場合、当該隣接セルへのセル再選択を行ってもよい。
　ＭＢＳをサポートするＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００は、上述のようなセル再選択に、次の変更を加えて適用する。具体的には、ＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）を介してＭＢＳブロードキャストサービスを受信している又は受信することに興味があるＵＥ１００は、これらのＭＢＳブロードキャストサービスを提供する周波数にキャンプすることによってのみこれらのＭＢＳブロードキャストサービスを受信することができるとき、この周波数を最高優先度（他のネットワーク設定の優先度よりも高い）にすることが許可される。
　一方、ＵＥ１００が興味のあるＭＢＳブロードキャストサービスが（セッションの終了後に）利用できなくなった場合、又はＵＥ１００が当該ブロードキャストサービスの受信に興味がなくなった場合、ＵＥ１００は当該周波数を優先しなくなる。また、ＰＴＭを介してＭＢＳブロードキャストサービスを受信している又は受信することに興味があるＵＥ１００は、これらのＭＢＳブロードキャストサービスを受信できない周波数を最低優先度（他のネットワーク設定の優先度よりも低い）にすることが許可される。
　（４）アクセス制御
　実施形態に係る移動通信システム１は、ＵＡＣ（Ｕｎｉｆｉｅｄ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）と称されるアクセス制御をサポートする。このようなアクセス制御により、例えばネットワーク５が輻輳する事態を回避し得る。ＵＡＣの詳細については、３ＧＰＰ技術仕様書：ＴＳ３８．３３１の５．３．１４章に規定されているが、ここではＵＡＣの概要について説明する。
　ＵＡＣでは、すべてのＲＲＣ状態（ＲＲＣアイドル状態、ＲＲＣインアクティブ状態、及びＲＲＣコネクティッド状態）のＵＥ１００についてアクセス規制を行うことができる。ＵＥ１００における各通信要求は、１つのアクセスカテゴリ（Ａｃｃｅｓｓ　Ｃａｔｅｇｏｒｙ）及び１つ以上のアクセス識別子（Ａｃｃｅｓｓ　Ｉｄｅｎｔｉｔｙ）に対応付けられる。ｇＮＢ２００は、この組み合わせごとに規制が可能である。アクセスカテゴリは、サービス種別の識別子である。アクセス識別子は、呼種別の識別子である。ｇＮＢ２００は、アクセスカテゴリごとに規制対象のアクセス識別子及びパラメータ値をＵＥ１００に通知する。ＵＥ１００は、通信要求が発生するたびに、アクセスカテゴリ及びアクセス識別子に基づいて規制要否を判断し、規制が必要な場合はパラメータ値に応じた規制動作を行う。
　（５）実施形態に係る動作
　実施形態に係る各動作パターンについて説明する。
　以下においては、配信モード１ベースのソリューションを用いて、ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うシナリオを主として想定する。但し、後述の第２動作パターン及び第３動作パターンでは、配信モード２ベースのソリューションを適用してもよい。
　また、ＲＲＣインアクティブ状態のＵＥ１００がマルチキャスト受信を行うシナリオを想定するが、ＲＲＣアイドル状態のＵＥ１００がマルチキャスト受信を行うシナリオを想定してもよい。すなわち、以下の実施形態の説明におけるＲＲＣアイドル状態をＲＲＣインアクティブ状態と読み替えてもよい。
　（５．１）第１動作パターン
　ネットワーク５がデディケイテッドシグナリングでＰＴＭ設定（マルチキャスト設定）をＵＥ１００に対して行った後、ＵＥ１００がマルチキャスト受信をＲＲＣインアクティブ状態で行っている（もしくは待ち受けている）ものとする。ＲＲＣインアクティブ状態のＵＥ１００は、ＰＴＭ設定の更新が必要になったことに応じて、ネットワーク５にアクセスし、新しいＰＴＭ設定をネットワーク５から受信する。
　具体的には、ＲＲＣインアクティブ状態のＵＥ１００は、ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージをネットワーク５に送信することでネットワーク５にアクセスする。なお、ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージをネットワーク５に送信したＵＥ１００は、ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージに応じて、新たなＰＴＭ設定を含むＲＲＣ　Ｒｅｌｅａｓｅメッセージをネットワーク５から受信した場合、ＲＲＣコネクティッド状態に遷移することなく新たなＰＴＭ設定を取得できる。
　ここで、ＲＲＣインアクティブ状態のＵＥ１００では、ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージをネットワーク５に送信する前に、通常はＵＡＣによるアクセス制御が適用される。アクセス制御によりアクセスが規制される場合、ＵＥ１００は、ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージをネットワーク５に送信できない。
　ＲＲＣインアクティブ状態でマルチキャスト受信を行うＵＥ１００がＰＴＭ設定更新のためにネットワーク５にアクセスする場合、ＵＡＣをスキップ可能とすることが考えられる。ＰＴＭ設定の更新だけでユニキャスト通信を行わない場合、ネットワーク５の負荷が増大しないため、アクセス制御による規制を受けないというのはリーズナブルではある。しかしながら、ＲＲＣインアクティブ状態でのマルチキャスト受信のモチベーションのひとつは、ネットワーク混雑の緩和であり、ネットワーク混雑中にＵＡＣをスキップして大量のＵＥ１００がネットワーク５にアクセスすることは好ましくない。そこで、本動作パターンでは、ＲＲＣインアクティブ状態でマルチキャスト受信を行うＵＥ１００がＰＴＭ設定更新のためにネットワーク５にアクセスするときにＵＡＣを適用するか又はスキップするかを、ネットワーク５から設定可能とする。
　すなわち、本動作パターンでは、第１に、ＵＥ１００は、デディケイテッドシグナリングによりネットワーク５から受信したマルチキャスト設定（ＰＴＭ設定）に基づいて、ＲＲＣインアクティブ状態においてマルチキャスト受信を行う。第２に、ＵＥ１００は、マルチキャスト設定の更新が必要であると判定したことに応じて、更新のためにネットワーク５へのアクセスを行うことを決定する。第３に、ＵＥ１００は、アクセスを規制するためのアクセス制御（ＵＡＣ）を適用するか又はスキップするかを、ネットワーク５からの設定情報（「ＵＡＣスキップ可否情報」とも称する）に基づいて判定する。
　これにより、ＲＲＣインアクティブ状態でマルチキャスト受信を行うＵＥ１００がＰＴＭ設定更新のためにネットワーク５にアクセスするときにＵＡＣを適用するか又はスキップするかを、ネットワーク５から設定できる。例えば、ネットワーク５（ｇＮＢ２００）は、ネットワーク混雑中はＵＡＣを適用するようＵＥ１００に設定し、ネットワーク混雑中でなければＵＡＣをスキップするようＵＥ１００に設定できる。
　本動作パターンでは、ＵＥ１００は、当該設定情報をネットワーク５（ｇＮＢ２００）から受信する。当該設定情報は、マルチキャスト設定（ＰＴＭ設定）の更新のみの目的でネットワーク５へのアクセスを行うときにアクセス制御（ＵＡＣ）をスキップすることをＵＥ１００に許可するか否かを設定するための情報である。これにより、ＰＴＭ設定更新のみの場合にＵＡＣをスキップしてよいか否かをｇＮＢ２００からＵＥ１００に通知及び設定できる。
　図９は、本動作パターンに係る移動通信システム１の動作例を示す図である。
　ステップＳ１０１において、ＲＲＣコネクティッド状態のＵＥ１００は、特定のマルチキャストセッション（ここでは、マルチキャストセッション＃１とする）に参加する。
　ステップＳ１０２において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、マルチキャストセッション＃１の受信に必要なＰＴＭ設定を含むデディケイテッドシグナリングを送信する。当該デディケイテッドシグナリングは、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージであってもよい。当該デディケイテッドシグナリングは、後述のＵＡＣスキップ可否情報を含んでもよい。ＵＥ１００は、受信したＰＴＭ設定を記憶する。
　ステップＳ１０３において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、ＵＥ１００をＲＲＣインアクティブ状態に遷移させるためのＲＲＣ　Ｒｅｌｅａｓｅメッセージ（具体的には、Ｓｕｓｐｅｎｄ　Ｃｏｎｆｉｇ．を含むＲＲＣ　Ｒｅｌｅａｓｅメッセージ）を送信する。ステップＳ１０３は、ステップＳ１０２と同時であってもよい。ＲＲＣ　Ｒｅｌｅａｓｅメッセージは、上述のＰＴＭ設定及び／又はＵＡＣスキップ可否情報を含んでもよい。
　ステップＳ１０４において、ＵＥ１００は、ステップＳ１０３のＲＲＣ　Ｒｅｌｅａｓｅメッセージの受信に応じて、ＲＲＣインアクティブ状態に遷移する。
　ステップＳ１０５において、ＵＥ１００は、ＲＲＣインアクティブ状態でマルチキャストセッション＃１のマルチキャストデータを受信する（もしくは待ち受ける）。
　ステップＳ１０６において、ｇＮＢ２００は、ＰＴＭ設定更新のみの場合におけるＵＡＣのスキップ可否を示すＵＡＣスキップ可否情報をＵＥ１００に送信してもよい。ＵＥ１００は、ＵＡＣスキップ可否情報を受信する。当該ＵＡＣスキップ可否情報は、システム情報ブロック（ＳＩＢ）、ページングメッセージ、及びＭＣＣＨのいずれかで送信される。
　なお、ＵＡＣスキップ可否情報は、例えば、「ＵＡＣスキップ許可」、「ＵＡＣスキップ不可」、又は「ＵＡＣをスキップしてもよいか否か」の情報であってもよい。ＵＡＣスキップ可否情報は、マルチキャストセッションごと（例えば、ＴＭＧＩごと）に通知されてもよい。例えば、ＵＡＣスキップ可否情報及び対応するＴＭＧＩ（又はＭＲＢ　ＩＤ）のセットが送受信されてもよい。
　例えば、ｇＮＢ２００は、ネットワーク混雑時には、ＵＡＣスキップ可否情報により、ＵＡＣスキップ不可をＵＥ１００に通知してもよい。一方、ネットワーク混雑が解消した場合、ｇＮＢ２００は、ＵＡＣスキップ可否情報により、ＵＡＣスキップ許可をＵＥ１００に通知してもよい。
　ステップＳ１０７において、ｇＮＢ２００は、ＰＴＭ設定更新の通知をＵＥ１００に送信する。ＵＥ１００は、当該通知を受信する。当該通知は、ＰＴＭ設定が更新されるマルチキャストセッションのＴＭＧＩを含むページングメッセージであってもよい。ここでは、ｇＮＢ２００が、マルチキャストセッション＃１についてＰＴＭ設定更新を通知するものとする。ＵＥ１００は、当該通知の受信に応じて、ＰＴＭ設定更新のためにｇＮＢ２００に対してアクセス（ＲＲＣレジューム処理）を行うことを決定する。
　ステップＳ１０８において、ＵＥ１００は、ＰＴＭ設定更新のみの目的でＲＲＣレジュームを行う場合、ＵＡＣスキップ可否情報に基づいて、ＵＡＣを適用するか又はスキップするかを判定する。ここで、ＵＥ１００はＵＡＣをスキップすると判定した場合、ＵＡＣよりもＰＴＭ設定更新によるアクセスを優先するとみなしてもよい。なお、ＵＥ１００は、ＲＲＣレジュームの他のトリガ（例えば、上りリンクデータが発生したこと）も検知した場合、ＵＡＣスキップ可否情報にかかわらず、ＵＡＣを適用すると判定してもよい。ＵＡＣをスキップすると判定した場合（ステップＳ１０８：ＹＥＳ）、ＵＡＣの処理をスキップしてステップＳ１１０に進む。
　一方、ＵＡＣを適用すると判定した場合（ステップＳ１０８：ＮＯ）、ステップＳ１０９において、ＵＥ１００は、上述のＵＡＣを適用し、ｇＮＢ２００へのアクセスが許可されるか又は禁止（規制）されるかを判定する。ｇＮＢ２００へのアクセスが禁止されると判定した場合、ＵＥ１００は、ｇＮＢ２００へのアクセスを控える。ここでは、ｇＮＢ２００へのアクセスが許可されたと仮定して説明を進める。
　ステップＳ１１０において、ＵＥ１００は、ｇＮＢ２００へのアクセスを行い、ＲＲＣ　Ｒｅｓｕｍｅ　ＲｅｑｕｅｓｔメッセージをｇＮＢ２００に送信する。ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージは、ＰＴＭ設定更新を示す情報を含んでもよい。
　ステップＳ１１１において、ｇＮＢ２００は、マルチキャストセッション＃１について更新後の新たなＰＴＭ設定をＵＥ１００に送信する。ＵＥ１００は、新たなＰＴＭ設定を受信及び記憶する。
　なお、ＵＥ１００は、ＰＴＭ設定の更新後にＲＲＣインアクティブ状態のままマルチキャスト受信を行うと判定した場合に、ＵＡＣスキップ可否情報に基づいて、ＵＡＣを適用するか又はスキップするかを判定してもよい（ステップＳ１０８）。すなわち、ＵＥ１００は、ＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔを送信した後に新たなＰＴＭ設定を含むＲＲＣ　Ｒｅｌｅａｓｅメッセージを受信すると予期する場合、すなわち、ＲＲＣコネクティッド状態に遷移せずに新たなＰＴＭ設定を取得可能であると予期する場合、ステップＳ１０８の判定を行ってもよい。例えば、ＵＥ１００において受信のみを行うマルチキャストセッション（例えば、テレビ放送のようなマルチキャストセッション）の場合に、ＲＲＣ　Ｒｅｌｅａｓｅを受信すると予期してもよい。一方、グループ通話のように、ＵＬ送信を伴うマルチキャストセッションの場合、ＲＲＣコネクティッド状態で当該マルチキャストセッションの受信を行うと予期できる。
　（５．２）第２動作パターン
　上述のように、ＭＢＳブロードキャストについては、ＲＲＣアイドル状態／ＲＲＣインアクティブ状態において、ＭＢＳ周波数を最高優先度とみなすことができる仕組みが採用されている。一方、ＭＢＳマルチキャストについては、現状の技術仕様では、このような仕組みは無い。
　しかしながら、ＭＢＳマルチキャストをＲＲＣインアクティブ状態で受信可能とする場合、ＭＢＳマルチキャストをＵＥ１００が受信不能なセルにキャンプしてしまうと、ＵＥ１００がマルチキャスト受信を行うことができない。また、ＭＢＳブロードキャストと比較して、ＭＢＳマルチキャストは、ｇＮＢ２００のフルコントロールが前提であること、及び、ＵＥ１００はＲＲＣインアクティブ状態でＭＢＳ興味が変わることはない（具体的には、興味が変わった場合、ＲＲＣコネクティッド状態に遷移してＮＡＳでセッション離脱又はセッション参加をしなくてはならない）という点が異なる。そのため、ＲＲＣコネクティッド状態時にｇＮＢ２００に保持されたＵＥ　ｃｏｎｔｅｘｔを用いて、ｇＮＢ２００から周波数の制御が可能であり得る。よって、ＭＢＳマルチキャストの場合、ＭＢＳブロードキャストとは異なる周波数優先度付け処理（Ｐｒｉｏｒｉｔｙ　ｈａｎｄｌｉｎｇ）が必要となる可能性がある。
　本動作パターンでは、ＵＥ１００は、ＰＴＭ設定を受信した（もしくはＲＲＣ　Ｒｅｌｅａｓｅを受信した）ときのサービングセルの周波数を、セル再選択の最高優先度とみなす。すなわち、ＵＥ１００は、ネットワーク５から受信したマルチキャスト設定（ＰＴＭ設定）に基づいて、ＲＲＣインアクティブ状態においてマルチキャスト受信を行う。ＵＥ１００は、ＲＲＣインアクティブ状態において、当該ＰＴＭ設定を送信したセルが属する周波数をセル再選択の最高優先度とみなす。
　具体的には、本動作パターンでは、ＵＥ１００に対してＰＴＭ設定を送信したセルの属する周波数がマルチキャストをサポートしている周波数であると仮定している。ＵＥ１００がセル再選択の最高優先度とみなす周波数を自律的に決定することにより、ｇＮＢ２００が当該周波数をＵＥ１００に明示的に指定しなくても済み、シグナリング負荷の増大を抑制できる。そのため、ｇＮＢ２００から周波数指定しなかった場合、ＵＥ１００は自律的にマルチキャストを受信できる周波数を最高優先度として待ち受けることができる。
　図１０は、本動作パターンに係る移動通信システム１の第１動作例を示す図である。
　ステップＳ２０１において、ＲＲＣコネクティッド状態のＵＥ１００は、マルチキャストセッション（ここでは、マルチキャストセッション＃１とする）に参加する。
　ステップＳ２０２において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、マルチキャストセッション＃１の受信に必要なＰＴＭ設定を含むデディケイテッドシグナリングを送信する。当該デディケイテッドシグナリングは、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージであってもよい。ＵＥ１００は、受信したＰＴＭ設定を記憶する。
　ステップＳ２０３において、ＵＥ１００は、ステップＳ２０２のＰＴＭ設定を送信したセルが属する周波数を記憶する。
　ステップＳ２０４において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、ＵＥ１００をＲＲＣインアクティブ状態に遷移させるためのＲＲＣ　Ｒｅｌｅａｓｅメッセージ（具体的には、Ｓｕｓｐｅｎｄ　Ｃｏｎｆｉｇ．を含むＲＲＣ　Ｒｅｌｅａｓｅメッセージ）を送信する。ステップＳ２０４は、ステップＳ２０２と同時であってもよい。ＲＲＣ　Ｒｅｌｅａｓｅメッセージは、上述のＰＴＭ設定を含んでもよい。
　ステップＳ２０５において、ＵＥ１００は、ＲＲＣ　Ｒｅｌｅａｓｅに周波数優先情報（ｄｅｄｉｃａｔｅｄ　ｐｒｉｏｒｉｔｙ等）が含まれていないことを確認してもよい。ＵＥ１００は、マルチキャストセッション＃１をＲＲＣインアクティブ状態で受信する（もしくは待ち受ける）ことを認識してもよい。
　ステップＳ２０６において、ＵＥ１００は、ステップＳ２０４のＲＲＣ　Ｒｅｌｅａｓｅメッセージの受信に応じて、ＲＲＣインアクティブ状態に遷移する。
　ステップＳ２０７において、ＵＥ１００は、ステップＳ２０３で記憶した周波数、すなわち、ＰＴＭ設定（もしくはＲＲＣ　Ｒｅｌｅａｓｅ）を受信したときのサービングセルが属する周波数を最高優先度とみなす。これにより、ＵＥ１００は、マルチキャストセッション＃１をサポートするセルにキャンプする状態を維持しやすくなる。
　ステップＳ２０８において、ＵＥ１００は、ＲＲＣインアクティブ状態でマルチキャストセッション＃１のマルチキャストデータを受信する（もしくは待ち受ける）。
　上述の第１動作例では、ｇＮＢ２００がセル再選択で優先する周波数をＵＥ１００に明示的に指定しないことを想定していた。しかしながら、ＵＥ１００がｇＮＢ２００から周波数が指定された場合、ＵＥ１００が最高優先度とみなす周波数を自律的に決定しないことが望ましい。そのため、本動作パターンでは、ＵＥ１００は、デディケイテッドシグナリングで周波数を指定された場合（ｄｅｄｉｃａｔｅｄ　ｐｒｉｏｒｉｔｙ及び／又はｄｅ－ｐｒｉｏｒｉｔｉｚａｔｉｏｎ　ｒｅｑｕｅｓｔ等）、ＵＥ自身で特定した周波数を最高優先度とみなす処理を適用しない。
　具体的には、ＵＥ１００は、周波数を指定する指定情報（「周波数指定情報」とも称する）を含むデディケイテッドシグナリングをネットワーク５から受信し、ＲＲＣインアクティブ状態においてマルチキャスト受信を行う。ＵＥ１００は、ＲＲＣインアクティブ状態において、ＵＥ１００が決定した周波数をセル再選択の最高優先度とみなす処理を適用せずに、当該指定情報に基づいてセル再選択の周波数優先度を決定する。ここで、当該指定情報に基づいてセル再選択の周波数優先度を決定する動作は、従来と同様な周波数優先度付け処理である。
　図１１は、本動作パターンに係る移動通信システム１の第２動作例を示す図である。上述の動作と重複する動作については重複する説明を省略する。
　ステップＳ３０１において、ＵＥ１００は、マルチキャストセッションに参加する。
　ステップＳ３０２において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対してＰＴＭ設定を送信する。ＵＥ１００は、ＲＲＣコネクティッド状態でＰＴＭ設定を受信する。
　ステップＳ３０３において、ｇＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に対して、ＵＥ１００をＲＲＣインアクティブ状態に遷移させるためのＲＲＣ　Ｒｅｌｅａｓｅメッセージを送信する。ＵＥ１００は、ＲＲＣ　Ｒｅｌｅａｓｅメッセージを受信し、ＲＲＣインアクティブ状態に遷移する。ステップＳ３０３は、ステップＳ３０２と同時であってもよい。ＲＲＣ　Ｒｅｌｅａｓｅメッセージは、上述のＰＴＭ設定を含んでもよい。
　ステップＳ３０３のＲＲＣ　Ｒｅｌｅａｓｅメッセージ（もしくは、ステップＳ３０２のＰＴＭ設定）は、周波数を指定する周波数指定情報を含む。周波数指定情報は、次の情報のうち少なくとも１つである：
　・Ｄｅｄｉｃａｔｅｄ　ｐｒｉｏｒｉｔｙ：セル再選択優先度を指定する情報要素である；
　・Ｄｅ－ｐｒｉｏｒｉｔｉｚａｔｉｏｎ　ｒｅｑｕｅｓｔ：最低優先度とする周波数又は無線アクセス技術（ＲＡＴ）を指定する情報要素である；
　・Ｒｅｄｉｒｅｃｔｅｄ　Ｃａｒｒｉｅｒ　Ｉｎｆｏ：キャンプする周波数又はＲＡＴを指定する情報要素である。
　或いは、周波数指定情報は、マルチキャスト周波数を指定するための新たな情報要素であってもよい。当該新たな情報要素は、例えば、”ｍｕｌｔｉｃａｓｔ　ｒｅｃｅｐｔｉｏｎ　ｆｒｅｑｕｅｎｃｙ”などである。当該新たな情報要素は、ＴＭＧＩ毎（ＴＭＧＩと紐づいている）であってもよい。
　ステップＳ３０３のＲＲＣ　Ｒｅｌｅａｓｅメッセージ（もしくは、ステップＳ３０２のＰＴＭ設定）は、周波数指定情報が強制であるか又は任意であるかを示す情報要素をさらに含んでもよい。「強制」の場合、下記の処理へ進む。一方、「任意」の場合、既存仕様と同様に最高優先度とみなす処理を行ってもよい。
　ステップＳ３０４において、ＵＥ１００は、ｇＮＢ２００から明示的に周波数（周波数優先度）が指定されていることを認識する。
　ステップＳ３０５において、ＵＥ１００は、ステップＳ３０３のＲＲＣ　Ｒｅｌｅａｓｅメッセージの受信に応じて、ＲＲＣインアクティブ状態に遷移する。
　ステップＳ３０６において、ＵＥ１００は、ＵＥ１００が特定したある周波数（いわゆる、ＭＢＳ周波数）を最高優先度とみなす処理を行わず、ｇＮＢ２００から指定された周波数優先度を適用する。ＵＥ１００は、ｇＮＢ２００から指定された周波数（“ｍｕｌｔｉｃａｓｔ　ｒｅｃｅｐｔｉｏｎ　ｆｒｅｑｕｅｎｃｙ”）を最高優先度とみなしてもよい。ＵＥ１００は、ｇＮＢ２００から指定された周波数（ｄｅ－ｐｒｉｏｒｉｔｉｚａｔｉｏｎ　ｒｅｑｕｅｓｔ）を最低優先度とみなしてもよい。これにより、ＵＥ１００は、マルチキャストセッション＃１をサポートするセルにキャンプする状態を維持しやすくなる。
　ステップＳ３０７において、ＵＥ１００は、ＲＲＣインアクティブ状態でマルチキャストセッション＃１のマルチキャストデータを受信する（もしくは待ち受ける）。
　なお、ＵＥ１００は、既にＲＲＣインアクティブ状態でマルチキャスト受信を行っている場合、ステップＳ３０６に代えて、現在マルチキャストセッション＃１を送信しているセルの周波数を最高優先度とみなしてもよい。
　また、上記「強制・任意を示す情報」は、ＲＲＣインアクティブ状態でのマルチキャスト受信に限定されなくてもよい。例えば、ＲＲＣアイドル状態であってもよいし、マルチキャスト受信に興味がない場合に当該情報を適用してもよい。
　（６）その他の実施形態
　ＵＥ１００は、ＲＲＣコネクティッド状態において、ユニキャスト受信とＭＢＳブロードキャスト受信とを同一ハードウェアで実行できる。この場合、ｇＮＢ２００は、ＵＥ１００の処理能力を考慮してユニキャストのスケジューリングを行う必要がある。ＵＥ１００は、ＭＢＳブロードキャスト受信に係る処理能力に関する情報をｇＮＢ２００へ報告できる。当該処理能力に関する情報は、ＭＢＳブロードキャストの、周波数、サブキャリア間隔、及び帯域幅の情報を少なくとも含む。当該処理能力に関する情報は、ＭＢＳ興味情報メッセージにて報告されてもよい。ＭＢＳ興味情報メッセージは、興味のあるＴＭＧＩ、周波数、及びユニキャストＭＢＳブロードキャストの優先度の情報を含むことができる。一方で、当該処理能力に関する情報は、ｇＮＢ２００おいて既知である場合、ＵＥ１００からの通知は不要である。よって、ｇＮＢ２００は、当該処理能力に関する情報の要否に関する情報をＵＥ１００へ通知してもよい。当該要否に関する情報は、前記ＭＢＳブロードキャストが同一ＰＬＭＮ（Ｐｕｂｌｉｃ　Ｌａｎｄ　Ｍｏｂｉｌｅ　Ｎｅｔｗｏｒｋ）で提供されているセッションなのか、又は他ＰＬＭＮで提供されているセッションなのかによって、要否が通知されてもよい。ＵＥ１００は、興味のあるＴＭＧＩに含まれるＰＬＭＮ　ＩＤと現在のサービングＰＬＭＮとを比較することで、同一ＰＬＭＮで提供されているセッションか否かを特定することができる。もしくは、当該要否に関する情報は、ＴＭＧＩによって、要否が通知されてもよい。ｇＮＢ２００は、既に他のＵＥ１００から通知された前記処理能力に関する情報を既に有しているＴＭＧＩについては、前記報告が不要であることを通知してもよい。
　実施形態では、最高優先度の処理例について示したが、最低優先度の処理に適用してもよい。上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよいし、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。各フローにおいて、必ずしもすべてのステップを実行する必要は無く、一部のステップのみを実行してもよい。
　上述の実施形態及び実施例において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）又は６Ｇ基地局であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵであってもよい。また、ＵＥ１００は、ＩＡＢノードのＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）であってもよい。
　また、用語「ネットワークノード」は、主として基地局を意味するが、コアネットワークの装置又は基地局の一部（ＣＵ、ＤＵ、又はＲＵ）を意味してもよい。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ）として構成してもよい。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ／ｉｎ　ｒｅｓｐｏｎｓｅ　ｔｏ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」等の呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本願は、米国仮出願第６３／４２１７６５号（２０２２年１１月２日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
　（７）付記１
　上述の実施形態に関する特徴について付記する。
　（付記１）
　マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
　デディケイテッドシグナリングによりネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、
　前記マルチキャスト設定の更新が必要であると判定したことに応じて、前記更新のために前記ネットワークへのアクセスを行うことを決定するステップと、
　前記アクセスを規制するためのアクセス制御を適用するか又はスキップするかを、前記ネットワークからの設定情報に基づいて判定するステップと、を有する
　通信方法。
　（付記２）
　前記設定情報を前記ネットワークから受信するステップをさらに有し、
　前記設定情報は、前記更新のみの目的で前記アクセスを行うときに前記アクセス制御をスキップすることを前記ユーザ装置に許可するか否かを設定するための情報である
　付記１に記載の通信方法。
　（付記３）
　マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
　ネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、
　前記ＲＲＣインアクティブ状態において、前記マルチキャスト設定を送信したセルが属する周波数をセル再選択の最高優先度とみなすステップと、を有する
　通信方法。
　（付記４）
　マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
　周波数を指定する指定情報を含むデディケイテッドシグナリングをネットワークから受信するステップと、
　無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うステップと、
　前記ＲＲＣインアクティブ状態において、前記ユーザ装置が決定した周波数をセル再選択の最高優先度とみなす処理を適用せずに、前記指定情報に基づいて前記セル再選択の周波数優先度を決定するステップと、を有する
　通信方法。
　（８）付記２
　上述の実施形態に関する補足事項について付記する。
１．導入
　ＭＢＳ（ｅＭＢＳ）の拡張に関する作業項目は、次のようにインアクティブのＵＥによるマルチキャスト受信をサポートすることを目的としている:
　-ＲＲＣインアクティブ状態のＵＥによるマルチキャスト受信のサポートを規定
　-ＲＲＣインアクティブ状態でマルチキャストを受信するＵＥのＰＴＭ設定
　-ＲＲＣインアクティブでマルチキャストを受信するＵＥのモビリティと状態遷移の影響を調査する（シームレス／ロスレスモビリティは不要）
　ＲＡＮ２はこの目的に向けて議論を開始し、一連の合意に達した。その上で、インアクティブでのマルチキャスト受信の詳細については、この付記で記述されている。
２．議論
２．１．配信モードベースライン
　Ｒｅｌ－１７では、２つの配信モードが規定された。つまり、マルチキャストセッションの場合はいわゆる配信モード１、ブロードキャストセッションの場合は配信モード２と呼ばれる。これにより、ＭＴＣＨを受信するための設定は、配信モード１で接続されているＵＥに対してのみＲＲＣ再設定によって提供されるが、配信モード２のすべてのＲＲＣ状態にあるＵＥに対してはＭＣＣＨによって行われる。
　ＲＡＮ２＃１１９ｅは、これらの配信モードがインアクティブでのマルチキャスト受信の候補であること、つまり選択肢１と選択肢２であることを識別した。これにより、これらの選択肢の「組み合わせ（Ｍｉｘ）」もテーブルに記載される。
　ＰＴＭ設定の配信に関して、ＲＡＮ２は次のソリューションをさらに調査する。
　選択肢１：デディケイテッドシグナリング
　選択肢２：ＳＩＢ＋ＭＣＣＨに基づくソリューション
　選択肢の「組み合わせ（Ｍｉｘ）」を排除するものではない。
　ＲＡＮ２＃１１９ｂｉｓ－ｅはさらに、選択肢１及び選択肢２の一般的な記述に合意した。
　次の一般的な記述は、ＰＴＭ設定配信選択肢１のベースラインとして採用される。
　（１－ａ）少なくとも１つのセルに対する１つ以上のマルチキャストセッションのＰＴＭ設定（すなわち、ＲＲＣインアクティブにおけるマルチキャスト受信に使用される設定）は、専用のＲＲＣシグナリングを介してＵＥに提供される。
　（１－ｂ）このためのＲＲＣメッセージには、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ及び／又はＲＲＣＲｅｌｅａｓｅ及び／又はＲＲＣＲｅｓｕｍｅが含まれる（詳細については更なる検討が必要である）。
　（１?ｃ）ＵＥは、ＲＲＣインアクティブにある間、受信した設定を保存し、一部又はすべての設定を更新する必要がある場合、ＵＥはそのような変更を通知され、更新された設定を取得するためにＲＲＣ接続Ｒｅｓｕｍｅをトリガしてもよい。ＲＲＣインアクティブのモビリティの場合、セッションの設定が新しいセルで利用できない場合、ＵＥはＲＲＣ接続のＲｅｓｕｍｅをトリガする。
　次の一般的な記述は、ＰＴＭ設定配信選択肢２のベースラインとなる。
　（２－ａ）ＰＴＭ設定（つまり、ＲＲＣインアクティブでのマルチキャスト受信に使用される設定）は、ＭＣＣＨのようなチャネル（ＭＢＳブロードキャストに使用されるものと同じ又は異なる）を介して提供され、ＭＣＣＨスケジューリングに関する情報は、ＳＩＢ、デディケイテッドシグナリングを介して提供される（更なる検討が必要である）。
　（２－ｂ）ＵＥは、ＲＲＣインアクティブにあるときにそのような設定を受信できる。ＵＥがＲＲＣコネクティッドにあるときにも受信することが許可されているか、必要であるかどうかについては更なる検討が必要である。
　（２?ｃ）受信した設定の一部又はすべてを更新する必要がある場合、ＵＥはＲＲＣ接続をｒｅｓｕｍｅする必要はないが、そのような変更について（例えば、ＭＣＣＨ　ＤＣＩを介して）通知され、ＭＣＣＨを介して更新された設定を取得する。
　これまでに企業から提出された寄書によると、インアクティブでのマルチキャスト受信のサポートは、ネットワークの輻輳とＵＥの電力節約の２つの理由によって動機付けられている。
　所見１：インアクティブでのマルチキャスト受信の動機は、ネットワークの輻輳とＵＥの電力節約である。
　この付記によると、ネットワークの輻輳に直接影響するシグナリングオーバーヘッドの点で、選択肢１は選択肢２よりも優れている。言い換えれば、モチベーションの観点から、ネットワークが輻輳に遭遇したときに、ＳＩＢ２０及びＭＣＣＨ送信による追加のシグナリングオーバーヘッドを許可することは意味がない。
　所見２：ＭＣＣＨ送信によるシグナリングオーバーヘッドは、ネットワークが輻輳している状態では非常に重要である。
　インアクティブのＵＥの観点から見ると、消費電力を削減するためにページング監視のためのＤＲＸを実行する。インアクティブでのマルチキャスト受信に選択肢２が選択された場合、ＵＥは追加のＤＲＸアクティビティ、つまりＭＣＣＨモニタリングを実行する必要があり、追加の電力消費が発生する。したがって、これはＵＥの省電力という動機と一致しない。
　所見３：ＭＣＣＨモニタリングアクティビティにより、ＲＲＣインアクティブでは追加のＵＥ電力消費が発生する。
　もちろん、選択肢１では、ＭＢＳ設定が提供又は更新されるときに、ＵＥがＲＲＣ　Ｒｅｓｕｍｅプロシージャを開始することが義務付けられる。ただし、「ＭＲＢが設定され、セッションがアクティブ化されると、セッション中に設定が頻繁に変更されることは想定されていない」と明確にされている。また、ＲＡＮ２＃１１９ｅでは、「ＲＲＣインアクティブ状態でのセル再選択後の（つまり、ＲＲＣ接続をＲｅｓｕｍｅせずに）マルチキャストサービスの継続性がサポートされる（新しいセルの設定がＵＥで利用可能な場合）」ことが合意されている。したがって、ネットワークの輻輳とＵＥの電力消費に関しては大きな問題にはならないはずである。
　さらに、Ｒｅｌ－１７では、マルチキャストサービスがいわゆる配信モード１（つまり、選択肢１）によって提供されることを規定していることがＲＡＮ２の共通の理解であり、これはマルチキャスト設計の基本概念である。解放間でこれほど大幅な変更を加える理由はない。
　上記の所見を考慮すると、選択肢１はＰＴＭ設定の配信にとって簡単である。
　提案１：ＲＡＮ２は、ＰＴＭ設定がデディケイテッドシグナリング、つまり選択肢１によって提供されることに合意すべきである。
２．２．ＲＲＣ状態遷移
　ＲＡＮ２＃１１９ｅでは、ＲＲＣ状態変更に関連する側面は要検討事項とされていた。
　Ｒｅｌ－１８では、ＵＥがすでに有効なＰＴＭ設定を持っていることを前提として、インアクティブのＵＥのマルチキャスト受信は少なくとも次のシナリオをサポートする。
　－シナリオ１：ＵＥはコネクティッドでマルチキャストを受信しており、インアクティブに入りマルチキャスト受信を継続する。
　－シナリオ２：ＵＥがマルチキャストセッションに参加し、インアクティブに指示された場合、ＵＥはマルチキャストセッションの受信を開始する。
　例えばインアクティブでサービスが提供されなくなった等の理由等の詳細については更なる検討が必要である。
　ネットワークとＵＥの観点から、ＲＲＣ状態の変化に関連する多くの側面があると考えられる。したがって、以下ではケースバイケースで記述する。
２．２．１．サブケース１：マルチキャストセッションのインアクティブ化／解放
　ＲＡＮ２＃１１９ｂｉｓ－ｅは、マルチキャストセッションがインアクティブ化されたときにＵＥに通知され、マルチキャストセッションが解放されたときにＲｅｌ－１７メカニズムが適用されることに合意した。
　ＵＥがＲＲＣインアクティブにあり、ＲＲＣインアクティブでマルチキャストセッションを受信するように設定されている場合、ＵＥは、マルチキャストセッションがインアクティブ化されたときに通知を受けることができる。方法については更なる検討が必要である（グループページング、ＭＣＣＨ、又はその他の方法を介して通知されるなど）。
　マルチキャストセッションの解放には、Ｒｅｌ－１７メカニズム（ＮＡＳベースの指示）が適用される。拡張が必要な場合については更なる検討が必要である。
　インアクティブ状態のＵＥがＭＢＳサービスを受信している場合、マルチキャストセッションはインアクティブ化又は解放されると考えられ、それに応じてｇＮＢはＰＴＭ／ＭＴＣＨの送信を停止する可能性がある。この場合、ＵＥがＭＴＣＨを監視し続ける理由はないが、ＰＴＭ設定が削除されない限り、ＵＥは監視し続ける必要がある。ＵＥの省電力の観点からは、ＭＴＣＨの監視をできるだけ早く停止することが望まれる。
　所見４：ＵＥの電力消費の観点から、マルチキャストセッションがインアクティブ化又は解放された後もＵＥがＰＴＭ／ＭＴＣＨを監視し続けることは非効率である。
　したがって、マルチキャストセッションのインアクティブ化時のＵＥの動作を明確にすることは価値がある。つまり、通知方法に関係なく、マルチキャストセッションのインアクティブ化の通知を受信した場合、ＵＥはＭＴＣＨの監視を停止できる必要がある。また、そのような通知を受信した場合、ＵＥはＲＲＣインアクティブのままでなければならない。
　提案２：ＲＡＮ２は、ＵＥがマルチキャストセッションのインアクティブ化の受信時にＭＴＣＨの監視を停止できることに合意すべきである。。
　マルチキャストセッションのインアクティブ化の場合、ＲＡＮ２は、グループページング、ＭＣＣＨ、又はその他の方法でＵＥに通知する方法については更なる検討が必要である。
　ＬＴＥ　ＳＣ－ＰＴＭでは、ＵＥがＧ－ＲＮＴＩのＰＤＣＣＨの監視を停止することを通知するために、ＳＣ－ＰＴＭ　Ｓｔｏｐ　Ｉｎｄｉｃａｔｉｏｎ　ＭＡＣ　ＣＥが導入されており、ＭＡＣ　ＣＥはＧ－ＲＮＴＩに関連付けられたＳＣ－ＭＴＣＨに多重化されている。この軽量シグナリングは、ＴＭＧＩとＧ－ＲＮＴＩ間の１対１マッピングの制限下で機能する可能性がある。一方、ＮＲＭ　ＢＳでは、ＴＭＧＩとＧ－ＲＮＴＩ間の多対１マッピングが許可されるため、ＭＡＣ　ＣＥが導入される場合は、インアクティブ化されたＴＭＧＩを示す必要がある。ＭＡＣ　ＣＥはＭＴＣＨと一緒に送信されるため、最後のマルチキャストデータの受信からＭＴＣＨ監視の停止までの遅延を最小限に抑えることが期待される。
　もう１つの選択肢は、グループページングを再利用することである。グループページングは、ＵＥ－ＩＤの代わりにＴＭＧＩを使用して、グループ内の複数のＵＥを同時にページングするために使用される。既存のページンググループリスト（つまり、ＴＭＧＩのリスト）はレガシーＵＥに適用できるため、グループページングはレガシーＵＥへの影響を回避するために、インアクティブ化通知用の新しいＴＭＧＩリストを追加する必要がある。グループページングはページングの機会に送信される。つまり、Ｉ－ＤＲＸサイクルに基づいて、最後のマルチキャストデータの受信とＭＴＣＨモニタリングの停止の間にはいくらかの遅延が発生する。
　第３の選択肢は、ＭＣＣＨを再利用することである。マルチキャストセッションの非活性化を通知する方法には２つの可能性がある。すなわち、非活性化されたＴＭＧＩのＰＴＭ設定を削除するか、非活性化されたＴＭＧＩを通知する新しい通知を追加するかである。いずれにせよ、ＭＣＣＨを更新する必要があるため、ＭＣＣＨ変更通知を事前にＵＥに送信する必要がある。そのため、最後のマルチキャストデータを受信してからＭＴＣＨ監視を停止するまでの遅延が長くなる。さらに、ＵＥはＭＣＣＨを取得するためにウェイクアップする必要があり、ＭＴＣＨのオケージョンとＩ－ＤＲＸに加えて、ＭＣＣＨの変更境界が１回発生するため、上記の他の選択肢に比べて消費電力が高くなる。
　上記を考慮すると、リソース効率とＵＥの消費電力の観点から、マルチキャストセッションの停止を通知するために、新しいＭＡＣＣＥ又は拡張グループページングのいずれかを選択することが望ましい。
　提案３：ＲＡＮ２は、マルチキャストセッション無効化の通知に新しいＭＡＣＣＥ又は拡張グループページングのいずれかを選択することに合意すべきである。
　マルチキャストセッションの解放については、ＲＡＮ２が合意したＲｅｌ－１７のＮＡＳベースの通知が適用され、これは「ネットワーク又はＭＢＳセッション解放によって要求されたマルチキャストセッションの解放」となる可能性がある。このプロシージャでは、ＵＥがｇＮＢからページングされ、ＡＭＦと通信するためにＲＲＣコネクティッドに遷移すると想定する。このプロシージャでは、既存のグループページング（あるいは従来の個別ページング）を再利用できるものとする。
　つまり、ｇＮＢはＵＥがＭＴＣＨの監視を停止できるようにＭＡＣ　ＣＥを送信し、その後、同時ＲＲＣ状態遷移によるシグナリングのストームを回避するために、レガシーの個別ページングを使用して、ＵＥに対してページのタイミングを分散させることができる。
　提案４：ＲＡＮ２は、マルチキャストセッション解放に特化した機能拡張は必要ないこと、つまり、ＵＥは既存の（グループ）ページングによってＲＲＣコネクティッドに遷移することに合意すべきである。
２．２．２．サブケース２：選択的遷移
　ＲＡＮ２＃１１９ｅは、サブケース２に関する以下の合意に達した。
　マルチキャストセッションをＵＥがインアクティブで受信できるかどうかを決定するのはｇＮＢである。そのような決定を行うために、ｇＮＢにどのような情報を提供するか（ＳＡ２の議論に関連）については更なる検討が必要である。
　ｇＮＢは、同じセル内のコネクティッドとインアクティブの両方のＵＥに対して、１つのマルチキャストセッションを送信することがサポートされている。ｇＮＢがこれをどのように設定するかについては、更なる検討が必要である。
　ネットワークは、どのＵＥがＲＲＣインアクティブで受信し、どのＵＥがＲＲＣコネクティッドで受信するかを選択でき、マルチキャストサービス受信のためにＵＥを状態間で移動できると想定する。
　ｇＮＢがＵＥをインアクティブに解放する場合、ｇＮＢは、ＵＥ能力、ＵＥアシスタンス情報、及び／又はＣＮアシスタンス情報（規定されている場合）などに基づいて、現在と同じように、つまりＲＲＣＲｅｌｅａｓｅ　ｗｉｔｈ　Ｓｕｓｐｅｎｄ　Ｃｏｎｆｉｇによって、どのＵＥを解放するかを選択できる。そのため、ＲＲＣＲｅｌｅａｓｅメッセージに関しては、ＵＥの選択的な遷移に関する機能強化は予想されていない。
　所見５：既存のＲＲＣＲｅｌｅａｓｅは、ｇＮＢがどのＵＥを解放するかを選択するために使用される。
　マルチキャストセッションのアクティブ化について、ＲＡＮ２＃１１９ｂｉｓ－ｅは以下の文章に合意した。
　Ｒｅｌ－１８セッションがアクティブになると、インアクティブ状態のＵＥに通知できる（詳細については更なる検討が必要である）。
　ベースラインとして、Ｒｅｌ－１８ＵＥにセッションのアクティブ化を通知するためにグループページングを使用できる（例えば、そのようなグループ通知を受信したときのＵＥの動作等の詳細については更なる検討が必要である）。
　セッションがアクティブ化されたときに、ＵＥがＲＲＣインアクティブでマルチキャストセッションを受信できるかどうかを判断する方法を、以下のソリューションを考慮して要検討事項で記述する（必要に応じてさらに記述を更新することができ、複数のソリューションが必要になる場合がある。）
　１．マルチキャストセッションがアクティブ化されると、ＵＥは、セッションのためにＲＲＣインアクティブで使用されたＰＴＭ設定がＵＥで使用可能であり、ＵＥがすでにセッションに参加している場合（専用ＲＲＣシグナリング又はＭＣＣＨ経由でＵＥに提供された設定など）は、ＲＲＣインアクティブでマルチキャストセッションを受信できるが、そうでない場合はＲＲＣコネクティッドに戻ってマルチキャストセッションを受信する。
　２．マルチキャストセッションがアクティブになると、ＵＥはＲＲＣインアクティブでマルチキャストセッションを受信できるかどうかをグループページングで示される（詳細なシグナリングについては更なる検討が必要である）。
　３．ＵＥは、ＵＥが解放される前に、デディケイテッドシグナリングによって「ＲＲＣインアクティブでマルチキャストセッションを受信できるかどうか」が設定される。マルチキャストセッションがアクティブになると、ＵＥはＲＲＣインアクティブに留まるか、それに応じてＲＲＣ接続をＲｅｓｕｍｅする（詳細なシグナリングについては更なる検討が必要である）。
　Ｒｅｌ－１７では、マルチキャストセッションの活性化はグループページングによって通知される。Ｒｅｌ－１８とレガシーメカニズムを区別する必要はないため、ＲＡＮ２はマルチキャストセッションのアクティブ化をＵＥに通知するためにグループページングが使用されることを確認する必要がある。
　提案５：ＲＡＮ２は、Ｒｅｌ－１８　ＵＥにセッションのアクティブ化を通知するためにグループページングを使用できることを確認する必要がある。
　確認の上で、ＲＡＮ２は、上記で言及したように、マルチキャスト活性化通知の受信時のＵＥの動作について、３つの選択肢を特定した。
　選択肢１の場合、ＵＥは、有効なＰＴＭ設定があれば、インアクティブでマルチキャストセッションを受信できる。インアクティブ状態のＵＥは、ＰＴＭ設定なしではマルチキャストセッションを受信できないため、他のすべてのＵＥ動作のベースラインと考えることができる。そのため、選択肢１に合意すべきである。
　提案６：ＲＡＮ２は、ＵＥの動作選択肢１：マルチキャストセッションがアクティブ化されたとき、セッションのためにＲＲＣインアクティブで使用されたＰＴＭ設定がＵＥで使用可能であり、ＵＥがすでにセッションに参加している場合（専用ＲＲＣ信号又はＭＣＣＨ経由でＵＥに提供された設定など）は、ＵＥはＲＲＣインアクティブでマルチキャストセッションを受信できる。
　選択肢２の場合、ＵＥはグループページングを受信した時点で、マルチキャストセッションをインアクティブで受信すべきかどうかを示す。
　選択肢３の場合、ＵＥは、ＲＲＣ再設定又はＲＲＣ　Ｒｅｌｅａｓｅによって、マルチキャストセッションをインアクティブで受信すべきかどうかを事前に示す。
　これらの選択肢は、ＵＥにそのように指示するメッセージを除き、非常によく似たメカニズムになる可能性がある。つまり、これらの選択肢は、上記の所見１で述べた動機の観点から分析することができる。
　ネットワーク輻輳の場合、セル負荷が時々刻々と変化することが想定される。選択肢２では、グループページング内で通知が送信されるため、ｇＮＢがＵＥをインアクティブに保つべきかどうかを決定する際に、最新の負荷状況を考慮することができる。一方、選択肢３では、ｇＮＢがＵＥに通知する際に将来の負荷を予測するため、ｇＮＢが実際にグループページングを送信する際にセル負荷が変更される可能性がある。そのため、輻輳が悪化してもコネクティッドに遷移するＵＥが増えたり、輻輳が解消してもインアクティブに留まるＵＥが増えたりするなどのリスクがある。そのため、ＵＥのＲＲＣ状態を効率的に制御するには、選択肢２が望ましい。
　ＵＥの省電力ケースから、ＵＥ　Ａｓｓｉｓｔａｎｃｅ　Ｉｎｆｏｒｍａｔｉｏｎに何らかの「省電力プリファレンス」を導入することが想定される。このようなプリファレンス通知は、接続中のＵＥからのみ送信できる。そのため、ｇＮＢは、ＵＥが前回コネクティッド状態であったときに、ＵＥがインアクティブ状態でマルチキャストセッションの受信を許可されているかどうかをＵＥに示すことができる。このようなプリファレンス通知が導入されていない場合、ｇＮＢはＵＥが省電力を好むかどうかを知らないため、ｇＮＢはいつでもこの通知を送信することができる。つまり、選択肢２と選択肢３に違いはない。
　上記の分析を踏まえると、選択肢２の方が効率的であり、選択肢３の使用量をカバーできると考えられる。したがって、ＲＡＮ２は少なくとも選択肢２に合意すべきである。
　提案７：ＲＡＮ２は、ＵＥの動作選択肢２「マルチキャストセッションがアクティブになると、ＵＥはＲＲＣインアクティブでマルチキャストセッションを受信できるかどうかをグループページングで示される（詳細なシグナリングについては更なる検討が必要である）」に合意すべきである。。
　選択肢２のグループページングに関して、現在の仕様では、グループページングを受信したときのＵＥの動作、つまり、ページングメッセージに関心のあるＴＭＧＩが含まれている場合、すべてのＵＥがＲＲＣ　Ｒｅｓｕｍｅプロシージャを開始することが規定されているため、選択肢２で選択的ページングが必要な場合、ｇＮＢはページングメッセージにＴＭＧＩを含めることができない。ｇＮＢが選択的ページング（つまり、選択されたＲｅｌ－１８ＵＥをページングするための、ＴＭＧＩを使用しないレガシー個別ページング）用のＵＥ－ＩＤのみを含む場合、インアクティブでマルチキャストのアクティブ化を待つＲｅｌ－１７　ＵＥをページングすることはできない。さらに、シグナリングのオーバヘッドの点でも非効率的である。
　所見６：つまり、ページングメッセージに関心のあるＴＭＧＩが含まれている場合、すべてのＵＥがＲＲＣコネクティッドに遷移する。
　現在のページンググループリストがグループページングメッセージに設定され、少なくともＲｅｌ－１７　ＵＥをページングすると想定すると、関心のあるＴＭＧＩによってＲｅｌ－１８　ＵＥもページングされる。そこで、選択されたＵＥがコネクティッドに遷移しないように、ＵＥ－ＩＤの新しいリストである"ｐａｇｉｎｇｃａｎｃｅｌｌｉｓｔ"（又は"ｉｎａｃｔｉｖｅａｌｌｏｗｅｄｌｉｓｔ"）を定義し、このリストにリストされているＵＥがマルチキャストセッションを受信できるようにインアクティブのままにすることが考えられる。
　そのため、ＲＡＮ２は、ＵＥのサブセットをページングするためにグループページングを強化する方法について議論すべきである。
　提案８：ＲＡＮ２は、例えば、マルチキャストセッション受信のためにインアクティブにとどまる新しいＵＥ－ＩＤリストを使用して、ＵＥのサブセットをページングするためにグループページングを強化する方法について議論すべきである。
２．２．３．サブケース３：ＱｏＳエンフォースメント
　ＲＡＮ２＃１１９ｅは、サブケース３に関連する以下の合意に達した。
　ＲＲＣインアクティブのマルチキャスト受信では、ＨＡＲＱフィードバックとＰＴＰはサポートされない。
　合意によると、インアクティブでのマルチキャスト受信は、Ｒｅｌ－１７で規定されたＭＢＳ放送受信（いわゆる配信モード２）と同様である。ＭＢＳの放送は、ベストエフォートを基本としている。
　一方、ＱｏＳ／信頼性を保証することは、マルチキャストセッションにとって重要な問題である。また、ＳＡ２は、コネクティッドとインアクティブでマルチキャスト受信の品質／信頼性に違いがあるかどうか疑問視し、ＲＡＮ２＃１１９ｂｉｓ－ｅは以下の回答に合意した。
　ＲＡＮ２Ｑ１－ａ）ＲＲＣコネクティッド状態のＵＥとＲＲＣインアクティブ状態のＵＥとの間で、ＭＢＳデータ受信の品質と信頼性に大きな違いがある場合：
　ＲＲＣコネクティッド状態のＵＥとＲＲＣインアクティブ状態のＵＥ間のＭＢＳデータ受信の品質及び信頼性は、ＨＡＲＱフィードバック及びＰＴＰ送信がサポートされておらず、ＲＲＣインアクティブでのマルチキャスト受信にシームレス／ロスレスモビリティが要求されていないため、異なる場合もある。
　ＲＲＣコネクティッド状態のＵＥとＲＲＣインアクティブ状態のＵＥ間のＭＢＳデータ受信の品質及び信頼性は、ＨＡＲＱフィードバック及びＰＴＰ送信がサポートされておらず、ＲＲＣインアクティブでのマルチキャスト受信にシームレス／ロスレスモビリティが要求されていないため、異なる場合もある。
　ＲＡＮ２＃１１９ｅでは、ＲＳＲＰやＢＬＥＲなどの受信品質の閾値を導入することが提案されており、マルチキャスト受信に要求されるＱｏＳを一定レベル確保するために利用されると考えられている。また、ネットワークがＱｏＳ要件を管理する上でも役立つ。インアクティブでのマルチキャスト受信が対応するＱｏＳ要件を満たすことができない場合、ＵＥはコネクティッドに遷移し、ＨＡＲＱフィードバック／再送信やＰＴＰ（又はＳｐｌｉｔＭＲＢ）を利用して受信品質を保証する必要がある。
　所見７：マルチキャストセッションは、ＵＥがインアクティブ状態であっても、一定のＱｏＳ要件を確保する必要がある。
　ＲＳＲＰのしきい値については、ＮＲＭＢＳがシングルセル伝送方式で想定されているため、ＵＥがセル端に移動したり、セル再選択を行ったりするたびに、常にコネクティッドに遷移する必要があると考えられる。これは、ネットワークの輻輳やＵＥの省電力化の観点から、展開によっては最適な動作ではないかもしれない。
　ＢＬＥＲのしきい値に関しては、ＱｏＳの要件を確保するために、より簡単であると考えられる。したがって、受信品質に基づくＲＲＣの状態遷移を導入する場合は、これらの選択肢について議論すべきである。
　提案９：ＲＡＮ２は、受信品質が閾値（例えば、ＲＳＲＰ又はＢＬＥＲ）より悪くなった場合、インアクティブ状態のＵＥがコネクティッドに遷移すべきであることに合意すべきである。
２．２．４．サブケース４：モビリティとサービスの継続性
　ＲＡＮ２＃１１９ｅは、サブケース４に関する以下の記述に合意した。
　ＲＲＣインアクティブ状態でのセル再選択後（つまりＲＲＣ接続をＲｅｓｕｍｅせずに）のマルチキャストサービスの継続がサポートされる（新しいセルの設定がＵＥで利用可能な場合）。ＵＥが接続をＲｅｓｕｍｅする必要がある場合があるかどうかについては更なる検討が必要である。ＧＮＢ間モビリティによるＲＡＮ３の影響についても更なる検討が必要である。
　アクティブなマルチキャストセッション中に近隣セルへのセル再選択が行われた場合、インアクティブ状態のＵＥが新しいセルでセッションの設定を利用できない場合、ＵＥはＲＲＣ接続をＲｅｓｕｍｅしてマルチキャストＭＲＢの設定を取得する必要がある。
　ＲＡＮ２＃１１９ｂｉｓ－ｅは、配信モード選択肢１の問題を特定した。
　以下の一般的な記述は、ＰＴＭ設定配信選択肢１のベースラインとされる：
　（１－ａ）少なくとも１つのセルの１つ又は複数のマルチキャストセッションのＰＴＭ設定（すなわち、ＲＲＣインアクティブでのマルチキャスト受信に使用される設定）が、専用のＲＲＣシグナリングを介してＵＥに提供される。
　（１－ｂ）このためのＲＲＣメッセージには、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ及び／又はＲＲＣ　Ｒｅｌｅａｓｅ及び／又はＲＲＣ　Ｒｅｓｕｍｅが含まれる（詳細については更なる検討が必要である）。
　（１－ｃ）ＵＥはＲＲＣインアクティブにいる間、受信した設定を保存し、一部又はすべての設定を更新する必要がある場合は、ＵＥにそのような変更が通知され、更新された設定を取得するためにＲＲＣ接続のＲｅｓｕｍｅをトリガすることができる。ＲＲＣインアクティブでモビリティが発生した場合、セッションの設定が新しいセルで利用できない場合、ＵＥはＲＲＣ接続のＲｅｓｕｍｅをトリガする。
　Ｒｅｌ－１７の配信モード１では、ＰＴＭ設定はＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージによって提供されるため、ＵＥがＰＴＭ設定を受信するには常にコネクティッドになっている必要がある。コネクティッドへの遷移を回避するために、ＲＲＣ　Ｒｅｌｅａｓｅメッセージを使用して更新されたＰＴＭ設定を提供することが考えられる。この場合、ＵＥはＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔメッセージを送信し、ｇＮＢはＰＴＭ設定を含むＲＲＣ　Ｒｅｌｅａｓｅに応答する。そのため、ＵＥは更新されたＰＴＭ設定を提供されるためにコネクティッドに遷移する必要はない。このようなプロシージャは、セル再選択時（すなわち、ＰＴＭ設定が新しいセルで利用できない場合にＵＥが開始するプロシージャ）及びＲＡＮページング時（すなわち、ＰＴＭ設定を更新する必要がある場合にネットワークが開始するプロシージャ）に使用できる。
　提案１０：ＲＡＮ２は、ＰＴＭ設定を提供するためにＲＲＣ解放が強化されることに合意すべきである。
　考慮すべきもう１つの問題は、ＷＩＤに記載されているように、「シームレス／ロスレスモビリティは必要ない」という想定の下でのＵＥモビリティの影響である。ＲＡＮ２＃１１９ｂｉｓ－ｅは、以下の更なる検討が必要である事項に合意した。
　ＰＴＭ設定適用エリア、つまり、ＵＥがいったん取得したＰＴＭ設定が特定のエリア（つまり、単一セルではなくセルセット）に適用されるメカニズムを導入するかどうかについては更なる検討が必要な事項とする。
　Ｒｅｌ－１７では、配信モード１のＰＴＭ設定がＵＥを設定するセル内でのみ有効であることは明らかである。ハンドオーバが実行された場合、ターゲットセルはＵＥを新しいＰＴＭ設定に合わせて再設定する。一方、インアクティブ状態のＵＥがアイドル状態のモビリティを実行する場合、既存のＰＴＭ設定が再選択されたセル（すなわち、新しいセル）において有効でなくなったときの出発点と考えることができる。
　ＵＥがサービングセルからターゲットセルに引き渡されるか、又は再選択されたセルによって再設定されるようにするために、（例えば、セル再選択を実行する前又は後に）常にインアクティブＵＥがコネクティッドに遷移することを要求することが、仕様への影響を最小限に抑えた最も単純なソリューションとなり得る。
　より効率的な方法として、ＰＴＭ設定はＲＮＡ内で有効であるため、ｇＮＢは各ＵＥのＲＮＡ内で同じ設定を適用できるようにする必要がある。この方法の利点は、インアクティブ状態のＵＥが再設定する必要がなく、ＲＮＡ内でＭＴＣＨを受信し続けられることである。一方、ＲＮＡはＵＥ固有のものであるため、ネットワークがさらに複雑になる。
より柔軟で複雑でない方法は、ｇＮＢが設定内でセルリストを提供することで、リストに含まれるセル内で設定が有効であるとみなすことができる。セルリストは、セル固有、ＤＵ／ＣＵ関連、ＵＥセルリスト関連、ＭＲＢエリア固有、又はＭＢＳサービスエリア固有のいずれかに設定することができるが、これはＮＷの実装次第である。
そのため、ＲＡＮ２は、このような設定のエリアスコープを導入するかどうかを議論すべきである。
提案１１：ＲＡＮ２は、ＭＴＣＨを受信するための設定がサービングセルで有効か、エリア（ＲＮＡやセルリストなど）で有効かを議論すべきである。
　（９）付記３
１．導入
　ＭＢＳの強化（ｅＭＢＳ）に関するワークアイテムには、以下のように、ＭＢＳブロードキャスト及びユニキャストに対するＵＥの共有処理をサポートするという目的が含まれている：
　－ＵＥがＭＢＳブロードキャスト及びユニキャスト受信に共有処理を使用できるようにするためのＵｕシグナリングの拡張を規定する。すなわち、ＲＲＣコネクティッドにおけるユニキャスト受信と、同一又は異なる事業者からのＭＢＳブロードキャスト受信の同時受信に関するＵＥ能力及び関連するアシスタンス情報の報告を含む。
２．議論
２．１．ＬＴＥソリューションに基づく合意メカニズム
　ＲＡＮ２＃１１９ｂｉｓ－ｅは、ＬＴＥ　ＲＯＭソリューションに基づくいくつかの更なる検討が必要な事項と以下の合意を達成した。
　共有処理については、ベースラインとして以下を採用する：
　１）共有処理のためのＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎを送信できるかどうかを制御するために、システム情報に新しいＩＥが追加された；
　２）ＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎメッセージの内容と関連プロシージャが共有処理のために更新される。
　共有処理のＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎを送信できるかどうかを制御する新しいＩＥがＳＩＢ１に追加された。
　ＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎでは、ＵＥが受信中又は受信に関心がある放送サービスについて、少なくとも次の情報をシグナリングできる：放送周波数、サブキャリア間隔、及び帯域幅。詳細／正確なパラメータ及びその他の情報については更なる検討が必要である。ＵＥがどのシナリオでこの情報を報告するか（例：ＰＬＭＮ内の場合、ＰＬＭＮ間の場合）についても更なる検討が必要である。
　共有処理を可能にするためにＵＥの能力が必要かどうかを更なる検討が必要な事項で確認する。
　このソリューションでは、ｇＮＢは、ＵＥの処理能力がその能力を超えないという条件の下で、ＵＥにユニキャストリソースを割り当てることができる。処理能力はＰＬＭＮ内とＰＬＭＮ間で共通であると想定されるため、拡張ＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎ（ＭＩＩ）を報告すべきかどうかは、サービングセルが異なる周波数及び／又は異なるＰＬＭＮで提供されるＭＢＳブロードキャスト設定に関する知識を持っているかどうかに依存する。この意味で、ＳＩＢ１の新しいＩＥは、ＵＥが拡張ＭＩＩをＰＬＭＮ間の場合のみ報告すべきか、ＰＬＭＮ内の場合にも報告すべきかを示す必要がある。ＵＥは、（ＴＭＧＩから）サービングＰＬＭＮとＭＢＳ　ＰＬＭＮに違いがあるかどうかを確認し、ＳＩＢ１の指示に従う。そのため、ＲＡＮ２は、１ビットの通知で十分なのか（すなわち、拡張ＭＩＩのＯＮ／ＯＦＦの場合）、複数ビットの通知が必要なのか（すなわち、ＰＬＭＮ間及び／又はＰＬＭＮ内の場合）を議論すべきである。
　提案１：ＲＡＮ２は、ＳＩＢ１の新しいＩＥが、ＵＥが共有処理のために拡張ＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎを報告するのが、ＰＬＭＮ間の場合のみか、ＰＬＭＮ内の場合も制御すべきかどうかを議論すべきである。
　もう１つの更なる検討が必要な事項はＵＥ能力（ｃａｐａｂｉｌｉｔｙ）に関連するものである。共有処理が可能なＵＥだけが拡張ＭＩＩを送信できるため、ＵＥ能力シグナリングが不要であることは明らかであり、拡張ＭＩＩは暗黙の能力シグナリングと見なされる。そのため、ＲＡＮ２はＵＥ能力シグナリングの原則に合意すべきである。
　提案２：ＲＡＮ２は、共有処理にＵＥ能力シグナリングを必要としないことに合意すべきである。
２．２．ＲＦチェーンの共有
　第２．１節で合意されたメカニズムは、主にＵＥの処理能力を共有するためのものである。一方、ＵＥのＲＦチェーンをどのように共有するかについては、検討する価値がある。
２．２．１．時間領域におけるＲＦ共有のためのＭＢＳギャップ
２．２．１．１．ギャップ設定
　ＷＩＤの正当化部分では、ＵＥが別の事業者から関心のあるＭＢＳサービスを受信すること、つまり、ＰＬＭＮ間ＭＢＳ受信が明示されており、これにより、いくつかのキーワードが強調表示されている。
　Ｒｅｌ－１７　ＮＲ　ＭＢＳブロードキャストソリューションでは、ＵＥがダウンリンクのみでブロードキャストサービスを受信することができる。しかし、ブロードキャストの典型的なユースケースでは、ＵＥは、同じ事業者又は別の事業者のネットワークから、ブロードキャストサービスとユニキャストサービスを同時に受信する必要がある場合があり、一部のＵＥは、ブロードキャストとユニキャストの間でハードウェアリソースを共有する場合がある。したがって、この種のＵＥでは、ユニキャスト接続がブロードキャスト受信の影響を受ける可能性がある。このような場合の最適化は、Ｒｅｌ－１７では特に取り上げられておらず、ＲＲＣコネクティッドでのユニキャスト受信と、緊急放送や公共安全放送を含む、同一又は異なる事業者からの放送受信の場合に焦点を当てるべきである。
　共有処理の場合、ＵＥはＭＢＳブロードキャストとユニキャストに同じ受信機を使用することができる。前述のとおり、ＭＢＳサービスは異なる事業者によって提供されることがあり、そのため、異なる周波数で提供されることがある。１つの受信機が異なる周波数に使用される場合、ＵＥはＴＤＤ方式でＲＦチェーンをこれらの周波数にチューニングする必要がある。そのため、共有処理には、ＭＢＳ放送受信のための追加のギャップが必要となる。このギャップの間、ｇＮＢはユニキャスト用のＤＬ送信のスケジューリングを回避するため、ＵＥは別の周波数／オペレータで関心のあるＭＢＳ放送を受信することができる。これは、周波数間測定の測定ギャップ又はＰＬＭＮ間動作のＭＵＳＩＭギャップのいずれかと同様である。
　所見１：ＵＥは、ｇＮＢがユニキャストの送受信をスケジューリングしていない間、ＲＦチェーンをＭＢＳ周波数と異なる周波数にチューニングできる。
　ギャップについては、既存のＭＵＳＩＭのギャップがＭＢＳの受信に再利用できるかどうかが問題である。技術的には、ＭＢＳ受信のためにＭＵＳＩＭギャップを拡張することができる。しかし、現在の仕様では、ＭＵＳＩＭギャップは以下のようにＭＵＳＩＭの目的に限定されている。現在のＭＵＳＩＭギャップがＭＢＳのレセプションに使われることを意図していないのは明らかである。
　ＵＥが、セル識別及び測定、ページングモニタリング、ＳＩＢ取得、及び／又はターゲットネットワークのターゲットセルのオンデマンドＳＩ要求などのＭＵＳＩＭ目的のためにギャップパターンを必要とする場合、ネットワークは、ＭＵＳＩＭ－ＧａｐＣｏｎｆｉｇを介して、ＭＵＳＩＭのためのすべての周波数レイヤの同時モニタリングのために、１つ又は複数のＵＥごとのＭＵＳＩＭギャップパターンを提供することができる。
　また、同じギャップを異なる目的で使用する場合、不必要な複雑さを生むことが予想される。実際、ＭＵＳＩＭギャップは、Ｒｅｌ－１７で既存の測定ギャップとは別に導入された。したがって、ＭＵＳＩＭギャップとは異なる、周波数間／ＰＬＭＮ間ＭＢＳ受信に特化した追加ギャップを導入することが望ましい。
　提案３：ＲＡＮ２は、特にＲＲＣコネクティッドにおけるＭＢＳブロードキャストのＰＬＭＮ間受信のための追加ギャップ、すなわち「ＭＢＳギャップ」を導入することに合意すべきである。
２．２．１．２．ギャップアシスタンス情報
　提案３に合意する場合、ｇＮＢはＵＥにＭＢＳギャップを設定する必要があるが、ｇＮＢはＵＥがどのようなギャップパターンを必要とするかは不明である。そのため、ＵＥは必要なギャップの詳細をｇＮＢに通知するためにアシスタンス情報を送信する必要があり、これは本ＷＩの目的に意図されている。現在のネットワーク（すなわち、選択されたＰＬＭＮ）は、ＭＴＣＨスケジューリング情報など、異なる事業者のＭＢＳ放送設定の詳細を知らないため、特に関心のあるＭＢＳ放送が異なる事業者によって提供されている場合、このアシスタンス情報は有用であると考えられる。これは、ＵＡＩで導入されたＭＵＳＩＭアシスタンスに似ている。
　提案４：ＲＡＮ２は、特に関心のあるＭＢＳ放送が別のＰＬＭＮによって提供される場合、ＭＢＳギャップ設定にＵＥからの追加アシスタンス情報を導入することに合意すべきである。
　提案４が合意できるのであれば、どのようなアシスタンス情報が必要になるかを検討する価値がある。Ｒｅｌ－１７では、ＵＥはＴＭＧＩ、周波数、及びＭＢＳブロードキャストとユニキャストの優先度を含むＭＩＩをｇＮＢに通知できる。Ｒｅｌ－１８では、ＲＡＮ２がサブキャリア間隔や帯域幅などの追加情報を含む拡張ＭＩＩに合意した。同じ事業者が関心のあるＭＢＳ放送を提供する場合、ｇＮＢが異なる周波数で提供される特定のＴＭＧＩのＭＴＣＨスケジューリング情報を知っていれば、ＭＩＩはうまく機能する可能性がある。
　選択されたネットワークのｇＮＢは、異なるネットワークのＭＢＳブロードキャスト設定を知らないため、異なる事業者が目的のＭＢＳブロードキャストを提供する場合、ＵＥはｇＮＢにギャップパターンを提供する必要がある。ギャップパターンは異なるオペレータのＭＴＣＨスケジューリング情報に基づくべきであるが、参照は選択されたネットワークに基づくべきである。さらに、ＲＦチューニング時間も含めることができ、ギャップパターンをどのように設定するかはＵＥの実装に任される。
　提案５：特に、ＰＬＭＮ間ＭＢＳ受信では、ＲＡＮ２はＵＥがｇＮＢにギャップパターンを要求することに合意する必要があり、これによって、ギャップパターンは異なるＰＬＭＮのＲＦ調整時間とＭＴＣＨスケジューリング期間をカバーすることができる。
２．２．２．ＲＦ共有のためのＳＣｅｌｌの設定解除／インアクティブ化
　ＲＡＮ２＃１１９ｅでは、ギャップメカニズムがネットワーク的に複雑であるとの意見があった。この場合、ＭＢＳのギャップとそれに対応するアシスタンス情報を許可するかどうかは、ネットワークの実装次第である。ただし、ＵＥの受信機がすべてサービングネットワークのユニキャスト転送に使用されている場合、ＵＥが別のネットワークからＭＢＳサービスを受信する方法については、まだ根本的な問題が残っている（たとえば、キャリアアグリゲーション設定でＵＥが目的のＭＢＳサービスを受信できない場合など）。
　ＵＥがその受信機の１つをＭＢＳの受信に使用できるようにする簡単な方法の１つは、ｇＮＢがＵＥで現在アクティブになっているＳＣｅｌｌの１つを設定解除又はインアクティブにすることである。しかし、ｇＮＢは、ＵＥがＳＣｅｌｌの設定解除／インアクティブ化を好むかどうか／いつＳＣｅｌｌの設定解除／インアクティブ化を好むかを知らない可能性があるため、上記のＭＢＳギャップに加えて、ＭＢＳ受信のためのＳＣｅｌｌの設定解除／インアクティブ化の追加アシスタンス情報が有用かどうかを議論する価値がある。もし有用であると認識された場合、現在のＭＩＩの内容、すなわち周波数と優先順位がこの目的のために機能するかどうか議論されるべきである。
　提案６：ＲＡＮ２はさらに、異なるＰＬＭＮからのＭＢＳ受信のために、ＵＥがＳＣｅｌｌの再設定又はインアクティブ化に関する優先順位をｇＮＢに通知することが許可されるかどうかを議論すべきである。
１　　　　　　：移動通信システム
１０　　　　　：ＲＡＮ
２０　　　　　：ＣＮ
１００　　　　：ＵＥ（ユーザ装置）
１１０　　　　：受信部
１２０　　　　：送信部
１３０　　　　：制御部
２００　　　　：ｇＮＢ（基地局）
２１０　　　　：送信部
２２０　　　　：受信部
２３０　　　　：制御部
２４０　　　　：バックホール通信部

Claims (4)

  1. 　マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
    　デディケイテッドシグナリングによりネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うことと、
    　前記マルチキャスト設定の更新が必要であると判定したことに応じて、前記更新のために前記ネットワークへのアクセスを行うことを決定することと、
    　前記アクセスを規制するためのアクセス制御を適用するか又はスキップするかを、前記ネットワークからの設定情報に基づいて判定することと、を有する
    　通信方法。
  2. 　前記設定情報を前記ネットワークから受信することをさらに有し、
    　前記設定情報は、前記更新のみの目的で前記アクセスを行うときに前記アクセス制御をスキップすることを前記ユーザ装置に許可するか否かを設定するための情報である
    　請求項１に記載の通信方法。
  3. 　マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
    　ネットワークから受信したマルチキャスト設定に基づいて、無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うことと、
    　前記ＲＲＣインアクティブ状態において、前記マルチキャスト設定を送信したセルが属する周波数をセル再選択の最高優先度とみなすことと、を有する
    　通信方法。
  4. 　マルチキャスト／ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
    　周波数を指定する指定情報を含むデディケイテッドシグナリングをネットワークから受信することと、
    　無線リソース制御（ＲＲＣ）インアクティブ状態においてマルチキャスト受信を行うことと、
    　前記ＲＲＣインアクティブ状態において、前記ユーザ装置が決定した周波数をセル再選択の最高優先度とみなす処理を適用せずに、前記指定情報に基づいて前記セル再選択の周波数優先度を決定することと、を有する
    　通信方法。
PCT/JP2023/039401 2022-11-02 2023-11-01 通信方法 WO2024096048A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263421765P 2022-11-02 2022-11-02
US63/421,765 2022-11-02

Publications (1)

Publication Number Publication Date
WO2024096048A1 true WO2024096048A1 (ja) 2024-05-10

Family

ID=90930615

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/039401 WO2024096048A1 (ja) 2022-11-02 2023-11-01 通信方法

Country Status (1)

Country Link
WO (1) WO2024096048A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022028539A1 (zh) * 2020-08-06 2022-02-10 维沃移动通信有限公司 信息传输方法、装置、终端及网络侧设备

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022028539A1 (zh) * 2020-08-06 2022-02-10 维沃移动通信有限公司 信息传输方法、装置、终端及网络侧设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CATT: "Report of [Post119-e][610][eMBS] PTM configuration for INACTIVE (CATT)", 3GPP DRAFT; R2-2210068, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Electronic meeting; 20221010 - 20221019, 30 September 2022 (2022-09-30), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052263391 *
OPPO: "Discussion on multicast reception in RRC_INACTIVE state", 3GPP DRAFT; R2-2209513, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Electronic; 20221010 - 20221019, 30 September 2022 (2022-09-30), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052262842 *

Similar Documents

Publication Publication Date Title
US11197259B2 (en) Coordination of simultaneous multi-RAT camping
US9843919B2 (en) Mobile communication system, user terminal, and base station
US11134535B2 (en) Radio terminal and base station
JP6965324B2 (ja) 無線端末
JP6633779B2 (ja) 無線端末、プロセッサ、及び方法
KR20130019732A (ko) Ｍｂｍｓ 서비스에 관한 제어정보의 전송 장치 및 방법
JP2024059904A (ja) 通信制御方法、ユーザ装置、チップセット、プログラム、基地局及びシステム
EP3179805A1 (en) User terminal
JPWO2018084194A1 (ja) 無線端末及び基地局
WO2022199702A1 (en) Bwp operation for nr multicast and broadcast services
WO2021184418A1 (zh) 多连接管理方法及相关产品
WO2024096048A1 (ja) 通信方法
WO2024162427A1 (ja) 通信方法
WO2024162425A1 (ja) 通信方法
WO2024071245A1 (ja) 通信方法
WO2024096049A1 (ja) 通信方法及びネットワーク装置
WO2024071156A1 (ja) 通信方法
WO2024213015A1 (en) Wireless communication method
WO2024034569A1 (ja) 通信方法
WO2024071157A1 (ja) 通信方法
WO2024034567A1 (ja) 通信方法
WO2024034566A1 (ja) 通信方法
WO2024210086A1 (ja) 通信方法及びユーザ装置
JP7508634B2 (ja) 通信制御方法、基地局、ユーザ装置及びプロセッサ
WO2024067863A1 (en) Network energy saving method, and related devices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23885802

Country of ref document: EP

Kind code of ref document: A1