Communication method, network node, processor, program, and mobile communication system

Abstract

A communication method according to a first embodiment is used in a mobile communication system providing multicast / broadcast services (MBS), and comprises a step in which a first base station transmits, to a second base station on an inter-base-station interface, a paging message that requests a paging to user equipment participating in a multicast session, the message including an MBS session identifier for identifying the multicast session.

Description

Technical Field

[0001] The present disclosure relates to a communication method used in a mobile communication system.

Background Art

[0002] In the 3GPP (3rd Generation Partnership Project) standard, the technical specifications of NR (New Radio), which is the 5th generation (5G) radio access technology, are defined. NR has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is the 4th generation (4G) radio access technology. In 3GPP, discussions are being held to formulate the technical specifications of the 5G / NR multicast and broadcast service (MBS) (see, for example, Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] The 5G / NR multicast and broadcast service is desired to provide a service improved from the 4G / LTE multicast and broadcast service.

[0005] Therefore, an object of the present disclosure is to provide a communication method capable of realizing an improved multicast and broadcast service.

[0006] The communication method according to the first aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS). The first base station transmits a paging message, which is a message requesting paging for user equipment participating in a multicast session and includes an MBS session identifier for identifying the multicast session, to a second base station on an interface between base stations.

[0007] The communication method according to the second aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS). A paging entity that generates a paging message for calling user equipment in the radio resource control (RRC) idle state or the RRC inactive state includes steps of: transmitting a first paging message including an MBS session identifier for identifying a multicast session to be started; identifying user equipment that is participating in the multicast session and has not responded to the first paging message; and transmitting a second paging message including a user equipment identifier for identifying the identified user equipment.

[0008] The communication method according to the third aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS). A user equipment in the radio resource control (RRC) idle state or the RRC inactive state sets cause information indicating the reason for transitioning to the RRC connected state in an RRC message for transitioning to the RRC connected state, and the user equipment transmits the RRC message to a base station. The setting step includes setting, as the cause information, first cause information defined for MBS reception in the RRC message when the reason is only MBS reception, and setting, as the cause information, second cause information defined for unicast communication in the RRC message when the reason is both the MBS reception and unicast communication.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Embodiments for Carrying Out the Invention

[0010] With reference to the drawings, a mobile communication system according to an embodiment will be described. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

[0011] [First Embodiment] (Configuration of Mobile Communication System) FIG. 1 is a diagram showing the configuration of a mobile communication system according to the first embodiment. The mobile communication system 1 complies with the 5th generation system (5GS: 5th Generation System) of the 3GPP standard. Hereinafter, the 5GS will be described as an example, but the LTE (Long Term Evolution) system may be at least partially applied to the mobile communication system. Also, the 6th generation (6G) system may be at least partially applied to the mobile communication system.

[0012] The mobile communication system 1 includes a user equipment (UE: User Equipment) 100, a 5G radio access network (NG-RAN: Next Generation Radio Access Network) 10, and a 5G core network (5GC: 5G Core Network) 20. Hereinafter, the NG-RAN 10 may sometimes be simply referred to as the RAN 10. Also, the 5GC 20 may sometimes be simply referred to as the core network (CN) 20.

[0013] UE100 is a mobile wireless communication device. UE100 can be any device as long as it is a device used by a user. For example, UE100 can be a mobile phone terminal (including smartphones), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided for a sensor, a vehicle or a device provided for a vehicle (Vehicle UE), an aircraft or a device provided for an aircraft (Aerial UE).

[0014] NG-RAN10 includes base stations (referred to as "gNB" in the 5G system) 200. The gNBs 200 are interconnected via the Xn interface which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE100 that has established a connection with its cell. The gNB 200 has functions such as a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, etc. "Cell" is used as a term indicating the smallest unit of a wireless communication area. "Cell" is also used as a term indicating a function or resource for performing wireless communication with the UE100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

[0015] Note that the gNB can also be connected to the EPC (Evolved Packet Core) which is the core network of LTE. The base station of LTE can also be connected to the 5GC. The base station of LTE and the gNB can also be connected via an interface between base stations.

[0016] 5GC20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 300. The AMF performs various mobility controls and the like for the UE100. The AMF manages the mobility of the UE100 by communicating with the UE100 using NAS (Non-Access Stratum) signaling. The UPF performs data transfer control. The AMF and the UPF are connected to the gNB200 via the NG interface, which is an interface between the base station and the core network.

[0017] FIG. 2 is a diagram showing the configuration of a UE100 (user equipment) according to the first embodiment. The UE100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB200.

[0018] The receiving unit 110 performs various receptions under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

[0019] The transmitting unit 120 performs various transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmitted signal) output by the control unit 130 into a radio signal and transmits it from the antenna.

[0020] The control unit 130 performs various controls and processes in the UE100. Such processes include the processes of each layer described later. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for the processes by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals and the like. The CPU executes programs stored in the memory to perform various processes.

[0021] FIG. 3 is a diagram showing the configuration of the gNB 200 (base station) according to the first embodiment. The gNB 200 includes a transmission unit 210, a reception unit 220, a control unit 230, and a backhaul communication unit 240. The transmission unit 210 and the reception unit 220 constitute a radio communication unit that performs radio communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.

[0022] The transmission unit 210 performs various transmissions under the control of the control unit 230. The transmission unit 210 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits it from the antenna.

[0023] The reception unit 220 performs various receptions under the control of the control unit 230. The reception unit 220 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (reception signal) and outputs it to the control unit 230.

[0024] The control unit 230 performs various controls and processes in the gNB 200. Such processes include the processes of each layer described later. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for the processes by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of the baseband signal, etc. The CPU executes the programs stored in the memory to perform various processes.

[0025] The backhaul communication unit 240 is connected to an adjacent base station via the Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via the NG interface, which is an interface between the base station and the core network. Note that the gNB 200 is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally split), and the two units may be connected by the F1 interface, which is a fronthaul interface.

[0026] Figure 4 is a diagram showing the configuration of the protocol stack of the radio interface of the user plane that handles data.

[0027] The radio interface protocol of the user plane has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[0028] 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 a physical channel. Note that the PHY layer of the UE 100 receives downlink control information (DCI) transmitted on the physical downlink control channel (PDCCH) from the gNB 200. Specifically, the UE 100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and obtains the DCI that has been successfully decoded as DCI addressed to the own UE. The DCI transmitted from the gNB 200 has CRC parity bits scrambled by the RNTI added thereto.

[0029] The MAC layer performs functions such as prioritization control of data, retransmission processing by Hybrid Automatic Repeat reQuest (HARQ), and random access procedures. Between the MAC layer of UE100 and the MAC layer of gNB200, data and control information are transmitted via transport channels. The MAC layer of gNB200 includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) for uplink and downlink and the resource blocks allocated to UE100.

[0030] The RLC layer uses the functions of the MAC layer and the PHY layer to transmit data to the RLC layer on the receiving side. Between the RLC layer of UE100 and the RLC layer of gNB200, data and control information are transmitted via logical channels.

