WO2022210914A1 - 通信制御方法及びユーザ装置 - Google Patents

通信制御方法及びユーザ装置 Download PDF

Info

Publication number
WO2022210914A1
WO2022210914A1 PCT/JP2022/016093 JP2022016093W WO2022210914A1 WO 2022210914 A1 WO2022210914 A1 WO 2022210914A1 JP 2022016093 W JP2022016093 W JP 2022016093W WO 2022210914 A1 WO2022210914 A1 WO 2022210914A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdcp
mbs
base station
cell
gnb
Prior art date
Application number
PCT/JP2022/016093
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Priority to JP2023511494A priority Critical patent/JPWO2022210914A1/ja
Publication of WO2022210914A1 publication Critical patent/WO2022210914A1/ja
Priority to US18/478,762 priority patent/US20240040662A1/en

Links

Images

Classifications

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

Definitions

  • the present disclosure relates to a communication control method and user equipment used in a mobile communication system.
  • NR New Radio
  • RAT Radio Access Technology
  • LTE Long Term Evolution
  • a communication control method is a method executed by a user device in a mobile communication system in which a base station provides a user device with a multicast/broadcast service (MBS).
  • a communication control method is to receive from the base station a PDCP packet encrypted using a count value consisting of a PDCP sequence number and a hyperframe number and transmitted in an MBS session, and to estimate the hyperframe number. generating a guessed hyperframe number; attempting to decode the PDCP packet using a guessed count value comprising the PDCP sequence number and the guessed hyperframe number included in the received PDCP packet; if successful, determining the guessed hyperframe number as a valid hyperframe number.
  • a communication control method is a method executed by a user device in a mobile communication system in which a base station provides a user device with a multicast/broadcast service (MBS).
  • the communication control method includes updating a PDCP variable associated with the MBS session by the PDCP entity of the user equipment in response to reception of a PDCP packet transmitted in the MBS session, or when the MBS session is resumed after the MBS session has been suspended, or when an instruction to initialize the PDCP variables is received from the base station, the updated PDCP variables are initialized.
  • a communication control method is a method executed by the user equipment in a mobile communication system in which a base station provides a multicast/broadcast service (MBS) to the user equipment.
  • the communication control method includes updating a PDCP variable associated with the MBS session by the PDCP entity of the user equipment in response to reception of a PDCP packet transmitted in the MBS session, and reestablishing the PDCP entity. In this case, holding without initializing the PDCP variables associated with the MBS session, and the PDCP entity, based on the held PDCP variables, of PDCP packets transmitted in the MBS session. and continuing the receiving process.
  • a communication control method is a method executed by the user equipment in a mobile communication system in which a base station provides a multicast/broadcast service (MBS) to the user equipment.
  • a communication control method includes updating a PDCP variable associated with the MBS session by a PDCP entity of the user device in response to reception of a PDCP packet transmitted in the MBS session; Before performing handover from the first cell to the second cell, RRC re-establishment, or cell reselection, it is determined whether the updated PDCP variable can continue to be used in the second cell and receiving notification information from the base station to indicate.
  • a communication control method is a method executed by the user equipment in a mobile communication system in which a base station provides a multicast/broadcast service (MBS) to the user equipment.
  • the communication control method includes: the RLC entity of the user equipment receiving from the base station RLC PDUs transmitted in an MBS session and the base station dividing the RLC SDUs; determining whether to reconstruct the RLC SDU from the first received RLC PDU and RLC PDUs subsequent to the first received RLC PDU, based on an RLC sequence number included in the received RLC PDU; , have
  • a user device comprises a processor that executes the communication control method according to any one of the first to fifth aspects.
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to one embodiment; FIG. It is a figure which shows the structure of UE (user apparatus) which concerns on one Embodiment.
  • FIG. 2 is a diagram showing the configuration of a gNB (base station) according to one 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. 2 is a diagram showing a correspondence relationship between a downlink logical channel and a transport channel according to an embodiment; FIG. 3 illustrates a method of distributing MBS data according to one embodiment; FIG.
  • FIG. 4 illustrates a split MBS bearer according to one embodiment
  • Figure 4 illustrates an example operation for activating and deactivating legs according to one embodiment.
  • FIG. 3 is a diagram showing an operation example 1 of PDCP according to one embodiment
  • FIG. 10 is a diagram showing an operation example 2 of PDCP according to one embodiment
  • FIG. 11 is a diagram showing an operation example 3 of PDCP according to one embodiment
  • FIG. 11 is a diagram illustrating an operation example 4 of PDCP according to one embodiment
  • FIG. 11 is a diagram illustrating an operation example 4 of PDCP according to one embodiment
  • FIG. 11 is a diagram for explaining an operation example 6 of PDCP according to one embodiment
  • FIG. 4 is a diagram for explaining an operation example of RLC according to one embodiment
  • FIG. 4 is a diagram for explaining an operation example of RLC according to one embodiment
  • FIG. 4 is a diagram for explaining a case of reusing an existing PDCP functional view;
  • NR 5G system
  • an object of the present disclosure is to provide a communication control method and user equipment that realize improved multicast/broadcast services.
  • FIG. 1 is a diagram showing the configuration of a mobile communication system according to one embodiment.
  • This mobile communication system conforms to the 5th generation system (5GS: 5th Generation System) of the 3GPP standard.
  • 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.
  • a sixth generation (6G) system may be at least partially applied to the mobile communication system.
  • the mobile communication system includes a user equipment (UE: User Equipment) 100, a 5G radio access network (NG-RAN: Next Generation Radio Access Network) 10, a 5G core network (5GC: 5G Core Network) 20.
  • UE User Equipment
  • NG-RAN Next Generation Radio Access Network
  • 5G core network 5G 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 the user. (including chipsets), sensors or devices installed in sensors, vehicles or devices installed in vehicles (Vehicle UE), and/or aircraft or devices installed in aircraft (Aerial UE).
  • 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.
  • 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 one embodiment.
  • the UE 100 includes a receiver 110, a transmitter 120, and a controller .
  • 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 in the UE 100.
  • 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 one embodiment.
  • the gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240.
  • 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 in the gNB200.
  • 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 an adjacent base station via an interface between base stations.
  • Backhaul communication unit 240 is connected to AMF/UPF 300 via a base station-core network interface.
  • the gNB may be composed of a CU (Central Unit) and a DU (Distributed Unit) (that is, functionally divided), and the two units may be connected via an F1 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 radio interface protocol of the user plane includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, SDAP (Service Data Adaptation Protocol) 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 MAC layer performs data priority control, hybrid ARQ (HARQ) retransmission processing, random access procedures, and so on. 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)) and resource blocks to be allocated to the 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 and encryption/decryption.
  • 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 signaling for various settings is transmitted between the RRC layer of the UE 100 and the RRC layer of the gNB 200.
  • the RRC layer controls logical, transport and physical channels according to establishment, re-establishment and release of radio bearers.
  • RRC connection connection between the RRC of UE 100 and the RRC of gNB 200
  • UE 100 is in the RRC connected state.
  • RRC connection no connection between RRC of UE 100 and RRC of gNB 200
  • UE 100 is in RRC idle state.
  • UE 100 is in RRC inactive state.
  • the NAS layer located above the RRC layer performs session management and mobility management.
  • NAS signaling is transmitted between the NAS layer of UE 100 and the NAS layer of AMF 300B.
  • the UE 100 has an application layer and the like in addition to the radio interface protocol.
  • 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 may be called MBMS (Multimedia Broadcast and Multicast Service).
  • Use cases (service types) of MBS include public safety communication, mission critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communication, and software distribution. .
  • FIG. 6 is a diagram showing a correspondence relationship between downlink logical channels and transport channels according to an embodiment.
  • the logical channels used for MBSFN transmission are MTCH (Multicast Traffic Channel) and MCCH (Multicast Control Channel), and the transport channel used for MBSFN transmission is MCH (Multicast Control Channel).
  • MBSFN transmission is mainly designed for multi-cell transmission, and in an MBSFN area consisting of multiple cells, each cell performs synchronous transmission of the same signal (same data) in the same MBSFN subframe.
  • SC-PTM transmission The logical channels used for SC-PTM transmission are SC-MTCH (Single Cell Multicast Traffic Channel) and SC-MCCH (Single Cell Multicast Control Channel), and the transport channel used for SC-PTM transmission is DL-SCH (Downlink Shared Channel). ).
  • SC-PTM transmission is primarily designed for single-cell transmission, with broadcast or multicast data transmission on a cell-by-cell basis.
  • Physical channels used for SC-PTM transmission are PDCCH (Physical Downlink Control Channel) and PDSCH (Physical Downlink Control Channel), enabling dynamic resource allocation.
  • MBS may be provided using a scheme similar to the SC-PTM transmission scheme.
  • MBS may be provided using the MBSFN transmission scheme.
  • MBS may be read as multicast.
  • MBS may be provided by broadcast.
  • MBS data refers to data provided by MBS
  • MBS control channel refers to MCCH or SC-MCCH
  • MBS traffic channel refers to MTCH or SC-MTCH.
  • MBS data may also be transmitted by unicast.
  • MBS data may also be referred to as MBS packets or MBS traffic.
  • the network can provide different MBS services for each MBS session.
  • An MBS session is identified by at least one of a TMGI (Temporary Mobile Group Identity) and a session identifier, and at least one of these identifiers is called an MBS session identifier.
  • TMGI Temporal Mobile Group Identity
  • MBS session identifiers may be referred to as MBS service identifiers or multicast group identifiers.
  • FIG. 7 is a diagram showing a method of distributing MBS data according to one embodiment.
  • MBS data (MBS Traffic) is distributed to multiple UEs from a single data source (application service provider).
  • 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.
  • NG-RAN10 In shared MBS data delivery, a connection is established between NG-RAN10 and 5GC20, which are 5G radio access networks (5G RAN), and MBS data is delivered from 5GC20 to NG-RAN10.
  • 5G RAN 5G radio access networks
  • MBS connection In the following, such a connection (tunnel) will be referred to as an "MBS connection”.
  • An MBS connection may also be called a Shared MBS Traffic delivery connection or a shared transport.
  • the MBS connection terminates at the NG-RAN 10 (ie gNB 200).
  • An MBS connection may have a one-to-one correspondence with an MBS session.
  • gNB 200 selects either PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) transmission method at its own discretion, and transmits MBS data to UE 100 in the selected transmission method. to send.
  • PTP Point-to-Point: unicast
  • PTM Point-to-Multipoint: multicast or broadcast
  • a unicast session is established between NG-RAN 10 and UE 100, and MBS data is delivered individually from 5GC 20 to UE 100.
  • MBS data is delivered individually from 5GC 20 to UE 100.
  • Such a unicast may be called a PDU Session.
  • Unicast (PDU session) terminates at the UE 100 .
  • split MBS bearer Next, a split MBS bearer according to one embodiment will be described.
  • the gNB 200 can configure the UE 100 with an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter referred to as a "split MBS bearer" as appropriate). This allows the gNB 200 to dynamically switch transmission of MBS data to the UE 100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB 200 can double transmit the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path) to increase reliability.
  • the predetermined layer that terminates the split is the MAC layer (HARQ), RLC layer, PDCP layer, or SDAP layer.
  • HARQ MAC layer
  • RLC layer PDCP layer
  • SDAP layer SDAP layer.
  • FIG. 8 is a diagram illustrating a split MBS bearer according to one embodiment.
  • a PTP communication path is called a PTP leg and a PTM communication path is called a PTM leg.
  • a functional unit corresponding to each layer is called an entity.
  • each of the PDCP entity of gNB 200 and the PDCP entity of UE 100 separates MBS bearers (data radio bearers) used for MBS into PTP legs and PTM legs.
  • MBS bearers data radio bearers
  • a PDCP entity is provided for each bearer.
  • Each of gNB 200 and UE 100 has two RLC entities, one MAC entity, and one PHY entity provided for each leg.
  • a PHY entity may be provided for each leg.
  • the UE 100 may have two MAC entities.
  • the PHY entity uses a cell RNTI (C-RNTI: Cell Radio Network Temporary Identifier) assigned to UE 100 on a one-to-one basis to transmit and receive PTP leg data.
  • C-RNTI Cell Radio Network Temporary Identifier
  • the PHY entity transmits and receives data of the PTM leg using a group RNTI (G-RNTI: Group Radio Network Temporary Identifier) assigned one-to-one with the MBS session.
  • the C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UEs 100 that receive one MBS session.
  • a split MBS bearer is set from the gNB 200 to the UE 100, and the PTM leg is activated. must have been In other words, even if a split MBS bearer is configured in the UE 100, the gNB 200 cannot perform PTM transmission of MBS data using this PTM leg when the PTM leg is in a deactivation state.
  • a split MBS bearer in order for the gNB 200 and the UE 100 to perform PTP transmission (unicast) of MBS data using the PTP leg, a split MBS bearer must be set from the gNB 200 to the UE 100 and the PTP leg must be activated. There is In other words, even if a split MBS bearer is configured in the UE 100, the gNB 200 cannot perform PTP transmission of MBS data using this PTP leg when the PTP leg is in an inactive state.
  • UE 100 monitors the PDCCH (Physical Downlink Control Channel) to which the G-RNTI associated with the MBS session is applied in a state where the PTM leg is activated (that is, performs blind deactivation of the PDCCH using the G-RNTI). coding). UE 100 may monitor the PDCCH only at scheduling opportunities for the MBS session.
  • PDCCH Physical Downlink Control Channel
  • the UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied while the PTM leg is deactivated (that is, does not perform blind decoding of the PDCCH using the G-RNTI). .
  • the UE 100 monitors the PDCCH to which the C-RNTI is applied while the PTP leg is activated.
  • DRX Discontinuous Reception
  • UE 100 monitors PDCCH during the set On Duration.
  • UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.
  • the UE 100 may monitor the PDCCH to which the C-RNTI is applied in preparation for normal unicast downlink transmission other than MBS data while the PTP leg is deactivated. However, when a cell (frequency) associated with an MBS session is designated, UE 100 may not monitor the PDCCH for the MBS session.
  • a split MBS bearer as described above is set by an RRC message (for example, an RRC Reconfiguration message) transmitted from the RRC entity of gNB200 to the RRC entity of UE100.
  • RRC message for example, an RRC Reconfiguration message
  • FIG. 9 is a diagram illustrating example operations for leg activation and deactivation in accordance with one embodiment.
  • the RRC entity of gNB 200 transmits an RRC message including the split MBS bearer (split bearer) configuration shown in FIG. 8 to UE 100.
  • the RRC message is, for example, an RRC Reconfiguration message.
  • the RRC entity of UE 100 establishes split MBS bearers based on the configuration included in the RRC message received from gNB 200 .
  • An example in which the UE 100 establishes one split MBS bearer will be mainly described below, but the UE 100 may establish multiple split MBS bearers according to the settings from the gNB 200 .
  • the gNB 200 may instruct the UE 100 on the initial state of each leg (that is, activation or deactivation of each leg) in the same message.
  • the RRC entity of the gNB 200 sends the RRC message including the bearer setup of the split MBS bearer to the UE 100, it includes the activation or deactivation indication of each leg in the RRC message along with the bearer setup.
  • Such an RRC message may include at least one of the identifier of the leg to be instructed (PTP leg, PTM leg) and the identifier indicating either activation or deactivation.
  • the RRC message may include an identifier (eg, TMGI, G-RNTI, session identifier, QoS flow identifier, bearer identifier) associated with the indicated MBS session (split MBS bearer).
  • the gNB 200 transmits to the UE 100 an instruction to individually activate or deactivate the PTP leg and the PTM leg.
  • the MAC entity of gNB200 may transmit a MAC control element (MAC CE) including the instruction to UE100.
  • the MAC entity of UE100 receives MAC CE from gNB200.
  • the PHY entity of gNB200 may transmit downlink control information (DCI) including the instruction to UE100.
  • DCI downlink control information
  • the PHY entity of UE100 receives DCI from gNB200.
  • Such a MAC CE or DCI may include at least one of the identifier of the leg to be indicated (PTP leg, PTM leg) and the identifier indicating either activation or deactivation.
  • MAC CE or DCI may include an identifier (eg, TMGI, G-RNTI, session identifier, QoS flow identifier, bearer identifier) associated with the MBS session (split MBS bearer) to be indicated.
  • the UE 100 starts data reception processing using the C-RNTI in response to receiving the instruction to activate the PTP leg. Upon receiving the instruction to activate the PTM leg, the UE 100 starts receiving MBS data using the G-RNTI. On the other hand, the UE 100 ends the data reception process using the C-RNTI in response to receiving the instruction to deactivate the PTP leg. Upon receiving the instruction to deactivate the PTM leg, the UE 100 terminates the MBS data reception process using the G-RNTI.
  • the gNB 200 may transmit (PTM transmission) an instruction to activate or deactivate the PTP leg to the UE 100 via the activated PTM leg.
  • PTM transmission an instruction to activate or deactivate the PTP leg to the UE 100 via the activated PTM leg.
  • the gNB 200 may transmit (PTM transmission) an instruction to deactivate the PTM leg to the UE 100 via the activated PTM leg.
  • PTM transmission an instruction to deactivate the PTM leg to the UE 100 via the activated PTM leg.
  • the gNB 200 may transmit (PTP transmission) an instruction to activate or deactivate the PTM leg to the UE 100 via the activated PTP leg. This allows PTM legs to be activated or deactivated individually for each UE 100 .
  • the gNB 200 may transmit (PTP transmission) an instruction to deactivate the PTP leg to the UE 100 via the activated PTP leg. This allows the PTP leg to be individually deactivated for each UE 100 .
  • the UE 100 may transmit a response to the received instruction to the gNB 200 in response to receiving the instruction to activate at least one of the PTP leg and the PTM leg from the gNB 200 in step S12.
  • This response may be sent from the MAC entity of UE 100 to gNB 200 via the PTP leg, for example.
  • the UE 100 may start data reception operation on the activated leg.
  • the gNB 200 transmits data via the activated leg in response to receiving the response from the UE 100. That is, after receiving the response, the gNB 200 starts data transmission operation in the leg.
  • the UE 100 may transmit a response to the received instruction to the gNB 200 in response to receiving the instruction to deactivate at least one of the PTP leg and the PTM leg from the gNB 200 in step S12.
  • the PDCP entity of the UE 100 may perform duplicate packet discarding of two identical MBS packets transmitted by duplication.
  • PDCP operation example 1 Next, an operation example 1 of PDCP according to one embodiment will be described.
  • the PDCP entity of UE 100 sets and updates PDCP variables according to the PDCP sequence number (PDCP SN) included in the PDCP packet received from gNB 200. Normally, the UE 100 sets the initial value of the PDCP variable to zero, and updates (increments, counts up) the PDCP variable according to packet reception from the gNB 200 .
  • PDCP SN PDCP sequence number
  • the PDCP entity of the UE 100 that has participated in an MBS session from the beginning can sequentially update the PDCP variables to bring them to the latest state.
  • the PDCP entity of the UE 100, which has joined the MBS session halfway through can receive a PDCP packet having a PDCP SN whose value is significantly different from the initial value, so that the PDCP entity operation (predetermined PDCP operation) cannot be performed normally. There is a possibility that it will not be possible.
  • the following method enables the UE 100 that has joined the MBS session midway to perform the prescribed PDCP operation normally.
  • the PDCP entity of the UE 100 sets the PDCP SN included in the PDCP packet first received from the gNB 200 as the initial value of the variable (PDCP variable) used for the predetermined PDCP operation. That is, when the PDCP entity of the UE 100 receives a PDCP packet transmitted in an MBS session (PTM), the PDCP SN included in the PDCP packet first received from the gNB 200 is set to PDCP instead of setting the PDCP variable to zero. Set as the initial value of the variable. This enables the PDCP entity of the UE 100, which has joined the MBS session from the middle, to normally perform the predetermined PDCP operation.
  • PTM MBS session
  • the predetermined PDCP operation is at least one of reception window control and packet rearrangement operation.
  • the PDCP variable used for reception window control may be at least one of RX_NEXT and RX_DELIV.
  • RX_NEXT is configured to contain the sequence number of the PDCP SDU expected to be received next.
  • RX_DELIV contains the sequence number of the oldest PDCP SDU waiting to be received and not yet provided to the upper layer. Normally, the initial values of RX_NEXT and RX_DELIV are "0".
  • the PDCP variable used for packet reordering may be RX_REORD.
  • RX_REORD is the sequence number of the PDCP SDU that started the timer indicating the maximum time to wait for packet reordering. For example, if the sequence number of the received packet is smaller than RX_REORD, UE 100 discards the packet.
  • FIG. 10 is a diagram showing an operation example 1 of PDCP according to one embodiment.
  • step S101 the gNB 200 starts MBS transmission for a given MBS session.
  • step S102 the UE 100A participating in the MBS session from the beginning starts receiving MBS for the MBS session.
  • UE 100A is in RRC connected state, RRC idle state, or RRC inactive state.
  • the UE 100A may receive and execute MBS bearer (PDCP) configuration from the gNB 200 .
  • PDCP MBS bearer
  • step S103 the gNB 200 transmits PDCP packets by PTM via the MBS bearer. Assume that the sequence number (PDCP SN) included in the PDCP header of this PDCP packet is "0".
  • step S104 when the PDCP entity of the UE 100A receives the PDCP packet from the gNB 200, it sets the PDCP SN "0" included in the received PDCP packet as the initial value of the PDCP variable, and performs a predetermined PDCP operation.
  • step S105 the UE 100B joins the MBS session from the middle and starts receiving MBS for the MBS session.
  • the UE 100B is in RRC connected state, RRC idle state or RRC inactive state.
  • the UE 100B may receive and execute MBS bearer (PDCP) configuration from the gNB 200 .
  • PDCP MBS bearer
  • step S106 the gNB 200 transmits the PDCP packet by PTM via the MBS bearer.
  • the PDCP SN included in the PDCP header of this PDCP packet is "n".
  • "n" is an integer of 1 or more.
  • step S107 when the PDCP entity of the UE 100B first receives the PDCP packet via the MBS bearer, it sets the PDCP SN "n" included in the first received PDCP packet as the initial value of the PDCP variable, and performs the predetermined PDCP operation. I do.
  • it may be (n+1) mod [SN size].
  • step S108 when the PDCP entity of the UE 100A receives the PDCP packet via the MBS bearer, it updates the PDCP variable with the PDCP SN "n" included in the received PDCP packet.
  • step S109 the gNB 200 transmits the PDCP packet by PTM via the MBS bearer. Assume that the PDCP SN included in the PDCP header of this PDCP packet is "n+1".
  • step S110 when the PDCP entity of the UE 100B receives the PDCP packet via the MBS bearer, it updates the PDCP variable with the PDCP SN "n+1" included in the received PDCP packet.
  • step S111 when the PDCP entity of the UE 100A receives the PDCP packet via the MBS bearer, it updates the PDCP variable with the PDCP SN "n+1" included in the received PDCP packet.
  • the initial value of each PDCP variable is updated from the received PDCP packet, but it is not limited to this.
  • the initial value of each PDCP variable may be set from the gNB 200 to the UE 100.
  • the UE 100B that performs MBS intermediate reception may be given the initial value of each PDCP variable from the gNB 200 when setting MBS reception with dedicated signaling.
  • PDCP operation example 2 Next, an operation example 2 of PDCP according to one embodiment will be described, mainly focusing on differences from the operation example 1 described above.
  • the PDCP SN was mainly assumed as the PDCP variable managed by the UE 100.
  • the UE 100 also manages the hyperframe number (HFN) as a PDCP variable will be described.
  • HFN is incremented when PDCP SN wraps around. That is, HFN is a value that is counted up each time the PDCP SN goes around.
  • the UE 100 manages COUNT, which is a count value consisting of PDCP SN and HFN.
  • COUNT is a count value consisting of PDCP SN and HFN.
  • the format of RX_DELIV is the same as COUNT, HFN+SN.
  • COUNT is also used to encrypt PDCP packets for security.
  • the UE 100B which joins the MBS session from the middle, calculates RX_DELIV from the PDCP SN included in the header of the PDCP packet (PDCP PDU) first received in this MBS session.
  • the PDCP PDU header contains the PDCP SN but not the HFN.
  • the initial value of RX_DELIV is 0, and in the case of unicast, both gNB 200 and UE 100 increment the HFN based on the initial value for each PDCP SN wrap around, thereby synchronizing the HFN of gNB 200 and UE 100.
  • a valid HFN that is, the gNB 200 is managing HFN
  • the PDCP entity of UE 100 receives from gNB 200 a PDCP packet that is encrypted using COUNT consisting of PDCP SN and HFN and transmitted in the MBS session.
  • the PDCP entity of UE 100 generates a guessed HFN by guessing the HFN.
  • the PDCP entity of the UE 100 attempts to decode the PDCP packet using the estimated COUNT consisting of the PDCP SN and the estimated HFN contained in the received PDCP packet.
  • the PDCP entity of UE 100 determines the guessed HFN as a valid HFN if the decoding is successful.
  • the UE 100 can derive a valid HFN using the PDCP security function even if it joins the MBS session in the middle.
  • PDCP variables such as RX_DELIV can be appropriately managed by managing COUNT using the HFN derived in this way.
  • the UE 100 may receive range information indicating the HFN range (hereinafter referred to as "HFN range information") from the gNB 200.
  • the PDCP entity of UE 100 may generate a guess HFN based on the received HFN range information. For example, an HFN included in the range indicated by the received HFN range information is generated as an estimated HFN. Since arithmetic processing is required to decrypt the encrypted PDCP packet, there are problems in power consumption and response time of the UE 100 . Therefore, by having the gNB 200 notify the UE 100 of available HFNs in advance, the number of estimated HFN candidates generated by the PDCP entity of the UE 100 can be reduced, and the power consumption and response time of the UE 100 can be reduced.
  • HFN range information range information indicating the HFN range
  • the gNB 200 notifies the UE 100 of the HFN value itself.
  • HFN is counted up according to the count up of PDCP SN. Since there may be a delay between the gNB 200 notifying the UE 100 of the current HFN and the UE 100 applying this HFN, the HFN between the gNB 200 and the UE 100 may become unsynchronized.
  • FIG. 11 is a diagram showing an operation example 2 of PDCP according to one embodiment.
  • the UE 100 is assumed to be the UE 100B of the operation example 1 described above, that is, the UE 100 that has joined the MBS session from the middle.
  • step S201 the PDCP entity of the UE 100 receives PDCP packets transmitted (for example, PTM transmission) from the gNB 200 in the MBS session.
  • PDCP packets transmitted for example, PTM transmission
  • step S202 the PDCP entity of UE 100 acquires the PDCP SN contained in the header of the PDCP packet received in step S201. It is assumed that the value of this PDCP SN is not zero because the UE 100 has joined the MBS session from the middle.
  • step S203 the UE 100 may receive HFN range information from the gNB 200.
  • the gNB 200 notifies the range of possible HFNs for a given MBS session.
  • the value range may be determined according to the amount of data transmitted by MBS. Note that step S203 may be performed before step S202.
  • the HFN range information may be information that directly indicates the HFN range (for example, "0 to 10"). Also, the HFN range information may be information indicating the number of HFN bits (for example, “3 bits”: equivalent to “0 to 7”). When the HFN range information is designated as "3 bits”, the PDCP entity of UE 100 may manage HFN so that "7" is followed by "0".
  • HFN range information For notification of HFN range information from gNB 200 to UE 100, SIB, MCCH (multicast control channel), RRC Reconfiguration message, or PDCP Control PDU may be used. These messages may include HFN range information and MBS session identifiers (eg, TMGI, G-RNTI) associated with this HFN range information. These messages may contain multiple sets of HFN range information and MBS session identifiers.
  • MBS session identifiers eg, TMGI, G-RNTI
  • step S204 the PDCP entity of UE 100 generates an estimated HFN.
  • the PDCP entity of the UE 100 generates an estimated HFN by substituting values for HFN in the order of 0, 1, 2, . . . , for example. If the HFN range information is received in step S203, the PDCP entity of the UE 100 generates an estimated HFN within the range indicated by the HFN range information.
  • the PDCP entity of the UE 100 generates an estimated COUNT consisting of the PDCP SN obtained at step S202 and the estimated HFN generated at step S204.
  • step S206 the PDCP entity of the UE 100 attempts to decrypt (decrypt) the PDCP packet received at step S201 using the estimated COUNT generated at step S205. If the decoding of the PDCP packet fails (step S207: NO), the process returns to step S204.
  • step S208 the PDCP entity of the UE 100 determines the estimated HFN generated in step S204 as a valid HFN, and stores and manages this HFN. This synchronizes the HFN between the gNB 200 and the UE 100 .
  • the UE 100 may perform handover from the first cell of the gNB 200 to the second cell, RRC re-establishment, or cell reselection. If the MBS session that the UE 100 was receiving in the first cell is also provided in the second cell, the UE 100 can continue receiving MBS even if handover, RRC re-establishment, or cell re-selection is performed. Note that the first cell and the second cell may be managed by gNBs 200 different from each other.
  • the PDCP SN is synchronized between cells, but the HFN may not be synchronized between cells. Therefore, the UE 100, based on the handover from the first cell to the second cell, RRC re-establishment, or cell reselection, may re-execute the same operation as in FIG. 11 in the second cell. .
  • UE 100 before performing handover from the first cell to the second cell, RRC re-establishment, or cell reselection, receives information indicating whether or not to re-execute the same operation as in FIG. 11 from gNB 200 good too. If the information indicates that re-execution is unnecessary, the managed HFN is retained without being discarded even after handover from the first cell to the second cell, RRC re-establishment, or cell re-selection. may Thereby, when the HFN is synchronized between the first cell and the second cell, the UE 100 does not need to re-execute the operation similar to that of FIG. 11 . Details of such an operation will be described later in Operation Example 6.
  • PDCP operation example 3 Next, an operation example 3 of PDCP according to one embodiment will be described, mainly focusing on differences from the operation examples 1 and 2 described above.
  • HFN is counted up when the PDCP SN wraps around, so there is no problem even if the PDCP SN wraps around.
  • HFN on the other hand, is not supposed to wrap around (ie, COUNT does not wrap around). Therefore, it is desirable to be able to initialize the PDCP variable (eg, COUNT) containing the HFN when the HFN is about to wrap around.
  • the PDCP entity of the UE 100 updates PDCP variables associated with the MBS session in response to receiving PDCP packets transmitted in the MBS session.
  • the PDCP entity of UE 100 initializes the updated PDCP variables (ie, returns them to zero) when the MBS session is resumed after the MBS session has been suspended.
  • the PDCP entity of the UE 100 initializes the PDCP variables with the restart of the MBS session as a trigger. This allows the PDCP variable (eg, COUNT) containing the HFN to be initialized, for example, if the HFN is about to wrap around.
  • FIG. 12 is a diagram showing an operation example 3 of PDCP according to one embodiment.
  • the UE 100 may be the UE 100 that has joined the MBS session from the beginning. Also, the UE 100 may be a UE 100 that has joined the MBS session from the middle.
  • the gNB 200 may transmit MBS data by multicast to multiple UEs 100 in the RRC connected state.
  • step S301 the PDCP entity of the UE 100 receives PDCP packets transmitted (for example, PTM transmission) from the gNB 200 in the MBS session.
  • PDCP packets transmitted for example, PTM transmission
  • step S302 the PDCP entity of UE 100 updates the PDCP variable (eg, COUNT) based on the PDCP packet received in step S301.
  • the PDCP variables that are updated may be RX_NEXT and/or RX_DELIV.
  • the gNB 200 may transmit a session suspension notification indicating suspension of the MBS session to the UE 100.
  • a session suspension notification may be sent by MAC CE.
  • the session suspension notification may be sent in SIB, MCCH (multicast control channel), RRC Reconfiguration message, or PDCP Control PDU.
  • the UE 100 detects suspension of the MBS session in response to reception of the session suspension notification.
  • UE 100 may determine that the MBS session has been interrupted when no MBS data is received in the MBS session for a certain period of time regardless of the session interruption notification.
  • a timer value that defines this certain period of time may be set from the gNB 200 to the UE 100, for example.
  • the gNB 200 may configure the UE 100 with a set of this timer value and MBS session identifier (eg, TMGI, G-RNTI).
  • MBS session identifier eg, TMGI, G-RNTI
  • the gNB 200 may transmit a session restart notification indicating restart of the MBS session to the UE 100.
  • a session restart notification may be transmitted by MAC CE.
  • the session resumption notification may be sent in SIB, MCCH (multicast control channel), RRC Reconfiguration message, or PDCP Control PDU.
  • the UE 100 detects restart of the MBS session upon receiving the session restart notification. Alternatively, UE 100 may determine that the MBS session has been resumed when receiving MBS data in the MBS session after determining that the MBS session has been suspended, regardless of the session restart notification.
  • step S305 the PDCP entity of the UE 100 initializes (that is, returns to zero) the updated PDCP variables associated with the MBS session when the MBS session is resumed after being suspended. .
  • the gNB 200 may initialize updated PDCP variables associated with that MBS session.
  • step S306 the PDCP entity of UE 100 receives PDCP packets transmitted from gNB 200 in the MBS session.
  • the PDCP entity of the UE 100 updates the PDCP variable (eg, COUNT) based on the PDCP packet received at step S306.
  • the PDCP variable eg, COUNT
  • the UE 100 may initialize the PDCP variables when detecting suspension of the MBS session in step S303.
  • step S305 when the UE 100 detects suspension of the MBS session in step S303 or detects resumption of the MBS session in step S304, in step S305, the PDCP entity may be re-established. good.
  • the RRC layer may instruct the PDCP layer to re-establish the PDCP entity.
  • PDCP variables managed by the PDCP entity are initialized.
  • PDCP operation example 4 Next, an operation example 4 of PDCP according to one embodiment will be described mainly with respect to differences from the operation examples 1 to 3 described above.
  • a plurality of UEs 100 receive MBS data from the gNB 200 via multicast for a given MBS session, and one of the plurality of UEs 100 performs handover or RRC re-establishment.
  • the PDCP entity of the UE 100 is re-established with the handover of the UE 100 or the re-establishment of RRC, so the PDCP variables managed by the PDCP entity are initialized.
  • the COUNT of the MBS session reaches the upper limit (that is, when it is about to wrap around)
  • one or more UEs receiving the MBS session must initialize the PDCP variables of
  • the PDCP entity of the UE 100 updates PDCP variables associated with the MBS session in response to receiving PDCP packets transmitted in the MBS session.
  • the PDCP entity of the UE 100 initializes the updated PDCP variables (that is, returns them to zero) when receiving the PDCP variable initialization instruction from the gNB 200 .
  • the instruction for initializing the PDCP variable is a PDCP entity re-establishment instruction. good.
  • FIG. 13 is a diagram showing an operation example 4 of PDCP according to one embodiment.
  • the UE 100 may be the UE 100 that has joined the MBS session from the beginning. Also, the UE 100 may be a UE 100 that has joined the MBS session from the middle.
  • the gNB 200 may transmit MBS data by multicast to multiple UEs 100 in the RRC connected state. The gNB 200 may transmit MBS data by multicast to multiple UEs 100 in RRC idle or inactive state.
  • step S401 the PDCP entity of the UE 100 receives PDCP packets transmitted (for example, PTM transmission) from the gNB 200 in the MBS session.
  • PDCP packets transmitted for example, PTM transmission
  • step S402 the PDCP entity of UE 100 updates the PDCP variable (eg, COUNT) based on the PDCP packet received in step S401.
  • the PDCP variables that are updated may be RX_NEXT and/or RX_DELIV.
  • the PDCP entity of gNB 200 updates a PDCP variable (eg, COUNT) based on the packet sent in step S401.
  • the gNB 200 transmits to the UE 100 an initialization instruction instructing initialization of the PDCP variables.
  • the initialization indication may be a PDCP entity re-establishment indication.
  • the gNB 200 may stop (pause) the transmission of PDCP packets before transmitting the initialization instruction.
  • the gNB 200 may send the initialization indication in response to the PDCP variables of the PDCP entity of the gNB 200 being about to wrap around (eg, reaching the COUNT upper limit).
  • the initialization instruction may be sent in an RRC Reconfiguration message, PDCP Control PDU, SIB, or MCCH (multicast control channel).
  • the initialization instruction may be sent by MAC CE (Control Element) or MTCH (Multicast Traffic Channel). Note that the initialization instruction is desirably notified to a plurality of UEs all at once. For example, the MAC CE indicating the initialization instruction may be multiplexed in the transport block containing the multicast MTCH and notified. These messages may include an initialization indication and an MBS session identifier (eg, TMGI, G-RNTI, session ID) associated with the initialization indication. In addition to this MBS session identifier, or instead of the MBS session identifier, a bearer ID (or MBS bearer ID) may be used.
  • MBS session identifier eg, TMGI, G-RNTI, session ID
  • the gNB 200 re-establishes the PDCP entity by another UE 100 that receives the same MBS session as the UE 100 by multicast, that is, the other UE 100 initializes the PDCP variable.
  • Initialization in step S403 Instructions may be sent. As a result, all of the multiple UEs 100 that receive the same MBS session will initialize the PDCP variables.
  • step S404 the PDCP entity of UE 100 initializes (that is, resets to zero) the updated PDCP variables associated with the MBS session in response to receiving the initialization instruction in step S403.
  • the gNB 200 may initialize updated PDCP variables associated with that MBS session. Initialization of the PDCP variables may be performed at re-establishment of the PDCP entity.
  • step S405 the PDCP entity of UE 100 receives PDCP packets transmitted from gNB 200 in the MBS session.
  • the gNB 200 may resume transmission of PDCP packets upon completing the initialization of the PDCP variables of all UEs that receive the multicast.
  • the PDCP entity of the UE 100 updates the PDCP variable (eg, COUNT) based on the PDCP packet received at step S406.
  • the PDCP variable eg, COUNT
  • the other UE 100 among the plurality of UE 100 may act to initialize the PDCP variables. For example, when one UE 100 among multiple UEs 100 receiving the same MBS session re-establishes the PDCP entity, the gNB 200 suspends the MBS session and then resumes the MBS session. As a result, all of the multiple UEs 100 that receive the same MBS session will initialize the PDCP variables.
  • PDCP operation example 5 Next, an operation example 5 of PDCP according to one embodiment will be described mainly with respect to differences from the operation examples 1 to 4 described above.
  • the PDCP entity of UE 100 updates PDCP variables associated with the MBS session in response to reception of PDCP packets transmitted in the MBS session.
  • the UE 100 retains the PDCP variables associated with the MBS session without initializing them.
  • the PDCP entity of the UE 100 continues reception processing (PDCP operation) of PDCP packets transmitted in the MBS session based on the held PDCP variables. This can prevent the re-establishment of the PDCP entity in one UE 100 receiving the same MBS session by multicast from adversely affecting other UEs 100 .
  • FIG. 14 is a diagram showing an operation example 4 of PDCP according to one embodiment.
  • the UE 100 may be the UE 100 that has joined the MBS session from the beginning. Also, the UE 100 may be a UE 100 that has joined the MBS session from the middle.
  • the gNB 200 may transmit MBS data by multicast to multiple UEs 100 in the RRC connected state.
  • step S501 the PDCP entity of the UE 100 receives PDCP packets transmitted (for example, PTM transmission) from the gNB 200 in the MBS session.
  • PDCP packets transmitted for example, PTM transmission
  • step S502 the PDCP entity of UE 100 updates the PDCP variable (eg, COUNT) based on the PDCP packet received in step S401.
  • the PDCP variables that are updated may be RX_NEXT and/or RX_DELIV.
  • step S503 the UE 100 re-establishes the PDCP entity following handover or RRC re-establishment. That is, the UE 100 deletes the old PDCP entity before handover or RRC re-establishment and generates a new PDCP entity. However, it is assumed that the PDCP variables updated by the old PDCP entity can be retained in a predetermined storage area. Note that the UE 100 may receive a re-establishment instruction for instructing re-establishment of the PDCP entity from the gNB 200 and re-establish the PDCP entity in response to the reception of this re-establishment instruction.
  • step S504 the UE 100 determines whether or not the PDCP entity related to re-establishment is associated with the MBS session.
  • the UE 100 may determine whether or not the PDCP entity related to re-establishment is configured to hold PDCP variables without initializing them.
  • Such settings may be made from the gNB 200 to the UE 100 by, for example, an RRC Reconfiguration message.
  • step S506 the UE 100 holds the PDCP variables updated in step S502 without initializing them. That is, the UE 100 resets the PDCP variable held in the predetermined storage area to the new PDCP entity related to re-establishment.
  • step S507 the PDCP entity of UE 100 receives PDCP packets transmitted from gNB 200 in the MBS session.
  • step S508 the PDCP entity of UE 100 updates the PDCP variable (eg, COUNT) based on the PDCP packet received in step S507.
  • the PDCP variable eg, COUNT
  • the UE 100 may re-establish the PDCP entity in response to handover from the first cell to the second cell of the gNB 200 or RRC re-establishment (step S503).
  • UE 100 is notified from gNB 200 that the PDCP variable can be used continuously in the second cell before performing handover or RRC re-establishment, PDCP variable even if handover or RRC re-establishment is performed may be retained without being initialized.
  • Such notification information may be transmitted by the gNB 200 to the UE 100 in the RRC Reconfiguration message or SIB in the first cell. Operations related to such operations will be described later in Operation Example 6.
  • FIG. 15 is a diagram for explaining PDCP operation example 6 according to an embodiment.
  • the UE 100 may perform handover from cell C1 (first cell) to cell C2 (second cell), RRC re-establishment, or cell reselection.
  • FIG. 15 shows an example in which gNB 200A managing cell C1 and gNB 200B managing cell C2 are different.
  • the UE 100 can continue receiving MBS even after handover, RRC re-establishment, or cell reselection.
  • HFN may not be synchronized between cells.
  • the UE 100 needs to synchronize with the HFN in cell C2, ie, the HFN managed by the gNB 200B, when moving from cell C1 to cell C2.
  • the PDCP entity of the UE 100 updates a PDCP variable (eg, COUNT) associated with the MBS session in response to receiving a PDCP packet transmitted in the MBS session (step S601 ).
  • the PDCP variables that are updated may be RX_NEXT and/or RX_DELIV.
  • UE 100 is handed over from cell C1 to cell C2, RRC re-establishment, or before performing cell reselection, whether the updated PDCP variables continue to be available in cell C2 is received from the gNB 200A (step S602). It is assumed that the gNB 200A knows whether or not the HFNs are synchronized between the cells C1 and C2 through inter-base station communication with the gNB 200B, for example. The gNB 200A sends notification information indicating that the updated PDCP variables can continue to be used in cell C2 when the HFN is synchronized between cells C1 and C2.
  • the gNB 200A will send a notification indicating that the updated PDCP variables are continuously disabled in cell C2.
  • the gNB 200A may transmit notification information in SIB, MCCH, RRC Reconfiguration, PDCP Control PDU.
  • the notification information may include information indicating an area consisting of one or more cells that can continue to use the updated PDCP variables.
  • the notification information may include a cell ID list consisting of cell IDs of cells that can reuse the PDCP variables used in cell C1.
  • the UE 100 performs handover from cell C1 to cell C2, RRC re-establishment, or cell reselection (step S603).
  • the PDCP entity of the UE 100 when the notification information indicates that the PDCP variables (eg, COUNT) used in the cell C1 can also be used in the cell C2, continue the PDCP variables held in the cell C2. to receive a PDCP packet from cell C2 (step S604).
  • the notification information indicates that the PDCP variables used in cell C1 cannot be used in cell C2
  • the PDCP entity of UE 100 derives the PDCP variables from the PDCP packet first received in cell C2 (described above See operation example 1).
  • the UE 100 may derive PDCP variables using the notified HFN.
  • FIGS. 16 and 17 are diagrams for explaining an operation example of RLC according to one embodiment.
  • the RLC entity of the UE 100 receives from the gNB 200 RLC PDUs (Protocol Data Units) obtained by dividing the RLC SDUs (Service Data Units) by the gNB 200, which are transmitted in the MBS session.
  • RLC PDUs Protocol Data Units
  • RLC SDUs Service Data Units
  • the RLC entity of the gNB 200 performs division processing of PDCP packets (that is, RLC SDUs) (step S701). Such division processing is sometimes called segmentation.
  • the RLC entity of gNB 200 allocates a sequence number (SN) to each segment obtained by the segmentation process to obtain RLC PDUs.
  • FIG. 16 shows an example of division into a total of six RLC PDUs (six segments) of SN#0 to #5.
  • the RLC entity of UE 100 cannot reconstruct the original PDCP packet (RLC SDU) until it receives all of these six RLC PDUs.
  • Such reconstruction processing is sometimes called Reassembly.
  • UM Unacknowledged Mode
  • the UE 100 receives from the first RLC PDU (that is, the RLC PDU of SN#0), so there is no big problem.
  • the UE 100 may join the MBS session in the middle, so it is not always possible to receive the RLC PDU of SN#0. If the UE 100 cannot receive the RLC PDU of SN#0, the reassembly to the RLC SDU cannot be completed. RLC SDUs that cannot be reassembled will be discarded when the timer (T-Reassembly) expires.
  • the RLC entity of UE 100 that has joined the MBS session halfway through the first received RLC PDU and the first received RLC PDU Reconstruct the RLC SDU from the RLC PDUs that follow the RLC PDU that was generated.
  • the RLC entity of UE 100 has received the first RLC PDU (that is, the RLC PDU of SN#0) (step S702). Therefore, the RLC entity of the UE 100 reconstructs the RLC SDU when the RLC PDUs of SN#0 to #5 are complete (step S703), and passes the RLC SDU to the upper layer (that is, PDCP).
  • the RLC entity of UE 100 receives the first received RLC PDU and the first received RLC PDU subsequent Discard the RLC PDUs. Specifically, if the RLC sequence number included in the RLC PDU first received from gNB 200 is not zero, the RLC entity of UE 100 receives the first Discard the RLC PDU and the RLC PDU that follows the first received RLC PDU.
  • the RLC entity of UE 100 that has joined the MBS session halfway confirms the sequence number of the RLC PDU first received from gNB 200 and detects that this sequence number is SN#2 (step S711). In this case, the RLC entity of UE 100 discards the RLC PDU of SN#2 and the subsequent RLC PDUs of SN#3 to #5 even if the timer (T-Reassembly) has not expired.
  • the gNB 200 it is desirable for the gNB 200 to reduce the number of RLC divisions in MBS transmission in order to minimize PDCP packet discards.
  • PDCP operation examples 1 to 6 according to the above embodiment may be applied to the RLC operation. That is, "PDCP" in the PDCP operation examples 1 to 6 according to the above embodiment may be read as "RLC".
  • Each operation flow described above is not limited to being implemented independently, but can be implemented by combining two or more operation flows. For example, some steps of one operational flow may be added to another operational flow. Also, some steps of one operation flow may be replaced with some steps of another operation flow.
  • the base station may be an NR base station (gNB)
  • the base station may be an LTE base station (eNB).
  • the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node.
  • the base station may be a DU (Distributed Unit) 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 PDCP SN when reusing an existing PDCP functional view, the PDCP SN is common to both the PTM leg and the PTP leg. Since PTM legs are used for multiple UEs, the PDCP SN may not be UE specific and affects both PTM and PTP legs. This means that when a UE joins a multicast session late, the initial value of each state variable is always '0' regardless of whether the first received MBS data is from the PTM leg or the PTP leg. It means that it is not necessarily the case. In other words, the PDCP SN that the UE initially receives can be any value that is not assumed in current unicast transmissions. Also, PDCP re-establishment for one UE may affect all other UEs because state variables are set to initial values. This causes unexpected behavior with receive windows. In other words, PDCP PDUs outside the reception window are discarded.
  • the first received data is received first regardless of whether it is from the PTM leg or the PTP leg.
  • the SN of the received PDCP PDU is the initial value, that is, not "0".
  • Option A The gNB notifies the UE of the initial COUNT value, or RX_NEXT and RX_DELIV.
  • This option allows the UE to receive the first transmission of MBS data with existing mechanisms by only changing the initial values related to the reception window based on information from the gNB.
  • the UE will always successfully receive the gNB's intended first transmission, e.g. due to delays in switching, bad radio conditions, or being outside the RLC reconfiguration window. It is unclear how this option would work in this case.
  • Option B The gNB notifies the UE of the first HFN, and the UE guesses the first HFN and SN from the first received PDCP PDU.
  • this option is similar to the Rel-16 V2X mechanism. That is, "For broadcast and groupcast NR sidelink communications, the initial value of the SN part of RX_NEXT is (x+1) modulo (2 [sl-PDCP-SN-Size] ), where x is the first received PDCP data is the SN of the PDU" and "For broadcast and groupcast NR sidelink communications, the initial value of the SN part of RX_DELIV is (x-0.5x2 [sl-PDCP-SN-Size-1] ) modulo ( 2 [sl-PDCP-SN-Size] ), where x is the SN of the first received PDCP data PDU'.
  • the Rel-16 V2X mechanism does not require synchronization of the transmitter and receiver.
  • HFN since HFN is not used for security, "Note: It is up to the UE implementation to select HFN for RX_NEXT so that the initial value of RX_DELIV is a positive value.”
  • SA3 wait for SA3 to finish investigating the security of MBS before replying to explain the security aspects of RAN2. Therefore, if the HFN part needs to be signaled at this point, RAN2 should be deferred.
  • Option B should serve as a baseline for further discussion.
  • RAN2 sets the initial value of state variables from the first received PDCP PDU of MBS data by the UE, considering the progress of SA3 on security of NR MBS must at least agree to do so.
  • Proposal 3 RAN2 should agree that the UE sets the initial value of the SN part of RX_NEXT and RX_DELIV from the first received MBS data regardless of PTM leg or PTP leg. Depending on the progress of SA3, further consideration is required whether the HFN part will be signaled by the gNB.
  • proposal 2 can be agreed, the UE needs to support simultaneous reception from both PTM and PTP legs. That is, two legs can be activated at the same time, similar to existing PDCP packet duplication. It is beneficial for dynamic PTM/PTP switching because PTP legs are received by multiple UEs, i.e. not UE-specific, and can easily compensate for missing packets that were not received via the PTM leg. it is conceivable that. Therefore, RAN2 needs to agree to simultaneous reception for at least a period of time during dynamic PTM/PTP switching.
  • Proposal 4 RAN2 should agree that UE supports simultaneous reception from both PTM leg and PTP leg for a period of time after dynamic PTM/PTP switching. If Proposals 3 and 4 can be agreed upon, the gNB may not actually know the PDCP SN that the UE has successfully started receiving over the PTM leg. In the case of a PTP to PTM switch, this means that the gNB may not know which PDCP PDUs need to be sent over the PTP leg and/or when the PTP leg can be deactivated. . To solve this problem, it is proposed that the UE inform the gNB of successful PTM reception. This can be sent over the PTP leg if not already deactivated. However, it is unclear if this solution is intended to include the PDCP SN in the information.
  • the gNB may not know the PDCP SN that the UE has finished receiving over the PTM leg. This means that the gNB may not be aware of the PDCP PDUs to initiate transmission over the PTP leg. Therefore, the UE can be considered to inform the gNB of the SN information via the activated PTP leg during dynamic PTM/PTP switching.
  • the UE reports SN information when dynamically switching between PTM and PTP, it is easy to reuse the PDCP control PDUs and exactly the PDCP status report is FMC (first missing PDCP SDU) and an arbitrary bitmap (indicating that the next PDCP SDU is missing or received correctly).
  • FMC first missing PDCP SDU
  • an arbitrary bitmap indicating that the next PDCP SDU is missing or received correctly.
  • reporting the first/last successful PDCP SDU reception over the PTM leg is another option. Therefore, it is necessary to further discuss what needs to be reported during dynamic switching between PTM and PTP.
  • the PDCP Control PDU contains PDCP SN information for service continuity (e.g. activation/deactivation MAC by the CE).
  • Proposal 5 RAN2 should consider whether the UE will send a PDCP control PDU containing PDCP SN information during dynamic switching for service continuity.
  • the type of PDCP control PDUs used and the exact meaning of the SN information need further study.
  • NG-RAN 5G RAN
  • 5GC 5G CN
  • UE 110 Reception unit 120: Transmission unit 130: Control unit 200: gNB 210: Transmission unit 220: Reception unit 230: Control unit 240: Backhaul communication unit

Landscapes

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

Abstract

第１の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する方法である。通信制御方法は、ＰＤＣＰシーケンス番号及びハイパーフレーム番号からなるカウント値を用いて暗号化され、ＭＢＳセッションで伝送されるＰＤＣＰパケットを前記基地局から受信することと、前記ハイパーフレーム番号を推測することで推測ハイパーフレーム番号を生成することと、前記受信したＰＤＣＰパケットに含まれる前記ＰＤＣＰシーケンス番号と前記推測ハイパーフレーム番号とからなる推測カウント値を用いて、前記ＰＤＣＰパケットの復号を試みることと、前記復号に成功した場合、前記推測ハイパーフレーム番号を有効なハイパーフレーム番号として決定することと、を有する。

Description

通信制御方法及びユーザ装置
　本開示は、移動通信システムで用いる通信制御方法及びユーザ装置に関する。
　近年、第５世代（５Ｇ）の移動通信システムが注目されている。５Ｇシステムの無線アクセス技術（ＲＡＴ：Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｔｅｃｈｎｏｌｏｇｙ）であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）は、第４世代の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。
３ＧＰＰ技術仕様書「３ＧＰＰ　ＴＳ　３８．３００　Ｖ１６．３．０　（２０２０－０９）」
　第１の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する方法である。通信制御方法は、ＰＤＣＰシーケンス番号及びハイパーフレーム番号からなるカウント値を用いて暗号化され、ＭＢＳセッションで伝送されるＰＤＣＰパケットを前記基地局から受信することと、前記ハイパーフレーム番号を推測することで推測ハイパーフレーム番号を生成することと、前記受信したＰＤＣＰパケットに含まれる前記ＰＤＣＰシーケンス番号と前記推測ハイパーフレーム番号とからなる推測カウント値を用いて、前記ＰＤＣＰパケットの復号を試みることと、前記復号に成功した場合、前記推測ハイパーフレーム番号を有効なハイパーフレーム番号として決定することと、を有する。
　第２の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する方法である。通信制御方法は、前記ユーザ装置のＰＤＣＰエンティティが、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、前記ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新することと、前記ＭＢＳセッションが中断された場合、又は、前記ＭＢＳセッションが中断された後に前記ＭＢＳセッションが再開された場合、又は、前記基地局から前記ＰＤＣＰ変数を初期化するための指示を受信した場合、前記更新されたＰＤＣＰ変数を初期化することと、を有する。
　第３の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する方法である。通信制御方法は、前記ユーザ装置のＰＤＣＰエンティティが、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、前記ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新することと、前記ＰＤＣＰエンティティが再確立された場合、前記ＭＢＳセッションと対応付けられた前記ＰＤＣＰ変数を初期化せずに保持することと、前記ＰＤＣＰエンティティが、前記保持されたＰＤＣＰ変数に基づいて、前記ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信処理を継続することと、を有する。
　第４の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する方法である。通信制御方法は、前記ユーザ装置のＰＤＣＰエンティティが、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、前記ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新することと、前記ユーザ装置が前記基地局の第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行うよりも前において、前記更新されたＰＤＣＰ変数を前記第２セルにおいて継続して使用可能であるか否かを示す通知情報を前記基地局から受信することと、を有する。
　第５の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する方法である。通信制御方法は、前記ユーザ装置のＲＬＣエンティティが、ＭＢＳセッションで伝送され、前記基地局がＲＬＣ　ＳＤＵを分割して得られたＲＬＣ　ＰＤＵを前記基地局から受信することと、前記基地局から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号に基づいて、前記最初に受信したＲＬＣ　ＰＤＵ及び前記最初に受信したＲＬＣ　ＰＤＵに後続するＲＬＣ　ＰＤＵから前記ＲＬＣ　ＳＤＵを再構築するか否かを決定することと、を有する。
　第６の態様に係るユーザ装置は、第１乃至第５の態様のいずれかに係る通信制御方法を実行するプロセッサを備える。
一実施形態に係る移動通信システムの構成を示す図である。 一実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 一実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 一実施形態に係る下りリンクの論理チャネル（Ｌｏｇｉｃａｌ　ｃｈａｎｎｅｌ）とトランスポートチャネル（Ｔｒａｎｓｐｏｒｔ　ｃｈａｎｎｅｌ）との対応関係を示す図である。 一実施形態に係るＭＢＳデータの配信方法を示す図である。 一実施形態に係るスプリットＭＢＳベアラを示す図である。 一実施形態に係るレグのアクティブ化及び非アクティブ化に関する動作例を示す図である。 一実施形態に係るＰＤＣＰの動作例１を示す図である。 一実施形態に係るＰＤＣＰの動作例２を示す図である。 一実施形態に係るＰＤＣＰの動作例３を示す図である。 一実施形態に係るＰＤＣＰの動作例４を示す図である。 一実施形態に係るＰＤＣＰの動作例４を示す図である。 一実施形態に係るＰＤＣＰの動作例６を説明するための図である。 一実施形態に係るＲＬＣの動作例を説明するための図である。 一実施形態に係るＲＬＣの動作例を説明するための図である。 既存のＰＤＣＰファンクショナルビューを再利用するケースを説明するための図である。
　５Ｇシステム（ＮＲ）にマルチキャスト・ブロードキャストサービスを導入することが検討されている。ＮＲのマルチキャスト・ブロードキャストサービスは、ＬＴＥのマルチキャスト・ブロードキャストサービスよりも改善されたサービスを提供することが望まれる。
　そこで、本開示は、改善されたマルチキャスト・ブロードキャストサービスを実現する通信制御方法及びユーザ装置を提供することを目的とする。
　図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（移動通信システムの構成）
　まず、実施形態に係る移動通信システムの構成について説明する。図１は、一実施形態に係る移動通信システムの構成を示す図である。この移動通信システムは、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ　Ｇｅｎｅｒａｔｉｏｎ　Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。また、移動通信システムには第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
　図１に示すように、移動通信システムは、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ　Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）２０とを有する。
　ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わないが、例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）、タブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ　ＵＥ）、及び／又は飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ　ＵＥ）である。
　ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と呼ばれる）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数に属する。
　なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。
　５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。
　図２は、一実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。
　図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
　受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
　送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　図３は、一実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。
　図３に示すように、ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
　送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
　バックホール通信部２４０は、基地局間インターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢは、ＣＵ（Ｃｅｎｔｒａｌ　Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間はＦ１インターフェイスで接続されてもよい。
　図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　図４に示すように、ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
　ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。
　図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
　図５に示すように、制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤを有する。
　ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間の接続がサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＢのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。
　なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。
　（ＭＢＳ）
　次に、一実施形態に係るＭＢＳについて説明する。ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ　Ｔｏ　Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ　Ｂｒｏａｄｃａｓｔ　ａｎｄ　Ｍｕｌｔｉｃａｓｔ　Ｓｅｒｖｉｃｅ）と呼ばれてもよい。なお、ＭＢＳのユースケース（サービス種別）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ　ｔｏ　Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ　ｐｒｏｔｏｃｏｌ　ｔｅｌｅｖｉｓｉｏｎ）、グループ通信、及びソフトウェア配信等がある。
　ＬＴＥにおけるＭＢＳの送信方式には、ＭＢＳＦＮ（Ｍｕｌｔｉｃａｓｔ　Ｂｒｏａｄｃａｓｔ　Ｓｉｎｇｌｅ　Ｆｒｅｑｕｅｎｃｙ　Ｎｅｔｗｏｒｋ）送信及びＳＣ－ＰＴＭ（Ｓｉｎｇｌｅ　Ｃｅｌｌ　Ｐｏｉｎｔ　Ｔｏ　Ｍｕｌｔｉｐｏｉｎｔ）送信の２種類がある。図６は、一実施形態に係る下りリンクの論理チャネル（Ｌｏｇｉｃａｌ　ｃｈａｎｎｅｌ）とトランスポートチャネル（Ｔｒａｎｓｐｏｒｔ　ｃｈａｎｎｅｌ）との対応関係を示す図である。
　図６に示すように、ＭＢＳＦＮ送信に用いる論理チャネルはＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ　Ｔｒａｆｆｉｃ　Ｃｈａｎｎｅｌ）及びＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）であり、ＭＢＳＦＮ送信に用いるトランスポートチャネルはＭＣＨ（Ｍｕｌｔｉｃａｓｔ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）である。ＭＢＳＦＮ送信は、主にマルチセル送信用に設計されており、複数のセルからなるＭＢＳＦＮエリアにおいて各セルが同じＭＢＳＦＮサブフレームで同じ信号（同じデータ）の同期送信を行う。
　ＳＣ－ＰＴＭ送信に用いる論理チャネルはＳＣ－ＭＴＣＨ（Ｓｉｎｇｌｅ　Ｃｅｌｌ　Ｍｕｌｔｉｃａｓｔ　Ｔｒａｆｆｉｃ　Ｃｈａｎｎｅｌ）及びＳＣ－ＭＣＣＨ（Ｓｉｎｇｌｅ　Ｃｅｌｌ　Ｍｕｌｔｉｃａｓｔ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）であり、ＳＣ－ＰＴＭ送信に用いるトランスポートチャネルはＤＬ－ＳＣＨ（Ｄｏｗｎｌｉｎｋ　Ｓｈａｒｅｄ　Ｃｈａｎｎｅｌ）である。ＳＣ－ＰＴＭ送信は、主に単一セル送信用に設計されており、セル単位でブロードキャスト又はマルチキャストでのデータ送信を行う。ＳＣ－ＰＴＭ送信に用いる物理チャネルはＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ　Ｄｏｗｎｌｉｎｋ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）及びＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ　Ｄｏｗｎｌｉｎｋ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）であり、動的なリソース割当が可能になっている。
　以下において、ＳＣ－ＰＴＭ伝送方式と同様な方式を用いてＭＢＳが提供される一例について主として説明するが、ＭＢＳＦＮ伝送方式を用いてＭＢＳが提供されてもよい。また、ＭＢＳがマルチキャストにより提供される一例について主として説明する。このため、ＭＢＳをマルチキャストと読み替えてもよい。但し、ＭＢＳがブロードキャストにより提供されてもよい。
　また、ＭＢＳデータとは、ＭＢＳにより提供されるデータをいい、ＭＢＳ制御チャネルとは、ＭＣＣＨ又はＳＣ－ＭＣＣＨをいい、ＭＢＳトラフィックチャネルとは、ＭＴＣＨ又はＳＣ－ＭＴＣＨをいうものとする。但し、ＭＢＳデータは、ユニキャストで送信される場合もある。ＭＢＳデータは、ＭＢＳパケット又はＭＢＳトラフィックと呼ばれてもよい。
　ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｇｒｏｕｐ　Ｉｄｅｎｔｉｔｙ）及びセッション識別子のうち少なくとも１つにより識別され、これらの識別子のうち少なくとも１つをＭＢＳセッション識別子と呼ぶ。このようなＭＢＳセッション識別子は、ＭＢＳサービス識別子又はマルチキャストグループ識別子と呼ばれてもよい。
　図７は、一実施形態に係るＭＢＳデータの配信方法を示す図である。
　図７に示すように、ＭＢＳデータ（ＭＢＳ　Ｔｒａｆｆｉｃ）は、単一のデータソース（アプリケーションサービスプロバイダ）から複数のＵＥに配信される。５Ｇコアネットワークである５Ｇ　ＣＮ（５ＧＣ）２０は、アプリケーションサービスプロバイダからＭＢＳデータを受信し、ＭＢＳデータのコピーの作成（Ｒｅｐｌｉｃａｔｉｏｎ）を行って配信する。
　５ＧＣ２０の観点からは、共有ＭＢＳデータ配信（Ｓｈａｒｅｄ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）及び個別ＭＢＳデータ配信（Ｉｎｄｉｖｉｄｕａｌ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ）の２つの配信方法が可能である。
　共有ＭＢＳデータ配信では、５Ｇ無線アクセスネットワーク（５Ｇ　ＲＡＮ）であるＮＧ－ＲＡＮ１０と５ＧＣ２０との間に接続が確立され、５ＧＣ２０からＮＧ－ＲＡＮ１０へＭＢＳデータを配信する。以下において、このような接続（トンネル）を「ＭＢＳ接続」と呼ぶ。
　ＭＢＳ接続は、Ｓｈａｒｅｄ　ＭＢＳ　Ｔｒａｆｆｉｃ　ｄｅｌｉｖｅｒｙ接続又は共有トランスポート（ｓｈａｒｅｄ　ｔｒａｎｓｐｏｒｔ）と呼ばれてもよい。ＭＢＳ接続は、ＮＧ－ＲＡＮ１０（すなわち、ｇＮＢ２００）で終端する。ＭＢＳ接続は、ＭＢＳセッションと１対１で対応していてもよい。
　ｇＮＢ２００は、自身の判断でＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ：ユニキャスト）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ：マルチキャスト又はブロードキャスト）のいずれかの伝送方式を選択し、選択した伝送方式でＵＥ１００にＭＢＳデータを送信する。
　他方、個別ＭＢＳデータ配信では、ＮＧ－ＲＡＮ１０とＵＥ１００との間にユニキャストのセッションが確立され、５ＧＣ２０からＵＥ１００へＭＢＳデータを個別に配信する。このようなユニキャストは、ＰＤＵセッション（ＰＤＵ　Ｓｅｓｓｉｏｎ）と呼ばれてもよい。ユニキャスト（ＰＤＵセッション）は、ＵＥ１００で終端する。
　（スプリットＭＢＳベアラ）
　次に、一実施形態に係るスプリットＭＢＳベアラについて説明する。
　ｇＮＢ２００は、ＰＴＰ通信パス及びＰＴＭ通信パスに分離されたＭＢＳベアラ（以下、適宜「スプリットＭＢＳベアラ」と呼ぶ）をＵＥ１００に設定し得る。これにより、ｇＮＢ２００は、ＵＥ１００に対するＭＢＳデータの送信をＰＴＰ（ＰＴＰ通信パス）とＰＴＭ（ＰＴＭ通信パス）との間で動的に切り替えることができる。或いは、ｇＮＢ２００は、ＰＴＰ（ＰＴＰ通信パス）及びＰＴＭ（ＰＴＭ通信パス）を併用して同一のＭＢＳデータを二重送信することにより信頼性を高めることができる。
　スプリットを終端する所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、ＰＤＣＰレイヤ、又はＳＤＡＰレイヤである。以下において、スプリットを終端する所定レイヤがＰＤＣＰレイヤである一例について主として説明するが、所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、又はＳＤＡＰレイヤであってもよい。
　図８は、一実施形態に係るスプリットＭＢＳベアラを示す図である。以下において、ＰＴＰ通信パスをＰＴＰレグと呼び、ＰＴＭ通信パスをＰＴＭレグと呼ぶ。また、各レイヤに相当する機能部をエンティティと呼ぶ。
　図８に示すように、ｇＮＢ２００のＰＤＣＰエンティティ及びＵＥ１００のＰＤＣＰエンティティのそれぞれは、ＭＢＳに用いるベアラ（データ無線ベアラ）であるＭＢＳベアラをＰＴＰレグ及びＰＴＭレグに分離する。なお、ＰＤＣＰエンティティはベアラごとに設けられる。
　ｇＮＢ２００及びＵＥ１００のそれぞれは、レグごとに設けられる２つのＲＬＣエンティティと、１つのＭＡＣエンティティと、１つのＰＨＹエンティティとを有する。ＰＨＹエンティティは、レグごとに設けられてもよい。なお、ＵＥ１００が２つのｇＮＢ２００との通信を行う二重接続（Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙ）の場合、ＵＥ１００が２つのＭＡＣエンティティを有していてもよい。
　ＰＨＹエンティティは、ＵＥ１００と１対１で割り当てられるセルＲＮＴＩ（Ｃ－ＲＮＴＩ：Ｃｅｌｌ　Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｔｅｍｐｏｒａｒｙ　Ｉｄｅｎｔｉｆｉｅｒ）を用いて、ＰＴＰレグのデータを送受信する。ＰＨＹエンティティは、ＭＢＳセッションと１対１で割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ：Ｇｒｏｕｐ　Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｔｅｍｐｏｒａｒｙ　Ｉｄｅｎｔｉｆｉｅｒ）を用いて、ＰＴＭレグのデータを送受信する。Ｃ－ＲＮＴＩはＵＥ１００ごとに異なるが、Ｇ－ＲＮＴＩは１つのＭＢＳセッションを受信する複数のＵＥ１００で共通のＲＮＴＩである。
　ｇＮＢ２００からＵＥ１００に対してＰＴＭレグを用いてＭＢＳデータのＰＴＭ送信（マルチキャスト又はブロードキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＢＳベアラが設定されており、且つ、ＰＴＭレグがアクティブ化（ａｃｔｉｖａｔｉｏｎ）されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＢＳベアラが設定されていても、ＰＴＭレグが非アクティブ（ｄｅａｃｔｉｖａｔｉｏｎ）状態にある場合は、このＰＴＭレグを用いてＭＢＳデータのＰＴＭ送信を行うことができない。
　また、ｇＮＢ２００及びＵＥ１００がＰＴＰレグを用いてＭＢＳデータのＰＴＰ送信（ユニキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＢＳベアラが設定されており、且つ、ＰＴＰレグがアクティブ化されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＢＳベアラが設定されていても、ＰＴＰレグが非アクティブ状態にある場合は、このＰＴＰレグを用いてＭＢＳデータのＰＴＰ送信を行うことができない。
　ＵＥ１００は、ＰＴＭレグがアクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ　Ｄｏｗｎｌｉｎｋ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）をモニタする（すなわち、Ｇ－ＲＮＴＩを用いてＰＤＣＣＨのブラインドデコーディングを行う）。ＵＥ１００は、当該ＭＢＳセッションのスケジューリング機会にのみ当該ＰＤＣＣＨをモニタしてもよい。
　ＵＥ１００は、ＰＴＭレグが非アクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしない（すなわち、Ｇ－ＲＮＴＩを用いたＰＤＣＣＨのブラインドデコーディングを行わない）。
　ＵＥ１００は、ＰＴＰレグがアクティブ化された状態において、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタする。ＵＥ１００は、ＰＴＰレグにおける間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ　Ｒｅｃｅｐｔｉｏｎ）が設定されている場合、設定されたオン期間（ＯｎＤｕｒａｔｉｏｎ）においてＰＤＣＣＨをモニタする。ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該セルが非アクティブ化されていても、当該セルのＰＤＣＣＨをモニタしてもよい。
　ＵＥ１００は、ＰＴＰレグが非アクティブ化された状態において、ＭＢＳデータ以外の通常のユニキャスト下りリンク送信に備えて、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしてもよい。但し、ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該ＭＢＳセッションについて当該ＰＤＣＣＨをモニタしなくてもよい。
　なお、ｇＮＢ２００のＲＲＣエンティティがＵＥ１００のＲＲＣエンティティに対して送信するＲＲＣメッセージ（例えば、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）により、上述のようなスプリットＭＢＳベアラが設定されるものとする。
　（レグのアクティブ化及び非アクティブ化）
　次に、一実施形態に係るレグのアクティブ化及び非アクティブ化について説明する。図９は、一実施形態に係るレグのアクティブ化及び非アクティブ化に関する動作例を示す図である。
　図９に示すように、ステップＳ１１において、ｇＮＢ２００のＲＲＣエンティティは、図８に示すスプリットＭＢＳベアラ（スプリットベアラ）の設定を含むＲＲＣメッセージをＵＥ１００に送信する。ＲＲＣメッセージは、例えばＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージである。ＵＥ１００のＲＲＣエンティティは、ｇＮＢ２００から受信したＲＲＣメッセージに含まれる設定に基づいてスプリットＭＢＳベアラを確立する。以下において、ＵＥ１００が確立するスプリットＭＢＳベアラが１つである一例について主として説明するが、ＵＥ１００は、ｇＮＢ２００からの設定に応じて複数のスプリットＭＢＳベアラを確立してもよい。
　ｇＮＢ２００は、ＲＲＣメッセージ（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）でベアラ設定を行う際に、同メッセージにて各レグの初期状態（すなわち、各レグのアクティブ化又は非アクティブ化）をＵＥ１００に指示してもよい。ｇＮＢ２００のＲＲＣエンティティは、スプリットＭＢＳベアラのベアラ設定を含むＲＲＣメッセージをＵＥ１００に送信するとき、ベアラ設定と共に、各レグのアクティブ化又は非アクティブ化の指示をＲＲＣメッセージに含める。
　このようなＲＲＣメッセージは、指示の対象となるレグ（ＰＴＰレグ、ＰＴＭレグ）の識別子、及び、アクティブ化及び非アクティブ化のいずれか一方を示す識別子のうち、少なくとも一方を含んでもよい。ＲＲＣメッセージは、指示の対象となるＭＢＳセッション（スプリットＭＢＳベアラ）と対応付けられた識別子（例えば、ＴＭＧＩ、Ｇ－ＲＮＴＩ、セッション識別子、ＱｏＳフロー識別子、ベアラ識別子）を含んでもよい。
　ステップＳ１２において、ｇＮＢ２００は、ＰＴＰレグ及びＰＴＭレグを個別にアクティブ化又は非アクティブ化するための指示をＵＥ１００に送信する。
　ここで、ｇＮＢ２００のＭＡＣエンティティは、当該指示を含むＭＡＣ制御要素（ＭＡＣ　ＣＥ）をＵＥ１００に送信してもよい。ＵＥ１００のＭＡＣエンティティは、ｇＮＢ２００からＭＡＣ　ＣＥを受信する。或いは、ｇＮＢ２００のＰＨＹエンティティは、当該指示を含む下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信してもよい。ＵＥ１００のＰＨＹエンティティは、ｇＮＢ２００からＤＣＩを受信する。
　このようなＭＡＣ　ＣＥ又はＤＣＩは、指示の対象となるレグ（ＰＴＰレグ、ＰＴＭレグ）の識別子、及び、アクティブ化及び非アクティブ化のいずれか一方を示す識別子のうち、少なくとも一方を含んでもよい。ＭＡＣ　ＣＥ又はＤＣＩは、指示の対象となるＭＢＳセッション（スプリットＭＢＳベアラ）と対応付けられた識別子（例えば、ＴＭＧＩ、Ｇ－ＲＮＴＩ、セッション識別子、ＱｏＳフロー識別子、ベアラ識別子）を含んでもよい。
　ＭＡＣ　ＣＥ又はＤＣＩを用いて各レグのアクティブ化及び非アクティブ化を指示することにより、ＲＲＣメッセージを用いる場合に比べて動的な制御が可能である。
　ＵＥ１００は、ＰＴＰレグをアクティブ化する指示の受信に応じて、Ｃ－ＲＮＴＩを用いたデータの受信処理を開始する。ＵＥ１００は、ＰＴＭレグをアクティブ化する指示の受信に応じて、Ｇ－ＲＮＴＩを用いたＭＢＳデータの受信処理を開始する。他方、ＵＥ１００は、ＰＴＰレグを非アクティブ化する指示の受信に応じて、Ｃ－ＲＮＴＩを用いたデータの受信処理を終了する。ＵＥ１００は、ＰＴＭレグを非アクティブ化する指示の受信に応じて、Ｇ－ＲＮＴＩを用いたＭＢＳデータの受信処理を終了する。
　ステップＳ１２において、ｇＮＢ２００は、アクティブ化された状態にあるＰＴＭレグを介して、ＰＴＰレグをアクティブ化又は非アクティブ化する指示をＵＥ１００に送信（ＰＴＭ送信）してもよい。これにより、複数のＵＥ１００のＰＴＰレグをＰＴＭで一括してアクティブ化又は非アクティブ化することができる。
　ｇＮＢ２００は、アクティブ化された状態にあるＰＴＭレグを介して、ＰＴＭレグを非アクティブ化する指示をＵＥ１００に送信（ＰＴＭ送信）してもよい。これにより、複数のＵＥ１００のＰＴＭレグをＰＴＭで一括して非アクティブ化することができる。
　ステップＳ１２において、ｇＮＢ２００は、アクティブ化された状態にあるＰＴＰレグを介して、ＰＴＭレグをアクティブ化又は非アクティブ化する指示をＵＥ１００に送信（ＰＴＰ送信）してもよい。これにより、ＵＥ１００ごとにＰＴＭレグを個別にアクティブ化又は非アクティブ化することができる。
　ｇＮＢ２００は、アクティブ化された状態にあるＰＴＰレグを介して、ＰＴＰレグを非アクティブ化する指示をＵＥ１００に送信（ＰＴＰ送信）してもよい。これにより、ＵＥ１００ごとにＰＴＰレグを個別に非アクティブ化することができる。
　ステップＳ１３において、ＵＥ１００は、ステップＳ１２でｇＮＢ２００からＰＴＰレグ及びＰＴＭレグの少なくとも一方のレグをアクティブ化する指示を受信したことに応じて、受信した指示に対する応答をｇＮＢ２００に送信してもよい。この応答は、例えば、ＵＥ１００のＭＡＣエンティティからＰＴＰレグを介してｇＮＢ２００に送信されてもよい。ＵＥ１００は、当該応答を送信後、アクティブ化されたレグにおけるデータ受信動作を開始してもよい。
　ｇＮＢ２００は、ＵＥ１００からの応答の受信に応じて、アクティブ化されたレグを介してデータを送信する。すなわち、ｇＮＢ２００は、当該応答を受信後、当該レグにおけるデータ送信動作を開始する。
　なお、ＵＥ１００は、ステップＳ１２でｇＮＢ２００からＰＴＰレグ及びＰＴＭレグの少なくとも一方のレグを非アクティブ化する指示を受信したことに応じて、受信した指示に対する応答をｇＮＢ２００に送信してもよい。
　ＵＥ１００のＰＤＣＰエンティティは、ＰＴＰレグ及びＰＴＭレグの両方がアクティブ化された場合、二重送信（Ｄｕｐｌｉｃａｔｉｏｎ）で送信される２つの同一ＭＢＳパケットの重複破棄（ｄｕｐｌｉｃａｔｅ　ｐａｃｋｅｔ　ｄｉｓｃａｒｄｉｎｇ）処理を行ってもよい。
　（ＰＤＣＰの動作例１）
　次に、一実施形態に係るＰＤＣＰの動作例１について説明する。
　ＵＥ１００のＰＤＣＰエンティティは、ｇＮＢ２００から受信するＰＤＣＰパケットに含まれるＰＤＣＰシーケンス番号（ＰＤＣＰ　ＳＮ）に応じてＰＤＣＰ変数を設定及び更新する。通常、ＵＥ１００は、ＰＤＣＰ変数の初期値をゼロに設定し、ｇＮＢ２００からのパケット受信に応じてＰＤＣＰ変数を更新（インクリメント、カウントアップ）していく。
　あるＭＢＳセッションに最初から参加したＵＥ１００のＰＤＣＰエンティティは、ＰＤＣＰ変数を順次更新し、最新の状態にすることができる。他方、ＭＢＳセッションに途中から参加したＵＥ１００のＰＤＣＰエンティティは、初期値から大きく離れた値のＰＤＣＰ　ＳＮを有するＰＤＣＰパケットを受信し得るため、ＰＤＣＰエンティティの動作（所定ＰＤＣＰ動作）を正常に行うことができない虞がある。
　動作例１において、次のような方法により、ＭＢＳセッションに途中から参加したＵＥ１００が所定ＰＤＣＰ動作を正常に行うことを可能とする。
　ＵＥ１００のＰＤＣＰエンティティは、ｇＮＢ２００から最初に受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮを、所定ＰＤＣＰ動作に用いる変数（ＰＤＣＰ変数）の初期値として設定する。すなわち、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッション（ＰＴＭ）で送信されるＰＤＣＰパケットを受信する場合、ＰＤＣＰ変数をゼロに設定するのではなく、ｇＮＢ２００から最初に受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮをＰＤＣＰ変数の初期値として設定する。これにより、ＭＢＳセッションに途中から参加したＵＥ１００のＰＤＣＰエンティティが所定ＰＤＣＰ動作を正常に行うことが可能になる。
　所定ＰＤＣＰ動作は、受信ウィンドウ制御及びパケット並び替え動作のうち少なくとも一方である。
　受信ウィンドウ制御に用いるＰＤＣＰ変数は、ＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶの少なくとも一方であってもよい。ＲＸ＿ＮＥＸＴは、次に受信することが期待されるＰＤＣＰ　ＳＤＵのシーケンス番号を含んで構成される。ＲＸ＿ＤＥＬＩＶは、受信待ちで、未だ上位レイヤに提供していないＰＤＣＰ　ＳＤＵのうち最も古いもののシーケンス番号を含んで構成される。通常、ＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶの初期値は”０”である。
　パケット並び替え動作（Ｒｅｏｒｄｅｒｉｎｇ）に用いるＰＤＣＰ変数は、ＲＸ＿ＲＥＯＲＤであってもよい。ＲＸ＿ＲＥＯＲＤは、パケットの並び替えを待つ最大時間を示すタイマを始動したＰＤＣＰ　ＳＤＵのシーケンス番号である。例えば、ＵＥ１００は、受信パケットのシーケンス番号がＲＸ＿ＲＥＯＲＤよりも小さい場合、当該パケットを破棄する。
　図１０は、一実施形態に係るＰＤＣＰの動作例１を示す図である。
　図１０に示すように、ステップＳ１０１において、ｇＮＢ２００は、あるＭＢＳセッションについてＭＢＳ送信を開始する。ステップＳ１０２において、当該ＭＢＳセッションに最初から参加するＵＥ１００Ａは、当該ＭＢＳセッションについてＭＢＳ受信を開始する。ＵＥ１００Ａは、ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、又はＲＲＣインアクティブ状態にある。ＵＥ１００Ａは、ＭＢＳベアラ（ＰＤＣＰ）の設定をｇＮＢ２００から受信して実行してもよい。
　ステップＳ１０３において、ｇＮＢ２００は、ＭＢＳベアラを介してＰＤＣＰパケットをＰＴＭで送信する。このＰＤＣＰパケットのＰＤＣＰヘッダに含まれるシーケンス番号（ＰＤＣＰ　ＳＮ）は“０”であるとする。
　ステップＳ１０４において、ＵＥ１００ＡのＰＤＣＰエンティティは、ＰＤＣＰパケットをｇＮＢ２００から受信すると、受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮ“０”をＰＤＣＰ変数の初期値として設定し、所定ＰＤＣＰ動作を行う。
　その後、ステップＳ１０５において、ＵＥ１００Ｂは、当該ＭＢＳセッションに途中から参加し、当該ＭＢＳセッションについてＭＢＳ受信を開始する。ＵＥ１００Ｂは、ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、又はＲＲＣインアクティブ状態にある。ＵＥ１００Ｂは、ＭＢＳベアラ（ＰＤＣＰ）の設定をｇＮＢ２００から受信して実行してもよい。
　ステップＳ１０６において、ｇＮＢ２００は、ＭＢＳベアラを介してＰＤＣＰパケットをＰＴＭで送信する。このＰＤＣＰパケットのＰＤＣＰヘッダに含まれるＰＤＣＰ　ＳＮは“ｎ”であるとする。但し、“ｎ”は１以上の整数である。
　ステップＳ１０７において、ＵＥ１００ＢのＰＤＣＰエンティティは、ＭＢＳベアラを介してＰＤＣＰパケットを最初に受信すると、最初に受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮ“ｎ”をＰＤＣＰ変数の初期値として設定し、所定ＰＤＣＰ動作を行う。例えば、ＵＥ１００ＢのＰＤＣＰエンティティは、ＲＸ＿ＤＥＬＩＶ＝当該パケットのシーケンス番号“ｎ”とし、ＲＸ＿ＮＥＸＴ＝当該パケットのシーケンス番号“ｎ”とする。もしくは、（ｎ＋１）　ｍｏｄ　［ＳＮサイズ］としてもよい。
　ステップＳ１０８において、ＵＥ１００ＡのＰＤＣＰエンティティは、ＭＢＳベアラを介してＰＤＣＰパケットを受信すると、受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮ“ｎ”でＰＤＣＰ変数を更新する。
　ステップＳ１０９において、ｇＮＢ２００は、ＭＢＳベアラを介してＰＤＣＰパケットをＰＴＭで送信する。このＰＤＣＰパケットのＰＤＣＰヘッダに含まれるＰＤＣＰ　ＳＮは“ｎ＋１”であるとする。
　ステップＳ１１０において、ＵＥ１００ＢのＰＤＣＰエンティティは、ＭＢＳベアラを介してＰＤＣＰパケットを受信すると、受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮ“ｎ＋１”でＰＤＣＰ変数を更新する。
　ステップＳ１１１において、ＵＥ１００ＡのＰＤＣＰエンティティは、ＭＢＳベアラを介してＰＤＣＰパケットを受信すると、受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮ“ｎ＋１”でＰＤＣＰ変数を更新する。
　本動作例では、受信したＰＤＣＰパケットから各ＰＤＣＰ変数の初期値を更新したが、これに限らない。各ＰＤＣＰ変数の初期値は、ｇＮＢ２００からＵＥ１００に設定されてもよい。例えば、ＭＢＳ途中受信を行うＵＥ１００Ｂは、ｄｅｄｉｃａｔｅｄ　ｓｉｇｎａｌｌｉｎｇでＭＢＳ受信設定が行われる際に、各ＰＤＣＰ変数の初期値がｇＮＢ２００から与えられてもよい。
　（ＰＤＣＰの動作例２）
　次に、一実施形態に係るＰＤＣＰの動作例２について、上述の動作例１との相違点を主として説明する。
　上述の動作例１では、ＵＥ１００が管理するＰＤＣＰ変数として主としてＰＤＣＰ　ＳＮを想定していた。本動作例２では、ＵＥ１００がハイパーフレーム番号（ＨＦＮ）もＰＤＣＰ変数として管理する一例について説明する。ＨＦＮは、ＰＤＣＰ　ＳＮが一周（ｗｒａｐ　ａｒｏｕｎｄ）するとインクリメントされる。すなわち、ＨＦＮは、ＰＤＣＰ　ＳＮが一周する度にカウントアップされる値である。
　例えば、ＵＥ１００は、ＰＤＣＰ　ＳＮ及びＨＦＮからなるカウント値であるＣＯＵＮＴを管理する。ＲＸ＿ＤＥＬＩＶのフォーマットはＣＯＵＮＴと同じであり、ＨＦＮ＋ＳＮである。また、ＣＯＵＮＴは、セキュリティのためのＰＤＣＰパケットの暗号化にも用いられる。
　上述の動作例１では、ＭＢＳセッションに途中から参加するＵＥ１００Ｂは、このＭＢＳセッションで最初に受信したＰＤＣＰパケット（ＰＤＣＰ　ＰＤＵ）のヘッダに含まれるＰＤＣＰ　ＳＮからＲＸ＿ＤＥＬＩＶを算出していた。ここで、ＰＤＣＰ　ＰＤＵのヘッダには、ＰＤＣＰ　ＳＮが含まれているが、ＨＦＮは含まれていない。
　ＲＸ＿ＤＥＬＩＶの初期値は０であり、ユニキャストの場合はｇＮＢ２００及びＵＥ１００双方が初期値をベースにＰＤＣＰ　ＳＮのｗｒａｐ　ａｒｏｕｎｄ毎にＨＦＮをインクリメントすることで、ｇＮＢ２００及びＵＥ１００のＨＦＮは同期する。他方、マルチキャストの場合、上述のように、ＵＥ１００はどのＲＸ＿ＤＥＬＩＶからＰＤＣＰパケットを受信し始めるかが不定であるため、受信したＰＤＣＰパケットだけを見ても有効なＨＦＮ（すなわち、ｇＮＢ２００が管理しているＨＦＮ）が分からないという問題がある。
　本動作例２において、ＵＥ１００のＰＤＣＰエンティティは、ＰＤＣＰ　ＳＮ及びＨＦＮからなるＣＯＵＮＴを用いて暗号化され、ＭＢＳセッションで伝送されるＰＤＣＰパケットをｇＮＢ２００から受信する。ＵＥ１００のＰＤＣＰエンティティは、ＨＦＮを推測することで推測ＨＦＮを生成する。ＵＥ１００のＰＤＣＰエンティティは、受信したＰＤＣＰパケットに含まれるＰＤＣＰ　ＳＮと推測ＨＦＮとからなる推測ＣＯＵＮＴを用いて、ＰＤＣＰパケットの復号を試みる。ＵＥ１００のＰＤＣＰエンティティは、復号に成功した場合、推測ＨＦＮを有効なＨＦＮとして決定する。
　これにより、ＵＥ１００は、ＭＢＳセッションに途中から参加した場合であっても、ＰＤＣＰのセキュリティ機能を利用して有効なＨＦＮを導出できる。このようにして導出されたＨＦＮを用いてＣＯＵＮＴを管理することにより、ＲＸ＿ＤＥＬＩＶ等のＰＤＣＰ変数を適切に管理可能である。
　本動作例２において、ＵＥ１００は、ＨＦＮの値域を示す値域情報（以下、「ＨＦＮ値域情報」と呼ぶ）をｇＮＢ２００から受信してもよい。ＵＥ１００のＰＤＣＰエンティティは、受信したＨＦＮ値域情報に基づいて推測ＨＦＮを生成してもよい。例えば、受信したＨＦＮ値域情報が示す値域に含まれるＨＦＮを推測ＨＦＮとして生成する。暗号化されたＰＤＣＰパケットの復号には演算処理が必要となるため、ＵＥ１００の消費電力や応答時間に課題がある。よって、取り得るＨＦＮを予めｇＮＢ２００がＵＥ１００に通知しておくことで、ＵＥ１００のＰＤＣＰエンティティが生成する推測ＨＦＮの候補数を減らし、ＵＥ１００の消費電力や応答時間を低減できる。
　なお、ｇＮＢ２００がＨＦＮの値そのものをＵＥ１００に通知する方法も考えられる。しかしながら、ＨＦＮは、ＰＤＣＰ　ＳＮのカウントアップに応じてカウントアップされる。ｇＮＢ２００が現在のＨＦＮをＵＥ１００に通知してＵＥ１００がこのＨＦＮを適用するまでには遅延が生じ得るため、ｇＮＢ２００及びＵＥ１００間でＨＦＮが非同期になり得る。
　図１１は、一実施形態に係るＰＤＣＰの動作例２を示す図である。ＵＥ１００は、上述の動作例１のＵＥ１００Ｂ、すなわち、ＭＢＳセッションに途中から参加したＵＥ１００であるものとする。
　図１１に示すように、ステップＳ２０１において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションでｇＮＢ２００から伝送（例えば、ＰＴＭ伝送）されるＰＤＣＰパケットを受信する。
　ステップＳ２０２において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ２０１で受信したＰＤＣＰパケットのヘッダに含まれるＰＤＣＰ　ＳＮを取得する。ＵＥ１００が途中からＭＢＳセッションに参加しているため、このＰＤＣＰ　ＳＮの値はゼロではないものとする。
　ステップＳ２０３において、ＵＥ１００は、ｇＮＢ２００からＨＦＮ値域情報を受信してもよい。ｇＮＢ２００は、あるＭＢＳセッションについて、取り得るＨＦＮの範囲（値域）を通知する。値域は、ＭＢＳで送信するデータ量などにより決定されてもよい。なお、ステップＳ２０３は、ステップＳ２０２よりも前に行われてもよい。
　ＨＦＮ値域情報は、ＨＦＮの値域（例えば、“０～１０”）を直接的に示す情報であってもよい。また、ＨＦＮ値域情報は、ＨＦＮのビット数（例えば、“３ビット”：“０～７”と等価）を示す情報であってもよい。ＨＦＮ値域情報が“３ビット”と指定された場合、ＵＥ１００のＰＤＣＰエンティティは、“７”の次は“０”になるようにＨＦＮを管理してもよい。
　ｇＮＢ２００からＵＥ１００へのＨＦＮ値域情報の通知には、ＳＩＢ、ＭＣＣＨ（マルチキャスト制御チャネル）、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、又はＰＤＣＰ　Ｃｏｎｔｒｏｌ　ＰＤＵが用いられてもよい。これらのメッセージには、ＨＦＮ値域情報と、このＨＦＮ値域情報と対応付けられたＭＢＳセッション識別子（例えば、ＴＭＧＩ、Ｇ－ＲＮＴＩ）とが含まれていてもよい。これらのメッセージには、ＨＦＮ値域情報とＭＢＳセッション識別子とのセットが複数含まれていてもよい。
　ステップＳ２０４において、ＵＥ１００のＰＤＣＰエンティティは、推測ＨＦＮを生成する。ＵＥ１００のＰＤＣＰエンティティは、例えば、０、１、２…といった順番でＨＦＮに値を代入することで推測ＨＦＮを生成する。ステップＳ２０３でＨＦＮ値域情報を受信している場合、ＵＥ１００のＰＤＣＰエンティティは、ＨＦＮ値域情報が示す値域内において推測ＨＦＮを生成する。
　ステップＳ２０５において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ２０２で取得したＰＤＣＰ　ＳＮとステップＳ２０４で生成した推測ＨＦＮとからなる推測ＣＯＵＮＴを生成する。
　ステップＳ２０６において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ２０５で生成した推測ＣＯＵＮＴを用いて、ステップＳ２０１で受信したＰＤＣＰパケットの復号（暗号化解除）を試みる。ＰＤＣＰパケットの復号に失敗した場合（ステップＳ２０７：ＮＯ）、ステップＳ２０４に処理を戻す。
　ＰＤＣＰパケットの復号に成功した場合（ステップＳ２０７：ＹＥＳ）、ステップＳ２０８において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ２０４で生成した推測ＨＦＮを有効なＨＦＮとして決定し、このＨＦＮを記憶及び管理する。これにより、ｇＮＢ２００及びＵＥ１００間のＨＦＮが同期する。
　なお、図１１に示す動作の後、ＵＥ１００は、ｇＮＢ２００の第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行う場合がある。ＵＥ１００が第１セルにおいて受信していたＭＢＳセッションが第２セルにおいても提供される場合、ＵＥ１００は、ハンドオーバ、ＲＲＣ再確立、又はセル再選択を行っても、ＭＢＳ受信を継続できる。なお、第１セル及び第２セルは、互いに異なるｇＮＢ２００により管理されていてもよい。
　ここで、第１セル及び第２セルにおいて、ＰＤＣＰ　ＳＮはセル間で同期しているが、ＨＦＮはセル間で同期していない可能性がある。このため、ＵＥ１００は、第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行ったことに基づいて、第２セルにおいて図１１と同様な動作を再実行してもよい。
　ＵＥ１００は、第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行うよりも前において、図１１と同様な動作の再実行の要否を示す情報をｇＮＢ２００から受信してもよい。再実行が不要であることを当該情報が示す場合、第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行っても、管理しているＨＦＮを破棄せずに保持してもよい。これにより、ＨＦＮが第１セル及び第２セル間で同期しているような場合、ＵＥ１００は、図１１と同様な動作を再実行しなくても済む。このような動作の詳細については、動作例６において後述する。
　（ＰＤＣＰの動作例３）
　次に、一実施形態に係るＰＤＣＰの動作例３について、上述の動作例１及び２との相違点を主として説明する。
　上述のように、ＰＤＣＰ　ＳＮがｗｒａｐ　ａｒｏｕｎｄした際にＨＦＮがカウントアップされるため、ＰＤＣＰ　ＳＮがｗｒａｐ　ａｒｏｕｎｄしても問題無い。他方、ＨＦＮはｗｒａｐ　ａｒｏｕｎｄが想定されていない（すなわち、ＣＯＵＮＴはｗｒａｐ　ａｒｏｕｎｄしない）。このため、ＨＦＮがｗｒａｐ　ａｒｏｕｎｄしそうになった場合、ＨＦＮを含むＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を初期化できることが望ましい。
　動作例３において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、当該ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新する。ＵＥ１００のＰＤＣＰエンティティは、当該ＭＢＳセッションが中断された後にＭＢＳセッションが再開された場合、更新されたＰＤＣＰ変数を初期化する（すなわち、ゼロに戻す）。このように、動作例３においては、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションの再開をトリガとしてＰＤＣＰ変数を初期化する。これにより、例えばＨＦＮがｗｒａｐ　ａｒｏｕｎｄしそうになった場合、ＨＦＮを含むＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を初期化できる。
　図１２は、一実施形態に係るＰＤＣＰの動作例３を示す図である。ＵＥ１００は、ＭＢＳセッションに最初から参加したＵＥ１００であってもよい。また、ＵＥ１００は、ＭＢＳセッションに途中から参加したＵＥ１００であってもよい。ｇＮＢ２００は、ＲＲＣコネクティッド状態にある複数のＵＥ１００に対してマルチキャストでＭＢＳデータを送信してもよい。
　図１２に示すように、ステップＳ３０１において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションでｇＮＢ２００から伝送（例えば、ＰＴＭ伝送）されるＰＤＣＰパケットを受信する。
　ステップＳ３０２において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ３０１で受信したＰＤＣＰパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。更新されるＰＤＣＰ変数は、ＲＸ＿ＮＥＸＴ及び／又はＲＸ＿ＤＥＬＩＶであってもよい。
　ステップＳ３０３において、ｇＮＢ２００は、当該ＭＢＳセッションの中断を示すセッション中断通知をＵＥ１００に送信してもよい。セッション中断通知は、ＭＡＣ　ＣＥで送信されてもよい。セッション中断通知は、ＳＩＢ、ＭＣＣＨ（マルチキャスト制御チャネル）、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、又はＰＤＣＰ　Ｃｏｎｔｒｏｌ　ＰＤＵで送信されてもよい。ＵＥ１００は、セッション中断通知の受信に応じてＭＢＳセッションの中断を検知する。或いは、ＵＥ１００は、セッション中断通知にかかわらず、ある一定時間にわたって当該ＭＢＳセッションでＭＢＳデータを受信しない場合、ＭＢＳセッションが中断されたと判断してもよい。この一定期間を定めるタイマ値は、例えばｇＮＢ２００からＵＥ１００に設定されてもよい。ｇＮＢ２００は、このタイマ値とＭＢＳセッション識別子（例えば、ＴＭＧＩ、Ｇ－ＲＮＴＩ）とのセットをＵＥ１００に設定してもよい。
　その後、ステップＳ３０４において、ｇＮＢ２００は、当該ＭＢＳセッションの再開を示すセッション再開通知をＵＥ１００に送信してもよい。セッション再開通知は、ＭＡＣ　ＣＥで送信されてもよい。セッション再開通知は、ＳＩＢ、ＭＣＣＨ（マルチキャスト制御チャネル）、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、又はＰＤＣＰ　Ｃｏｎｔｒｏｌ　ＰＤＵで送信されてもよい。ＵＥ１００は、セッション再開通知の受信に応じてＭＢＳセッションの再開を検知する。或いは、ＵＥ１００は、セッション再開通知にかかわらず、ＭＢＳセッションが中断されたと判断した後に、当該ＭＢＳセッションでＭＢＳデータを受信した場合、ＭＢＳセッションが再開されたと判断してもよい。
　ステップＳ３０５において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションが中断された後に当該ＭＢＳセッションが再開された場合、当該ＭＢＳセッションと対応付けられた更新されたＰＤＣＰ変数を初期化する（すなわち、ゼロに戻す）。同様に、ｇＮＢ２００は、当該ＭＢＳセッションと対応付けられた更新されたＰＤＣＰ変数を初期化してもよい。
　ステップＳ３０６において、ＵＥ１００のＰＤＣＰエンティティは、当該ＭＢＳセッションでｇＮＢ２００から伝送されるＰＤＣＰパケットを受信する。
　ステップＳ３０７において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ３０６で受信したＰＤＣＰパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。
　本動作例３において、ＵＥ１００は、ステップＳ３０３でＭＢＳセッションの中断を検知した時に、ＰＤＣＰ変数を初期化してもよい。
　本動作例３において、ＵＥ１００は、ステップＳ３０３でＭＢＳセッションの中断を検知した時、もしくはＳ３０４でＭＢＳセッションの再開を検知した場合、ステップＳ３０５において、ＰＤＣＰエンティティを再確立（ｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）してもよい。ＵＥ１００においてＲＲＣレイヤがＰＤＣＰレイヤにＰＤＣＰエンティティのｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔを指示してもよい。ＰＤＣＰエンティティがｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔされると、当該ＰＤＣＰエンティティが管理するＰＤＣＰ変数は初期化される。
　（ＰＤＣＰの動作例４）
　次に、一実施形態に係るＰＤＣＰの動作例４について、上述の動作例１乃至３との相違点を主として説明する。
　上述の動作例３において、ＵＥ１００がＰＤＣＰ変数を自発的に初期化する一例について説明した。これに対し、本動作例４において、ＵＥ１００は、ｇＮＢ２００からの指示の受信に従ってＰＤＣＰ変数を初期化する。
　例えば、あるＭＢＳセッションについて複数のＵＥ１００がマルチキャストでｇＮＢ２００からＭＢＳデータを受信している状況下で、当該複数のＵＥ１００のうち１つのＵＥ１００がハンドオーバ又はＲＲＣ再確立を行ったと仮定する。通常は、ＵＥ１００のハンドオーバ又はＲＲＣ再確立に伴って当該ＵＥ１００のＰＤＣＰエンティティが再確立されるため、当該ＰＤＣＰエンティティが管理するＰＤＣＰ変数は初期化されることになる。もしくは、上述のＰＤＣＰ動作例３で説明したように、ＭＢＳセッションのＣＯＵＮＴが上限に達する前に（すなわちｗｒａｐ　ａｒｏｕｎｄしそうになった場合に）、当該ＭＢＳセッションを受信している１つ又は複数のＵＥのＰＤＣＰ変数を初期化する必要がある。
　本動作例４において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、当該ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新する。ＵＥ１００のＰＤＣＰエンティティは、ｇＮＢ２００からＰＤＣＰ変数の初期化指示を受信した場合、更新されたＰＤＣＰ変数を初期化する（すなわち、ゼロに戻す）。これにより、例えばＨＦＮがｗｒａｐ　ａｒｏｕｎｄしそうになった場合、ＨＦＮを含むＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を初期化できる。なお、上述のように、ＰＤＣＰエンティティが再確立（ｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）されるとＰＤＣＰ変数が初期化されるため、ＰＤＣＰ変数を初期化するための指示は、ＰＤＣＰエンティティの再確立指示であってもよい。
　図１３は、一実施形態に係るＰＤＣＰの動作例４を示す図である。ＵＥ１００は、ＭＢＳセッションに最初から参加したＵＥ１００であってもよい。また、ＵＥ１００は、ＭＢＳセッションに途中から参加したＵＥ１００であってもよい。ｇＮＢ２００は、ＲＲＣコネクティッド状態にある複数のＵＥ１００に対してマルチキャストでＭＢＳデータを送信してもよい。ｇＮＢ２００は、ＲＲＣアイドル又はインアクティブ状態にある複数のＵＥ１００に対してマルチキャストでＭＢＳデータを送信してもよい。
　図１３に示すように、ステップＳ４０１において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションでｇＮＢ２００から伝送（例えば、ＰＴＭ伝送）されるＰＤＣＰパケットを受信する。
　ステップＳ４０２において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ４０１で受信したＰＤＣＰパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。更新されるＰＤＣＰ変数は、ＲＸ＿ＮＥＸＴ及び／又はＲＸ＿ＤＥＬＩＶであってもよい。同様に、ｇＮＢ２００のＰＤＣＰエンティティは、ステップＳ４０１で送信したパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。
　その後、ステップＳ４０３において、ｇＮＢ２００は、ＰＤＣＰ変数の初期化を指示する初期化指示をＵＥ１００に送信する。上述のように、初期化指示は、ＰＤＣＰエンティティのｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ指示であってもよい。ｇＮＢ２００は、初期化指示を送信する前に、ＰＤＣＰパケットの送信を停止（一旦停止）してもよい。ｇＮＢ２００は、ｇＮＢ２００のＰＤＣＰエンティティのＰＤＣＰ変数がｗｒａｐ　ａｒｏｕｎｄしそうになったこと（例えば、ＣＯＵＮＴ上限値に達したこと）に応じて、当該初期化指示を送信してもよい。初期化指示は、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、ＰＤＣＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ、ＳＩＢ、又はＭＣＣＨ（マルチキャスト制御チャネル）で送信されてもよい。初期化指示は、ＭＡＣ　ＣＥ(Ｃｏｎｔｒｏｌ　Ｅｌｅｍｅｎｔ)又はＭＴＣＨ（マルチキャストトラフィックチャネル）で送信されてもよい。なお、初期化指示は、複数のＵＥに一斉に通知されることが望ましい。例えば、マルチキャストされるＭＴＣＨを含むトランスポートブロックに、初期化指示を示すＭＡＣ　ＣＥを多重して通知してもよい。これらのメッセージには、初期化指示と、この初期化指示と対応付けられたＭＢＳセッション識別子（例えば、ＴＭＧＩ、Ｇ－ＲＮＴＩ、セッションＩＤ）とが含まれていてもよい。このＭＢＳセッション識別子に加えて、又はＭＢＳセッション識別子に代えて、ベアラＩＤ（もしくはＭＢＳベアラＩＤ）を用いてもよい。
　なお、ｇＮＢ２００は、ＵＥ１００と同じＭＢＳセッションをマルチキャストで受信する他のＵＥ１００がＰＤＣＰエンティティを再確立したこと、すなわち、当該他のＵＥ１００がＰＤＣＰ変数を初期化したことに応じて、ステップＳ４０３の初期化指示の送信を行ってもよい。これにより、同じＭＢＳセッションを受信する複数のＵＥ１００がいずれもＰＤＣＰ変数を初期化することになる。
　ステップＳ４０４において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ４０３で初期化指示を受信したことに応じて、当該ＭＢＳセッションと対応付けられた更新されたＰＤＣＰ変数を初期化する（すなわち、ゼロに戻す）。同様に、ｇＮＢ２００は、当該ＭＢＳセッションと対応付けられた更新されたＰＤＣＰ変数を初期化してもよい。当該ＰＤＣＰ変数の初期化は、ＰＤＣＰエンティティのｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔで実行されてもよい。
　ステップＳ４０５において、ＵＥ１００のＰＤＣＰエンティティは、当該ＭＢＳセッションでｇＮＢ２００から伝送されるＰＤＣＰパケットを受信する。ｇＮＢ２００は、マルチキャストを受信する全てのＵＥのＰＤＣＰ変数の初期化が完了したことに応じて、ＰＤＣＰパケットの送信を再開してもよい。
　ステップＳ４０６において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ４０６で受信したＰＤＣＰパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。
　なお、上述の動作例３についても、動作例４と同様に、同じＭＢＳセッションを受信する複数のＵＥ１００のうち１つのＵＥ１００がＰＤＣＰエンティティを再確立した際に、当該複数のＵＥ１００のうち他のＵＥ１００がＰＤＣＰ変数を初期化するように動作してもよい。例えば、ｇＮＢ２００は、同じＭＢＳセッションを受信する複数のＵＥ１００のうち１つのＵＥ１００がＰＤＣＰエンティティを再確立した際に、当該ＭＢＳセッションを中断し、その後に当該ＭＢＳセッションを再開する。これにより、同じＭＢＳセッションを受信する複数のＵＥ１００がいずれもＰＤＣＰ変数を初期化することになる。
　（ＰＤＣＰの動作例５）
　次に、一実施形態に係るＰＤＣＰの動作例５について、上述の動作例１乃至４との相違点を主として説明する。
　上述の動作例４において、ＵＥ１００がＰＤＣＰエンティティを再確立した場合、当該ＵＥ１００がＰＤＣＰ変数を初期化する一例について説明した。この場合、上述のように、同じＭＢＳセッションをマルチキャストで受信する他のＵＥ１００もＰＤＣＰ変数を初期化する必要があり得る。つまり、同じＭＢＳセッションをマルチキャストで受信する１つのＵＥ１００におけるＰＤＣＰエンティティの再確立が他のＵＥ１００に悪影響を与えることになり得る。
　このため、本動作例５において、ＭＢＳセッション（ＭＢＳベアラ）用のＰＤＣＰについては、ＰＤＣＰエンティティを再確立しても、ＰＤＣＰ変数を初期化せずに、再確立前のＰＤＣＰ変数を継続して使用するものとする。すなわち、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新する。ＵＥ１００は、ＰＤＣＰエンティティが再確立された場合、ＭＢＳセッションと対応付けられたＰＤＣＰ変数を初期化せずに保持する。ＵＥ１００のＰＤＣＰエンティティは、保持されたＰＤＣＰ変数に基づいて、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信処理（ＰＤＣＰ動作）を継続する。これにより、同じＭＢＳセッションをマルチキャストで受信する１つのＵＥ１００におけるＰＤＣＰエンティティの再確立が他のＵＥ１００に悪影響を与えることを防止できる。
　図１４は、一実施形態に係るＰＤＣＰの動作例４を示す図である。ＵＥ１００は、ＭＢＳセッションに最初から参加したＵＥ１００であってもよい。また、ＵＥ１００は、ＭＢＳセッションに途中から参加したＵＥ１００であってもよい。ｇＮＢ２００は、ＲＲＣコネクティッド状態にある複数のＵＥ１００に対してマルチキャストでＭＢＳデータを送信してもよい。
　図１４に示すように、ステップＳ５０１において、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションでｇＮＢ２００から伝送（例えば、ＰＴＭ伝送）されるＰＤＣＰパケットを受信する。
　ステップＳ５０２において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ４０１で受信したＰＤＣＰパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。更新されるＰＤＣＰ変数は、ＲＸ＿ＮＥＸＴ及び／又はＲＸ＿ＤＥＬＩＶであってもよい。
　ステップＳ５０３において、ＵＥ１００は、ハンドオーバ又はＲＲＣ再確立に伴ってＰＤＣＰエンティティを再確立する。すなわち、ＵＥ１００は、ハンドオーバ又はＲＲＣ再確立を行う前の古いＰＤＣＰエンティティを削除し、新たなＰＤＣＰエンティティを生成する。但し、古いＰＤＣＰエンティティが更新していたＰＤＣＰ変数は所定の記憶領域に保持されることが可能であるものとする。なお、ＵＥ１００は、ＰＤＣＰエンティティの再確立を指示する再確立指示をｇＮＢ２００から受信し、この再確立指示の受信に応じてＰＤＣＰエンティティを再確立してもよい。
　ステップＳ５０４において、ＵＥ１００は、再確立に係るＰＤＣＰエンティティがＭＢＳセッションと対応付けられているか否かを判定する。ＵＥ１００は、再確立に係るＰＤＣＰエンティティが、ＰＤＣＰ変数を初期化せずに保持するように設定されているか否かを判定してもよい。このような設定は、ｇＮＢ２００からＵＥ１００に対して例えばＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにより行われていてもよい。ＵＥ１００は、ＰＤＣＰエンティティの再確立を指示する再確立指示をｇＮＢ２００から受信する場合、ＰＤＣＰ変数を初期化せずに保持することを示す情報（例えば、“ＣＯＵＮＴ－ｃｏｎｔｉｎｕｅｄ＝ｔｒｕｅ”）が再確立指示に含まれるか否かを判定してもよい。ステップＳ５０４で「ＮＯ」である場合、ステップＳ５０５において、ＵＥ１００は、ステップＳ５０２で更新されたＰＤＣＰ変数を初期化する。
　ステップＳ５０４で「ＹＥＳ」である場合、ステップＳ５０６において、ＵＥ１００は、ステップＳ５０２で更新されたＰＤＣＰ変数を初期化せずに保持する。すなわち、ＵＥ１００は、所定の記憶領域に保持されたＰＤＣＰ変数を再確立に係る新たなＰＤＣＰエンティティに再度設定する。
　ステップＳ５０７において、ＵＥ１００のＰＤＣＰエンティティは、当該ＭＢＳセッションでｇＮＢ２００から伝送されるＰＤＣＰパケットを受信する。
　ステップＳ５０８において、ＵＥ１００のＰＤＣＰエンティティは、ステップＳ５０７で受信したＰＤＣＰパケットに基づいてＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する。
　なお、ＵＥ１００は、ｇＮＢ２００の第１セルから第２セルへのハンドオーバ又はＲＲＣ再確立を行ったことに応じて、ＰＤＣＰエンティティを再確立してもよい（ステップＳ５０３）。ＵＥ１００は、ハンドオーバ又はＲＲＣ再確立を行うよりも前において、ＰＤＣＰ変数を第２セルにおいて継続して使用可能であることをｇＮＢ２００から通知されている場合、ハンドオーバ又はＲＲＣ再確立を行ってもＰＤＣＰ変数を初期化せずに保持してもよい。このような通知情報は、ｇＮＢ２００が第１セルにおいてＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＳＩＢでＵＥ１００に送信してもよい。このような動作に関連する動作について動作例６で後述する。
　（ＰＤＣＰの動作例６）
　次に、一実施形態に係るＰＤＣＰの動作例６について、上述の動作例１乃至５との相違点を主として説明する。図１５は、一実施形態に係るＰＤＣＰの動作例６を説明するための図である。
　図１５に示すように、ＵＥ１００は、セルＣ１（第１セル）からセルＣ２（第２セル）へのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行う場合がある。図１５において、セルＣ１を管理するｇＮＢ２００ＡとセルＣ２を管理するｇＮＢ２００Ｂとが異なる一例を図示している。
　ＵＥ１００がセルＣ１において受信していたＭＢＳセッションがセルＣ２においても提供される場合、ＵＥ１００は、ハンドオーバ、ＲＲＣ再確立、又はセル再選択を行っても、ＭＢＳ受信を継続できる。ここで、セルＣ１及びセルＣ２において、ＰＤＣＰ　ＳＮがセル間で同期していても、ＨＦＮはセル間で同期していない可能性がある。セルＣ１及びセルＣ２においてＨＦＮが同期していない場合、ＵＥ１００は、セルＣ１からセルＣ２へ移動した際に、セルＣ２におけるＨＦＮ、すなわち、ｇＮＢ２００Ｂが管理するＨＦＮとの同期をとる必要がある。
　本動作例６において、第１に、ＵＥ１００のＰＤＣＰエンティティは、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、ＭＢＳセッションと対応付けられたＰＤＣＰ変数（例えば、ＣＯＵＮＴ）を更新する（ステップＳ６０１）。更新されるＰＤＣＰ変数は、ＲＸ＿ＮＥＸＴ及び／又はＲＸ＿ＤＥＬＩＶであってもよい。
　第２に、ＵＥ１００は、セルＣ１からセルＣ２へのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行うよりも前において、更新されたＰＤＣＰ変数をセルＣ２において継続して使用可能であるか否かを示す通知情報をｇＮＢ２００Ａから受信する（ステップＳ６０２）。なお、ｇＮＢ２００Ａは、例えばｇＮＢ２００Ｂとの基地局間通信により、セルＣ１及びセルＣ２間でＨＦＮが同期しているか否かを把握しているものとする。ｇＮＢ２００Ａは、セルＣ１及びセルＣ２間でＨＦＮが同期している場合、更新されたＰＤＣＰ変数をセルＣ２において継続して使用可能であることを示す通知情報を送信する。他方、セルＣ１及びセルＣ２間でＨＦＮが同期していない場合、ｇＮＢ２００Ａは、更新されたＰＤＣＰ変数をセルＣ２において継続して使用不可であることを示す通知情報を送信する。ｇＮＢ２００Ａは、ＳＩＢ、ＭＣＣＨ、ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ、ＰＤＣＰ　Ｃｏｎｔｒｏｌ　ＰＤＵで通知情報を送信してもよい。
　通知情報は、更新されたＰＤＣＰ変数を継続して使用可能な１つ又は複数のセルからなるエリアを示す情報を含んでもよい。例えば、通知情報は、セルＣ１で用いていたＰＤＣＰ変数を使いまわすことが可能なセルのセルＩＤからなるセルＩＤリストを含んでもよい。
　第３に、ＵＥ１００は、セルＣ１からセルＣ２へのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行う（ステップＳ６０３）。ここで、ＵＥ１００のＰＤＣＰエンティティは、セルＣ１で用いていたＰＤＣＰ変数（例えば、ＣＯＵＮＴ）をセルＣ２でも使用可能であることを通知情報が示す場合、保持しているＰＤＣＰ変数をセルＣ２において継続して使用し、セルＣ２からＰＤＣＰパケットを受信する（ステップＳ６０４）。他方、セルＣ１で用いていたＰＤＣＰ変数をセルＣ２で使用不可であることを通知情報が示す場合、ＵＥ１００のＰＤＣＰエンティティは、セルＣ２において最初に受信したＰＤＣＰパケットからＰＤＣＰ変数を導出する（上述の動作例１参照）。或いは、ＵＥ１００は、セルＣ２で使用中のＨＦＮがｇＮＢ２００Ｂから通知される場合、通知されたＨＦＮを用いてＰＤＣＰ変数を導出してもよい。
　（ＲＬＣの動作例）
　次に、一実施形態に係るＲＬＣの動作例について説明する。図１６及び図１７は、一実施形態に係るＲＬＣの動作例を説明するための図である。本動作例において、ＵＥ１００のＲＬＣエンティティは、ＭＢＳセッションで伝送され、ｇＮＢ２００がＲＬＣ　ＳＤＵ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ｕｎｉｔ）を分割して得られたＲＬＣ　ＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）をｇＮＢ２００から受信する。
　図１６に示すように、本動作例において、ｇＮＢ２００のＲＬＣエンティティがＰＤＣＰパケット（すなわち、ＲＬＣ　ＳＤＵ）の分割処理を行うものとする（ステップＳ７０１）。このような分割処理はＳｅｇｍｅｎｔａｔｉｏｎと呼ばれることがある。ｇＮＢ２００のＲＬＣエンティティは、分割処理により得た各セグメントにシーケンス番号（ＳＮ）を割り振ってＲＬＣ　ＰＤＵを得る。図１６において、ＳＮ＃０乃至＃５の合計６つのＲＬＣ　ＰＤＵ（６つのセグメント）に分割される一例を図示している。ＵＥ１００のＲＬＣエンティティは、これら６つのＲＬＣ　ＰＤＵのすべてを受信しないと、元のＰＤＣＰパケット（ＲＬＣ　ＳＤＵ）を再構築できない。このような再構築処理はＲｅａｓｓｅｍｂｌｙと呼ばれることがある。なお、本動作例において、ＲＬＣには、ＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ）モードが適用されるものとする。
　ユニキャストの場合は、ＵＥ１００は最初のＲＬＣ　ＰＤＵ（すなわち、ＳＮ＃０のＲＬＣ　ＰＤＵ）から受信するので、大きな問題はない。これに対し、マルチキャストの場合、ＵＥ１００はＭＢＳセッションに途中から参加することもあるため、必ずしもＳＮ＃０のＲＬＣ　ＰＤＵから受信できるとは限らない。ＳＮ＃０のＲＬＣ　ＰＤＵをＵＥ１００が受信できない場合、ＲＬＣ　ＳＤＵへの再構築は完了できない。再構築できないＲＬＣ　ＳＤＵは、タイマ（Ｔ－Ｒｅａｓｓｅｍｂｌｙ）が満了すると破棄されることになる。
　しかしながら、ＰＤＣＰパケット（ＲＬＣ　ＳＤＵ）を順序通りに上位レイヤ（すなわち、ＰＤＣＰ）に渡すｉｎ－ｏｒｄｅｒ　ｄｅｌｉｖｅｒｙが設定されている場合、再構築用のタイマ（Ｔ－Ｒｅａｓｓｅｍｂｌｙ）が満了するまで次のＰＤＣＰパケットを上位レイヤに渡せないことから、遅延が発生するという問題がある。
　本動作例において、ＭＢＳセッションに途中から参加したＵＥ１００のＲＬＣエンティティは、ｇＮＢ２００から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号がゼロである場合、当該最初に受信したＲＬＣ　ＰＤＵ及び当該最初に受信したＲＬＣ　ＰＤＵに後続するＲＬＣ　ＰＤＵからＲＬＣ　ＳＤＵを再構築する。図１６において、ＵＥ１００のＲＬＣエンティティは、最初のＲＬＣ　ＰＤＵ（すなわち、ＳＮ＃０のＲＬＣ　ＰＤＵ）から受信できている（ステップＳ７０２）。よって、ＵＥ１００のＲＬＣエンティティは、ＳＮ＃０乃至＃５のＲＬＣ　ＰＤＵが揃った時点でＲＬＣ　ＳＤＵを再構築し（ステップＳ７０３）、ＲＬＣ　ＳＤＵを上位レイヤ（すなわち、ＰＤＣＰ）に渡す。
　他方、図１７に示すように、ｇＮＢ２００から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号がゼロではない場合、ＵＥ１００のＲＬＣエンティティは、当該最初に受信したＲＬＣ　ＰＤＵ及び最初に受信したＲＬＣ　ＰＤＵ後続するＲＬＣ　ＰＤＵを破棄する。具体的には、ｇＮＢ２００から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号がゼロではない場合、ＵＥ１００のＲＬＣエンティティは、タイマ（Ｔ－Ｒｅａｓｓｅｍｂｌｙ）が満了していなくても、当該最初に受信したＲＬＣ　ＰＤＵ及び最初に受信したＲＬＣ　ＰＤＵに後続するＲＬＣ　ＰＤＵを破棄する。このように、ｇＮＢ２００から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号に基づいて、当該最初に受信したＲＬＣ　ＰＤＵ及び当該最初に受信したＲＬＣ　ＰＤＵに後続するＲＬＣ　ＰＤＵからＲＬＣ　ＳＤＵを再構築するか否かを決定することにより、再構築できないパケットを早期に破棄できるため、遅延の発生を抑制できる。
　図１７に示す例において、ＭＢＳセッションに途中から参加したＵＥ１００のＲＬＣエンティティは、ｇＮＢ２００から最初に受信したＲＬＣ　ＰＤＵのシーケンス番号を確認し、このシーケンス番号がＳＮ＃２であることを検知する（ステップＳ７１１）。この場合、ＵＥ１００のＲＬＣエンティティは、タイマ（Ｔ－Ｒｅａｓｓｅｍｂｌｙ）が満了していなくても、当該ＳＮ＃２のＲＬＣ　ＰＤＵ及び後続するＳＮ＃３乃至＃５の各ＲＬＣ　ＰＤＵを破棄する。
　なお、本動作例においては、ＰＤＣＰパケット破棄を最小限にするために、ｇＮＢ２００は、ＭＢＳ送信においてＲＬＣ分割数を小さくすることが望ましい。
　（その他の実施形態）
　上述の実施形態に係るＰＤＣＰの動作例１乃至６は、ＲＬＣの動作に応用してもよい。すなわち、上述の実施形態に係るＰＤＣＰの動作例１乃至６における「ＰＤＣＰ」を「ＲＬＣ」と読み替えてもよい。
　上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよい。また、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。
　上述の実施形態において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）であってもよい。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ（Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ））として構成してもよい。
　以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本願は、米国仮出願第６３／１６７８１８号（２０２１年３月３０日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
　（付記）
　（ＰＤＣＰの動作）
・状態変数の初期値
　現在の合意ではＲＬＣ　ＵＭモードのみが規定されているが、サービスの継続性のために、ＭＢＳデータ受信の開始時及び動的なＰＴＭ／ＰＴＰ切り替え中のパケット損失を最小限に抑える方法を検討する価値がある。
　図１８に示すように、既存のＰＤＣＰファンクショナルビューを再利用する場合、ＰＤＣＰ　ＳＮは、ＰＴＭレグとＰＴＰレグの両方に共通する。ＰＴＭレグは複数のＵＥに使用されるため、ＰＤＣＰ　ＳＮはＵＥ固有ではない可能性があり、ＰＴＭレグとＰＴＰレグの両方に影響する。これは、マルチキャストセッションでＵＥが遅れて参加する場合、最初に受信したＭＢＳデータがＰＴＭレグ又はＰＴＰレグのどちらからのものであるかに関係なく、各状態変数の初期値が常に「０」になるとは限らないことを意味する。言い換えると、ＵＥが最初に受信するＰＤＣＰ　ＳＮは、現在のユニキャスト送信では想定されていない任意の値にすることができる。また、状態変数が初期値に設定されているため、１つのＵＥのＰＤＣＰ再確立が他のすべてのＵＥに影響を与える可能性がある。これにより、受信ウィンドウで予期しない動作が発生する。つまり、受信ウィンドウの外にあるＰＤＣＰ　ＰＤＵが破棄される。
　所見２：マルチキャストセッションに遅れて参加し、２つのレグが１つのＭＲＢに関連付けられている場合、最初に受信したデータがＰＴＭレグ又はＰＴＰレグからのものであるかどうかに関係なく、最初に受信したＰＤＣＰ　ＰＤＵのＳＮは初期値、つまり「０」ではない。
　この問題を解決するために、次のオプションが提案された。
　オプションＡ：ｇＮＢはＵＥに初期ＣＯＵＮＴ値、又はＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶを通知する。
　このオプションは、ｇＮＢからの情報に基づいて受信ウィンドウに関連する初期値を変更するだけで、ＵＥが既存のメカニズムでＭＢＳデータの最初の送信を受信できるようにする。ただし、ＰＤＣＰ層の観点から、例えば、切り替えの遅延、悪い無線状態、又はＲＬＣ再設定ウィンドウの外にあるために、ＵＥがｇＮＢの意図した最初の送信を常に正常に受信できるかどうかは疑わしい。この場合、このオプションがどのように機能するかは不明である。
　オプションＢ：ｇＮＢはＵＥに最初のＨＦＮを通知し、ＵＥは最初に受信したＰＤＣＰ　ＰＤＵから最初のＨＦＮとＳＮを推測する。
　ＳＮ部分に関しては、このオプションはＲｅｌ－１６のＶ２Ｘメカニズムに似ている。つまり、「ブロードキャスト及びグループキャストのＮＲサイドリンク通信の場合、ＲＸ＿ＮＥＸＴのＳＮ部分の初期値は（ｘ＋１）モジュロ（２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］）、ここでｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」及び「ブロードキャスト及びグループキャストのＮＲサイドリンク通信の場合、ＲＸ＿ＤＥＬＩＶのＳＮ部分の初期値は（ｘ-０．５×２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ-１］）モジュロ（２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］）、ここでｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」。
　ＨＦＮ部分に関しては、Ｒｅｌ－１６のＶ２Ｘメカニズムでは、送信機及び受信機を同期させる必要はない。つまり、ＨＦＮはセキュリティに使用されないため、「注：ＲＸ＿ＤＥＬＩＶの初期値が正の値になるように、ＲＸ＿ＮＥＸＴにＨＦＮを選択するのはＵＥの実装次第である。」ＮＲ　ＭＢＳの場合、「ＲＡＮ２は、ＳＡ３がＭＢＳのセキュリティに関する調査を終了するのを待ってから、ＲＡＮ２のセキュリティの側面について説明することを返信する」。したがって、この時点でＨＦＮ部分が通知される必要がある場合は、ＲＡＮ２を延期する必要がある。
　上記の所見に基づいて、オプションＢはさらなる議論のベースラインとなるはずである。ブロードキャスト及びグループキャストのＲｅｌ－１６のサイドリンク通信によると、ＮＲ　ＭＢＳのセキュリティに関するＳＡ３の進捗状況を考慮すると、ＲＡＮ２は、ＵＥがＭＢＳデータの最初に受信したＰＤＣＰ　ＰＤＵから状態変数の初期値を設定することに少なくとも同意する必要がある。
　提案３：ＲＡＮ２は、ＵＥがＰＴＭレグ又はＰＴＰレグに関係なく、最初に受信したＭＢＳデータからＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶのＳＮ部分の初期値を設定することに同意する必要がある。ＳＡ３の進捗状況に応じて、ＨＦＮ部分がｇＮＢから通知されるかどうかは更なる検討が必要である。
　（同時受信とＵＥ支援情報）
　提案２が同意できる場合、ＵＥはＰＴＭレグとＰＴＰレグの両方からの同時受信をサポートする必要がある。つまり、既存のＰＤＣＰパケットの複製と同様に２つのレグを同時にアクティブ化できる。ＰＴＰレグは複数のＵＥによって受信されるため、つまりＵＥ固有ではないため、ＰＴＭレグを介して受信されなかった欠落パケットを簡単に補うことができるため、動的なＰＴＭ／ＰＴＰ切り替えにとって有益であると考えられる。したがって、ＲＡＮ２は、動的なＰＴＭ／ＰＴＰ切り替え時に、少なくとも一定期間の同時受信に同意する必要がある。
　提案４：ＲＡＮ２は、ＵＥが動的なＰＴＭ／ＰＴＰ切り替え後の一定期間、ＰＴＭレグとＰＴＰレグの両方からの同時受信をサポートすることに同意する必要がある。
　提案３及び提案４が合意できる場合、ｇＮＢは、ＵＥがＰＴＭレグを介して正常に受信を開始したＰＤＣＰ　ＳＮを実際に認識していない可能性がある。ＰＴＰからＰＴＭへの切り替えの場合、ｇＮＢは、どのＰＤＣＰ　ＰＤＵをＰＴＰレグ経由で送信する必要があるか、及び／又はＰＴＰレグをいつ非アクティブ化できるかを認識できない可能性があることを意味する。この問題を解決するために、ＵＥがｇＮＢにＰＴＭ受信が成功したことを通知することが提案されている。これは、まだ非アクティブ化されていない場合はＰＴＰレグを介して送信できる。ただし、この解決策がＰＤＣＰ　ＳＮを情報に含めることを意図しているかどうかは不明である。
　同様に、ＰＴＭからＰＴＰへの切り替えの場合、ｇＮＢは、ＵＥがＰＴＭレグを介して受信を終了したＰＤＣＰ　ＳＮを認識しない場合がある。これは、ｇＮＢがＰＴＰレグを介して送信を開始するＰＤＣＰ　ＰＤＵを認識していない可能性があることを意味する。したがって、ＵＥは、動的なＰＴＭ／ＰＴＰ切り替え時に、アクティブ化されたＰＴＰレグを介してＳＮ情報をｇＮＢに通知すると見なすことができる。
　ＵＥがＰＴＭとＰＴＰ間の動的な切り替え時にＳＮ情報を報告する場合、ＰＤＣＰ制御ＰＤＵを再利用するのは簡単であり、正確に、ＰＤＣＰステータスレポートはＦＭＣ（最初に欠落しているＰＤＣＰ　ＳＤＵ）と任意のビットマップ（次のＰＤＣＰ　ＳＤＵが欠落しているか正しく受信されていることを示す）を含む。一方、ＰＴＭレグを介して最初／最後に成功したＰＤＣＰ　ＳＤＵ受信を報告することは別のオプションである。したがって、ＰＴＭとＰＴＰの間の動的な切り替え時に何を報告する必要があるかについてさらに議論する必要がある。
　上記のいずれの場合でも（つまり、ＰＴＰからＰＴＭへ及びＰＴＭからＰＴＰへ）、ＰＤＣＰ制御ＰＤＵは、サービス継続性のためのＰＤＣＰ　ＳＮ情報を含む動的な切り替え（例えば、アクティブ化／非アクティブ化ＭＡＣ　ＣＥによって）時にトリガされる必要がある。
　提案５：ＲＡＮ２は、サービスの継続性のために、ＵＥが動的な切り替え時にＰＤＣＰ　ＳＮ情報を含むＰＤＣＰ制御ＰＤＵを送信するかどうかを検討する必要がある。使用されるＰＤＣＰ制御ＰＤＵの種類とＳＮ情報の正確な意味については更なる検討が必要である。
１０　　　：ＮＧ－ＲＡＮ（５Ｇ　ＲＡＮ）
２０　　　：５ＧＣ（５Ｇ　ＣＮ）
１００　　：ＵＥ
１１０　　：受信部
１２０　　：送信部
１３０　　：制御部
２００　　：ｇＮＢ
２１０　　：送信部
２２０　　：受信部
２３０　　：制御部
２４０　　：バックホール通信部

Claims (12)

  1. 　基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する通信制御方法であって、
    　ＰＤＣＰシーケンス番号及びハイパーフレーム番号からなるカウント値を用いて暗号化され、ＭＢＳセッションで伝送されるＰＤＣＰパケットを前記基地局から受信することと、
    　前記ハイパーフレーム番号を推測することで推測ハイパーフレーム番号を生成することと、
    　前記受信したＰＤＣＰパケットに含まれる前記ＰＤＣＰシーケンス番号と前記推測ハイパーフレーム番号とからなる推測カウント値を用いて、前記ＰＤＣＰパケットの復号を試みることと、
    　前記復号に成功した場合、前記推測ハイパーフレーム番号を有効なハイパーフレーム番号として決定することと、を有する
    　通信制御方法。
  2. 　前記ハイパーフレーム番号の値域を示す値域情報を前記基地局から受信することをさらに有し、
    　前記生成することは、前記受信した値域情報に基づいて前記推測ハイパーフレーム番号を生成することを含む
    　請求項１に記載の通信制御方法。
  3. 　前記ユーザ装置が前記基地局の第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行ったことに基づいて、前記第２セルにおいて、前記受信すること、前記生成すること、前記試みること、及び前記決定することを再実行することをさらに有する
    　請求項１又は２に記載の通信制御方法。
  4. 　前記ハンドオーバを行うよりも前において、前記再実行の要否を示す情報を前記基地局から受信することと、
    　前記再実行が不要であることを前記情報が示す場合、前記ハンドオーバを行っても、前記管理しているハイパーフレーム番号を破棄せずに保持することと、をさらに有する
    　請求項３に記載の通信制御方法。
  5. 　基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する通信制御方法であって、
    　前記ユーザ装置のＰＤＣＰエンティティが、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、前記ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新することと、
    　前記ＭＢＳセッションが中断された場合、又は、前記ＭＢＳセッションが中断された後に前記ＭＢＳセッションが再開された場合、又は、前記基地局から前記ＰＤＣＰ変数を初期化するための指示を受信した場合、前記更新されたＰＤＣＰ変数を初期化することと、を有する
    　通信制御方法。
  6. 　基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する通信制御方法であって、
    　前記ユーザ装置のＰＤＣＰエンティティが、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、前記ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新することと、
    　前記ＰＤＣＰエンティティが再確立された場合、前記ＭＢＳセッションと対応付けられた前記ＰＤＣＰ変数を初期化せずに保持することと、
    　前記ＰＤＣＰエンティティが、前記保持されたＰＤＣＰ変数に基づいて、前記ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信処理を継続することと、を有する
    　通信制御方法。
  7. 　前記ユーザ装置が前記基地局の第１セルから第２セルへのハンドオーバ又はＲＲＣ再確立を行ったことに応じて、前記ＰＤＣＰエンティティを再確立することをさらに有し、
    　前記保持することは、前記ハンドオーバ又は前記ＲＲＣ再確立を行うよりも前において、前記ＰＤＣＰ変数を前記第２セルにおいて継続して使用可能であることを前記基地局から通知されている場合、前記ハンドオーバ又は前記ＲＲＣ再確立を行っても前記ＰＤＣＰ変数を初期化せずに保持することを含む
    　請求項６に記載の通信制御方法。
  8. 　基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する通信制御方法であって、
    　前記ユーザ装置のＰＤＣＰエンティティが、ＭＢＳセッションで伝送されるＰＤＣＰパケットの受信に応じて、前記ＭＢＳセッションと対応付けられたＰＤＣＰ変数を更新することと、
    　前記ユーザ装置が前記基地局の第１セルから第２セルへのハンドオーバ、ＲＲＣ再確立、又はセル再選択を行うよりも前において、前記更新されたＰＤＣＰ変数を前記第２セルにおいて継続して使用可能であるか否かを示す通知情報を前記基地局から受信することと、を有する
    　通信制御方法。
  9. 　前記通知情報は、前記更新されたＰＤＣＰ変数を継続して使用可能な１つ又は複数のセルからなるエリアを示す情報を含む
    　請求項８に記載の通信制御方法。
  10. 　基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて前記ユーザ装置が実行する通信制御方法であって、
    　前記ユーザ装置のＲＬＣエンティティが、ＭＢＳセッションで伝送され、前記基地局がＲＬＣ　ＳＤＵを分割して得られたＲＬＣ　ＰＤＵを前記基地局から受信することと、
    　前記基地局から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号に基づいて、前記最初に受信したＲＬＣ　ＰＤＵ及び前記最初に受信したＲＬＣ　ＰＤＵに後続するＲＬＣ　ＰＤＵから前記ＲＬＣ　ＳＤＵを再構築するか否かを決定することと、を有する
    　通信制御方法。
  11. 　前記基地局から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号がゼロである場合、前記最初に受信したＲＬＣ　ＰＤＵ及び前記最初に受信したＲＬＣ　ＰＤＵに後続するＲＬＣ　ＰＤＵから前記ＲＬＣ　ＳＤＵを再構築することと、
    　前記基地局から最初に受信したＲＬＣ　ＰＤＵに含まれるＲＬＣシーケンス番号がゼロではない場合、前記最初に受信したＲＬＣ　ＰＤＵ及び前記最初に受信したＲＬＣ　ＰＤＵ後続するＲＬＣ　ＰＤＵを破棄することと、をさらに有する
    　請求項１０に記載の通信制御方法。
  12. 　請求項１乃至１１のいずれか１項に記載の通信制御方法を実行するプロセッサを備える
    　ユーザ装置。
PCT/JP2022/016093 2021-03-30 2022-03-30 通信制御方法及びユーザ装置 WO2022210914A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023511494A JPWO2022210914A1 (ja) 2021-03-30 2022-03-30
US18/478,762 US20240040662A1 (en) 2021-03-30 2023-09-29 Communication control method and user equipment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163167818P 2021-03-30 2021-03-30
US63/167,818 2021-03-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/478,762 Continuation US20240040662A1 (en) 2021-03-30 2023-09-29 Communication control method and user equipment

Publications (1)

Publication Number Publication Date
WO2022210914A1 true WO2022210914A1 (ja) 2022-10-06

Family

ID=83459572

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/016093 WO2022210914A1 (ja) 2021-03-30 2022-03-30 通信制御方法及びユーザ装置

Country Status (3)

Country Link
US (1) US20240040662A1 (ja)
JP (1) JPWO2022210914A1 (ja)
WO (1) WO2022210914A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101742430A (zh) * 2008-11-20 2010-06-16 华为技术有限公司 数据包处理方法、装置以及基站
CN104684030A (zh) * 2013-12-02 2015-06-03 普天信息技术研究院有限公司 一种集群系统中实现安全参数同步的方法
JP2017092574A (ja) * 2015-11-04 2017-05-25 株式会社Ｎｔｔドコモ 無線通信装置
WO2017119377A1 (ja) * 2016-01-08 2017-07-13 株式会社Ｎｔｔドコモ 無線通信装置及び無線通信方法
JP2018526894A (ja) * 2015-08-06 2018-09-13 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ エンハンスドコンポーネントキャリアによるパケットデータコンバージェンスプロトコル（ｐｄｃｐ）リオーダリングのための方法、装置、およびコンピュータ可読媒体
US20190364421A1 (en) * 2017-01-10 2019-11-28 Hytera Communications Corporation Limited Decryption method for trunking group call, and user equipment

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101742430A (zh) * 2008-11-20 2010-06-16 华为技术有限公司 数据包处理方法、装置以及基站
CN104684030A (zh) * 2013-12-02 2015-06-03 普天信息技术研究院有限公司 一种集群系统中实现安全参数同步的方法
JP2018526894A (ja) * 2015-08-06 2018-09-13 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ エンハンスドコンポーネントキャリアによるパケットデータコンバージェンスプロトコル（ｐｄｃｐ）リオーダリングのための方法、装置、およびコンピュータ可読媒体
JP2017092574A (ja) * 2015-11-04 2017-05-25 株式会社Ｎｔｔドコモ 無線通信装置
WO2017119377A1 (ja) * 2016-01-08 2017-07-13 株式会社Ｎｔｔドコモ 無線通信装置及び無線通信方法
US20190364421A1 (en) * 2017-01-10 2019-11-28 Hytera Communications Corporation Limited Decryption method for trunking group call, and user equipment

Also Published As

Publication number Publication date
US20240040662A1 (en) 2024-02-01
JPWO2022210914A1 (ja) 2022-10-06

Similar Documents

Publication Publication Date Title
JP7307284B2 (ja) 通信制御方法
KR20190143782A (ko) 차세대 이동 통신 시스템에서 rrc 비활성화 모드 단말의 이중 접속을 지원하는 방법 및 장치
JP7448689B2 (ja) 通信制御方法及びユーザ装置
JP6645963B2 (ja) ユーザ端末及び移動通信システム
WO2020032129A1 (ja) 中継装置
KR20220051754A (ko) 이동 통신 시스템에서 mbs 서비스를 지원하는 방법 및 장치
WO2022085717A1 (ja) 通信制御方法
CN115516880A (zh) 动态改变多播/广播业务递送
US20230354475A1 (en) Communication control method
WO2022239690A1 (ja) 通信制御方法及びユーザ装置
JP2023100957A (ja) 通信制御方法、ユーザ装置及びプロセッサ
WO2022138450A1 (ja) 通信制御方法及びユーザ装置
WO2022210914A1 (ja) 通信制御方法及びユーザ装置
JP7469571B2 (ja) 通信方法、ユーザ装置、ネットワークノード、チップセット、及びプログラム
WO2023013671A1 (ja) 通信方法
WO2022202833A1 (ja) 通信制御方法及びユーザ装置
WO2023063323A1 (ja) 通信方法、ユーザ装置、及び基地局
WO2022153990A1 (ja) 通信制御方法及びユーザ装置
WO2023063371A1 (ja) 通信方法
JP7481588B2 (ja) 通信方法、ユーザ装置、移動通信システム、チップセット、及びプログラム
WO2024034567A1 (ja) 通信方法
WO2022234847A1 (ja) 通信制御方法及びユーザ装置
JP7259136B2 (ja) 通信制御方法、基地局、ユーザ装置及びプロセッサ
US20230188950A1 (en) Communication control method
WO2023002988A1 (ja) 通信方法

Legal Events

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

Ref document number: 22781124

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023511494

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22781124

Country of ref document: EP

Kind code of ref document: A1