Communication method, user equipment, and network node
Patent Information
- Application Number
- JP2025519449
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2023-05-09
- Filing Date
- 2024-05-08
- Publication Date
- 2026-08-21
- Estimated Expiration
- 2044-05-08
Smart Images

Figure 0007909699000001 
Figure 0007909699000002 
Figure 0007909699000003
Abstract
Description
Technical Field
[0001] The present disclosure relates to a communication method, a user device, and a network node used in a mobile communication system.
Background Art
[0002] In 3GPP (3rd Generation Partnership Project), the technical specifications of NR (New Radio), which is a 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 a 4th generation (4G) radio access technology. In 3GPP, the technical specifications of 5G / NR multicast / broadcast services (MBS) are defined.
[0003] In 3GPP Release 17, reception of MBS multicast (i.e., multicast reception) is possible only for user devices in the radio resource control (RRC) connected state (see, for example, Non-Patent Document 1). In contrast, in 3GPP Release 18, the technical specifications are planned to be extended so that user devices in the RRC inactive state can perform multicast reception.
Prior Art Documents
Non-Patent Documents
[0004]
Non-Patent Document 1
Summary of the Invention
[0005] The first aspect of the communication method is a communication method performed by a user device in a mobile communication system that provides multicast / broadcast services (MBS). The communication method includes the steps of: receiving information from a network node regarding whether or not to permit the execution of session participation processing for a multicast session using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state; and, based on the information indicating that the execution of the session participation processing using the SDT technology is permitted, executing the session participation processing using the SDT technology while maintaining the RRC inactive state.
[0006] The user device according to the second embodiment is a user device used in a mobile communication system that provides multicast / broadcast services (MBS). The user device includes a receiving unit that receives information from the network node regarding whether or not to permit the execution of session participation processing for a multicast session using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state, and a control unit that, based on the information indicating that the execution of the session participation processing using the SDT technology is permitted, executes the session participation processing using the SDT technology while maintaining the RRC inactive state.
[0007] The network node according to the third embodiment is a network node used in a mobile communication system that provides multicast / broadcast services (MBS). The network node includes a transmitting unit that transmits to the user device information regarding whether or not to allow the user device to perform session participation processing for a multicast session using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state. [Brief explanation of the drawing]
[0008] [Figure 1] This is a diagram showing an example configuration of a mobile communication system according to the embodiment. [Figure 2] This figure shows an example configuration of a UE (User Equipment) according to the embodiment. [Figure 3] This figure shows an example configuration of a gNB (base station) according to the embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This figure shows an example of the basic operation of the UE according to the embodiment. [Figure 7] This figure shows an example of the operation of the mobile communication system according to the embodiment. [Modes for carrying out the invention]
[0009] A mobile communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.
[0010] (1) Example of system configuration Figure 1 shows an example configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 5th Generation System (5GS) of the 3GPP standard. In the following explanation, 5GS will be used as an example, but the mobile communication system may also incorporate an LTE (Long Term Evolution) system at least partially. The mobile communication system may also incorporate a 6th Generation (6G) system at least partially.
[0011] The mobile communication system 1 comprises user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, NG-RAN 10 may be simply referred to as RAN 10, and 5GC 20 may be simply referred to as the core network (CN) 20. RAN 10 and CN 20 constitute the network of the mobile communication system 1.
[0012] UE100 is a mobile wireless communication device. UE100 can be any device used by a user. For example, UE100 can be a mobile phone terminal (including smartphones) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or device attached to a sensor, a vehicle or device attached to a vehicle (Vehicle UE), or an aircraft or device attached to an aircraft (Aerial UE).
[0013] NG-RAN10 includes base stations (referred to as "gNBs" in 5G systems) 200. The gNBs 200 are interconnected via the Xn interface, which is an inter-base station interface. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with UEs 100 that have established a connection with its own cell. The gNB 200 has radio resource management (RRM) functions, user data routing functions (hereinafter simply referred to as "data"), measurement and control functions for mobility control and scheduling, etc. "Cell" is used as a term to indicate the smallest unit of a wireless communication area. "Cell" is also used as a term to indicate a function or resource that performs wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").
[0014] Furthermore, gNBs can also connect to the EPC (Evolved Packet Core), which is the core network of LTE. LTE base stations can also connect to 5GCs. LTE base stations and gNBs can also be connected via an inter-base station interface.
[0015] The 5GC20 includes the AMF (Access and Mobility Management Function) and the UPF (User Plane Function) 300. The AMF performs various mobility controls for the UE100. The AMF manages the mobility of the UE100 by communicating with it using NAS (Non-Access Stratum) signaling. The UPF controls data transfer. The AMF and UPF are connected to the gNB200 via the NG interface, which is the base station-core network interface.
[0016] Figure 2 shows an example configuration of UE100 (user device) according to an embodiment. 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 gNB200.
[0017] The receiving unit 110 performs various types of reception 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.
[0018] The transmitting unit 120 performs various types of 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 (transmission signal) output by the control unit 130 into a wireless signal and transmits it from the antenna.
[0019] The control unit 130 performs various controls and processes in the UE 100. Such processes include the processes of each layer described later. The operations of the UE 100 described above and below may be operations under the control of the control unit 230. 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 processing 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, etc. The CPU executes programs stored in the memory to perform various processes.
[0020] FIG. 3 is a diagram showing a configuration example of the gNB 200 (base station) according to the 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 wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.
[0021] 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 wireless signal and transmits it from the antenna.
[0022] 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 wireless signal received by the antenna into a baseband signal (reception signal) and outputs it to the control unit 230.
[0023] The control unit 230 performs various control and processing operations in the gNB200. Such processing includes processing in each layer described later. The operation of the gNB200 described above and below may also be controlled by the control unit 230. 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 processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.
[0024] The backhaul communication unit 240 is connected to an adjacent base station via the Xn interface, which is an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via the NG interface, which is an inter-base station-core network interface. The gNB200 may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected by the F1 interface, which is a fronthaul interface.
[0025] Figure 4 shows the configuration of the protocol stack for the user plane's wireless interface that handles data.
[0026] The user plane radio interface protocol consists of 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.
[0027] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the UE100's PHY layer and the gNB200's PHY layer via a physical channel. The UE100's PHY layer receives downlink control information (DCI) transmitted from the gNB200 over the physical downlink control channel (PDCCH). Specifically, the UE100 performs blind decoding of the PDCCH using a Radio Network Temporary Identifier (RNTI) and acquires the successfully decoded DCI as the DCI addressed to its own UE. The DCI transmitted from the gNB200 has a CRC (Cyclic Redundancy Code) parity bit added, which is scrambled by the RNTI.
[0028] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat request (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.
[0029] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the UE100's RLC layer and the gNB200's RLC layer via a logical channel.
[0030] The PDCP layer performs header compression / decompression, encryption / decryption, etc.
[0031] The SDAP layer maps IP flows, which are the units under which the core network performs QoS (Quality of Service) control, to wireless bearers, which are the units under which the AS (Access Stratum) performs QoS control. Note that if the RAN is connected to the EPC, the SDAP is not required.
[0032] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).
[0033] The control plane's wireless interface protocol stack includes an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer, instead of the SDAP layer shown in Figure 4.
[0034] RRC signaling for various settings is transmitted between the RRC layer of the UE100 and the RRC layer of the gNB200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. If there is a connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC idle state. If the connection between the RRC of the UE100 and the RRC of the gNB200 is suspended, the UE100 is in the RRC inactive state.
[0035] The NAS layer (also simply referred to as "NAS"), located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300A's NAS layer. The UE100 also has application layers and other components in addition to its wireless interface protocol. Furthermore, the layer below the NAS layer is called the AS layer (also simply referred to as "AS").
[0036] (2) Overview of MBS Mobile communication system 1 can perform resource-efficient distribution through multicast / broadcast services (MBS).
[0037] (2.1) MBS Broadcast In the case of broadcast communication services (also referred to as "MBS broadcast"), the same service and specific content data are provided simultaneously to all UE100s within a geographical area. That is, all UE100s within the broadcast service area are permitted to receive the data. Broadcast communication services are delivered to the UE100s using broadcast sessions, which are a type of MBS session. UE100s can receive broadcast sessions regardless of whether they are in the RRC idle, RRC inactive, or RRC connected state. MBS sessions can be identified by their MBS session ID (e.g., TMGI (Temporary Mobile Group Identity)).
[0038] Broadcast communication services utilize Point-to-Multipoint (PTM) distribution. In PTM transmission, the gNB200 distributes a single copy of an MBS packet to a set (group) of multiple UE100s. For example, the gNB200 schedules a group-common PDSCH, which has a CRC scrambled by a group-common RNTI (G-RNTI), using a group-common PDCCH with a CRC scrambled by a group-common RNTI.
[0039] For broadcast communication services, UE100 receives a broadcast session in the following steps: First, UE100 receives a System Information Block Type 20 (SIB20) from gNB200. SIB20 contains the settings for a Multicast Control Channel (MCCH), which is a type of logical channel. Second, based on SIB20, UE100 receives the MCCH from gNB200. The MCCH contains the PTM settings. The PTM settings transmit settings for a Multicast Traffic Channel (MTCH), which is a type of logical channel, and settings for a Broadcast MRB, which is a Multicast Radio Bearer (MRB) for the broadcast session. The information transmitted by the MCCH is sometimes referred to as MBS broadcast control information. Third, based on the MCCH, UE100 receives the MTCH. The MTCH transmits the broadcast session (specifically, the MBS data belonging to the broadcast session).
[0040] MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from network 10 to UE100. MTCH is a PTM downlink channel for transmitting MBS data for either a multicast session or a broadcast session from network 10 to UE100.
[0041] (2.2) MBS Multicast In the case of multicast communication services (also known as "MBS multicast"), the same service and the same specific content data are provided simultaneously to a specific set of UEs. That is, not all UE100s within a multicast service area are permitted to receive the data. Multicast communication services are delivered to UE100s using multicast sessions, which are a type of MBS session.
[0042] UE100 can only receive multicast sessions after it has joined the multicast session. Joining a multicast session may mean that UE100 is registered with network 5 (CN20) as a device capable of receiving the multicast session.
[0043] For multicast communication services, 3GPP Release 17 allows only UE100s in an RRC connected state to receive multicast sessions. However, 3GPP Release 18 is planned to extend this so that UE100s in an RRC inactive state can also receive multicast sessions.
[0044] (2.2.1) Multicast reception in RRC connected state A UE100 in RRC connected state can receive multicast sessions (specifically, MBS data belonging to a multicast session) using mechanisms such as PTP (Point-to-Point) and / or PTM (Point-to-Multipoint) distribution.
[0045] In the case of a multicast communication service, a UE100 in the RRC connected state receives a multicast session in the following procedure. First, the UE100 receives an RRC Reconfiguration message from the gNB200. The RRC Reconfiguration message is transmitted on the Dedicated Control Channel (DCCH). The RRC Reconfiguration message transmits the settings for the MTCH for receiving the multicast session and the settings for the multicast MRB, which is the MRB for that multicast session. Second, the UE100 receives the MTCH based on the RRC Reconfiguration message. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session). The MTCH settings (MTCH settings) are settings related to MTCH reception and include at least one of the following, for example, a group identifier (G-RNTI), intermittent reception settings (DRX settings or scheduling information: MTCH transmission ON time, MTCH transmission period, reference time and time offset, HARQ retransmission settings), Layer 2 settings (PDCP settings, RLC settings), and physical channel settings (PDCCH settings, PDSCH settings, SSB mapping settings).
[0046] (2.2.2) Multicast reception in RRC inactive state A UE100 in an RRC inactive state can receive multicast sessions (specifically, MBS data belonging to multicast sessions) using the PTM distribution mechanism.
[0047] In the case of a multicast communication service, a UE100 in an RRC inactive state can receive a multicast session in the following manner: First, the UE100 in an RRC inactive state receives a newly introduced system information block (also called the "new SIB") from the gNB200. The new SIB includes the configuration of a newly introduced MCCH (also called the "multicast MCCH"). Second, the UE100 in an RRC inactive state receives the multicast MCCH from the gNB200 based on the new SIB. The multicast MCCH includes the PTM configuration. The PTM configuration transmits the configuration for the MTCH for multicast session reception and the configuration of the multicast MRB, which is the MRB for multicast sessions. Third, the UE100 in an RRC inactive state receives the MTCH based on the multicast MCCH. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).
[0048] If the gNB200 configures the UE100 to receive multicast in an RRC inactive state, it can send the PTM configuration to the UE100 using an RRC Release message that includes the suspend configuration. In this case, when the UE100 receives the RRC Release message containing the PTM configuration from the gNB200, it transitions to the RRC inactive state and receives multicast sessions in the RRC inactive state.
[0049] (3) System operation example The following describes the operation of multicast reception when RRC is inactive.
[0050] In order for UE100 to receive a multicast session, it must perform the join process to the multicast session with CN20. Therefore, the basic scenario for UE100 interested in receiving a multicast session is assumed to be: first, perform the join process to the multicast session while in the RRC connected state; second, transition from the RRC connected state to the RRC inactive state; and third, receive the multicast session while in the RRC inactive state. Note that UE100 joining a multicast session may also mean that UE100 is registered with CN20 in association with that multicast session.
[0051] However, UE100 may become interested in receiving a multicast session after transitioning to the RRC inactive state. In such cases, UE100 may need to transition to the RRC connected state by RRC connection resume in order to process joining the multicast session. When UE100 transitions to the RRC connected state, the load on both UE100 and network 5 (particularly gNB200) increases. Therefore, it is undesirable from the perspective of load reduction for UE100 to perform RRC connection resume in order to process joining a multicast session.
[0052] On the other hand, the mobile communication system 1 supports Small Data Transmission (SDT) technology, which enables communication (data transmission and / or signaling transmission) with the gNB200 while the UE100 remains in an RRC inactive state (i.e., without transitioning to an RRC connected state).
[0053] The SDT procedure is initiated by transmission via a Random Access Channel (RACH) resource configured in the system information, or a Type 1 Configured Grant (CG) resource configured in Dedicated Signaling (RRC Release message). In the case of RACH, network 5 can configure RA resources for two-stage RA or four-stage RA for SDT. The following embodiments mainly describe an example using RA-SDT, which is an SDT using Random Access (RA), but CG-SDT, which is an SDT using CG, may also be used. Note that SDT is enabled on a radio bearer basis and is initiated by UE100 only when the amount of uplink data waiting to be transmitted on all radio bearers with SDT enabled is less than a set amount, the downlink reference signal received power (RSRP) exceeds a set threshold, and there are valid SDT resources.
[0054] By using this SDT technology, the UE100 can perform session participation processing, allowing it to participate in a multicast session while remaining in an RRC inactive state, and enabling multicast reception in an RRC inactive state. However, as mentioned above, the basic scenario assumes that the UE100 has already joined the session, so there may be cases where the gNB200 does not support session participation processing using SDT technology.
[0055] Figure 6 shows an example of the basic operation of the UE100 according to this embodiment.
[0056] In step S1, UE100 receives information from gNB200 regarding whether or not to allow session participation processing for a multicast session using SDT (SDT technology), which communicates with gNB200 while maintaining an RRC inactive state. In this embodiment, UE100 in the RRC inactive state receives broadcast information broadcast from gNB200 via a System Information Block (SIB) or Multicast Control Channel (MCCH).
[0057] In step S2, based on the broadcast information indicating permission to perform session join processing using SDT, UE100 performs session join processing using SDT while maintaining the RRC inactive state.
[0058] This allows UE100 to execute session participation processing using SDT technology only after confirming that gNB200 supports SDT technology. Therefore, if gNB200 does not support session participation processing using SDT technology, it becomes easier to prevent UE100 from executing session participation processing using SDT technology.
[0059] In this embodiment, the SDT is a random access SDT (RA-SDT) that communicates with the gNB200 during the random access procedure. In step S2, the UE100 may send a non-access layer (NAS) request message for session participation processing along with message 3 (Msg3) or message A (MsgA) to be sent to the gNB200 during the random access procedure.
[0060] Furthermore, in step S2, UE100 may receive a NAS response message to a NAS request message for session participation processing, along with message 4 (Msg4) or message B (MsgB) received from gNB200 during the random access procedure.
[0061] Furthermore, in step S2, UE100 may receive the point-to-multipoint (PTM) settings necessary for receiving the multicast session from gNB200 along with the NAS response message. This makes it easier for UE100 to perform multicast reception in an RRC inactive state. Alternatively, UE100 may perform session participation processing using SDT in an RRC inactive state, and then receive MCCH from gNB200 to obtain the PTM settings during MCCH.
[0062] Figure 7 shows an example of the operation of the mobile communication system 1 according to this embodiment.
[0063] In step S101, UE100 is in an RRC inactive state in the cell of gNB200.
[0064] In step S102, UE100, which is in an RRC inactive state, becomes interested in multicast reception. For example, UE100 becomes interested in receiving a certain multicast session (let's call it "Multicast Session #1").
[0065] In step S103, the gNB200 sends broadcast information regarding whether or not to allow session joining of a multicast session using SDT. For example, the gNB200 may send an SIB containing an information element indicating that session joining of a multicast session using SDT is permitted or not permitted. In this example, the gNB200 sends an SIB containing an information element indicating that session joining of a multicast session using SDT is permitted.
[0066] Based on the broadcast information received from gNB200 (cell) in the SIB, UE100 determines that session participation processing using SDT is permitted. Then, in step S104, UE100 starts RA-SDT.
[0067] In step S105, UE100 sends Msg3 or MsgA to gNB200. Specifically, in the case of a four-stage RA, UE100 sends a random access preamble to gNB200 over the physical random access channel (PRACH), gNB200 sends a random access response to UE100, and UE100 sends Msg3 to gNB200. The transmission of Msg3 may also include the transmission of an RRC resume request message. In the case of a two-stage RA, UE100 sends the random access preamble and Msg3 transmission together as MsgA to gNB200.
[0068] In step S105, when UE100 sends Msg3 or MsgA, it sends a NAS message addressed to AMF300A on CN20. This NAS message is a join request message containing the session ID of the multicast session that UE100 requests to join. AMF300A on CN20 receives the join request message from UE100. Note that if the NAS message is sent using an RRC message in Msg3 or MsgA, the RRC message may include a container for storing the NAS message (dedicatedNAS-Message IE). This container may be included in the RRC Resume Request message or in another RRC message.
[0069] Upon receiving a join request message from UE100, the AMF300A on CN20 sends a join request to the MB-SMF (Multicast Broadcast Session Management Function) on CN20. The MB-SMF on CN20 accepts the join request and sends a join response to the AMF300A.
[0070] In step S106, the AMF300A of CN20 sends a NAS message (join response message) to UE100 in response to receiving a join response from MB-SMF.
[0071] In step S107, gNB200 sends a NAS message (join response message) from CN20's AMF300A to UE100 along with Msg4 or MsgB. Sending Msg4 or MsgB may also include sending an RRC Release message to keep UE100 in an RRC inactive state. gNB200 may also send the RRC Release message to UE100 including some of the PTM settings necessary to receive multicast session #1 (e.g., basic settings). If the NAS message is sent using an RRC message in Msg4 or MsgB, the RRC message may include a container for storing the NAS message (dedicatedNAS-Message IE). This container may be included in the RRC Release message, the RRC Resume message, or any other RRC message.
[0072] In step S108, the AMF300A of CN20 may send a UE context update message to the gNB200. This UE context update message may include the session ID of multicast session #1 in which UE100 has joined, as the updated UE context. Based on the UE context update message, the gNB200 recognizes multicast session #1 in which UE100 has joined. Note that step S108 may be performed before step S106 or simultaneously with step S106.
[0073] In step S109, gNB200 may send the PTM configuration, including the multicast session #1 configuration, over the MCCH for UE100. If gNB200 has sent the basic configuration for multicast session #1 in the RRC Release message, it may send the remaining PTM configuration over the MCCH.
[0074] In step S110, CN20 sends multicast data for multicast session #1 to gNB200.
[0075] In step S111, gNB200 multicasts the multicast data for multicast session #1 from CN20 to UE100 via multicast on the MTCH. UE100, in an RRC inactive state, receives the multicast data for multicast session #1 from gNB200 on the MTCH.
[0076] In this example, we described one instance where the gNB200 provides PTM settings to the UE100 in step S107. However, a scenario where the gNB200 cannot provide PTM settings to the UE100 in step S107 is also conceivable. In such a scenario, all PTM settings necessary for the UE100 to perform multicast reception (MTCH reception) must be provided via MCCH. However, it is also possible that the gNB200 does not provide such PTM settings via MCCH.
[0077] Therefore, in step S103, instead of sending an SIB containing a block configuration indicating whether or not to allow session participation processing of a multicast session using SDT, the gNB200 may send an MCCH indicating whether or not to allow session participation processing of a multicast session using SDT.
[0078] Here, if gNB200 permits session joining of a multicast session using SDT, it may send an MCCH containing all the information necessary for multicast reception. On the other hand, if it does not permit session joining of a multicast session using SDT, gNB200 may send an MCCH containing only some of the information necessary for multicast reception. Based on the contents of the MCCH received from gNB200, UE100 determines whether or not session joining of a multicast session using SDT is permitted.
[0079] When UE100 performs session participation processing using SDT, it may notify gNB200 in step S105 that it will perform such processing. This notification may be performed by sending Msg1 using a specific PRACH resource. gNB200 may notify UE100 of this specific PRACH resource (a PRACH resource for notifying session participation processing using SDT) via SIB, MCCH, or dedicated signaling. Alternatively, this notification may be sent via Msg3. In this case, the RRC Resume Request message may use a Resume Cause element, or it may be notified using a new information element. This notification allows gNB200 to optimize the reception of steps S106 and S108, and the transmission of steps S107 and S109. For example, by sending step S107 after receiving step S108, the multicast reception setting can be included in the RRC Request message in step S107.
[0080] (4) Other embodiments In the embodiments described above, multicast reception in the RRC inactive state was mainly explained, but the operation according to the embodiments described above may also be applied to multicast reception in the RRC idle state. In the case of the RRC idle state, the above-described RRC resume is read as RRC establishment.
[0081] Each of the above-described operation flows can be performed not only independently, but also in combination of 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. It is not necessary to execute all steps in each flow; only some steps may be executed.
[0082] In the embodiments and examples described above, an example in which the base station is an NR base station (gNB) was described, but the base station may also be an LTE base station (eNB) or a 6G base station. Furthermore, the base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of an IAB node. Furthermore, UE100 may be an MT (Mobile Termination) of an IAB node.
[0083] In other words, UE100 may be a terminal function unit (a type of communication module) for a base station to control a repeater that performs signal relay. Such a terminal function unit is called an MT. Examples of MTs other than IAB-MT include NCR (Network Controlled Repeater)-MT and RIS (Reconfigurable Intelligent Surface)-MT.
[0084] Furthermore, the term "network node" primarily refers to a base station, but may also refer to a core network device or a part of a base station (CU, DU, or RU). Additionally, a network node may consist of a combination of at least a part of the core network device and at least a part of a base station.
[0085] A program may be provided that causes a computer to execute each process performed by the 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-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM. Alternatively, the circuits that execute each process performed by the UE100 or gNB200 may be integrated, and at least a part of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).
[0086] The functions realized by UE100 or gNB200 (network node) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor, including transistors and other circuits, is considered circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, and means are hardware programmed to realize or perform the described functions. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to realize or perform the described functions. If such hardware is a processor that is considered to be a type of circuitry, then such circuitry, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.
[0087] The phrases “based on” and “depending on / in response to” used in this disclosure do not mean “based solely on” or “depending solely on” unless otherwise specified. “Based on” means both “based solely on” and “at least partially on.” Similarly, “depending on” means both “at least partially on” and “at least partially on.” The terms “include,” “comprise,” and variations thereof do not mean that only the listed items are included; they mean that only the listed items may be included, or that additional items may be included in addition to the listed items. Furthermore, the term “or” used in this disclosure is not intended to mean exclusive OR. Additionally, any reference to elements using designations such as “first,” “second,” etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be adopted therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated by the context that they are not.
[0088] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.
[0089] This application claims priority to U.S. Provisional Application No. 63 / 500966 (filed May 9, 2023), the entirety of which is incorporated into the specification of this application.
[0090] (5) Note The features of the above-described embodiment are noted below.
[0091] (Note 1) A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), The steps include receiving information from a network node regarding whether or not to allow the execution of the multicast session join process using Small Data Transmission (SDT) technology, which communicates with the network node while maintaining a Radio Resource Control (RRC) inactive state, and The step of executing the session join process using the SDT technology while maintaining the RRC inactive state, based on the information indicating that the execution of the session join process using the SDT technology is permitted. Communication method.
[0092] (Note 2) The receiving step includes the user device, which is in an RRC inactive state, receiving the information broadcast from the network node on a System Information Block (SIB) or Multicast Control Channel (MCCH). The communication method described in Appendix 1.
[0093] (Note 3) The aforementioned SDT technology is a random access SDT that performs the aforementioned communication during a random access procedure. The steps to be performed include sending a non-access layer (NAS) request message for the session join process, along with message 3 (Msg3) or message A (MsgA) to be sent to the network node during the random access procedure. The communication method described in Appendix 1 or 2.
[0094] (Note 4) The steps described above further include receiving a response message from the NAS to the request message, along with message 4 (Msg4) or message B (MsgB) received from the network node during the random access procedure. The communication method described in Appendix 3.
[0095] (Note 5) The steps described above further include receiving, along with the response message, the point-to-multipoint (PTM) configuration necessary for receiving the multicast session from the network node. The communication method described in Appendix 4.
[0096] (Note 6) User equipment used in a mobile communication system that provides multicast / broadcast services (MBS), A receiving unit that receives information from the network node regarding whether or not to allow the execution of multicast session participation processing using Small Data Transmission (SDT) technology, which communicates with the network node while maintaining a Radio Resource Control (RRC) inactive state, The system includes a control unit that, based on the information indicating that it is permissible to execute the session join process using the SDT technology, executes the session join process using the SDT technology while maintaining the RRC inactive state. User device.
[0097] (Note 7) A network node used in a mobile communication system that provides multicast / broadcast services (MBS), The system includes a transmitting unit that transmits information to the user device regarding whether or not to allow the user device to perform session participation processing for a multicast session using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state. Network node. [Explanation of Symbols]
[0098] 1: Mobile communication systems 5: Network 10: RAN 20 :CN 100: UE (User Device) 110: Receiving unit 120: Transmitter 130: Control Unit 200:gNB (base station) 210: Transmitter 220: Receiving unit 230: Control Unit 240: Backhaul Communications Department
Claims
1. A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), Receiving information from the network node regarding whether or not to allow the execution of multicast session participation processing using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state, Based on the information indicating that the execution of the session participation process using the SDT technology is permitted, the RRC inactive state is maintained while the session participation process is executed using the SDT technology. Communication method.
2. The aforementioned reception includes the user device, in an RRC inactive state, receiving the information broadcast from the network node on a System Information Block (SIB) or Multicast Control Channel (MCCH). The communication method according to claim 1.
3. The aforementioned SDT technology is a random access SDT that performs the aforementioned communication during a random access procedure. The aforementioned actions include sending a Non-Access Layer (NAS) request message for the session join process along with message 3 (Msg3) or message A (MsgA) to be sent to the network node during the random access procedure. The communication method according to claim 1.
4. The execution described above further includes receiving a response message from the NAS to the request message, along with message 4 (Msg4) or message B (MsgB) received from the network node during the random access procedure. The communication method according to claim 3.
5. The aforementioned actions further include receiving, along with the response message, the point-to-multipoint (PTM) configuration necessary for receiving the multicast session from the network node. The communication method according to claim 4.
6. A user device used in a mobile communication system that provides multicast / broadcast services (MBS), A receiving unit that receives information from the network node regarding whether or not to allow the execution of multicast session participation processing using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state, The system includes a control unit that, based on the information indicating permission to execute the session participation process using the SDT technology, executes the session participation process using the SDT technology while maintaining the RRC inactive state. User device.
7. A network node used in a mobile communication system that provides multicast / broadcast services (MBS), The system includes a transmitting unit that transmits information to the user device regarding whether or not to allow the user device to perform session participation processing for a multicast session using small data transmission (SDT) technology, which communicates with the network node while maintaining a radio resource control (RRC) inactive state. Network node.