[0031] The PDCP layer performs functions such as header compression / expansion and encryption / decryption.

[0032] The SDAP layer performs the mapping between the IP flow, which is the unit for the core network to perform Quality of Service (QoS) control, and the radio bearer, which is the unit for the Access Stratum (AS) to perform QoS control. When the RAN is connected to the EPC, the SDAP may not be necessary.

[0033] Figure 5 is a diagram showing the configuration of the protocol stack of the radio interface in the control plane that handles signaling (control signals).

[0034] The protocol stack of the radio interface in the control plane has a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer instead of the SDAP layer shown in Figure 4.

[0035] Between the RRC layer of UE100 and the RRC layer of gNB200, RRC signaling for various settings is transmitted. The RRC layer controls logical channels, transport channels, and physical channels in response to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in the RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in the RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in the RRC inactive state.

[0036] The NAS layer located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF300A. Note that UE100 has an application layer etc. in addition to the protocol of the radio interface. Also, the layer below the NAS layer is called the AS layer.

[0037] (Overview of MBS) The overview of MBS according to the first embodiment will be described. MBS is a service that enables the NG-RAN10 to transmit data to UE100 in a broadcast or multicast manner, that is, one-to-many (PTM: Point To Multipoint). The use cases (service types) of MBS are assumed to include public security communication, mission-critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communication, and software distribution, etc.

[0038] The broadcast service provides services to all UEs 100 within a specific service area for applications that do not require high-reliability QoS. The MBS session used for the broadcast service is called a broadcast session.

[0039] The multicast service provides services not to all UEs 100, but to a group of UEs 100 that participate in the multicast service (multicast session). The MBS session used for the multicast service is called a multicast session. According to the multicast service, the same content can be provided to a group of UEs 100 in a more radio-efficient way compared to the broadcast service.

[0040] FIG. 6 is a diagram showing an overview of MBS traffic distribution according to the first embodiment.

[0041] MBS traffic (MBS data) is distributed from a single data source (application service provider) to multiple UEs. The 5G core network, 5G CN (5GC) 20, receives MBS data from the application service provider, creates (Replication) copies of the MBS data, and distributes them.

[0042] From the perspective of 5GC 20, two multicast distribution methods are possible: 5GC Shared MBS Traffic delivery and 5GC Individual MBS Traffic delivery.

[0043] In the 5GC Individual MBS Traffic delivery method, 5GC 20 receives a single copy of the MBS data packet and distributes individual copies of those MBS data packets to individual UEs 100 via a PDU session for each UE 100. Therefore, it is necessary to associate one PDU session for each UE 100 with the multicast session.

[0044] In the 5GC shared MBS traffic distribution method, the 5GC 20 receives a single copy of the MBS data packets and distributes a single copy of those MBS packets to the RAN node (i.e., gNB 200). The gNB 200 receives the MBS data packets via the MBS tunnel connection and distributes them to one or more UEs 100.

[0045] From the perspective of the RAN (5G RAN) 10, for the wireless transmission of MBS data in the 5GC shared MBS traffic distribution method, two distribution methods, PTP (Point-to-Point) and PTM (Point-to-Multipoint), are possible. PTP means unicast, and PTM means multicast and broadcast.

[0046] In the PTP distribution method, the gNB 200 wirelessly distributes individual copies of the MBS data packets to individual UEs 100. On the other hand, in the PTM distribution method, the gNB 200 wirelessly distributes a single copy of the MBS data packets to a group of UEs 100. The gNB 200 can dynamically determine whether to use PTM or PTP as the distribution method for MBS data to a single UE 100.

[0047] The PTP distribution method and the PTM distribution method mainly relate to the user plane. As control modes for MBS data distribution, there are two distribution modes: the first distribution mode and the second distribution mode.

[0048] FIG. 7 is a diagram showing the distribution mode according to the first embodiment.

[0049] The first delivery mode (Delivery mode 1: DM1) is a delivery mode available to the UE100 in the RRC connected state and is a delivery mode for high QoS requirements. The first delivery mode is used for the multicast session among the MBS sessions. However, the first delivery mode may be used for the broadcast session. The first delivery mode may also be available to the UE100 in the RRC idle state or the RRC inactive state.

[0050] The setting of MBS reception in the first delivery mode is performed by UE-dedicated signaling. For example, the setting of MBS reception in the first delivery mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted unicast from the gNB200 to the UE100.

[0051] The setting of MBS reception includes MBS traffic channel setting information (hereinafter referred to as "MTCH setting information") regarding the setting of the MBS traffic channel for transmitting MBS data. The MTCH setting information includes MBS session information regarding the MBS session (including the MBS session identifier described later) and the scheduling information of the MBS traffic channel corresponding to this MBS session. The scheduling information of the MBS traffic channel may include the discontinuous reception (DRX) setting of the MBS traffic channel. The discontinuous reception setting includes a timer value (On Duration Timer) for defining the on period (reception period), a timer value (Inactivity Timer) for extending the on period, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), and an offset value of the start subframe of the scheduling or DRX cycle (Start Offset, DRX Cycle Off set) It may include one or more parameters such as the start delay slot value (Slot Offset) of the on-period timer, the timer value (Retransmission Timer) that defines the maximum time until retransmission, and the timer value (HARQ RTT Timer) that defines the minimum interval until the DL assignment of HARQ retransmission.

[0052] Note that the MBS traffic channel is a type of logical channel and may be called MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH: Down Link - Shared CHannel), which is a type of transport channel.

[0053] The second delivery mode (Delivery mode 2: DM2) is a delivery mode that can be used not only by the UE100 in the RRC connected state but also by the UE100 in the RRC idle state or the RRC inactive state, and it is a delivery mode for low QoS requirements. The second delivery mode is used for the broadcast session among the MBS sessions. However, the second delivery mode may also be applicable to the multicast session.

[0054] The setting of MBS reception in the second delivery mode is performed by broadcast signaling. For example, the setting of MBS reception in the second delivery mode is performed by a logical channel, such as a broadcast control channel (BCCH) and / or a multicast control channel (MCCH), which is broadcast from the gNB200 to the UE100. The UE100 can receive the BCCH and MCCH using, for example, a dedicated RNTI predefined in the technical specifications. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0055] In the second delivery mode, the UE 100 may receive MBS data in the following three procedures. First, the UE 100 receives MCCH configuration information by means of an SIB (MBS SIB) transmitted on the BCCH from the gNB 200. Second, the UE 100 receives the MCCH from the gNB 200 based on the MCCH configuration information. The MCCH transmits MTCH configuration information. Third, the UE 100 receives the MTCH (MBS data) based on the MTCH configuration information. Hereinafter, the MTCH configuration information and / or the MCCH configuration information may be referred to as MBS reception settings.

[0056] In the first and second delivery modes, the UE 100 may receive the MTCH using a group RNTI (G-RNTI) assigned from the gNB 200. The G-RNTI corresponds to the RNTI for MTCH reception. The G-RNTI may be included in the MBS reception settings (MTCH configuration information).

