WO2023063371A1 - 通信方法 - Google Patents

通信方法 Download PDF

Info

Publication number
WO2023063371A1
WO2023063371A1 PCT/JP2022/038110 JP2022038110W WO2023063371A1 WO 2023063371 A1 WO2023063371 A1 WO 2023063371A1 JP 2022038110 W JP2022038110 W JP 2022038110W WO 2023063371 A1 WO2023063371 A1 WO 2023063371A1
Authority
WO
WIPO (PCT)
Prior art keywords
mrb
pdcp
mbs
rrc
base station
Prior art date
Application number
PCT/JP2022/038110
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Publication of WO2023063371A1 publication Critical patent/WO2023063371A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • 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 a communication method used in a mobile communication system.
  • 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 and user equipment that enable improved multicast broadcast services to be realized.
  • a communication method is a communication method executed by a user apparatus in a mobile communication system that provides a multicast broadcast service (MBS), and transmits MBS data from a base station via a multicast radio bearer (MRB).
  • MBS multicast broadcast service
  • MRB multicast radio bearer
  • RRC radio resource control
  • a communication method is a communication method executed by a user apparatus in a mobile communication system that provides a multicast broadcast service (MBS), and transmits MBS data from a base station via a multicast radio bearer (MRB). and a transition from the RRC idle state or the RRC inactive state to the RRC connected state, and/or in response to the MBS data packet being discarded in the RLC layer, associated with the MRB spontaneously triggering transmission of a PDCP status report indicating data reception status at a PDCP entity; and transmitting said PDCP status report to said base station.
  • MBS multicast broadcast service
  • MRB multicast radio bearer
  • a communication method is a communication method executed by a base station in a mobile communication system that provides a multicast broadcast service (MBS), and transmits MBS data to a user device via a multicast radio bearer (MRB). and transmitting an RRC reconfiguration message to the user equipment, the message indicating a bearer type change of the MRB, the RRC reconfiguration message including a first information element indicating re-establishment of a PDCP entity associated with the MRB. and receiving a PDCP status report transmitted from the user equipment based on the first information element.
  • the step of transmitting the RRC reconfiguration message further includes a second information element indicating to maintain the state of the header compression protocol of the PDCP entity when the first information element is included in the RRC reconfiguration message. Sending an RRC reconfiguration message.
  • a user device is a user device used in a mobile communication system that provides a multicast broadcast service (MBS), receives MBS data from a base station via a multicast radio bearer (MRB), a receiving unit for receiving from the base station a radio resource control (RRC) reconfiguration message instructing to change the MRB bearer type; and an MRB type in which the bearer type change indicated by the RRC reconfiguration message is AM (Acknowledged Mode) , a control unit that triggers transmission of a PDCP status report indicating the data reception status in the PDCP entity associated with the MRB, and a transmission unit that transmits the PDCP status report to the base station And prepare.
  • MBS multicast broadcast service
  • MRB multicast radio bearer
  • RRC radio resource control
  • AM Acknowledged Mode
  • 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 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;
  • Figure 4 illustrates the operation of a receiving PDCP entity in a UE with respect to PDCP status reporting according to an embodiment;
  • Figure 4 illustrates the operation of a UE's RRC entity for PDCP status reporting according to an embodiment; It is a figure which shows the structural example of the PDCP status report which concerns on embodiment.
  • FIG. 4 is a diagram showing operations of a UE according to the first embodiment;
  • FIG. 4 is a diagram illustrating the operation of a receiving side PDCP entity of the UE according to the first example of the first embodiment;
  • FIG. 10 is a diagram illustrating the operation of a receiving side PDCP entity of the UE according to the second example of the first embodiment;
  • FIG. 10 is a diagram illustrating the operation of a receiving side PDCP entity in a UE according to the third example of the first embodiment;
  • FIG. 10 is a diagram showing the operation of a UE according to the second embodiment;
  • FIG. 10 is a diagram showing operations of a mobile communication system according to a third embodiment;
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to the first embodiment.
  • the mobile communication system 1 complies with the 3GPP standard 5th generation system (5GS: 5th Generation System).
  • 5GS will be described below as an example, an LTE (Long Term Evolution) system may be at least partially applied to the mobile communication system.
  • 6G 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 includes a mobile phone terminal (including a smartphone), a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or a device provided in the 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 first embodiment.
  • UE 100 includes a receiver 110 , a transmitter 120 and a controller 130 .
  • the receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200 .
  • the receiving unit 110 performs various types of reception under the control of the control unit 130.
  • the receiver 110 includes an antenna and a receiver.
  • the receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal (received signal) to control section 130 .
  • the transmission unit 120 performs various transmissions under the control of the control unit 130.
  • the transmitter 120 includes an antenna and a transmitter.
  • the transmitter converts a baseband signal (transmission signal) output from the control unit 130 into a radio signal and transmits the radio signal from an antenna.
  • Control unit 130 performs various controls and processes in the UE 100. Such processing includes processing of each layer, which will be described later.
  • Control unit 130 includes at least one processor and at least one memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU (Central Processing Unit).
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • FIG. 3 is a diagram showing the configuration of the gNB 200 (base station) according to the first embodiment.
  • the gNB 200 comprises a transmitter 210 , a receiver 220 , a controller 230 and a backhaul communicator 240 .
  • the transmitting unit 210 and the receiving unit 220 constitute a radio communication unit that performs radio communication with the UE 100 .
  • the backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20 .
  • the transmission unit 210 performs various transmissions under the control of the control unit 230.
  • Transmitter 210 includes an antenna and a transmitter.
  • the transmitter converts a baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits the radio signal from an antenna.
  • 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 first embodiment.
  • MBS traffic (MBS data) is delivered from a single data source (application service provider) to multiple UEs.
  • a 5G CN (5GC) 20 which is a 5G core network, receives MBS data from an application service provider, creates a copy of the MBS data (Replication), and distributes it.
  • 5GC20 From the perspective of 5GC20, two multicast delivery methods are possible: 5GC Shared MBS Traffic delivery and 5GC Individual MBS Traffic delivery.
  • the 5GC 20 receives single copies of MBS data packets and delivers individual copies of those MBS data packets to individual UEs 100 via per-UE 100 PDU sessions. Therefore, one PDU session per UE 100 needs to be associated with the multicast session.
  • the 5GC 20 receives a single copy of MBS data packets and delivers the single copy of those MBS packets to the RAN nodes (ie gNB 200).
  • a gNB 200 receives MBS data packets over an MBS tunnel connection and delivers them to one or more UEs 100 .
  • PTP Point-to-Point
  • PTM Point-to-Multipoint
  • the gNB 200 delivers individual copies of MBS data packets to individual UEs 100 over the air.
  • the gNB 200 delivers a single copy of MBS data packets to a group of UEs 100 over the air.
  • the gNB 200 can dynamically determine which of PTM and PTP to use as the MBS data delivery method for one UE 100 .
  • the PTP and PTM delivery methods are primarily concerned with the user plane. There are two distribution modes, a first distribution mode and a second distribution mode, as MBS data distribution control modes.
  • FIG. 7 is a diagram showing distribution modes according to the first embodiment.
  • the first delivery mode (delivery mode 1: DM1) is a delivery mode that can be used by UE 100 in the RRC connected state, and is a delivery mode for high QoS requirements.
  • the first delivery mode is used for multicast sessions among MBS sessions. However, the first delivery mode may be used for broadcast sessions.
  • the first delivery mode may also be available for UEs 100 in RRC idle state or RRC inactive state.
  • MBS reception settings in the first delivery mode are done by UE-dedicated signaling.
  • MBS reception settings in the first distribution mode are performed by an RRC Reconfiguration message (or RRC Release message), which is an RRC message unicast from the gNB 200 to the UE 100 .
  • the MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") regarding the configuration of 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 regarding MBS reception of the UE 100 according to the first embodiment.
  • FIG. 9 is a diagram showing another example of internal processing regarding MBS reception of the UE 100 according to the first 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".
  • the bearer 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 first 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 gNB 200 has an RRC entity 202 that transmits and receives RRC signaling to and from each UE 100.
  • Each UE 100 has an RRC entity 102 (RRC entities 102a to 102c) that transmits and receives RRC signaling to and from the gNB 200 .
  • the RRC entity 102 of the UE 100 controls the receiving side PDCP entity 101 of the UE 100 based on RRC signaling received from the RRC entity 202 of the gNB 200 .
  • 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
  • UE 100 transmits to gNB 200 a PDCP status report (Status Report) indicating the data reception status in the PDCP layer.
  • the gNB 200 can identify missing PDCP packets (PDCP SDUs) based on the PDCP status report from the UE 100 and retransmit the identified PDCP packets to the UE 100 .
  • PDCP SDUs missing PDCP packets
  • FIG. 14 is a diagram showing the operation of the receiving side PDCP entity 101 of the UE 100 regarding PDCP status reporting. Note that FIG. 14 is a quote from the 3GPP technical specification “TS38.323” for the PDCP layer.
  • the receiving-side PDCP entity 101 of the UE 100 performs the following for the data radio bearer (DRB) in the acknowledged mode (AM) set by the upper layer (RRC layer) to transmit the PDCP status report. Trigger the transmission of PDCP status reports if any of the conditions are met: - the upper layer requests a PDCP entity re-establishment; - upper layer requests a PDCP data recovery; - upper layer requests a uplink data switching; - The upper layer reconfigures the PDCP entity to release DAPS.
  • DRB data radio bearer
  • AM acknowledged mode
  • RRC layer upper layer
  • FIG. 15 is a diagram showing the operation of the RRC entity 102 of the UE 100 regarding PDCP status reporting. Note that FIG. 15 is a quote from the 3GPP technical specification “TS38.331” for the RRC layer.
  • the RRC entity 102 of the UE 100 For each DRB identifier (drb-Identity) included in the drb-ToAddModList that is part of the current UE configuration, the RRC entity 102 of the UE 100: - If re-establish PDCP is set, re-establish the PDCP entity for that DRB; • If PDCP recovery (recoverPDCP) is set, triggers the PDCP entity of that DRB to perform data recovery.
  • the UE 100 triggers the transmission of PDCP status reports in response to being instructed to PDCP re-establishment or PDCP recovery by RRC signaling from the gNB 200.
  • the existing technical specifications do not define whether or not to apply the PDCP status report for the MRB, and how to trigger the PDCP status report when applying the PDCP status report for the MRB.
  • FIG. 16 is a diagram showing a configuration example of a PDCP status report.
  • a D / C field indicating that the PDU is a control PDU and a PDU type field indicating that the PDU is a PDCP status report are provided.
  • the PDCP status report includes FMC (First missing COUNT) and bitmap fields.
  • the FMC field is set to the COUNT value of the first missing PDCP SDU in the reordering window, ie RX_DELIV.
  • a bit associated with each PDCP PDU is set in the bitmap field, and "1" is set when it is received correctly, and "0" is set when it is missing.
  • the PDCP status report includes FMC and LMC (Last missing COUNT) fields.
  • the sequence number (COUNT value) of the last packet in the missing packet group is set in the LMC field.
  • the COUNT value (LMC+1, for example, First Successful COUNT: FSC) of the first successfully received packet may be set.
  • the bit length of the bitmap field can be long (for example, the bitmap for 200 packets is 200 bits), but by providing the LMC field instead of the bitmap field, the PDCP status report Bit length can be shortened.
  • the RRC entity 202 of the gNB 200 can change the MRB bearer type through RRC signaling, specifically an RRC Reconfiguration message, sent to the RRC entity 102 of the UE 100 .
  • RRC signaling specifically an RRC Reconfiguration message
  • a processing delay occurs from when the UE 100 receives the RRC reconfiguration message to when the RRC reconfiguration processing is completed. MBS data cannot be received during this delay time, and the UE 100 suffers from the problem of missing MBS data packets, ie, packet loss.
  • the PDCP layer has PDCP status reporting as a mechanism that can compensate for packet loss.
  • UE 100 transmits a PDCP status report indicating the data reception status in the PDCP layer to gNB 200 .
  • the gNB 200 can identify the missing PDCP packets based on the PDCP status report from the UE 100 and retransmit the identified PDCP packets to the UE 100 .
  • the first embodiment is an embodiment in which the UE 100 voluntarily triggers the transmission of a PDCP status report so that the packet loss caused by the MRB bearer type change can be compensated for by the PDCP status report. Specifically, for PDCP status reporting, a new transmission trigger condition for MBS reception is introduced.
  • FIG. 17 is a diagram showing the operation of the UE 100 according to the first embodiment.
  • step S1 the UE 100 receives MBS data from the gNB 200 via the MRB.
  • MBS bearer types include "PTM only", “PTP only”, or "both PTM and PTP” (i.e. split MRB).
  • PTM only a type of MBS
  • PTP packet transfer protocol
  • step S2 the UE 100 receives from the gNB 200 an RRC Reconfiguration message that instructs to change the bearer type of the MRB.
  • the RRC Reconfiguration message contains a configuration to change the bearer type of an established MRB.
  • the RRC reconfiguration message may include the bearer identifier of the MRB and bearer type information indicating the bearer type to which the MRB is to be changed.
  • step S3 the UE 100 determines whether the bearer type change indicated by the RRC reconfiguration message received in step S2 is a predetermined bearer type change.
  • step S4 the UE 100 uses PDCP indicating the data reception status in the PDCP entity (receiving side PDCP entity 101) associated with the MRB. Voluntarily trigger the sending of status reports.
  • step S5 the UE 100 transmits a PDCP status report to the gNB 200.
  • the UE 100 spontaneously triggers the transmission of the PDCP status report when instructed by the gNB 200 to change a predetermined bearer type. This allows packet loss due to MRB bearer type changes to be compensated for by PDCP status reporting.
  • the UE 100 triggers the transmission of the PDCP status report without being explicitly instructed by the gNB 200 to trigger the transmission of the PDCP status report.
  • the UE 100 triggers transmission of PDCP status reports in response to certain bearer type changes without being instructed to PDCP re-establishment or PDCP recovery by RRC signaling from the gNB 200 .
  • PDCP status reporting is performed without PDCP re-establishment or PDCP recovery. can be triggered to send
  • a predetermined bearer type change for example, for MBS services that allow packet loss
  • Such behavior applies to bearer type changes of established MRBs and does not apply when establishing new MRBs. That is, the UE 100 does not spontaneously trigger the transmission of PDCP status reports when establishing a new MRB.
  • the predetermined bearer type change is a change to a PTP (Point-To-Point) only MRB type or a change to a split MRB. That is, the UE 100 triggers transmission of the PDCP status report (only) when changed to PTP only or split MRB.
  • the bearer type change to PTP only or split MRB has the following four patterns: 1) PTM only ⁇ PTP only; 2) PTM only ⁇ split MRB; 3) PTP only ⁇ split MRB; 4) Split MRB ⁇ PTP only.
  • a PTM-only MRB cannot transmit a PDCP status report because there is no uplink path. Also, it is considered that PTM-only MRBs do not require high reliability compared to PTP-only MRBs and split MRBs. Therefore, in this embodiment, the transmission of the PDCP status report is triggered (only) when changing to PTP only or split MRB.
  • FIG. 18 is a diagram showing the operation of the receiving side PDCP entity 101 of the UE 100 according to this embodiment.
  • FIG. 18 portions different from FIG. 14 are underlined.
  • “DRB” in FIG. 18 may be read as "MRB”.
  • statusReportRequired is set in the PDCP entity of the MRB (receiving side PDCP entity 101), and when the higher layer resets the PDCP entity so that the bearer type is changed to PTP only or split MRB (upper layer reconfigures the PDCP entity to change bearer type to PTP-only MRB or Split MRB), triggering PDCP status reporting.
  • the predetermined bearer type change is a change to the MRB type of AM (Acknowledged Mode). That is, the UE 100 triggers transmission of the PDCP status report (only) when changed to AM MRB.
  • a PTM-only MRB is considered to be treated as a UM (Unacknowledged Mode) MRB. Also, since PTM (especially PTM only) is more efficient in using radio resources than PTP, gNB 200 is considered to have a motivation to make UE 100 PTM (-only) as much as possible.
  • the gNB 200 for example, uses PTM (-only) (i.e., UM MRB) when the radio conditions are good, and uses PTP only or split MRB (i.e., AM MRB) when the radio conditions deteriorate. It is thought that it will be done by change. Note that the radio conditions can be determined, for example, from existing measurement reports.
  • PTM -only
  • UM MRB UM MRB
  • PTP only or split MRB i.e., AM MRB
  • the UE 100 spontaneously triggers the transmission of the PDCP status report when changed to AM MRB.
  • AM MRB There are two patterns for changing to AM MRB (MRB resetting): 1) UM MRB ⁇ AM MRB; 2) AM MRB ⁇ AM MRB; For example, from split MRB to PTP-only MRB.
  • FIG. 19 is a diagram showing the operation of the receiving side PDCP entity 101 of the UE 100 according to this embodiment.
  • FIG. 19 parts different from FIG. 14 are underlined.
  • “DRB” in FIG. 19 may be read as "MRB”.
  • the predetermined bearer type change is a change from a PTM-only MRB type to another MRB type. That is, the UE 100 triggers PDCP status reporting (only) when changed from PTM-only to non-PTM-only.
  • a split MRB can perform packet loss compensation using a PTP leg, but when packet loss compensation is performed for a PTM-only MRB, it is always necessary to change the bearer type. Therefore, it is intended to trigger PDCP status reporting (only) when changing from PTM-only to non-PTM-only.
  • FIG. 20 is a diagram showing the operation of the receiving side PDCP entity 101 of the UE 100 according to this embodiment.
  • FIG. 20 portions different from FIG. 14 are underlined.
  • “DRB” in FIG. 20 may be read as "MRB”.
  • the upper layer reconfigures the PDCP entity so that the bearer type is changed from only PTP to another type (upper layer reconfigures the PDCP entity to change bearer type from PTP-only to other type), triggering PDCP status reporting.
  • a scenario is mainly assumed in which the UE 100 performing MBS reception (PTM reception) in the RRC idle state or RRC inactive state transitions to the RRC connected state by a random access procedure.
  • PTM reception MBS reception
  • the UE 100 cannot perform MBS reception during the random access procedure, and packet loss of MBS data may occur.
  • the second embodiment is an embodiment capable of compensating for such packet loss.
  • the UE 100 spontaneously triggers transmission of the PDCP status report when transitioning to the RRC connected state.
  • the RRC entity 102 of the UE 100 notifies the receiving side PDCP entity 101 that it has transitioned to the RRC connected state, and the receiving side PDCP entity 101 may spontaneously trigger the transmission of the PDCP status report in response to the notification.
  • the UE 100 may autonomously trigger PDCP status reporting when packet discard occurs in RLC.
  • the receiving PDCP entity 101 of the UE 100 may autonomously trigger a PDCP status report when informed of packet discard by the RLC layer.
  • FIG. 21 is a diagram showing the operation of the UE 100 according to the second embodiment.
  • step S11 UE 100 in RRC idle state or RRC inactive state receives MBS data from gNB 200 via MRB.
  • step S12 the UE 100 determines whether at least one condition of transition from the RRC idle state or the RRC inactive state to the RRC connected state, and that the MBS data packet is discarded in the RLC layer is satisfied. judge.
  • step S13 the UE 100 spontaneously triggers transmission of a PDCP status report indicating the data reception status in the PDCP entity associated with the MRB. .
  • step S14 the UE 100 transmits a PDCP status report to the gNB 200.
  • the third embodiment is the same as the first and second embodiments in that gNB 200 instructs UE 100 to change the bearer type for MRB, but at the time of the instruction, gNB 200 triggers PDCP status report to UE 100
  • the gNB 200 instructs the re-establishment of the PDCP entity (receiving side PDCP entity 101) associated with the MRB in the RRC message (RRC reconfiguration message) instructing to change the bearer type of the MRB.
  • RRC message RRC reconfiguration message
  • the header compression protocol in the PDCP entity (receiving side PDCP entity 101), specifically, the operation of RoHC (Robust Header Compression) is reset, and the RoHC context is also reset.
  • the RoHC context includes fixed values in the header and information for predicting values in the header, and is information necessary for the UE 100 to decompress the compressed header. If the RoHC context is also reset, it is necessary to send and receive the complete uncompressed header after the bearer type change, which causes a problem of increased overhead.
  • the gNB 200 when the gNB 200 includes the first information element (reestablish PDCP) in the RRC reconfiguration message that instructs to change the MRB bearer type, the header compression protocol of the PDCP entity of the UE 100 (receiving side PDCP entity 101) A second information element (drb-ContinueROHC) instructing to maintain the state of (eg, RoHC context) is included in the RRC reconfiguration message.
  • the header compression protocol state (eg, RoHC context) of the PDCP entity (receiving side PDCP entity 101) of the UE 100 is maintained, so it is possible to transmit and receive compressed headers even after the bearer type is changed. .
  • FIG. 22 is a diagram showing the operation of the mobile communication system 1 according to the third embodiment.
  • step S101 the UE 100 receives MBS data from the gNB 200 via the MRB.
  • the gNB 200 decides to change the bearer type for the MRB. Specifically, the gNB 200 decides to change between three types: PTP only, PTM only, and split MRB (PTP leg and PTM leg). For example, the gNB 200 makes the decision in step S102 according to the radio quality report (measurement report) from the UE 100 and/or the radio resource status of the gNB 200, or the like.
  • the gNB 200 transmits an RRC reconfiguration message for changing the bearer type to the UE 100.
  • the RRC Reconfiguration message contains a configuration to change the bearer type of an established MRB.
  • the RRC reconfiguration message may include the bearer identifier of the MRB and bearer type information indicating the bearer type to which the MRB is to be changed.
  • the gNB 200 sets “reestablish PDCP “true”” and “drb-Continue ROHC “true”” in the RRC reconfiguration message in association with the MRB identifier.
  • step S104 the UE 100 that has received the RRC reconfiguration message reestablishes the PDCP entity (receiving side PDCP entity 101) according to "reestablish PDCP "true”” included in the RRC reconfiguration message, and according to the re-establishment Trigger the transmission of PDCP status reports (see PDCP operation in FIG. 14).
  • the UE 100 continues the RoHC process according to "reestablish PDCP "true”” included in the RRC reconfiguration message (specifically, continues to use the RoHC context used until immediately before, and maintains the RoHC state do).
  • the UE 100 transmits a PDCP status report to the gNB 200.
  • the gNB 200 receives PDCP status reports.
  • 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 operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow.
  • 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 PDCP status reports 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 10 ms. 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 reporting should be supported at least to meet the higher reliability required by certain MBS services.
  • Proposal 1 RAN2 should agree that PDCP status reporting is supported at least between AM MRBs and for lossless bearer type changes 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 PDCP status reporting in certain cases, it is readily apparent that the UM MRB can be configured to determine whether the NW requires PDCP status reporting. 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 PDCP status reporting when changing the UM MRB bearer type depends on the implementation of the NW. 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, it may be possible to minimize the timing gap between the PDCP Control PDU and the first received packet. 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 in a multicast session there is a session join procedure in higher layers. 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)
  • Mobile Radio Communication Systems (AREA)

