WO2023013608A1 - 通信方法 - Google Patents

通信方法 Download PDF

Info

Publication number
WO2023013608A1
WO2023013608A1 PCT/JP2022/029552 JP2022029552W WO2023013608A1 WO 2023013608 A1 WO2023013608 A1 WO 2023013608A1 JP 2022029552 W JP2022029552 W JP 2022029552W WO 2023013608 A1 WO2023013608 A1 WO 2023013608A1
Authority
WO
WIPO (PCT)
Prior art keywords
mbs
rnti
mcch
mtch
session
Prior art date
Application number
PCT/JP2022/029552
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 京セラ株式会社
Priority to JP2023540347A priority Critical patent/JPWO2023013608A5/ja
Publication of WO2023013608A1 publication Critical patent/WO2023013608A1/ja
Priority to US18/431,737 priority patent/US20240179722A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H04W72/232—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal the control data signalling from the physical layer, e.g. DCI signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • 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
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services

Definitions

  • the present disclosure relates to a communication method used in a mobile communication system.
  • a communication method is a communication method used in a user equipment that performs reception processing of a physical downlink control channel (PDCCH) from a base station using a radio network temporary identifier (RNTI),
  • RNTI radio network temporary identifier
  • N ⁇ 2 group RNTIs G-RNTIs
  • M ⁇ M multicast broadcast service
  • a communication method is a communication method used in a user equipment that performs reception processing of a physical downlink control channel (PDCCH) from a base station using a radio network temporary identifier (RNTI), wherein the cell RNTI ( C-RNTI) for receiving a Dedicated Traffic Channel (DTCH); and Group RNTI (G-RNTI) for receiving a Multicast Traffic Channel (MTCH).
  • RNTI radio network temporary identifier
  • C-RNTI cell RNTI
  • G-RNTI Group RNTI
  • MTCH Multicast Traffic Channel
  • a communication method is a communication method used in a mobile communication system, wherein a base station transmits setting information used for receiving a multicast traffic channel (MTCH) on a multicast control channel (MCCH). and the base station transmitting a notification about the content change of the MCCH to the user equipment on a physical downlink control channel (PDCCH) at a predetermined timing.
  • the sending includes, if there is no change, sending the notification indicating that there is no change.
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to a first embodiment; FIG. It is a figure which shows the structure of UE (user apparatus) based on 1st Embodiment.
  • FIG. 2 is a diagram showing the configuration of a gNB (base station) according to the first embodiment; FIG. 2 is a diagram showing the configuration of a protocol stack of a user plane radio interface that handles data; FIG. 2 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals); 1 is a diagram showing an outline of MBS traffic distribution according to the first embodiment; FIG. It is a figure which shows the delivery mode which concerns on 1st Embodiment.
  • FIG. 2 shows a split multicast radio bearer (MRB) according to the first embodiment
  • FIG. 4 is a diagram showing a correspondence relationship (mapping) between group RNTIs (G-RNTIs) and MBS sessions
  • FIG. 2 is a diagram showing the correspondence (mapping) between G-RNTIs, multicast radio bearers (MRBs)/multicast traffic channels (MTCHs), quality of service (QoS) flows, and MBS sessions
  • MBS sessions multicast radio bearers
  • MBS sessions multicast traffic channels
  • QoS quality of service
  • FIG. 10 is a diagram showing internal processing of a UE according to the second embodiment
  • FIG. 10 is a diagram showing internal processing of a UE according to a modification of the second embodiment; It is a figure which shows an example of the operation
  • Figure 4 shows an overview of aspects of the stage 2 control plane in delivery mode;
  • FIG. 10 is a diagram showing one-step setting in delivery mode 2;
  • Fig. 2 shows MBMS interest indication for LTE (excluding ROM related settings); It is a figure which shows the content of SIB13 of LTE. It is a figure which shows the content of SIB13 of LTE. It is a figure which shows the content of SIB13 of LTE. It is a figure which shows the content of SIB13 of LTE.
  • FIG. 2 is a diagram showing the contents of SC-MCCH in LTE;
  • FIG. 2 is a diagram showing the contents of SC-MCCH in LTE;
  • FIG. 2 is a diagram showing the contents of SC-MCCH in LTE;
  • FIG. 4 is a diagram showing the content of MBMS interest indication in LTE;
  • FIG. 4 is a diagram showing the content of MBMS interest indication in LTE;
  • FIG. 4 is a diagram showing the content of MBMS interest indication in LTE;
  • FIG. 4 is a diagram showing the content of MBMS interest indication in LTE;
  • FIG. 3 shows cell reselection priorities for eMBMS frequencies in LTE;
  • Figure 3 shows cell-level prioritization in intra-frequency and intra-frequency cell reselection of equal priority in LTE for NB-IoT in CE (including eMTC) and UE;
  • FIG. 10 illustrates an example in which QoffsetSCPTM is set as SCPTM frequency offset in SIB5;
  • FIG. 10 is a diagram showing a UE function scptm-ParallelReception-r13 in LTE SC-PTM;
  • FIG. 2 illustrates DRX parameters for PTM transmission via delivery mode 1;
  • FIG. 2 shows DRX parameters for PTM transmission via delivery mode 2;
  • 5G/NR multicast broadcast services will provide improved services over 4G/LTE multicast broadcast services.
  • the present disclosure provides a communication method that enables improved multicast broadcast services.
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to the first embodiment.
  • the mobile communication system 1 complies with the 3GPP standard 5th generation system (5GS: 5th Generation System).
  • 5GS will be described below as an example, an LTE (Long Term Evolution) system may be at least partially applied to the mobile communication system.
  • 6G systems may be applied at least partially in mobile communication systems.
  • the mobile communication system 1 includes a user equipment (UE: User Equipment) 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 below.
  • the 5GC 20 is sometimes simply referred to as a core network (CN) 20 .
  • CN core network
  • the UE 100 is a mobile wireless communication device.
  • the UE 100 may be any device as long as it is used by a user.
  • the UE 100 may be a mobile phone terminal (including a smartphone) 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 the vehicle (Vehicle UE ), an aircraft or a device (Aerial UE) provided on the aircraft.
  • the NG-RAN 10 includes a base station (called “gNB” in the 5G system) 200.
  • the gNBs 200 are interconnected via an Xn interface, which is an interface between base stations.
  • the gNB 200 manages one or more cells.
  • the gNB 200 performs radio communication with the UE 100 that has established connection with its own cell.
  • the gNB 200 has a radio resource management (RRM) function, a user data (hereinafter simply referred to as “data”) routing function, a measurement control function for mobility control/scheduling, and the like.
  • RRM radio resource management
  • a “cell” is used as a term indicating the minimum unit of a wireless communication area.
  • a “cell” is also used as a term indicating a function or resource for radio communication with the UE 100 .
  • One cell belongs to one carrier frequency (hereinafter simply called "frequency").
  • the gNB can also be connected to the EPC (Evolved Packet Core), which is the LTE core network.
  • EPC Evolved Packet Core
  • LTE base stations can also connect to 5GC.
  • An LTE base station and a gNB may also be connected via an inter-base station interface.
  • FIG. 2 is a diagram showing the configuration of the UE 100 (user equipment) according to the first embodiment.
  • UE 100 includes a receiver 110 , a transmitter 120 and a controller 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 receiver 110 includes an antenna and a receiver.
  • the receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal (received signal) to control section 130 .
  • the transmission unit 120 performs various transmissions under the control of the control unit 130.
  • the transmitter 120 includes an antenna and a transmitter.
  • the transmitter converts a baseband signal (transmission signal) output from the control unit 130 into a radio signal and transmits the radio signal from an antenna.
  • Control unit 130 performs various controls and processes in the UE 100. Such processing includes processing of each layer, which will be described later.
  • Control unit 130 includes at least one processor and at least one memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU (Central Processing Unit).
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • FIG. 3 is a diagram showing the configuration of the gNB 200 (base station) according to the first embodiment.
  • the gNB 200 comprises a transmitter 210 , a receiver 220 , a controller 230 and a backhaul communicator 240 .
  • the transmitting unit 210 and the receiving unit 220 constitute a radio communication unit that performs radio communication with the UE 100 .
  • the backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20 .
  • the transmission unit 210 performs various transmissions under the control of the control unit 230.
  • Transmitter 210 includes an antenna and a transmitter.
  • the transmitter converts a baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits the radio signal from an antenna.
  • Control unit 230 performs various controls and processes in the gNB200. Such processing includes processing of each layer, which will be described later.
  • Control unit 230 includes at least one processor and at least one memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the backhaul communication unit 240 is connected to adjacent base stations via the Xn interface, which is an interface between base stations.
  • the backhaul communication unit 240 is connected to the AMF/UPF 300 via the NG interface, which is the base station-core network interface.
  • the gNB 200 may be composed of a CU (Central Unit) and a DU (Distributed Unit) (that is, functionally divided), and the two units may be connected by an F1 interface, which is a fronthaul interface.
  • FIG. 4 is a diagram showing the configuration of the protocol stack of the radio interface of the user plane that handles data.
  • the MAC layer performs data priority control, retransmission processing by hybrid ARQ (HARQ: Hybrid Automatic Repeat reQuest), random access procedures, and the like. Data and control information are transmitted between the MAC layer of the UE 100 and the MAC layer of the gNB 200 via transport channels.
  • the MAC layer of gNB 200 includes a scheduler. The scheduler determines uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS: Modulation and Coding Scheme)) and resource blocks to be allocated to UE 100 .
  • 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 the UE 100 and the RLC layer of the gNB 200 via logical channels.
  • the SDAP layer maps IP flows, which are units for QoS (Quality of Service) control by the core network, and radio bearers, which are units for QoS control by AS (Access Stratum). Note that SDAP may not be present when the RAN is connected to the EPC.
  • FIG. 5 is a diagram showing the protocol stack configuration of the radio interface of the control plane that handles signaling (control signals).
  • the radio interface protocol stack 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 FIG.
  • RRC Radio Resource Control
  • NAS Non-Access Stratum
  • RRC signaling for various settings is transmitted between the RRC layer of the UE 100 and the RRC layer of the gNB 200.
  • the RRC layer controls logical, transport and physical channels according to establishment, re-establishment and release of radio bearers.
  • RRC connection connection between the RRC of UE 100 and the RRC of gNB 200
  • UE 100 is in the RRC connected state.
  • RRC connection no connection between RRC of UE 100 and RRC of gNB 200
  • UE 100 is in RRC idle state.
  • UE 100 is in RRC inactive state.
  • the NAS layer located above the RRC layer performs session management and mobility management.
  • NAS signaling is transmitted between the NAS layer of UE 100 and the NAS layer of AMF 300A.
  • the UE 100 has an application layer and the like in addition to the radio interface protocol.
  • a layer lower than the NAS layer is called an AS layer.
  • MBS is a service that enables data transmission from the NG-RAN 10 to the UE 100 via broadcast or multicast, that is, point-to-multipoint (PTM).
  • MBS use cases include public safety communications, mission critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet Protocol TeleVision), group communication, and software distribution. .
  • a broadcast service provides service to all UEs 100 within a specific service area for applications that do not require highly reliable QoS.
  • An MBS session used for broadcast services is called a broadcast session.
  • a multicast service provides a service not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session).
  • An MBS session used for a multicast service is called a multicast session.
  • a multicast service can provide the same content to a group of UEs 100 in a more wirelessly efficient manner than a broadcast service.
  • FIG. 6 is a diagram showing an overview of MBS traffic distribution according to the first embodiment.
  • MBS traffic (MBS data) is delivered from a single data source (application service provider) to multiple UEs.
  • a 5G CN (5GC) 20 which is a 5G core network, receives MBS data from an application service provider, creates a copy of the MBS data (Replication), and distributes it.
  • 5GC20 From the perspective of 5GC20, two multicast delivery methods are possible: 5GC Shared MBS Traffic delivery and 5GC Individual MBS Traffic delivery.
  • the 5GC 20 receives single copies of MBS data packets and delivers individual copies of those MBS data packets to individual UEs 100 via per-UE 100 PDU sessions. Therefore, one PDU session per UE 100 needs to be associated with the multicast session.
  • the 5GC 20 receives a single copy of MBS data packets and delivers the single copy of those MBS packets to the RAN nodes (ie gNB 200).
  • a gNB 200 receives MBS data packets over an MBS tunnel connection and delivers them to one or more UEs 100 .
  • PTP Point-to-Point
  • PTM Point-to-Multipoint
  • the gNB 200 delivers individual copies of MBS data packets to individual UEs 100 over the air.
  • the gNB 200 delivers a single copy of MBS data packets to a group of UEs 100 over the air.
  • the gNB 200 can dynamically determine which of PTM and PTP to use as the MBS data delivery method for one UE 100 .
  • the PTP and PTM delivery methods are primarily concerned with the user plane. There are two distribution modes, a first distribution mode and a second distribution mode, as MBS data distribution control modes.
  • FIG. 7 is a diagram showing distribution modes according to the first embodiment.
  • the first delivery mode (delivery mode 1: DM1) is a delivery mode that can be used by UE 100 in the RRC connected state, and is a delivery mode for high QoS requirements.
  • the first delivery mode is used for multicast sessions among MBS sessions. However, the first delivery mode may be used for broadcast sessions.
  • the first delivery mode may also be available for UEs 100 in RRC idle state or RRC inactive state.
  • MBS reception settings in the first delivery mode are done by UE-dedicated signaling.
  • MBS reception settings in the first distribution mode are performed by an RRC Reconfiguration message (or RRC Release message), which is an RRC message unicast from the gNB 200 to the UE 100 .
  • the MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") regarding the configuration of MBS traffic channels that carry MBS data.
  • MTCH configuration information includes MBS session information for an MBS session and scheduling information for MBS traffic channels corresponding to this MBS session.
  • the MBS traffic channel scheduling information may include a discontinuous reception (DRX) configuration of the MBS traffic channel.
  • DRX discontinuous reception
  • the MBS traffic channel is a kind of logical channel and is sometimes called MTCH.
  • the MBS traffic channel is mapped to a downlink shared channel (DL-SCH), which is a type of transport channel.
  • DL-SCH downlink shared channel
  • the second delivery mode (Delivery mode 2: DM2) is a delivery mode that can be used not only by the UE 100 in the RRC connected state but also by the UE 100 in the RRC idle state or RRC inactive state, and is a delivery mode for low QoS requirements. is.
  • the second delivery mode is used for broadcast sessions among MBS sessions. However, the second delivery mode may also be applicable to multicast sessions.
  • the setting for MBS reception in the second delivery mode is performed by broadcast signaling.
  • the configuration of MBS reception in the second delivery mode is done via logical channels broadcasted from the gNB 200 to the UE 100, eg, Broadcast Control Channel (BCCH) and/or Multicast Control Channel (MCCH).
  • the UE 100 can receive the BCCH and MCCH using, for example, a dedicated RNTI predefined in technical specifications.
  • the RNTI for BCCH reception may be SI-RNTI
  • the RNTI for MCCH reception may be MCCH-RNTI.
  • the UE 100 may receive MBS data in the following three procedures. First, UE 100 receives MCCH configuration information from gNB 200 by SIB (MBS-SIB) transmitted on BCCH. Second, UE 100 receives MCCH from gNB 200 based on MCCH configuration information. MCCH carries MTCH configuration information. Third, the UE 100 receives MTCH (MBS data) based on MTCH setting information. In the following, MTCH configuration information and/or MCCH configuration information may be referred to as MBS reception configuration.
  • SIB SIB
  • An MBS session consists of a TMGI (Temporary Mobile Group Identity), a source-specific IP multicast address (consisting of a source unicast IP address such as an application function or application server, and an IP multicast address indicating a destination address), a session identifier, and G- Identified by at least one of the RNTIs. At least one of TMGI, source-specific IP multicast address, and session identifier is called MBS session identifier. TMGI, source-specific IP multicast address, session identifier, and G-RNTI are collectively referred to as MBS session information.
  • the gNB 200 can configure the UE 100 with MRBs separated into the PTP communication path and the PTM communication path. This allows the gNB 200 to dynamically switch transmission of MBS data to the UE 100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB 200 can double transmit the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path) to increase reliability.
  • a PTP communication path is called a PTP leg and a PTM communication path is called a PTM leg.
  • a functional unit corresponding to each layer is called an entity.
  • the predetermined layer that terminates the split is the MAC layer (HARQ), RLC layer, PDCP layer, or SDAP layer.
  • HARQ MAC layer
  • RLC layer PDCP layer
  • SDAP layer SDAP layer.
  • Each of the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 separates the MRB, which is a bearer (data radio bearer) used for MBS, into a PTP leg and a PTM leg.
  • a PDCP entity is provided for each bearer.
  • Each of gNB 200 and UE 100 has two RLC entities, one MAC entity, and one PHY entity provided for each leg.
  • a PHY entity may be provided for each leg.
  • the UE 100 may have two MAC entities.
  • the PHY entity uses a cell RNTI (C-RNTI: Cell Radio Network Temporary Identifier) assigned to UE 100 on a one-to-one basis to transmit and receive PTP leg data.
  • C-RNTI Cell Radio Network Temporary Identifier
  • PHY entities transmit and receive data on PTM legs using G-RNTIs assigned on a one-to-one basis with MBS sessions.
  • the C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UEs 100 that receive one MBS session.
  • the split MRB is set from the gNB 200 to the UE 100 and the PTP leg is activated. be.
  • gNB 200 cannot perform PTP transmission of MBS data using this PTP leg when the PTP leg is in an inactive state even if split MRB is configured in UE 100 .
  • the UE 100 monitors the PDCCH to which the G-RNTI associated with the MBS session is applied (that is, performs blind decoding of the PDCCH using the G-RNTI). UE 100 may monitor the PDCCH only at scheduling opportunities for the MBS session.
  • the UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied while the PTM leg is deactivated (that is, does not perform blind decoding of the PDCCH using the G-RNTI). .
  • the UE 100 monitors the PDCCH to which the C-RNTI is applied while the PTP leg is activated.
  • DRX Discontinuous Reception
  • UE 100 monitors PDCCH during the set On Duration.
  • UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.
  • the UE 100 may monitor the PDCCH to which the C-RNTI is applied in preparation for normal unicast downlink transmission other than MBS data while the PTP leg is deactivated. However, when a cell (frequency) associated with an MBS session is designated, UE 100 may not monitor the PDCCH for the MBS session.
  • the split MRB as described above is set by an RRC message (for example, an RRC Reconfiguration message) transmitted from the RRC entity of gNB200 to the RRC entity of UE100.
  • RRC message for example, an RRC Reconfiguration message
  • FIG. 9 is a diagram showing the correspondence (mapping) between group RNTIs (G-RNTIs) and MBS sessions.
  • the G-RNTI may be a G-CS (Configured Scheduling)-RNTI.
  • G-RNTI may be read as G-CS-RNTI.
  • two G-RNTIs may consist of one G-RNTI and one G-CS-RNTI.
  • the G-CS-RNTI is a G-RNTI used for Configured Scheduling that allocates the same radio resource at regular intervals. - the radio resources specified in the RNTI are allocated;
  • the mapping between the G-RNTI and the MBS session includes "1:1 mapping” in which one G-RNTI and one MBS session are associated, and one G-RNTI and N (N ⁇ 2) MBSs.
  • N:1 mapping is used.
  • FIG. 10 is a diagram showing the correspondence (mapping) between G-RNTIs, multicast radio bearers (MRBs)/multicast traffic channels (MTCHs), quality of service (QoS) flows, and MBS sessions.
  • MBS multicast radio bearers
  • MTCH multicast traffic channels
  • QoS quality of service
  • MBS sessions There are cases where multiple QoS flows are associated with one MBS session, and multiple QoS flows are associated with one G-RNTI.
  • QoS flows and MRB/MTCH may have a 1:1 relationship.
  • N 1 mapping
  • MBS data with different settings for each QoS flow e.g., different MTCH settings for each QoS flow
  • QoS flow #1 is for video
  • QoS flow #2 is for text message (chat).
  • it is considered optimal to transmit and receive data with the following settings, for example.
  • RLC UM means that the RLC mode is unacknowledged mode (UM)
  • RLC AM is the RLC mode. is in acknowledgment mode (AM).
  • a DRX cycle means a period in which the UE 100 wakes up in discontinuous reception.
  • the first embodiment is an embodiment that makes it possible to receive only some QoS flows out of multiple QoS flows associated with one MBS session.
  • the communication method according to the first embodiment is a method used by UE 100 that performs PDCCH reception processing (hereinafter referred to as "PDCCH reception processing") from gNB 200 using a radio network temporary identifier (RNTI).
  • RNTI radio network temporary identifier
  • the PDCCH reception process is a process in which the UE 100 performs blind decoding of the PDCCH (DCI) using the RNTI and performs a CRC check using the CRC parity bits assigned to the DCI, and monitors the PDCCH. It may also be called processing.
  • the timing at which UE 100 wakes up may be determined by MTCH settings associated with M G-RNTIs used for PDCCH reception processing. That is, UE 100 does not need to apply MTCH settings associated with (NM) G-RNTIs, and therefore does not need to wake up according to the MTCH settings. Thereby, the power consumption of the UE 100 is reduced.
  • UE 100 identifies a desired QoS flow that it desires to receive from among K (K ⁇ 2) QoS flows associated with one MBS session, and M G-RNTIs may be identified.
  • a desired QoS flow may be determined by higher layers of the UE 100, such as the application layer and/or the NAS layer.
  • UE 100 may receive information (mapping information) that associates one MBS session, K QoS flows, and N G-RNTIs from gNB 200 . This allows the UE 100 to clearly (specifically) grasp the correspondence (mapping) between the MBS session, the QoS flow, and the G-RNTI.
  • mapping information information that associates one MBS session, K QoS flows, and N G-RNTIs from gNB 200 . This allows the UE 100 to clearly (specifically) grasp the correspondence (mapping) between the MBS session, the QoS flow, and the G-RNTI.
  • FIG. 11 is a diagram showing an example of operations according to the first embodiment.
  • the RRC state of UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state).
  • the mode of MBS distribution may be the first distribution mode or the second distribution mode.
  • gNB200 transmits mapping information of MBS sessions, QoS flows, and G-RNTIs to UE100.
  • the gNB 200 may transmit mapping information via broadcast signaling (SIB or MCCH) or via UE-specific signaling (RRC Reconfiguration message or RRC Release message).
  • the mapping information may include one or more sets of MBS session identifiers, QoS flow identifiers and G-RNTIs.
  • the mapping information may be notified from AMF 300A to UE 100 using a NAS message.
  • step S102 the UE 100 is receiving or interested in receiving an MBS session. Note that step S101 may be performed after step S102.
  • step S103 the UE 100 identifies a desired QoS flow that the UE 100 wishes to receive from among K (K ⁇ 2) QoS flows associated with the MBS session.
  • the desired QoS flow may be one QoS flow or multiple QoS flows.
  • the upper layers (application layer, etc.) of the UE 100 may notify the AS layer of the required QoS flow identifier in the MBS session. For example, the upper layer notifies the AS layer that in the video conference application, video streaming (QoS flow #1) is used and is necessary, but the chat function (QoS flow #2) is turned off and is not necessary. may
  • the UE 100 sends an MBS Interest Information message containing the identifier of the MBS session (the MBS session that the UE 100 is receiving or is interested in receiving) and the identifier of the desired QoS flow belonging to the MBS session to the gNB 205.
  • the identifier for the desired QoS flow is, for example, an identifier for the desired QoS flow, an identifier for a QoS flow other than the desired QoS flow among K QoS flows, or a G-RNTI associated with the desired QoS flow.
  • the MBS interest information message is a type of RRC message, and may be, for example, an MBS Interest Indication message or a UE Assistance Information message.
  • the gNB 200 that has received the MBS information-of-interest message stops transmission of QoS flows that the UE 100 does not want, or changes settings in the UE 100 (for example, , deletion of QoS flow settings that the UE 100 does not desire, etc.). Note that step S105 may be performed before step S104.
  • step S106 the UE 100 performs PDCCH reception processing using the M G-RNTIs identified in step S104. Thereby, the UE 100 acquires the scheduling information of the PDSCH to which the MTCH is mapped from the DCI.
  • step S107 the UE 100 receives MBS data from the gNB 200 on PDSCH.
  • FIG. 12 is a diagram showing internal processing of the UE 100 according to the second embodiment.
  • the PHY layer of the UE 100 processes user data (received data) received on the PDSCH, which is one of the physical channels, and sends it to the downlink shared channel (DL-SCH), which is one of the transport channels.
  • the MAC layer of the UE 100 processes the data received on the DL-SCH, based on the logical channel identifier (LCID) included in the header (MAC header) included in the received data, the received data to the corresponding logical channel ( corresponding RLC entity).
  • LCID logical channel identifier
  • logical channels for user data include a dedicated traffic channel (DTCH) and a multicast traffic channel (MTCH).
  • DTCH is a logical channel for unicast and MTCH is a logical channel for multicast/broadcast.
  • the assignment of LCIDs for each logical channel may be done by gNB 200 .
  • DTCH may be a multicast/broadcast PTP logical channel
  • MTCH may be a multicast/broadcast PTM logical channel.
  • the MAC layer can stream received data to an appropriate logical channel based on the LCID included in the MAC header.
  • the LCID space is not divided between DTCH and MTCH.
  • the second embodiment is an embodiment that allows received data to flow to an appropriate logical channel even if the same LCID is assigned to DTCH and MTCH.
  • the same LCID can be assigned to DTCH and MTCH, so that the finite number of LCIDs can be effectively used.
  • DTCH and MTCH originally required two independent LCIDs, one common LCID can be assigned. Also, the complexity caused by independently assigning and managing LCIDs for DTCH and MTCH can be avoided.
  • the communication method according to the second embodiment is a method used by UE 100 that performs PDCCH reception processing from gNB 200 using RNTI.
  • the communication method includes a step of performing PDCCH reception processing for receiving DTCH using cell RNTI (C-RNTI), and a step of performing PDCCH reception processing for receiving MTCH using G-RNTI. , when the same LCID is assigned to the DTCH and MTCH, identifying a logical channel to which received data obtained according to the PDCCH reception process belongs based on the RNTI used for the PDCCH reception process. .
  • the MAC layer of the UE 100 obtains according to the PDCCH reception process using the C-RNTI when the LCID included in the header of the MAC PDU that is the received data is the same LCID for DTCH and MTCH.
  • DTCH is specified as the logical channel to which the received data belongs.
  • MTCH is specified as a logical channel to which received data obtained according to PDCCH reception processing using G-RNTI belongs. Then, the MAC layer of UE 100 outputs received data (MAC SDU/RLC PDU) to the specified logical channel.
  • the UE 100 receives information that associates the data radio bearer (DRB) with the LCID of the DTCH and information that associates the multicast radio bearer (MRB) with the LCID of the MTCH from the gNB 200. good.
  • DRB data radio bearer
  • MRB multicast radio bearer
  • FIG. 13 is a diagram showing an example of operations according to the second embodiment.
  • the RRC state of UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state).
  • the RRC state of UE 100 may be the RRC connected state.
  • the mode of MBS distribution is the first distribution mode or the second distribution mode.
  • the mode of MBS distribution may be the first distribution mode.
  • step S201 the gNB 200 notifies the UE 100 of mapping information for the DTCH LCID and the MTCH LCID.
  • the gNB 200 transmits to the UE 100 information that associates DRB #1 with DTCH LCID #1 and information that associates MRB #2 with MTCH LCID #1. That is, in this operation example, the same LCID may be associated with DTCH and MTCH.
  • the UE 100 may perform the following operations.
  • the UE 100 may perform unicast reception for DTCH LCID#1 using C-RNTI. Specifically, the UE 100 may perform DTCH reception by performing PDCCH reception processing using C-RNTI.
  • step S205 the UE 100 receives user data on the PDSCH.
  • the user data received on PDSCH according to step S203 may be unicast data
  • the user data received on PDSCH according to step S204 may be MBS data (multicast data or broadcast data). .
  • step S208 the UE 100 (MAC layer) transfers the packet (MAC PDU) to the logical channel indicated by the LCID included in the header of the packet. flow.
  • the UE 100 acquires MTCH setting information by receiving MCCH from the gNB 200, and receives MTCH (MBS data) based on the MTCH setting information.
  • the content of MCCH can be changed.
  • the period during which the content of the MCCH is maintained may be called the MCCH modification period.
  • a predetermined timing at which the content of the MCCH can be changed may be called an MCCH modification boundary.
  • the load and power consumption increase. leads to Therefore, it is assumed that the notification regarding the content change of MCCH is transmitted from gNB 200 to UE 100 on PDCCH (in DCI) at a predetermined timing. As a result, the UE 100 can determine whether or not it is necessary to receive the MCCH, and can suppress unnecessary MCCH reception.
  • Such MCCH change notification may be sent based on MCCH content change, eg, MBS session start, MBS session change, or MBS session stop.
  • the MCCH change notification may be configured as one bit in the DCI, ie a one bit flag that is set to "1" only when there is a change.
  • the gNB 200 transmits setting information (MTCH setting information) used for MTCH reception on the MCCH, and the gNB 200 changes the content of the MCCH (hereinafter referred to as “MCCH change”). ) (hereinafter referred to as “MCCH notification”) to the UE 100 on a physical downlink control channel (PDCCH) at a predetermined timing.
  • the transmitting step includes, if there is no MCCH change, transmitting an MCCH notification indicating no MCCH change. In this way, when there is no MCCH change, the UE 100 can clearly grasp that there is no MCCH change by transmitting an MCCH notification indicating that there is no MCCH change. Therefore, UE 100 that does not receive an MCCH notification at a predetermined timing can determine that it is caused by a PDCCH (DCI) transmission error. Therefore, it is possible to suppress unnecessary MCCH reception by the UE 100 .
  • DCI PDCCH
  • the gNB 200 transmits a first value indicating that there is an MCCH change as the MCCH notification. If there is no MCCH change, gNB 200 sends a second value as MCCH notification indicating no MCCH change. This allows the UE 100 to clearly grasp whether or not the MCCH is changed.
  • the UE 100 may attempt to receive the MCCH.
  • the UE 100 may omit receiving the MCCH when receiving the second value on the PDCCH.
  • the UE 100 may try to receive the MCCH if it fails to receive the MCCH notification on the PDCCH at a predetermined timing.
  • FIG. 15 is a diagram showing an example of operations according to the third embodiment.
  • the RRC state of UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state).
  • the mode of MBS distribution may be the second distribution mode.
  • the UE 100 is receiving or interested in receiving an MBS session.
  • the gNB 200 performs MCCH notification transmission processing.
  • the MCCH notification is configured using certain bits of DCI.
  • the MCCH notification based on MBS session start and the MCCH notification based on MBS session change/stop may be notified using the same bit or different bits.
  • the MCCH notification may be performed using a different bit for each MBS session, or using a common bit for all sessions (only one bit).
  • the (each) bit that constitutes the MCCH notification may be defined as 'no change' when '0' and 'changed' when '1'.
  • the (each) bit that constitutes the MCCH notification may have the 0/1 relationship reversed.
  • the gNB 200 sends MCCH notifications regardless of whether there is an MCCH change.
  • step S304 the gNB 200 transmits a second value (for example, "0") indicating that there is no MCCH change as an MCCH notification at a predetermined timing. do.
  • a second value for example, "0"
  • the UE 100 attempts to receive an MCCH notification (DCI) at a predetermined timing (MCCH change boundary).
  • DCI MCCH notification
  • step S305 when the UE 100 normally receives the MCCH notification and the received MCCH notification is the second value (step S305: YES), the UE 100 does not attempt to receive the MCCH (PDSCH).
  • MCCH (PDSCH) reception is attempted (step S306).
  • the UE 100 fails to receive the MCCH notification normally, the UE 100 attempts to receive the MCCH (PDSCH) (step S306).
  • UE 100 attempts to receive PDCCH (DCI) that transmits scheduling information for MCCH (PDSCH).
  • DCI PDCCH
  • the DCI that constitutes the MCCH notification may be scrambled with a dedicated RNTI (eg SC-N-RNTI), and the DCI for MCCH may be scrambled with a dedicated RNTI (eg SC-RNTI).
  • RNTIs may be fixed RNTIs defined in technical specifications.
  • the UE 100 checks the received MCCH, and if there is a change, applies the content (setting) of the MCCH.
  • the presence or absence of MCCH change is indicated by a bit value, but the presence or absence of MCCH change may be indicated by the value of RNTI.
  • the value of the bit may be a fixed value regardless of the presence or absence of MCCH change.
  • steps S303', S304', and S305' of FIG. It may be defined as 'changed' if the MCCH notification was sent in .
  • Each of the operation flows described above can be implemented in combination of two or more operation flows without being limited to being implemented independently. For example, some steps of one operational flow may be added to another operational flow. Some steps of one operation flow may be replaced with some steps of another operation flow.
  • the base station may be an NR base station (gNB) or a 6G base station.
  • the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node.
  • IAB Integrated Access and Backhaul
  • a base station may be a DU of an IAB node.
  • the user equipment may be an MT (Mobile Termination) of an IAB node.
  • references to elements using the "first,” “second,” etc. designations used in this disclosure do not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • RAN2 has agreed to two delivery modes. That is, distribution mode 1 for multicast sessions received by UEs in the connected state and distribution mode 2 for broadcast sessions received by all UEs in the RRC state.
  • RAN2 also agreed on the details of the MCCH scheduling method: MCCH repetition period, MCCH transmission window, search space, and MCCH change period.
  • RAN2#114-e has reached the following agreement on two distribution modes.
  • Use PCCH for multicast enablement notifications (also for MBS support nodes). Check that the MBS session ID is conveyed in the notification. The use of paging in all (legacy) POs using PRNTI is a baseline assumption (other changes can be discussed). MBS-specific SIBs are defined to perform MCCH setup. The content of MCCH should include information about the broadcast session such as G-RNTI, MBS session ID, and scheduling information of MTCH (search space, DRX, etc.). L1 parameters that need to be included in the MCCH are pending further RAN1 progression and input. Defer discussion on whether dedicated MCCH configuration is required until RAN1 progresses on MCCH BWP/CFR.
  • Indication of MCCH changes due to changes in the configuration of an ongoing session is provided by explicit signaling from the network (RAN1 may add a bit for this purpose in addition to the session start signaling bit). ) can be accommodated in the MCCH change notification DCI). Further consideration is needed as to whether this notification can be reused to change other information held by the MCCH. Further consideration is needed as to whether the possibility of a UE missing an MCCH change notification needs to be addressed or can be left to the UE implementation. At least, if RAN1 decides to utilize an RNTI other than MCCH-RNTI for MCCH change notification, MCCH change notification is sent at the first MCCH monitoring opportunity of each MCCH repetition period. Supports single MCCH.
  • Appendix 1 provides details of the control plane aspects of delivery mode 2, considering the baseline of the LTE eMBMS mechanism.
  • NR MBS (4. Multicast session connected via delivery mode 2)
  • NR MBS is expected to support various types of use cases as quoted from the WID below.
  • NR MBS must be well-designed for a variety of requirements, from delay-sensitive applications such as mission-critical and V2X to delay-tolerant applications such as IoT.
  • delay-sensitive applications such as mission-critical and V2X
  • delay-tolerant applications such as IoT.
  • IoT delay-tolerant applications
  • Objective A of SA2 SI is about enabling general MBS services over 5GS, and use cases identified that could benefit from this feature include public safety, mission critical, V2X applications, transparent IPv4/IPv6 multicast distribution, IPTV, and software distribution via wireless, group communication, IoT applications are included.
  • LTE eMBMS may deliver multicast sessions, which can be considered a baseline for NR MBS. In this sense, it is beneficial for gNBs to be able to choose to use delivery mode 2 for multicast sessions. This issue needs further study from RAN2#112-e to RAN2#114-e, but in general there is no technical reason to limit it.
  • RAN2 will prioritize active multicast support in RRC connected mode for Rel-17, and if time permits, multicast support in RRC inactive state (connected mode multicast solution and broadcast solution will become more mature. agreed that it can be discussed later”, but since the agreement was made in the context of delivery mode 1, it does not preclude multicast sessions with delivery mode 2 for connected UEs.
  • Proposal 1 RAN2 should agree that, in addition to broadcast sessions, delivery mode 2 can be used at least for multicast sessions of UEs in RRC Connected state.
  • RAN2 agreed to "defer discussion on whether dedicated MCCH configuration is required until RAN1 progresses with BWP/CFR on MCCH".
  • a dedicated MCCH is expected to be provided, eg by RRC reconfiguration, if supported.
  • Dedicated MCCH is provided by RRC reconfiguration. In other words, it can be interpreted that it is not a broadcast-based method.
  • a dedicated MCCH can be considered from the perspective of broadcast service continuity.
  • RAN2 has already agreed that "it is assumed that the LTE SC-PTM mechanism of the connected UE can be reused to receive the PTM setup for NR MBS delivery mode 2, ie a broadcast-based method". This assumption is for intra-cell setup, but not for inter-cell service continuity, ie handover.
  • RAN2 agreed MCCH is provided in a broadcast-based manner for intra-cell setup, but not for inter-cell service continuity.
  • the UE In LTE SC-PTM, it is assumed that the UE somehow acquires the SIB20 and MCCH of the target cell before, during, or even after handover. This may be considered the baseline for NR MBS delivery mode 2. However, it does mean that there is a risk of service disruption, as the UE may miss or delay acquiring the MCCH of the neighboring cell, for example, if it is busy. Therefore, it's worth discussing a more reliable solution.
  • the target cell's MCCH at least the target MTCH scheduling information, needs to be provided by the RRC reconfiguration using synchronization, ie handover command. This solution ensures service continuity after handover.
  • Proposal 2 RAN2 should agree that the target cell's MCCH, at least the target MTCH scheduling information, is provided during the handover procedure. That is, it is provided by RRC reconfiguration using synchronization to ensure inter-cell service continuity for UEs in RRC Connected state.
  • RAN2 agrees to introduce MCCH change notifications upon session start, session change and stop, whereby settings related to MTCH reception (e.g. MBS session information and MTCH scheduling information) are changed. It is the current intention that the MCCH change notification is sent when RAN2 left "Whether this notification can be re-used to change other information held by MCCH needs further study.”
  • Another information can be interpreted as neighbor cell/frequency information, which is discussed in the following section. If the UE misses neighbor cell/frequency information, it is not a critical issue when the UE stays on the serving cell. However, the latest neighbor cell/frequency information is important information in case of inter-cell mobility for UEs in idle/inactive state and UEs in RRC Connected state if Proposal 5 is not agreed. In this sense, for more reliable service continuity, if RAN2 agrees that neighboring cell/frequency information is provided by MCCH, it will also send MCCH change notification when other information is changed. There is a need to.
  • Proposal 3 RAN2 should agree to send MCCH change notifications when any of the MCCH contents are changed. That is, in addition to MBS session information and MTCH scheduling information, it also applies to "other information" which is at least neighboring frequency/cell information (if agreed to be provided by MCCH).
  • RAN2 left "Whether the possibility of UE missing MCCH change notifications needs to be addressed or left to the UE implementation needs further consideration.” According to the agreement, MCCH change notification is expected to be provided in DCI, but details are up to RAN1.
  • RAN2 Further consideration is not only related to session change/stop, but also session initiation, and has never been recognized as a problem with LTE eMBMS. Furthermore, whether the problem actually exists may depend on the DCI design of RAN1. For example, an MCCH change notification may be sent even if the MCCH has not changed. For example, a DCI bit can be '0' to indicate 'no change' and '1' to indicate 'change', so that the UE can tell if it missed an MCCH change. May notify without additional power consumption and take some action for recovery. Therefore, it is unclear at this time whether RAN2 should discuss the need for further consideration.
  • On-demand MCCH A new paradigm for NR is the support for on-demand SI transmission. This concept can be reused for delivery mode 2 MCCH, ie on-demand MCCH. For example, MCCH for delay tolerant services is provided on demand, thus optimizing signaling resource consumption. Of course, the network has other options, namely to provide MCCH periodically rather than on demand, such as for delay sensitive services.
  • Proposal 4 RAN2 should agree to be able to provide MCCH on demand.
  • SIB provides MTCH scheduling information directly, ie without MCCH. It provides delay tolerant services and optimizations for power sensitive UEs. For example, a UE may request SIBs (on demand) and a gNB may start providing SIBs and corresponding services after requests from multiple UEs. These UEs do not need to monitor the repeatedly broadcast MCCH.
  • Proposal 5 RAN2 should agree that multicast reception without MCCH is supported (that is, one-step configuration). For example, the SIB directly provides MTCH scheduling information.
  • LTE eMBMS In LTE eMBMS, neither MII nor counting can collect information from idle UEs, even if most of the UEs are in RRC idle and receiving broadcast services. This is one of the remaining issues of LTE eMBMS in terms of session control and resource efficiency.
  • the same problem can occur with idle/inactive UEs, ie delivery mode 2 of broadcast sessions.
  • the network does not know if idle/inactive UEs are not receiving/interested in broadcast services. Therefore, the network may continue to provide PTM transmissions even if there are no UEs receiving service. If the gNB knows the benefits of idle/inactive UEs, it should avoid such unnecessary PTM transmissions. Conversely, if PTM goes down while there are still idle/inactive UEs receiving service, many UEs may send connection requests at the same time, which is also undesirable.
  • Proposal 6 RAN2 should discuss whether MBS counting is introduced and whether it is also collected from idle/inactive UEs.
  • SIB13, SIB15, SIB20, SC-MCCH, MBMS Interest Indication IEs, and the cell reselection procedure in LTE can be considered the baseline for the NR MBS Stage 3 specification.
  • RAN2 agreed that "MBS-specific SIBs are defined to perform MCCH setup". Regarding MCCH configuration, RAN2 has already agreed that "MCCH transmission window is defined by MCCH repetition period, MCCH window period and radio frame/slot offset" and "Modification period is defined for NR MCCH”. are doing. These parameters are the same as in SIB20, i.e. SC-MCCH-repetition period, SC-MCCH-first subframe, SC-MCCH-period, SC-MCCH-offset and SC-MCCH-change period respectively. be. Therefore, these parameter ranges can be easily reused to minimize standardization effort.
  • MBS-specific SIBs provide information on whether a UE needs to be connected to obtain MBS services.
  • Proposal 8 RAN2 should discuss whether MBS-specific SIBs provide information for associating MBS services with their delivery modes.
  • RAN2 has agreed to introduce the MBS Interest Indication that is supposed to be used in broadcast sessions. At least from the AS point of view, it is up to the network whether the MBS service is offered as a multicast session or a broadcast session. Furthermore, from the UE's point of view, it is unknown whether the gNB can obtain information about the MBS service that the UE is interested in, which may be provided by AMF for multicast sessions, but for broadcast sessions isn't it. As a result, the UE cannot know whether it needs to send an MBS Interest Indication for the MBS service it is interested in. Therefore, it would be helpful for the UE if the gNB provided information on whether MBS Interest Indication is allowed for each MBS service. In other words, which MBS services require an MBS Interest Indication. Therefore, RAN2 needs to discuss whether such additional information is required.
  • Proposal 9 RAN2 should discuss whether MBS-specific SIBs provide information on whether MBS Interest Indications can be sent to each MBS service.
  • RAN2 agreed that the content of MCCH should include information about broadcast sessions such as G-RNTI, MBS session ID, and schedule information of MTCH (search space, DRX, etc.). Certain L1 parameters are pending RAN1 progress and input", and "Defer discussion of whether dedicated MCCH configuration is required until RAN1 progresses with MCCH BWP/CFR".
  • Proposal 11 RAN2 has the same value range for each parameter of MTCH scheduling information (that is, On Duration Timer, Inactivity Timer, Scheduling Period, and Start Offset) as those parameters in LTE SC-PTM, that is, SC-PTM configuration must agree that
  • RAN2 needs to agree on a cell/frequency list on which the MBS service will be broadcast. Since the UE needs to know on which cell/frequency the MBS service of interest is provided, the neighbor cell/frequency information should be associated with the MBS session ID (eg TMGI). For example, the cell/frequency list further associated with SAI such as LTE eMBMS needs further consideration and whether it is broadcast via MBS specific SIB or MCCH also needs further consideration.
  • MBS session ID eg TMGI
  • Proposal 12 RAN2 should agree that the neighbor cell/frequency list associated with the MBS session ID (such as TMGI) is broadcast for service continuity. Whether it is further associated with SAI and provided on MBS-specific SIB or MCCH needs further consideration.
  • MBS session ID such as TMGI
  • RAN2 agreed to "assume that MBS indication of interest is supported by UEs in connected mode for broadcast services", but the exact content has not yet been discussed.
  • the MBMS interest indication includes three IEs (shown in Figure 19), excluding ROM-related settings. This assistance information helps to ensure continuity of services such as gNB scheduling and handover decisions. Since the characteristics of SC-PTM and delivery mode 2 are very similar, the same information is considered useful for NR MBS.
  • Proposal 13 RAN2 should agree that the MBS Indication of Interest includes the frequency list, the priority between MBS reception and unicast, and the MBS service list, similar to the MBMS Indication of Interest in LTE.
  • the MBS Interest Indication should also include a list of cells providing MBS services of interest to the UE.
  • gNB provides neighbor cell information, so MBMS service means such cell, assuming that gNB knows which neighbor cell provides which MBS service.
  • Proposition 9 is acceptable, the same assumptions apply to NR MBS. Therefore, RAN2 needs to confirm the gNB.
  • Proposal 14 RAN2 should make sure that if the MBS service list is included in the MBS Interest Indication, it means the cell that provides the MBS service of interest for the UE, i.e. the gNB is a neighboring cell We assume that we know the MBS service offered.
  • MBMS priority is used to indicate whether the UE prioritizes MBMS reception over unicast reception, which is useful for gNB scheduling, for example, and can be reused in NR MBS.
  • NR MBS has two delivery modes, namely delivery mode 1 using C-RNTI and delivery mode 2 using G-RNTI, which are based on different scheduling algorithms for MTCH transmission. Therefore, if a UE is interested in multiple MBS services offered via different delivery modes, it may be helpful for the UE to provide priority between delivery mode 1 reception and delivery mode 2 reception. Other examples may also be considered, such as UE power save settings, which will be discussed where appropriate. Therefore, RAN2 should first discuss whether additional information for advanced purposes is provided by the MBS Interest Indication.
  • Proposal 15 RAN2 should discuss whether additional information is provided by the MBS Indication of Interest, e.g. the priority between delivery mode 1 reception and delivery mode 2 reception.
  • MBS Interest Indication is a new/separate message or integrated with the UE Assistance Information message.
  • MII MBMS Interest Indication
  • UAI UE Assistance Information
  • IDC In-device Coexistence Indication
  • MBS-specific SIB or MCCH neighboring cell/frequency information as in Proposition 9. It is also expected that the MBS Interest Indication is set in the MBS specific SIB, the same SIB (or MCCH) as in LTE eMBMS. Therefore, it is inconsistent with the preconditions of UAI, ie RRC reconfiguration. Therefore, the MBS Interest Indication needs to be a separate message from the UAI, like LTE eMBMS.
  • Proposal 16 RAN2 should agree to define MBS Interest Indication as a new message, ie separate from UE Assistance Information.
  • Proposal 17 RAN2 should agree that if the UE is able to obtain the MBS-specific SIB from the serving cell (that is, as a precondition), it is allowed to transmit the MBS Indication of Interest.
  • RAN2 assumes that MBS Indication of Interest is supported in broadcast sessions, but not in multicast sessions.
  • the core network informs the gNB of the UE's interest, since there are higher layer session join procedures in the multicast session.
  • Proposal 10 and Figure 18 it applies to the UE's interested MBS service.
  • Proposal 11 can be agreed, it is clear that the gNB knows the MBS frequency and the cell providing the UE's interested MBS service.
  • the priority between MBS reception and unicast is similar to LTE's MBMS priority, which is purely AS-related information, i.e., the UE sends the core network the priority information in the session joining procedure. It's weird to advertise, so it may not be provided by the core network.
  • the core network provides the UE's interested gNBs such as MBS services, the gNB knows the MBS frequency/cell, but the core network and the gNB are the UE's AS between MBS and unicast You may not know your priorities.
  • Priority information is still considered useful for gNBs, for example, for scheduling and handover decisions as well as for LTE eMBMS, which is also relevant for service continuity. Therefore, the UE needs to notify the gNB of priority information for multicast sessions as well. In this sense, RAN2 has to agree that it needs to support MBS Interest Indication even in multicast service/delivery mode 1.
  • Proposal 18 RAN2 needs to agree that MBS interest indication is also supported in multicast session/delivery mode 1, at least for the UE to inform the gNB of the priority between MBS reception and unicast .
  • the so-called "highest priority rule" is applied to handle cell reselection priority.
  • the UE can regard frequencies that provide MBMS services of interest as a top priority.
  • the UE may consider frequencies that do not provide MBMS services of interest as lowest priority.
  • the UE can reselect the cell serving the MBMS service of interest, thereby ensuring continuity of service.
  • the UE can also consider frequencies not providing the targeted MBMS service as the lowest priority, which is applicable for inter-frequency cell reselection.
  • the R criteria i.e. ranking
  • SC-PTM specific offsets which can be set to "infinity”. This mimics the "highest priority rule" for each cell. This is because ⁇ the defined ranking is applied to intra-frequency and inter-frequency cell reselection (regardless of the configured frequency priority), so the UE is in extended coverage'', that is, the conventional Inter-frequency cell reselection is not applicable for CE NB-IoT and UE.
  • NB-IoT UEs and CE UEs apply SC-PTM-specific offsets (which may be "infinite") to the R reference. This is applicable for intra-frequency and same-priority inter-frequency cell reselection.
  • inter-frequency cell reselection ie frequency-based
  • intra-frequency and equal priority inter-frequency reselection ie cell-based
  • RAN2 must agree to introduce a "top priority rule” to NR MBS.
  • a “lowest priority rule” such as Observation 5 should also be introduced.
  • Proposal 19 RAN2 should agree that, similar to LTE, the frequencies on which the UE provides the targeted MBS service may be viewed as a top priority.
  • Proposal 20 RAN2 should agree that, similar to LTE, frequencies on which the UE does not provide the intended MBS service may be considered lowest priority.
  • the R-based SC-PTM-specific offset is worth taking into account that the minimum coverage of NR MBS is considered a cell, but is still the preferred deployment scenario in Rel-17, namely , frequency-based or cell-based.
  • Frequency-based deployments where the same MBS service is provided between cells on frequencies within a particular MBS service area, are a subset of cell-based deployments. That is, the MBS service can be represented by a list of cells on a frequency, so that the MBS service is only provided in a cell, so that the list contains all cells on the frequency. Therefore, if MBS services are provided on a cell-by-cell basis, there is more flexibility to support different deployment scenarios.
  • the SC-PTM specific offset was introduced for multicast support in Rel-14 eMTC/NB-IoT, i.e. no inter-frequency cell reselection at the CE, but a specific can be used to prioritize cells in Provide interesting MBMS services. Therefore, the same mechanism can be reused to prioritize cells providing MBS services of interest to the UE, thereby reducing standardization efforts.
  • Proposal 21 RAN2 should agree that MBS-specific offsets can be applied to the R criteria to prioritize specific cells serving MBS services of interest to the UE, thereby: As in LTE, the offset can be set to "infinity".
  • FIG. 23 shows the contents of SIB15 of LTE.
  • FIG. 24 shows the contents of the LTE SIB 20 .
  • LTE SC-MCCH The contents of the LTE SC-MCCH are shown in FIGS. 25-27.
  • FIG. 33 shows an example in which QoffsetSCPTM is set as SCPTM frequency offset in SIB5.
  • one G-RNTI/G-CS-RNTI multiplexes multiple MBS sessions.
  • G-RNTI#1 carries TMGI#1 and TMGI#2. Flexibility is gained from the NW point of view as some MBS sessions requiring similar QoS may be transmitted in one G-RNTI. It has also been pointed out that 1:N mapping may reduce UE complexity if the UE is interested in receiving multiple MBS sessions simultaneously. However, it is not clear whether such optimization is really necessary.
  • RAN2 already receives multiple MCPTT sessions etc. at the same time as "UE can support multiple G-RNTI/G-CS-RNTI. Whether this depends on UE capabilities needs further study" A needing UE only supports such functionality (if defined).
  • 1:N mapping is inefficient for retransmissions, eg if only one TMGI receives a NACK and the other TMGI receives an ACK, the entire transport block needs to be retransmitted.
  • a UE that is only interested in TMGI#1 still needs to receive data from TMGI#2, so it is not optimal in terms of UE power consumption. That is, it is necessary to decode a larger PDSCH than expected.
  • multiple G-RNTI/G-CS-RNTI carry one MBS session.
  • TMGI#1 can be considered split into G-RNTI#1 and G-RNTI#2.
  • RAN2 has agreed that "multiple MBS QoS flows corresponding to the same MBS session may be mapped to one or more MBS radio bearers". This may assume that these QoS flows require different QoS, for example one QoS flow for video streaming and another QoS flow for text transfer within the same MBS session. and so on. Therefore, it makes sense for these QoS flows to be sent on different G-RNTIs, eg with different periodicities and resource amounts. Since the UE only needs to monitor the G-RNTIs associated with the MBS session (and QoS flow) of interest, a significant increase in UE power consumption is not expected.
  • N 1 mapping of G-RNTI/G-CS-RNTI to MBS sessions is efficient for different QoS flows with different QoS requirements and less impact on UE power consumption there is a possibility.
  • FIG. 9 shows UE functions of multiple G-RNTI/G-CS-RNTI.
  • NR MBS For NR MBS, similar UE capabilities can be used as a baseline, but there are still many open issues and NR-specific enhancements under discussion, such as the use of BWP/CFR (Common Frequency Resource). Therefore, it is premature to discuss aspects of UE functionality at this time.
  • BWP/CFR Common Frequency Resource
  • the MCCH and MTCH can share the same LCID (that is, "00000"), but different MTCHs are assigned different LCIDs ("00001-11100").
  • “MTCH and MCCH can be multiplexed on the same MCH”
  • “Multiple MBMS services can be mapped on the same MCH”, i.e. 1:N mapping as in remark 11, so to distinguish between MCCH and different MTCH A different LCID is required.
  • the MCCH/MTCH is mapped to the MCH and the DTCH is mapped to the DL-SCH, thus separating the MCCH/MTCH LCID space from the unicast LCID space. It is useful to avoid colliding LCIDs in MBSFN (ie MBMS area-specific and common to a group of UEs) with the same LCID in unicast (ie cell-specific and UE-specific).
  • each MTCH has a different LCID (up to 32 due to 1:N mapping), the MCCH's LCID may not be shared with the MTCH unless the MCH has no MCCH, and the MCCH/MTCH The LCID space is separated from one for DTCH.
  • SC-MCCH In LTE SC-PTM, the same LCID ("11001") is shared by SC-MCCH, SC-MTCH, and multiple SC-MTCHs.
  • SC-MCCH is transmitted on SC-RNTI
  • SC-MCCH and SC-MTCH transmissions are each indicated by a logical channel-specific RNTI on PDCCH (used for reception of DL-SCH to which SC-MTCH is mapped
  • TMGI logical channel-specific RNTI
  • G-RNTI G-RNTI
  • the UE can distinguish these logical channels by either the agreed new RNTI of MCCH or the G-RNTI of MTCH, regardless of the LCID, so the LCID of MCCH and MTCH are different logical Can be shared in channels.
  • RAN2 agreed that "multiple MBS QoS flows corresponding to the same MBS session can be mapped to one or more MBS radio bearers". This allows us to simply assume that each MRB is associated with a separate LCH, as shown in FIG. Therefore, even if a 1:1 mapping between G-RNTI/G-CS-RNTI and MBS sessions is adopted, the UE cannot distinguish between MTCHs belonging to the same MBS session. That is, the same G-RNTI/G-CS-RNTI can carry multiple MTCHs associated with the same MBS session. Therefore, the concept of one LCID shared by multiple MTCHs like LTE SC-PTM cannot be applied to NR MBS, and multiple LCIDs are required for MTCH like LTE MBSFN.
  • the method of defining LCID for MTCH is also related to whether to maintain the principle of 1:1 mapping between G-RNTI/G-CS-RNTI and MBS sessions.
  • 1:1 mapping the UE can learn each MBS session from the corresponding G-RNTI. Therefore, LCIDs can be grouped per MBS session (or G-RNTI) so that the number of LCIDs equals the number of MTCHs belonging to the same MBS session. For example, three LCIDs regardless of the number of MBS sessions as shown in FIG.
  • N:1 mapping the UE can also learn each MBS session from the corresponding G-RNTI. Therefore, the number of LCIDs equals the number of MTCHs mapped to the same G-RNTI.
  • the number of LCIDs in MTCH is related to the mapping rule (1:1, N:1, or 1:N) from G-RNTI/G-CS-RNTI to MBS session.
  • each MTCH should be assigned a different LCID. This means defining the maximum number of LCIDs for MTCH. At this point, according to the aforementioned LTE MBSFN, the maximum number of such can be considered to be 32, although a smaller number may be desirable.
  • Proposal 2 RAN2 should discuss the maximum number of LCIDs for MTCH. For example, a possible baseline is less than 32 LCID based on LTE MBSFN.
  • RAN2 should agree that MCCH and MTCH may share the same LCID in order to avoid unnecessary consumption of LCIDs.
  • Proposal 3 RAN2 should agree that MCCH and MTCH may share the same LCID. That is, the UE distinguishes the MCCH by the agreed new RNTI and the MTCH by the G-RNTI, but each MTCH is distinguished by the corresponding LCID.
  • the remaining issue is whether the MBS LCID space should be common to or separate from the unicast LCID space. Assuming 32 LCIDs as in Proposal 2, eLCIDs may be allowed to consume such codepoints dedicated to MBS due to the large space of eLCIDs. That is, 256 in 1 octet eLCID for predominantly MAC CE and 65,536 in 2 octet eLCID for predominantly DTCH. However, provision of such a separate LCID space is questionable as the actual benefits are unknown. From the MAC perspective of the UE, after receiving and demultiplexing the MAC PDUs, each MAC SDU is sent to the corresponding RLC entity.
  • MCCH/MTCH is cell
  • LCID space for MBS is beneficial because LCID for MBS needs to be coordinated among multiple cells/gNBs. That is, the LCID is MBS area specific, common to all UEs, and there is a potential risk of conflict with the DTCH's LCID (cell specific and UE specific). Therefore, it needs to be discussed whether a separate LCID space is reserved for MCCH/MTCH in this release, just for future extensions of MBS.
  • Proposal 4 RAN2 should discuss whether the MCCH and MTCH LCID spaces are separate from the DTCH LCID space for future assurance (such as supporting single frequency networks).
  • RAN2 agreed to "reuse DTCH for PTP transmission of NR MBS". Therefore, we believe that LCIDs for PTP transmissions are not part of recognized RAN2 which requires further consideration. So it is very natural to share the same LCID space with unicast. However, it may be useful for RAN2 to confirm the intent of the agreement.
  • Proposal 5 RAN2 should ensure that the DTCH for PTP transmission shares the LCID space with the DTCH for unicast. So, at least from MAC point of view, PTP transmission is the same as conventional unicast.
  • RAN2 states “multiplexing/demultiplexing of different logical channels associated with the same G-RNTI is supported in NR MBS” and “multiplexing/demultiplexing of different logical channels associated with C-RNTI is supported by NR MBS”. RAN2 left "Whether multiplexing/demultiplexing of different logical channels associated with the same G-CS-RNTI is supported in NR MBS needs further study.”
  • DRX is set per G-RNTI be done.
  • the UE wakes up on PTM transmission opportunities (on periods) and monitors the associated G-RNTI. Therefore, RAN2 needs to agree that DRX configuration is provided per G-RNTI independent of unicast DRX.
  • Proposal 7 RAN2 should agree that PTM DRX is independent of unicast DRX and is set for each G-RNTI.
  • MTCH reception in delivery mode 1 is basically performed by UEs in RRC connected state, and its characteristics are similar to DTCH, i.e. unicast, in order to support dynamic scheduling, HARQ feedback/retransmission, etc. Therefore, it makes sense to reuse the unicast DRX parameters, ie the DRX configuration.
  • Proposal 8 RAN2 should agree that the DRX parameters for PTM transmissions via delivery mode 1 should be the one for unicast, ie the DRX setting should be used as a baseline.
  • Proposal 9 In addition to Proposal 8 (i.e. Unicast DRX as baseline for PTM transmission over delivery mode 1), RAN2 agrees that parameters related to UL retransmissions and short DRX are unnecessary There is a need.
  • DRX parameters for delivery mode 2 RAN2 agreed that "for NR MBS delivery mode 2, the LTE SC-PTM DRX scheme is used as a baseline".
  • DRX parameters for LTE SC-PTM are shown in FIG. This is basically the same as in Fig. 35/proposal 30 (ie for PTM transmission over delivery mode 1) for parameters related to DL retransmissions. If parameters related to unnecessary DL retransmissions are excluded in delivery mode 2, the on-duration timer, inactivity timer, scheduling period and starting offset can be reused without major problems.
  • RAN2 left "In the case of PTP transmission, whether to reuse the DRX operation of unicast transmission needs further consideration".
  • RAN2 has already agreed that "multiplexing/demultiplexing of different logical channels associated with C-RNTI is supported in NR MBS". It is not restricted to different logical channels belonging to MBS services. That is, it may be (de-)multiplexed with a unicast service.
  • RAN2 agreed that "DTCH is reused for PTP transmission of NR MBS". This means that MAC does not need to know whether each MAC SDU for DTCH belongs to DRB or MRB.
  • PTP transmissions are transmitted using the same C-RNTI as existing unicast transmissions. In this sense, PTP transmission is exactly the same and consistent with unicast transmission, at least from the perspective of DRX operation.
  • RAN 20 CN 100: UE 110: Reception unit 120: Transmission unit 130: Control unit 200: gNB 210: Transmission unit 220: Reception unit 230: Control unit 240: Backhaul communication unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

第１の態様に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、Ｎ個（Ｎ≧２）のグループＲＮＴＩ（Ｇ－ＲＮＴＩ）が１つのマルチキャストブロードキャストサービス（ＭＢＳ）セッションと対応付けられている場合、前記Ｎ個のＧ－ＲＮＴＩの中から前記受信処理に用いるＭ個（Ｍ≦Ｎ）のＧ－ＲＮＴＩを特定することと、前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことと、を有する。

Description

通信方法
　本開示は、移動通信システムで用いる通信方法に関する。
　３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）規格において、第５世代（５Ｇ）の無線アクセス技術であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）の技術仕様が規定されている。ＮＲは、第４世代（４Ｇ）の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。３ＧＰＰにおいて、５Ｇ／ＮＲのマルチキャストブロードキャストサービス（ＭＢＳ）の技術仕様を策定する議論が行われている（例えば、非特許文献１参照）。
　第１の態様に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、Ｎ個（Ｎ≧２）のグループＲＮＴＩ（Ｇ－ＲＮＴＩ）が１つのマルチキャストブロードキャストサービス（ＭＢＳ）セッションと対応付けられている場合、前記Ｎ個のＧ－ＲＮＴＩの中から前記受信処理に用いるＭ個（Ｍ≦Ｎ）のＧ－ＲＮＴＩを特定することと、前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことと、を有する。
　第２の態様に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いて、専用トラフィックチャネル（ＤＴＣＨ）を受信するための前記受信処理を行うことと、グループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いて、マルチキャストトラフィックチャネル（ＭＴＣＨ）を受信するための前記受信処理を行うことと、前記ＤＴＣＨ及び前記ＭＴＣＨに同一の論理チャネル識別子（ＬＣＩＤ）が割り当てられている場合、前記受信処理に応じて得られた受信データが属する論理チャネルを、当該受信処理に用いたＲＮＴＩに基づいて特定することと、を有する。
　第３の態様に係る通信方法は、移動通信システムで用いる通信方法であって、基地局が、マルチキャストトラフィックチャネル（ＭＴＣＨ）の受信に用いる設定情報をマルチキャスト制御チャネル（ＭＣＣＨ）上で送信することと、前記基地局が、前記ＭＣＣＨの内容変更に関する通知を、所定タイミングにおいて物理下りリンク制御チャネル（ＰＤＣＣＨ）上でユーザ装置に送信することと、を有する。前記送信することは、前記変更が無い場合、前記変更が無いことを示す前記通知を送信することを含む。
第１実施形態に係る移動通信システムの構成を示す図である。 第１実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 第１実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 第１実施形態に係るＭＢＳトラフィック配信の概要を示す図である。 第１実施形態に係る配信モードを示す図である。 第１実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。 グループＲＮＴＩ（Ｇ－ＲＮＴＩ）とＭＢＳセッションとの対応関係（マッピング）を示す図である。 Ｇ－ＲＮＴＩと、マルチキャスト無線ベアラ（ＭＲＢ）／マルチキャストトラフィックチャネル（ＭＴＣＨ）と、サービス品質（ＱｏＳ）フローと、ＭＢＳセッションとの対応関係（マッピング）を示す図である。 第１実施形態に係る動作の一例を示す図である。 第２実施形態に係るＵＥの内部処理を示す図である。 第２実施形態に係る動作の一例を示す図である。 第２実施形態の変更例に係るＵＥの内部処理を示す図である。 第３実施形態に係る動作の一例を示す図である。 第３実施形態に係る動作の変更例を示す図である。 配信モードのステージ２コントロールプレーンの側面の概要を示す図である。 配信モード２のワンステップ設定を示す図である。 ＬＴＥのＭＢＭＳ興味インディケーション（ＲＯＭ関連の設定を除く）を示す図である。 ＬＴＥのＳＩＢ１３の内容を示す図である。 ＬＴＥのＳＩＢ１３の内容を示す図である。 ＬＴＥのＳＩＢ１３の内容を示す図である。 ＬＴＥのＳＩＢ１５の内容を示す図である。 ＬＴＥのＳＩＢ２０の内容を示す図である。 ＬＴＥのＳＣ－ＭＣＣＨの内容を示す図である。 ＬＴＥのＳＣ－ＭＣＣＨの内容を示す図である。 ＬＴＥのＳＣ－ＭＣＣＨの内容を示す図である。 ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を示す図である。 ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を示す図である。 ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を示す図である。 ＬＴＥでのｅＭＢＭＳ周波数のセル再選択の優先順位を示す図である。 イントラ周波数におけるセルレベルの優先順位付けと、ＣＥ（ｅＭＴＣを含む）におけるＮＢ－ＩｏＴ及びＵＥのＬＴＥでの同等の優先度のイントラ周波数セル再選択を示す図である。 ＱｏｆｆｓｅｔＳＣＰＴＭがＳＩＢ５でＳＣＰＴＭ周波数オフセットとして設定される例を示す図である。 ＬＴＥ　ＳＣ－ＰＴＭにおけるＵＥ機能ｓｃｐｔｍ－ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ－ｒ１３を示す図である。 配信モード１を介したＰＴＭ送信のＤＲＸパラメータを示す図である。 配信モード２を介したＰＴＭ送信のＤＲＸパラメータを示す図である。
　５Ｇ／ＮＲのマルチキャストブロードキャストサービスは、４Ｇ／ＬＴＥのマルチキャストブロードキャストサービスよりも改善されたサービスを提供することが望まれる。
　そこで、本開示は、改善されたマルチキャストブロードキャストサービスを実現可能とする通信方法を提供する。
　図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　［第１実施形態］
　（移動通信システムの構成）
　図１は、第１実施形態に係る移動通信システムの構成を示す図である。移動通信システム１は、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ　Ｇｅｎｅｒａｔｉｏｎ　Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。移動通信システムには第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
　移動通信システム１は、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ　Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）２０とを有する。以下において、ＮＧ－ＲＡＮ１０を単にＲＡＮ１０と呼ぶことがある。また、５ＧＣ２０を単にコアネットワーク（ＣＮ）２０と呼ぶことがある。
　ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）又はタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ　ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ　ＵＥ）である。
　ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と呼ばれる）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数（以下、単に「周波数」と呼ぶ）に属する。
　なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。
　５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。
　図２は、第１実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。受信部１１０及び送信部１２０は、ｇＮＢ２００との無線通信を行う無線通信部を構成する。
　受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
　送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１３０は、ＵＥ１００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　図３は、第１実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。送信部２１０及び受信部２２０は、ＵＥ１００との無線通信を行う無線通信部を構成する。バックホール通信部２４０は、ＣＮ２０との通信を行うネットワーク通信部を構成する。
　送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
　制御部２３０は、ｇＮＢ２００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　バックホール通信部２４０は、基地局間インターフェイスであるＸｎインターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ　Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がフロントホールインターフェイスであるＦ１インターフェイスで接続されてもよい。
　図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。なお、ＵＥ１００のＰＨＹレイヤは、ｇＮＢ２００から物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される下りリンク制御情報（ＤＣＩ）を受信する。具体的には、ＵＥ１００は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＰＤＣＣＨのブラインド復号を行い、復号に成功したＤＣＩを自ＵＥ宛てのＤＣＩとして取得する。ｇＮＢ２００から送信されるＤＣＩには、ＲＮＴＩによってスクランブルされたＣＲＣパリティビットが付加されている。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化等を行う。
　ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。
　図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤを有する。
　ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間の接続がサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＡのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。また、ＮＡＳレイヤよりも下位のレイヤをＡＳレイヤと呼ぶ。
　（ＭＢＳの概要）
　第１実施形態に係るＭＢＳの概要について説明する。ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ　Ｔｏ　Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳのユースケース（サービス種別）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ　ｔｏ　Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　ＴｅｌｅＶｉｓｉｏｎ）、グループ通信、及びソフトウェア配信等が想定される。
　ブロードキャストサービスは、高信頼性のＱｏＳを必要としないアプリケーションのために、特定のサービスエリア内のすべてのＵＥ１００に対してサービスを提供する。ブロードキャストサービスに用いるＭＢＳセッションをブロードキャストセッションと呼ぶ。
　マルチキャストサービスは、すべてのＵＥ１００に対してではなく、マルチキャストサービス（マルチキャストセッション）に参加しているＵＥ１００のグループに対してサービスを提供する。マルチキャストサービスに用いるＭＢＳセッションをマルチキャストセッションと呼ぶ。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でＵＥ１００のグループに対して同じコンテンツを提供できる。
　図６は、第１実施形態に係るＭＢＳトラフィック配信の概要を示す図である。
　ＭＢＳトラフィック（ＭＢＳデータ）は、単一のデータソース（アプリケーションサービスプロバイダ）から複数のＵＥに配信される。５Ｇコアネットワークである５Ｇ　ＣＮ（５ＧＣ）２０は、アプリケーションサービスプロバイダからＭＢＳデータを受信し、ＭＢＳデータのコピーの作成（Ｒｅｐｌｉｃａｔｉｏｎ）を行って配信する。
　５ＧＣ２０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信（５ＧＣ　Ｓｈａｒｅｄ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）及び５ＧＣ個別ＭＢＳトラフィック配信（５ＧＣ　Ｉｎｄｉｖｉｄｕａｌ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）の２つのマルチキャスト配信方法が可能である。
　５ＧＣ個別ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、ＵＥ１００ごとのＰＤＵセッションを介してそれらのＭＢＳデータパケットの個別のコピーを個別のＵＥ１００に配信する。したがって、ＵＥ１００ごとに１つのＰＤＵセッションをマルチキャストセッションと関連付ける必要がある。
　５ＧＣ共有ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、それらのＭＢＳパケットの単一コピーをＲＡＮノード（すなわち、ｇＮＢ２００）に配信する。ｇＮＢ２００は、ＭＢＳトンネル接続を介してＭＢＳデータパケットを受信し、それらを１つ又は複数のＵＥ１００に配信する。
　ＲＡＮ（５Ｇ　ＲＡＮ）１０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信方法における無線を介したＭＢＳデータの送信には、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）の２つの配信方法が可能である。ＰＴＰはユニキャストを意味し、ＰＴＭはマルチキャスト及びブロードキャストを意味する。
　ＰＴＰ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの個別のコピーを無線で個々のＵＥ１００に配信する。他方、ＰＴＭ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの単一コピーを無線でＵＥ１００のグループに配信する。ｇＮＢ２００は、１つのＵＥ１００に対するＭＢＳデータの配信方法としてＰＴＭ及びＰＴＰのどちらを用いるかを動的に決定できる。
　ＰＴＰ配信方法及びＰＴＭ配信方法は主としてユーザプレーンに関するものである。ＭＢＳデータ配信の制御モードとしては、第１配信モード及び第２配信モードの２つの配信モードがある。
　図７は、第１実施形態に係る配信モードを示す図である。
　第１配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　１：ＤＭ１）は、ＲＲＣコネクティッド状態のＵＥ１００が利用できる配信モードであって、高ＱｏＳ要件のための配信モードである。第１配信モードは、ＭＢＳセッションのうちマルチキャストセッションに用いられる。但し、第１配信モードがブロードキャストセッションに用いられてもよい。第１配信モードは、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００も利用可能であってもよい。
　第１配信モードにおけるＭＢＳ受信の設定は、ＵＥ固有（ＵＥ－ｄｅｄｉｃａｔｅｄ）シグナリングにより行われる。例えば、第１配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にユニキャストで送信されるＲＲＣメッセージであるＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又はＲＲＣ　Ｒｅｌｅａｓｅメッセージ）により行われる。
　ＭＢＳ受信の設定は、ＭＢＳデータを運ぶＭＢＳトラフィックチャネルの設定に関するＭＢＳトラフィックチャネル設定情報（以下、「ＭＴＣＨ設定情報」と呼ぶ）を含む。ＭＴＣＨ設定情報は、ＭＢＳセッションに関するＭＢＳセッション情報と、このＭＢＳセッションに対応するＭＢＳトラフィックチャネルのスケジューリング情報とを含む。ＭＢＳトラフィックチャネルのスケジューリング情報は、ＭＢＳトラフィックチャネルの間欠受信（ＤＲＸ）設定を含んでもよい。間欠受信設定は、オン期間（Ｏｎ　Ｄｕｒａｔｉｏｎ：受信期間）を定義するタイマ値（Ｏｎ　Ｄｕｒａｔｉｏｎ　Ｔｉｍｅｒ）、オン期間を延長するタイマ値（Ｉｎａｃｔｉｖｉｔｙ　Ｔｉｍｅｒ）、スケジューリング間隔もしくはＤＲＸサイクル（Ｓｃｈｅｄｕｌｉｎｇ　Ｐｅｒｉｏｄ、ＤＲＸ　Ｃｙｃｌｅ）、スケジューリングもしくはＤＲＸサイクルの開始サブフレームのオフセット値（Ｓｔａｒｔ　Ｏｆｆｓｅｔ、ＤＲＸ　Ｃｙｃｌｅ　Ｏｆｆｅｓｔ）、オン期間タイマの開始遅延スロット値（Ｓｌｏｔ　Ｏｆｆｓｅｔ）、再送時までの最大時間を定義するタイマ値（Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ　Ｔｉｍｅｒ）、ＨＡＲＱ再送のＤＬ割り当てまでの最小間隔を定義するタイマ値（ＨＡＲＱ　ＲＴＴ　Ｔｉｍｅｒ）のいずれか一つ以上のパラメータを含んでもよい。
　なお、ＭＢＳトラフィックチャネルは論理チャネルの一種であって、ＭＴＣＨと呼ばれることがある。ＭＢＳトラフィックチャネルは、トランスポートチャネルの一種である下りリンク共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。
　第２配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　２：ＤＭ２）は、ＲＲＣコネクティッド状態のＵＥ１００だけではなく、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００が利用できる配信モードであって、低ＱｏＳ要件のための配信モードである。第２配信モードは、ＭＢＳセッションのうちブロードキャストセッションに用いられる。但し、第２配信モードは、マルチキャストセッションにも適用可能であってもよい。
　第２配信モードにおけるＭＢＳ受信の設定は、ブロードキャストシグナリングにより行われる。例えば、第２配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にブロードキャストで送信される論理チャネル、例えば、ブロードキャスト制御チャネル（ＢＣＣＨ）及び／又はマルチキャスト制御チャネル（ＭＣＣＨ）により行われる。ＵＥ１００は、例えば、技術仕様で予め規定された専用のＲＮＴＩを用いてＢＣＣＨ及びＭＣＣＨを受信できる。ＢＣＣＨ受信用のＲＮＴＩがＳＩ－ＲＮＴＩであって、ＭＣＣＨ受信用のＲＮＴＩがＭＣＣＨ－ＲＮＴＩであってもよい。
　第２配信モードにおいて、ＵＥ１００は、次の３つの手順でＭＢＳデータを受信してもよい。第１に、ＵＥ１００は、ｇＮＢ２００からＢＣＣＨ上で伝送されるＳＩＢ（ＭＢＳ－ＳＩＢ）によりＭＣＣＨ設定情報を受信する。第２に、ＵＥ１００は、ＭＣＣＨ設定情報に基づいてｇＮＢ２００からＭＣＣＨを受信する。ＭＣＣＨは、ＭＴＣＨ設定情報を伝送する。第３に、ＵＥ１００は、ＭＴＣＨ設定情報に基づいて、ＭＴＣＨ（ＭＢＳデータ）を受信する。以下において、ＭＴＣＨ設定情報及び／又はＭＣＣＨ設定情報をＭＢＳ受信設定と呼ぶことがある。
　第１配信モード及び第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００から割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いてＭＴＣＨを受信してもよい。Ｇ－ＲＮＴＩは、ＭＴＣＨ受信用ＲＮＴＩに相当する。Ｇ－ＲＮＴＩは、ＭＢＳ受信設定（ＭＴＣＨ設定情報）に含まれていてもよい。
　なお、ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｇｒｏｕｐ　Ｉｄｅｎｔｉｔｙ）、ソーススペシフィックＩＰマルチキャストアドレス（アプリケーション機能やアプリケーションサーバ等のソースユニキャストＩＰアドレスと、宛先アドレスを示すＩＰマルチキャストアドレスとから成る）、セッション識別子、及びＧ－ＲＮＴＩのうち少なくとも１つにより識別される。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、及びセッション識別子の少なくとも１つをＭＢＳセッション識別子と呼ぶ。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、セッション識別子、及びＧ－ＲＮＴＩを総括してＭＢＳセッション情報と呼ぶ。
　図８は、第１実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。ＭＲＢは、データ無線ベアラ（ＤＲＢ）の一種であってもよい。スプリットＭＲＢは、上述の第１配信モードで用いられてもよい。
　ｇＮＢ２００は、ＰＴＰ通信パス及びＰＴＭ通信パスに分離されたＭＲＢをＵＥ１００に設定し得る。これにより、ｇＮＢ２００は、ＵＥ１００に対するＭＢＳデータの送信をＰＴＰ（ＰＴＰ通信パス）とＰＴＭ（ＰＴＭ通信パス）との間で動的に切り替えることができる。或いは、ｇＮＢ２００は、ＰＴＰ（ＰＴＰ通信パス）及びＰＴＭ（ＰＴＭ通信パス）を併用して同一のＭＢＳデータを二重送信することにより信頼性を高めることができる。以下において、ＰＴＰ通信パスをＰＴＰレグと呼び、ＰＴＭ通信パスをＰＴＭレグと呼ぶ。また、各レイヤに相当する機能部をエンティティと呼ぶ。
　スプリットを終端する所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、ＰＤＣＰレイヤ、又はＳＤＡＰレイヤである。以下において、スプリットを終端する所定レイヤがＰＤＣＰレイヤである一例について主として説明するが、所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、又はＳＤＡＰレイヤであってもよい。
　ｇＮＢ２００のＰＤＣＰエンティティ及びＵＥ１００のＰＤＣＰエンティティのそれぞれは、ＭＢＳに用いるベアラ（データ無線ベアラ）であるＭＲＢをＰＴＰレグ及びＰＴＭレグに分離する。なお、ＰＤＣＰエンティティはベアラごとに設けられる。
　ｇＮＢ２００及びＵＥ１００のそれぞれは、レグごとに設けられる２つのＲＬＣエンティティと、１つのＭＡＣエンティティと、１つのＰＨＹエンティティとを有する。ＰＨＹエンティティは、レグごとに設けられてもよい。なお、ＵＥ１００が２つのｇＮＢ２００との通信を行う二重接続（Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙ）の場合、ＵＥ１００が２つのＭＡＣエンティティを有していてもよい。
　ＰＨＹエンティティは、ＵＥ１００と１対１で割り当てられるセルＲＮＴＩ（Ｃ－ＲＮＴＩ：Ｃｅｌｌ　Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｔｅｍｐｏｒａｒｙ　Ｉｄｅｎｔｉｆｉｅｒ）を用いて、ＰＴＰレグのデータを送受信する。ＰＨＹエンティティは、ＭＢＳセッションと１対１で割り当てられるＧ－ＲＮＴＩを用いて、ＰＴＭレグのデータを送受信する。Ｃ－ＲＮＴＩはＵＥ１００ごとに異なるが、Ｇ－ＲＮＴＩは１つのＭＢＳセッションを受信する複数のＵＥ１００で共通のＲＮＴＩである。
　ｇＮＢ２００からＵＥ１００に対してＰＴＭレグを用いてＭＢＳデータのＰＴＭ送信（マルチキャスト又はブロードキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＲＢが設定されており、且つ、ＰＴＭレグがアクティブ化（ａｃｔｉｖａｔｉｏｎ）されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＲＢが設定されていても、ＰＴＭレグが非アクティブ（ｄｅａｃｔｉｖａｔｉｏｎ）状態にある場合は、このＰＴＭレグを用いてＭＢＳデータのＰＴＭ送信を行うことができない。
　また、ｇＮＢ２００及びＵＥ１００がＰＴＰレグを用いてＭＢＳデータのＰＴＰ送信（ユニキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＲＢが設定されており、且つ、ＰＴＰレグがアクティブ化されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＲＢが設定されていても、ＰＴＰレグが非アクティブ状態にある場合は、このＰＴＰレグを用いてＭＢＳデータのＰＴＰ送信を行うことができない。
　ＵＥ１００は、ＰＴＭレグがアクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタする（すなわち、Ｇ－ＲＮＴＩを用いてＰＤＣＣＨのブラインドデコーディングを行う）。ＵＥ１００は、当該ＭＢＳセッションのスケジューリング機会にのみ当該ＰＤＣＣＨをモニタしてもよい。
　ＵＥ１００は、ＰＴＭレグが非アクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしない（すなわち、Ｇ－ＲＮＴＩを用いたＰＤＣＣＨのブラインドデコーディングを行わない）。
　ＵＥ１００は、ＰＴＰレグがアクティブ化された状態において、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタする。ＵＥ１００は、ＰＴＰレグにおける間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ　Ｒｅｃｅｐｔｉｏｎ）が設定されている場合、設定されたオン有効期間（ＯｎＤｕｒａｔｉｏｎ）においてＰＤＣＣＨをモニタする。ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該セルが非アクティブ化されていても、当該セルのＰＤＣＣＨをモニタしてもよい。
　ＵＥ１００は、ＰＴＰレグが非アクティブ化された状態において、ＭＢＳデータ以外の通常のユニキャスト下りリンク送信に備えて、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしてもよい。但し、ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該ＭＢＳセッションについて当該ＰＤＣＣＨをモニタしなくてもよい。
　なお、ｇＮＢ２００のＲＲＣエンティティがＵＥ１００のＲＲＣエンティティに対して送信するＲＲＣメッセージ（例えば、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）により、上述のようなスプリットＭＲＢが設定されるものとする。
　（移動通信システムの動作）
　第１実施形態に係る移動通信システム１の動作について説明する。
　図９は、グループＲＮＴＩ（Ｇ－ＲＮＴＩ）とＭＢＳセッションとの対応関係（マッピング）を示す図である。Ｇ－ＲＮＴＩは、Ｇ－ＣＳ（Ｃｏｎｆｉｇｕｒｅｄ　Ｓｃｈｅｄｕｌｉｎｇ）－ＲＮＴＩであってもよい。以下において、Ｇ－ＲＮＴＩはＧ－ＣＳ－ＲＮＴＩと読み替えられてもよい。例えば２個のＧ－ＲＮＴＩは、１個のＧ－ＲＮＴＩと１個のＧ－ＣＳ－ＲＮＴＩとで構成されてもよい。なお、Ｇ－ＣＳ－ＲＮＴＩは、一定周期で同じ無線リソースの割り当てを行うＣｏｎｆｉｇｕｒｅｄ　Ｓｃｈｅｄｕｌｉｎｇに用いるＧ－ＲＮＴＩであって、複数のＵＥに対してＲＲＣで設定された周期（ｐｅｒｉｏｄｉｃｉｔｙ）で、Ｇ－ＣＳ－ＲＮＴＩで指定された無線リソースが割り当てられる。
　Ｇ－ＲＮＴＩとＭＢＳセッションとのマッピングには、１つのＧ－ＲＮＴＩと１つのＭＢＳセッションとが対応付けられる「１：１マッピング」と、１つのＧ－ＲＮＴＩとＮ個（Ｎ≧２）のＭＢＳセッションとが対応付けられる「１：Ｎマッピング」と、Ｎ個のＧ－ＲＮＴＩと１つのＭＢＳセッションとが対応付けられる「Ｎ：１マッピング」と、がある。第１実施形態において、Ｎ：１マッピングが用いられる場合を主として想定する。
　図１０は、Ｇ－ＲＮＴＩと、マルチキャスト無線ベアラ（ＭＲＢ）／マルチキャストトラフィックチャネル（ＭＴＣＨ）と、サービス品質（ＱｏＳ）フローと、ＭＢＳセッションとの対応関係（マッピング）を示す図である。１つのＭＢＳセッションに複数本のＱｏＳフローが対応付けられる場合と、１つのＧ－ＲＮＴＩに複数本のＱｏＳフローが対応付けられる場合とがある。ＱｏＳフローとＭＲＢ／ＭＴＣＨとは１：１の関係にあってもよい。
　Ｎ：１マッピングにおいて、１つのＭＢＳセッション（例えば、１つのＭＢＳアプリケーション）に複数本のＱｏＳフローが対応付けられる場合、ＱｏＳフローごとに異なる設定（例えば、ＱｏＳフローごとに異なるＭＴＣＨ設定）でＭＢＳデータを送受信できる。例えば、ビデオ会議アプリケーションを用いたグループ通信を考えた場合、ＱｏＳフロー＃１はビデオ及びＱｏＳフロー＃２はテキストメッセージ（チャット）をそれぞれ流しているというシナリオが想定される。そのようなシナリオにおいて、例えば以下のような設定でデータ送受信を行うことが最適と考えられる。
　ＱｏＳフロー＃１：ＲＬＣ　ＵＭ、ＤＲＸサイクル＝ショート
　ＱｏＳフロー＃２：ＲＬＣ　ＡＭ、ＤＲＸサイクル＝ロング
　ここで、“＃1”及び“＃２”はＱｏＳフローの識別子であり、“ＲＬＣ　ＵＭ”はＲＬＣのモードが非確認モード（ＵＭ）であることを意味し、“ＲＬＣ　ＡＭ”はＲＬＣのモードが確認モード（ＡＭ）であることを意味する。ＤＲＸサイクルは、間欠受信におけるＵＥ１００がウェイクアップする周期を意味する。
　このような設定を用いる場合において、ＵＥ１００は、１つのＭＢＳセッションについて２つのＤＲＸサイクルがあるため、ある一定期間内に２回ウェイクアップしなければならず、ＵＥ１００の受信効率（消費電力）の点で好ましくない。第１実施形態は、１つのＭＢＳセッションと対応付けられた複数本のＱｏＳフローのうち一部のＱｏＳフローについてのみ受信することを可能とする実施形態である。
　第１実施形態に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてｇＮＢ２００からのＰＤＣＣＨの受信処理（以下、「ＰＤＣＣＨ受信処理」と呼ぶ）を行うＵＥ１００で用いる方法である。当該通信方法は、Ｎ個（Ｎ≧２）のＧ－ＲＮＴＩが１つのＭＢＳセッションと対応付けられている場合、Ｎ個のＧ－ＲＮＴＩの中からＰＤＣＣＨ受信処理に用いるＭ個（Ｍ＜Ｎ）のＧ－ＲＮＴＩを特定するステップと、Ｍ個のＧ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行うステップと、を有する（但し、ＭはＮと等しい値になり得る）。例えば、ＵＥ１００は、ＭＢＳセッションの受信において、Ｎ個のＧ－ＲＮＴＩのうち（Ｎ－Ｍ）個のＧ－ＲＮＴＩをＰＤＣＣＨ受信処理に用いることなく、Ｍ個のＧ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行う。これにより、Ｍ＜Ｎの場合、ＵＥ１００は、１つのＭＢＳセッションと対応付けられた複数本のＱｏＳフローのうち一部のＱｏＳフローについてのみ受信を行うことが可能である。
　なお、ＰＤＣＣＨ受信処理とは、ＵＥ１００が、ＲＮＴＩを用いてＰＤＣＣＨ（ＤＣＩ）のブラインド復号を行ってＤＣＩに付与されたＣＲＣパリティビットを用いたＣＲＣチェックを行う処理をいい、ＰＤＣＣＨの監視（モニタ）処理と呼ばれてもよい。
　ＵＥ１００がウェイクアップするタイミングは、ＰＤＣＣＨ受信処理に用いるＭ個のＧ－ＲＮＴＩと対応付けられたＭＴＣＨ設定により定められてもよい。すなわち、ＵＥ１００は、（Ｎ－Ｍ）個のＧ－ＲＮＴＩと対応付けられたＭＴＣＨ設定を適用しなくてもよいため、当該ＭＴＣＨ設定に応じてウェイクアップしなくてもよい。これにより、ＵＥ１００の消費電力が削減される。
　ＵＥ１００は、１つのＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳフローの中から、自身が受信を希望する所望のＱｏＳフローを特定し、所望のＱｏＳフローと対応付けられたＭ個のＧ－ＲＮＴＩを特定してもよい。所望のＱｏＳフローは、ＵＥ１００の上位レイヤ、例えば、アプリケーションレイヤ及び／又はＮＡＳレイヤにより決定されてもよい。
　ＵＥ１００は、１つのＭＢＳセッションとＫ本のＱｏＳフローとＮ個のＧ－ＲＮＴＩとを対応付ける情報（マッピング情報）をｇＮＢ２００から受信してもよい。これにより、ＵＥ１００は、ＭＢＳセッションとＱｏＳフローとＧ－ＲＮＴＩとの対応関係（マッピング）を明確（具体的）に把握できる。
　ＵＥ１００は、ＭＢＳセッション（ＵＥ１００が受信している又は受信に興味のあるＭＢＳセッション）の識別子と、当該ＭＢＳセッションに属する所望のＱｏＳフローに関する識別子とを含むメッセージをｇＮＢ２００に送信してもよい。これにより、ｇＮＢ２００は、ＵＥ１００がどのＭＢＳセッションのどのＱｏＳフローの受信を希望しているか、すなわち、どのＱｏＳフローを受信しているか（又は受信に興味があるのか）を把握できる。これにより、ｇＮＢ２００は、例えば、ＵＥ１００が受信を希望するＱｏＳフローと対応付けられたＭＲＢ／ＭＴＣＨのスケジューリングを適切に制御できる。
　図１１は、第１実施形態に係る動作の一例を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第１配信モード、又は第２配信モードであってもよい。
　ステップＳ１０１において、ｇＮＢ２００は、ＭＢＳセッションとＱｏＳフローとＧ－ＲＮＴＩのマッピング情報をＵＥ１００に送信する。ｇＮＢ２００は、ブロードキャストシグナリング（ＳＩＢ又はＭＣＣＨ）によりマッピング情報、又はＵＥ専用シグナリング（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ　Ｒｅｌｅａｓｅメッセージ）によりマッピング情報を送信してもよい。マッピング情報は、ＭＢＳセッション識別子とＱｏＳフロー識別子とＧ－ＲＮＴＩとのセットを１つ以上含んでいてもよい。マッピング情報は、ＮＡＳメッセージで、ＡＭＦ３００ＡからＵＥ１００に通知されてもよい。
　ステップＳ１０２において、ＵＥ１００は、ＭＢＳセッションを受信している又は受信に興味を持っている。なお、ステップＳ１０１は、ステップＳ１０２の後であってもよい。
　ステップＳ１０３において、ＵＥ１００は、当該ＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳフローの中から、自身が受信を希望する所望のＱｏＳフローを特定する。所望のＱｏＳフローは、１本のＱｏＳフロー、又は複数のＱｏＳフローであってもよい。
　ここで、ＵＥ１００の上位レイヤ（アプリケーションレイヤ等）は、当該ＭＢＳセッションにおいて、必要なＱｏＳフローの識別子をＡＳレイヤに通知してもよい。例えば、上位レイヤは、ビデオ会議アプリケーションにおいて、ビデオストリーミング（ＱｏＳフロー＃１）は使っているので必要だが、チャット機能（ＱｏＳフロー＃２）はオフしているので必要無い旨をＡＳレイヤに通知してもよい。
　ステップＳ１０４において、ＵＥ１００は、ステップＳ１０３で特定した所望のＱｏＳフローと対応付けられたＭ個のＧ－ＲＮＴＩを特定する。
　ステップＳ１０５において、ＵＥ１００は、当該ＭＢＳセッション（ＵＥ１００が受信している又は受信に興味のあるＭＢＳセッション）の識別子と、当該ＭＢＳセッションに属する所望のＱｏＳフローに関する識別子とを含むＭＢＳ興味情報メッセージをｇＮＢ２００に送信してもよい。所望のＱｏＳフローに関する識別子は、例えば、所望のＱｏＳフローの識別子、Ｋ本のＱｏＳフローのうち所望のＱｏＳフロー以外のＱｏＳフローの識別子、又は、所望のＱｏＳフローと対応付けられたＧ－ＲＮＴＩであってもよい。ＭＢＳ興味情報メッセージは、ＲＲＣメッセージの一種であって、例えば、ＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎメッセージ又はＵＥ　Ａｓｓｉｓｔａｎｃｅ　Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよい。ＭＢＳ興味情報メッセージを受信したｇＮＢ２００は、ＭＢＳ興味情報メッセージに含まれる情報（特に、所望のＱｏＳフローに関する識別子）に基づいて、ＵＥ１００が希望しないＱｏＳフローの送信の停止、又はＵＥ１００における設定変更（例えば、ＵＥ１００が希望しないＱｏＳフローの設定削除など）を行ってもよい。なお、ステップＳ１０５は、ステップＳ１０４の前に行われてもよい。
　ステップＳ１０６において、ＵＥ１００は、ステップＳ１０４で特定したＭ個のＧ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行う。これにより、ＵＥ１００は、ＭＴＣＨがマッピングされたＰＤＳＣＨのスケジューリング情報をＤＣＩから取得する。
　ステップＳ１０７において、ＵＥ１００は、ＰＤＳＣＨ上でｇＮＢ２００からのＭＢＳデータを受信する。
　［第２実施形態］
　第２実施形態について、上述の第１実施形態との相違点を主として説明する。
　図１２は、第２実施形態に係るＵＥ１００の内部処理を示す図である。ＵＥ１００のＰＨＹレイヤは、物理チャネルの１つであるＰＤＳＣＨ上で受信したユーザデータ（受信データ）を処理し、トランスポートチャネルの１つである下りリンク共有チャネル（ＤＬ－ＳＣＨ）に流す。ＵＥ１００のＭＡＣレイヤは、ＤＬ－ＳＣＨ上で受信したデータを処理し、受信データに含まれるヘッダ（ＭＡＣヘッダ）に含まれる論理チャネル識別子（ＬＣＩＤ）に基づいて、当該受信データを対応する論理チャネル（対応するＲＬＣエンティティ）に流す。
　ここで、ユーザデータ用の論理チャネルには、専用トラフィックチャネル（ＤＴＣＨ）及びマルチキャストトラフィックチャネル（ＭＴＣＨ）がある。ＤＴＣＨはユニキャスト用の論理チャネルであり、ＭＴＣＨはマルチキャスト／ブロードキャスト用の論理チャネルである。各論理チャネルに対するＬＣＩＤの割り当てはｇＮＢ２００により行われてもよい。なお、ＤＴＣＨはマルチキャスト／ブロードキャストのＰＴＰ用の論理チャネルであり、ＭＴＣＨはマルチキャスト／ブロードキャストのＰＴＭ用の論理チャネルであってもよい。
　ＤＴＣＨ及びＭＴＣＨに対して互いに異なるＬＣＩＤが割り当てられる場合、ＭＡＣレイヤは、ＭＡＣヘッダに含まれるＬＣＩＤに基づいて受信データを適切な論理チャネルに流すことができる。しかしながら、例えばＬＣＩＤに関する制約を少なくする観点から、ＤＴＣＨ及びＭＴＣＨでＬＣＩＤ空間を分けないことも想定される。
　仮にＬＣＩＤ空間を分けないと規定された場合、ＭＴＣＨ及びＤＴＣＨで別々のＬＣＩＤがｇＮＢ２００から割り当てられれば特に問題はないが、ＭＴＣＨは複数ＵＥに共通の論理チャネルであるため、あるＵＥ１００においてＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤになってしまう懸念がある。第２実施形態は、ＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤが割り当てられた場合であっても、適切な論理チャネルに受信データを流すことを可能とする実施形態である。換言すると、ＤＴＣＨとＭＴＣＨに同一のＬＣＩＤが割り当て可能となることにより、有限個であるＬＣＩＤを有効に使用することができる。つまり、ＤＴＣＨとＭＴＣＨは本来２つの独立したＬＣＩＤが必要であったのに対して、１つの共通のＬＣＩＤを割り当てることが可能となる。また、ＤＴＣＨとＭＴＣＨのＬＣＩＤをそれぞれ独立して割り当てること、管理することによって生じる複雑さを回避できる。
　第２実施形態に係る通信方法は、ＲＮＴＩを用いてｇＮＢ２００からのＰＤＣＣＨ受信処理を行うＵＥ１００で用いる方法である。当該通信方法は、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いて、ＤＴＣＨを受信するためのＰＤＣＣＨ受信処理を行うステップと、Ｇ－ＲＮＴＩを用いて、ＭＴＣＨを受信するためのＰＤＣＣＨ受信処理を行うステップと、ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが割り当てられている場合、ＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルを、当該ＰＤＣＣＨ受信処理に用いたＲＮＴＩに基づいて特定するステップと、を有する。このように、ＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルを、当該ＰＤＣＣＨ受信処理に用いたＲＮＴＩに基づいて特定することにより、ＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤが割り当てられた場合であっても、適切な論理チャネルに受信データを流すことが可能である。
　具体的には、ＵＥ１００のＭＡＣレイヤは、受信データであるＭＡＣ　ＰＤＵのヘッダに含まれるＬＣＩＤが、ＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤである場合において、Ｃ－ＲＮＴＩを用いたＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルとしてＤＴＣＨを特定する。一方、Ｇ－ＲＮＴＩを用いたＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルとしてＭＴＣＨを特定する。そして、ＵＥ１００のＭＡＣレイヤは、特定された論理チャネルに対して受信データ（ＭＡＣ　ＳＤＵ／ＲＬＣ　ＰＤＵ）を出力する。
　なお、第２実施形態において、ＵＥ１００は、データ無線ベアラ（ＤＲＢ）とＤＴＣＨのＬＣＩＤとを対応付ける情報と、マルチキャスト無線ベアラ（ＭＲＢ）とＭＴＣＨのＬＣＩＤとを対応付ける情報と、をｇＮＢ２００から受信してもよい。
　図１３は、第２実施形態に係る動作の一例を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。例えば、ＵＥ１００のＲＲＣ状態はＲＲＣコネクティッド状態であってもよい。ＭＢＳ配信のモードは、第１配信モード又は第２配信モードである。例えば、ＭＢＳ配信のモードは、第１配信モードであってもよい。
　ステップＳ２０１において、ｇＮＢ２００は、ＤＴＣＨのＬＣＩＤとＭＴＣＨのＬＣＩＤについて、それぞれのマッピング情報をＵＥ１００に通知する。例えば、ｇＮＢ２００は、ＤＲＢ＃１とＤＴＣＨ　ＬＣＩＤ＃１とを対応付ける情報と、ＭＲＢ＃２とＭＴＣＨ　ＬＣＩＤ＃１とを対応付ける情報とをＵＥ１００に送信する。すなわち、本動作例では、ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが対応付けられてもよい。ＵＥ１００は、ＬＣＩＤが同一であると認識した場合、以下の動作を行うとしてもよい。
　ステップＳ２０２において、ＵＥ１００は、ＭＢＳセッションを受信している又は受信に興味を持っている。なお、ステップＳ２０１は、ステップＳ２０２の後であってもよい。
　ステップＳ２０３において、ＵＥ１００は、ＤＴＣＨ　ＬＣＩＤ＃１について、Ｃ－ＲＮＴＩを用いてユニキャスト受信を行ってもよい。具体的には、ＵＥ１００は、Ｃ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行うことにより、ＤＴＣＨ受信を行ってもよい。
　ステップＳ２０４において、ＵＥ１００は、ＭＴＣＨ　ＬＣＩＤ＃１について、Ｇ－ＲＮＴＩを用いてマルチキャスト受信を行ってもよい。具体的には、ＵＥ１００は、Ｇ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行うことにより、ＭＴＣＨ受信を行ってもよい。なお、ステップＳ２０４はステップＳ２０３の前に実行されてもよい。
　ステップＳ２０３又はステップＳ２０４に応じて、ステップＳ２０５において、ＵＥ１００は、ＰＤＳＣＨ上でユーザデータを受信する。例えば、ステップＳ２０３に応じてＰＤＳＣＨ上で受信されるユーザデータはユニキャストデータであり、ステップＳ２０４に応じてＰＤＳＣＨ上で受信されるユーザデータはＭＢＳデータ（マルチキャストデータ又はブロードキャストデータ）であってもよい。
　ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが対応付けられている場合（ステップＳ２０６：ＹＥＳ）、ステップＳ２０７において、ＵＥ１００（ＭＡＣレイヤ）は、ステップＳ２０５で受信したデータ（パケット）について、受信に用いたＲＮＴＩから、対応する論理チャネルを特定する。ＵＥ１００は、Ｃ－ＲＮＴＩで受信した場合、ＤＲＢ＃１（ＤＴＣＨ）に紐づいたＬＣＩＤ＃１に当該パケットを流す（ステップＳ２０８）。一方、ＵＥ１００は、Ｇ－ＲＮＴＩで受信した場合、ＭＲＢ＃２（ＭＴＣＨ）に紐づいたＬＣＩＤ＃１に当該パケットを流す（ステップＳ２０８）。
　ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが対応付けられていない場合（ステップＳ２０６：ＮＯ）、ステップＳ２０８において、ＵＥ１００（ＭＡＣレイヤ）は、パケット（ＭＡＣ　ＰＤＵ）のヘッダに含まれるＬＣＩＤが示す論理チャネルに当該パケットを流す。
　第２実施形態では、ＤＴＣＨとＭＴＣＨが同一のＬＣＩＤである場合の受信方法について説明したが、これに限らない。別々のＭＴＣＨに同一のＬＣＩＤが割り当てられる場合にも第２実施形態に係る動作を適用可能である。図１４に示すように、ＭＴＣＨ＃１がＧ－ＲＮＴＩ＃１で送信／受信され、ＭＴＣＨ＃２がＧ－ＲＮＴＩ＃２で送信／受信される場合において、ＭＴＣＨ＃１とＭＴＣＨ＃２に同一ＬＣＩＤが割り当てられている（設定されている）場合においても、ＵＥ１００は、受信処理に用いたＧ－ＲＮＴＩ＃１とＧ－ＲＮＴＩ＃２から、適切なＲＬＣエンティティにデータを流すことが可能である。
　［第３実施形態］
　第３実施形態について、上述の第１及び第２実施形態との相違点を主として説明する。
　第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００からＭＣＣＨを受信することによりＭＴＣＨ設定情報を取得し、ＭＴＣＨ設定情報に基づいてＭＴＣＨ（ＭＢＳデータ）を受信する。ここで、ＭＣＣＨの内容は変更され得る。ＭＣＣＨの内容が維持される期間はＭＣＣＨ変更周期（ＭＣＣＨ　ｍｏｄｉｆｉｃａｔｉｏｎ　ｐｅｒｉｏｄ）と呼ばれてもよい。ＭＣＣＨの内容が変更され得る所定タイミングはＭＣＣＨ変更バウンダリ（ＭＣＣＨ　ｍｏｄｉｆｉｃａｔｉｏｎ　ｂｏｕｎｄａｒｙ）と呼ばれてもよい。
　ＭＢＳ受信を行っている又はＭＢＳ受信に興味のあるＵＥ１００が各ＭＣＣＨ変更バウンダリにおいてＭＣＣＨ（具体的には、物理チャネルであるＰＤＳＣＨ）を受信してその中身を解読することは負荷及び消費電力の増大につながる。そのため、ＭＣＣＨの内容変更に関する通知を、所定タイミングにおいてＰＤＣＣＨ上で（ＤＣＩ中で）ｇＮＢ２００からＵＥ１００に送信することを想定する。これにより、ＵＥ１００は、ＭＣＣＨを受信する必要があるか否かを判定できるため、不要なＭＣＣＨ受信を抑制できる。このようなＭＣＣＨ変更通知は、ＭＣＣＨの内容変更、例えば、ＭＢＳセッション開始、ＭＢＳセッション変更、又はＭＢＳセッション停止に基づいて送信されてもよい。ＭＣＣＨ変更通知は、ＤＣＩ中の１つのビット、すなわち、変更があるときのみ“１”とされる１ビットのフラグとして構成されてもよい。
　しかしながら、所定タイミングにおいてＭＣＣＨ変更通知を受信しないＵＥ１００、すなわち、ＭＣＣＨ変更を示すビットを検出しないＵＥ１００は、それがＰＤＣＣＨ（ＤＣＩ）の伝送エラー（無線区間での消失）に起因するのか又はＭＣＣＨ変更が無いことに起因するのかを判別できない。そのため、ＰＤＣＣＨ（ＤＣＩ）の伝送エラーが生じる可能性を考慮すると、所定タイミングにおいてＭＣＣＨ変更通知を受信しないＵＥ１００は、ＭＣＣＨを受信してその中身を解読することが必要になり得る。第３実施形態は、そのような問題を解決しようとする実施形態である。
　第３実施形態に係る通信方法は、ｇＮＢ２００が、ＭＴＣＨの受信に用いる設定情報（ＭＴＣＨ設定情報）をＭＣＣＨ上で送信するステップと、ｇＮＢ２００が、ＭＣＣＨの内容変更（以下、「ＭＣＣＨ変更」と呼ぶ）に関する通知（以下、「ＭＣＣＨ通知」と呼ぶ）を、所定タイミングにおいて物理下りリンク制御チャネル（ＰＤＣＣＨ）上でＵＥ１００に送信するステップと、を有する。当該送信するステップは、ＭＣＣＨ変更が無い場合、ＭＣＣＨ変更が無いことを示すＭＣＣＨ通知を送信するステップを含む。このように、ＭＣＣＨ変更が無い場合、ＭＣＣＨ変更が無いことを示すＭＣＣＨ通知を送信することにより、ＵＥ１００は、ＭＣＣＨ変更が無いことを明確に把握できる。そのため、所定タイミングにおいてＭＣＣＨ通知を受信しないＵＥ１００は、それがＰＤＣＣＨ（ＤＣＩ）の伝送エラーに起因するものであると判別できるようになる。よって、ＵＥ１００が不要なＭＣＣＨ受信を行うことを抑制可能である。
　例えば、ｇＮＢ２００は、ＭＣＣＨ変更が有る場合、ＭＣＣＨ変更が有ることを示す第１の値をＭＣＣＨ通知として送信する。ｇＮＢ２００は、ＭＣＣＨ変更が無い場合、ＭＣＣＨ変更が無いことを示す第２の値をＭＣＣＨ通知として送信する。これにより、ＵＥ１００は、ＭＣＣＨ変更の有無を明確に把握できる。
　例えば、ＵＥ１００は、ＰＤＣＣＨ上で第１の値を受信した場合、ＭＣＣＨの受信を試みてもよい。ＵＥ１００は、ＰＤＣＣＨ上で第２の値を受信した場合、ＭＣＣＨの受信を省略してもよい。ＵＥ１００は、所定タイミングにおいてＰＤＣＣＨ上でＭＣＣＨ通知を受信できなかった場合、ＭＣＣＨの受信を試みてもよい。
　図１５は、第３実施形態に係る動作の一例を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第２配信モードであってもよい。
　ステップＳ３０１において、ＵＥ１００は、ＭＢＳセッションを受信している又は受信に興味を持っている。
　ステップＳ３０２乃至Ｓ３０４において、ｇＮＢ２００は、ＭＣＣＨ通知の送信処理を行う。ここで、ＭＣＣＨ通知は、ＤＣＩのあるビットを用いて構成される。ＭＢＳセッション開始に基づくＭＣＣＨ通知と、ＭＢＳセッション変更／停止に基づくＭＣＣＨ通知とは、同一ビット、又はそれぞれ異なるビットで通知が行われてもよい。また、当該ＭＣＣＨ通知は、ＭＢＳセッションごとに異なるビットで、又は全セッション共通（１ビットのみ）で通知が行われてもよい。ＭＣＣＨ通知を構成する（各）ビットは、“０”の時は「変更無し」、“１”の時は「変更有り」と定義されてもよい。また、ＭＣＣＨ通知を構成する（各）ビットは、０／１の関係が逆であってもよい。ｇＮＢ２００は、ＭＣＣＨ変更の有無に関わらず、ＭＣＣＨ通知を送信する。
　ＭＣＣＨ変更有りの場合（ステップＳ３０２：ＹＥＳ）、ステップＳ３０３において、ｇＮＢ２００は、所定タイミングにおいて、ＭＣＣＨ変更が有ることを示す第１の値（例えば、“１”）をＭＣＣＨ通知として送信する。
　これに対し、ＭＣＣＨ変更無しの場合（ステップＳ３０２：ＮＯ）、ステップＳ３０４において、ｇＮＢ２００は、所定タイミングにおいて、ＭＣＣＨ変更が無いことを示す第２の値（例えば、“０”）をＭＣＣＨ通知として送信する。
　ＵＥ１００は、所定タイミング（ＭＣＣＨ　ｃｈａｎｇｅ　ｂｏｕｎｄａｒｙ）においてＭＣＣＨ通知（ＤＣＩ）の受信を試みる。
　ここで、ＵＥ１００は、ＭＣＣＨ通知を正常に受信し、受信したＭＣＣＨ通知が第２の値である場合（ステップＳ３０５：ＹＥＳ）、ＵＥ１００は、ＭＣＣＨ（ＰＤＳＣＨ）の受信を試みない。
　一方、ＭＣＣＨ通知を正常に受信し、受信したＭＣＣＨ通知が第１の値である場合、ＭＣＣＨ（ＰＤＳＣＨ）の受信を試みる（ステップＳ３０６）。また、ＵＥ１００は、ＭＣＣＨ通知を正常に受信ができなかった場合、ＭＣＣＨ（ＰＤＳＣＨ）の受信を試みる（ステップＳ３０６）。具体的には、ＵＥ１００は、ＭＣＣＨ（ＰＤＳＣＨ）のスケジューリング情報を伝送するＰＤＣＣＨ（ＤＣＩ）の受信を試みる。なお、ＭＣＣＨ通知を構成するＤＣＩは専用のＲＮＴＩ（例えばＳＣ－Ｎ－ＲＮＴＩ）でスクランブルされてもよく、ＭＣＣＨ用ＤＣＩは専用のＲＮＴＩ（例えばＳＣ－ＲＮＴＩ）でスクランブルされてもよい。これらのＲＮＴＩは、技術仕様で規定された固定のＲＮＴＩであってもよい。ＵＥ１００は、受信したＭＣＣＨを確認し、変更があった場合は、当該ＭＣＣＨの内容（設定）を適用する。
　第２実施形態において、ＭＣＣＨ変更の有無をビットの値で表す一例について説明したが、ＭＣＣＨ変更の有無をＲＮＴＩの値で表すように変更してもよい。その場合、ＭＣＣＨ変更の有無にかかわらず、ビットの値は固定値であってもよい。図１６のステップＳ３０３’、Ｓ３０４’、及びＳ３０５’に示すように、第１のＲＮＴＩ（ＲＮＴＩ＃１）でＭＣＣＨ通知が送信された場合は「変更無し」、第２のＲＮＴＩ（ＲＮＴＩ＃２）でＭＣＣＨ通知が送信された場合は「変更有り」と定義されてもよい。
　［その他の実施形態］
　上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよい。１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。
　上述の実施形態及び実施例において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）又は６Ｇ基地局であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵであってもよい。また、ユーザ装置は、ＩＡＢノードのＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）であってもよい。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ）として構成してもよい。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本願は、米国仮出願第６３／２２８２６８号（２０２１年８月２日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
　［付記１］
　（１．導入）
　ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。
　ＲＡＮ２は、２つの配信モードに同意した。つまり、コネクティッド状態のＵＥが受信するマルチキャストセッションの配信モード１と、すべてのＲＲＣ状態のＵＥが受信するブロードキャストセッションの配信モード２である。
　ＲＡＮ２は、ＭＣＣＨスケジューリング方法の詳細、つまり、ＭＣＣＨ繰り返し期間、ＭＣＣＨ送信ウィンドウ、検索スペース、及びＭＣＣＨ変更期間にも同意した。
　ＲＡＮ２＃１１４－ｅでは、２つの配信モードについて次の合意に達した。
　マルチキャスト有効化通知にＰＣＣＨを使用する（ＭＢＳサポートノードにも使用する）。
　通知でＭＢＳセッションＩＤが伝達されていることを確認する。
　ＰＲＮＴＩを使用したすべての（レガシー）ＰＯにおけるページングの使用は、ベースラインの前提である（他の変更についても議論可能である）。
　ＭＢＳ固有のＳＩＢは、ＭＣＣＨ設定を実行するように定義される。
　ＭＣＣＨのコンテンツには、Ｇ－ＲＮＴＩ、ＭＢＳセッションＩＤなどのブロードキャストセッションに関する情報と、ＭＴＣＨのスケジュール情報（検索スペース、ＤＲＸなど）を含める必要がある。
　ＭＣＣＨに含める必要のあるＬ１パラメータは、更なるＲＡＮ１の進行とインプットを保留する。
　ＲＡＮ１がＭＣＣＨのＢＷＰ／ＣＦＲについて進行するまで、専用のＭＣＣＨ設定が必要かどうかについての議論を延期する。
　進行中のセッションの設定の変更（セッション停止を含む）によるＭＣＣＨ変更のインディケーションは、ネットワークからの明示的な通知で提供される（ＲＡＮ１が、セッション開始通知用のビットに加えて、この目的のための別のビットをＭＣＣＨ変更通知ＤＣＩに収容できることを確認した場合）。この通知をＭＣＣＨが保持する他の情報の変更に再利用できるかどうかについては更なる検討が必要である。
　ＵＥがＭＣＣＨ変更通知を見逃す可能性に対処する必要があるか、又はＵＥの実装に任せることができるかどうかは更なる検討が必要である。
　少なくとも、ＲＡＮ１がＭＣＣＨ変更通知のためにＭＣＣＨ－ＲＮＴＩ以外のＲＮＴＩを利用することを決定した場合、ＭＣＣＨ変更通知は、各ＭＣＣＨ繰り返し期間の最初のＭＣＣＨ監視機会に送信される。
　シングルＭＣＣＨをサポートする。
　付記１では、ＬＴＥ　ｅＭＢＭＳメカニズムのベースラインを考慮して、配信モード２のコントロールプレーンの側面の詳細を提供する。
（２．議論）
　（３．残りのステージ２の問題）
　この時点で、ＲＡＮ２の合意に従って、２つの配信モードの特性を図１７に示す。
　（４．配信モード２を介して接続されたマルチキャストセッション）
　ＮＲ　ＭＢＳは、以下のＷＩＤから引用されているように、さまざまなタイプのユースケースをサポートすることが期待されている。ＮＲ　ＭＢＳは、ミッションクリティカルやＶ２Ｘなどの遅延に敏感なアプリケーションから、ＩｏＴなどの遅延耐性のあるアプリケーションまで、さまざまな要件に合わせて適切に設計する必要がある。ＩＰＴＶなどのＵＤＰタイプのストリーミングへのソフトウェア配信として、実際には、すべてのマルチキャストサービスが「高ＱｏＳ」を必要とするわけではない。
　ＳＡ２　ＳＩの目的Ａは、５ＧＳを介した一般的なＭＢＳサービスの有効化に関するものであり、この機能の恩恵を受ける可能性があると認識されたユースケースには、公共の安全、ミッションクリティカル、Ｖ２Ｘアプリケーション、透過的なＩＰｖ４／ＩＰｖ６マルチキャスト配信、ＩＰＴＶ、及びワイヤレス、グループ通信、ＩｏＴアプリケーションを介したソフトウェア配信が含まれる。
　「ＱｏＳ要件が低い」これらのサービスの一部は配信モード２でカバーされる場合があるが、「ＱｏＳ要件が高い」他のサービスは配信モード１が必要である。さらに、ＬＴＥ　ｅＭＢＭＳはマルチキャストセッションを配信する場合があり、これはＮＲ　ＭＢＳのベースラインと見なすことができる。この意味で、ｇＮＢがマルチキャストセッションに配信モード２を使用することを選択できることは有益である。この問題は、ＲＡＮ２＃１１２－ｅからＲＡＮ２＃１１４－ｅまで更なる検討が必要であるが、一般的に、制限する技術的な理由はない。
　ＲＡＮ２では「ＲＡＮ２は、Ｒｅｌ－１７のＲＲＣコネクティッドモードでのアクティブマルチキャストサポートを優先し、時間が許せば、ＲＲＣインアクティブ状態のマルチキャストサポートを（コネクティッドモードのマルチキャストソリューション、及びブロードキャストソリューションがより成熟した）後で議論できる」ことを同意したが、配信モード１のコンテキストで合意が行われたため、コネクティッド状態のＵＥの配信モード２によるマルチキャストセッションを排除するものではない。
　提案１：ＲＡＮ２は、ブロードキャストセッションに加えて、配信モード２を少なくともＲＲＣコネクティッド状態のＵＥのマルチキャストセッションに使用できることに同意する必要がある。
　（５．専用のＭＣＣＨ（サービス継続性の観点から））
　ＲＡＮ２は「ＲＡＮ１がＭＣＣＨのＢＷＰ／ＣＦＲで進展するまで、専用のＭＣＣＨ設定が必要かどうかに関する議論を延期する」ことに同意した。専用のＭＣＣＨは、サポートされている場合、例えば、ＲＲＣ再設定によって提供されることが期待される。
　所見１：専用のＭＣＣＨは、ＭＣＣＨがＲＲＣ再設定によって提供される。つまりブロードキャストベースの方法ではないと解釈できる。
　一方、専用のＭＣＣＨは、ブロードキャストサービスの継続性の観点から考えることができる。ＲＡＮ２は「コネクティッド状態のＵＥのＬＴＥ　ＳＣ－ＰＴＭメカニズムを再利用して、ＮＲ　ＭＢＳ配信モード２のＰＴＭ設定、つまりブロードキャストベースの方法を受信できると想定する」ことにすでに同意している。この想定はセル内設定に関するものであるが、セル間サービスの継続性、つまりハンドオーバに関するものではない。
　所見２：ＲＡＮ２が合意したＭＣＣＨは、セル内設定に対してブロードキャストベースの方法で提供されるが、セル間サービスの継続性のためではない。
　ＬＴＥ　ＳＣ－ＰＴＭでは、ＵＥは、ハンドオーバ前、ハンドオーバ中、又はハンドオーバ後でも、ターゲットセルのＳＩＢ２０とＭＣＣＨを何らかの方法で取得すると想定される。これは、ＮＲ　ＭＢＳ配信モード２のベースラインと見なされる可能性がある。ただし、ＵＥが、例えば、ビジー状態で、隣接セルのＭＣＣＨを取得するのを見逃したり、遅延したりする可能性があるため、サービスが中断するリスクがあることを意味する。したがって、より信頼性の高いソリューションを議論する価値がある。具体的には、ターゲットセルのＭＣＣＨ、少なくとも対象のＭＴＣＨスケジューリング情報は、同期を使用したＲＲＣ再設定、つまりハンドオーバーコマンドによって提供される必要がある。このソリューションにより、ハンドオーバ後のサービス継続性を確実に確保できる。
　提案２：ＲＡＮ２は、ターゲットセルのＭＣＣＨ、少なくとも対象のＭＴＣＨスケジューリング情報が、ハンドオーバ手順中に提供されることに同意する必要がある。つまり、ＲＲＣコネクティッド状態のＵＥのセル間サービスの継続性を確保するために、同期を使用したＲＲＣ再設定によって提供される。
　（６．その他の情報に関するＭＣＣＨ変更通知）
　ＲＡＮ２は、セッションの開始、セッションの変更、及び停止により、ＭＣＣＨ変更通知を導入することに同意し、これにより、ＭＴＣＨ受信に関連する設定（例えば、ＭＢＳセッション情報、及びＭＴＣＨスケジューリング情報）が変更されたときにＭＣＣＨ変更通知が送信されることが現在の意図である。ＲＡＮ２は、「この通知を、ＭＣＣＨが保持する他の情報の変更に再利用できるかどうかについては更なる検討が必要である」と残した。
　考えられる「その他の情報」は、隣接セル／周波数情報として解釈でき、これについては、以下のセクションで議論する。ＵＥが隣接セル／周波数情報を見逃した場合、ＵＥがサービングセルに留まっているときは重大な問題ではない。ただし、最新の隣接セル／周波数情報は、アイドル／インアクティブ状態のＵＥ、及び提案５が合意されていない場合はＲＲＣコネクティッド状態のＵＥのセル間モビリティの場合に重要な情報である。この意味で、より信頼性の高いサービス継続性のために、ＲＡＮ２が隣接セル／周波数情報がＭＣＣＨによって提供されることに同意した場合、他の情報が変更されたときにもＭＣＣＨ変更通知を送信する必要がある。
　提案３：ＲＡＮ２は、ＭＣＣＨの内容のいずれかが変更されたときに、ＭＣＣＨ変更通知が送信されることに同意する必要がある。つまり、ＭＢＳセッション情報及びＭＴＣＨスケジューリング情報に加えて、少なくとも隣接周波数／セル情報（ＭＣＣＨによって提供されることに同意した場合）である「その他の情報」にも適用される。
　（７．ＭＣＣＨ変更通知の見逃し）
　ＲＡＮ２は、「ＵＥがＭＣＣＨ変更通知を見逃す可能性に対処する必要があるか、ＵＥの実装に任せることができるかどうかは更なる検討が必要である」と残した。合意によると、ＭＣＣＨ変更通知はＤＣＩで提供されると予想されるが、詳細はＲＡＮ１までである。
　更なる検討が必要なことはセッションの変更／停止だけでなく、セッションの開始にも関連しており、ＬＴＥ　ｅＭＢＭＳで問題として認識されたことはない。さらに、問題が実際に存在するかどうかは、ＲＡＮ１のＤＣＩ設計に依存する場合がある。例えば、ＭＣＣＨが変更されていない場合にも、ＭＣＣＨ変更通知が送信される場合がある。例えば、ＤＣＩのビットは、「０」で「変更なし」を示し、「１」で「変更」を示すことができるため、ＵＥはＭＣＣＨ変更を見逃したかどうかを通知できる。追加の電力消費なしで通知し、回復のためにいくつかのアクションを実行する場合がある。したがって、現時点でＲＡＮ２が更なる検討が必要なことについて議論すべきかどうかは不明である。
　所見３：ＲＡＮ２でＵＥがＭＣＣＨ変更通知を見逃す可能性について議論する前に、ＭＣＣＨ変更通知のＤＣＩ設計のＲＡＮ１進捗状況が必要である。
　（８．オンデマンドＭＣＣＨ）
　ＮＲの新しいパラダイムは、オンデマンドＳＩ送信のサポートである。この概念は、配信モード２のＭＣＣＨ、つまりオンデマンドＭＣＣＨで再利用できる。例えば、遅延耐性サービスのＭＣＣＨはオンデマンドで提供されるため、シグナリングのリソース消費を最適化できる。言うまでもなく、ネットワークには、つまり、遅延に敏感なサービス等のオンデマンドではなく、ＭＣＣＨを定期的に提供する別のオプションがある。
　提案４：ＲＡＮ２は、ＭＣＣＨをオンデマンドで提供できることに同意する必要がある。
　（９．ワンステップ設定）
　別の可能性として、ＭＣＣＨをＢＣＣＨにマージすること、つまり、図１８に示すようなワンステップ設定をさらに議論することができる。例えば、ＳＩＢは、ＭＴＣＨスケジューリング情報を直接、つまりＭＣＣＨなしで提供する。遅延耐性のあるサービスや電力に敏感なＵＥの最適化を提供する。例えば、ＵＥは、ＳＩＢ（オンデマンド）を要求することができ、ｇＮＢは、複数のＵＥからの要求の後に、ＳＩＢ及び対応するサービスの提供を開始することができる。これらのＵＥは、繰り返しブロードキャストされるＭＣＣＨを監視する必要はない。
　提案５：ＲＡＮ２は、ＭＣＣＨなしのマルチキャスト受信がサポートされていること（つまり、ワンステップ設定）に同意する必要がある。例えば、ＳＩＢはＭＴＣＨスケジューリング情報を直接提供する。
　（１０．アイドル／インアクティブ状態でのカウント）
　ＮＲ　ＭＢＳの場合、ＭＢＳ興味インディケーションは、ＲＲＣコネクティッド状態でサポートされることに同意したが、アイドル／インアクティブ状態ではサポートされない。これに基づいて、ＬＴＥ　ｅＭＢＭＳに加えての機能強化を議論する価値がある。
　ＬＴＥ　ｅＭＢＭＳでは、ＵＥの大部分がＲＲＣアイドル状態でブロードキャストサービスを受信している場合でも、ＭＩＩもカウントもアイドル状態のＵＥから情報を収集できない。これは、セッション制御とリソース効率の観点から見たＬＴＥ　ｅＭＢＭＳの残りの問題の１つである。
　所見４：ブロードキャストセッションの場合、ＭＢＳサービスを受信するほとんどのＵＥはＲＲＣアイドル／インアクティブ状態にある可能性がある。
　ＮＲ　ＭＢＳでは、アイドル／インアクティブ状態のＵＥ、つまりブロードキャストセッションの配信モード２でも同じ問題が発生する可能性がある。例えば、ネットワークは、アイドル／インアクティブ状態のＵＥがブロードキャストサービスを受信していない／興味がないかどうかを知らない。したがって、サービスを受信しているＵＥがない場合でも、ネットワークはＰＴＭ送信を提供し続ける可能性がある。ｇＮＢがアイドル／インアクティブ状態のＵＥの利益を知っている場合は、このような不要なＰＴＭ送信を回避する必要がある。逆に、サービスを受信しているアイドル／インアクティブ状態のＵＥがまだ存在するときにＰＴＭが停止すると、多数のＵＥが同時に接続要求を送信する可能性があり、これも望ましくはない。
　したがって、アイドル／インアクティブ状態のＵＥからＵＥ支援情報、特にＭＢＭＳカウントを収集するメカニズムを導入するかどうかを議論する価値がある。言うまでもなく、アイドル／インアクティブ状態のこれらのＵＥは、ＲＲＣコネクティッド状態に移行せずに情報を報告できることが望ましい。これは、例えば、ＭＢＳサービスに関連付けられたＰＲＡＣＨリソースパーティショニングがそのようなレポートに導入された場合に達成される可能性がある。
　ＮＲ　ＭＢＳにはＭＣＥがないことに注意し、これは、ＭＣＥ機能がｇＮＢ内に統合されることを意味する。この意味で、ネットワークインターフェイスの観点からＲＡＮ３が決定したものに関係なく、ＮＲ　ＭＢＳでカウントが必要かどうかを決定するのはＲＡＮ２である。
　提案６：　ＲＡＮ２は、ＭＢＳカウントが導入されているかどうか、及びアイドル／インアクティブ状態のＵＥからも収集されているかどうかについて議論する必要がある。
　（１１．ステージ３の側面）
　ＳＩＢ１３、ＳＩＢ１５、ＳＩＢ２０、ＳＣ－ＭＣＣＨ、ＭＢＭＳ興味インディケーションのＩＥ、及びＬＴＥでのセル再選択手順は、ＮＲ　ＭＢＳのステージ３仕様のベースラインと見なすことができる。
　（１２．ＭＢＳ固有のＳＩＢ）
　（１３．基本的な内容）
　ＲＡＮ２は、「ＭＢＳ固有のＳＩＢはＭＣＣＨ設定を実行するように定義されている」ことに同意した。ＭＣＣＨ設定に関して、ＲＡＮ２は、「ＭＣＣＨ送信ウィンドウはＭＣＣＨ繰り返し期間、ＭＣＣＨウィンドウ期間、及び無線フレーム／スロットオフセットによって定義される」、及び「変更期間はＮＲ　ＭＣＣＨに対して定義される」ことにすでに同意している。これらのパラメータは、ＳＩＢ２０と同じであり、つまり、それぞれＳＣ－ＭＣＣＨ－繰り返し期間、ＳＣ－ＭＣＣＨ－第１サブフレーム、ＳＣ－ＭＣＣＨ－期間、ＳＣ－ＭＣＣＨ－オフセット、及びＳＣ－ＭＣＣＨ－変更期間である。したがって、これらのパラメータの範囲は、標準化の労力を最小限に抑えるために簡単に再利用できる。
　提案７：ＲＡＮ２は、ＭＢＳ固有のＳＩＢで、ＭＣＣＨ繰り返し期間、期間、無線フレーム／オフセット、及び変更期間の範囲が、ＬＴＥ　ＳＣ－ＰＴＭ、つまりＳＩＢ２０のこれらのパラメータの範囲を再利用することに同意する必要がある。
　（１４．高度なコンテンツ）
　ＭＢＳサービスがＰＴＰ又はＰＴＭのどちらで提供されるか、及び配信モード１又は配信モード２で提供されるかどうかは、ＮＷの実装次第である。これにより、サービスの信頼性とスペクトル効率のバランスをうまくとることができる。ただし、ＵＥの観点から、特にアイドル／インアクティブ状態のＵＥ及び遅れて参加するＵＥの場合、ＵＥは、対象のＭＢＳサービスを取得するために接続確立を開始する必要があるかどうかを知る必要がある。ＵＥは最初にＭＣＣＨをチェックし、ＭＣＣＨが対象のＭＢＳサービスのＭＴＣＨスケジューリング情報を含まない場合、ＵＥは、ＭＢＳサービスがＲＲＣコネクティッド状態で、すなわち、ＰＴＰ、配信モード１、又は、ユニキャスト（ＰＤＵセッション）を介して、のみ提供されることに気付くと考えることができる。ただし、このようなプロセスはＵＥにとって負担であり、ＭＢＳサービスを取得する前に多少の遅延が発生する可能性がある。したがって、ＭＢＳ固有のＳＩＢが、ＭＢＳサービスを取得するためにＵＥが接続されている必要があるかどうかの情報を提供するかどうかを議論する価値がある。
　提案８：ＲＡＮ２は、ＭＢＳ固有のＳＩＢがＭＢＳサービスをそれらの配信モードに関連付けるための情報を提供するかどうかについて議論する必要がある。
　ＲＡＮ２は、ブロードキャストセッションで使用されると想定されているＭＢＳ興味インディケーションを導入することに同意した。少なくともＡＳの観点からは、ＭＢＳサービスがマルチキャストセッションとして提供されるかブロードキャストセッションとして提供されるかはネットワーク次第である。さらに、ＵＥの観点からは、ｇＮＢはＵＥが興味のあるＭＢＳサービスに関する情報を取得できるかどうかは不明であり、これは、マルチキャストセッション用にＡＭＦによって提供される可能性があるが、ブロードキャストセッション用ではない。その結果、ＵＥは、興味のあるＭＢＳサービスに対してＭＢＳ興味インディケーションを送信する必要があるかどうかを知ることができない。したがって、ｇＮＢが各ＭＢＳサービスに対してＭＢＳ興味インディケーションが許可されているかどうかに関する情報を提供する場合、ＵＥにとって役立つ。言い換えれば、どのＭＢＳサービスにＭＢＳ興味インディケーションが必要かということである。したがって、ＲＡＮ２は、そのような追加情報が必要かどうかについて議論する必要がある。
　提案９：ＲＡＮ２は、ＭＢＳ固有のＳＩＢが、ＭＢＳ興味インディケーションを各ＭＢＳサービスに送信できるかどうかに関する情報を提供するかどうかについて議論する必要がある。
　（１５．ＭＣＣＨ）
　ＲＡＮ２は、「ＭＣＣＨのコンテンツには、Ｇ－ＲＮＴＩ、ＭＢＳセッションＩＤなどのブロードキャストセッションに関する情報と、ＭＴＣＨのスケジュール情報（検索スペース、ＤＲＸなど）を含める必要があることに同意した。ＭＣＣＨに含める必要のあるＬ１パラメータは、ＲＡＮ１の進行と入力が保留されている」、及び「ＲＡＮ１がＭＣＣＨのＢＷＰ／ＣＦＲで進行するまで、専用のＭＣＣＨ設定が必要かどうかの議論を延期する」。
　ＭＴＣＨスケジューリング情報については、ＬＴＥ　ＳＣ－ＰＴＭのＳＣ－ＭＣＣＨには、ＭＢＭＳ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏ（ＴＭＧＩ及びセッションＩＤ）、ｇ－ＲＮＴＩ、及びＳＣ－ＭＴＣＨ－ｓｃｈｅｄｕｌｉｎｇ　Ｉｎｆｏ（Ｏｎ　Ｄｕｒａｔｉｏｎ　Ｔｉｍｅｒ　ＳＣＰＴＭ、ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ　Ｔｉｍｅｒ　ＳＣＰＴＭ、Ｓｃｈｅｄｕｌｉｎｇ　Ｐｅｒｉｏｄ　Ｓｔａｒｔ　Ｏｆｆｓｅｔ　ＳＣＰＴＭ）を含むＳＣ－ＭＴＣＨ－ＩｎｆｏＬｉｓｔが含まれている。ＲＡＮ２は「ＮＲ　ＭＢＳ配信モード２の場合、ＬＴＥ　ＳＣ－ＰＴＭ　ＤＲＸスキームがベースラインとして使用される」ことに同意したため、これらのパラメータと値の範囲は、標準化の労力を最小限に抑えるために単純に再利用される。
　提案１０：ＲＡＮ２は、ＭＣＣＨがＭＢＳ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏ（ＴＭＧＩ及びセッションＩＤ）、Ｇ－ＲＮＴＩ及びＭＴＣＨ－ｓｃｈｅｄｕｌｉｎｇ　Ｉｎｆｏ（Ｏｎ　Ｄｕｒａｔｉｏｎ　Ｔｉｍｅｒ、Ｉｎａｃｔｉｖｉｔｙ　Ｔｉｍｅｒ、Ｓｃｈｅｄｕｌｉｎｇ　Ｐｅｒｉｏｄ、及びＳｔａｒｔ　Ｏｆｆｓｅｔ）をＭＴＣＨ情報として提供することに同意する必要がある。
　提案１１：ＲＡＮ２は、ＭＴＣＨスケジューリング情報の各パラメータの値の範囲（つまり、Ｏｎ　Ｄｕｒａｔｉｏｎ　Ｔｉｍｅｒ、Ｉｎａｃｔｉｖｉｔｙ　Ｔｉｍｅｒ、Ｓｃｈｅｄｕｌｉｎｇ　Ｐｅｒｉｏｄ、及びＳｔａｒｔ　Ｏｆｆｓｅｔ）がＬＴＥ　ＳＣ－ＰＴＭ、つまりＳＣ－ＰＴＭ設定のこれらのパラメータと同じであることに同意する必要がある。
　ＬＴＥ　ｅＭＢＭＳでは、ＳＩＢ１５はＳＡＩで周波数間情報を提供し、つまり、ＭＢＭＳ－ＳＡＩ－インタ周波数リストである。ＬＴＥ　ＳＣ－ＰＴＭでは、ＳＣ－ＭＣＣＨには、セルＩＤと周波数で構成されるＳＣＰＴＭ－隣接セルリストと、隣接セルリストを参照するビット文字列であるＳＣ－ＭＴＣＨ隣接セルリストが含まれている。これらの情報は、ＵＥの観点からのサービス継続性、つまりＭＢＭＳ興味インディケーション及びセル再選択優先順位処理に役立つ。
　このような隣接セル／周波数情報は、同じ目的、つまりサービスの継続性のためにＮＲ　ＭＢＳで引き続き有用であると見なされる。したがって、ＲＡＮ２は、ＭＢＳサービスがブロードキャストされるセル／周波数リストに同意する必要がある。ＵＥは対象のＭＢＳサービスが提供されているセル／周波数を知る必要があるため、隣接セル／周波数情報はＭＢＳセッションＩＤ（ＴＭＧＩなど）に関連付ける必要がある。例えば、ＬＴＥ　ｅＭＢＭＳのようなＳＡＩにさらに関連付けられるセル／周波数リストは更なる検討が必要であり、ＭＢＳ固有のＳＩＢ又はＭＣＣＨを介してブロードキャストされているかどうかも更なる検討が必要である。
　提案１２：ＲＡＮ２は、ＭＢＳセッションＩＤ（ＴＭＧＩなど）に関連付けられている隣接セル／周波数リストがサービス継続性のためにブロードキャストされることに同意する必要がある。ＳＡＩにさらに関連付けられているかどうか、及びＭＢＳ固有のＳＩＢ又はＭＣＣＨで提供されているかどうかは更なる検討が必要である。
　（１６．ＭＢＳ興味インディケーション）
　（１７．基本的な内容）
　ＲＡＮ２は、「ＭＢＳ興味インディケーションがブロードキャストサービスのコネクティッドモードのＵＥでサポートされていると想定する」ことに同意したが、正確なコンテンツについてはまだ議論されていない。
　ＬＴＥでは、ＭＢＭＳ興味インディケーションには、ＲＯＭ関連の設定を除いて、３つのＩＥが含まれる（図１９に示す）。この支援情報は、ｇＮＢのスケジューリングやハンドオーバの決定などのサービスの継続性を確保するのに役立つ。ＳＣ－ＰＴＭと配信モード２の特性は非常に似ているため、同じ情報がＮＲ　ＭＢＳに役立つと見なされる。
　提案１３：ＲＡＮ２は、ＬＴＥのＭＢＭＳ興味インディケーションと同様に、ＭＢＳ興味インディケーションに周波数リスト、ＭＢＳ受信とユニキャスト間の優先順位、及びＭＢＳサービスリストが含まれることに同意する必要がある。
　最小ＭＢＳサービスエリアはＮＲ　ＭＢＳのセルである可能性があるため、ＭＢＳ興味インディケーションには、ＵＥの興味のあるＭＢＳサービスを提供するセルのリストも含める必要があるかどうかが考慮される。ＬＴＥ　ＳＣ－ＰＴＭでは、ｇＮＢが隣接セル情報を提供するため、ｇＮＢがどの隣接セルがどのＭＢＳサービスを提供するかを知っていると想定すると、ＭＢＭＳサービスはそのようなセルを意味する。特に、提案９が同意できる場合、同じ想定がＮＲ　ＭＢＳにも当てはまる。したがって、ＲＡＮ２はｇＮＢを確認する必要がある。
　提案１４：ＲＡＮ２は、ＭＢＳサービスリストがＭＢＳ興味インディケーションに含まれている場合、ＵＥの興味のあるＭＢＳサービスを提供するセルを意味することを確認する必要があり、つまり、ｇＮＢは隣接セルで提供されるＭＢＳサービスを知っていると想定する。
　（１８．高度なコンテンツ）
　ＬＴＥベースライン、つまり上記の提案１３及び提案１４に加えて、ＭＢＳ興味インディケーションが他の支援情報を提供する必要があるかどうかを検討する価値がある。
　例えば、ＭＢＭＳ優先順位は、ＵＥがユニキャスト受信よりもＭＢＭＳ受信を優先するかどうかを示すために使用され、これは、例えば、ｇＮＢのスケジューリングに役立ち、ＮＲ　ＭＢＳで再利用できる。ただし、ＮＲ　ＭＢＳには２つの配信モードがあり、つまり、Ｃ－ＲＮＴＩを使用した配信モード１及びＧ－ＲＮＴＩを使用した配信モード２があり、ＭＴＣＨ送信に関して異なるスケジューリングアルゴリズムに基づいている。したがって、ＵＥが異なる配信モードを介して提供される複数のＭＢＳサービスに興味がある場合、ＵＥが配信モード１の受信と配信モード２の受信との間に優先順位を提供すると役立つ場合がある。必要に応じて説明するＵＥの省電力設定など、他の例を検討することもできる。したがって、ＲＡＮ２はまず、高度な目的のための追加情報がＭＢＳ興味インディケーションによって提供されるかどうかについて議論する必要がある。
　提案１５：ＲＡＮ２は、追加情報がＭＢＳ興味インディケーションによって提供されるかどうか、例えば、配信モード１の受信と配信モード２の受信との間の優先順位について議論する必要がある。
　（１９．メッセージの定義）
　検討する価値のあるもう１つの問題は、ＭＢＳ興味インディケーションが新しい／個別のメッセージであるか、ＵＥ支援情報メッセージと統合されているかである。ＬＴＥでは、前提条件が異なるため、つまり、ＵＡＩのＲＲＣ接続再設定中にＭＩＩのＳＩＢ１５を取得するため、ＭＢＭＳ興味インディケーション（ＭＩＩ）がＵＥ支援情報（ＵＡＩ）から分離される。一方、ＬＴＥでは個別のメッセージであったＩｎ－ｄｅｖｉｃｅＣｏｅｘｉｓｔｅｎｃｅＩｎｄｉｃａｔｉｏｎ（ＩＤＣ）は、ＮＲのＵＡＩに統合されている。ＬＴＥ（及びＮＲ）の前提条件は、ＩＤＣとＵＡＩの間で同じであったため、つまり、ＲＲＣ接続再設定が同じであるため、実現可能である。
　所見５：ＭＢＳ興味インディケーションをＵＥ支援情報と統合できるかどうかは、前提条件が２つのメッセージ間で調整されているかどうかによって異なる。
　ＮＲ　ＭＢＳの場合、提案１０のＩＥでＭＢＳ興味インディケーションメッセージを生成するには、提案９のようなＭＢＳ固有のＳＩＢ又はＭＣＣＨの隣接セル／周波数情報が必要である。また、ＭＢＳ興味インディケーションはＭＢＳ固有のＳＩＢ、ＬＴＥ　ｅＭＢＭＳの場合と同じＳＩＢ（又はＭＣＣＨ）で設定されることが期待される。したがって、ＵＡＩの前提条件、つまりＲＲＣ再設定とは一致していない。したがって、ＭＢＳ興味インディケーションは、ＬＴＥ　ｅＭＢＭＳのように、ＵＡＩとは別のメッセージである必要がある。
　提案１６：ＲＡＮ２は、ＭＢＳ興味インディケーションを新しいメッセージとして、つまりＵＥ支援情報とは別に定義することに同意する必要がある。
　提案１７：ＲＡＮ２は、ＵＥがサービングセルからＭＢＳ固有のＳＩＢを取得できる場合（つまり、前提条件として）、ＭＢＳ興味インディケーションの送信が許可されることに同意する必要がある。
　（２０．マルチキャストセッションのＭＢＳ興味インディケーション）
　ＲＡＮ２は、ＭＢＳ興味インディケーションがブロードキャストセッションでサポートされていると想定していますが、マルチキャストセッションではサポートされていない。マルチキャストセッションの場合、マルチキャストセッションには上位層のセッション参加手順があるため、コアネットワークがｇＮＢにＵＥの興味を通知するというのが一般的な理解のようである。提案１０と図１８の文脈で、それはＵＥの興味のあるＭＢＳサービスに当てはまる。また、提案１１が合意できる場合、ｇＮＢはＭＢＳ周波数とＵＥの興味のあるＭＢＳサービスを提供するセルを知っていることは明らかである。ただし、ＭＢＳ受信とユニキャストの間の優先順位はＬＴＥのＭＢＭＳ優先順位と同様であり、純粋にＡＳ関連の情報であるため、つまり、ＵＥがコアネットワークにセッション参加手順内の優先順位の情報を通知するのは奇妙であるため、コアネットワークによって提供されない場合がある。
　所見６：マルチキャストセッションの場合、コアネットワークはＭＢＳサービスなどのＵＥの興味のあるｇＮＢを提供し、ｇＮＢはＭＢＳ周波数／セルを知るが、コアネットワークとｇＮＢはＭＢＳとユニキャストと間のＵＥのＡＳ優先順位を知らない場合がある。
　優先順位情報は、例えば、サービスの継続性にも関連するＬＴＥ　ｅＭＢＭＳと同様にスケジューリング及びハンドオーバの決定に関して、ｇＮＢにとって依然として有用であると見なされる。したがって、ＵＥは、マルチキャストセッションについても優先順位情報をｇＮＢに通知する必要がある。この意味で、ＲＡＮ２は、マルチキャストサービス／配信モード１でもＭＢＳ興味インディケーションをサポートする必要があることに同意する必要がある。
　提案１８：ＲＡＮ２は、少なくともＵＥがＭＢＳ受信とユニキャストとの間の優先順位をｇＮＢに通知するために、マルチキャストセッション／配信モード１でもＭＢＳ興味インディケーションがサポートされることに同意する必要がある。
　（２１．セル再選択）
　（２２．セル再選択の優先順位の処理）
　ＬＴＥ　ｅＭＢＭＳでは、周波数間セル再選択のために、いわゆる「最高優先ルール」がセル再選択の優先順位の処理に適用される。詳細には、ＵＥは、興味のあるＭＢＭＳサービスを提供する周波数を最優先事項と見なすことができる。また、ＵＥは、興味のあるＭＢＭＳサービスを提供しない周波数を最低の優先順位と見なすことができる。ｅＮＢによって設定された絶対周波数の優先順位に関係なく、ＵＥは対象のＭＢＭＳサービスを提供するセルを再選択できるため、サービスの継続性が保証される。これらのルールは周波数レベルにのみ適用され、ＭＢＭＳサービスが周波数ごとに提供されていると想定すれば十分である。
　所見７：ＬＴＥでは、サービスの継続性は、対象のＭＢＭＳサービスを提供する周波数を最優先事項と見なすことができるＵＥによって保証され、これは、周波数間セルの再選択に適用できる。
　所見８：ＬＴＥでは、ＵＥは、対象のＭＢＭＳサービスを提供していない周波数を最低の優先順位と見なすこともでき、これは、周波数間セルの再選択に適用できる。
　さらに、イントラ周波数及び同等の優先順位のインタ周波数セル再選択、及びＣＥのＮＢ－ＩｏＴ及びＵＥ（つまり、拡張カバレッジ）のために、Ｒ基準（つまり、ランキング）はＳＣ－ＰＴＭ固有のオフセットを適用し、これは「無限大」に設定できる。これは、セルごとに「最高優先順位ルール」を模倣している。これは、「定義されたランキングが、イントラ周波数及びインタ周波数セルの再選択に適用されるため（設定された周波数優先順位に関係なく）、ＵＥは拡張されたカバレッジにある」、つまり、従来の周波数間セル再選択は、ＣＥのＮＢ－ＩｏＴ及びＵＥに適用できない。
　所見９：ＬＴＥでは、ＮＢ－ＩｏＴ　ＵＥとＣＥのＵＥは、Ｒ基準にＳＣ－ＰＴＭ固有のオフセット（「無限大」の場合があります）を適用する。これは、イントラ周波数及び同じ優先順位のインタ周波数セル再選択に適用できる。
　要約すると、ＬＴＥには、周波数間セル再選択（つまり、周波数ベース）と、イントラ周波数及び同等の優先順位のインタ周波数再選択（つまり、セルベース）にそれぞれ適用できる２つのメカニズムがある。周波数間セル再選択の「最優先ルール」は、ＬＴＥ　ｅＭＢＭＳと同様に、アイドル／インアクティブ状態のＵＥが対象のＭＢＳサービスを提供する周波数でキャンプする必要があるため、ＮＲ　ＭＢＳに導入するのは簡単である。したがって、ＲＡＮ２は、ＮＲ　ＭＢＳに「最優先ルール」を導入することに同意する必要がある。さらに、所見５のような「最低優先順位ルール」も導入する必要がある。
　提案１９：ＲＡＮ２は、ＬＴＥと同様に、ＵＥが対象のＭＢＳサービスを提供する周波数を最優先事項と見なす場合があることに同意する必要がある。
　提案２０：ＲＡＮ２は、ＬＴＥと同様に、ＵＥが対象のＭＢＳサービスを提供しない周波数を最低の優先順位と見なす場合があることに同意する必要がある。
　（２３．Ｒ基準）
　もう１つのメカニズム、つまりＲ基準のＳＣ－ＰＴＭ固有のオフセットは、ＮＲ　ＭＢＳの最小サービスエリアがセルと見なされることを考慮に入れる価値があるが、それでもＲｅｌ－１７で優先される展開シナリオ、つまり、周波数ベース又はセルベースに依存する。周波数ベースの展開、つまり同じＭＢＳサービスが特定のＭＢＳサービスエリア内の周波数でセル間で提供されるのは、セルベースの展開のサブセットである。つまり、ＭＢＳサービスは周波数をセルのリストで表すことができるため、ＭＢＳサービスはセルでのみ提供され、これにより、リストには周波数上のすべてのセルが含まれる。したがって、ＭＢＳサービスが基本的にセルごとに提供される場合は、さまざまな展開シナリオをサポートするための柔軟性が高くなる。
　上記のように、ＳＣ－ＰＴＭ固有のオフセットはＲｅｌ－１４のｅＭＴＣ／ＮＢ－ＩｏＴでのマルチキャストサポートのために、つまり、ＣＥでの周波数間セルの再選択がないために導入されたが、特定のセルに優先順位を付けるために使用できる。興味のあるＭＢＭＳサービスを提供する。したがって、同じメカニズムを再利用して、ＵＥの興味のあるＭＢＳサービスを提供するセルに優先順位を付けることができ、これにより、標準化の労力を減らすことができる。
　提案２１：ＲＡＮ２は、ＵＥの興味のあるＭＢＳサービスを提供する特定のセルに優先順位を付けるために、ＭＢＳ固有のオフセットがＲ基準に適用可能であることに同意する必要があり、これにより、ＬＴＥと同様に、オフセットを「無限大」で設定できる。
　［附属書］
　ＬＴＥのＳＩＢ１３
　ＬＴＥのＳＩＢ１３の内容を図２０－図２２に示す。
　ＬＴＥのＳＩＢ１５
　ＬＴＥのＳＩＢ１５の内容を図２３に示す。
　ＬＴＥのＳＩＢ２０
　ＬＴＥのＳＩＢ２０の内容を図２４に示す。
　ＬＴＥのＳＣ－ＭＣＣＨ
　ＬＴＥのＳＣ－ＭＣＣＨの内容を図２５－図２７に示す。
　ＬＴＥでのＭＢＭＳ興味インディケーション
　ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を図２８－図３０に示す。
　ＬＴＥでのセル再選択優先処理
　ＬＴＥでのｅＭＢＭＳ周波数のセル再選択の優先順位を図３１に示す。
　LTEでのセルレベルの優先順位付け
　イントラ周波数におけるセルレベルの優先順位付けと、ＣＥ（ｅＭＴＣを含む）におけるＮＢ－ＩｏＴ及びＵＥのＬＴＥでの同等の優先度のイントラ周波数セル再選択を図３２に示す。
　ＱｏｆｆｓｅｔＳＣＰＴＭがＳＩＢ５でＳＣＰＴＭ周波数オフセットとして設定される例を図３３に示す。
　［付記２］
　（１．導入）
　ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。グループスケジューリングの側面に関して、ＲＡＮ２＃１１４は次の合意に達した。
　Ｇ－ＲＮＴＩとＭＢＳセッション間の１対１のマッピングは、ＮＲ　ＭＢＳでサポートされている。その他のマッピングは更なる検討が必要である。
　Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１対１のマッピングは、ＮＲ　ＭＢＳでサポートされている。その他のマッピングは更なる検討が必要である。
　ＵＥは複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩをサポートできる。これがＵＥの機能に依存するかどうかは更なる検討が必要である。この合意をＲＡＮ１に通知する。
　同じＭＢＳセッションに対応する複数のＭＢＳ　ＱｏＳフローを、１つ又は複数のＭＢＳ無線ベアラにマッピングできる。
　ＭＣＣＨは、ＮＲ　ＭＢＳ配信モード２のＤＬ－ＳＣＨにマッピングされる。
　ＭＴＣＨは、ＮＲ　ＭＢＳのＰＴＭ送信用に規定されている。
　ＭＴＣＨはＤＬ－ＳＣＨにマッピングされる。
　ＤＴＣＨは、ＮＲ　ＭＢＳのＰＴＰ送信に再利用される。
　使用するチャネルに特定のＬＣＩＤスペースが必要かどうかは更なる検討が必要である。
　同じＧ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化は、ＮＲ　ＭＢＳでサポートされている。
　同じＧ－ＣＳ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化がＮＲ　ＭＢＳでサポートされるかどうかは更なる検討が必要である。
　Ｃ－ＲＮＴＩに関連付けられたさまざまな論理チャネルの多重化／逆多重化は、ＮＲ　ＭＢＳでサポートされている。
　付記２では、グループスケジューリングで認識された未解決の問題について議論する。これらの未解決の問題は、配信モード１及び配信モード２の共通の問題と見なされることに注意する。したがって、特に明記されていない限り、所見と提案は両方の配信モードに適用される。
　（２．議論）
　（３．Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間のマッピング）
　ＲＡＮ２は、Ｇ－ＲＮＴＩとＭＢＳセッション間、及びＧ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングに同意したが、他のマッピングがサポートされているかどうかは更なる検討が必要である。
　最も単純なスキームであり、ＮＲ　ＭＢＳのベースラインとして広く再利用されているＬＴＥ　ＳＣ－ＰＴＭで採用されている１：１マッピングの利点は、興味のないＭＢＳセッションを受信しようとすることによる不要なＵＥ電力消費を回避することである。例えば、ＴＭＧＩ＃１のみに興味のあるＵＥは、Ｇ－ＲＮＴＩ＃１のみを監視する必要がある。言い換えると、ＵＥは、他のＧ－ＲＮＴＩとスクランブルされたＰＤＣＣＨによって割り当てられたＰＤＳＣＨをデコードしようとはしない。
　所見１：Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩからＭＢＳセッションへの１：１マッピングは、ＵＥの消費電力と単純さの観点から有益である。
　１：Ｎマッピングに関しては、１つのＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩが複数のＭＢＳセッションを多重化する。例えば、Ｇ－ＲＮＴＩ＃１はＴＭＧＩ＃１とＴＭＧＩ＃２を伝達する。同様のＱｏＳを必要とする一部のＭＢＳセッションが１つのＧ－ＲＮＴＩで送信される可能性があるため、ＮＷの観点から柔軟性が得られる。また、ＵＥが複数のＭＢＳセッションを同時に受信することに興味がある場合、１：ＮマッピングによってＵＥの複雑さが軽減される可能性があることが指摘されている。ただし、そのような最適化が本当に必要かどうかは明確ではない。ＲＡＮ２はすでに「ＵＥは複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩをサポートできる。これがＵＥの機能に依存するかどうかは更なる検討が必要である」ので、複数のＭＣＰＴＴセッションなどを同時に受信する必要があるＵＥはそのような機能（定義されている場合）をサポートするだけである。さらに、１：Ｎマッピングは再送信については非効率であり、例えば、１つのＴＭＧＩのみがＮＡＣＫを受信し、他のＴＭＧＩがＡＣＫを受信する場合、トランスポートブロック全体を再送信する必要がある。
　一方、ＴＭＧＩ＃１のみに興味のあるＵＥは、ＴＭＧＩ＃２からデータをまだ受信する必要があるため、ＵＥの消費電力の観点からは最適ではない。つまり、予想よりも大きなＰＤＳＣＨをデコードする必要がある。
　所見２：Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩからＭＢＳセッションへの１：Ｎマッピングにより、ＮＷの観点からは限られたケースで柔軟性が得られる可能性があるが、ＵＥの電力消費の観点からは最適ではない。
　Ｎ：１マッピングに関しては、複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩが１つのＭＢＳセッションを伝達する。例えば、ＴＭＧＩ＃１はＧ－ＲＮＴＩ＃１とＧ－ＲＮＴＩ＃２に分割されていると考えることができる。ＲＡＮ２は「同じＭＢＳセッションに対応する複数のＭＢＳ　ＱｏＳフローを１つ又は複数のＭＢＳ無線ベアラにマッピングできる」に同意した。これは、これらのＱｏＳフローには異なるＱｏＳが必要であると想定している可能性があり、例えば、ビデオストリーミング用の１つのＱｏＳフローと、同じＭＢＳセッション内のテキスト転送用の別のＱｏＳフローなどである。したがって、これらのＱｏＳフローは、例えば、異なる周期性とリソース量を持つ異なるＧ－ＲＮＴＩで送信されることは理にかなっている。ＵＥは対象のＭＢＳセッション（及びＱｏＳフロー）に関連付けられたＧ－ＲＮＴＩのみを監視する必要があるため、ＵＥの消費電力が大幅に増加することは期待できない。
　注：所見１０のように１：１マッピングでは、同じＭＢＳセッションに対応し、複数のＭＲＢにマッピングされるすべてのＱｏＳフローは、これらのＱｏＳフローのＱｏＳ要件が異なる場合でも、同じＧ－ＲＮＴＩにマッピングする必要がある。１：１マッピングはほとんどの場合効率的であるが、すべての場合で同じではない場合がある。
　所見３：Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのＭＢＳセッションへのＮ：１マッピングは、さまざまなＱｏＳ要件を持つさまざまなＱｏＳフローに対して効率的であり、ＵＥの電力消費への影響が少ない可能性がある。
　上記の所見を考慮すると、Ｎ：１マッピングはサポートする価値があるが、１：Ｎマッピングはあまり有益ではない可能性がある。したがって、ＲＡＮ２は、１：１マッピングに加えて、Ｎ：１マッピングをサポートする必要があるかどうかを議論する必要がある。
　提案１：ＲＡＮ２は、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのＭＢＳセッションへのＮ：１マッピングが追加でサポートされているかどうかを議論する必要がある。
　図９に、複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのＵＥ機能を示す。
　（４．複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのためのＵＥ能力）
　ＲＡＮ２は「ＵＥは複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩをサポートできる」ことに同意したが、「これがＵＥの機能に依存するかどうかは更なる検討が必要である」。
　ＬＴＥ　ＳＣ－ＰＴＭでは、ＵＥ機能ｓｃｐｔｍ－ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ－ｒ１３は図３４のように定義されている。
　ＮＲ　ＭＢＳの場合、同様のＵＥ機能をベースラインとして使用できますが、ＢＷＰ／ＣＦＲ（Ｃｏｍｍｏｎ　Ｆｒｅｑｕｅｎｃｙ　Ｒｅｓｏｕｒｃｅ）の使用など、まだ多くの未解決の問題とＮＲ固有の拡張機能が議論されている。したがって、現時点でＵＥ機能の側面について議論するのは時期尚早である。
　所見４：ＵＥ機能については、機能が固まった後に議論する。
　（５．ＭＣＣＨ及びＭＴＣＨのＬＣＩＤ及びＬＣＩＤスペース）
　ＲＡＮ２は「使用するチャネルに特定のＬＣＩＤスペースが必要かどうかは更なる検討が必要である」とした。ＬＴＥ　ｅＭＢＭＳでは、ＭＣＨのＭＣＣＨ（「０００００」）及びＭＴＣＨ（「００００１－１１１００」、あるケースでは「０００００」）、ＤＬ－ＳＣＨのＳＣ－ＭＣＣＨ及びＳＣ－ＭＴＣＨ（「１１００１」）に別々のＬＣＩＤスペースが用意された。ｅＭＢＭＳはＰＤＣＰレイヤをサポートせず、ＲＬＣ－ＵＭモードのみが適用されたため、これらは実行可能である。
　ＬＴＥ　ＭＢＳＦＮでは、ＭＣＨにＭＣＣＨがない場合、ＭＣＣＨとＭＴＣＨは同じＬＣＩＤ（つまり、「０００００」）を共有できるが、異なるＭＴＣＨには異なるＬＣＩＤ（「００００１－１１１００」）が割り当てられる。「ＭＴＣＨとＭＣＣＨは同じＭＣＨで多重化できる」、「複数のＭＢＭＳサービスは同じＭＣＨにマッピングできる」、つまり、所見１１のように１：Ｎでマッピングするため、ＭＣＣＨと異なるＭＴＣＨを区別するために異なるＬＣＩＤが必要である。言うまでもなく、ＭＣＣＨ／ＭＴＣＨはＭＣＨにマッピングされ、ＤＴＣＨはＤＬ－ＳＣＨにマッピングされるため、ＭＣＣＨ／ＭＴＣＨのＬＣＩＤスペースはユニキャストのＬＣＩＤスペースから分離される。ＭＢＳＦＮのＬＣＩＤ（つまり、ＭＢＭＳエリア固有でありＵＥのグループに共通）がユニキャストの同じＬＣＩＤ（つまり、セル固有及びＵＥ固有）と衝突するのを回避することは有用である。
　所見５：ＬＴＥ　ＭＢＳＦＮでは、各ＭＴＣＨに異なるＬＣＩＤ（１：Ｎマッピングのため最大３２）があり、ＭＣＨにＭＣＣＨがない場合を除き、ＭＣＣＨのＬＣＩＤはＭＴＣＨで共有されない場合があり、ＭＣＣＨ／ＭＴＣＨのＬＣＩＤスペースはＤＴＣＨの場合は１つから分離される。
　ＬＴＥ　ＳＣ－ＰＴＭでは、同じＬＣＩＤ（「１１００１」）がＳＣ－ＭＣＣＨ、ＳＣ－ＭＴＣＨ、及び複数のＳＣ－ＭＴＣＨによって共有される。ＳＣ－ＭＣＣＨはＳＣ－ＲＮＴＩで送信され、「ＳＣ－ＭＣＣＨ及びＳＣ－ＭＴＣＨ送信は、それぞれＰＤＣＣＨ上の論理チャネル固有のＲＮＴＩによって示される（ＳＣ－ＭＴＣＨがマッピングされているＤＬ－ＳＣＨの受信に使用されるＴＭＧＩとＧ－ＲＮＴＩの間には１対１のマッピングがある）」ため、ＳＣ－ＭＣＣＨと異なるＳＣ－ＭＴＣＨを区別するために異なるＬＣＩＤは必要ではない。つまり、ＵＥはこれらのＬＣＨをＲＮＴＩで区別できる。ＭＢＳＦＮと同様に、デフォルトでは、個別のＬＣＩＤスペースがＳＣ－ＰＴＭとユニキャスト間のＬＣＩＤ衝突を回避するために機能する。
　所見６：ＬＴＥＳＣ－ＰＴＭでは、すべてのＭＴＣＨとＭＣＣＨが同じＬＣＩＤを共有し（１：１マッピングと論理チャネル固有のＲＮＴＩのため）、ＬＣＩＤ（スペース）はＤＴＣＨのＬＣＩＤスペースから分離される。
　ＮＲ　ＭＢＳの場合、ＬＴＥ　ＳＣ－ＰＴＭと同様に、ＲＡＮ２が「ＭＣＣＨのスケジューリング用に新しいＲＮＴＩが定義されている」ことに同意したため、ＭＣＣＨはＲＮＴＩによって区別できる。ＭＴＣＨについても同じことが言える。つまり、ＭＴＣＨは、一般にＧ－ＲＮＴＩによって他の論理チャネルと区別できる。
　所見７：ＮＲ　ＭＢＳの場合、ＵＥはＬＣＩＤに関係なく、合意されたＭＣＣＨの新しいＲＮＴＩ又はＭＴＣＨのＧ－ＲＮＴＩのいずれかによってこれらの論理チャネルを区別できるため、ＭＣＣＨ及びＭＴＣＨのＬＣＩＤは他の論理チャネルで共有できる。
　一方、ＭＴＣＨの場合、ＲＡＮ２は、「同じＭＢＳセッションに対応する複数のＭＢＳ　ＱｏＳフローを１つ又は複数のＭＢＳ無線ベアラにマッピングできる」ことに同意した。これにより、図９に示すように、各ＭＲＢが個別のＬＣＨに関連付けられていると単純に想定できる。したがって、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングが採用されている場合でも、ＵＥは同じＭＢＳセッションに属する各ＭＴＣＨを区別できない。つまり、同じＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩは、同じＭＢＳセッションに関連付けられた複数のＭＴＣＨを伝送できる。したがって、ＬＴＥ　ＳＣ－ＰＴＭのように複数のＭＴＣＨで共有される１つのＬＣＩＤの概念は、ＮＲ　ＭＢＳには適用できず、ＬＴＥ　ＭＢＳＦＮのようにＭＴＣＨには複数のＬＣＩＤが必要である。
　所見８：ＮＲ　ＭＢＳの場合、１つのＬＣＩＤを複数のＭＴＣＨで共有することはできない。つまり、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングが想定されている場合でも、同じＭＢＳセッションに属する複数のＭＲＢ／ＭＴＣＨが存在する可能性があるため、複数のＬＣＩＤが必要である。
　一方、ＭＴＣＨのＬＣＩＤを定義する方法は、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングの原則を維持するかどうかにも関係する。１：１マッピングを使用すると、ＵＥは対応するＧ－ＲＮＴＩから各ＭＢＳセッションを知ることができる。したがって、ＬＣＩＤはＭＢＳセッション（又はＧ－ＲＮＴＩ）ごとにグループ化できるため、ＬＣＩＤの数は同じＭＢＳセッションに属するＭＴＣＨの数に等しくなる。例えば、図１０に示すようにＭＢＳセッションの数に関係なく３つのＬＣＩＤである。Ｎ：１マッピングを使用すると、ＵＥは対応するＧ－ＲＮＴＩからの各ＭＢＳセッションも知ることができる。したがって、ＬＣＩＤの数は、同じＧ－ＲＮＴＩにマッピングされたＭＴＣＨの数に等しくなる。例えば、図１０に示すように、ＭＢＳセッションの数に関係なく最大２つのＬＣＩＤになります。１：Ｎマッピングが許可されている場合、ＵＥは各ＭＢＳセッションをＧ－ＲＮＴＩと区別できない。したがって、ＬＣＩＤの数は、すべてのＭＢＳセッションのＭＴＣＨの数と同じである。したがって、１：１又はＮ：１マッピングの場合と比較して、１：Ｎマッピングの場合はより多くのＬＣＩＤが必要になる可能性がある。
　所見９：ＮＲ　ＭＢＳの場合、ＭＴＣＨのＬＣＩＤの数は、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩからＭＢＳセッションへのマッピングルール（１：１、Ｎ：１、又は１：Ｎ）に関連する。
　所見１０：ＮＲ　ＭＢＳの場合、１：１及びＮ：１マッピングルールでは、１：Ｎマッピングと比較して、ＭＴＣＨのＬＣＩＤの数が少なくなる可能性がある。
　上記の所見に照らして、各ＭＴＣＨには異なるＬＣＩＤを割り当てる必要がある。これは、ＭＴＣＨのＬＣＩＤの最大数を定義することを意味する。この時点で、前述のＬＴＥ　ＭＢＳＦＮによれば、このような最大数は３２と見なすことができるが、より少ない数が望ましい場合がある。
　提案２：ＲＡＮ２は、ＭＴＣＨのＬＣＩＤの最大数について議論する必要がある。例えば、可能なベースラインとして、ＬＴＥ　ＭＢＳＦＮに基づく３２ＬＣＩＤ未満である。
　また、上記の所見の文脈では、ＲＡＮ２は、ＬＣＩＤを不必要に消費することを避けるために、ＭＣＣＨとＭＴＣＨが同じＬＣＩＤを共有する可能性があることに同意する必要がある。
　提案３：ＲＡＮ２は、ＭＣＣＨとＭＴＣＨが同じＬＣＩＤを共有する可能性があることに同意する必要がある。つまり、ＵＥは合意された新しいＲＮＴＩによってＭＣＣＨを区別し、Ｇ－ＲＮＴＩによってＭＴＣＨを区別するが、各ＭＴＣＨは対応するＬＣＩＤによって区別される。
　次に、残りの問題は、ＭＢＳのＬＣＩＤスペースをユニキャストのＬＣＩＤスペースと共通にするか、それとも分離するかである。提案２のように３２個のＬＣＩＤを想定すると、ｅＬＣＩＤのスペースが大きいため、ｅＬＣＩＤは、ＭＢＳ専用のこのようなコードポイントを消費することが許容される場合がある。つまり、主にＭＡＣ　ＣＥの場合は１オクテットｅＬＣＩＤにおいて２５６、主にＤＴＣＨの場合は２オクテットｅＬＣＩＤにおいて６５，５３６である。ただし、実際のメリットが不明であるため、このような個別のＬＣＩＤスペースを準備することには疑問がある。ＵＥのＭＡＣの観点から、ＭＡＣ　ＰＤＵを受信して逆多重化した後、各ＭＡＣ　ＳＤＵは対応するＲＬＣエンティティに送信される。つまり、これらのＭＡＣ　ＳＤＵがＭＣＣＨ、ＭＴＣＨ、又はＤＴＣＨのいずれに関連付けられているかに関係なく、ＵＥの動作は同じである。さらに、ＭＢＳサービスが提供されているかどうかに関係なく、ＬＣＩＤのセット（３２など）がデフォルトでＭＢＳ用に予約されている場合、ＬＣＩＤの使用には非効率的である（つまり、ＭＣＣＨ／ＭＴＣＨはセルで送信される）。
　所見１１：ＮＲ　ＭＢＳの場合、ＭＢＳ用に個別のＬＣＩＤスペースを使用することの利点は、ＵＥの観点からは明確ではない。
　さらに、ＮＲ　ＭＢＳはＲｅｌ－１７の単一セル伝送のみをサポートする。つまり、ＳＦＮ（単一周波数ネットワーク）の標準サポートはない。したがって、ｇＮＢは、実装によって、ＭＣＣＨ／ＭＴＣＨのＬＣＩＤ（セル固有であり、すべてのＵＥに共通）を完全に管理して、ＤＴＣＨのＬＣＩＤ（ＵＥ固有）と競合しないようにすることができる。
　所見１２：ＮＲ　ＭＢＳの場合、標準サポートはＲｅｌ－１７の単一セル送信に制限されているため、ＮＷ実装はＭＢＳのＬＣＩＤを管理して、個別のＬＣＩＤスペースがなくてもユニキャストのＬＣＩＤと競合しないようにすることができる。
　一方、将来の保証の観点から、例えば、ＳＦＮの標準サポートの可能性については、ＭＢＳのＬＣＩＤを複数のセル／ｇＮＢ間で調整する必要があるため、ＭＢＳの個別のＬＣＩＤスペースが有益である。つまり、ＬＣＩＤはＭＢＳエリア固有であり、すべてのＵＥに共通であり、ＤＴＣＨのＬＣＩＤ（セル固有及びＵＥ固有）と競合するリスクがある可能性がある。したがって、ＭＢＳの将来の拡張のためだけに、このリリースで個別のＬＣＩＤスペースがＭＣＣＨ／ＭＴＣＨ用に予約されているかどうかを議論する必要がある。
　提案４：ＲＡＮ２は、将来の保証（単一周波数ネットワークのサポートなど）のために、ＭＣＣＨとＭＴＣＨのＬＣＩＤスペースがＤＴＣＨのＬＣＩＤスペースとは別のものであるかどうかを議論する必要がある。
　ちなみに、ＰＴＰ送信に関しては、ＲＡＮ２は「ＮＲ　ＭＢＳのＰＴＰ送信にＤＴＣＨを再利用する」ことに同意した。したがって、ＰＴＰ送信用のＬＣＩＤは、認識された更なる検討が必要であるＲＡＮ２の一部ではないと考えている。つまり、ユニキャストと同じＬＣＩＤスペースを共有するのは非常に自然なことである。ただし、ＲＡＮ２が合意の意図を確認することは有益かもしれない。
　提案５：ＲＡＮ２は、ＰＴＰ送信用のＤＴＣＨがユニキャスト用のＤＴＣＨとＬＣＩＤスペースを共有することを確認する必要がある。つまり、少なくともＭＡＣの観点から、ＰＴＰ送信は従来のユニキャストと同じである。
　（６．異なる論理チャネルの（逆）多重化）
　ＲＡＮ２は「同じＧ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化はＮＲ　ＭＢＳでサポートされている」、及び「Ｃ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化はＮＲ　ＭＢＳでサポートされている」ことに同意した。ＲＡＮ２は「同じＧ－ＣＳ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化がＮＲ　ＭＢＳでサポートされるかどうかは更なる検討が必要である」と残した。
　更なる検討が必要であることは、Ｇ－ＣＳ－ＲＮＴＩで異なる論理チャネルを（逆）多重化するために認識されるが、ＲＡＮ２はすでにＧ－ＲＮＴＩで１つに同意している。Ｇ－ＲＮＴＩと同様に、同じＧ－ＣＳ－ＲＮＴＩで異なる論理チャネルの（逆）多重化をサポートすることに問題はない。
　提案６：ＲＡＮ２は、Ｇ－ＲＮＴＩと同様に、同じＧ－ＣＳ－ＲＮＴＩに関連付けられた異なる論理チャネルの（逆）多重化がサポートされていることに同意する必要がある。
　（７．ＰＴＭ送信用のＤＲＸ）
　ＲＡＮ２は「ＮＲ　ＭＢＳのＰＴＭ送信の場合、ＤＲＸスキームがユニキャスト送信のＤＲＸから独立しているかどうかにかかわらず更なる検討が必要であり、例えば、Ｇ－ＲＮＴＩごとにサポートされる」ことを残した。ＬＴＥ　ＳＣ－ＰＴＭでは、ＳＣ－ＭＴＣＨのＤＲＸはユニキャストのＤＲＸから独立している。言うまでもなく、ＬＴＥ　ＭＢＳＦＮでは、ＭＴＣＨのＤＲＸ（つまり、ＭＢＳＦＮサブフレーム）はユニキャストのＤＲＸから独立している。
　ＮＲ　ＭＢＳの場合、ＭＴＣＨのＤＲＸは複数のＵＥに共通であるのに対し、ユニキャストのＤＲＸはＵＥ固有であるため、同じ原則が適用される。したがって、これらのＤＲＸを調整することは困難で非効率的である。さらに、ＲＡＮ２はすでに「同じＧ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化がＮＲ　ＭＢＳでサポートされる」ことに同意しているため、ＭＴＣＨのＤＲＸはＧ－ＲＮＴＩごとに設定される。ＵＥは、ＰＴＭ送信機会（オン期間）でウェイクアップして、関連するＧ－ＲＮＴＩを監視する。したがって、ＲＡＮ２は、ＤＲＸ設定がユニキャストＤＲＸから独立しているＧ－ＲＮＴＩごとに提供されることに同意する必要がある。
　提案７：ＲＡＮ２は、ＰＴＭのＤＲＸがユニキャストのＤＲＸから独立しており、Ｇ－ＲＮＴＩごとに設定されていることに同意する必要がある。
　（８．配信モード１のＤＲＸパラメータ）
　配信モード１でのＭＴＣＨ受信は、基本的にＲＲＣコネクティッド状態のＵＥによって実行され、動的スケジューリングやＨＡＲＱフィードバック／再送信などをサポートするため、その特性はＤＴＣＨ、つまりユニキャストと同様である。したがって、ユニキャストのＤＲＸパラメータ、つまりＤＲＸ設定を再利用することは理にかなっている。
　提案８：ＲＡＮ２は、配信モード１を介したＰＴＭ送信のＤＲＸパラメータが、ユニキャスト用の１つ、つまりＤＲＸ設定をベースラインとして使用することに同意する必要がある。
　提案８に同意する場合は、配信モード１を介したＰＴＭ送信にどのパラメータを正確に導入する必要があるかを議論する必要がある。図３５に示すように、ＵＬ再送信はＮＲ　ＭＢＳに適用できないため、ＵＬ再送信に関連するパラメータは必要ないことは明らかである。さらに、短いＤＲＸはＭＢＳトラフィックに対してそれほど効率的ではない可能性があるため、短いＤＲＸに関連するパラメータも必要ではない。例えば、一般的なＭＢＳトラフィックは一種の音声及びビデオであると想定されるため、これらの送信サイクルは安定している可能性があり、長いＤＲＸに適合する。また、ＬＴＥ　ＳＣ－ＰＴＭには、図３６に示すように短いＤＲＸオプションがない。言い換えれば、長いＤＲＸ及びＤＬ再送信に関連するパラメータをそのまま再利用できる。
　提案９：提案８（つまり、配信モード１を介したＰＴＭ送信のベースラインとしてのユニキャストＤＲＸ）に加えて、ＲＡＮ２は、ＵＬ再送信及び短いＤＲＸに関連するパラメータが不要であることに同意する必要がある。
　（９．配信モード２のＤＲＸパラメータ）
　ＲＡＮ２は「ＮＲ　ＭＢＳ配信モード２の場合、ＬＴＥ　ＳＣ－ＰＴＭ　ＤＲＸスキームがベースラインとして使用される」ことに同意した。ＬＴＥ　ＳＣ－ＰＴＭのＤＲＸパラメータを図３６に示す。これは、ＤＬ再送信に関連するパラメータの場合、基本的に図３５／提案３０（つまり、配信モード１を介したＰＴＭ送信の場合）と同じである。配信モード２では不要なＤＬ再送に関連するパラメータが除外されている場合、オン期間タイマ、非アクティブタイマ、スケジューリング期間、及び開始オフセットは、大きな問題なしに再利用できる。
　所見１３：配信モード２を介したＰＴＭ送信のＤＲＸパラメータのベースライン、つまり、ＳＣ－ＭＴＣＨスケジューリング情報に基づくベースラインを確認できる。
　（１０．ＰＴＰ送信用のＤＲＸ）
　ＲＡＮ２は「ＰＴＰ送信の場合、ユニキャスト送信のＤＲＸ操作を再利用するかどうかは更なる検討が必要である」ことを残した。一方、ＲＡＮ２はすでに「Ｃ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化はＮＲ　ＭＢＳでサポートされている」ことに同意した。これは、ＭＢＳサービスに属する異なる論理チャネル内に限定されない。つまり、ユニキャストサービスと（逆）多重化される場合がある。さらに、ＲＡＮ２は「ＤＴＣＨはＮＲ　ＭＢＳのＰＴＰ送信に再利用される」ことに同意した。これは、ＭＡＣがＤＴＣＨに対する各ＭＡＣ　ＳＤＵがＤＲＢ又はＭＲＢのどちらに属しているかを知る必要がないことを意味する。また、ＰＴＰ伝送は、既存のユニキャスト伝送と同じＣ－ＲＮＴＩを使用して伝送されることはすでに明らかである。この意味で、ＰＴＰ送信は、少なくともＤＲＸ操作の観点からは、まったく同じであり、ユニキャスト送信と整合する。
　提案１０：ＲＡＮ２は、ＰＴＰ受信の場合、ＵＥはユニキャストのオン期間でのみウェイクアップすることに同意する必要がある。つまり、少なくともＤＲＸの観点からは、追加のオン期間やＰＴＰ送信の特定の拡張はない。
１　　　　　　：移動通信システム
１０　　　　　：ＲＡＮ
２０　　　　　：ＣＮ
１００　　　　：ＵＥ
１１０　　　　：受信部
１２０　　　　：送信部
１３０　　　　：制御部
２００　　　　：ｇＮＢ
２１０　　　　：送信部
２２０　　　　：受信部
２３０　　　　：制御部
２４０　　　　：バックホール通信部

Claims (12)

  1. 　無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、
    　Ｎ個（Ｎ≧２）のグループＲＮＴＩ（Ｇ－ＲＮＴＩ）が１つのマルチキャストブロードキャストサービス（ＭＢＳ）セッションと対応付けられている場合、前記Ｎ個のＧ－ＲＮＴＩの中から前記受信処理に用いるＭ個（Ｍ≦Ｎ）のＧ－ＲＮＴＩを特定することと、
    　前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことと、を有する
    　通信方法。
  2. 　前記受信処理を行うことは、前記ＭＢＳセッションの受信において、前記Ｎ個のＧ－ＲＮＴＩのうち（Ｎ－Ｍ）個のＧ－ＲＮＴＩを前記受信処理に用いることなく、前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことを含む
    　請求項１に記載の通信方法。
  3. 　前記特定することは、
    　前記１つのＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）フローの中から、前記ユーザ装置が受信を希望する所望のＱｏＳフローを特定することと、
    　前記所望のＱｏＳフローと対応付けられた前記Ｍ個のＧ－ＲＮＴＩを特定することと、を含む
    　請求項１又は２に記載の通信方法。
  4. 　前記１つのＭＢＳセッションと前記Ｋ本のＱｏＳフローと前記Ｎ個のＧ－ＲＮＴＩとを対応付ける情報を前記基地局から受信することをさらに有する
    　請求項３に記載の通信方法。
  5. 　前記ＭＢＳセッションの識別子と前記所望のＱｏＳフローに関する識別子とを含むメッセージを前記基地局に送信することをさらに有する
    　請求項３に記載の通信方法。
  6. 　無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、
    　セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いて、専用トラフィックチャネル（ＤＴＣＨ）を受信するための前記受信処理を行うことと、
    　グループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いて、マルチキャストトラフィックチャネル（ＭＴＣＨ）を受信するための前記受信処理を行うことと、
    　前記ＤＴＣＨ及び前記ＭＴＣＨに同一の論理チャネル識別子（ＬＣＩＤ）が割り当てられている場合、前記受信処理に応じて得られた受信データが属する論理チャネルを、当該受信処理に用いたＲＮＴＩに基づいて特定することと、を有する
    　通信方法。
  7. 　前記特定することは、前記受信データに含まれるＬＣＩＤが前記同一のＬＣＩＤである場合、
    　前記Ｃ－ＲＮＴＩを用いた前記受信処理に応じて得られた前記受信データが属する前記論理チャネルとして前記ＤＴＣＨを特定することと、
    　前記Ｇ－ＲＮＴＩを用いた前記受信処理に応じて得られた前記受信データが属する前記論理チャネルとして前記ＤＴＣＨを特定することと、を含む
    　請求項６に記載の通信方法。
  8. 　前記ユーザ装置の媒体アクセス制御（ＭＡＣ）レイヤが、前記特定された論理チャネルに対して前記受信データを出力することをさらに有する
    　請求項６又は７に記載の通信方法。
  9. 　データ無線ベアラ（ＤＲＢ）と前記ＤＴＣＨのＬＣＩＤとを対応付ける情報と、マルチキャスト無線ベアラ（ＭＲＢ）と前記ＭＴＣＨのＬＣＩＤを対応付ける情報と、を前記基地局から受信することをさらに有する
    　請求項６又は７に記載の通信方法。
  10. 　移動通信システムで用いる通信方法であって、
    　基地局が、マルチキャストトラフィックチャネル（ＭＴＣＨ）の受信に用いる設定情報をマルチキャスト制御チャネル（ＭＣＣＨ）上で送信することと、
    　前記基地局が、前記ＭＣＣＨの内容変更に関する通知を、所定タイミングにおいて物理下りリンク制御チャネル（ＰＤＣＣＨ）上でユーザ装置に送信することと、を有し、
    　前記送信することは、前記変更が無い場合、前記変更が無いことを示す前記通知を送信することを含む
    　通信方法。
  11. 　前記送信することは、
    　前記変更が有る場合、前記変更が有ることを示す第１の値を前記通知として送信することと、
    　前記変更が無い場合、前記変更が無いことを示す第２の値を前記通知として送信することと、を含む
    　請求項１０に記載の通信方法。
  12. 　前記ユーザ装置が、前記ＰＤＣＣＨ上で前記第１の値を受信した場合、前記ＭＣＣＨの受信を試みることと、
    　前記ユーザ装置が、前記ＰＤＣＣＨ上で前記第２の値を受信した場合、前記ＭＣＣＨの受信を省略することと、
    　前記所定タイミングにおいて前記ＰＤＣＣＨ上で前記通知を受信できなかった場合、前記ＭＣＣＨの受信を試みることと、をさらに有する
    　請求項１１に記載の通信方法。
PCT/JP2022/029552 2021-08-02 2022-08-01 通信方法 WO2023013608A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023540347A JPWO2023013608A5 (ja) 2022-08-01 通信方法、ユーザ装置
US18/431,737 US20240179722A1 (en) 2021-08-02 2024-02-02 Communication method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163228268P 2021-08-02 2021-08-02
US63/228,268 2021-08-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/431,737 Continuation US20240179722A1 (en) 2021-08-02 2024-02-02 Communication method

Publications (1)

Publication Number Publication Date
WO2023013608A1 true WO2023013608A1 (ja) 2023-02-09

Family

ID=85155655

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/029552 WO2023013608A1 (ja) 2021-08-02 2022-08-01 通信方法

Country Status (2)

Country Link
US (1) US20240179722A1 (ja)
WO (1) WO2023013608A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020502882A (ja) * 2016-11-04 2020-01-23 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信ネットワークにおけるネットワークノード、無線デバイス、およびその中における方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020502882A (ja) * 2016-11-04 2020-01-23 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信ネットワークにおけるネットワークノード、無線デバイス、およびその中における方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LG ELECTRONICS INC.: "Discussion on RAN2 aspects of group scheduling and DRX", 3GPP DRAFT; R2-2106422, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Electronic meeting; 20210519 - 20210527, 11 May 2021 (2021-05-11), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP052007768 *

Also Published As

Publication number Publication date
US20240179722A1 (en) 2024-05-30
JPWO2023013608A1 (ja) 2023-02-09

Similar Documents

Publication Publication Date Title
JP6506887B2 (ja) 無線端末及び基地局
US20230262423A1 (en) Communication control method
WO2022239690A1 (ja) 通信制御方法及びユーザ装置
WO2022085717A1 (ja) 通信制御方法
WO2022025013A1 (ja) 通信制御方法
US20240298217A1 (en) Communication method
JPWO2018084194A1 (ja) 無線端末及び基地局
WO2022239691A1 (ja) 通信制御方法
JP7475458B2 (ja) 通信制御方法、基地局、及びユーザ装置
WO2023140144A1 (ja) 通信方法及びユーザ装置
WO2023013608A1 (ja) 通信方法
WO2023013607A1 (ja) 通信方法
US20240267812A1 (en) Communication method
US20240298381A1 (en) Communication method
JP7425259B2 (ja) 通信制御方法及び基地局
WO2023153452A1 (ja) 通信方法及びユーザ装置
WO2022234847A1 (ja) 通信制御方法及びユーザ装置
US20240357322A1 (en) Communication method
WO2023063323A1 (ja) 通信方法、ユーザ装置、及び基地局
US20240237143A1 (en) Communication method
WO2023132209A1 (ja) 通信方法
JP7259136B2 (ja) 通信制御方法、基地局、ユーザ装置及びプロセッサ
WO2022085646A1 (ja) 通信制御方法
WO2023074721A1 (ja) 通信方法及びユーザ装置
US20240284555A1 (en) Communication method and user equipment

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: 22853027

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023540347

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22853027

Country of ref document: EP

Kind code of ref document: A1