[0057] Note that the network can provide different MBS services for each MBS session. The MBS session is identified by at least one of a TMGI (Temporary Mobile Group Identity), a source-specific IP multicast address (composed of a source unicast IP address such as an application function or an application server and an IP multicast address indicating a destination address), a session identifier, and a G-RNTI. At least one of the TMGI, the source-specific IP multicast address, and the session identifier is referred to as an MBS session identifier. The TMGI, the source-specific IP multicast address, the session identifier, and the G-RNTI are collectively referred to as MBS session information.

[0058] FIG. 8 is a diagram showing an example of internal processing related to MBS reception of the UE 100 according to the first embodiment. FIG. 9 is a diagram showing another example of internal processing related to MBS reception of the UE 100 according to the first embodiment.

[0059] One multicast bearer service (MBS) radio bearer (MRB) is one radio bearer that transmits a multicast session or a broadcast session. That is, there are cases where a multicast session is associated with the MRB and cases where a broadcast session is associated with the MRB.

[0060] The MRB and the corresponding logical channel (e.g., MTCH) are set from the gNB 200 to the UE 100 by RRC signaling. The setting procedure of the MRB may be separated from the setting procedure of the data radio bearer (DRB). In RRC signaling, one MRB can be set as "PTM only", "PTP only", or "both PTM and PTP". Such types of MRBs can be changed by RRC signaling.

[0061] In FIG. 8, an example is shown in which a multicast session and a dedicated traffic channel (DTCH) are associated with MRB #1, a multicast session and MTCH #1 are associated with MRB #2, and a broadcast session and MTCH #2 are associated with MRB #3. That is, MRB #1 is an MRB of "PTP only", MRB #2 is an MRB of "PTM only", and MRB #3 is an MRB of "PTM only". Note that the DTCH is scheduled using the cell radio network temporary identifier (C-RNTI). The MTCH is scheduled using the group radio network temporary identifier (G-RNTI).

[0062] The PHY layer of the UE 100 processes user data (received data) received on the physical downlink shared channel (PDSCH), which is one of the physical channels, and sends it to the downlink shared channel (DL-SCH), which is one of the transport channels. The MAC layer (MAC entity) of the UE 100 processes the data received on the DL-SCH and sends the received data to the corresponding logical channel (corresponding RLC entity) based on the logical channel identifier (LCID) included in the header (MAC header) included in the received data.

[0063] FIG. 9 shows an example in which a DTCH and an MTCH are associated with an MRB associated with a multicast session. Specifically, one MRB is split into two legs, one leg is associated with the DTCH, and the other leg is associated with the MTCH. The two legs are combined in the PDCP layer (PDCP entity). That is, the MRB is an MRB for both PTM and PTP. Such an MRB may be called a split MRB.

[0064] (Group Activation Notification) FIG. 10 is a diagram showing operations related to the group activation notification according to the first embodiment. The group activation notification may be called a multicast activation notification or a session activation notification.

[0065] Here, in the first distribution mode, it is mainly assumed that the UE 100 in the RRC connected state receives MBS data transmitted multicast from the gNB 200 (that is, multicast data). Therefore, it is assumed that the MBS session is a multicast session. The multicast session may be mapped to a PTM leg or a PTM bearer (MRB). Further, the multicast session may be mapped to a PTP leg, a PTP bearer, or a split MRB. An MBS traffic channel (MTCH) or a dedicated traffic channel (DTCH) is used for transmitting multicast data from the gNB 200 to the UE 100.

[0066] After participating in the multicast session, UE100 transitions to the RRC idle state or the RRC inactive state and waits for the start of the multicast session. UE100 receives a group activation notification, which is a notification indicating the start (activation) of the multicast session in which UE100 participates and is sent from the network to the group to which UE100 belongs, in the RRC idle state or the RRC inactive state. Assume that the group activation notification is a type of paging message. In response to receiving the group activation notification, UE100 transitions to the RRC connected state and receives multicast data of the multicast session from gNB200.

[0067] Hereinafter, RAN10 (gNB200) and CN20 (particularly, AMF300A) are collectively referred to as the "network" as appropriate. AMF300A is an example of a core network (CN) device. AMF300A manages an MBS session (multicast session) in cooperation with a session management device. The session management device may be an (MB-)SMF.

[0068] In step S1, UE100 is in the RRC connected state. Assume that UE100 is interested in a certain multicast session (hereinafter referred to as the "target multicast session"). "Being interested in a multicast session" means that the upper layer of UE100 requests or desires to receive the multicast session. The upper layer includes the NAS layer. The upper layer may further include an application.

[0069] In step S2, the UE 100 (NAS entity) performs a multicast session participation procedure to participate in the target multicast session with respect to the network. For example, the UE 100 transmits a first NAS message requesting participation in the target multicast session to the AMF 300A, and participates in the target multicast session by receiving a second NAS message approving the participation in the target multicast session from the AMF 300A. For example, the first NAS message is a PDU Session Modification Request, and the message may include an MBS session identifier and participation request information. When the approval of the first NAS message is implicitly notified by the MRB setting from the gNB 200, the second NAS message may be omitted. Also, "participating in the target multicast session" means registering the UE 100 as a member of a UE group (multicast group) that receives the multicast session with respect to the CN device. The CN device may authenticate the UE 100 at the time of the registration. Also, the CN device may permit the UE 100 to receive the multicast session. Note that the participation in the multicast session may be performed when the multicast session is in an active state (transmitting), or may be performed when the multicast session is in an inactive state (waiting for transmission start or during transmission interruption).

[0070] In step S3, the UE 100 transitions to the RRC idle state or the RRC inactive state. Specifically, the UE 100 transitions to the RRC idle state or the RRC inactive state by receiving an RRC release message from the gNB 200. Prior to step S3, the UE 100 may transmit an RRC message (for example, a UE Assistance Information message) including an information element prompting the UE 100 to transition to the RRC idle state or the RRC inactive state to the gNB 200. The gNB 200 may determine to transition the UE 100 to the RRC idle state or the RRC inactive state in response to the target multicast session that the UE 100 is interested in being in an inactive state.

[0071] In step S4, UE100 starts monitoring the group activation notification from gNB200. In the first embodiment, the group activation notification may be a paging message transmitted from AMF300A via gNB200. For example, UE100 monitors the group activation notification at the paging opportunity (PO) of the periodically set paging frame (PF). The group activation notification may notify the start of a multicast session. The start of the session may mean that the multicast session is activated from an inactive state.

[0072] In step S5, gNB200 transmits a group activation notification addressed to the group including UE100 or a group that UE100 is interested in. gNB200 may transmit a group activation notification (paging message) to UE100 in response to a paging request (group activation notification request) from AMF300A. The group activation notification includes an MBS session identifier indicating the multicast session to be started. UE100 that receives the group activation notification including such an identifier can recognize that the target multicast session it has joined has started. The start of the target multicast session may mean that the transmission of multicast data has been activated in the target multicast session. Also, the start of the target multicast session may mean that the target multicast session has become in a state where the transmission of multicast data can be started.