Abstract

第１の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信するステップと、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信するステップと、前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガするステップと、前記ＰＤＣＰステータス報告を前記基地局に送信するステップと、を有する。

Description

通信方法
　本開示は、移動通信システムで用いる通信方法に関する。
　３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）規格において、第５世代（５Ｇ）の無線アクセス技術であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）の技術仕様が規定されている。ＮＲは、第４世代（４Ｇ）の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。３ＧＰＰにおいて、５Ｇ／ＮＲのマルチキャストブロードキャストサービス（ＭＢＳ）の技術仕様を策定する議論が行われている（例えば、非特許文献１参照）。
　５Ｇ／ＮＲのマルチキャストブロードキャストサービスは、４Ｇ／ＬＴＥのマルチキャストブロードキャストサービスよりも改善されたサービスを提供することが望まれる。
　そこで、本開示は、改善されたマルチキャストブロードキャストサービスを実現可能とする通信方法及びユーザ装置を提供することを目的とする。
　第１の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信するステップと、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信するステップと、前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガするステップと、前記ＰＤＣＰステータス報告を前記基地局に送信するステップと、を有する。
　第２の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信するステップと、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移したこと、及び／又は、ＲＬＣレイヤにおいてＭＢＳデータパケットの破棄が発生したことに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガするステップと、前記ＰＤＣＰステータス報告を前記基地局に送信するステップと、を有する。
　第３の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて基地局が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介してＭＢＳデータをユーザ装置に送信するステップと、前記ＭＲＢのベアラタイプ変更を指示するメッセージであって、前記ＭＲＢと対応付けられたＰＤＣＰエンティティの再確立を指示する第１情報要素を含むＲＲＣ再設定メッセージを前記ユーザ装置に送信するステップと、前記第１情報要素に基づいて前記ユーザ装置から送信されるＰＤＣＰステータス報告を受信するステップと、を有する。前記ＲＲＣ再設定メッセージを送信するステップは、前記第１情報要素を前記ＲＲＣ再設定メッセージに含める場合、前記ＰＤＣＰエンティティのヘッダ圧縮プロトコルの状態を維持することを指示する第２情報要素をさらに含む前記ＲＲＣ再設定メッセージを送信するステップを含む。
　第４の態様に係るユーザ装置は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いるユーザ装置であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信し、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信する受信部と、前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガする制御部と、前記ＰＤＣＰステータス報告を前記基地局に送信する送信部と、を備える。
実施形態に係る移動通信システムの構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 実施形態に係るＭＢＳトラフィック配信の概要を示す図である。 実施形態に係る配信モードを示す図である。 実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の一例を示す図である。 実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の他の例を示す図である。 実施形態に係る移動通信システムにおけるＰＤＣＰレイヤの動作を示す図である。 実施形態に係るＰＤＣＰ状態変数の一例を示す図である。 実施形態に係るＭＢＳデータを構成するＰＤＣＰデータＰＤＵの一例を示す図である。 実施形態に係るＵＥの受信側ＰＤＣＰエンティティにおいて受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。 実施形態に係るＰＤＣＰステータス報告に関するＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。 実施形態に係るＰＤＣＰステータス報告に関するＵＥのＲＲＣエンティティの動作を示す図である。 実施形態に係るＰＤＣＰステータス報告の構成例を示す図である。 第１実施形態に係るＵＥの動作を示す図である。 第１実施形態の第１実施例に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。 第１実施形態の第２実施例に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。 第１実施形態の第３実施例に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。 第２実施形態に係るＵＥの動作を示す図である。 第３実施形態に係る移動通信システムの動作を示す図である。
　図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　［第１実施形態］
　（移動通信システムの構成）
　図１は、第１実施形態に係る移動通信システムの構成を示す図である。移動通信システム１は、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ　Ｇｅｎｅｒａｔｉｏｎ　Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。また、移動通信システムには第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
　移動通信システム１は、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ　Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）２０とを有する。以下において、ＮＧ－ＲＡＮ１０を単にＲＡＮ１０と呼ぶことがある。また、５ＧＣ２０を単にコアネットワーク（ＣＮ）２０と呼ぶことがある。
　ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）やタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ　ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ　ＵＥ）である。
　ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と呼ばれる）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数（以下、単に「周波数」と呼ぶ）に属する。
　なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。
　５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。
　図２は、第１実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。受信部１１０及び送信部１２０は、ｇＮＢ２００との無線通信を行う無線通信部を構成する。
　受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
　送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１３０は、ＵＥ１００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　図３は、第１実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。送信部２１０及び受信部２２０は、ＵＥ１００との無線通信を行う無線通信部を構成する。バックホール通信部２４０は、ＣＮ２０との通信を行うネットワーク通信部を構成する。
　送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
　制御部２３０は、ｇＮＢ２００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　バックホール通信部２４０は、基地局間インターフェイスであるＸｎインターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ　Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がフロントホールインターフェイスであるＦ１インターフェイスで接続されてもよい。
　図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。なお、ＵＥ１００のＰＨＹレイヤは、ｇＮＢ２００から物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される下りリンク制御情報（ＤＣＩ）を受信する。具体的には、ＵＥ１００は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＰＤＣＣＨのブラインド復号を行い、復号に成功したＤＣＩを自ＵＥ宛てのＤＣＩとして取得する。ｇＮＢ２００から送信されるＤＣＩには、ＲＮＴＩによってスクランブルされたＣＲＣパリティビットが付加されている。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化等を行う。
　ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。
　図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤを有する。
　ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間にコネクション（ＲＲＣコネクション）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間にコネクション（ＲＲＣコネクション）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間のコネクションがサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＡのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。また、ＮＡＳレイヤよりも下位のレイヤをＡＳレイヤと呼ぶ。
　（ＭＢＳの概要）
　第１実施形態に係るＭＢＳの概要について説明する。ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ　Ｔｏ　Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳのユースケース（サービスタイプ）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ　ｔｏ　Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ　ｐｒｏｔｏｃｏｌ　ｔｅｌｅｖｉｓｉｏｎ）、グループ通信、及びソフトウェア配信等が想定される。
　ブロードキャストサービスは、高信頼性のＱｏＳを必要としないアプリケーションのために、特定のサービスエリア内のすべてのＵＥ１００に対してサービスを提供する。ブロードキャストサービスに用いるＭＢＳセッションをブロードキャストセッションと呼ぶ。
　マルチキャストサービスは、すべてのＵＥ１００に対してではなく、マルチキャストサービス（マルチキャストセッション）に参加しているＵＥ１００のグループに対してサービスを提供する。マルチキャストサービスに用いるＭＢＳセッションをマルチキャストセッションと呼ぶ。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でＵＥ１００のグループに対して同じコンテンツを提供できる。
　図６は、第１実施形態に係るＭＢＳトラフィック配信の概要を示す図である。
　ＭＢＳトラフィック（ＭＢＳデータ）は、単一のデータソース（アプリケーションサービスプロバイダ）から複数のＵＥに配信される。５Ｇコアネットワークである５Ｇ　ＣＮ（５ＧＣ）２０は、アプリケーションサービスプロバイダからＭＢＳデータを受信し、ＭＢＳデータのコピーの作成（Ｒｅｐｌｉｃａｔｉｏｎ）を行って配信する。
　５ＧＣ２０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信（５ＧＣ　Ｓｈａｒｅｄ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）及び５ＧＣ個別ＭＢＳトラフィック配信（５ＧＣ　Ｉｎｄｉｖｉｄｕａｌ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）の２つのマルチキャスト配信方法が可能である。
　５ＧＣ個別ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、ＵＥ１００ごとのＰＤＵセッションを介してそれらのＭＢＳデータパケットの個別のコピーを個別のＵＥ１００に配信する。したがって、ＵＥ１００ごとに１つのＰＤＵセッションをマルチキャストセッションと関連付ける必要がある。
　５ＧＣ共有ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、それらのＭＢＳパケットの単一コピーをＲＡＮノード（すなわち、ｇＮＢ２００）に配信する。ｇＮＢ２００は、ＭＢＳトンネル接続を介してＭＢＳデータパケットを受信し、それらを１つ又は複数のＵＥ１００に配信する。
　ＲＡＮ（５Ｇ　ＲＡＮ）１０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信方法における無線を介したＭＢＳデータの送信には、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）の２つの配信方法が可能である。ＰＴＰはユニキャストを意味し、ＰＴＭはマルチキャスト及びブロードキャストを意味する。
　ＰＴＰ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの個別のコピーを無線で個々のＵＥ１００に配信する。他方、ＰＴＭ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの単一コピーを無線でＵＥ１００のグループに配信する。ｇＮＢ２００は、１つのＵＥ１００に対するＭＢＳデータの配信方法としてＰＴＭ及びＰＴＰのどちらを用いるかを動的に決定できる。
　ＰＴＰ配信方法及びＰＴＭ配信方法は主としてユーザプレーンに関するものである。ＭＢＳデータ配信の制御モードとしては、第１配信モード及び第２配信モードの２つの配信モードがある。
　図７は、第１実施形態に係る配信モードを示す図である。
　第１配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　１：ＤＭ１）は、ＲＲＣコネクティッド状態のＵＥ１００が利用できる配信モードであって、高ＱｏＳ要件のための配信モードである。第１配信モードは、ＭＢＳセッションのうちマルチキャストセッションに用いられる。但し、第１配信モードがブロードキャストセッションに用いられてもよい。第１配信モードは、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００も利用可能であってもよい。
　第１配信モードにおけるＭＢＳ受信の設定は、ＵＥ固有（ＵＥ－ｄｅｄｉｃａｔｅｄ）シグナリングにより行われる。例えば、第１配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にユニキャストで送信されるＲＲＣメッセージであるＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又はＲＲＣ　Ｒｅｌｅａｓｅメッセージ）により行われる。
　ＭＢＳ受信の設定は、ＭＢＳデータを伝送するＭＢＳトラフィックチャネルの設定に関するＭＢＳトラフィックチャネル設定情報（以下、「ＭＴＣＨ設定情報」と呼ぶ）を含む。ＭＴＣＨ設定情報は、ＭＢＳセッションに関するＭＢＳセッション情報（後述のＭＢＳセッション識別子を含む）と、このＭＢＳセッションに対応するＭＢＳトラフィックチャネルのスケジューリング情報とを含む。ＭＢＳトラフィックチャネルのスケジューリング情報は、ＭＢＳトラフィックチャネルの間欠受信（ＤＲＸ）設定を含んでもよい。間欠受信設定は、オン期間（Ｏｎ　Ｄｕｒａｔｉｏｎ：受信期間）を定義するタイマ値（Ｏｎ　Ｄｕｒａｔｉｏｎ　Ｔｉｍｅｒ）、オン期間を延長するタイマ値（Ｉｎａｃｔｉｖｉｔｙ　Ｔｉｍｅｒ）、スケジューリング間隔もしくはＤＲＸサイクル（Ｓｃｈｅｄｕｌｉｎｇ　Ｐｅｒｉｏｄ、ＤＲＸ　Ｃｙｃｌｅ）、スケジューリングもしくはＤＲＸサイクルの開始サブフレームのオフセット値（Ｓｔａｒｔ　Ｏｆｆｓｅｔ、ＤＲＸ　Ｃｙｃｌｅ　Ｏｆｆｅｓｔ）、オン期間タイマの開始遅延スロット値（Ｓｌｏｔ　Ｏｆｆｓｅｔ）、再送時までの最大時間を定義するタイマ値（Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ　Ｔｉｍｅｒ）、ＨＡＲＱ再送のＤＬ割り当てまでの最小間隔を定義するタイマ値（ＨＡＲＱ　ＲＴＴ　Ｔｉｍｅｒ）のいずれか一つ以上のパラメータを含んでもよい。
　なお、ＭＢＳトラフィックチャネルは論理チャネルの一種であって、ＭＴＣＨと呼ばれることがある。ＭＢＳトラフィックチャネルは、トランスポートチャネルの一種である下りリンク共有チャネル（ＤＬ－ＳＣＨ：Ｄｏｗｎ　Ｌｉｎｋ―Ｓｈａｒｅｄ　ＣＨａｎｎｅｌ）にマッピングされる。
　第２配信モード（Ｄｅｌｉｖｅｒｙ　ｍｏｄｅ　２：ＤＭ２）は、ＲＲＣコネクティッド状態のＵＥ１００だけではなく、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００が利用できる配信モードであって、低ＱｏＳ要件のための配信モードである。第２配信モードは、ＭＢＳセッションのうちブロードキャストセッションに用いられる。但し、第２配信モードは、マルチキャストセッションにも適用可能であってもよい。
　第２配信モードにおけるＭＢＳ受信の設定は、ブロードキャストシグナリングにより行われる。例えば、第２配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にブロードキャストで送信される論理チャネル、例えば、ブロードキャスト制御チャネル（ＢＣＣＨ）及び／又はマルチキャスト制御チャネル（ＭＣＣＨ）により行われる。ＵＥ１００は、例えば、技術仕様で予め規定された専用のＲＮＴＩを用いてＢＣＣＨ及びＭＣＣＨを受信できる。ＢＣＣＨ受信用のＲＮＴＩがＳＩ－ＲＮＴＩであって、ＭＣＣＨ受信用のＲＮＴＩがＭＣＣＨ－ＲＮＴＩであってもよい。
　第２配信モードにおいて、ＵＥ１００は、次の３つの手順でＭＢＳデータを受信してもよい。第１に、ＵＥ１００は、ｇＮＢ２００からＢＣＣＨ上で伝送されるＳＩＢ（ＭＢＳ　ＳＩＢ）によりＭＣＣＨ設定情報を受信する。第２に、ＵＥ１００は、ＭＣＣＨ設定情報に基づいてｇＮＢ２００からＭＣＣＨを受信する。ＭＣＣＨは、ＭＴＣＨ設定情報を伝送する。第３に、ＵＥ１００は、ＭＴＣＨ設定情報に基づいて、ＭＴＣＨ（ＭＢＳデータ）を受信する。以下において、ＭＴＣＨ設定情報及び／又はＭＣＣＨ設定情報をＭＢＳ受信設定と呼ぶことがある。
　第１配信モード及び第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００から割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いてＭＴＣＨを受信してもよい。Ｇ－ＲＮＴＩは、ＭＴＣＨ受信用ＲＮＴＩに相当する。Ｇ－ＲＮＴＩは、ＭＢＳ受信設定（ＭＴＣＨ設定情報）に含まれていてもよい。
　なお、ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｇｒｏｕｐ　Ｉｄｅｎｔｉｔｙ）、ソーススペシフィックＩＰマルチキャストアドレス（アプリケーション機能やアプリケーションサーバ等のソースユニキャストＩＰアドレスと、宛先アドレスを示すＩＰマルチキャストアドレスとから成る）、セッション識別子、及びＧ－ＲＮＴＩのうち少なくとも１つにより識別される。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、及びセッション識別子の少なくとも１つをＭＢＳセッション識別子と呼ぶ。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、セッション識別子、及びＧ－ＲＮＴＩを総括してＭＢＳセッション情報と呼ぶ。
　図８は、第１実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の一例を示す図である。図９は、第１実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の他の例を示す図である。
　１つのＭＢＳ無線ベアラ（ＭＲＢ）は、マルチキャストセッション又はブロードキャストセッションを伝送する１つの無線ベアラである。すなわち、ＭＲＢにマルチキャストセッションが対応付けられる場合と、ＭＲＢにブロードキャストセッションが対応付けられる場合とがある。
　ＭＲＢ及び対応する論理チャネル（例えば、ＭＴＣＨ）は、ＲＲＣシグナリングによってｇＮＢ２００からＵＥ１００に設定される。ＭＲＢの設定手順は、データ無線ベアラ（ＤＲＢ）の設定手順と分離されていてもよい。ＲＲＣシグナリングでは、１つのＭＲＢを、「ＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）」、「ＰＴＰのみ（ＰＴＰ　ｏｎｌｙ）」、又は「ＰＴＭ及びＰＴＰの両方（ｂｏｔｈ　ＰＴＭ　ａｎｄ　ＰＴＰ）」で設定できる。このようなＭＲＢのベアラタイプはＲＲＣシグナリングにより変更できる。
　図８において、ＭＲＢ＃１にはマルチキャストセッション及び専用トラフィックチャネル（ＤＴＣＨ）が対応付けられ、ＭＲＢ＃２にはマルチキャストセッション及びＭＴＣＨ＃１が対応付けられ、ＭＲＢ＃３にはブロードキャストセッション及びＭＴＣＨ＃２が対応付けられる一例を示している。すなわち、ＭＲＢ＃１はＰＴＰのみ（ＰＴＰ　ｏｎｌｙ）のＭＲＢであり、ＭＲＢ＃２はＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）のＭＲＢであり、ＭＲＢ＃３はＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）のＭＲＢである。なお、ＤＴＣＨは、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いてスケジューリングされる。ＭＴＣＨは、Ｇ－ＲＮＴＩを用いてスケジューリングされる。
　ＵＥ１００のＰＨＹレイヤは、物理チャネルの１つであるＰＤＳＣＨ上で受信したユーザデータ（受信データ）を処理し、トランスポートチャネルの１つである下りリンク共有チャネル（ＤＬ－ＳＣＨ）に流す。ＵＥ１００のＭＡＣレイヤ（ＭＡＣエンティティ）は、ＤＬ－ＳＣＨ上で受信したデータを処理し、受信データに含まれるヘッダ（ＭＡＣヘッダ）に含まれる論理チャネル識別子（ＬＣＩＤ）に基づいて、当該受信データを対応する論理チャネル（対応するＲＬＣエンティティ）に流す。
　図９において、マルチキャストセッションと対応付けられるＭＲＢに、ＤＴＣＨ及びＭＴＣＨが対応付けられる一例を示している。具体的には、１つのＭＲＢが２つのレグに分割（スプリット）され、一方のレグがＤＴＣＨと対応付けられ、他方のレグがＭＴＣＨと対応付けられている。当該２つのレグは、ＰＤＣＰレイヤ（ＰＤＣＰエンティティ）において結合される。すなわち、当該ＭＲＢは、ＰＴＭ及びＰＴＰの両方（ｂｏｔｈ　ＰＴＭ　ａｎｄ　ＰＴＰ）のＭＲＢである。このようなＭＲＢは、スプリットＭＲＢと呼ばれることがある。
　（ＰＤＣＰレイヤの動作の概要）
　図１０は、第１実施形態に係る移動通信システム１におけるＰＤＣＰレイヤの動作を示す図である。
　ｇＮＢ２００は、あるＭＢＳセッションのＭＢＳデータをＰＴＭ（マルチキャスト又はブロードキャスト）で複数のＵＥ１００（図１０の例では、ＵＥ１００ａ乃至ＵＥ１００ｃ）に送信する。各ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第１配信モード又は第２配信モードであってもよい。
　ｇＮＢ２００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられた送信側ＰＤＣＰエンティティ２０１（具体的には、当該ＭＢＳセッションに属するマルチキャスト無線ベアラ（ＭＲＢ）と対応付けられた送信側ＰＤＣＰエンティティ）を有する。送信側ＰＤＣＰエンティティ２０１は、ＭＢＳセッションの送信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰデータＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）の送信に応じて更新されるＰＤＣＰ状態変数を管理する。
　各ＵＥ１００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられた受信側ＰＤＣＰエンティティ１０１（具体的には、当該ＭＢＳセッションに属するＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ）を有する。各受信側ＰＤＣＰエンティティ１０１（図１０の例では、受信側ＰＤＣＰエンティティ１０１ａ乃至受信側ＰＤＣＰエンティティ１０１ｃ）は、ＭＢＳセッションの受信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰデータＰＤＵの受信に応じて更新されるＰＤＣＰ状態変数を管理する。
　なお、ｇＮＢ２００は、ＲＲＣシグナリングを各ＵＥ１００と送受信するＲＲＣエンティティ２０２を有する。各ＵＥ１００は、ＲＲＣシグナリングをｇＮＢ２００と送受信するＲＲＣエンティティ１０２（ＲＲＣエンティティ１０２ａ乃至ＲＲＣエンティティ１０２ｃ）を有する。ＵＥ１００のＲＲＣエンティティ１０２は、ｇＮＢ２００のＲＲＣエンティティ２０２から受信するＲＲＣシグナリングに基づいて、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１を制御する。
　図１１に示すように、ＰＤＣＰ状態変数は、ＰＤＣＰシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号（ＨＦＮ）と、ＰＤＣＰシーケンス番号（ＰＤＣＰ　ＳＮ）と、からなるカウント値（ＣＯＵＮＴ値）であってもよい。例えば、ＣＯＵＮＴ値は３２ビットのビット長を有し、ＰＤＣＰ　ＳＮは１２ビット又は１８ビットのビット長（ＳＮ＿ｌｅｎｇｔｈ）を有し、ＨＦＮはＣＯＵＮＴ値のビット長からＰＤＣＰ　ＳＮのビット長を減じたビット長を有する。ＰＤＣＰ　ＳＮのビット長は、ＲＲＣシグナリングにより設定されてもよい。ＰＤＣＰ　ＳＮビット長は、デフォルト値（予め決められた固定値）であってもよい。なお、用語「ＰＤＣＰ状態変数」は、ＣＯＵＮＴ値を指す場合に限らず、ＰＤＣＰレイヤで扱う各種の変数（ＨＦＮ又はＰＤＣＰ　ＳＮ、或いはＴＸ＿ＮＥＸＴ、ＲＸ＿ＮＥＸＴ、ＲＸ＿ＤＥＬＩＶ及びＲＸ＿ＲＥＯＲＤ等）を指す用語としても用いられる。
　図１２は、ＭＢＳデータを構成するＰＤＣＰデータＰＤＵの一例を示す図である。図１２に示すように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ　ＳＮと、データと、ＭＡＣ－Ｉとを有する。ＰＤＣＰ　ＳＮは、ＰＤＣＰデータＰＤＵに順次付与されるシーケンス番号である。データは、ＰＤＣＰ　ＳＤＵ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ｕｎｉｔ）に相当する。ＭＡＣ－Ｉは、メッセージ認証コードに相当する。ＰＤＣＰデータＰＤＵは、ＭＡＣ－Ｉを有していない場合がある。このように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ　ＳＮを有するものの、ＨＦＮを有していない。そのため、ｇＮＢ２００及びＵＥ１００のそれぞれは、ＰＤＣＰデータＰＤＵの送受信に応じてＨＦＮを更新、具体的には、ＰＤＣＰシーケンス番号が一周する度にカウントアップする必要がある。
　図１３は、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）において受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。ここで、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ　ＳＮをＲＣＶＤ＿ＳＮと呼ぶ。
　第１に、
　　ＲＣＶＤ＿ＳＮ＜ＳＮ（ＲＸ＿ＤＥＬＩＶ）－Ｗｉｎｄｏｗ＿Ｓｉｚｅ
　である場合、
　ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）＋１
　である。ここで、ＲＸ＿ＤＥＬＩＶは、受信待ちであって、未だ上位レイヤに提供していないＰＤＣＰ　ＳＤＵのうち最も古いものを表す変数である。ＲＸ＿ＤＥＬＩＶの初期値はゼロである。なお、ＰＴＭ受信においては、ＲＸ＿ＤＥＬＩＶの初期値は、最初に受信したパケットのＳＮを用いてセットされてもよい。Ｗｉｎｄｏｗ＿Ｓｉｚｅは、リオーダリングウィンドウのサイズを示す定数である。
　第２に、
　ＲＣＶＤ＿ＳＮ≧ＳＮ（ＲＸ＿ＤＥＬＩＶ）＋Ｗｉｎｄｏｗ＿Ｓｉｚｅ
　である場合、
　ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）－１
　である。
　第３に、上記のいずれの条件も満たされない場合、
　ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）
　である。
　そして、
　ＲＣＶＤ＿ＣＯＵＮＴ＝［ＲＣＶＤ＿ＨＦＮ，ＲＣＶＤ＿ＳＮ］
　にセットされる。
　（ＰＤＣＰステータス報告の概要）
　ここで、一般的なＰＤＣＰステータス報告について説明する。ＵＥ１００は、ＰＤＣＰレイヤにおけるデータ受信状況を示すＰＤＣＰステータス報告（Ｓｔａｔｕｓ　Ｒｅｐｏｒｔ）をｇＮＢ２００に送信する。ｇＮＢ２００は、ＵＥ１００からのＰＤＣＰステータス報告に基づいて、欠落したＰＤＣＰパケット（ＰＤＣＰ　ＳＤＵ）を特定し、特定したＰＤＣＰパケットをＵＥ１００に再送することができる。
　図１４は、ＰＤＣＰステータス報告に関するＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。なお、図１４は、ＰＤＣＰレイヤの３ＧＰＰ技術仕様書「ＴＳ３８．３２３」からの引用である。
　ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰステータス報告を送信するように上位レイヤ（ＲＲＣレイヤ）により設定された確認モード（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のデータ無線ベアラ（ＤＲＢ：Ｄａｔａ　Ｒａｄｉｏ　Ｂｅａｒｅｒ）について、次のいずれかの条件が満たされた場合、ＰＤＣＰステータス報告の送信をトリガする：
　・上位レイヤがＰＤＣＰエンティティの再確立を要求した（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｑｕｅｓｔｓ　ａ　ＰＤＣＰ　ｅｎｔｉｔｙ　ｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）；
　・上位レイヤがＰＤＣＰデータリカバリを要求した（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｑｕｅｓｔｓ　ａ　ＰＤＣＰ　ｄａｔａ　ｒｅｃｏｖｅｒｙ）；
　・上位レイヤが上りリンクデータ切り替えを要求した（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｑｕｅｓｔｓ　ａ　ｕｐｌｉｎｋ　ｄａｔａ　ｓｗｉｔｃｈｉｎｇ）；
　・上位レイヤがＤＡＰＳを解放するようにＰＤＣＰエンティティを再設定した（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｃｏｎｆｉｇｕｒｅｓ　ｔｈｅ　ＰＤＣＰ　ｅｎｔｉｔｙ　ｔｏ　ｒｅｌｅａｓｅ　ＤＡＰＳ）。
　図１５は、ＰＤＣＰステータス報告に関するＵＥ１００のＲＲＣエンティティ１０２の動作を示す図である。なお、図１５は、ＲＲＣレイヤの３ＧＰＰ技術仕様書「ＴＳ３８．３３１」からの引用である。
　ＵＥ１００のＲＲＣエンティティ１０２は、現在のＵＥ設定の一部であるｄｒｂ－ＴｏＡｄｄＭｏｄＬｉｓｔに含まれるＤＲＢ識別子（ｄｒｂ－Ｉｄｅｎｔｉｔｙ）ごとに、
　・ＰＤＣＰ再確立（ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ）がセットされている場合、そのＤＲＢのＰＤＣＰエンティティを再確立する；
　・ＰＤＣＰリカバリ（ｒｅｃｏｖｅｒＰＤＣＰ）がセットされている場合、そのＤＲＢのＰＤＣＰエンティティがデータリカバリを行うことをトリガする。
　このように、ＤＲＢについての既存の技術仕様の動作によれば、ＵＥ１００は、ｇＮＢ２００からのＲＲＣシグナリングによってＰＤＣＰ再確立又はＰＤＣＰリカバリを指示されたことに応じて、ＰＤＣＰステータス報告の送信をトリガする。なお、ＭＲＢについてＰＤＣＰステータス報告を適用するか否か、及び、ＭＲＢについてＰＤＣＰステータス報告を適用する場合にどのようにＰＤＣＰステータス報告をトリガするかは、既存の技術仕様では規定されていない。
　図１６は、ＰＤＣＰステータス報告の構成例を示す図である。なお、ＰＤＣＰステータス報告を構成するＰＤＣＰ制御ＰＤＵの先頭に、当該ＰＤＵが制御ＰＤＵであることを示すＤ／Ｃフィールドと、当該ＰＤＵがＰＤＣＰステータス報告であることを示すＰＤＵタイプフィールドとが設けられていてもよい。
　図１６に示す構成例１において、ＰＤＣＰステータス報告は、ＦＭＣ（Ｆｉｒｓｔ　ｍｉｓｓｉｎｇ　ＣＯＵＮＴ）及びビットマップの各フィールドを含む。ＦＭＣフィールドには、リオーダリングウィンドウ内で最初に欠落しているＰＤＣＰ　ＳＤＵのＣＯＵＮＴ値、すなわち、ＲＸ＿ＤＥＬＩＶがセットされる。ビットマップフィールドには、各ＰＤＣＰ　ＰＤＵと対応付けられたビットがセットされ、正しく受信した場合は“１”がセットされ、欠落した場合は“０”がセットされる。
　図１６に示す構成例２において、ＰＤＣＰステータス報告は、ＦＭＣ及びＬＭＣ（Ｌａｓｔ　ｍｉｓｓｉｎｇ　ＣＯＵＮＴ）の各フィールドを含む。ＬＭＣフィールドには、欠落パケット群のうち最後のパケットのシーケンス番号（ＣＯＵＮＴ値）がセットされる。ＬＭＣフィールドには、最初に受信成功したパケットのＣＯＵＮＴ値（ＬＭＣ＋１、例えばＦｉｒｓｔ　Ｓｕｃｃｅｓｓｆｕｌ　ＣＯＵＮＴ：　ＦＳＣ）がセットされてもよい。上述の構成例１はビットマップフィールドのビット長が長くなり得る（例えば、２００パケット分のビットマップは２００ビットになる）が、ビットマップフィールドに代えてＬＭＣフィールドを設けることにより、ＰＤＣＰステータス報告のビット長を短縮できる。
　（第１実施形態に係る動作）
　上述のように、ｇＮＢ２００のＲＲＣエンティティ２０２は、ＵＥ１００のＲＲＣエンティティ１０２に送信するＲＲＣシグナリング、具体的には、ＲＲＣ再設定（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージによりＭＲＢのベアラタイプを変更できる。ここで、ＵＥ１００がＲＲＣ再設定メッセージを受信してからＲＲＣ再設定処理が完了するまでに処理遅延が生じる。この遅延時間の間はＭＢＳデータの受信が不可になり、ＵＥ１００においてＭＢＳデータパケットの欠落、すなわち、パケットロスが生じるという問題がある。
　上述のように、ＰＤＣＰレイヤは、パケットロスを補償可能な仕組みとして、ＰＤＣＰステータス報告を有する。具体的には、ＵＥ１００は、ＰＤＣＰレイヤにおけるデータ受信状況を示すＰＤＣＰステータス報告をｇＮＢ２００に送信する。ｇＮＢ２００は、ＵＥ１００からのＰＤＣＰステータス報告に基づいて、欠落したＰＤＣＰパケットを特定し、特定したＰＤＣＰパケットをＵＥ１００に再送することができる。
　第１実施形態は、ＰＤＣＰステータス報告の送信をＵＥ１００が自発的にトリガすることにより、ＭＲＢのベアラタイプ変更に起因するパケットロスをＰＤＣＰステータス報告により補償可能とする実施形態である。具体的には、ＰＤＣＰステータス報告について、ＭＢＳ受信に関する新たな送信トリガ条件を導入する。
　図１７は、第１実施形態に係るＵＥ１００の動作を示す図である。
　ステップＳ１において、ＵＥ１００は、ＭＲＢを介してｇＮＢ２００からＭＢＳデータを受信する。上述のように、ＭＢＳのベアラタイプには、「ＰＴＭのみ（ＰＴＭ　ｏｎｌｙ）」、「ＰＴＰのみ（ＰＴＰ　ｏｎｌｙ）」、又は「ＰＴＭ及びＰＴＰの両方（ｂｏｔｈ　ＰＴＭ　ａｎｄ　ＰＴＰ）」（すなわち、スプリットＭＲＢ）の３つのタイプがある。
　ステップＳ２において、ＵＥ１００は、当該ＭＲＢのベアラタイプ変更を指示するＲＲＣ再設定（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージをｇＮＢ２００から受信する。ＲＲＣ再設定メッセージは、確立済みのＭＲＢのベアラタイプ変更を行う設定を含む。例えば、ＲＲＣ再設定メッセージは、当該ＭＲＢのベアラ識別子と、当該ＭＲＢの変更先のベアラタイプを示すベアラタイプ情報とを含んでもよい。
　ステップＳ３において、ＵＥ１００は、ステップＳ２で受信したＲＲＣ再設定メッセージにより指示されたベアラタイプ変更が所定のベアラタイプ変更であるか否かを判定する。
　当該ベアラタイプ変更が所定のベアラタイプ変更である場合（ステップＳ３：ＹＥＳ）、ステップＳ４において、ＵＥ１００は、当該ＭＲＢと対応付けられたＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）におけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガする。
　ステップＳ５において、ＵＥ１００は、ＰＤＣＰステータス報告をｇＮＢ２００に送信する。
　このように、ＵＥ１００は、所定のベアラタイプ変更をｇＮＢ２００から指示された場合、ＰＤＣＰステータス報告の送信を自発的にトリガする。これにより、ＭＲＢのベアラタイプ変更に起因するパケットロスをＰＤＣＰステータス報告により補償可能になる。
　ここで、「自発的にトリガする」とは、ＰＤＣＰステータス報告の送信をトリガすることをｇＮＢ２００から明示的に指示されなくても、ＵＥ１００がＰＤＣＰステータス報告の送信をトリガすることをいう。例えば、ＵＥ１００は、ｇＮＢ２００からのＲＲＣシグナリングによってＰＤＣＰ再確立又はＰＤＣＰリカバリを指示されなくても、所定のベアラタイプ変更に応じてＰＤＣＰステータス報告の送信をトリガする。
　ＰＤＣＰステータス報告の送信をトリガすることを目的としてＰＤＣＰ再確立又はＰＤＣＰリカバリを行うことは非効率になり得るが、第１実施形態によれば、ＰＤＣＰ再確立又はＰＤＣＰリカバリを伴わずにＰＤＣＰステータス報告の送信をトリガ可能である。また、ＰＤＣＰステータス報告の送信をトリガするベアラタイプ変更を、所定のベアラタイプ変更に限定することにより、例えばパケットロスが許容されるようなＭＢＳサービスについては、ＰＤＣＰステータス報告の送信をトリガしないことが可能である。
　このような動作は、確立済みのＭＲＢのベアラタイプ変更に適用され、新たなＭＲＢを確立する場合には適用されない。すなわち、ＵＥ１００は、新たなＭＲＢを確立する場合は、ＰＤＣＰステータス報告の自発的な送信トリガを行わない。
　（第１実施形態の実施例）
　上述の第１実施形態に係る動作を前提として、第１実施形態に係る第１実施例乃至第３実施例について説明する。
　（１）第１実施例
　本実施例において、所定のベアラタイプ変更は、ＰＴＰ（Ｐｏｉｎｔ－Ｔｏ－Ｐｏｉｎｔ）のみのＭＲＢタイプへの変更又はスプリットＭＲＢへの変更である。すなわち、ＵＥ１００は、ＰＴＰのみ又はスプリットＭＲＢに変更された時に（のみ）、ＰＤＣＰステータス報告の送信をトリガする。
　ここで、ＰＴＰのみ又はスプリットＭＲＢへのベアラタイプ変更は、次の４パターンがある：
　１）ＰＴＭのみ→ＰＴＰのみ；
　２）ＰＴＭのみ→スプリットＭＲＢ；
　３）ＰＴＰのみ→スプリットＭＲＢ；
　４）スプリットＭＲＢ→ＰＴＰのみ。
　ＰＴＭのみのＭＲＢは、上りリンクのパスが存在しないため、ＰＤＣＰステータス報告を送信しようとしても、送信することはできない。また、ＰＴＭのみのＭＲＢは、ＰＴＰのみのＭＲＢ及びスプリットＭＲＢに比べて、高信頼性が要求されないと考えられる。そのため、本実施例では、ＰＴＰのみ又はスプリットＭＲＢに変更された時に（のみ）、ＰＤＣＰステータス報告の送信をトリガすることとしている。
　図１８は、本実施例に係るＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。図１８において、図１４と異なる部分を下線で示している。但し、図１８における「ＤＲＢ」を「ＭＲＢ」と読み替えてもよい。
　ＵＥ１００は、当該ＭＲＢのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）にｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄが設定されており、且つ、ＰＴＰのみ又はスプリットＭＲＢへのベアラタイプ変更を行うよう上位レイヤが当該ＰＤＣＰエンティティを再設定した場合（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｃｏｎｆｉｇｕｒｅｓ　ｔｈｅ　ＰＤＣＰ　ｅｎｔｉｔｙ　ｔｏ　ｃｈａｎｇｅ　ｂｅａｒｅｒ　ｔｙｐｅ　ｔｏ　ＰＴＰ－ｏｎｌｙ　ＭＲＢ　ｏｒ　Ｓｐｌｉｔ　ＭＲＢ）、ＰＤＣＰステータス報告をトリガする。
　（２）第２実施例
　本実施例において、所定のベアラタイプ変更は、ＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢタイプへの変更である。すなわち、ＵＥ１００は、ＡＭ　ＭＲＢに変更された時に（のみ）、ＰＤＣＰステータス報告の送信をトリガする。
　ＰＴＭのみのＭＲＢは、ＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢとして扱われると考えられる。また、ＰＴＭ（特に、ＰＴＭのみ）はＰＴＰに比べて無線リソースの使用効率が良いことから、ｇＮＢ２００は、出来るだけＵＥ１００をＰＴＭ（－ｏｎｌｙ）にしたいという動機があると考えられる。
　この場合、ｇＮＢ２００は、例えば、無線状態が良い場合はＰＴＭ（－ｏｎｌｙ）（すなわち、ＵＭ　ＭＲＢ）とし、無線状態が悪くなってきたらＰＴＰのみ又はスプリットＭＲＢ（すなわち、ＡＭ　ＭＲＢ）という使い分けをベアラタイプ変更により行うと考えられる。なお、無線状況は、例えば既存の測定報告により判断できる。
　ここで、ある程度高い信頼性が要求されるサービスについて、ベアラタイプ変更時のパケットロス補償として、次のような方法がある：
　・ＡＭからＵＭへの変更；
　ＡＭ（ＰＴＰ）にて、ＵＭ（ＰＴＭ）のＳＮよりも先のパケットを予め伝送しておく；
　・ＵＭからＡＭへの変更；
　ＵＭ（ＰＴＭ）で欠損したパケットを、後からＡＭ（ＰＴＰ）で伝送する。ここで、ＰＤＣＰステータス報告が必要となる。
　よって、本実施例では、ＵＥ１００は、ＡＭ　ＭＲＢへ変更された場合に、ＰＤＣＰステータス報告の自発的な送信トリガを行う。ＡＭ　ＭＲＢへの変更（ＭＲＢ再設定）は、次の２パターンがある：
　１）ＵＭ　ＭＲＢ→ＡＭ　ＭＲＢ；
　２）ＡＭ　ＭＲＢ→ＡＭ　ＭＲＢ；　例えば、スプリットＭＲＢからＰＴＰのみのＭＲＢの場合など。
　図１９は、本実施例に係るＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。図１９において、図１４と異なる部分を下線で示している。但し、図１９における「ＤＲＢ」を「ＭＲＢ」と読み替えてもよい。
　ＵＥ１００は、当該ＭＲＢのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）にｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄが設定されており、且つ、ＡＭ　ＭＲＢへのベアラタイプ変更を行うよう上位レイヤが当該ＰＤＣＰエンティティを再設定した場合（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｃｏｎｆｉｇｕｒｅｓ　ｔｈｅ　ＰＤＣＰ　ｅｎｔｉｔｙ　ｔｏ　ｃｈａｎｇｅ　ｂｅａｒｅｒ　ｔｙｐｅ　ｔｏ　ＡＭ　ＭＲＢ）、ＰＤＣＰステータス報告をトリガする。
　（３）第３実施例
　本実施例において、所定のベアラタイプ変更は、ＰＴＭのみのＭＲＢタイプから他のＭＲＢタイプへの変更である。すなわち、ＵＥ１００は、ＰＴＭのみからＰＴＭのみ以外に変更された時に（のみ）、ＰＤＣＰステータス報告をトリガする。
　スプリットＭＲＢは、ＰＴＰレグを使ってパケットロス補償が可能であるが、ＰＴＭのみのＭＲＢについてパケットロス補償を行う場合、必ずベアラタイプ変更が必要になる。そのため、ＰＴＭのみからＰＴＭのみ以外に変更された時に（のみ）、ＰＤＣＰステータス報告をトリガすることとしている。
　図２０は、本実施例に係るＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。図２０において、図１４と異なる部分を下線で示している。但し、図２０における「ＤＲＢ」を「ＭＲＢ」と読み替えてもよい。
　ＵＥ１００は、当該ＭＲＢのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）にｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄが設定されており、且つ、ＰＴＰのみから他のタイプへのベアラタイプ変更を行うよう上位レイヤが当該ＰＤＣＰエンティティを再設定した場合（ｕｐｐｅｒ　ｌａｙｅｒ　ｒｅｃｏｎｆｉｇｕｒｅｓ　ｔｈｅ　ＰＤＣＰ　ｅｎｔｉｔｙ　ｔｏ　ｃｈａｎｇｅ　ｂｅａｒｅｒ　ｔｙｐｅ　ｆｒｏｍ　ＰＴＰ－ｏｎｌｙ　ｔｏ　ｏｔｈｅｒ　ｔｙｐｅ）、ＰＤＣＰステータス報告をトリガする。
　［第２実施形態］
　第２実施形態について、上述の第１実施形態との相違点を主として説明する。
　第２実施形態において、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態でＭＢＳ受信（ＰＴＭ受信）を行うＵＥ１００がランダムアクセスプロシージャによりＲＲＣコネクティッド状態に遷移するシナリオを主として想定する。このようなシナリオにおいて、ランダムアクセスプロシージャの実行中は、ＵＥ１００がＭＢＳ受信を行うことができず、ＭＢＳデータのパケットロスが発生し得る。第２実施形態では、そのようなパケットロスを補償可能とする実施形態である。
　例えば、ＵＥ１００は、ＲＲＣコネクティッド状態に遷移した時に、ＰＤＣＰステータス報告の送信を自発的にトリガする。ＵＥ１００のＲＲＣエンティティ１０２はＲＲＣコネクティッド状態に遷移した旨を受信側ＰＤＣＰエンティティ１０１に通知し、受信側ＰＤＣＰエンティティ１０１は、当該通知に応じてＰＤＣＰステータス報告の送信を自発的にトリガしてもよい。但し、ランダムアクセスプロシージャを実行してもパケットロスが発生しない場合もある。そのため、ＵＥ１００は、ＲＬＣでパケット破棄が発生した場合に、ＰＤＣＰステータス報告を自発的にトリガしてもよい。具体的には、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＲＬＣレイヤからパケット破棄を通知された場合に、ＰＤＣＰステータス報告を自発的にトリガしてもよい。
　図２１は、第２実施形態に係るＵＥ１００の動作を示す図である。
　ステップＳ１１において、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態にあるＵＥ１００は、ＭＲＢを介してｇＮＢ２００からＭＢＳデータを受信する。
　ステップＳ１２において、ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移したこと、及びＲＬＣレイヤにおいてＭＢＳデータパケットの破棄が発生したことの少なくとも一方の条件が満たされたか否かを判定する。
　当該少なくとも一方の条件が満たされた場合（ステップＳ１２：ＹＥＳ）、ステップＳ１３において、ＵＥ１００は、当該ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガする。
　ステップＳ１４において、ＵＥ１００は、ＰＤＣＰステータス報告をｇＮＢ２００に送信する。
　［第３実施形態］
　第３実施形態について、上述の第１実施形態及び第２実施形態との相違点を主として説明する。
　第３実施形態は、ｇＮＢ２００がＭＲＢについてベアラタイプ変更をＵＥ１００に指示する点は第１実施形態及び第２実施形態と同じであるが、当該指示の際に、ｇＮＢ２００がＰＤＣＰステータス報告をＵＥ１００にトリガさせる。具体的には、ｇＮＢ２００は、ＭＲＢのベアラタイプ変更を指示するＲＲＣメッセージ（ＲＲＣ再設定メッセージ）に、当該ＭＲＢと対応付けられたＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）の再確立を指示する第１情報要素（ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ）を含める。
　但し、このようなＲＲＣ再確立を指示する場合、当該ＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）におけるヘッダ圧縮プロトコル、具体的には、ＲｏＨＣ（Ｒｏｂｕｓｔ　Ｈｅａｄｅｒ　Ｃｏｍｐｒｅｓｓｉｏｎ）の動作がリセットされ、ＲｏＨＣコンテキストもリセットされてしまう。ＲｏＨＣコンテキストは、ヘッダにおける固定の値、及びヘッダにおける値を予測するための情報を含み、圧縮されたヘッダをＵＥ１００が復元するために必要な情報である。ＲｏＨＣコンテキストもリセットされると、ベアラタイプ変更後において、圧縮されていない完全なヘッダを送受信する必要があり、オーバーヘッドが大きくなるという問題がある。
　よって、第３実施形態では、ｇＮＢ２００は、ＭＲＢのベアラタイプ変更を指示するＲＲＣ再設定メッセージに第１情報要素（ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ）を含める場合、ＵＥ１００のＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）のヘッダ圧縮プロトコルの状態（例えば、ＲｏＨＣコンテキスト）を維持することを指示する第２情報要素（ｄｒｂ－ＣｏｎｔｉｎｕｅＲＯＨＣ）を当該ＲＲＣ再設定メッセージに含める。これにより、ＵＥ１００のＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）のヘッダ圧縮プロトコルの状態（例えば、ＲｏＨＣコンテキスト）が維持されるため、ベアラタイプ変更後においても圧縮されたヘッダを送受信することが可能である。
　図２２は、第３実施形態に係る移動通信システム１の動作を示す図である。
　ステップＳ１０１において、ＵＥ１００は、ｇＮＢ２００からＭＲＢを介してＭＢＳデータを受信する。
　ステップＳ１０２において、ｇＮＢ２００は、当該ＭＲＢについてベアラタイプ変更を決定する。具体的には、ｇＮＢ２００は、ＰＴＰのみ、ＰＴＭのみ、及びスプリットＭＲＢ（ＰＴＰレグ及びＰＴＭレグ）の３つのタイプ間での変更を決定する。例えば、ｇＮＢ２００は、ＵＥ１００からの無線品質の報告（ｍｅａｓｕｒｅｍｅｎｔ　ｒｅｐｏｒｔ）及び／又はｇＮＢ２００の無線リソース状況などに応じてステップＳ１０２の決定を行う。
　ステップＳ１０３において、ｇＮＢ２００は、ベアラタイプ変更用のＲＲＣ再設定メッセージをＵＥ１００に送信する。ＲＲＣ再設定メッセージは、確立済みのＭＲＢのベアラタイプ変更を行う設定を含む。例えば、ＲＲＣ再設定メッセージは、当該ＭＲＢのベアラ識別子と、当該ＭＲＢの変更先のベアラタイプを示すベアラタイプ情報とを含んでもよい。ここで、ｇＮＢ２００は、当該ＭＲＢ識別子と対応付けて「ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ“ｔｒｕｅ”」及び「ｄｒｂ－ＣｏｎｔｉｎｕｅＲＯＨＣ“ｔｒｕｅ”」をＲＲＣ再設定メッセージにセットする。
　ステップＳ１０４において、ＲＲＣ再設定メッセージを受信したＵＥ１００は、ＲＲＣ再設定メッセージに含まれる「ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ“ｔｒｕｅ”」に応じてＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）を再確立し、当該再確立に応じてＰＤＣＰステータス報告の送信をトリガする（図１４のＰＤＣＰ動作を参照）。ここで、ＵＥ１００は、ＲＲＣ再設定メッセージに含まれる「ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ“ｔｒｕｅ”」に応じて、ＲｏＨＣ処理を継続する（具体的には、直前まで使っていたＲｏＨＣコンテキストを使用継続し、ＲｏＨＣ状態も維持する）。
　ステップＳ１０５において、ＵＥ１００は、ＰＤＣＰステータス報告をｇＮＢ２００に送信する。ｇＮＢ２００は、ＰＤＣＰステータス報告を受信する。
　［その他の実施形態］
　上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよいし、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。
　上述の実施形態及び実施例において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）又は６Ｇ基地局であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵであってもよい。また、ユーザ装置は、ＩＡＢノードのＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）であってもよい。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ）として構成してもよい。
　以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　本願は、米国仮出願第６３／２５５５７９号（２０２１年１０月１４日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
　（付記）
　１．導入
　ＲＡＮ２＃１１５ｅでは、ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）の作業項目が、マルチキャストサービスの継続性について次の合意を達成した。
　ＲＲＣシグナリングでは、１つのＭＲＢを、ＰＴＭのみ、ＰＴＰのみ、又はＰＴＭとＰＴＰとの両方で設定できる。ＰＴＭ、ＰＴＭ＋ＰＴＰ、又はＰＴＰのみ、のいずれかをＲＲＣシグナリングで変更できる。
　ＲＲＣ信号において、ＰＴＭ用のＵＭ　ＲＬＣ設定のみの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 (4)

  1. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
    　マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信することと、
    　前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信することと、
    　前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガすることと、
    　前記ＰＤＣＰステータス報告を前記基地局に送信することと、を有する
    　通信方法。
  2. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、
    　マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信することと、
    　ＲＲＣアイドル状態又はＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移したこと、及び／又は、ＲＬＣレイヤにおいてＭＢＳデータパケットの破棄が発生したことに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガすることと、
    　前記ＰＤＣＰステータス報告を前記基地局に送信することと、を有する
    　通信方法。
  3. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて基地局が実行する通信方法であって、
    　マルチキャスト無線ベアラ（ＭＲＢ）を介してＭＢＳデータをユーザ装置に送信することと、
    　前記ＭＲＢのベアラタイプ変更を指示するメッセージであって、前記ＭＲＢと対応付けられたＰＤＣＰエンティティの再確立を指示する第１情報要素を含むＲＲＣ再設定メッセージを前記ユーザ装置に送信することと、
    　前記第１情報要素に基づいて前記ユーザ装置から送信されるＰＤＣＰステータス報告を受信することと、を有し、
    　前記ＲＲＣ再設定メッセージを送信することは、前記第１情報要素を前記ＲＲＣ再設定メッセージに含める場合、前記ＰＤＣＰエンティティのヘッダ圧縮プロトコルの状態を維持することを指示する第２情報要素をさらに含む前記ＲＲＣ再設定メッセージを送信することを含む
    　通信方法。
  4. 　マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いるユーザ装置であって、
    　マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信し、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信する受信部と、
    　前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガする制御部と、
    　前記ＰＤＣＰステータス報告を前記基地局に送信する送信部と、を備える
    　ユーザ装置。
