WO2023063323A1 - 通信方法、ユーザ装置、及び基地局 - Google Patents

通信方法、ユーザ装置、及び基地局 Download PDF

Info

Publication number
WO2023063323A1
WO2023063323A1 PCT/JP2022/037903 JP2022037903W WO2023063323A1 WO 2023063323 A1 WO2023063323 A1 WO 2023063323A1 JP 2022037903 W JP2022037903 W JP 2022037903W WO 2023063323 A1 WO2023063323 A1 WO 2023063323A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdcp
mbs
data
base station
hfn
Prior art date
Application number
PCT/JP2022/037903
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 JP2023554539A priority Critical patent/JPWO2023063323A1/ja
Publication of WO2023063323A1 publication Critical patent/WO2023063323A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast

Definitions

  • the present disclosure relates to communication methods, user equipment, and base stations used in mobile communication systems.
  • NR New Radio
  • 5G fifth generation
  • 4G fourth generation
  • MBS multicast broadcast services
  • 5G/NR multicast broadcast services will provide improved services over 4G/LTE multicast broadcast services.
  • an object of the present disclosure is to provide a communication method, a user equipment, and a base station that enable improved multicast broadcast services.
  • a communication method is a communication method executed by a user device that receives a series of PDCP (Packet Data Convergence Protocol) data PDUs (Protocol Data Units) constituting multicast/broadcast service (MBS) data from a base station. and receiving, from the base station, a radio resource control (RRC) Reconfiguration message containing a hyperframe number that is incremented each time the sequence number contained in the PDCP data PDU transmitted by the base station is incremented. and determining initial values of PDCP state variables managed by the user equipment based on the hyperframe number included in the RRC Reconfiguration message.
  • PDCP Packet Data Convergence Protocol
  • PDUs Protocol Data Units
  • MBS multicast/broadcast service
  • a user device is a user device that receives a series of PDCP (Packet Data Convergence Protocol) data PDUs (Protocol Data Units) constituting multicast broadcast service (MBS) data from a base station, A receiving unit that receives from the base station a radio resource control (RRC) Reconfiguration message containing a hyperframe number that is counted up each time the sequence number included in the PDCP data PDU sent by the base station goes around, and the RRC Reconfiguration a control unit that determines initial values of PDCP state variables managed by the user equipment based on the hyperframe number included in the message.
  • PDCP Packet Data Convergence Protocol
  • MMS multicast broadcast service
  • a base station is a base station that transmits a series of PDCP (Packet Data Convergence Protocol) data PDU (Protocol Data Unit) constituting multicast broadcast service (MBS) data to a user device, It comprises a transmission unit that transmits a radio resource control (RRC) Reconfiguration message containing a hyperframe number that is counted up each time the sequence number contained in the PDCP data PDU transmitted by the base station goes around, to the user equipment.
  • PDCP Packet Data Convergence Protocol
  • PDU Protocol Data Unit
  • MMS multicast broadcast service
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to an embodiment
  • FIG. It is a figure which shows the structure of UE (user apparatus) which concerns on embodiment.
  • It is a diagram showing the configuration of a gNB (base station) according to the 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)
  • FIG. 4 is a diagram illustrating an overview of MBS traffic distribution according to an embodiment
  • FIG. 4 is a diagram showing an example of internal processing regarding MBS reception of the UE 100 according to the embodiment;
  • FIG. 4 is a diagram showing another example of internal processing regarding MBS reception of the UE 100 according to the embodiment;
  • FIG. 4 is a diagram showing the operation of the PDCP layer in the mobile communication system according to the embodiment;
  • FIG. 4 is a diagram illustrating an example of PDCP state variables according to an embodiment; It is a figure which shows an example of PDCP data PDU which comprises the MBS data which concerns on embodiment.
  • FIG. 4 illustrates an operation of determining RCVD_COUNT, which is a COUNT value of received PDCP data PDUs, at a receiving PDCP entity of a UE according to an embodiment;
  • FIG. 4 illustrates an example of operation of a receiving PDCP entity in a UE according to an embodiment;
  • FIG. 4 is a diagram illustrating operation of a UE according to an embodiment; It is a figure which shows the operation
  • FIG. 10 is a diagram showing PDCP data PDUs according to the third embodiment; It is a figure which shows the operation
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to an 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 sixth generation
  • 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.
  • 5GC20 includes AMF (Access and Mobility Management Function) and UPF (User Plane Function) 300.
  • AMF performs various mobility control etc. with respect to UE100.
  • AMF manages the mobility of UE 100 by communicating with UE 100 using NAS (Non-Access Stratum) signaling.
  • the UPF controls data transfer.
  • AMF and UPF are connected to gNB 200 via NG interface, which is a base station-core network interface.
  • FIG. 2 is a diagram showing the configuration of the UE 100 (user equipment) according to the 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 gNB 200 (base station) according to the 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.
  • the receiving unit 220 performs various types of reception under the control of the control unit 230.
  • the receiver 220 includes an antenna and a receiver.
  • the receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal (received signal) to the control unit 230 .
  • 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 user plane radio interface protocol includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer. layer.
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • SDAP Service Data Adaptation Protocol
  • the PHY layer performs encoding/decoding, modulation/demodulation, antenna mapping/demapping, and resource mapping/demapping. Data and control information are transmitted between the PHY layer of the UE 100 and the PHY layer of the gNB 200 via physical channels.
  • the PHY layer of UE 100 receives downlink control information (DCI) transmitted from gNB 200 on a physical downlink control channel (PDCCH). Specifically, the UE 100 blind-decodes the PDCCH using the radio network temporary identifier (RNTI), and acquires the successfully decoded DCI as the DCI addressed to the UE 100 itself.
  • the DCI transmitted from the gNB 200 is appended with CRC parity bits scrambled by the RNTI.
  • 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 PDCP layer performs header compression/decompression, encryption/decryption, etc.
  • 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 the RRC of UE 100 and the RRC of gNB 200
  • UE 100 is in the 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 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 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 the MBS traffic channel that transmits MBS data.
  • MTCH configuration information includes MBS session information (including an MBS session identifier to be described later) regarding the MBS session and scheduling information of the MBS traffic channel 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 discontinuous reception setting includes a timer value (On Duration Timer) that defines an on duration (On Duration: reception period), a timer value (Inactivity Timer) that extends the on duration, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), Scheduling or DRX cycle start subframe offset value (Start Offset, DRX Cycle Offset), ON period timer start delay slot value (Slot Offset), timer value defining maximum time until retransmission (Retransmission Timer), HARQ It may include any one or more parameters of timer value (HARQ RTT Timer) that defines the minimum interval to DL allocation for retransmission.
  • HARQ RTT Timer timer value that defines the minimum interval to DL allocation for retransmission.
  • 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: Down Link-Shared CHannel), which is a type of transport channel.
  • DL-SCH Down Link-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 using 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
  • the UE 100 may receive MTCH using the group RNTI (G-RNTI) assigned by the gNB 200.
  • G-RNTI corresponds to MTCH reception RNTI.
  • the G-RNTI may be included in MBS reception settings (MTCH setting information).
  • 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.
  • FIG. 8 is a diagram showing an example of internal processing related to MBS reception by the UE 100 according to the embodiment.
  • FIG. 9 is a diagram illustrating another example of internal processing regarding MBS reception of the UE 100 according to the embodiment.
  • MBS radio bearer is one radio bearer that carries a multicast or broadcast session. That is, there are cases where an MRB is associated with a multicast session and where an MRB is associated with a broadcast session.
  • the MRB and the corresponding logical channel are set from gNB 200 to UE 100 by RRC signaling.
  • the MRB setup procedure may be separate from the data radio bearer (DRB) setup procedure.
  • DRB data radio bearer
  • one MRB can be configured as "PTM only (PTM only)", “PTP only (PTP only)", or "both PTM and PTP".
  • PTM only PTM only
  • PTP PTP only
  • the type of such MRB can be changed by RRC signaling.
  • MRB#1 is associated with a multicast session and a dedicated traffic channel (DTCH)
  • MRB#2 is associated with a multicast session and MTCH#1
  • MRB#3 is associated with a broadcast session and MTCH#2.
  • the DTCH is scheduled using the cell RNTI (C-RNTI).
  • MTCH is scheduled using G-RNTI.
  • 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 (MAC entity) of the UE 100 processes the data received on the DL-SCH, and corresponds to the received data based on the logical channel identifier (LCID) included in the header (MAC header) included in the received data. to the corresponding logical channel (corresponding RLC entity).
  • LCID logical channel identifier
  • FIG. 9 shows an example in which DTCH and MTCH are associated with MRB associated with a multicast session. Specifically, one MRB is divided (split) into two legs, one leg is associated with DTCH, and the other leg is associated with MTCH. The two legs are combined at the PDCP layer (PDCP entity). That is, the MRB is an MRB of both PTM and PTP (both PTM and PTP). Such an MRB is sometimes called a split MRB.
  • FIG. 10 is a diagram showing the operation of the PDCP layer in the mobile communication system 1 according to the embodiment.
  • the gNB 200 transmits MBS data of a certain MBS session to multiple UEs 100 (UE 100a to UE 100c in the example of FIG. 10) by PTM (multicast or broadcast).
  • the RRC state of each 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.
  • the gNB 200 has, in the PDCP layer, a transmitting PDCP entity 201 associated with the MBS session (specifically, a transmitting PDCP entity associated with the multicast radio bearer (MRB) belonging to the MBS session).
  • a transmitting PDCP entity 201 associated with the MBS session
  • MBS multicast radio bearer
  • the transmitting side PDCP entity 201 starts transmitting an MBS session, it manages PDCP state variables that are updated according to the transmission of PDCP data PDUs (Protocol Data Units) in the MBS session.
  • PDCP data PDUs Protocol Data Units
  • Each UE 100 has a receiving side PDCP entity 101 associated with the MBS session (specifically, a receiving side PDCP entity associated with the MRB belonging to the MBS session) in the PDCP layer.
  • Each receiving side PDCP entity 101 (receiving side PDCP entity 101a to receiving side PDCP entity 101c in the example of FIG. 10) is updated according to reception of PDCP data PDUs in the MBS session when starting to receive the MBS session.
  • Manage PDCP state variables are managed according to reception of PDCP data PDUs in the MBS session when starting to receive the MBS session.
  • the PDCP state variable is a count value (COUNT value) consisting of a hyperframe number (HFN) that is incremented each time the PDCP sequence number goes around, and a PDCP sequence number (PDCP SN).
  • COUNT value has a bit length of 32 bits
  • the PDCP SN has a bit length (SN_length) of 12 or 18 bits
  • the HFN is the bit length of the COUNT value minus the bit length of the PDCP SN.
  • the bit length of PDCP SN may be set by RRC signaling.
  • the PDCP SN bit length may be the default value (predetermined fixed value).
  • PDCP state variable is not limited to referring to the COUNT value, but is also used as a term to indicate various variables (HFN or PDCP SN, or TX_NEXT, RX_NEXT, RX_DELIV, RX_REORD, etc.) handled in the PDCP layer.
  • FIG. 12 is a diagram showing an example of PDCP data PDUs forming MBS data.
  • the PDCP data PDU has PDCP SN, data, and MAC-I.
  • PDCP SN is a sequence number sequentially assigned to PDCP data PDUs.
  • the data corresponds to a PDCP SDU (Service Data Unit).
  • MAC-I corresponds to a message authentication code.
  • a PDCP data PDU may not have a MAC-I.
  • a PDCP data PDU has a PDCP SN but no HFN. Therefore, each of the gNB 200 and the UE 100 needs to update the HFN according to the transmission/reception of the PDCP data PDU, specifically, count up each time the PDCP sequence number completes one cycle.
  • FIG. 13 is a diagram showing the operation of identifying RCVD_COUNT, which is the COUNT value of PDCP data PDUs received in UE 100 (receiving side PDCP entity 101).
  • RCVD_COUNT the COUNT value of PDCP data PDUs received in UE 100 (receiving side PDCP entity 101).
  • the PDCP SN included in the received PDCP data PDU is called RCVD_SN.
  • RX_DELIV is a variable representing the oldest PDCP SDU waiting for reception and not yet provided to the upper layer.
  • the initial value of RX_DELIV is zero. Note that in PTM reception, the initial value of RX_DELIV may be set using the SN of the first received packet.
  • Window_Size is a constant that indicates the size of the reordering window.
  • RCVD_HFN HFN(RX_DELIV) is.
  • RCVD_COUNT [RCVD_HFN, RCVD_SN] is set to
  • FIG. 14 is a diagram showing an example of the operation of the receiving side PDCP entity 101 of the UE 100.
  • FIG. 14 is a diagram showing an example of the operation of the receiving side PDCP entity 101 of the UE 100.
  • Step S12 when receiving a PDCP PDU (PDCP data PDU), the receiving side PDCP entity 101 performs security processing (specifically, deciphering/integrity verification) using the count value (RCVD_COUNT) on the PDCP PDU.
  • security processing specifically, deciphering/integrity verification
  • RCVD_COUNT count value
  • step S12 The PDCP entity 101 on the receiving side, if the integrity verification is successful (step S12: No), if the count value (RCVD_COUNT) is smaller than RX_DELIV (step S14: Yes), or if the RCVD_COUNT has been received (step S16 : Yes), discard the relevant PDCP PDU (step S15).
  • RX_NEXT is a variable that indicates the count value (RCVD_COUNT) of PDCP SDUs expected to be received next.
  • the initial value of RX_NEXT is zero. Note that in PTM reception, the initial value of RX_NEXT may be set using the SN of the first received packet.
  • step S20 If Out-of-order delivery is configured (step S20: Yes), the receiving side PDCP entity 101 passes the PDCP PDU to the upper layer after header decompression (step S21). Specifically, the PDCP entity 101 on the receiving side performs the operation of step S21 when "outOfOrderDelivery" is set in RRC. Out of order delivery is the operation of passing packets to the upper layer without performing order control. Therefore, as in step S21, as soon as the packet is received and stored in the buffer, the packet is transferred to the upper layer. In addition, when step S20 is "No", order control will be performed.
  • T-Reordering is a timer used to detect missing PDCP data PDUs.
  • RX_REORD is a variable that indicates the COUNT value following the COUNT value associated with the PDCP data PDU that triggered T-Reordering.
  • the initial value of the PDCP state variable is zero, and when data transmission from gNB 200 (transmitting PDCP entity 201) to UE 100 (receiving PDCP entity 101) starts, gNB 200 (transmitting PDCP entity 201) and PDCP state variables are updated synchronously in the UE 100 (receiving side PDCP entity 101).
  • the UE 100 (one of the UE 100a to UE 100c) is not necessarily able to start receiving MBS from the time the gNB 200 starts providing the MBS session (multicast session or broadcast session).
  • the PDCP state variables of the gNB 200 transmitting side PDCP entity 201) and the UE 100 (receiving side PDCP entity 101) become unsynchronized, and the PDCP layer operation as described above cannot be performed properly.
  • any UE 100 may start receiving MBS from the middle of the MBS session provided by the gNB 200.
  • Such a UE 100 may also be a UE 100 that has undergone a cell change (eg, cell reselection or handover) from another gNB 200 (another cell).
  • FIG. 15 is a diagram showing the operation of the UE 100 according to the embodiment.
  • the receiving PDCP entity 101 of the UE 100 receives from the gNB 200 a series of PDCP data PDUs that make up the MBS data transmitted over PTM from the gNB 200 .
  • a PDCP data PDU may also be referred to as a PDCP MRB data PDU.
  • step S1 the UE 100 that receives a specific MRB uses an HFN (specifically, the specific MRB Receive the current (latest) HFN in the gNB 200 from the gNB 200 .
  • HFN specifically, the specific MRB Receive the current (latest) HFN in the gNB 200 from the gNB 200 .
  • the UE 100 may request the gNB 200 to provide an HFN.
  • the UE 100 may request the gNB 200 to provide an HFN in response to satisfying the condition regarding the inability to receive MBS data (PDCP data PDU) normally.
  • the UE 100 is a first condition indicating that the time for which MBS reception failure continues exceeds a predetermined time, and a second condition indicating that the number of consecutive MBS reception failures exceeds a predetermined time.
  • the UE 100 may request the gNB 200 to provide the HFN in response to satisfying the third condition indicating that the UE 100 does not have the current (latest) HFN information.
  • the UE 100 may request the gNB 200 to provide an HFN if the UE 100 does not have a current HFN due to being interested in receiving or starting receiving from the middle of a broadcast session.
  • a configuration example of such a request signal will be described in the fourth embodiment.
  • the receiving side PDCP entity 101 of the UE 100 may receive a PDCP control PDU containing HFN or a PDCP data PDU containing HFN in the header from the transmitting side PDCP entity 201 of the gNB 200.
  • an RNTI for multiple UEs eg, G-RNTI, MCCH-RNTI, SI-RNTI, etc.
  • a single UE-oriented RNTI eg, C-RNTI
  • the UE 100 applies the HFN only in the receiving side PDCP entity 101 associated with the specific MRB.
  • the RRC entity of UE 100 may receive a message including HFN (eg, RRC Reconfiguration message, SIB, or MCCH) from the RRC entity of gNB 200.
  • the message may include an HFN and an MRB identifier, MBS service identifier (eg, TMGI) and/or logical channel identifier (LCID) associated with the HFN.
  • MBS service identifier eg, TMGI
  • LCID logical channel identifier
  • the UE 100 applies the HFN only in the receiving side PDCP entity 101 associated with the MRB indicated by the MRB identifier and/or MBS service identifier included in the message. Note that when the SIB includes an HFN, it is not necessary to increment the Value Tag due to the HFN change.
  • the MAC entity of UE100 may receive a MAC control element (MAC CE) including HFN from the MAC entity of gNB200.
  • MAC CE MAC control element
  • an RNTI for multiple UEs eg, G-RNTI, MCCH-RNTI, SI-RNTI, etc.
  • a single UE-oriented RNTI eg, C-RNTI
  • the MAC CE may include an HFN and an MRB identifier, MBS service identifier (eg, TMGI) and/or logical channel identifier (LCID) associated with the HFN.
  • the UE 100 applies the HFN only in the receiving side PDCP entity 101 associated with the MRB indicated by the MRB identifier and/or MBS service identifier included in the message.
  • step S2 the receiving side PDCP entity 101 of the UE 100 manages the HFN received from the gNB 200 in step S1 and the PDCP SN included in the PDCP data PDU received by the UE 100 from the gNB 200.
  • UE 100 (receiving side PDCP entity 101), the HFN received from gNB 200 in step S1, PDCP state variables according to the result of combining the PDCP SN included in the PDCP data PDU received by UE 100 from gNB 200 (for example, RX_NEXT, RX_DELIV).
  • the UE 100 sets the initial value of RX_NEXT to (x +1) modulo (2 [sl-PDCP-SN-Size] ) and the initial value of RX_DELIV is (x - 0.5 ⁇ 2 [sl-PDCP-SN-Size-1] ) modulo (2 [sl-PDCP-SN-Size] ) may be determined by where x is the SN of the first received packet.
  • step S3 the receiving side PDCP entity 101 of the UE 100 initializes the PDCP state variables with the initial values determined in step S2. That is, the receiving side PDCP entity 101 of the UE 100 sets the initial values determined in step S2 as PDCP state variables.
  • the UE 100 performs the operation according to the embodiment in response to the conditions (for example, any of the first to third conditions described above) regarding the inability to normally receive MBS data (PDCP data PDU). may be executed. That is, the UE 100 may perform the operation according to the embodiment under a situation where it can be determined that there is a possibility that the PDCP state variables are out of synchronization. The UE 100 may ignore or discard the HFN received from the gNB 200 in step S1 if none of the first to third conditions are satisfied.
  • the PDCP state variables can be synchronized so that the PDCP layer operations as described above can be performed properly.
  • the operation according to the embodiment is not limited to the case where the UE 100 that starts receiving MBS from the middle of the MBS session executes, but the UE 100 that has changed cells (for example, cell reselection or handover) from other gNB 200 (other cells) may be executed.
  • the other gNB 200 (other cell) that is the cell change source is called the source
  • the gNB 200 (cell) that is the cell change destination is called the target. If the HFN is not synchronized between cells (source and target), the UE 100 receiving MBS data transmitted in PTM may perform operations according to the above embodiments.
  • the source and/or target may notify the UE 100 that HFNs are not synchronized between cells.
  • the source and/or target may inform the UE 100 of the cell identities of neighboring cells whose HFNs are not synchronized.
  • the source and/or target may inform the UE 100 of the cell identifiers of neighboring cells with which HFNs are synchronized.
  • the UE 100 may determine whether to perform the operations according to the above-described embodiments when moving to the target (for example, when starting to receive MBS data from the target). Based on the notification, the UE 100 may decide to perform the operation according to the above embodiment only when it is determined that the HFNs are not synchronized between cells (between the source and the target).
  • Example Assuming the operation according to the above embodiment, the first to fourth examples will be described. In these examples, two or more examples may be combined and implemented.
  • UE 100 shall receive HFN from gNB 200 before receiving the first PDCP data PDU from gNB 200 .
  • the UE 100 stores the HFN received from the gNB 200.
  • UE 100 receives the first PDCP data PDU from gNB 200 after receiving HFN from gNB 200 .
  • the UE 100 determines initial values of PDCP state variables from the stored HFN and the PDCP SN included in the first PDCP data PDU.
  • FIG. 16 is a diagram showing the operation according to the first embodiment.
  • step S101 the gNB 200 notifies the UE 100 of the current HFN of the MBS data.
  • UE 100 receives the HFN.
  • step S102 the receiving side PDCP entity 101 of the UE 100 stores (in memory) the HFN received in step S101.
  • step S103 the UE 100 starts receiving MBS data.
  • the gNB 200 starts transmitting MBS data before step S103.
  • step S104 the transmitting side PDCP entity 201 of the gNB200 transmits the first PDCP data PDU to the UE100.
  • the receiving PDCP entity 101 of the UE 100 receives the first PDCP data PDU.
  • step S105 the receiving side PDCP entity 101 of the UE 100 confirms the PDCP SN included in the header of the first PDCP data PDU received in step S104.
  • step S106 the receiving side PDCP entity 101 of the UE 100 reads (from memory) the HFN stored in step S102. Then, the receiving side PDCP entity 101 of the UE 100 determines the initial values of the PDCP state variables from the read HFN and the PDCP SN confirmed in step S105, and initializes the PDCP state variables. The UE 100 may delete (discard) the stored HFN from the memory after the initialization of the PDCP state variables is completed.
  • step S107 the transmitting side PDCP entity 201 of the gNB 200 transmits the second and subsequent PDCP data PDUs to the UE 100.
  • the receiving PDCP entity 101 of the UE 100 receives the second and subsequent PDCP data PDUs.
  • step S108 the receiving side PDCP entity 101 of the UE 100 updates the PDCP state variables according to the PDCP data PDU received in step S107.
  • UE 100 shall receive HFN from gNB 200 after receiving at least one PDCP data PDU from gNB 200 .
  • PTM data transmission is already in progress for another UE 100 and the UE 100 enters the session with a delay (starts reception)
  • data reception may precede HFN reception. have a nature.
  • UE 100 receives at least one PDCP data PDU from gNB 200 before receiving HFN from gNB 200 .
  • UE 100 stores the at least one PDCP data PDU.
  • the UE 100 determines the initial value of the PDCP state variable from the HFN and the PDCP SN included in the first PDCP data PDU among the stored PDCP data PDUs.
  • the UE 100 suspends processing of MBS data received before HFN is provided (stores data), initializes PDCP state variables when HFN is provided, and performs data reception processing (PDCP processing ).
  • FIG. 17 is a diagram showing the operation according to the second embodiment.
  • step S201 the UE 100 starts receiving MBS data while the PDCP state variables have not yet been initialized.
  • step S202 the transmitting side PDCP entity 201 of the gNB 200 transmits at least one PDCP data PDU constituting MBS data to the UE 100.
  • the receiving PDCP entity 101 of the UE 100 receives the at least one PDCP data PDU.
  • the receiving side PDCP entity 101 of the UE 100 stores the PDCP data PDU received in step S202 in a buffer before performing PDCP processing.
  • the PDCP entity 101 on the receiving side has a buffer in the stage prior to PDCP processing (specifically, the stage immediately after input to the PDCP entity and before performing the above-described PDCP reception processing).
  • the receiving side PDCP entity 101 of the UE 100 may store them in the buffer in the order received.
  • the receiving side PDCP entity 101 of the UE 100 receives a plurality of PDCP data PDUs in step S202
  • the PDCP SNs of the PDCP data PDUs may be rearranged in ascending (or increasing) order and stored in the buffer.
  • step S204 the gNB 200 notifies the UE 100 of the current HFN.
  • UE 100 receives the HFN.
  • step S205 the receiving side PDCP entity 101 of the UE 100 confirms the HFN received in step S204 and the PDCP SN included in the first PDCP data PDU stored in step S203.
  • the receiving side PDCP entity 101 of the UE 100 stores a plurality of PDCP data PDUs in step S203, it acquires the PDCP SN from the PDCP data PDU with the smallest PDCP SN or the PDCP data PDU with the largest PDCP SN.
  • the receiving side PDCP entity 101 of the UE 100 may acquire the PDCP SN from the first received PDCP data PDU.
  • step S206 the receiving side PDCP entity 101 of the UE 100 determines the initial values of the PDCP state variables from the HFN and PDCP SN confirmed in step S205, and initializes the PDCP state variables.
  • step S207 the receiving side PDCP entity 101 of the UE 100 sequentially performs PDCP processing on at least one PDCP data PDU stored in the buffer in step S203.
  • step S208 the transmitting PDCP entity 201 of the gNB 200 transmits PDCP data PDUs to the UE 100.
  • the receiving PDCP entity 101 of the UE 100 receives PDCP data PDUs.
  • step S209 the receiving side PDCP entity 101 of the UE 100 updates the PDCP state variables according to the PDCP data PDU received in step S208.
  • the UE 100 receives the HFN at the same time it receives the PDCP data PDU from the gNB 200 . Specifically, UE 100 receives from gNB 200 a PDCP data PDU having a header containing HFN. However, if the header always contains the HFN, the overhead becomes large.
  • a third embodiment introduces a variable format (eg, variable header) that allows dynamic HFN insertion.
  • the header of the PDCP data PDU may include a flag indicating that the header includes HFN.
  • FIG. 18 is a diagram showing the operation according to the third embodiment. It is assumed that the UE 100 is receiving or interested in receiving MBS data transmitted on PTM.
  • step S301 the transmitting side PDCP entity 201 of the gNB 200 transmits to the UE 100 a PDCP data PDU containing the current HFN in its header.
  • the receiving PDCP entity 101 of the UE 100 receives the PDCP data PDU.
  • the receiving side PDCP entity 101 of the UE 100 may wait to receive a PDCP data PDU that includes HFN in its header.
  • the receiving side PDCP entity 101 of the UE 100 may wait for the PDCP data PDU only when the gNB 200 sets the use of the PDCP data PDU.
  • Such configuration may be done by RRC signaling.
  • a PDCP data PDU that includes an HFN in its header may be defined as a PDCP data PDU with a different format from a PDCP data PDU that does not include an HFN. For example, it may be defined as an existing PDCP data PDU when there is no HFN, and as a PDCP MRB data PDU when there is an HFN.
  • step S302 the receiving side PDCP entity 101 of the UE 100 confirms the HFN and SN included in the PDCP data PDU received in step S301.
  • step S303 the receiving side PDCP entity 101 of the UE 100 determines the initial values of the PDCP state variables from the HFN and PDCP SN confirmed in step S302, and initializes the PDCP state variables.
  • step S304 the transmitting side PDCP entity 201 of the gNB 200 transmits PDCP data PDUs to the UE 100.
  • This PDCP data PDU may not contain an HFN.
  • the receiving PDCP entity 101 of the UE 100 receives PDCP data PDUs.
  • step S305 the receiving side PDCP entity 101 of the UE 100 updates the PDCP state variables according to the PDCP data PDU received in step S304.
  • FIG. 19 is a diagram showing a PDCP data PDU according to the third embodiment.
  • the PDCP data PDU with HFN shown in FIG. 19 may be defined as the PDCP MRB data PDU.
  • "Oct 1" of the PDCP data PDU shown in FIG. 19 is a 1-bit "H” field in addition to a 1-bit "D/C" field indicating whether the PDU is a control PDU or a data PDU.
  • the "H" field is a reserved field "R”, so "0" is normally set.
  • HFN is set in the first half of "Oct 2" to "Oct 4" of the PDCP data PDU shown in FIG.
  • the PDCP SN is set in the second half of "Oct 4" to "Oct 5" of the PDCP data PDU shown in FIG. Then, data is stored from "Oct 6".
  • the HFN field is positioned before the PDCP SN field, but the HFN field may be positioned after the PDCP SN field.
  • FIG. 19 shows a format example in which the HFN field is provided in the header, but the HFN field may be provided after the data or after the MAC-I field. In this case, similarly to the format shown in FIG. 19, the "H" field may indicate whether or not the HFN field is added.
  • the UE 100 fails to receive PTM for a certain period of time due to coverage holes or interference, or when the UE 100 enters another cell (handover, cell reselection), the UE 100 receives the PDCP data PDU normally. may not be able to receive In these cases, the PDCP state variables may become out of sync and the current HFN and/or PDCP SN values may not be known.
  • the HFN is still synchronized with the gNB200, so it is possible that only the initialization of the PDCP SN part will suffice. For example, if the HFN at the time of reception failure is applied as it is, and if the PDCP process fails, for example, by applying the HFN of "+1", the COUNT value is synchronized with the gNB 200, and reception may be resumed normally.
  • the UE 100 initializes the PDCP state variables under the condition that the UE 100 cannot normally receive the PDCP data PDU.
  • the UE 100 has a first condition indicating that the time for which MBS reception failure continues exceeds a predetermined time, and a second condition indicating that the number of consecutive MBS reception failures exceeds a predetermined time.
  • a request signal requesting provision of HFN may be transmitted to the gNB 200 when at least one of the two conditions is satisfied.
  • UE100 receives HFN transmitted from gNB200 according to a request signal.
  • the UE 100 may initialize PDCP state variables with initial values in response to at least one of the first condition and the second condition being satisfied.
  • FIG. 20 is a diagram showing the operation according to the fourth embodiment.
  • step S401 the UE 100 receives MBS data (PTM reception) from the gNB 200.
  • MBS data PTM reception
  • the UE 100 determines whether or not the condition regarding the inability to normally receive MBS data (PDCP data PDU) is satisfied.
  • the UE 100 is a first condition indicating that the time for which MBS reception failure continues exceeds a predetermined time, and a second condition indicating that the number of consecutive MBS reception failures exceeds a predetermined time. , determines whether at least one of the conditions is satisfied.
  • the UE 100 may make a determination only for reception failures in PTM (-leg).
  • the UE 100 may use a timer to detect that reception has failed for a certain period of time. For example, the UE 100 measures the duration of reception failure. When reception fails, the UE 100 sets a certain period (set value) in the timer and then activates the timer. The setting value of the timer may be set from the gNB 200 to the UE 100. The UE 100 may manage the timer separately for each G-RNTI or each MTCH, for example. The UE 100 stops the timer when reception is successful. On the other hand, if the timer expires, the UE 100 may decide to perform PDCP state variable initialization processing.
  • the UE 100 may use a counter to detect that reception has failed a certain number of times in succession. For example, the UE 100 operates a counter for each MTCH reception opportunity to measure the number of continuous reception failures. The UE 100 increments the counter by 1 when reception fails. The UE 100 may manage the counter separately for each G-RNTI or each MTCH, for example. The UE 100 initializes the count value of the counter to zero upon successful reception. On the other hand, when the count value of the counter exceeds the threshold, the UE 100 may decide to perform the PDCP state variable initialization process. The threshold may be set from the gNB 200 to the UE 100.
  • the UE 100 may make a determination using a combination of timers and counters.
  • the UE 100 performs an initialization process of PDCP state variables when the number of reception failures occurring within a certain period of time exceeds a threshold. For example, the UE 100 starts a timer and sets a counter to zero at some point. The UE 100 increments the counter by 1 for each reception failure while the timer is running. If the timer expires, the UE 100 restarts the timer and sets the counter to zero. On the other hand, if the counter exceeds the threshold, the UE 100 may decide to perform PDCP state variable initialization processing.
  • the UE 100 may detect the possibility of out-of-synchronization of PDCP state variables (HFN, PDCP SN). For example, the UE 100 has a discrepancy between the COUNT value stored in the receiving side PDCP entity 101 and the COUNT value derived from the PDCP SN included in the received PDCP data PDU (both COUNT values are separated by a certain amount or more). ), it may decide to perform an initialization process for the PDCP state variables.
  • the security processing deciphering/integrity verification
  • the PDCP state variable initialization processing may decide to do
  • the UE 100 may decide to perform PDCP state variable initialization processing when starting reception at a target whose PDCP state variables (HFN, PDCP SN) are not synchronized with the source.
  • PDCP state variables HFN, PDCP SN
  • condition determination in step S402 may be performed in any layer of PDCP/RLC/MAC, and the determination result may be notified to RRC.
  • the UE 100 transmits a request signal requesting provision of the current HFN to the gNB 200.
  • the request signal may be RRC signaling such as a UE Assistance Information message or an MBS Interest Indication message.
  • the request signal may be a PDCP control PDU, a PDCP data PDU, or a MAC CE.
  • the request signal may be a random access preamble transmitted using a special PRACH resource (a special time/frequency resource or a special preamble sequence). The method of using a random access preamble as a request signal is suitable for UE 100 in RRC idle state or RRC inactive state.
  • the request signal may include an MRB identifier that identifies an MRB that wants to provide HFN.
  • the request signal may also include an MBS session identifier (eg, TMGI) identifying the MBS session for which HFN is desired.
  • the request signal may also include a Logical Channel Identifier (LCID) identifying the logical channel on which HFN is desired to be provided.
  • a PDCP data PDU is used as the request signal
  • the request signal may be a PDCP data PDU having a header with a flag bit set to "1" indicating a request for provision of HFN.
  • step S404 gNB 200 notifies UE 100 of the current HFN in response to the request signal received from UE 100 in step S403. UE 100 receives the HFN.
  • UEs other than the UE 100 that transmitted the request signal can also receive the HFN. Even if the other UEs that are able to perform MBS reception successfully receive the HFN, they may ignore or discard the received HFN and may not use the HFN to initialize PDCP state variables.
  • step S405 the UE 100 determines the initial values of the PDCP state variables from the HFN received in step S404 and the PDCP SN included in the received PDCP data PDU, and initializes the PDCP state variables. Subsequent operations are the same as in the above embodiment.
  • 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. Also, 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.
  • a program that causes a computer to execute each process performed by the UE 100 or the gNB 200 may be provided.
  • the program may be recorded on a computer readable medium.
  • a computer readable medium allows the installation of the program on the computer.
  • the computer-readable medium on which the program is recorded may be a non-transitory recording medium.
  • the non-transitory recording medium is not particularly limited, but may be, for example, a recording medium such as CD-ROM or DVD-ROM.
  • a circuit that executes each process performed by the UE 100 or gNB 200 may be integrated, and at least part of the UE 100 or gNB 200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).
  • the terms “based on” and “depending on,” unless expressly stated otherwise, “based only on.” does not mean The phrase “based on” means both “based only on” and “based at least in part on.” Similarly, the phrase “depending on” means both “only depending on” and “at least partially depending on.” Also, “obtain/acquire” may mean obtaining information among stored information, or it may mean obtaining information among information received from other nodes. or it may mean obtaining the information by generating the information.
  • the terms “include,” “comprise,” and variations thereof are not meant to include only the recited items, and may include only the recited items or in addition to the recited items. Means that it may contain further items.
  • 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.
  • one MRB can be configured with PTM only, PTP only, or both PTM and PTP. Either PTM, PTM+PTP, or PTP only can be changed by RRC signaling.
  • a PDCP SR can be generated when the bearer type of the RRC signal is changed, and how to generate a PDCP SR when it occurs.
  • the SN part of the COUNT value of these variables is set according to the SN of the packet originally received (by the UE) and optionally the HFN indicated by the gNB. .
  • the MRB configuration allows the 0 RLC state variable of the PTP RLC receive window to be set to the initial value (0).
  • a PDCP SR can be generated when the bearer type of the RRC signal is changed, and how to generate a PDCP SR when it occurs.
  • PDCP status reports are triggered by RRC when the following events occur, mainly for AM DRBs (and sometimes UM DRBs).
  • the receiving PDCP entity shall trigger a PDCP status report when: - Upper layers request re-establishment of the PDCP entity. - Higher layers request PDCP data recovery. - Higher layers request uplink data switching. - The upper layer reconfigures the PDCP entity to release DAPS and daps-SourceRelease is configured in TS 38.331.
  • the receiving PDCP entity shall trigger a PDCP status report when: Higher layers request uplink data switching.
  • PTM-only MRBs are configured only with RLC UM, but PTP-only MRBs and split MRB PTP legs are configured with RLC UM or RLC AM. These are called UM MRB and AM MRB respectively.
  • the UE performance requirement for RRC reconfiguration processing delay is specified at 10ms. Therefore, the UE may miss MBS transmissions during RRC reconfiguration for bearer type change, and the missing packets need to be compensated after bearer type change. In this sense, PDCP status reports should be supported at least to meet the higher reliability requirements of certain MBS services.
  • Proposal 1 RAN2 should agree that PDCP status reporting is supported at least between AM MRBs and for change of lossless bearer type from UM MRB to AM MRB.
  • UM MRB is not considered to require reliability when changing bearer types, that is, lossless. However, whether or not UM MRB is used for "high QoS" MBS service can actually be left to the implementation of the NW.
  • PTM-only MRBs for UEs with good radio conditions, and reconfiguring to PTP-only MRBs (or split MRBs) when the radio conditions deteriorate beyond a certain level, the NW can efficiently use resources. can be effectively operated.
  • the UM DRB allows the UM DRB to trigger a PDCP status report in certain cases, it is readily apparent that the UM MRB can be configured to determine whether the NW requires a PDCP status report. be.
  • the PTP-only MRB and split-MRB PTP legs need to be configured with a DL/UL bidirectional UM, ie a DL RLC entity for MBS data reception and a UL RLC entity for PDCP status report transmission.
  • Proposal 2 RAN2 should agree that whether or not to use the PDCP status report when changing the UM MRB bearer type is up to the NW implementation. For that purpose, a specification that can configure PTP with DL/UL bidirectional RLC UM is required.
  • the SN part of the COUNT value of these variables is set according to the SN of the first received packet (by the UE) and optionally the HFN indicated by the gNB.
  • Option 1 The initial value of each state variable is simply set to the SN of the first received packet.
  • the initial value of the SN part of RX_NEXT is (x+1) modulo(2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU'.
  • the initial value of the SN part of RX_DELIV is (x - 0.5 ⁇ 2 [sl-PDCP-SN-Size-1] ) modulo (2 [sl-PDCP-SN-Size] ), x is SN of the first received PDCP Data PDU".
  • RLC UM 'RX_Next_Reassemble' it is 'initialized to the SN of the first received UMD PDU containing the SN'.
  • RLC UM "RX_Next_Highest” it is "initialized to the SN of the first received UMD PDU containing the SN".
  • Option 3 A new mechanism for RLC UM is introduced.
  • RLC UM “RX_Next_Reassemble” is initialized to a value prior to “RX_Next_Highest”.
  • RLC UM “RX_Next_Highest” "initialized to the SN of the first received UMD PDU containing the SN", similar to option 2 above.
  • option 2 the next received packet, RX_NEXT, is set to ([SN of first received packet]+1).
  • RX_DELIV the first packet not delivered to upper layers, is set to ([SN of first received packet]-[1/4 of SN length]). This means that reordering can occur even if older packets are received after the first received packet. Therefore, option 2 is considered more reliable than option 1.
  • Proposal 3 RAN2 agrees with PDCP to set the initial value of RX_NEXT to be ([SN of first received packet] + 1) modulo (2 ⁇ [PDCP SN length]), similar to Rel-16 V2X Should.
  • Proposal 4 RAN2 sets the initial value of RX_DELIV to ⁇ [SN of the first received packet]-2 ⁇ ([PDCP SN length]-2) ⁇ modulo(2 ⁇ [PDCP SN length ]) should be agreed on the PDCP.
  • option 1 and option 2 are exactly the same. Also, options 2 and 3 are the same in terms of RX_Next_Highest. Therefore, RAN2 should confirm that there is no other solution for the initial value of RX_Next_Highest.
  • Proposal 5 RAN2 should agree with RLC UM that the initial value of RX_Next_Highest is the SN of the first received packet, similar to Rel-16 V2X.
  • Options 2 and 3 are different with respect to RX_Next_Reassemble.
  • the advantages of option 3 are similar to option 2 of PDCP state variables. In other words, discarding old packets received after the first received packet can be avoided. It has also been pointed out that this problem only occurs when RLC segmentation is performed, but it is always good if packet loss is minimized.
  • RAN2 should discuss for RLC UM whether the initial value of RX_Next_Reassembly is the SN of the first received packet (same as Rel-16 V2X) or the previous value of RX_Next_Highest.
  • Alt. 1 RRC reconstruction Alt. 2: PDCP Control PDU Alt. 3: MCCH Alt. 4: SIBs Alt. 5: Header of PDCP data PDU
  • Alt. 1 is considered simple as the gNB needs to configure an MRB for multicast to the UE via RRC reconfiguration, i.e. the HFN is set up together with the MRB.
  • RRC reconfiguration is signaling dedicated to a specific UE and is basically used only in the first delivery mode (Delivery mode 1: DM1), Alt.
  • DM1 Delivery mode 1
  • the processing is a little heavy compared to 2.
  • additional information may be required to indicate to which MRBs the HFN applies.
  • Alt. 2 is considered to be more lightweight and efficient signaling as the gNB can indicate the HFN over the PTM. Since the PDCP entity is associated with the MRB, no additional information HFN-to-MRB mapping is required. In other words, the PDCP entity that receives this PDCP control PDU should apply HFN as an initial value. This is commonly used in the first delivery mode and the second delivery mode (Delivery mode 2: DM2). Also, since the same PDCP entity processes these PDCP PDUs, the timing gap between the PDCP Control PDU and the first received packet could be minimized. However, there is concern that PDCP control PDUs are not secure.
  • Alt. 3 is another possibility, but MCCH is only applicable to the second delivery mode, and it is considered undesirable to impose the additional burden of acquiring MCCH on UEs receiving the first delivery mode. Also, there may be a certain timing gap between the MCCH reception and the first received packet. Furthermore, Alt. Mandatory acquisition of MCCH is not preferred as additional information may be required, similar to 1, HFN to MRB mapping.
  • Alt. 4 is considered as the normal provisioning method. SIB basically applies to both first delivery mode 1 and second delivery mode, but it is still unclear whether UEs connected for multicast reception are mandated to monitor SIB. . As a point of concern, Alt. 2 that the SIB is unsecured, Alt. As with 1, additional information is generated in HFN to MRB mapping, and there is a constant timing gap between the SIB reception and the first received packet. Also, when applying on-demand SI, the UE needs to send an on-demand SI request message before obtaining the SIB, which may cause HFN initialization delays.
  • Alt. 5 Similar advantages to 2 are seen. That is, it can be delivered in a PTM manner, no additional information is required, and it is a common solution for the first delivery mode and the second delivery mode.
  • Alt. The most important advantage is theoretically the timing gap, since the first packet received by 5 carries the HFN together. However, assuming that the HFN is included in the header of the first received packet, given that the packet is starting to be sent to other UEs over the PTM, how does the gNB find the UE's first received packet? It is questionable whether we know how. Otherwise, the gNB should always include the HFN in each data packet.
  • a concern is Alt. Similar to 2, the PDCP header is not secured. HFN provisioning is Alt. It is a bit strange from a concept/principle point of view as it is considered C-plane signaling as well as other alternatives including 2.
  • Alt. 5 uses U-plane data.
  • DM1 (or multicast) is generally more secure than DM2 (or broadcast). This is because the configuration is provided by dedicated signaling (and session join procedures are available in the NAS). In this sense, HFN also needs to be provided securely in DM1. In this case the simplest solution is Alt. 1, but not suitable to achieve commonality between DM1 and DM2. Alt. 2, if the PDCP Control PDU is sent on the C-RNTI, Alt. 3, Alt. 4, Alt. It is assumed that a certain degree of security can be ensured compared to 5.
  • DM2 should not obligate the UE to transition to CONNECTED, it is only intended for HFN acquisition.
  • HFN is provided periodically in a broadcast manner (ie, using G-RNTI, MCCH-RNTI, or SI-RNTI).
  • HFN As noted above (as also summarized in the table below), it is a good balance of performance and security that HFN be provided via PDCP Control PDUs (i.e. Alt.2), and , is slightly preferred as it is a common solution for both delivery modes (ie DM1 and DM2).
  • Proposal 7 RAN2 should agree that the HFN initial value is provided via the PDCP Control PDU.
  • Proposal 8 If Proposal 7 is agreeable, RAN2 should also agree that PDCP Control PDUs (for HFN provisioning) can be sent together with G-RNTI and C-RNTI.
  • the UE may receive data before receiving HFN. This is because the reception timing of the HFN and the first received packet may differ due to out-of-order delivery (eg, retransmissions in bad radio conditions and/or retransmissions during handover, etc.). and/or depending on which option in Section 2.2.2 is selected. Moreover, the PTM transmission has already started to be sent to other UEs, so the UE can receive the data as soon as it sets the MRB.
  • out-of-order delivery eg, retransmissions in bad radio conditions and/or retransmissions during handover, etc.
  • 1 UE may receive MBS data via PTM before HFN initialization.
  • RX_NEXT and RX_DELIV are (re)set to their initial values when RRC requests PDCP entity establishment, PDCP entity re-establishment, or PDCP entity suspension.
  • the initialization of the COUNT value is performed before data reception. Therefore, from a PDCP perspective, data may not be received even if the lower layers are ready to receive the data.
  • the RLC layer sends an RLC SDU (PDCP PDU) to the PDCP layer, the data may not be received. Even if PDCP accepts these PDCP PDUs, these PDUs will be discarded due to integrity verification failure because the HFN is still aolitic.
  • PDCP PDUs from lower layers may not be accepted or may be discarded at the PDCP layer.
  • Proposal 9 RAN2 should discuss how to process data packets received by the UE before HFN initialization.
  • HFN Provisioning Request Another possible issue is whether the UE is allowed to ask the gNB for the current HFN. Especially in the case of PTM-only MRBs, the HFN can become unsynchronized if the UE fails to receive packets for a period of time, eg due to coverage holes or interference. Another case is when the UE later joins an already activated MBS session if the HFN is only provided at MBS session activation (as briefly described in Section 2.2.2). It is sometimes necessary to have an HFN.
  • the UE may not receive the next packet outside the reception window. In this case, the UE may reset all state variables to initial values.
  • Proposal 10 RAN2 should discuss whether the UE is allowed to request the gNB to provide the current HFN of the MBS session.
  • Proposal 11 RAN2 should discuss whether the state variable can be reset if the UE fails to receive an MBS session for a certain period of time.
  • Lossless Mobility Operation RAN2 states: "R2 aims to support lossless handover of MBS-MBS mobility for services that require it (Scenario details TBD, but at least PTP-PTP)" and " From the UE side, PDCP status reporting may also be supported.” These agreements imply a mechanism very similar to existing handovers for unicast when the MRB is configured with PTP only.
  • PTM (-leg)
  • MRB configured only with PTM and split MRB including PTP leg and PTM leg.
  • a split MRB can be regarded as a PTP-only MRB if the PTM leg is not used. Therefore, lossless handover can be easily supported based on conventional unicast handover.
  • the basic procedure of the split MRB is considered as follows.
  • Step 1 The PTP leg of the split MRB is used with lossless dynamic switching at the source cell as needed.
  • Step 2 UE performs PTP-PTP handover (or like unicast handover), lossless handover.
  • Step 3 The PTM leg of the split MRB is used in the target cell with lossless dynamic switching if necessary.
  • Step 1 In the source cell, reconfigure MRB for PTM to MRB for PTP (or split MRB) due to lossless bearer type change.
  • Step 2 UE performs lossless handover as PTP-PTP handover (or like unicast handover).
  • Step 3 A lossless bearer type change allows a PTP-only MRB (or split MRB) to be reconfigured to a PTM-only MRB in the target cell if necessary.
  • Lossless bearer type change is essential for PTM-only MRB lossless handover.
  • Proposal 12 RAN2 should agree that MRB's basic lossless handover should always include PTP (-leg). That is, either the PTP leg of the split MRB is used, or the PTM-only MRB is reconfigured into a PTP-only MRB (or split MRB) before performing the handover.
  • Proposal 13 RAN2 should agree that MRB handover execution is the same as unicast handover, ie no extensions for basic lossless handover are needed.
  • the next most interesting advanced procedure is direct PTM-PTM handover. That is, the UE receiving MBS over PTM (-leg) performs lossless handover. It can reduce the signaling overhead and complexity of the above basic handover procedure. That is, steps 1 and 3 can be skipped. Moreover, such direct PTM-PTM lossless handovers are expected especially in split MRBs with PTP legs. used for services that require higher reliability. However, it is already past the halfway point of the Release 17 timeframe and WID only states that it "specifies support for basic mobility with service continuity". As such, advanced lossless handover should be deferred until a future release.
  • Multicast MBS Interest Indication RAN2 currently assumes that MBS Interest Indication is supported in broadcast sessions, but not in multicast sessions.
  • RAN2#115e agreed on the basic content of the MBS Interest Indication as follows.
  • MBS frequency list Priority between reception of all listed MBMS frequencies and reception of any unicast bearer TMGI list If MBS frequency reporting is allowed, the MBS frequency reported by the UE is LTE Like SC-PTM, they are sorted in descending order of interest.
  • the core network informs the gNB of the UE's interest, since there are higher layer session join procedures in the multicast session. This applies to the UE's interested MBS service. It is also possible that the gNB knows the MBS frequency and the cell that provides the MBS service of interest to the UE. However, the priority between MBS reception and unicast may not be provided by the core network as it is purely AS related information.
  • the core network provides the MBS service of interest to the UE to the gNB, and the gNB may know the MBS frequency/cell. However, the core network and gNB may not know the UE's AS priority between MBS and unicast.
  • priority information is also useful for gNBs, such as scheduling and handover decisions, and is considered to be related to service continuity. Therefore, the UE also needs to notify the gNB of the priority information for the multicast session. In this sense, RAN2 should agree that MBS Interest Indication should be supported for multicast service/delivery mode 1 as well.
  • Proposal 14 RAN2 should agree that MBS Interest Indication is also supported in multicast session/first delivery mode, at least for UE to inform gNB of priority between MBS reception and unicast reception. be.
  • RAN 20 CN 100: UE 101 : Receiving side PDCP entity 110 : Receiving unit 120 : Transmitting unit 130 : Control unit 200 : gNB 201: transmitting side PDCP entity 210: transmitting section 220: receiving section 230: control section 240: backhaul communication section

Landscapes

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

Abstract

第１の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰデータＰＤＵを基地局から受信するユーザ装置で実行する方法である。前記通信方法は、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を、前記基地局から受信するステップと、前記ハイパーフレーム番号と、前記基地局から前記ユーザ装置が受信するＰＤＣＰデータＰＤＵに含まれるＰＤＣＰシーケンス番号とから、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定するステップと、を有する。

Description

通信方法、ユーザ装置、及び基地局
　本開示は、移動通信システムで用いる通信方法、ユーザ装置、及び基地局に関する。
　３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）規格において、第５世代（５Ｇ）の無線アクセス技術であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）の技術仕様が規定されている。ＮＲは、第４世代（４Ｇ）の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。３ＧＰＰにおいて、５Ｇ／ＮＲのマルチキャストブロードキャストサービス（ＭＢＳ）の技術仕様を策定する議論が行われている（例えば、非特許文献１参照）。
　５Ｇ／ＮＲのマルチキャストブロードキャストサービスは、４Ｇ／ＬＴＥのマルチキャストブロードキャストサービスよりも改善されたサービスを提供することが望まれる。
　そこで、本開示は、改善されたマルチキャストブロードキャストサービスを実現可能とする通信方法、ユーザ装置、及び基地局を提供することを目的とする。
　第１の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）を基地局から受信するユーザ装置で実行する通信方法であって、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ）　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記基地局から受信することと、前記ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号に基づいて、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定することと、を有する。
　第２の態様に係るユーザ装置は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）を基地局から受信するユーザ装置であって、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ）　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記基地局から受信する受信部と、前記ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号に基づいて、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定する制御部と、を備える。
　第３の態様に係る基地局は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）をユーザ装置に送信する基地局であって、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ）　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記ユーザ装置に送信する送信部を備える。
実施形態に係る移動通信システムの構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 実施形態に係るＭＢＳトラフィック配信の概要を示す図である。 実施形態に係る配信モードを示す図である。 実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の一例を示す図である。 実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の他の例を示す図である。 実施形態に係る移動通信システムにおけるＰＤＣＰレイヤの動作を示す図である。 実施形態に係るＰＤＣＰ状態変数の一例を示す図である。 実施形態に係るＭＢＳデータを構成するＰＤＣＰデータＰＤＵの一例を示す図である。 実施形態に係るＵＥの受信側ＰＤＣＰエンティティにおいて受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。 実施形態に係るＵＥの受信側ＰＤＣＰエンティティの動作の一例を示す図である。 実施形態に係るＵＥの動作を示す図である。 第１実施例に係る動作を示す図である。 第２実施例に係る動作を示す図である。 第３実施例に係る動作を示す図である。 第３実施例に係るＰＤＣＰデータＰＤＵを示す図である。 第４実施例に係る動作を示す図である。
　図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（移動通信システムの構成）
　図１は、実施形態に係る移動通信システムの構成を示す図である。移動通信システム１は、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ　Ｇｅｎｅｒａｔｉｏｎ　Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。また、移動通信システムには第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
　移動通信システム１は、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ　Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）２０とを有する。以下において、ＮＧ－ＲＡＮ１０を単にＲＡＮ１０と呼ぶことがある。また、５ＧＣ２０を単にコアネットワーク（ＣＮ）２０と呼ぶことがある。
　ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）又はタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ　ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ　ＵＥ）である。
　ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と呼ばれる）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数（以下、単に「周波数」と呼ぶ）に属する。
　なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。
　５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。
　図２は、実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。受信部１１０及び送信部１２０は、ｇＮＢ２００との無線通信を行う無線通信部を構成する。
　受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
　送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１３０は、ＵＥ１００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　図３は、実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。送信部２１０及び受信部２２０は、ＵＥ１００との無線通信を行う無線通信部を構成する。バックホール通信部２４０は、ＣＮ２０との通信を行うネットワーク通信部を構成する。
　送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
　制御部２３０は、ｇＮＢ２００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　バックホール通信部２４０は、基地局間インターフェイスであるＸｎインターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ　Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がフロントホールインターフェイスであるＦ１インターフェイスで接続されてもよい。
　図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。なお、ＵＥ１００のＰＨＹレイヤは、ｇＮＢ２００から物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される下りリンク制御情報（ＤＣＩ）を受信する。具体的には、ＵＥ１００は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＰＤＣＣＨのブラインド復号を行い、復号に成功したＤＣＩを自ＵＥ宛てのＤＣＩとして取得する。ｇＮＢ２００から送信されるＤＣＩには、ＲＮＴＩによってスクランブルされたＣＲＣパリティビットが付加されている。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化等を行う。
　ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。
　図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤを有する。
　ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間にコネクション（ＲＲＣコネクション）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間にコネクション（ＲＲＣコネクション）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間のコネクションがサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＡのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。また、ＮＡＳレイヤよりも下位のレイヤをＡＳレイヤと呼ぶ。
　（ＭＢＳの概要）
　実施形態に係るＭＢＳの概要について説明する。ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ　Ｔｏ　Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳのユースケース（サービス種別）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ　ｔｏ　Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ　ｐｒｏｔｏｃｏｌ　ｔｅｌｅｖｉｓｉｏｎ）、グループ通信、及びソフトウェア配信等が想定される。
　ブロードキャストサービスは、高信頼性のＱｏＳを必要としないアプリケーションのために、特定のサービスエリア内のすべてのＵＥ１００に対してサービスを提供する。ブロードキャストサービスに用いるＭＢＳセッションをブロードキャストセッションと呼ぶ。
　マルチキャストサービスは、すべてのＵＥ１００に対してではなく、マルチキャストサービス（マルチキャストセッション）に参加しているＵＥ１００のグループに対してサービスを提供する。マルチキャストサービスに用いるＭＢＳセッションをマルチキャストセッションと呼ぶ。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でＵＥ１００のグループに対して同じコンテンツを提供できる。
　図６は、実施形態に係るＭＢＳトラフィック配信の概要を示す図である。
　ＭＢＳトラフィック（ＭＢＳデータ）は、単一のデータソース（アプリケーションサービスプロバイダ）から複数のＵＥに配信される。５Ｇコアネットワークである５Ｇ　ＣＮ（５ＧＣ）２０は、アプリケーションサービスプロバイダからＭＢＳデータを受信し、ＭＢＳデータのコピーの作成（Ｒｅｐｌｉｃａｔｉｏｎ）を行って配信する。
　５ＧＣ２０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信（５ＧＣ　Ｓｈａｒｅｄ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）及び５ＧＣ個別ＭＢＳトラフィック配信（５ＧＣ　Ｉｎｄｉｖｉｄｕａｌ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）の２つのマルチキャスト配信方法が可能である。
　５ＧＣ個別ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、ＵＥ１００ごとのＰＤＵセッションを介してそれらのＭＢＳデータパケットの個別のコピーを個別のＵＥ１００に配信する。したがって、ＵＥ１００ごとに１つのＰＤＵセッションをマルチキャストセッションと関連付ける必要がある。
　５ＧＣ共有ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、それらのＭＢＳパケットの単一コピーをＲＡＮノード（すなわち、ｇＮＢ２００）に配信する。ｇＮＢ２００は、ＭＢＳトンネル接続を介してＭＢＳデータパケットを受信し、それらを１つ又は複数のＵＥ１００に配信する。
　ＲＡＮ（５Ｇ　ＲＡＮ）１０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信方法における無線を介したＭＢＳデータの送信には、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）の２つの配信方法が可能である。ＰＴＰはユニキャストを意味し、ＰＴＭはマルチキャスト及びブロードキャストを意味する。
　ＰＴＰ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの個別のコピーを無線で個々のＵＥ１００に配信する。他方、ＰＴＭ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの単一コピーを無線でＵＥ１００のグループに配信する。ｇＮＢ２００は、１つのＵＥ１００に対するＭＢＳデータの配信方法としてＰＴＭ及びＰＴＰのどちらを用いるかを動的に決定できる。
　ＰＴＰ配信方法及びＰＴＭ配信方法は主としてユーザプレーンに関するものである。ＭＢＳデータ配信の制御モードとしては、第１配信モード及び第２配信モードの２つの配信モードがある。
　図７は、実施形態に係る配信モードを示す図である。
　第１配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　１：ＤＭ１）は、ＲＲＣコネクティッド状態のＵＥ１００が利用できる配信モードであって、高ＱｏＳ要件のための配信モードである。第１配信モードは、ＭＢＳセッションのうちマルチキャストセッションに用いられる。但し、第１配信モードがブロードキャストセッションに用いられてもよい。第１配信モードは、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００も利用可能であってもよい。
　第１配信モードにおけるＭＢＳ受信の設定は、ＵＥ固有（ＵＥ－ｄｅｄｉｃａｔｅｄ）シグナリングにより行われる。例えば、第１配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にユニキャストで送信されるＲＲＣメッセージであるＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又はＲＲＣ　Ｒｅｌｅａｓｅメッセージ）により行われる。
　ＭＢＳ受信の設定は、ＭＢＳデータを伝送するＭＢＳトラフィックチャネルの設定に関するＭＢＳトラフィックチャネル設定情報（以下、「ＭＴＣＨ設定情報」と呼ぶ）を含む。ＭＴＣＨ設定情報は、ＭＢＳセッションに関するＭＢＳセッション情報（後述のＭＢＳセッション識別子を含む）と、このＭＢＳセッションに対応するＭＢＳトラフィックチャネルのスケジューリング情報とを含む。ＭＢＳトラフィックチャネルのスケジューリング情報は、ＭＢＳトラフィックチャネルの間欠受信（ＤＲＸ）設定を含んでもよい。間欠受信設定は、オン期間（Ｏｎ　Ｄｕｒａｔｉｏｎ：受信期間）を定義するタイマ値（Ｏｎ　Ｄｕｒａｔｉｏｎ　Ｔｉｍｅｒ）、オン期間を延長するタイマ値（Ｉｎａｃｔｉｖｉｔｙ　Ｔｉｍｅｒ）、スケジューリング間隔もしくはＤＲＸサイクル（Ｓｃｈｅｄｕｌｉｎｇ　Ｐｅｒｉｏｄ、ＤＲＸ　Ｃｙｃｌｅ）、スケジューリングもしくはＤＲＸサイクルの開始サブフレームのオフセット値（Ｓｔａｒｔ　Ｏｆｆｓｅｔ、ＤＲＸ　Ｃｙｃｌｅ　Ｏｆｆｅｓｔ）、オン期間タイマの開始遅延スロット値（Ｓｌｏｔ　Ｏｆｆｓｅｔ）、再送時までの最大時間を定義するタイマ値（Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ　Ｔｉｍｅｒ）、ＨＡＲＱ再送のＤＬ割り当てまでの最小間隔を定義するタイマ値（ＨＡＲＱ　ＲＴＴ　Ｔｉｍｅｒ）のいずれか一つ以上のパラメータを含んでもよい。
　なお、ＭＢＳトラフィックチャネルは論理チャネルの一種であって、ＭＴＣＨと呼ばれることがある。ＭＢＳトラフィックチャネルは、トランスポートチャネルの一種である下りリンク共有チャネル（ＤＬ－ＳＣＨ：Ｄｏｗｎ　Ｌｉｎｋ―Ｓｈａｒｅｄ　ＣＨａｎｎｅｌ）にマッピングされる。
　第２配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　２：ＤＭ２）は、ＲＲＣコネクティッド状態のＵＥ１００だけではなく、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００が利用できる配信モードであって、低ＱｏＳ要件のための配信モードである。第２配信モードは、ＭＢＳセッションのうちブロードキャストセッションに用いられる。但し、第２配信モードは、マルチキャストセッションにも適用可能であってもよい。
　第２配信モードにおけるＭＢＳ受信の設定は、ブロードキャストシグナリングにより行われる。例えば、第２配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にブロードキャストで送信される論理チャネル、例えば、ブロードキャスト制御チャネル（ＢＣＣＨ）及び／又はマルチキャスト制御チャネル（ＭＣＣＨ）により行われる。ＵＥ１００は、例えば、技術仕様で予め規定された専用のＲＮＴＩを用いてＢＣＣＨ及びＭＣＣＨを受信できる。ＢＣＣＨ受信用のＲＮＴＩがＳＩ－ＲＮＴＩであって、ＭＣＣＨ受信用のＲＮＴＩがＭＣＣＨ－ＲＮＴＩであってもよい。
　第２配信モードにおいて、ＵＥ１００は、次の３つの手順でＭＢＳデータを受信してもよい。第１に、ＵＥ１００は、ｇＮＢ２００からＢＣＣＨ上で伝送されるＳＩＢ（ＭＢＳ　ＳＩＢ）によりＭＣＣＨ設定情報を受信する。第２に、ＵＥ１００は、ＭＣＣＨ設定情報に基づいてｇＮＢ２００からＭＣＣＨを受信する。ＭＣＣＨは、ＭＴＣＨ設定情報を伝送する。第３に、ＵＥ１００は、ＭＴＣＨ設定情報に基づいて、ＭＴＣＨ（ＭＢＳデータ）を受信する。以下において、ＭＴＣＨ設定情報及び／又はＭＣＣＨ設定情報をＭＢＳ受信設定と呼ぶことがある。
　第１配信モード及び第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００から割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いてＭＴＣＨを受信してもよい。Ｇ－ＲＮＴＩは、ＭＴＣＨ受信用ＲＮＴＩに相当する。Ｇ－ＲＮＴＩは、ＭＢＳ受信設定（ＭＴＣＨ設定情報）に含まれていてもよい。
　なお、ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｇｒｏｕｐ　Ｉｄｅｎｔｉｔｙ）、ソーススペシフィックＩＰマルチキャストアドレス（アプリケーション機能やアプリケーションサーバ等のソースユニキャストＩＰアドレスと、宛先アドレスを示すＩＰマルチキャストアドレスとから成る）、セッション識別子、及びＧ－ＲＮＴＩのうち少なくとも１つにより識別される。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、及びセッション識別子の少なくとも１つをＭＢＳセッション識別子と呼ぶ。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、セッション識別子、及びＧ－ＲＮＴＩを総括してＭＢＳセッション情報と呼ぶ。
　図８は、実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の一例を示す図である。図９は、実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の他の例を示す図である。
　１つのＭＢＳ無線ベアラ（ＭＲＢ）は、マルチキャストセッション又はブロードキャストセッションを伝送する１つの無線ベアラである。すなわち、ＭＲＢにマルチキャストセッションが対応付けられる場合と、ＭＲＢにブロードキャストセッションが対応付けられる場合とがある。
　ＭＲＢ及び対応する論理チャネル（例えば、ＭＴＣＨ）は、ＲＲＣシグナリングによってｇＮＢ２００からＵＥ１００に設定される。ＭＲＢの設定手順は、データ無線ベアラ（ＤＲＢ）の設定手順と分離されていてもよい。ＲＲＣシグナリングでは、１つのＭＲＢを、「ＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）」、「ＰＴＰのみ（ＰＴＰ　ｏｎｌｙ）」、又は「ＰＴＭ及びＰＴＰの両方（ｂｏｔｈ　ＰＴＭ　ａｎｄ　ＰＴＰ）」で設定できる。このようなＭＲＢの種別はＲＲＣシグナリングにより変更できる。
　図８において、ＭＲＢ＃１にはマルチキャストセッション及び専用トラフィックチャネル（ＤＴＣＨ）が対応付けられ、ＭＲＢ＃２にはマルチキャストセッション及びＭＴＣＨ＃１が対応付けられ、ＭＲＢ＃３にはブロードキャストセッション及びＭＴＣＨ＃２が対応付けられる一例を示している。すなわち、ＭＲＢ＃１はＰＴＰのみ（ＰＴＰ　ｏｎｌｙ）のＭＲＢであり、ＭＲＢ＃２はＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）のＭＲＢであり、ＭＲＢ＃３はＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）のＭＲＢである。なお、ＤＴＣＨは、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いてスケジューリングされる。ＭＴＣＨは、Ｇ－ＲＮＴＩを用いてスケジューリングされる。
　ＵＥ１００のＰＨＹレイヤは、物理チャネルの１つであるＰＤＳＣＨ上で受信したユーザデータ（受信データ）を処理し、トランスポートチャネルの１つである下りリンク共有チャネル（ＤＬ－ＳＣＨ）に流す。ＵＥ１００のＭＡＣレイヤ（ＭＡＣエンティティ）は、ＤＬ－ＳＣＨ上で受信したデータを処理し、受信データに含まれるヘッダ（ＭＡＣヘッダ）に含まれる論理チャネル識別子（ＬＣＩＤ）に基づいて、当該受信データを対応する論理チャネル（対応するＲＬＣエンティティ）に流す。
　図９において、マルチキャストセッションと対応付けられるＭＲＢに、ＤＴＣＨ及びＭＴＣＨが対応付けられる一例を示している。具体的には、１つのＭＲＢが２つのレグに分割（スプリット）され、一方のレグがＤＴＣＨと対応付けられ、他方のレグがＭＴＣＨと対応付けられている。当該２つのレグは、ＰＤＣＰレイヤ（ＰＤＣＰエンティティ）において結合される。すなわち、当該ＭＲＢは、ＰＴＭ及びＰＴＰの両方（ｂｏｔｈ　ＰＴＭ　ａｎｄ　ＰＴＰ）のＭＲＢである。このようなＭＲＢは、スプリットＭＲＢと呼ばれることがある。
　（ＰＤＣＰレイヤの動作）
　図１０は、実施形態に係る移動通信システム１におけるＰＤＣＰレイヤの動作を示す図である。
　ｇＮＢ２００は、あるＭＢＳセッションのＭＢＳデータをＰＴＭ（マルチキャスト又はブロードキャスト）で複数のＵＥ１００（図１０の例では、ＵＥ１００ａ乃至ＵＥ１００ｃ）に送信する。各ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第１配信モード又は第２配信モードであってもよい。
　ｇＮＢ２００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられた送信側ＰＤＣＰエンティティ２０１（具体的には、当該ＭＢＳセッションに属するマルチキャスト無線ベアラ（ＭＲＢ）と対応付けられた送信側ＰＤＣＰエンティティ）を有する。送信側ＰＤＣＰエンティティ２０１は、ＭＢＳセッションの送信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰデータＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）の送信に応じて更新されるＰＤＣＰ状態変数を管理する。
　各ＵＥ１００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられた受信側ＰＤＣＰエンティティ１０１（具体的には、当該ＭＢＳセッションに属するＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ）を有する。各受信側ＰＤＣＰエンティティ１０１（図１０の例では、受信側ＰＤＣＰエンティティ１０１ａ乃至受信側ＰＤＣＰエンティティ１０１ｃ）は、ＭＢＳセッションの受信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰデータＰＤＵの受信に応じて更新されるＰＤＣＰ状態変数を管理する。
　図１１に示すように、ＰＤＣＰ状態変数は、ＰＤＣＰシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号（ＨＦＮ）と、ＰＤＣＰシーケンス番号（ＰＤＣＰ　ＳＮ）と、からなるカウント値（ＣＯＵＮＴ値）であってもよい。例えば、ＣＯＵＮＴ値は３２ビットのビット長を有し、ＰＤＣＰ　ＳＮは１２ビット又は１８ビットのビット長（ＳＮ＿ｌｅｎｇｔｈ）を有し、ＨＦＮはＣＯＵＮＴ値のビット長からＰＤＣＰ　ＳＮのビット長を減じたビット長を有する。ＰＤＣＰ　ＳＮのビット長は、ＲＲＣシグナリングにより設定されてもよい。ＰＤＣＰ　ＳＮビット長は、デフォルト値（予め決められた固定値）であってもよい。なお、用語「ＰＤＣＰ状態変数」は、ＣＯＵＮＴ値を指す場合に限らず、ＰＤＣＰレイヤで扱う各種の変数（ＨＦＮ又はＰＤＣＰ　ＳＮ、或いはＴＸ＿ＮＥＸＴ、ＲＸ＿ＮＥＸＴ、ＲＸ＿ＤＥＬＩＶ及びＲＸ＿ＲＥＯＲＤ等）を指す用語としても用いられる。
　図１２は、ＭＢＳデータを構成するＰＤＣＰデータＰＤＵの一例を示す図である。図１２に示すように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ　ＳＮと、データと、ＭＡＣ－Ｉとを有する。ＰＤＣＰ　ＳＮは、ＰＤＣＰデータＰＤＵに順次付与されるシーケンス番号である。データは、ＰＤＣＰ　ＳＤＵ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ｕｎｉｔ）に相当する。ＭＡＣ－Ｉは、メッセージ認証コードに相当する。ＰＤＣＰデータＰＤＵは、ＭＡＣ－Ｉを有していない場合がある。このように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ　ＳＮを有するものの、ＨＦＮを有していない。そのため、ｇＮＢ２００及びＵＥ１００のそれぞれは、ＰＤＣＰデータＰＤＵの送受信に応じてＨＦＮを更新、具体的には、ＰＤＣＰシーケンス番号が一周する度にカウントアップする必要がある。
　図１３は、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）において受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。ここで、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮをＲＣＶＤ＿ＳＮと呼ぶ。
　第１に、
　　ＲＣＶＤ＿ＳＮ＜ＳＮ（ＲＸ＿ＤＥＬＩＶ）－Ｗｉｎｄｏｗ＿Ｓｉｚｅ
　である場合、
　ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）＋１
　である。ここで、ＲＸ＿ＤＥＬＩＶは、受信待ちであって、未だ上位レイヤに提供していないＰＤＣＰ　ＳＤＵのうち最も古いものを表す変数である。ＲＸ＿ＤＥＬＩＶの初期値はゼロである。なお、ＰＴＭ受信においては、ＲＸ＿ＤＥＬＩＶの初期値は、最初に受信したパケットのＳＮを用いてセットされてもよい。Ｗｉｎｄｏｗ＿Ｓｉｚｅは、リオーダリングウィンドウのサイズを示す定数である。
　第２に、
　ＲＣＶＤ＿ＳＮ≧ＳＮ（ＲＸ＿ＤＥＬＩＶ）＋Ｗｉｎｄｏｗ＿Ｓｉｚｅ
　である場合、
　ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）－１
　である。
　第３に、上記のいずれの条件も満たされない場合、
　ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）
　である。
　そして、
　ＲＣＶＤ＿ＣＯＵＮＴ＝［ＲＣＶＤ＿ＨＦＮ，ＲＣＶＤ＿ＳＮ］
　にセットされる。
　図１４は、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作の一例を示す図である。
　まず、受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ　ＰＤＵ（ＰＤＣＰデータＰＤＵ）を受信すると、当該ＰＤＣＰ　ＰＤＵに対して、カウント値（ＲＣＶＤ＿ＣＯＵＮＴ）を用いたセキュリティ処理（具体的には、ｄｅｃｉｐｈｅｒｉｎｇ／ｉｎｔｅｇｒｉｔｙ　ｖｅｒｉｆｉｃａｔｉｏｎ）を行い（ステップＳ１２）、ｉｎｔｅｇｒｉｔｙ　ｖｅｒｉｆｉｃａｔｉｏｎに失敗した場合（ステップＳ１２：Ｙｅｓ）、上位レイヤにｉｎｔｅｇｒｉｔｙ　ｖｅｒｉｆｉｃａｔｉｏｎ失敗を通知するとともに当該ＰＤＣＰ　ＰＤＵを破棄する（ステップＳ１３）。
　受信側ＰＤＣＰエンティティ１０１は、ｉｎｔｅｇｒｉｔｙ　ｖｅｒｉｆｉｃａｔｉｏｎに成功した場合（ステップＳ１２：Ｎｏ）、カウント値（ＲＣＶＤ＿ＣＯＵＮＴ）がＲＸ＿ＤＥＬＩＶよりも小さい場合（ステップＳ１４：Ｙｅｓ）、又は、ＲＣＶＤ＿ＣＯＵＮＴが受信済みである場合（ステップＳ１６：Ｙｅｓ）、当該ＰＤＣＰ　ＰＤＵを破棄する（ステップＳ１５）。
　次に、受信側ＰＤＣＰエンティティ１０１は、破棄しなかったＰＤＣＰ　ＰＤＵを受信バッファに格納し（ステップＳ１７）、「ＲＣＶＤ＿ＣＯＵＮＴ≧ＲＸ＿ＮＥＸＴ」である場合（ステップＳ１８：Ｙｅｓ）、ＲＸ＿ＮＥＸＴ＝ＲＣＶＤ＿ＣＯＵＮＴ＋１に更新する（ステップＳ１９）。ここで、ＲＸ＿ＮＥＸＴは、次に受信することが期待されるＰＤＣＰ　ＳＤＵのカウント値（ＲＣＶＤ＿ＣＯＵＮＴ）を示す変数である。ＲＸ＿ＮＥＸＴの初期値はゼロである。なお、ＰＴＭ受信においては、ＲＸ＿ＮＥＸＴの初期値は、最初に受信したパケットのＳＮを用いてセットされてもよい。Ｏｕｔ－ｏｆ－ｏｒｄｅｒ　ｄｅｌｉｖｅｒｙが設定（Ｃｏｎｆｉｇｕｒｅｄ）されている場合（ステップＳ２０：Ｙｅｓ）、受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰ　ＰＤＵをヘッダ逆圧縮後、上位レイヤに渡す（ステップＳ２１）。具体的には、受信側ＰＤＣＰエンティティ１０１は、ＲＲＣで“ｏｕｔＯｆＯｒｄｅｒＤｅｌｉｖｅｒｙ”が設定されている場合に、ステップＳ２１の動作を行う。Ｏｕｔ　ｏｆ　ｏｒｄｅｒ　ｄｅｌｉｖｅｒｙは、順序制御を行わずに上位レイヤにパケットを渡す動作である。よって、ステップＳ２１のように、パケットを受信してバッファに格納したら直ぐに上位レイヤに当該パケットを渡す。なお、ステップＳ２０が”Ｎｏ”の場合、順序制御を行うことになる。
　受信側ＰＤＣＰエンティティ１０１は、「ＲＣＶＤ＿ＣＯＵＮＴ＝ＲＸ＿ＤＥＬＩＶ」である場合（ステップＳ２２：Ｙｅｓ）、ＣＯＵＮＴ＝ＲＸ＿ＤＥＬＩＶから始まる連続するＣＯＵＮＴの全てのＰＤＣＰ　ＳＤＵをヘッダ逆圧縮後、上位レイヤに渡し（ステップＳ２３）、ＲＸ＿ＤＥＬＩＶを、上位レイヤに渡していない最初の（最も若い）ＣＯＵＮＴ値に更新する（ステップＳ２４）。
　受信側ＰＤＣＰエンティティ１０１は、Ｔ－Ｒｅｏｒｄｅｒｉｎｇが動作中であって、「ＲＸ＿ＤＥＬＩＶ≧ＲＸ＿ＲＥＯＲＤ」である場合（ステップＳ２５：Ｙｅｓ）、Ｔ－Ｒｅｏｒｄｅｒｉｎｇをｓｔｏｐ及びｒｅｓｅｔする（ステップＳ２６）。ここで、Ｔ－Ｒｅｏｒｄｅｒｉｎｇは、ＰＤＣＰデータＰＤＵの欠落を検出するために用いるタイマである。ＲＸ＿ＲＥＯＲＤは、Ｔ－ＲｅｏｒｄｅｒｉｎｇをトリガしたＰＤＣＰデータＰＤＵに関連付けられたＣＯＵＮＴ値に続くＣＯＵＮＴ値を示す変数である。
　受信側ＰＤＣＰエンティティ１０１は、Ｔ－Ｒｅｏｒｄｅｒｉｎｇが停止中であって、「ＲＸ＿ＤＥＬＩＶ＜ＲＸ＿ＲＥＯＲＤ」である場合（ステップＳ２７：Ｙｅｓ）、ＲＸ＿ＲＥＯＲＤ＝ＲＸ＿ＮＥＸＴに更新するとともにＴ－Ｒｅｏｒｄｅｒｉｎｇを始動（ｓｔａｒｔ）する（ステップＳ２８）。
　（移動通信システムの動作）
　一般的に、ＰＤＣＰ状態変数の初期値はゼロであり、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）からＵＥ１００（受信側ＰＤＣＰエンティティ１０１）へのデータ送信が開始されると、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）及びＵＥ１００（受信側ＰＤＣＰエンティティ１０１）で同期してＰＤＣＰ状態変数が更新される。
　しかしながら、図１０に示すようなシナリオにおいて、ＵＥ１００（ＵＥ１００ａ乃至ＵＥ１００ｃのいずれか）は、必ずしも、ｇＮＢ２００がＭＢＳセッション（マルチキャストセッション又はブロードキャストセッション）の提供を開始した時点からＭＢＳ受信を開始できるとは限らず、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）及びＵＥ１００（受信側ＰＤＣＰエンティティ１０１）でＰＤＣＰ状態変数が非同期の状態になり、上述のようなＰＤＣＰレイヤ動作を適切に実行できないという問題がある。例えば、いずれかのＵＥ１００は、当該ｇＮＢ２００が提供するＭＢＳセッションの途中からＭＢＳ受信を開始し得る。そのようなＵＥ１００は、他のｇＮＢ２００（他のセル）からセル変更（例えば、セル再選択又はハンドオーバ）してきたＵＥ１００でもあり得る。
　図１５は、実施形態に係るＵＥ１００の動作を示す図である。実施形態において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ｇＮＢ２００からＰＴＭで送信されるＭＢＳデータを構成する一連のＰＤＣＰデータＰＤＵをｇＮＢ２００から受信する。ＰＤＣＰデータＰＤＵは、ＰＤＣＰ　ＭＲＢデータＰＤＵと呼ばれてもよい。
　ステップＳ１において、特定のＭＲＢの受信を行うＵＥ１００は、ｇＮＢ２００が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号（ＰＤＣＰ　ＳＮ）が一周する度にカウントアップされるＨＦＮ（具体的には、当該特定のＭＲＢにおける現在（最新）のＨＦＮ）をｇＮＢ２００から受信する。
　ステップＳ１に先立ち、ＵＥ１００は、ＨＦＮの提供をｇＮＢ２００に要求してもよい。ＵＥ１００は、ＭＢＳデータ（ＰＤＣＰデータＰＤＵ）を正常受信できないことに関する条件が満たされたことに応じて、ＨＦＮの提供をｇＮＢ２００に要求してもよい。例えば、ＵＥ１００は、ＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及びＭＢＳ受信を連続して失敗した回数が所定時間を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたことに応じて、ＨＦＮの提供をｇＮＢ２００に要求してもよい。或いは、ＵＥ１００は、現在（最新）のＨＦＮの情報を有していないことを示す第３条件が満たされたことに応じて、ＨＦＮの提供をｇＮＢ２００に要求してもよい。例えば、ＵＥ１００は、ブロードキャストセッションについて途中から受信に興味を持ったこと又は途中から受信を開始したことなどにより、現在のＨＦＮを有していない場合、ＨＦＮの提供をｇＮＢ２００に要求してもよい。このような要求信号の構成例については、第４実施例において説明する。
　ステップＳ１において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＨＦＮを含むＰＤＣＰ制御ＰＤＵ、又はＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵをｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１から受信してもよい。ＰＨＹレイヤにおいて、当該ＰＤＣＰ制御ＰＤＵの伝送には、複数ＵＥ向けのＲＮＴＩ（例えば、Ｇ－ＲＮＴＩ、ＭＣＣＨ－ＲＮＴＩ、ＳＩ－ＲＮＴＩ等）が用いられてもよい。また、当該ＰＤＣＰ制御ＰＤＵの伝送には、単一ＵＥ向けのＲＮＴＩ（例えば、Ｃ－ＲＮＴＩ）が用いられてもよい。ＵＥ１００は、当該特定のＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ１０１においてのみ当該ＨＦＮを適用する。
　ステップＳ１において、ＵＥ１００のＲＲＣエンティティは、ＨＦＮを含むメッセージ（例えば、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、ＳＩＢ、又はＭＣＣＨ）をｇＮＢ２００のＲＲＣエンティティから受信してもよい。当該メッセージは、ＨＦＮと、当該ＨＦＮと対応付けられたＭＲＢ識別子、ＭＢＳサービス識別子（例えば、ＴＭＧＩ）及び／又は論理チャネル識別子（ＬＣＩＤ）とを含んでもよい。ＵＥ１００は、当該メッセージに含まれるＭＲＢ識別子及び／又はＭＢＳサービス識別子が示すＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ１０１においてのみ当該ＨＦＮを適用する。なお、ＳＩＢがＨＦＮを含む場合、ＨＦＮの変更によるＶａｌｕｅ　Ｔａｇのインクリメントは行わなくてもよい。
　ステップＳ１において、ＵＥ１００のＭＡＣエンティティは、ＨＦＮを含むＭＡＣ制御要素（ＭＡＣ　ＣＥ）をｇＮＢ２００のＭＡＣエンティティから受信してもよい。ＰＨＹレイヤにおいて、当該ＰＤＣＰ制御ＰＤＵの伝送には、複数ＵＥ向けのＲＮＴＩ（例えば、Ｇ－ＲＮＴＩ、ＭＣＣＨ－ＲＮＴＩ、ＳＩ－ＲＮＴＩ等）が用いられてもよい。また、当該ＰＤＣＰ制御ＰＤＵの伝送には、単一ＵＥ向けのＲＮＴＩ（例えば、Ｃ－ＲＮＴＩ）が用いられてもよい。当該ＭＡＣ　ＣＥは、ＨＦＮと、当該ＨＦＮと対応付けられたＭＲＢ識別子、ＭＢＳサービス識別子（例えば、ＴＭＧＩ）及び／又は論理チャネル識別子（ＬＣＩＤ）とを含んでもよい。ＵＥ１００は、当該メッセージに含まれるＭＲＢ識別子及び／又はＭＢＳサービス識別子が示すＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ１０１においてのみ当該ＨＦＮを適用する。
　ステップＳ２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１でｇＮＢ２００から受信したＨＦＮと、ｇＮＢ２００からＵＥ１００が受信するＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮとから、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）が管理するＰＤＣＰ状態変数の初期値を決定する。例えば、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）は、ステップＳ１でｇＮＢ２００から受信したＨＦＮと、ｇＮＢ２００からＵＥ１００が受信するＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮとを結合した結果に応じてＰＤＣＰ状態変数（例えば、ＲＸ＿ＮＥＸＴ、ＲＸ＿ＤＥＬＩＶ）の初期値を決定する。ここで、ＵＥ１００は、ＲＸ＿ＮＥＸＴの初期値を
       (x +1) modulo (2[sl-PDCP-SN-Size])
により決定し、ＲＸ＿ＤＥＬＩＶの初期値を
       (x - 0.5 × 2[sl-PDCP-SN-Size-1]) modulo (2[sl-PDCP-SN-Size])
により決定してもよい。但し、xは、最初に受信したパケットのＳＮである。
　ステップＳ３において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２で決定した初期値によってＰＤＣＰ状態変数を初期化する。すなわち、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２で決定した初期値をＰＤＣＰ状態変数としてセットする。
　なお、ＵＥ１００は、ＭＢＳデータ（ＰＤＣＰデータＰＤＵ）を正常受信できないことに関する条件（例えば、上述の第１条件乃至第３条件のいずれか）が満たされたことに応じて、実施形態に係る動作を実行してもよい。すなわち、ＵＥ１００は、ＰＤＣＰ状態変数の同期外れが生じた可能性があると判定できる状況下において、実施形態に係る動作を実行してもよい。ＵＥ１００は、第１条件乃至第３条件のいずれの条件も満たされない場合、ステップＳ１でｇＮＢ２００から受信するＨＦＮを無視又は破棄してもよい。
　実施形態に係る動作によれば、ｇＮＢ２００がＭＢＳセッションの提供を開始した時点からＵＥ１００がＭＢＳ受信を開始できない場合であっても、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）及びＵＥ１００（受信側ＰＤＣＰエンティティ１０１）でＰＤＣＰ状態変数を同期させることができ、上述のようなＰＤＣＰレイヤ動作を適切に実行可能になる。
　実施形態に係る動作は、ＭＢＳセッションの途中からＭＢＳ受信を開始するＵＥ１００が実行する場合に限らず、他のｇＮＢ２００（他のセル）からセル変更（例えば、セル再選択又はハンドオーバ）してきたＵＥ１００が実行してもよい。セル変更元である当該他のｇＮＢ２００（他のセル）をソースと呼び、セル変更先であるｇＮＢ２００（セル）をターゲットと呼ぶ。セル間（ソース及びターゲット間）でＨＦＮが同期していない場合、ＰＴＭで送信されるＭＢＳデータを受信するＵＥ１００は、上述の実施形態に係る動作を実行してもよい。
　この場合、セル間でＨＦＮが同期していないことを、ソース及び／又はターゲットからＵＥ１００へ通知してもよい。例えば、ソース及び／又はターゲットは、ＨＦＮが同期していない隣接セルのセル識別子をＵＥ１００に通知してもよい。もしくは、ソース及び／又はターゲットは、ＨＦＮが同期している隣接セルのセル識別子をＵＥ１００に通知してもよい。ＵＥ１００は、当該通知に基づいて、ターゲットに移動した際に（例えば、ターゲットからＭＢＳデータ受信を開始した際に）上述の実施形態に係る動作を実行するか否かを決定してもよい。ＵＥ１００は、当該通知に基づいて、セル間（ソース及びターゲット間）でＨＦＮが同期していないと判定した場合に限り、上述の実施形態に係る動作を実行すると決定してもよい。
　（実施例）
　上述の実施形態に係る動作を前提として、第１実施例乃至第４実施例について説明する。これらの実施例において、２以上の実施例を組み合わせて実施してもよい。
　（１）第１実施例
　第１実施例において、ＵＥ１００は、ｇＮＢ２００から最初のＰＤＣＰデータＰＤＵを受信する前に、ｇＮＢ２００からＨＦＮを受信するものとする。
　第１に、ＵＥ１００は、ｇＮＢ２００から受信したＨＦＮを記憶する。第２に、ＵＥ１００は、ＨＦＮをｇＮＢ２００から受信した後に、ｇＮＢ２００から最初のＰＤＣＰデータＰＤＵを受信する。第３に、ＵＥ１００は、記憶されたＨＦＮと、最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮとから、ＰＤＣＰ状態変数の初期値を決定する。
　図１６は、第１実施例に係る動作を示す図である。
　ステップＳ１０１において、ｇＮＢ２００は、ＭＢＳデータの現在のＨＦＮをＵＥ１００に通知する。ＵＥ１００は、当該ＨＦＮを受信する。
　ステップＳ１０２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０１で受信したＨＦＮを（メモリに）記憶する。
　ステップＳ１０３において、ＵＥ１００は、ＭＢＳデータの受信を開始する。なお、ｇＮＢ２００は、ステップＳ１０３よりも前にＭＢＳデータの送信を開始している。
　ステップＳ１０４において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、最初のＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、最初のＰＤＣＰデータＰＤＵを受信する。
　ステップＳ１０５において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０４で受信した最初のＰＤＣＰデータＰＤＵのヘッダに含まれるＰＤＣＰ　ＳＮを確認する。
　ステップＳ１０６において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０２で記憶したＨＦＮを（メモリから）読みだす。そして、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、読み出したＨＦＮと、ステップＳ１０５で確認したＰＤＣＰ　ＳＮとから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。ＵＥ１００は、ＰＤＣＰ状態変数の初期化が完了した後、記憶していたＨＦＮをメモリから削除（破棄）してもよい。
　ステップＳ１０７において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、２つ目以降のＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、２つ目以降のＰＤＣＰデータＰＤＵを受信する。
　ステップＳ１０８において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０７で受信したＰＤＣＰデータＰＤＵに応じてＰＤＣＰ状態変数を更新する。
　（２）第２実施例
　第２実施例において、ＵＥ１００は、ｇＮＢ２００から少なくとも１つのＰＤＣＰデータＰＤＵを受信した後に、ｇＮＢ２００からＨＦＮを受信するものとする。例えば、ＰＴＭデータ送信が、他のＵＥ１００のために既に実施中の状況で、ＵＥ１００が遅れてセッションに入ってきた（受信を開始した）場合、ＨＦＮ受信よりもデータ受信の方が先になる可能性がある。
　第１に、ＵＥ１００は、ＨＦＮをｇＮＢ２００から受信する前に、少なくとも１つのＰＤＣＰデータＰＤＵをｇＮＢ２００から受信する。第２に、ＵＥ１００は、当該少なくとも１つのＰＤＣＰデータＰＤＵを記憶する。第３に、ＵＥ１００は、ＨＦＮをｇＮＢ２００から受信した後に、当該ＨＦＮと、記憶されたＰＤＣＰデータＰＤＵのうち最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮとから、ＰＤＣＰ状態変数の初期値を決定する。
　すなわち、ＵＥ１００は、ＨＦＮが提供される前に受信したＭＢＳデータの処理を保留し（データを記憶し）、ＨＦＮが提供された時点でＰＤＣＰ状態変数の初期化を行い、データ受信処理（ＰＤＣＰ処理）を開始する。
　図１７は、第２実施例に係る動作を示す図である。
　ステップＳ２０１において、ＵＥ１００は、ＰＤＣＰ状態変数の初期化をまだ実施していない状況で、ＭＢＳデータの受信を開始する。
　ステップＳ２０２において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＭＢＳデータを構成する少なくとも１つのＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、当該少なくとも１つのＰＤＣＰデータＰＤＵを受信する。
　ステップＳ２０３において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ処理を行う前の段階で、ステップＳ２０２で受信したＰＤＣＰデータＰＤＵをバッファに記憶する。例えば、受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ処理を行う前段（具体的には、当該ＰＤＣＰエンティティの入力直後であって、上述のＰＤＣＰ受信処理を行う前の段階）にバッファを有するものとする。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０２で複数のＰＤＣＰデータＰＤＵを受信した場合、受信した順番にバッファに格納してもよい。また、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０２で複数のＰＤＣＰデータＰＤＵを受信した場合、当該ＰＤＣＰデータＰＤＵのＰＤＣＰ　ＳＮが小さい（又は大きい）順に並べ替えてバッファに格納してもよい。
　その後、ステップＳ２０４において、ｇＮＢ２００は、現在のＨＦＮをＵＥ１００に通知する。ＵＥ１００は、当該ＨＦＮを受信する。
　ステップＳ２０５において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０４で受信したＨＦＮと、ステップＳ２０３で記憶した最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮとを確認する。ここで、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０３で複数のＰＤＣＰデータＰＤＵを記憶している場合、ＰＤＣＰ　ＳＮが最も小さいＰＤＣＰデータＰＤＵもしくはＰＤＣＰ　ＳＮが最も大きいＰＤＣＰデータＰＤＵからＰＤＣＰ　ＳＮを取得してもよい。もしくは、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、最初に受信したＰＤＣＰデータＰＤＵからＰＤＣＰ　ＳＮを取得してもよい。
　ステップＳ２０６において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０５で確認したＨＦＮ及びＰＤＣＰ　ＳＮから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。
　ステップＳ２０７において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０３でバッファに格納した少なくとも１つのＰＤＣＰデータＰＤＵに対して順次ＰＤＣＰ処理を行う。
　ステップＳ２０８において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰデータＰＤＵを受信する。
　ステップＳ２０９において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０８で受信したＰＤＣＰデータＰＤＵに応じてＰＤＣＰ状態変数を更新する。
　（３）第３実施例
　上述の第１実施例及び第２実施例において、ＰＤＣＰデータＰＤＵ及びＨＦＮが別々にｇＮＢ２００から提供されることを主として想定しており、提供されるＨＦＮとＰＤＣＰデータＰＤＵとの間に提供タイミングのギャップが発生する。そのため、ＰＤＣＰ　ＳＮが一巡（ｗｒａｐ　ａｒｏｕｎｄ）する近辺のタイミングでｇＮＢ２００がＨＦＮを送信すると、ｇＮＢ２００とＵＥ１０と０の間でＨＦＮの同期外れ（ｄｅｓｙｎｃ）が発生してしまう可能性がある。
　ＰＤＣＰデータＰＤＵのヘッダ中でＨＦＮを送信することにより、このような問題を解決可能である。第３実施例において、ＵＥ１００は、ｇＮＢ２００からＰＤＣＰデータＰＤＵを受信すると同時にＨＦＮを受信する。具体的には、ＵＥ１００は、ＨＦＮを含むヘッダを有するＰＤＣＰデータＰＤＵをｇＮＢ２００から受信する。但し、当該ヘッダに常にＨＦＮを含める場合、オーバーヘッドが大きくなる。第３実施例では、ＨＦＮを動的に挿入できるような可変フォーマット（例えば、可変ヘッダ）を導入する。例えば、ＰＤＣＰデータＰＤＵのヘッダには、当該ヘッダにＨＦＮが含まれていることを示すフラグを含めることが可能な構成とする。
　図１８は、第３実施例に係る動作を示す図である。ＵＥ１００は、ＰＴＭで送信されるＭＢＳデータを受信中又は受信に興味を持っているものとする。
　ステップＳ３０１において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、現在のＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰデータＰＤＵを受信する。
　ステップＳ３０１に先立ち、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵの受信を待ち受けてもよい。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰデータＰＤＵを使用することをｇＮＢ２００から設定された場合に限り、当該ＰＤＣＰデータＰＤＵを待ち受けてもよい。このような設定は、ＲＲＣシグナリングによりなされてもよい。
　ＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵは、ＨＦＮを含まないＰＤＣＰデータＰＤＵと別のフォーマットのＰＤＣＰデータＰＤＵとして定義されてもよい。例えば、ＨＦＮ無しの場合は既存ＰＤＣＰデータＰＤＵ、ＨＦＮ有りの場合はＰＤＣＰ　ＭＲＢデータＰＤＵと定義されてもよい。
　ステップＳ３０２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ３０１で受信したＰＤＣＰデータＰＤＵに含まれるＨＦＮ及びＳＮを確認する。
　ステップＳ３０３において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ３０２で確認したＨＦＮ及びＰＤＣＰ　ＳＮから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。
　ステップＳ３０４において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＰＤＣＰデータＰＤＵをＵＥ１００に送信する。このＰＤＣＰデータＰＤＵは、ＨＦＮを含まないものであってもよい。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰデータＰＤＵを受信する。
　ステップＳ３０５において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ３０４で受信したＰＤＣＰデータＰＤＵに応じてＰＤＣＰ状態変数を更新する。
　図１９は、第３実施例に係るＰＤＣＰデータＰＤＵを示す図である。図１９に示すＨＦＮ有りのＰＤＣＰデータＰＤＵは、ＰＤＣＰ　ＭＲＢデータＰＤＵと定義されてもよい。なお、ＰＤＣＰ　ＳＮのビット長が１２ビットである一例を示している。
　図１９に示すＰＤＣＰデータＰＤＵの「Ｏｃｔ　１」は、当該ＰＤＵが制御ＰＤＵであるか又はデータＰＤＵであるかを示す１ビットの「Ｄ／Ｃ」フィールドに加えて、１ビットの「Ｈ」フィールドを有する。「Ｈ」フィールドに“１”がセットされる場合、ＨＦＮ入りのフォーマットであることを示し、「Ｈ」フィールドに“０”がセットされる場合、ＨＦＮ無しのフォーマット、すなわち、既存のＰＤＣＰデータＰＤＵフォーマットであることを示す。なお、既存のＰＤＣＰデータＰＤＵでは、「Ｈ」フィールドは予約フィールド“Ｒ”であるため、通常は“０”がセットされる。図１９に示すＰＤＣＰデータＰＤＵの「Ｏｃｔ　２」乃至「Ｏｃｔ　４」の前半部分には、ＨＦＮがセットされる。図１９に示すＰＤＣＰデータＰＤＵの「Ｏｃｔ　４」の後半部分乃至「Ｏｃｔ　５」には、ＰＤＣＰ　ＳＮがセットされる。そして、「Ｏｃｔ　６」からデータが格納される。
　図１９に示すフォーマット例では、ＨＦＮフィールドがＰＤＣＰ　ＳＮフィールドよりも前に位置しているが、ＨＦＮフィールドは、ＰＤＣＰ　ＳＮフィールドよりも後に位置してもよい。また、図１９において、ＨＦＮフィールドをヘッダに設けるフォーマット例を示しているが、ＨＦＮフィールドをデータの後、もしくはＭＡＣ－Ｉフィールドの後に設けてもよい。この場合、図１９に示すフォーマットと同様に、「Ｈ」フィールドによって、ＨＦＮフィールドが付与されているか否かを通知してもよい。
　（４）第４実施例
　ＵＥ１００がカバレッジホールや干渉などにより一定期間ＰＴＭ受信に失敗した場合、又はＵＥ１００が別セルに入った場合（ハンドオーバ、セル再選択）において、ＵＥ１００は、ＰＤＣＰデータＰＤＵを正常に受信できなくなる虞がある。これらの場合、ＰＤＣＰ状態変数の同期が外れてしまい、現在のＨＦＮ及び／又はＰＤＣＰ　ＳＮ値が分からなくなる可能性がある。
　但し、受信失敗した期間がそれほど長時間でない場合、ＨＦＮはまだｇＮＢ２００と同期しているため、ＰＤＣＰ　ＳＮ部の初期化だけで済む可能性がある。例えば、受信失敗時のＨＦＮをそのまま適用し、ＰＤＣＰ処理に失敗した場合は例えば「＋１」のＨＦＮを適用することにより、ＣＯＵＮＴ値がｇＮＢ２００と同期し、正常に受信が再開できる可能性がある。
　しかしながら、受信失敗が長期間になった場合などの状況においては、上記の限りではない。第４実施例では、ＰＤＣＰデータＰＤＵをＵＥ１００が正常受信できない状況下において、ＵＥ１００がＰＤＣＰ状態変数の初期化を行う。
　第４実施例において、ＵＥ１００は、ＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及びＭＢＳ受信を連続して失敗した回数が所定時間を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたことに応じて、ＨＦＮの提供を要求する要求信号をｇＮＢ２００に送信してもよい。ＵＥ１００は、要求信号に応じてｇＮＢ２００から送信されるＨＦＮを受信する。
　また、第４実施例において、ＵＥ１００は、第１条件及び第２条件のうち少なくとも一方の条件が満たされたことに応じて、初期値によってＰＤＣＰ状態変数を初期化してもよい。
　図２０は、第４実施例に係る動作を示す図である。
　ステップＳ４０１において、ＵＥ１００は、ｇＮＢ２００からのＭＢＳデータ受信（ＰＴＭ受信）を行う。
　ステップＳ４０２において、ＵＥ１００は、ＭＢＳデータ（ＰＤＣＰデータＰＤＵ）を正常受信できないことに関する条件が満たされたか否かを判定する。例えば、ＵＥ１００は、ＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及びＭＢＳ受信を連続して失敗した回数が所定時間を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたか否かを判定する。ここで、ＵＥ１００は、ＰＴＭ（－ｌｅｇ）における受信失敗のみを対象として判定を行ってもよい。
　第１条件の判定において、ＵＥ１００は、タイマを用いて、一定期間受信に失敗したことを検知してもよい。例えば、ＵＥ１００は、受信失敗が継続している時間を測定する。ＵＥ１００は、受信失敗時に、タイマに一定期間（設定値）をセットしたうえでタイマを起動する。当該タイマの設定値は、ｇＮＢ２００からＵＥ１００に設定されていてもよい。ＵＥ１００は、当該タイマを、例えばＧ－ＲＮＴＩごと又はＭＴＣＨごとに別々に管理してもよい。ＵＥ１００は、受信成功時に、当該タイマを停止する。一方、当該タイマが満了した場合、ＵＥ１００は、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。
　第２条件の判定において、ＵＥ１００は、カウンタを用いて、一定回数連続して受信に失敗したことを検知してもよい。例えば、ＵＥ１００は、ＭＴＣＨ受信機会ごとにカウンタを操作し、連続受信失敗回数を測定する。ＵＥ１００は、受信失敗時に、カウンタを１インクリメントする。ＵＥ１００は、当該カウンタを、例えばＧ－ＲＮＴＩごと又はＭＴＣＨごとに別々に管理してもよい。ＵＥ１００は、受信成功時に、カウンタのカウント値をゼロに初期化する。一方、当該カウンタのカウント値が閾値を超えた場合、ＵＥ１００は、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。当該閾値は、ｇＮＢ２００からＵＥ１００に設定されていてもよい。
　ＵＥ１００は、タイマ及びカウンタを組み合わせた判定を行ってもよい。ＵＥ１００は、一定時間内に発生した受信失敗回数が閾値を超えた場合、ＰＤＣＰ状態変数の初期化処理を行う。例えば、ＵＥ１００は、ある時点でタイマを開始するとともにカウンタをゼロにセットする。ＵＥ１００は、タイマが動作中は、受信失敗ごとにカウンタを１インクリメントする。タイマが満了した場合、ＵＥ１００は、タイマを再起動し、カウンタをゼロにセットする。一方、カウンタが閾値を超えた場合、ＵＥ１００は、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。
　ステップＳ４０２において、ＵＥ１００は、ＰＤＣＰ状態変数（ＨＦＮ、ＰＤＣＰ　ＳＮ）の同期外れの可能性を検知してもよい。例えば、ＵＥ１００は、受信側ＰＤＣＰエンティティ１０１において記憶しているＣＯＵＮＴ値と、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮから導出したＣＯＵＮＴ値とが乖離している（両ＣＯＵＮＴ値が一定以上離れている）場合、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。ここで、受信側ＰＤＣＰエンティティ１０１において記憶しているＨＦＮと受信したパケットのＰＤＣＰ　ＳＮとで構成したＣＯＵＮＴ値を用いたセキュリティ処理（ｄｅｃｉｐｈｅｒｉｎｇ／ｉｎｔｅｇｒｉｔｙ　ｖｅｒｉｆｉｃａｔｉｏｎ）に失敗した場合、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。
　ステップＳ４０２において、ＵＥ１００は、ＰＤＣＰ状態変数（ＨＦＮ、ＰＤＣＰ　ＳＮ）がソースと同期していないターゲットでの受信を開始した場合、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。
　なお、ステップＳ４０２における条件判定をＰＤＣＰ／ＲＬＣ／ＭＡＣのいずれかのレイヤで行い、判定結果をＲＲＣへ通知してもよい。
　ステップＳ４０３において、ＵＥ１００は、現在のＨＦＮの提供を要求する要求信号をｇＮＢ２００に送信する。要求信号は、ＵＥ　Ａｓｓｉｓｔａｎｃｅ　Ｉｎｆｏｒｍａｔｉｏｎメッセージ又はＭＢＳ　Ｉｎｔｅｒｅｓｔ　ＩｎｄｉｃａｔｉｏｎメッセージなどのＲＲＣシグナリングであってもよい。また、当該要求信号は、ＰＤＣＰ制御ＰＤＵ、ＰＤＣＰデータＰＤＵ又はＭＡＣ　ＣＥであってもよい。また、当該要求信号は、特別なＰＲＡＣＨリソース（特別な時間・周波数リソース又は特別なプリアンブル系列）を用いて送信するランダムアクセスプリアンブルであってもよい。ランダムアクセスプリアンブルを要求信号とする方法は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態にあるＵＥ１００にとって好適である。
　要求信号としてＲＲＣシグナリング又はＭＡＣ　ＣＥを用いる場合、当該要求信号は、ＨＦＮを提供して欲しいＭＲＢを識別するＭＲＢ識別子を含んでもよい。また、当該要求信号は、ＨＦＮを提供して欲しいＭＢＳセッションを識別するＭＢＳセッション識別子（例えば、ＴＭＧＩ）を含んでもよい。また、当該要求信号は、ＨＦＮを提供して欲しい論理チャネルを識別する論理チャネル識別子（ＬＣＩＤ）を含んでもよい。要求信号としてＰＤＣＰデータＰＤＵを用いる場合、当該要求信号は、ＨＦＮの提供を要求することを示すフラグビットとして“１”がセットされたヘッダを有するＰＤＣＰデータＰＤＵであってもよい。
　ステップＳ４０４において、ｇＮＢ２００は、ステップＳ４０３でＵＥ１００から受信した要求信号に応じて、現在のＨＦＮをＵＥ１００に通知する。ＵＥ１００は、当該ＨＦＮを受信する。
　ここで、ＨＦＮがＳＩＢ又はＭＣＣＨ等によりブロードキャストで通知される場合、要求信号を送信したＵＥ１００以外の他のＵＥ（すなわち、ＰＤＣＰ状態変数の初期化が必要ではないＵＥ）もＨＦＮを受信し得る。ＭＢＳ受信を正常に実施できている当該他のＵＥは、ＨＦＮを受信しても、当該受信したＨＦＮを無視又は破棄し、当該ＨＦＮを用いてＰＤＣＰ状態変数の初期化を行わなくてもよい。
　ステップＳ４０５において、ＵＥ１００は、ステップＳ４０４で受信したＨＦＮと、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮとから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。その後の動作は、上述の実施例と同様である。
　（その他の実施形態）
　上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよい。また、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。
　上述の実施形態及び実施例において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）又は６Ｇ基地局であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵであってもよい。また、ユーザ装置は、ＩＡＢノードのＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）であってもよい。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ）として構成してもよい。
　以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　本願は、米国仮出願第６３／２５５５７３号（２０２１年１０月１４日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
　（付記）
　１．導入
　ＲＡＮ２＃１１５ｅでは、ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）の作業項目が、マルチキャストサービスの継続性について次の合意を達成した。
　ＲＲＣシグナリングでは、１つのＭＲＢを、ＰＴＭのみ、ＰＴＰのみ、又はＰＴＭとＰＴＰとの両方で設定できる。ＰＴＭ、ＰＴＭ＋ＰＴＰ、又はＰＴＰのみ、のいずれかをＲＲＣシグナリングで変更できる。
　ＲＲＣ信号において、ＰＴＭ用のＵＭ　ＲＬＣ設定のみのDL、ＰＴＰ用のＤＬ及びＵL　ＡＭ　ＲＬＣ設定、ＰＴＰ用のＵＭ　ＲＬＣ設定のみのDLをサポートする。ＰＴＰ用のＤＬ及びＵＬ　ＵＭ　ＲＬＣ設定をサポートすることについては更なる検討が必要である。
　ＲＲＣ信号のベアラタイプ変更に伴うＰＤＣＰ　ＳＲの発生可否と、発生した場合のＰＤＣＰ　ＳＲの発生方法とについては更なる検討を行う。
　上記の最初の合意に準拠したＲＲＣ再構成を超えるＰＴＭのインアクティブ化／アクティブ化はサポートされない。
　構成中のＰＴＭ　ＰＤＣＰ状態変数のセットでは、これらの変数のＣＯＵＮＴ値のＳＮ部分は、（ＵＥによって）最初に受信されたパケットのＳＮと、必要に応じてｇＮＢによって示されるＨＦＮとに従ってセットされる。
　ＭＲＢ構成のＰＴＭ　ＲＬＣエンティティを初期化し、ＳＮを含む最初の受信パケットのＳＮに応じて、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ及びＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙの値をセットする。
　ＭＲＢ構成により、ＰＴＰ　ＲＬＣ受信ウィンドウの０ＲＬＣ状態変数を初期値（０）にセットすることができる。
　本付記では、マルチキャストのサービス継続に関する残された課題について議論する。
　２．議論
　２．１．ベアラタイプ変更時のＰＤＣＰステータスレポート
　ＲＡＮ２＃１１５ｅでは、以下のオープンイシューが合意された。
　ＲＲＣ信号において、ＰＴＭのＵＭ　ＲＬＣ構成のみのＤＬ、ＰＴＰのＤＬとＵＬのＡＭ　ＲＬＣ構成、ＰＴＰのＵＭ　ＲＬＣ構成のみのＤＬをサポートする。ＰＴＰのDL及びUL　ＵＭ　ＲＬＣ構成をサポートすることについては、更なる検討が必要である。
　ＲＲＣ信号のベアラタイプ変更に伴うＰＤＣＰ　ＳＲの発生可否と、発生した場合のＰＤＣＰ　ＳＲの発生方法とについては更なる検討を行う。
　現在のＰＤＣＰ仕様によれば、ＰＤＣＰステータスレポートは、主にＡＭ　ＤＲＢ（場合によってはＵＭ　ＤＲＢ）に対して、以下のイベント発生時にＲＲＣによってトリガされる。
　上りリンクでＰＤＣＰステータスレポートを送信するように上位層によって構成されたＡＭ　ＤＲＢ（ＴＳ　３８．３３１のｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄ）の場合、受信ＰＤＣＰエンティティは、次の場合にＰＤＣＰステータスレポートをトリガする必要がある。
　－上位層はＰＤＣＰエンティティの再確立を要求する。
　－上位層がＰＤＣＰデータ回復を要求する。
　－上位レイヤが上りリンクデータスイッチングを要求する。
　－上位層はＰＤＣＰエンティティを再構成してＤＡＰＳを解放し、ｄａｐｓ－ＳｏｕｒｃｅＲｅｌｅａｓｅはＴＳ　３８．３３１で構成される。
　上りリンクでＰＤＣＰステータスレポート（ＴＳ　３８．３３１のｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄ）を送信するように上位層によって構成されたＵＭ　ＤＲＢの場合、受信ＰＤＣＰエンティティは、次の場合にＰＤＣＰステータスレポートをトリガする必要がある。
　上位レイヤは、上りリンクデータ切替を要求する。
　ＭＢＳでは、ＰＴＭのみのＭＲＢはＲＬＣ　ＵＭでのみ構成されるが、ＰＴＰのみのＭＲＢとスプリットＭＲＢのＰＴＰレグとはＲＬＣ　ＵＭ又はＲＬＣ　ＡＭで構成される。これらは、それぞれＵＭ　ＭＲＢ及びＡＭ　ＭＲＢと呼ばれる。
　現在のＲＲＣ仕様によると、ＲＲＣ再構成の処理遅延に関するＵＥのパフォーマンス要件は１０ｍｓで規定されている。そのため、ＵＥは、ベアラタイプ変更のためのＲＲＣ再構成中にＭＢＳ送信を見逃す可能性があり、欠落したパケットは、ベアラタイプ変更後に補償する必要がある。この意味で、ＰＤＣＰステータスレポートは、少なくとも特定のＭＢＳサービスによって要求されるより高い信頼性を満たすためにサポートされるべきである。
　また、どのような場合にＰＤＣＰステータスレポートが必要であるかについても検討する価値がある。ＡＭ　ＭＲＢの場合は、一般的に「高ＱｏＳ」のＭＢＳサービスを想定しているため、ベアラタイプ変更の際にも信頼性が求められることは明らかである。ＡＭ　ＭＲＢ間でベアラタイプを変更する場合、ＵＭ　ＭＲＢからＡＭ　ＭＲＢへ変更する場合も含まれる。
　提案１：ＲＡＮ２は、少なくともＡＭ　ＭＲＢ間、及びＵＭ　ＭＲＢからＡＭ　ＭＲＢへのロスレスベアラタイプの変更にＰＤＣＰステータスレポートがサポートされることに合意すべきである。
　一般に、ＵＭ　ＭＲＢはベアラタイプ変更時の信頼性、すなわちロスレスを必要としないと考えられる。しかし、ＵＭ　ＭＲＢを「高ＱｏＳ」ＭＢＳサービスに使用するかどうかは、実際にはＮＷの実装に委ねることができる。無線状態が良好なＵＥに対してはＰＴＭのみのＭＲＢを使用し、無線状態が一定以上悪化した場合にはＰＴＰのみのＭＲＢ（又は、スプリットＭＲＢ）に再構成することで、ＮＷはリソースを効率的に運用することができる。現在の仕様では、ある場合にＵＭ　ＤＲＢがＰＤＣＰステータスレポートをトリガすることが認められていることを考えると、ＮＷがＰＤＣＰステータスレポートを必要とするかどうかをＵＭ　ＭＲＢに設定できることは容易に明らかである。この場合、ＰＴＰのみのＭＲＢとスプリットＭＲＢのＰＴＰレグには、ＤＬ／ＵＬ双方向ＵＭ、すなわちＭＢＳデータ受信用のＤＬ　ＲＬＣエンティティ及びＰＤＣＰステータスレポート送信用のＵＬ　ＲＬＣエンティティを設定する必要がある。
　提案２：ＲＡＮ２は、ＵＭ　ＭＲＢのベアラタイプ変更時にＰＤＣＰステータスレポートを使用するかどうかはＮＷの実装次第であることに合意すべきである。そのためにはＤＬ／ＵＬ双方向ＲＬＣ　ＵＭでＰＴＰを構成できる仕様が必要である。
　２．２．ＰＴＭのＰＤＣＰ／ＲＬＣ状態変数
　２．２．１．初期値
　ＲＡＮ２＃１１５ｅでは、以下の記述に合意した。
　構成中のＰＴＭ　ＰＤＣＰ状態変数のセットについては、これらの変数のＣＯＵＮＴ値のＳＮ部は、（ＵＥによる）最初の受信パケットのＳＮと、必要に応じてｇＮＢによって示されるＨＦＮとに従って設定される。
　ＭＲＢ構成のＰＴＭ　ＲＬＣエンティティを初期化し、ＳＮを含む最初の受信パケットのＳＮに応じて、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ及びＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙの値を設定する。
　２つの契約における「ａｃｃｏｒｄｉｎｇ　ｔｏ」という言葉は、次のような３つの選択肢を意図している。
　選択肢１：各状態変数の初期値は、単純に最初に受信したパケットのSNにセットされる。
　選択肢２：Ｒｅｌ－１６　Ｖ２Ｘ解決策が再利用される。
　ＰＤＣＰ「ＲＸ＿ＮＥＸＴ」の場合、「ＲＸ＿ＮＥＸＴのＳＮ部の初期値は(x +1) modulo (2[sl-PDCP-SN-Size])、ｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」。
　ＰＤＣＰ「ＲＸ＿ＤＥＬＩＶ」の場合、「ＲＸ＿ＤＥＬＩＶのＳＮ部の初期値は(x - 0.5 × 2[sl-PDCP-SN-Size-1]) modulo (2[sl-PDCP-SN-Size])、ｘは最初の受信ＰＤＣＰ　Ｄａｔａ　ＰＤＵのＳＮ」。
　ＲＬＣ　ＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙ」については、「ＳＮを含む最初に受信したＵＭＤ　ＰＤＵのＳＮに初期設定される」。
　ＲＬＣ　ＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ」について、「ＳＮを含む最初に受信したＵＭＤ　ＰＤＵのＳＮに初期設定される」。
　選択肢３：ＲＬＣ　ＵＭのための新しいメカニズムが導入される。
　ＰＤＣＰ状態変数については、選択肢１又は選択肢２のいずれかを適用することができる。
　ＲＬＣ　ＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙ」については、「ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ」よりも前の値に初期設定される。
　ＲＬＣ　ＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ」については、上記選択肢２と同様に、「ＳＮを含む最初に受信したＵＭＤ　ＰＤＵのＳＮに初期設定される」。
　ＰＤＣＰの状態変数では、選択肢２の場合、次に受信するパケットであるＲＸ＿ＮＥＸＴは、（［最初に受信したパケットのＳＮ］＋１）に設定される。上位層に配信されない最初のパケットであるＲＸ＿ＤＥＬＩＶは、（［最初に受信したパケットのＳＮ］－［ＳＮ長の１／４］）に設定される。これは、最初に受信したパケットの後に古いパケットを受信しても、並べ替えを行うことができることを意味する。したがって、選択肢２は選択肢１よりも信頼性が高いと考えられる。
　提案３：ＲＡＮ２は、Ｒｅｌ－１６　Ｖ２Ｘと同様に、ＲＸ＿ＮＥＸＴの初期値を（［最初に受信したパケットのＳＮ］＋１）ｍｏｄｕｌｏ（２＾［ＰＤＣＰ　ＳＮ　ｌｅｎｇｔｈ］）とすることにＰＤＣＰに対して合意すべきである。
　提案４：ＲＡＮ２は、ＲＸ＿ＤＥＬＩＶの初期値を、Ｒｅｌ－１６　Ｖ２Ｘと同様に、｛［最初の受信パケットの　ＳＮ］－２＾（［ＰＤＣＰ　ＳＮ長］－２）｝ｍｏｄｕｌｏ（２＾［ＰＤＣＰ　ＳＮ　長］）とすることにＰＤＣＰについて合意すべきである。
　ＲＬＣ状態変数については、選択肢１と選択肢２が全く同じである。また、選択肢２と選択肢３は、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの点でも同じである。したがって、ＲＡＮ２は、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの初期値について、他の解がないことを確認すればよい。
　提案５：ＲＡＮ２は、Ｒｅｌ－１６　Ｖ２Ｘと同様に、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの初期値が最初に受信したパケットのＳＮであるというＲＬＣ　ＵＭに合意すべきである。
　ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙに関して、選択肢２と選択肢３とは異なる。選択肢３の利点は、ＰＤＣＰ状態変数の選択肢２と似ている。つまり、最初に受信したパケットの後に受信した古いパケットを破棄することを回避できる。ＲＬＣセグメンテーションが実行された場合にのみこの問題が発生することも指摘されているが、パケット損失が最小限に抑えられれば常に良いことである。
　提案６：ＲＡＮ２はＲＬＣ　ＵＭについて、ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙの初期値が最初に受信したパケットのＳＮであるか（Ｒｅｌ－１６　Ｖ２Ｘと同じ）、又はＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの前の値であるかについて議論すべきである。
　２．２．２．       ＨＦＮプロビジョニング
　１）ＳＡ３がセキュリティのためにＨＦＮを使用するかどうか、２）ＲＡＮ２＃１１５ｅで説明したように、ＣＯＵＮＴがＨＦＮパートを有するためＰＤＣＰステータスレポートがサポートされるかどうか、などである。ＰＤＣＰステータスレポートは、ハンドオーバの場合にサポートされることが既に合意されており、２．１節のようにベアラタイプ変更の場合にもサポートされると思われる。そのため、ＲＡＮ２が合意したように、ＨＦＮはｇＮＢによって示される必要がある。
　その上で、ｇＮＢがＵＥにどのようにＨＦＮを提供するかを議論すべきである。ＨＦＮを提供する方法としては、以下の選択肢が考えられる。
　Ａｌｔ．１：ＲＲＣ再構成
　Ａｌｔ．２：ＰＤＣＰ制御ＰＤＵ
　Ａｌｔ．３：ＭＣＣＨ
　Ａｌｔ．４：ＳＩＢ
　Ａｌｔ．５：ＰＤＣＰデータＰＤＵのヘッダ
　Ａｌｔ．１は、ｇＮＢがＲＲＣ再構成によってＵＥにマルチキャスト用のＭＲＢを構成する必要があり、つまり、ＨＦＮはＭＲＢと一緒に設定されるため、簡単だと考えられている。しかし、ＲＲＣ再構成は特定のＵＥに対する専用のシグナリングであり、基本的に第１配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　１：ＤＭ１）でのみ使用され、Ａｌｔ．２と比較して処理が少し重いという欠点がある。また、ＲＲＣ再構成の受信と最初の受信パケットとの間に一定のタイミングのギャップがあり、ＨＦＮ非同期の原因となる可能性がある。さらに、ＨＦＮがどのＭＲＢに適用されるかを示すための追加情報が必要な場合がある。
　Ａｌｔ．２は、ｇＮＢがＰＴＭ上でＨＦＮを指示することができるため、より軽量で効率的なシグナリングであると考えられている。ＰＤＣＰエンティティはＭＲＢと関連付けられているため、追加情報であるＨＦＮとＭＲＢとのマッピングは不要である。つまり、このＰＤＣＰ制御ＰＤＵを受信したＰＤＣＰエンティティは、ＨＦＮを初期値として適用すれば良い。これは、第１配信モードと第２配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　２：ＤＭ２）とで一般的に使用されている。また、同じＰＤＣＰエンティティがこれらのＰＤＣＰ　ＰＤＵを処理するため、ＰＤＣＰ制御ＰＤＵと最初に受信したパケットとの間のタイミングのギャップを最小にすることができるだろう。ただし、ＰＤＣＰ制御ＰＤＵはセキュリティ保護されていないことが懸念される。
　Ａｌｔ．３は別の可能性であるが、ＭＣＣＨは第２配信モードにのみ適用可能であり、第１配信モードを受信するＵＥにＭＣＣＨの取得という追加の負担を義務付けることは好ましくないと考えられる。また、ＭＣＣＨの受信と最初の受信パケットとの間に一定のタイミングのギャップがある可能性がある。さらにＡｌｔ．１と同様にＨＦＮとＭＲＢとのマッピングという追加情報が必要になる可能性があるため、ＭＣＣＨの取得を義務付けることは好ましくない。
　Ａｌｔ．４は通常のプロビジョニング方法として考えられている。ＳＩＢは基本的に第１配信モード１及び第２配信モードの両方に適用されるが、マルチキャスト受信のために接続されたＵＥがＳＩＢを監視することが義務付けられているかどうかは、まだ不明である。懸念点としては、Ａｌｔ．２と同様にＳＩＢがセキュリティ保護されていないこと、Ａｌｔ．１と同様にＨＦＮとＭＲＢとのマッピングという追加情報が発生すること、ＳＩＢ受信と最初の受信パケットとの間に一定のタイミングのギャップが生じることなどが挙げられる。また、オンデマンドＳＩを適用する場合、ＵＥはＳＩＢを取得する前にオンデマンドＳＩ要求メッセージを送信する必要があり、ＨＦＮ初期化の遅延を引き起こす可能性がある。
　Ａｌｔ．５には、Ａｌｔ．２と同様の利点が見られる。つまり、ＰＴＭ方式で配信でき、追加情報は必要なく、第１配信モード及び第２配信モードの共通の解決策である。Ａｌｔ．５が最初に受信したパケットがＨＦＮを一緒に伝達するため、最も重要な利点は、理論的にはタイミングのギャップである。ただし、ＨＦＮが最初に受信したパケットのヘッダに含まれていると仮定すると、パケットがＰＴＭを介して他のＵＥに送信され始めていることを考えると、ｇＮＢがＵＥの最初に受信したパケットをどのように知るかは疑問である。それ以外の場合、ｇＮＢは常に各データパケットにＨＦＮを含める必要がある。懸念事項は、Ａｌｔ．２と同様にＰＤＣＰヘッダがセキュリティ保護されていないことである。ＨＦＮプロビジョニングは、Ａｌｔ．２を含む他の代替案と同様にＣプレーンシグナリングと見なされるため、概念／原理の観点からは少し奇妙である。一方、Ａｌｔ．５はＵプレーンデータを使用する。
　別の角度から見ると、第１配信モード（ＤＭ１）と第２配信モード（ＤＭ２）とでは、ＨＦＮの提供方法に違いがあることがわかる。一般に、ＤＭ１（又は、マルチキャスト）はＤＭ２（又は、ブロードキャスト）よりも安全である。これは、構成が専用のシグナリングによって提供されるためである（また、ＮＡＳではセッション参加手順が利用可能である）。この意味で、ＨＦＮもＤＭ１で安全に提供する必要がある。この場合、最も簡単な解決策はＡｌｔ．１であるが、ＤＭ１とＤＭ２との共通性を実現するには適していない。Ａｌｔ．２は、ＰＤＣＰ制御ＰＤＵがＣ－ＲＮＴＩで送信される場合、Ａｌｔ．３、Ａｌｔ．４、Ａｌｔ．５よりもある程度のセキュリティを確保できると想定される。一方、ＤＭ２はＵＥにＣＯＮＮＥＣＴＥＤへの移行を義務付けるべきではなく、ＨＦＮの取得のみを目的としている。ＤＭ２をサポートするために、ＨＦＮは定期的にブロードキャスト方式で（つまり、Ｇ－ＲＮＴＩ、ＭＣＣＨ－ＲＮＴＩ、又はＳＩ－ＲＮＴＩを使用して）提供される。
　上記のとおり、（以下の表にも要約されているように）、ＨＦＮはＰＤＣＰ制御ＰＤＵ（つまり、Ａｌｔ．２）を介して提供されることが、パフォーマンスとセキュリティのバランスが取れており、また、両方の配信モード（つまり、ＤＭ１及びＤＭ２）に共通の解決策であるため、わずかに好ましいと言える。
　提案７：ＲＡＮ２は、ＨＦＮの初期値がＰＤＣＰ制御ＰＤＵを介して提供されることに合意すべきである。
　提案８：提案７が合意可能である場合、ＲＡＮ２はさらに、ＰＤＣＰ制御ＰＤＵ（ＨＦＮプロビジョニング用）をＧ－ＲＮＴＩ及びＣ－ＲＮＴＩと共に送信できることに合意すべきである。
Figure JPOXMLDOC01-appb-T000001
       
　２．２．３．ＨＦＮ初期化前のデータ受信
　ＵＥは、ＨＦＮを受信する前にデータを受信する可能性がある。これは、ＨＦＮと最初に受信したパケットの受信タイミングが、順序どおりでない配信（たとえば、悪い無線状態での再送信及び／又はハンドオーバ中の再送信など）により異なる可能性があるためである。及び／又は、セクション２．２．２のどの選択肢が選択されているかによって異なる。さらに、当該ＰＴＭ送信は、他のＵＥへの送信が既に開始されているため、ＵＥは、ＭＲＢをセットするとすぐにデータを受信することができる。
　所見：１ＵＥは、ＨＦＮ初期化の前に、ＰＴＭを介してＭＢＳデータを受信する場合がある。
　現在のＰＤＣＰ仕様では、ＲＲＣがＰＤＣＰエンティティの確立、ＰＤＣＰエンティティの再確立、又はＰＤＣＰエンティティの一時停止を要求すると、ＲＸ＿ＮＥＸＴとＲＸ＿ＤＥＬＩＶとは初期値に（再）設定される。当然、ＣＯＵＮＴ値の初期化はデータ受信前に行われる。したがって、ＰＤＣＰの観点からは、たとえ下位層がデータ受信の準備を完了していても、データが受信されない場合がある。つまり、ＲＬＣ層がＲＬＣ　ＳＤＵ（ＰＤＣＰ　ＰＤＵ）をＰＤＣＰ層に送信したとしても、データが受信されない場合がある。ＰＤＣＰがこれらのＰＤＣＰ　ＰＤＵを受け入れたとしても、ＨＦＮがまだアオリスティックであるため、これらのＰＤＵは完全性検証の失敗により破棄される。
　所見：２ＨＦＮの初期化の前に、現在の仕様によると、下位層からのＰＤＣＰ　ＰＤＵは受け入れられないか、ＰＤＣＰ層で破棄される可能性がある。
　したがって、セクション２．２．１で説明されているＳＮの状態変数の初期化のすべての拡張機能（一部）と、セクション２．２．２で説明されているように、パケット損失を最小限に抑えることを目指している。簡単な方法の１つは、ＰＤＣＰがこれらのＰＤＵをＰＤＣＰ処理の前に一時的にバッファリングし、ＨＦＮの初期化後にこれらのＰＤＵの処理を開始することである。
　提案９：ＲＡＮ２は、ＨＦＮの初期化の前に、ＵＥが受信したデータパケットをどのように処理するかについて議論すべきである。
　２．２．４．ＨＦＮプロビジョニングのリクエスト
　もう１つの考えられる問題は、ＵＥがｇＮＢに現在のＨＦＮを問い合わせることが許可されているかどうかである。特にＰＴＭのみのＭＲＢの場合、たとえばカバレッジホールや干渉が原因で、ＵＥが一定期間パケットを受信できなかった場合、ＨＦＮが非同期になる可能性がある。もう１つのケースは、（セクション２．２．２で簡単に説明したように）ＨＦＮがＭＢＳセッションのアクティブ化時にのみ提供される場合、ＵＥが既にアクティブ化されているＭＢＳセッションに後で参加するときにＨＦＮを必要とすることである。
　そのため、ＵＥがＨＦＮプロビジョニングの必要性に気付いた場合、ＵＥが現在のＨＦＮを提供するようｇＮＢに要求できるようにすると便利である。たとえば、ＲＲＣシグナリング又はＰＤＣＰ制御ＰＤＵを介して、要求を送信する方法については更なる検討が必要である。同じ条件で、ＵＥは、受信ウィンドウの外にある次のパケットを受信しない場合がある。この場合、ＵＥは、すべての状態変数を初期値にリセットすることができる。
　提案１０：ＲＡＮ２は、ＵＥがｇＮＢにＭＢＳセッションの現在のＨＦＮを提供するよう要求することを許可されているかどうかを議論すべきである。
　提案１１：ＲＡＮ２は、ＵＥが一定期間ＭＢＳセッションの受信に失敗した場合に状態変数をリセットできるかどうかについて議論すべきである。
　２．３．ロスレスモビリティオペレーション
　ＲＡＮ２は、「Ｒ２は、これを必要とするサービスのためにＭＢＳ－ＭＢＳモビリティのロスレスハンドオーバをサポートすることを目指している（シナリオの詳細は未定だが、少なくともＰＴＰ－ＰＴＰ）」及び「ＵＥ側からは、ＰＤＣＰステータスレポートもサポートされる可能性がある」。これらの合意は、ＭＲＢがＰＴＰのみで構成されている場合、ユニキャストの既存のハンドオーバと非常によく似たメカニズムを意味する。
　所見３：ロスレスハンドオーバをサポートするために、ユニキャスト用の既存のハンドオーバ機構をＰＴＰのみで構成されたＭＲＢに再利用することが可能である。
　そこで、ＰＴＭ（－ｌｅｇ）を含むハンドオーバの場合、すなわち、ＰＴＭのみで構成されたＭＲＢ及びＰＴＰレグとＰＴＭレグとを含むスプリットＭＲＢについて検討する必要がある。
　スプリットＭＲＢは、ＰＴＭレグを使用しない場合は、ＰＴＰのみのＭＲＢとみなすことができる。そのため、従来のユニキャストハンドオーバをベースに、ロスレスハンドオーバを容易にサポートすることができる。そこであるスプリットＭＲＢの基本的な手順は、以下のように考えられる。
　ステップ１：スプリットＭＲＢのＰＴＰレグは、必要に応じて、ソースセルでロスレス動的切替により使用される。
　ステップ２：ＵＥは、ＰＴＰ－ＰＴＰハンドオーバ（又は、ユニキャストハンドオーバのように）、ロスレスハンドオーバを実行する。
　ステップ３：スプリットＭＲＢのＰＴＭレグは、必要に応じて、ロスレス動的切替によってターゲットセルで使用される。
　このとき、ＮＷの実装によって確保されるロスレス動的切替が重要な役割を果たすことになる。
　所見４：スプリットＭＲＢのロスレスハンドオーバには、ロスレスの動的ＰＴＭ／ＰＴＰ切替が不可欠である。
　ＰＴＭのみのＭＲＢに関しては、以下のように非常に類似した手順が適用可能である。
　ステップ１：ソースセルにおいて、ロスレスベアラタイプ変更により、ＰＴＭ用のＭＲＢをＰＴＰ用のＭＲＢ（又は、スプリットＭＲＢ）に再構成する。
　ステップ２：ＵＥは、ＰＴＰ－ＰＴＰハンドオーバとして（又は、ユニキャストハンドオーバのように）、ロスレスハンドオーバを実行する。
　ステップ３：ロスレスベアラタイプ変更により、必要に応じて、ターゲットセルにおいて、ＰＴＰのみのＭＲＢ（又は、スプリットＭＲＢ）をＰＴＭのみのＭＲＢに再構成することができる。
　この場合、２．１節で述べたロスレスベアラタイプの変更もロスレスハンドオーバのために重要である。
　所見５：ＰＴＭのみのＭＲＢのロスレスハンドオーバには、ロスレスベアラタイプ変更が必須である。
　以上のことから、ロスレスハンドオーバの基本手順のポイントは、ＰＴＰレグを使用するか、ＰＴＭのみのＭＲＢを再構成する（＝ステップ１）ことと、ハンドオーバ実行は既存のユニキャストハンドオーバと同じで、何の拡張もないことである。
　提案１２：ＲＡＮ２は、ＭＲＢの基本的なロスレスハンドオーバが常にＰＴＰ（－ｌｅｇ）を含む必要があることに合意すべきである。つまり、スプリットＭＲＢのＰＴＰレグが使用されるか、ＰＴＭのみのＭＲＢをＰＴＰのみのＭＲＢ（又は、スプリットＭＲＢ）に再構成してからハンドオーバを実行する。
　提案１３：ＲＡＮ２は、ＭＲＢのハンドオーバの実行はユニキャストのハンドオーバと同じであること、つまり、基本的なロスレスハンドオーバのための拡張は必要ないことに合意すべきである。
　次に、最も興味深い高度な手順は、直接ＰＴＭ－ＰＴＭハンドオーバである。つまり、ＰＴＭ（－ｌｅｇ）を介してＭＢＳを受信しているＵＥがロスレスハンドオーバを実行する。上記の基本的なハンドオーバ手順のシグナリングオーバーヘッドと複雑さを軽減できる。つまり、ステップ１とステップ３とをスキップできる。さらに、このような直接的なＰＴＭ－ＰＴＭロスレスハンドオーバは、特にＰＴＰレグが設定されたスプリットＭＲＢで予想されると考えられる。つまり、より高い信頼性を必要とするサービスに使用される。ただし、それはすでにリリース１７タイムフレームの中間点を過ぎており、ＷＩＤは「サービス継続性を伴う基本的なモビリティのサポートを指定する」と述べているだけである。そのため、高度なロスレスハンドオーバは、将来のリリースまで延期する必要がある。
　所見６：ＰＴＭ（－ｌｅｇ）を介してＭＢＳサービスを受けるＵＥの高度なロスレスハンドオーバ、つまり「直接ＰＴＭ－ＰＴＭハンドオーバ」は、特定のサービスでは有用であると考えられるが、Ｒｅｌ１７タイムフレームの残りの時間を考慮すると、将来のリリースに延期する必要がある場合がある。
　２．４．マルチキャストのＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎ
　ＲＡＮ２は現在、ブロードキャストセッションではＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎがサポートされていると想定しているが、マルチキャストセッションではサポートされていない。ＲＡＮ２＃１１５ｅは、次のようにＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎの基本的な内容に合意した。
　ＣＯＮＮＥＣＴＥＤの場合
　ＵＥは以下のＭＢＳ　Ｉｎｔｅｒｅｓｔ　ｉｎｆｏｒｍａｔｉｏｎを（ＬＴＥ　ＳＣ－ＰＴＭとして）報告する。
　ＭＢＳ周波数リスト
　リスト化されたすべてのＭＢＭＳ周波数の受信と、任意のユニキャスト・ベアラの受信の間の優先順位
　ＴＭＧＩリスト
　ＭＢＳ周波数の報告が許可されている場合、ＵＥが報告するＭＢＳ周波数は、ＬＴＥ　ＳＣ－ＰＴＭと同様に関心の高い順に並べ替えられる。
　マルチキャストセッションの場合、マルチキャストセッションでは上位層にセッション参加手順があるため、コアネットワークがｇＮＢにＵＥの関心を通知するというのが一般的な理解のようである。これはＵＥの興味のあるＭＢＳサービスに当てはまる。また、ｇＮＢがＭＢＳ周波数と、ＵＥの興味のあるＭＢＳサービスを提供するセルを知っている可能性もある。ただし、ＭＢＳ受信とユニキャストの間の優先順位は、純粋にＡＳ関連の情報であるため、コアネットワークによって提供されない場合がある。
　所見７：マルチキャストセッションでは、コアネットワークはＵＥの関心事であるＭＢＳサービスをｇＮＢに提供し、ｇＮＢはＭＢＳ周波数／セルを知っている可能性がある。しかし、コアネットワークとｇＮＢとは、ＭＢＳとユニキャストとの間のＵＥのＡＳ優先度を知らない可能性がある。
　優先度情報は、ＬＴＥ　ｅＭＢＭＳと同様に、スケジューリングやハンドオーバの決定など、ｇＮＢにとっても有用であり、サービスの継続性にも関係すると考えられる。したがって、ＵＥは、マルチキャストセッションについても、その優先度情報をｇＮＢに通知する必要がある。この意味で、ＲＡＮ２は、マルチキャストサービス／配信モード１についてもＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎがサポートされるべきであると合意すべきである。
　提案１４：ＲＡＮ２は、少なくともＵＥがＭＢＳ受信とユニキャスト受信との間の優先順位をｇＮＢに通知するために、ＭＢＳ　Ｉｎｔｅｒｅｓｔ　Ｉｎｄｉｃａｔｉｏｎがマルチキャストセッション／第１配信モードでもサポートされることに合意すべきである。
１　　　　　　：移動通信システム
１０　　　　　：ＲＡＮ
２０　　　　　：ＣＮ
１００　　　　：ＵＥ
１０１　　　　：受信側ＰＤＣＰエンティティ
１１０　　　　：受信部
１２０　　　　：送信部
１３０　　　　：制御部
２００　　　　：ｇＮＢ
２０１　　　　：送信側ＰＤＣＰエンティティ
２１０　　　　：送信部
２２０　　　　：受信部
２３０　　　　：制御部
２４０　　　　：バックホール通信部

Claims (13)

  1. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）を基地局から受信するユーザ装置で実行する通信方法であって、
    　前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ）　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記基地局から受信することと、
    　前記ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号に基づいて、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定することと、を有する
    　通信方法。
  2. 　前記決定することは、前記ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号と、前記基地局から前記ユーザ装置が受信するＰＤＣＰデータＰＤＵに含まれるＰＤＣＰシーケンス番号とから、前記初期値を決定することを含む
    　請求項１に記載の通信方法。
  3. 　前記ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、
    　前記ハイパーフレーム番号と対応付けられたマルチキャスト無線ベアラ（ＭＲＢ）識別子と、
    　前記ハイパーフレーム番号と対応付けられたＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｇｒｏｕｐ　Ｉｄｅｎｔｉｔｙ）と、をさらに含む
    　請求項１又は２に記載の通信方法。
  4. 　前記ＰＤＣＰ状態変数は、ハイパーフレーム番号（ＨＦＮ）及びＰＤＣＰシーケンス番号（ＰＤＣＰ　ＳＮ）からなるＣＯＵＮＴ値を含む
    　請求項１又は２に記載の通信方法。
  5. 　前記ＰＤＣＰ状態変数は、次に受信することが期待されるＰＤＣＰ　ＳＤＵのＣＯＵＮＴ値を示すＲＸ＿ＮＥＸＴを含む
    　請求項１又は２に記載の通信方法。
  6. 　前記ＰＤＣＰ状態変数は、受信待ちであって、未だ上位レイヤに提供していないＰＤＣＰ　ＳＤＵのうち最も古いものを示すＲＸ＿ＤＥＬＩＶを含む
    　請求項１又は２に記載の通信方法。
  7. 　前記基地局から受信した前記ハイパーフレーム番号を記憶することと、
    　前記ハイパーフレーム番号を前記基地局から受信した後に、前記基地局から最初のＰＤＣＰデータＰＤＵを受信することと、をさらに有し、
    　前記初期値を決定することは、前記記憶されたハイパーフレーム番号と、前記最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰシーケンス番号とから、前記初期値を決定することを含む
    　請求項１又は２に記載の通信方法。
  8. 　前記ハイパーフレーム番号の提供を要求する要求信号を前記基地局に送信することをさらに有し、
    　前記ハイパーフレーム番号を受信することは、前記要求信号に応じて前記基地局から送信される前記ハイパーフレーム番号を受信することを含む
    　請求項１又は２に記載の通信方法。
  9. 　前記要求信号を送信することは、前記ユーザ装置においてＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及び前記ユーザ装置においてＭＢＳ受信を連続して失敗した回数が所定時間を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたことに応じて、前記要求信号を送信することを含む
    　請求項８に記載の通信方法。
  10. 　前記ユーザ装置においてＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及び前記ユーザ装置においてＭＢＳ受信を連続して失敗した回数が所定時間を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたことに応じて、前記初期値によって前記ＰＤＣＰ状態変数を初期化することをさらに有する
    　請求項１又は２に記載の通信方法。
  11. 　前記第１条件及び前記第２条件のいずれの条件も満たされない場合、前記基地局から受信する前記ハイパーフレーム番号を無視又は破棄することをさらに有する
    　請求項１０に記載の通信方法。
  12. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）を基地局から受信するユーザ装置であって、
    　前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ）　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記基地局から受信する受信部と、
    　前記ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号に基づいて、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定する制御部と、を備える
    　ユーザ装置。
  13. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）をユーザ装置に送信する基地局であって、
    　前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ）　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記ユーザ装置に送信する送信部を備える
    　基地局。
PCT/JP2022/037903 2021-10-14 2022-10-11 通信方法、ユーザ装置、及び基地局 WO2023063323A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023554539A JPWO2023063323A1 (ja) 2021-10-14 2022-10-11

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163255573P 2021-10-14 2021-10-14
US63/255,573 2021-10-14

Publications (1)

Publication Number Publication Date
WO2023063323A1 true WO2023063323A1 (ja) 2023-04-20

Family

ID=85987987

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/037903 WO2023063323A1 (ja) 2021-10-14 2022-10-11 通信方法、ユーザ装置、及び基地局

Country Status (2)

Country Link
JP (1) JPWO2023063323A1 (ja)
WO (1) WO2023063323A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100293372A1 (en) * 2006-03-22 2010-11-18 Patrick Fischer Asymmetric cryptography for wireless systems
JP2017518667A (ja) * 2014-04-22 2017-07-06 エルジー エレクトロニクス インコーポレイティド Ｄ２ｄ通信システムのための階層−２の状態変数の明示的信号を送信する方法及びその装置
WO2018084195A1 (ja) * 2016-11-04 2018-05-11 京セラ株式会社 無線端末及び基地局
CN111818630A (zh) * 2019-07-12 2020-10-23 维沃移动通信有限公司 状态变量维护方法、装置及用户设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100293372A1 (en) * 2006-03-22 2010-11-18 Patrick Fischer Asymmetric cryptography for wireless systems
JP2017518667A (ja) * 2014-04-22 2017-07-06 エルジー エレクトロニクス インコーポレイティド Ｄ２ｄ通信システムのための階層−２の状態変数の明示的信号を送信する方法及びその装置
WO2018084195A1 (ja) * 2016-11-04 2018-05-11 京セラ株式会社 無線端末及び基地局
CN111818630A (zh) * 2019-07-12 2020-10-23 维沃移动通信有限公司 状态变量维护方法、装置及用户设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
XIAOMI COMMUNICATIONS: "Remaining PDCP issues for MBS", 3GPP DRAFT; R2-2108797, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. electronic; 20210809 - 20210827, 6 August 2021 (2021-08-06), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP052035128 *

Also Published As

Publication number Publication date
JPWO2023063323A1 (ja) 2023-04-20

Similar Documents

Publication Publication Date Title
WO2022085757A1 (ja) 通信制御方法
JP6645963B2 (ja) ユーザ端末及び移動通信システム
US20230050170A1 (en) Methods and apparatus of group scheduling for nr multicast service
WO2022085717A1 (ja) 通信制御方法
US20240080939A1 (en) Communication control method and user equipment
WO2022153991A1 (ja) 通信制御方法
US20230134356A1 (en) Methods and apparatus to set initial pdcp state variables for multicast
CN114698018B (zh) 发起pdcp状态报告进程的方法和用户设备
WO2023063323A1 (ja) 通信方法、ユーザ装置、及び基地局
WO2022000180A1 (en) Methods and apparatus of reliable multicast transmission with uplink feedback
WO2023063371A1 (ja) 通信方法
CN117062141A (zh) 发起pdcp状态报告进程的方法和用户设备
WO2023013671A1 (ja) 通信方法
WO2023013669A1 (ja) 通信方法、ユーザ装置、及び基地局
WO2023013670A1 (ja) 通信方法及びユーザ装置
US20240179580A1 (en) Communication method
WO2023074721A1 (ja) 通信方法及びユーザ装置
WO2022085573A1 (ja) 通信制御方法
WO2022153990A1 (ja) 通信制御方法及びユーザ装置
WO2023013608A1 (ja) 通信方法
US20240179799A1 (en) Communication method, user equipment, and base station
US20240179800A1 (en) Communication method and user equipment
WO2024034567A1 (ja) 通信方法
US20240040662A1 (en) Communication control method and user equipment
WO2022234847A1 (ja) 通信制御方法及びユーザ装置

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023554539

Country of ref document: JP

Kind code of ref document: A