[0073] In step S6, UE100 performs a random access procedure on gNB200 for receiving the target multicast session.

[0074] In step S7, UE100 transitions to the RRC connected state by the random access procedure.

[0075] In step S8, UE100 receives multicast data of the target multicast session from gNB200 in the RRC connected state. Before receiving the data, settings for receiving the target multicast session may be performed on UE100 from gNB200. The setting is, for example, an RRC Reconfiguration message including an MRB setting.

[0076] According to such a group activation notification (paging message), it is possible to efficiently call UE100 in the RRC idle state or the RRC inactive state that has joined (Session join) the multicast session.

[0077] (Operation of the mobile communication system) The operation of the mobile communication system 1 according to the first embodiment will be described.

[0078] The above group activation notification (paging message) is available only when gNB200 supports the MBS function. Therefore, UE100 in the RRC idle state or the RRC inactive state camping on a cell of gNB200 that does not support the MBS function cannot receive the group activation notification. Also, there is a concern that UE100 cannot receive the group activation notification even when the radio state of UE100 is temporarily poor. Therefore, in the first embodiment, by using the group activation notification (paging message) and the normal paging message in combination, it is possible to more reliably call UE100 in the RRC idle state or the RRC inactive state that has joined (Session join) the multicast session.

[0079] In the first embodiment, a paging entity that generates a paging message for calling UE 100 in the RRC idle state or the RRC inactive state first transmits a first paging message (i.e., a group activation notification) including an MBS session identifier (e.g., TMGI) that identifies a multicast session to be started. Second, the paging entity identifies UE 100 that participates in the multicast session and did not respond to the first paging message. Third, the paging entity transmits a second paging message (i.e., a normal paging message) including a UE identifier (e.g., 5G-S-TMSI) that identifies the identified UE 100. For example, the paging entity transmits the second paging message only when there is UE 100 that participates in the multicast session and did not respond to the first paging message.

[0080] This makes it possible to more reliably call UE 100 in the RRC idle state or the RRC inactive state that participates in the multicast session. Also, when all UE 100 that participate in the multicast session respond to the first paging message (i.e., transition to the RRC connected state), the second paging message is not transmitted, so consumption of radio resources can be suppressed.

[0081] In the first embodiment, the paging entity may be AMF 300A. Alternatively, the paging entity may be gNB 200. For example, for UE 100 in the RRC idle state, AMF 300A may generate and transmit a paging message, and for UE 100 in the RRC inactive state, gNB 200 may generate and transmit a paging message.

[0082] FIG. 11 is a diagram showing a first operation example according to the first embodiment. In the first operation example according to the first embodiment, it is assumed that the paging entity is AMF300A.

[0083] In step S101, each of UE100a and UE100b that has already participated in a certain multicast session (hereinafter referred to as "multicast session #1") is in the RRC idle state. Note that each of UE100a and UE100b is located in the cell of the same gNB200, but may be located in cells of different gNB200s.

[0084] In step S102, AMF300A detects the start (activation) of multicast session #1.

[0085] In step S103, AMF300A generates a first paging message (i.e., group activation notification) including the MBS session identifier (e.g., TMGI) of the multicast session #1 to be started.

[0086] In step S104, AMF300A transmits the first paging message to gNB200. This first paging message is transmitted on the NG interface.

[0087] In step S105, gNB200 transmits the first paging message received from AMF300A. This first paging message is an RRC message. Here, it is assumed that UE100a successfully receives the first paging message, but UE100b fails to receive the first paging message. Therefore, UE100b does not respond to the first paging message and does not transition to the RRC connected state.

[0088] When the UE100a that has received the first paging message determines that the MBS session identifier of the multicast session #1 it is participating in is included in the first paging message, it decides that the multicast session #1 has started and determines to transition to the RRC connected state.

[0089] In step S106, the UE100a performs a random access procedure with the gNB200. The details of the random access procedure will be described in the second embodiment.

[0090] In step S107, the UE100a transitions to the RRC connected state through the random access procedure. The UE100a receives an RRC reconfiguration message including MTCH configuration information for setting the MTCH for the multicast session #1 from the gNB200 and receives the MTCH based on the MTCH configuration information. As a result, the UE100a receives the MBS data of the multicast session #1 on the MTCH.

[0091] In step S108, the gNB200 sends a notification to the AMF300A indicating that the UE100a has transitioned to the RRC connected state in response to the first paging message. Such a notification may be an initial UE message. Also, such a notification may be a UE context resume request message.

[0092] In step S109, based on the notification from the gNB200, the AMF300A identifies the UE100b that is participating in the multicast session #1 and did not respond to the first paging message. For example, the AMF300A identifies the remaining UEs (i.e., UE100b) excluding the UE100a that responded to the first paging message from the list of UEs participating in the multicast session #1.

[0093] In step S110, the AMF 300A generates a second paging message (i.e., a normal paging message) including the UE identifier of the UE 100b identified in step S109.

[0094] In step S111, the AMF 300A transmits the second paging message to the gNB 200. This second paging message is transmitted on the NG interface.

[0095] In step S112, the gNB 200 transmits the second paging message received from the AMF 300A. The UE 100b that has received the second paging message determines to transition to the RRC connected state in response to its own UE identifier being included in the second paging message.

[0096] In step S113, the UE 100b performs a random access procedure with the gNB 200.

[0097] In step S114, the UE 100b transitions to the RRC connected state by the random access procedure. The UE 100b receives an RRC reconfiguration message including MTCH setting information for setting the MTCH for the multicast session #1 from the gNB 200, and receives the MTCH based on the MTCH setting information. As a result, the UE 100b receives the MBS data of the multicast session #1 on the MTCH.

[0098] FIG. 12 is a diagram showing a second operation example according to the first embodiment. In the second operation example according to the first embodiment, it is assumed that the paging entity is the gNB 200. Here, the differences from the first operation example according to the first embodiment will be described.

[0099] In step S131, each of the UE 100a and the UE 100b that has already joined the multicast session #1 is in the RRC inactive state.

[0100] In step S132, gNB200 detects the start (activation) of multicast session #1.

[0101] In step S133, gNB200 generates a first paging message (i.e., group activation notification) including the MBS session identifier (e.g., TMGI) of the multicast session #1 to be started. The first paging message may be transmitted to an adjacent gNB via the Xn interface. The Xn message may be a RAN PAGING or a new message (e.g., RAN GROUP NOTIFICATION).

[0102] In step S134, gNB200 transmits the first paging message. This first paging message is an RRC message and may be called a RAN paging message. Here, it is assumed that UE100a successfully receives the first paging message, while UE100b fails to receive the first paging message.

[0103] Upon receiving the first paging message, UE100a determines that multicast session #1 has started according to the fact that the MBS session identifier of the multicast session #1 it participates in is included in the first paging message, and decides to transition to the RRC connected state.

[0104] In step S135, UE100a performs a random access procedure with gNB200.