PCT/JP2022/038110 2021-10-14 2022-10-12 通信方法 WO2023063371A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163255579P 2021-10-14 2021-10-14
US63/255,579 2021-10-14

Publications (1)

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

Family

ID=85988649

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/038110 WO2023063371A1 (ja) 2021-10-14 2022-10-12 通信方法

Country Status (1)

Country Link
WO (1) WO2023063371A1 (ja)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
QUALCOMM INC: "NR Multicast Broadcast mobility enhancements with service", 3GPP DRAFT; R2-2009035, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. E-Meeting; 20201102 - 20201113, 23 October 2020 (2020-10-23), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051942080 *
SAMSUNG: "Service Continuity for Multicast", 3GPP DRAFT; R2-2107932, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. e-Meeting; 20210809 - 20210827, 6 August 2021 (2021-08-06), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP052034533 *
VIVO: "Discussion on PTP PTM Switch", 3GPP DRAFT; R2-2107795, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. E-Meeting; 20210816 - 20210827, 6 August 2021 (2021-08-06), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP052034407 *

Similar Documents

Publication Publication Date Title
ES2906704T3 (es) Procedimiento y aparato para el procesamiento de un paquete en un sistema de comunicación inalámbrica
WO2016013590A1 (ja) ユーザ端末及び移動通信システム
WO2021143868A1 (en) Methods and apparatus of lossless handover for nr multicast services
WO2022085717A1 (ja) 通信制御方法
US20240080939A1 (en) Communication control method and user equipment
TWI807527B (zh) 降低多分支傳輸中封包延遲的方法和裝置
US20230134356A1 (en) Methods and apparatus to set initial pdcp state variables for multicast
WO2023140144A1 (ja) 通信方法及びユーザ装置
JP2023100957A (ja) 通信制御方法、ユーザ装置及びプロセッサ
WO2022138450A1 (ja) 通信制御方法及びユーザ装置
WO2022141196A1 (en) Methods and apparatus to deliver reliable multicast services via pdcp retransmission
WO2023063371A1 (ja) 通信方法
WO2022082340A1 (en) Methods and apparatus to deliver reliable multicast services via mrb
WO2022000180A1 (en) Methods and apparatus of reliable multicast transmission with uplink feedback
WO2023063323A1 (ja) 通信方法、ユーザ装置、及び基地局
WO2023013671A1 (ja) 通信方法
CN114982202A (zh) Nr多播服务的多播和单播之间的动态切换
WO2023013670A1 (ja) 通信方法及びユーザ装置
WO2023013669A1 (ja) 通信方法、ユーザ装置、及び基地局
WO2023074721A1 (ja) 通信方法及びユーザ装置
US20240179800A1 (en) Communication method and user equipment
WO2022085573A1 (ja) 通信制御方法
WO2024034567A1 (ja) 通信方法
WO2022210914A1 (ja) 通信制御方法及びユーザ装置
US20240179580A1 (en) Communication method

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023554593

Country of ref document: JP

Kind code of ref document: A