[0105] In step S136, UE100a transitions to the RRC connected state through a random access procedure. If the random access procedure is performed at an adjacent gNB, the adjacent gNB may notify gNB200 via the Xn interface that there has been an access from UE100a. Such notification may be implicitly performed by a procedure for obtaining the context information of UE100a from gNB200. Such a procedure is composed of RETRIEVE UE CONTEXT REQUEST and RETRIEVE UE CONTEXT RESPONSE messages.

[0106] In step S137, gNB200 participates in multicast session #1 and identifies UE100b that did not respond to the first paging message.

[0107] In step S138, gNB200 generates a second paging message (i.e., a normal RAN paging message) including the UE identifier of UE100b identified in step S137.

[0108] In step S139, gNB200 transmits the second paging message. UE100b that receives the second paging message determines to transition to the RRC connected state in response to the inclusion of its own UE identifier in the second paging message.

[0109] In step S140, UE100b performs a random access procedure with gNB200.

[0110] In step S141, UE100b transitions to the RRC connected state through a random access procedure.

[0111] [Second Embodiment] The second embodiment will be mainly described with differences from the above-described first embodiment.

[0112] A UE 100 in the RRC idle state or the RRC inactive state sets cause information indicating the reason for transitioning to the RRC connected state in an RRC message (i.e., an RRC Setup Request message or an RRC Resume Request message) for transitioning to the RRC connected state. Such cause information may be referred to as a Cause information element (Cause IE). Note that hereinafter, an RRC message for transitioning to the RRC connected state may sometimes be referred to as a "connection request message".

[0113] Upon receiving a connection request message, the gNB 200 determines whether to accept the connection request based on the Cause information element included in the connection request message. For example, if the resource situation (radio resources, hardware load, BH link, etc.) is tight, the gNB 200 rejects connection requests associated with low-priority services (Reject) to relieve congestion.

[0114] In particular, considering the case where the MBS service is provided only by PTM, even if the UE 100 newly starts PTM reception, the impact on the increase in resource consumption in the gNB 200 is small. Specifically, for other UEs 100, PTM transmission and a shared delivery tunnel have already been established, and the resource consumption basically does not change just because the number of UEs 100 has increased.

[0115] Therefore, there is a significant difference in resource consumption between accepting the connection request of a unicast UE 100 and accepting the connection request of a multicast-receiving UE 100. Here, if the gNB 200 is congested but can accept a multicast-receiving UE 100, it is not efficient to reject the connection of the multicast-receiving UE 100 without being able to distinguish it.

[0116] In the second embodiment, a UE 100 in the RRC idle state or the RRC inactive state sets cause information indicating a reason for transitioning to the RRC connected state in an RRC message (connection request message) for transitioning to the RRC connected state, and then transmits the RRC message to the gNB 200. When the reason is only MBS reception (for example, PTM reception or multicast reception), the UE 100 sets, as the cause information, first cause information defined for MBS reception (PTM reception, multicast reception) in the RRC message. On the other hand, when the reason is both MBS reception and unicast communication (for example, uplink data transmission), the UE 100 sets, as the cause information, second cause information defined for unicast communication in the RRC message.

[0117] Thereby, the gNB 200 can identify a connection request intended only for PTM reception (particularly, multicast reception), and can appropriately accept a connection request intended only for PTM reception (particularly, multicast reception). In addition, the gNB 200 can appropriately reject a connection request intended for PTM reception (particularly, multicast reception) and unicast communication (particularly, uplink data transmission) according to the resource status.

[0118] FIG. 13 is a diagram showing an example of cause information according to the second embodiment. Here, “EstablishmentCause IE”, which is cause information included in the RRC Setup Request message, is illustrated, but the RRC Resume Request message can have a similar configuration.

[0119] "EstablishmentCause IE" is configured to be selectable with "multicast-access", which is an example of the first cause information defined for MBS reception (PTM reception, multicast reception). When the reason (purpose) for the UE100 to transition to the RRC connected state is MBS reception (PTM reception, multicast reception), the UE100 selects "multicast-access" and sends a connection request message with "multicast-access" set to the gNB200.

[0120] On the other hand, each of "emergency", "highPriorityAccess", "mt-Access", "mo-Signalling", "mo-Data", "mo-VoiceCall", "mo-VideoCall", "mo-SMS", "mps-PriorityAccess", and "mcs-PriorityAccess" is an example of the second cause information defined for unicast communication. Details of these cause information are described in the 3GPP technical specification "TS38.331".

[0121] Figure 14 is a diagram showing a first operation example according to the second embodiment. In the first operation example according to the second embodiment, it is assumed that the random access procedure is a 4-step random access procedure.

[0122] In step S201, the UE100 is in the RRC idle state or the RRC inactive state. Since a reason (cause) for the UE100 to transition to the RRC connected state has occurred, the UE100 starts a random access procedure to transition to the RRC connected state.

[0123] In step S202, the UE100 sends a random access preamble (Msg1) to the gNB200.

[0124] In step S203, gNB200 transmits a random access response (Msg2) to UE100 in response to the reception of a random access preamble (Msg1).

[0125] In step S204, UE100 determines whether the reason for transitioning to the RRC connected state is only PTM reception (in particular, multicast reception).

[0126] If the reason for transitioning to the RRC connected state is only PTM reception (in particular, multicast reception) (step S204: YES), in step S205, UE100 sets first cause information defined for PTM reception (in particular, multicast reception) in the connection request message. UE100 may set the first cause information in the connection request message in response to any one of the following conditions being satisfied: receiving a paging message (i.e., a group activation notification) including an MBS session identifier for identifying the multicast session to be started, UE100 transitioning to the RRC connected state only for the purpose of MBS reception, and UE100 transitioning to the RRC connected state not for the purpose of uplink data transmission.

[0127] On the other hand, if the reason for transitioning to the RRC connected state is both PTM reception and unicast communication (in particular, uplink data transmission) (step S204: NO), in step S206, UE100 sets second cause information defined for unicast communication in the connection request message.

[0128] In step S207, UE100 transmits a connection request message (RRC Setup Request message or RRC Resume Request message) with the first cause information or the second cause information set to gNB200. In a 4-step random access procedure, the transmission of such a connection request message may be referred to as Msg3.

[0129] In step S208, the gNB200 that has received the connection request message determines whether to accept the connection request of the UE100 based on the cause information included in the connection request message and the resource status.

[0130] If the connection request of the UE100 is accepted (step S208: YES), in step S209, the gNB200 transmits an affirmative response message (RRC Setup message or RRC Resume message) to the UE100. As a result, the UE100 transitions to the RRC connected state. In the 4-step random access procedure, the transmission of such an affirmative response message is sometimes called Msg4.

[0131] On the other hand, if the connection request of the UE100 is rejected (step S208: NO), in step S210, the gNB200 transmits a negative response message (RRC Reject message) to the UE100. As a result, the UE100 does not transition to the RRC connected state.

[0132] FIG. 15 is a diagram showing a second operation example according to the second embodiment. In the second operation example according to the second embodiment, it is assumed that the random access procedure is a 2-step random access procedure. Here, the differences from the first operation example according to the second embodiment will be described.

[0133] In step S231, the UE100 is in the RRC idle state or the RRC inactive state. Since a reason (cause) for transitioning to the RRC connected state has occurred, the UE100 starts a random access procedure to transition to the RRC connected state.

[0134] In step S232, the UE100 determines whether the reason for transitioning to the RRC connected state is only PTM reception (particularly, multicast reception).

[0135] If the reason for transitioning to the RRC connected state is only PTM reception (especially multicast reception) (step S232: YES), in step S233, UE100 sets the first cause information defined for PTM reception (especially multicast reception) in the connection request message.

[0136] On the other hand, if the reason for transitioning to the RRC connected state is both PTM reception and unicast communication (especially uplink data transmission) (step S232: NO), in step S234, UE100 sets the second cause information defined for unicast communication in the connection request message.

[0137] In step S235, UE100 transmits a set of a random access preamble and a connection request message (RRC Setup Request message or RRC Resume Request message) with the first cause information or the second cause information set as MsgA to gNB200.

[0138] In step S236, gNB200 that has received the connection request message determines whether to accept the connection request of UE100 based on the cause information and the resource status included in the connection request message.

[0139] If accepting the connection request of UE100 (step S236: YES), in step S237, gNB200 transmits a set of a random access response and an affirmative response message (RRC Setup message or RRC Resume message) as MsgB to UE100. As a result, UE100 transitions to the RRC connected state.

[0140] On the other hand, if rejecting the connection request of UE100 (step S236: NO), in step S238, gNB200 transmits a negative response message (RRC Reject message) to UE100 or does not transmit a random access response to UE100. As a result, UE100 does not transition to the RRC connected state.

[0141] [Other Embodiments] Each of the above operation flows can be implemented not only separately and independently, but also by combining two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow.

[0142] In the above embodiments and examples, an example where the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. Also, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may be the DU of the IAB node. Also, the user device may be the MT (Mobile Termination) of the IAB node.

[0143] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, 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 a CD-ROM or a DVD-ROM. Also, a circuit that executes each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0144] As described above in detail with reference to the drawings, the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the gist.

[0145] As used in this disclosure, the terms "based on" and "depending on" do not mean "only based on" or "only depending on" unless otherwise specified. The term "based on" means both "only based on" and "at least partially based on". Similarly, the term "depending on" means both "only depending on" and "at least partially depending on". Also, "obtain / acquire" may mean obtaining information from stored information, obtaining information from information received from other nodes, or obtaining the information by generating the information. The terms "include", "comprise", and their variants do not mean including only the listed items, but may include only the listed items or may include additional items in addition to the listed items. Also, the term "or" as used in this disclosure is not intended to be an exclusive disjunction. Further, any reference to elements using designations such as "first", "second", etc. in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this specification as a convenient way to distinguish between two or more elements. Thus, a reference to a first and a second element does not mean that only two elements may be employed there or that the first element must precede the second element in any way. In this disclosure, for example, when articles are added by translation, such as a, an, and the in English, these articles shall be construed to include pluralities unless the context clearly indicates otherwise.

[0146] This application claims priority to U.S. Provisional Application No. 63 / 255,563, filed Oct. 14, 2021, the entire contents of which are incorporated herein by reference.

[0147] [Appendix] 1. Introduction The work items for NR Multicast and Broadcast Services (MBS) reached the following agreements on group notifications. · RAN2 waits for the final decision of RAN1 on which RNTI / DCI (such as Alt1, Alt2 identified by RAN1) to adopt for MCCH change notifications. · No mechanism is specified to address the possibility that the UE misses the MCCH change notification, and it is left to the UE implementation. · As long as RAN3 confirms, for UEs with deactivated multicast sessions, paging for multicast activation notifications is used in the relevant legacy PO (paging opportunity). · RAN2 sends LS to RAN3 and SA2, and indicates the priority of paging for multicast activation notifications used in the relevant legacy PO for UEs with non-activated multicast sessions. Furthermore, RAN2 requests confirmation from RAN3 and specifies the necessary network signaling if confirmation is required. · Confirm that the unicast paging message is extended to include a new paging record list for group activation notifications of multicast sessions. · NAS is expected to notify the UE of the release of the multicast session. · Handling of scenarios where UE notifications may be lost depends on the network implementation (e.g., repeated paging). · RAN2 does not prioritize addressing PRACH capacity issues due to group notifications. · Further consideration is required on the availability of using short messages or WUS-based displays for multicast activation notifications in the corresponding paging messages. · Further consideration is required on introducing MBS-specific UAC. · Further consideration is required on the reasons for establishing and resuming MBS. · For idle / inactive UEs that monitor multicast activation notifications, further consideration is required if frequencies with multicast support need to be prioritized.

[0148] In this appendix, unresolved issues regarding multicast activation notifications in the first delivery mode (DM1) and MCCH change notifications in the second delivery mode (DM2) will be discussed.

[0149] 2. Discussion 2.1. Unresolved Issues Regarding Multicast Activation Notifications (DM1) 2.1.1. Short Messages and Wake-up Signals RAN2 agreed on the following unresolved issues. · Further consideration is required regarding the use of short messages or WUS-based indications for multicast activation notifications of corresponding paging messages.

[0150] These mechanisms are discussed in the context of the impact on legacy UEs or UEs not interested in MBS by multicast activation notifications.

[0151] Short messages are transmitted on the PDCCH scrambled by the P-RNTI, and the bits of the DCI can notify system information changes (bit 1), ETWS and CMAS indications (bit 2), and the stop of paging monitoring (bit 3, NR-U only). To indicate that the paging message contains only the multicast activation notification, a new bit (e.g., bit 4) for notifying the multicast activation notification may be used.

[0152] The reserved bit field '00' of the short message indicator different from the above short message may be used to indicate that the paging message contains only the multicast activation notification.

[0153] For the wake-up signal (WUS or PEI) on the table, paging WUS may be used, and the paging message may include only the multicast activation notification for notification.

[0154] Generally, even if the reserved bits of the short message are defined in Rel-17, legacy UEs cannot understand those bits. Also, legacy UEs cannot monitor Rel-17 WUS. Therefore, legacy UEs understand that they cannot avoid decoding the paging message even when the new bits of the Short Message or WUS indicate that only the multicast activation notification is included in the corresponding paging message.

[0155] On the other hand, the proposed use of the above short message indicator may function for legacy UEs to avoid decoding the paging message as long as the operation of the legacy UE is defined when receiving the reserved bit field '00' of the DCI. That is, in this case, the legacy UE can avoid decoding the corresponding paging message. The concerns are whether such legacy behavior is already clear, whether it consumes the last reserved bit field, and that it ultimately depends on RAN1.

[0156] Finding 1: Since legacy UEs cannot understand Rel-17 short messages or monitor Rel-17 WUS, legacy UEs cannot avoid decoding paging messages. Finding 2: Legacy UEs can avoid decoding paging messages if the operation of the legacy UE is cleared when receiving the reserved bit field '00' of the short message indicator.

[0157] RAN2 agreed that "as long as RAN3 confirms, paging for multicast activation notification is used in legacy POs related to UEs with deactivated multicast sessions." From the UE's perspective, it is still considered consistent with RAN2's agreement that "the use of paging in all (legacy) POs using the PRNTI is a basic premise (other variations can still be discussed)". That is, both UEs interested in MBS and UEs not interested in MBS only wake up at that PO for unicast.

[0158] Finding 3: Rel-17 UEs only wake up at legacy POs regardless of whether the UE is waiting for only legacy unicast paging or multicast activation notification.

[0159] Receiving unnecessary paging occurs when a UE not interested in MBS decodes a paging message containing only multicast activation notification. However, the same problem also occurs in Rel-15. That is, when a UE decodes a paging message that is not paging this UE. Therefore, paging subgroups and / or WUS are being discussed in the Rel-17 UE Power Saving Enhancements WI. These two problems are basically caused by the same fundamental problem and may be solved by one solution (e.g., paging subgroup / WUS).

[0160] Specifically, it is expected that the CN assigns one subgroup to UEs interested in MBS and another subgroup to UEs not interested in MBS. Also, if necessary, it is possible for the CN to assign a different subgroup for each TMGI.

[0161] Observation 4: For Rel-17 UEs not interested in MBS, by using the paging subgroup and WUS discussed in the Rel-17 UE Power Saving Enhancements WI, for example, if the CN assigns two subgroups to UEs interested in MBS and UEs not interested in MBS respectively, it may be possible to avoid unnecessary paging reception as it is.

[0162] On the other hand, for UEs not interested in MBS, since they do not decode the paging message when receiving DCI with the bit field '00', the proposal using the above short message indicator is also effective.

[0163] Observation 5: Rel-17 UEs not interested in MBS can avoid unnecessary paging reception by receiving DCI with the bit field of the short message indicator being '00'.

[0164] From the above, it is considered that the MBS-specific function expansion that is not the short message indicator is not an efficient solution.

[0165] The advantage of enhancing the short message indication is that, although it is at the RAN1 level, it can support both legacy UEs and Rel-17 UEs. On the other hand, the disadvantages of enhancing the short message indication are that it is a solution specific to MBS, the operation of legacy UEs is unclear, and the last reserved bit field is consumed.

[0166] The advantage of the paging subgroup / WUS is that it can be a unified solution for both unicast paging and multicast activation notification, but the disadvantage is that it does not function in legacy UEs.

[0167] Also, in the email discussion, the frequency of multicast activation notification may not be high, and ultimately, the UE power consumption due to multicast activation notification may not be a major problem.

[0168] Proposal 1: RAN2 should agree to pursue only the enhancement of the short message indicator rather than the enhancement of the short message.

[0169] Proposal 2: RAN2 should discuss whether to apply the Rel-17 paging subgroup / WUS as it is (operates only on Rel-17 UEs, no optimization for MBS), or to enhance the short message indicator (operable on legacy UEs up to RAN1).

[0170] 2.1.2. Unified Access Control RAN2 agreed on the following open issues. · Further consideration is required for introducing MBS-specific UAC.

[0171] The UAC procedure checks for access prohibition according to the Access Category (AC) and Access Identity (AI) provided by the upper layer or RRC itself, and is executed at the beginning of the RRC connection establishment procedure and the RRC connection resume procedure. If the UE determines that the access attempt is prohibited as a result of the UAC procedure, it refrains from transmitting the RRC Setup Request or RRC Resume Request and starts the RACH procedure. not performed UAC is used during network congestion, especially during PRACH congestion. As a result, UAC can ensure accessibility such as emergency calls even during congestion.

[0172] Regarding PRACH congestion due to multicast activation notification, it has been agreed that "RAN2 does not prioritize addressing the capacity issue of PRACH due to group notification." This may be interpreted as indicating that in the deployment of Rel-17, congestion due to multicast activation is not an important issue. In this case, high-priority access (such as emergency reporting) is not affected by MBS services. Therefore, the enhancement of the UAC function considered in the email discussion is not necessary.

[0173] Finding 6: According to the RAN2 consensus that gives non - priority to the PRACH capacity issue, network congestion due to multicast activation notifications is not an important issue in the Rel - 17 deployment.

[0174] Finding 7: As a result of Finding 6, access to high - priority services such as emergency notifications is not affected by multicast activation notifications.

[0175] Proposal 3: RAN2 should agree not to pursue the enhancement of the UAC function.

[0176] 2.1.3. Reasons for establishment / resumption RAN2 agreed on the following outstanding issues. · Further study is required on the reasons for the establishment and resumption of MBS.

[0177] The reasons for establishment and resumption are notified from the UE to the gNB in RRC Setup Request and RRC Resume Request respectively, by information from the upper layer or by RRC itself. The gNB can decide whether to accept or reject the UE's request considering the radio resource usage status, hardware load, backhaul / TNL quality, etc. Also, the gNB may decide to release the RRC connection of other UEs due to access from a UE providing high - priority services. The reasons for establishment / resumption may seem similar to UAC, but in fact, they are different mechanisms for different purposes.

[0178] The possibility of expansion for the reasons for establishment / resumption has also been discussed. Since multicast activation notifications are a type of paging, it has also been proposed to reuse the existing mt - Access.

[0179] Especially when the MBS session is provided via PTM, it is understood that it consumes fewer resources than unicast connections. Therefore, even when the network is congested, there is no reason for the gNB to reject a connection request for the MBS service.

[0180] Observation 8: The MBS service consumes far fewer resources than the unicast service (especially when the MBS session is provided via PTM).

[0181] One gNB implementation always accepts requests from mt-Access, while other gNB implementations are assumed to reject requests depending on their congestion / overload. In this case, in order to reuse the existing mt-Access, the problem is that the gNB cannot distinguish between MBS reception requests and unicast connection requests. Therefore, it is effective to define a new cause value indicating that the connection request is for MBS reception only.

[0182] Observation 9: In the existing mt-Access, since connection requests for MBS reception and connection requests for unicast communication cannot be distinguished, the user experience and resource efficiency may deteriorate.

[0183] Proposal 4: RAN2 should agree on the introduction of a new establishment / resumption cause, i.e., multicast reception only.

[0184] 2.1.4. Cell reselection RAN2 agreed on the following open issues. · Further study is needed on whether it is necessary to prioritize frequencies with multicast support for idle / inactive UEs that monitor multicast activation notifications.

[0185] RAN2 has already agreed that in non-supporting nodes, using the MBS session ID will not work because it will affect non-MBS nodes. Since unicast paging works, UEs in cells that do not support MBS can finally receive legacy paging when the multicast session is activated. However, it can be seen that the problem is not whether the UE can be paged when the multicast session is started, but is related to the capacity / efficiency of paging.

[0186] The motivation for introducing multicast activation notification (group paging) is to reduce the number of legacy pages (individual UE pages). Therefore, as the number of UEs that cannot receive multicast sessions for cells that do not support MBS increases, it directly leads to an increase in the number of legacy pages, and due to paging capacity shortage, it has an adverse impact on legacy UEs and UEs not interested in MBS.

[0187] For the implementation of the paging strategy by the AMF, it can be considered that the AMF first starts only the multicast activation notification. If there are UEs that have not responded, that is, UEs in the idle / inactive state, the AMF starts individual legacy paging for these UEs and tries to minimize the individual paging as much as possible.

[0188] Therefore, it is important to know how many UEs exist in cells that support MBS. Thus, while waiting for the multicast activation notification, UEs need to prioritize cells that support MBS.

[0189] Finding 10: As the number of UEs that miss the multicast activation notification increases, the number of legacy (individual) pages directly increases, and due to paging capacity shortage, it has an adverse impact on legacy UEs and UEs not interested in MBS.

[0190] RAN2 also agreed on the following for the second delivery mode: "UE is permitted to prioritize the MBS frequency of interest as LTE SC-PTM when the cell on the MBS frequency provides an MBS SIB carrying the MCCH configuration." "UE is permitted to prioritize the MBS frequency of interest as LTE SC-PTM when UE can receive MBS services only by camping on the MBS frequency," and "UE may consider cell reselection candidate frequencies where MBS services cannot be received as having the lowest priority during an MBS session as LTE SC-PTM." Therefore, common UE behavior can be enabled in both the first and second delivery modes.

[0191] Finding 11: It is desirable that UE behavior in the idle / inactive mode be unified in both broadcast (second delivery mode) and multicast (first delivery mode).

[0192] From the above, UE in the idle / inactive state should preferentially use frequencies that support multicast in order to maximize the possibility of receiving multicast activation notifications.

[0193] Proposal 5: RAN2 should agree that UE in the idle / inactive state that monitors multicast activation notifications should prioritize frequencies that support multicast.

[0194] 2.2. MCCH Change Notification (DM2) for Other Information RAN2 agreed on the introduction of MCCH change notifications for session start, session change, and stop. This indicates the current intention that an MCCH change notification will be sent when settings related to MTCH reception, such as MBS session information and MTCH scheduling information, are changed. RAN2 agreed on the following outstanding issues. · The indication of MCCH change due to the configuration change of an ongoing session (including session suspension) is provided by an explicit notification from the network (however, on the condition that RAN1 confirms that in addition to the bit for session start notification, another bit for this purpose can be accommodated in the MCCH change notification DCI). Further consideration is required on whether this notification can be reused for the change of other information transmitted on the MCCH.

[0195] "Other information" may be interpreted as "whether the gNB can indicate the list of neighboring cells where the broadcast MBS service currently provided in the current cell is provided as LTE SC-PTM is an FS". Even if the UE misses the neighboring cell / frequency information, it is not a critical issue when the UE stays in the serving cell. However, for a UE in the idle / inactive state, in the case of inter-cell mobility, the latest neighboring cell information becomes important information. Therefore, in order to continue a more reliable service, if RAN2 agrees to provide the neighboring cell / frequency information from the MCCH, an MCCH change notification should be sent even when other information is changed.

[0196] Proposal 6: RAN2 should agree that an MCCH change notification is sent when any of the MCCH contents is changed, that is, in addition to the MBS session information and MTCH scheduling information, it should also apply to "other information" including at least the neighboring cell information (when agreed to be provided by the MCCH).

Description of Signs

[0197] 1: Mobile communication system 10: RAN 20: CN 100: UE 110: Receiver 120: Transmitter 130: Control unit 200: gNB 210: Transmitter 220: Receiver unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method used in a mobile communication system that provides a multicast broadcast service (MBS), comprising: A first network node transmits a paging message that requests paging for user equipment participating in a multicast session and includes an MBS session identifier that identifies the multicast session to a second network node on an interface between network nodes; The second network node that has received the paging message transmits a message indicating that there has been an access from the user equipment to the first network node in response to having received access from the user equipment. The communication method.

2. The MBS session identifier in the paging message includes a TMCI (Temporary Mobile Group Identity). The communication method according to Claim 1.

3. The second network node transmits a RETRIEVE UE CONTEXT REQUEST for acquiring context information of the user equipment to the first network node as the message. The communication method according to Claim 1.

4. A paging entity that generates a paging message for calling user equipment in a radio resource control (RRC) idle state or an RRC inactive state transmits a first paging message that includes an MBS session identifier that identifies a multicast session to be started; The paging entity identifies user equipment that is participating in the multicast session and that did not respond to the first paging message; The paging entity further transmits a second paging message that includes a user equipment identifier that identifies the identified user equipment. The communication method according to Claim 1.

5. Transmitting the second paging message includes transmitting the second paging message only if there is user equipment that is participating in the multicast session and that did not respond to the first paging message. The communication method according to Claim 4.

6. The paging entity is an AMF (Access and Mobility Management Function). The communication method according to claim 4 or 5.

7. The paging entity is a base station. The communication method according to claim 4 or 5.

8. A user equipment in a radio resource control (RRC) idle state or an RRC inactive state sets cause information indicating a reason for transitioning to the RRC connected state in an RRC message for transitioning to the RRC connected state; The user equipment further transmits the RRC message to a network node; The setting includes: when the reason is only multicast or broadcast reception of the MBS, setting the first cause information defined for MBS reception as the cause information in the RRC message; when the reason is both the multicast or broadcast reception and unicast communication, setting the second cause information defined for unicast communication as the cause information in the RRC message. The communication method according to claim 1.

9. Setting the first cause information in the RRC message includes setting the first cause information in the RRC message in response to any one of the user equipment receiving a paging message including an MBS session identifier for identifying a multicast session to be started, the user equipment transitioning to the RRC connected state only for the purpose of MBS reception, and the user equipment transitioning to the RRC connected state without the purpose of uplink data transmission. The communication method according to claim 8.

10. The RRC message is an RRC SetupRequest message. The communication method according to claim 8 or 9.

11. The RRC message is an RRC Resume Request message. The communication method according to claim 8 or 9.

12. A network node used in a mobile communication system that provides a multicast / broadcast service (MBS), A paging message that requests paging for a user device participating in a multicast session from another network node, the paging message including an MBS session identifier for identifying the multicast session, is received on an interface between network nodes by a receiving unit, After receiving the paging message, in response to receiving access from the user device, a transmitting unit transmits a message indicating that there has been access from the user device to the another network node. A network node.

13. A processor for a network node used in a mobile communication system that provides a multicast broadcast service (MBS), Means for receiving, on an interface between network nodes, a paging message that requests paging for a user device participating in a multicast session from another network node, the paging message including an MBS session identifier for identifying the multicast session, After receiving the paging message, means for transmitting, to the another network node, a message indicating that there has been access from the user device in response to receiving access from the user device. A processor.

14. In a network node used in a mobile communication system that provides a multicast broadcast service (MBS), Receiving, on an interface between network nodes, a paging message that requests paging for a user device participating in a multicast session from another network node, the paging message including an MBS session identifier for identifying the multicast session, After receiving the paging message, in response to receiving access from the user device, transmitting a message indicating that there has been access from the user device to the another network node. A program.

15. A mobile communication system having the network node according to claim 12 and a user device.

Images