Communication systems, communication terminal equipment, and base station equipment
Patent Information
- Application Number
- JP2026100826
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2020-04-07
- Filing Date
- 2026-06-17
- Publication Date
- 2026-09-08
AI Technical Summary
【0061】 本開示によれば、良好な通信を提供することができる。
Smart Images

Figure 2026143798000001_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to wireless communication technology. BACKGROUND ART
[0002] In 3GPP (3rd Generation Partnership Project), which is a standardization organization for mobile communication systems, the radio access section is referred to as Long Term Evolution (LTE), and a communication method called System Architecture Evolution (SAE) has been studied for the overall system configuration including a core network and a radio access network (hereinafter collectively also referred to as a network) (for example, Non-Patent Documents 1 to 5). This communication method is also called a 3.9G (3.9 Generation) system.
[0003] As an access scheme for LTE, OFDM (Orthogonal Frequency Division Multiplexing) is used for the downlink direction, and SC-FDMA (Single Carrier Frequency Division Multiple Access) is used for the uplink direction. Also, unlike W-CDMA (Wideband Code Division Multiple Access), LTE does not include circuit switching and employs only a packet communication scheme.
[0004] The decisions made by 3GPP regarding the frame structure in LTE systems, as described in Non-Patent Document 1 (Chapter 5), will be explained using Figure 1. Figure 1 is an explanatory diagram showing the structure of a radio frame used in an LTE communication system. In Figure 1, one radio frame is 10ms. A radio frame is divided into 10 subframes of equal size. Each subframe is divided into two slots of equal size. Downlink synchronization signals are included in the 1st and 6th subframes of each radio frame. The synchronization signals consist of a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).
[0005] The 3GPP's decisions regarding channel configuration in LTE systems are described in Non-Patent Document 1 (Chapter 5). It is assumed that the same channel configuration as non-CSG cells will be used in CSG (Closed Subscriber Group) cells.
[0006] The Physical Broadcast Channel (PBCH) is a channel used for downlink transmission from base station equipment (hereinafter sometimes simply referred to as "base station") to communication terminal equipment (hereinafter sometimes simply referred to as "mobile terminal") and other such devices. A PBCH transport block is mapped to four subframes within a 40ms interval. There is no explicit signaling at 40ms timing.
[0007] The Physical Control Format Indicator Channel (PCFICH) is a channel used for downlink transmission from the base station to the communication terminal. The PCFICH notifies the communication terminal of the number of OFDM (Orthogonal Frequency Division Multiplexing) symbols to be used for PDCCHs. The PCFICH is transmitted for each subframe.
[0008] The Physical Downlink Control Channel (PDCCH) is the channel used for downlink transmission from the base station to the communication terminal. The PDCCH notifies resource allocation information for the Downlink Shared Channel (DL-SCH), one of the transport channels described later, resource allocation information for the Paging Channel (PCH), another transport channel described later, and HARQ (Hybrid Automatic Repeat reQuest) information related to the DL-SCH. The PDCCH carries the Uplink Scheduling Grant. The PDCCH also carries Ack (Acknowledgement) / Nack (Negative Acknowledgement), which are response signals to uplink transmissions. The PDCCH is also called the L1 / L2 control signal.
[0009] The Physical Downlink Shared Channel (PDSCH) is a channel used for downlink transmission from a base station to a communication terminal. The PDSCH is mapped to the Downlink Shared Channel (DL-SCH), which is a transport channel, and the PCH, which is also a transport channel.
[0010] A physical multicast channel (PMCH) is a channel used for downlink transmission from a base station to a communication terminal. A multicast channel (MCH), which is a transport channel, is mapped to the PMCH.
[0011] The Physical Uplink Control Channel (PUCCH) is the channel used for uplink transmission from the communication terminal to the base station. The PUCCH carries the Ack / Nack response signal for downlink transmission. The PUCCH also carries Channel State Information (CSI). The CSI consists of the Rank Indicator (RI), Precoding Matrix Indicator (PMI), and Channel Quality Indicator (CQI) report. RI is the rank information of the channel matrix in MIMO. PMI is information of the precoding weight matrix used in MIMO. CQI is quality information indicating the quality of the received data or the quality of the communication channel. The PUCCH also carries a Scheduling Request (SR).
[0012] The Physical Uplink Shared Channel (PUSCH) is a channel used for uplink transmission from a communication terminal to a base station. The Uplink Shared Channel (UL-SCH), which is one of the transport channels, is mapped to the PUSCH.
[0013] The Physical Hybrid ARQ Indicator Channel (PHICH) is the channel used for downlink transmission from the base station to the communication terminal. PHICH carries the Ack / Nack, which is the response signal to uplink transmissions. The Physical Random Access Channel (PRACH) is the channel used for uplink transmission from the communication terminal to the base station. PRACH carries the random access preamble.
[0014] The downlink reference signal (RS) is a well-known symbol in LTE communication systems. Five types of downlink reference signals are defined: Cell-specific Reference Signal (CRS), MBSFN Reference Signal, UE-specific Reference Signal (UE-specific), Demodulation Reference Signal (DM-RS), Positioning Reference Signal (PRS), and Channel State Information Reference Signal (CSI-RS). One measurement of the physical layer of a communication terminal is the Reference Signal Received Power (RSRP).
[0015] Similarly, the uplink reference signals are also known symbols for LTE communication systems. Two types of uplink reference signals are defined: the Demodulation Reference Signal (DM-RS) and the Sounding Reference Signal (SRS).
[0016] This section explains the transport channel described in Non-Patent Document 1 (Chapter 5). Of the downlink transport channels, the Broadcast Channel (BCH) broadcasts to the entire coverage of the base station (cell). The BCH is mapped to the Physical Broadcast Channel (PBCH).
[0017] Downlink Shared Channels (DL-SCH) are subject to retransmission control using HARQ (Hybrid ARQ). DL-SCH can broadcast to the entire coverage of a base station (cell). DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called persistent scheduling. DL-SCH supports discontinuous reception (DRX) for communication terminals to reduce power consumption. DL-SCH is mapped to Physical Downlink Shared Channels (PDSCH).
[0018] Paging Channels (PCHs) support DRX for communication terminals to enable low power consumption for those terminals. PCHs are required to broadcast across the entire coverage of a base station (cell). PCHs are mapped to physical resources, such as Physical Downlink Shared Channels (PDSCHs), which are dynamically available for traffic.
[0019] Multicast channels (MCHs) are used for broadcasting across the entire coverage of a base station (cell). MCHs support SFN synthesis of MBMS (Multimedia Broadcast Multicast Service) services (MTCH and MCCH) in multi-cell transmission. MCHs support quasi-static resource allocation. MCHs are mapped to PMCHs.
[0020] Among the uplink transport channels, the Uplink Shared Channel (UL-SCH) is subject to retransmission control using HARQ (Hybrid ARQ). UL-SCH supports dynamic or semi-static resource allocation. UL-SCH is mapped to the Physical Uplink Shared Channel (PUSCH).
[0021] Random Access Channels (RACHs) are limited to control information. RACHs carry a risk of collisions. RACHs are mapped to Physical Random Access Channels (PRACHs).
[0022] This section explains HARQ. HARQ is a technology that improves the communication quality of a transmission path by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction works effectively through retransmission even on transmission paths where the communication quality changes. In particular, it is possible to achieve further quality improvement by combining the reception results of the initial transmission and the retransmission during retransmission.
[0023] Here is an example of how to retransmit data. If the receiving side is unable to correctly decode the received data, in other words, if a CRC (Cyclic Redundancy Check) error occurs (CRC=NG), the receiving side sends "Nack" to the sending side. Upon receiving "Nack," the sending side retransmits the data. If the receiving side is able to correctly decode the received data, in other words, if no CRC error occurs (CRC=OK), the receiving side sends "Ack" to the sending side. Upon receiving "Ack," the sending side sends the next data.
[0024] This section explains the logical channel described in Non-Patent Document 1 (Chapter 6). The Broadcast Control Channel (BCCH) is a downstream channel for broadcast system control information. The BCCH, being a logical channel, is mapped to the broadcast channel (BCH), which is a transport channel, or to the downstream shared channel (DL-SCH).
[0025] The Paging Control Channel (PCCH) is a downlink channel used to transmit changes to paging information and system information. The PCCH is used when the network does not know the cell location of a communication terminal. As a logical channel, the PCCH is mapped to the Paging Channel (PCH), which is a transport channel.
[0026] The Common Control Channel (CCCH) is a channel for transmit control information between a communication terminal and a base station. The CCCH is used when a communication terminal does not have an RRC connection with the network. In the downlink direction, the CCCH is mapped to the downlink common channel (DL-SCH), which is a transport channel. In the uplink direction, the CCCH is mapped to the uplink common channel (UL-SCH), which is a transport channel.
[0027] A Multicast Control Channel (MCCH) is a downlink channel for one-to-many transmission. MCCHs are used to transmit MBMS control information for one or more MCCHs from the network to communication terminals. MCCHs are only used by communication terminals receiving MBMS. MCCHs are mapped to the Multicast Channel (MCH), which is the transport channel.
[0028] A Dedicated Control Channel (DCCH) is a channel that transmits dedicated control information one-to-one between a communication terminal and a network. DCCH is used when a communication terminal is in an RRC connection. DCCH is mapped to the Uplink Shared Channel (UL-SCH) in the uplink, and mapped to the Downlink Shared Channel (DL-SCH) in the downlink.
[0029] A Dedicated Traffic Channel (DTCH) is a one-to-one communication channel for a dedicated communication terminal for transmitting user information. DTCH exists in both the uplink and downlink. DTCH is mapped to the Uplink Shared Channel (UL-SCH) in the uplink, and mapped to the Downlink Shared Channel (DL-SCH) in the downlink.
[0030] A Multicast Traffic Channel (MTCH) is a downlink channel for transmitting traffic data from a network to communication terminals. MTCH is a channel used only for communication terminals that are receiving MBMS. MTCH is mapped to a Multicast Channel (MCH).
[0031] CGI refers to Cell Global Identifier. ECGI refers to E-UTRAN Cell Global Identifier. In LTE, LTE-A (Long Term Evolution Advanced) which will be described later, and UMTS (Universal Mobile Telecommunication System), Closed Subscriber Group (CSG) cells are introduced.
[0032] Location tracking of communication terminals is performed in units of areas consisting of one or more cells. Location tracking is performed to track the location of communication terminals even when they are in standby mode, and to enable them to be called, in other words, to allow them to receive calls. This area used for location tracking of communication terminals is called the tracking area.
[0033] Furthermore, 3GPP is working on the Long Term Evolution Advanced (LTE-A) standard as Release 10 (see Non-Patent Documents 3 and 4). LTE-A is based on the LTE wireless communication method and incorporates several new technologies.
[0034] In LTE-A systems, carrier aggregation (CA), which involves aggregating two or more component carriers (CCs) to support wider transmission bandwidths up to 100 MHz, is being considered. CA is described in Non-Patent Document 1.
[0035] When a CA is configured, the UE has a single RRC connection to the network (NW). In the RRC connection, one serving cell provides NAS mobility information and security inputs. This cell is called the Primary Cell (PCell). On the downlink, the carrier corresponding to the PCell is the Downlink Primary Component Carrier (DL PCC). On the uplink, the carrier corresponding to the PCell is the Uplink Primary Component Carrier (UL PCC).
[0036] Depending on the capabilities of the UE, secondary cells (SCells) are configured to form a set of serving cells together with PCells. On the downlink, the carrier corresponding to the SCell is the Downlink Secondary Component Carrier (DL SCC). On the uplink, the carrier corresponding to the SCell is the Uplink Secondary Component Carrier (UL SCC).
[0037] A set of serving cells consisting of one PCell and one or more SCells is configured for a single UE.
[0038] Furthermore, new technologies in LTE-A include Wider bandwidth extension and Coordinated Multiple Point transmission and reception (CoMP) technology. The CoMP technology being considered by 3GPP for LTE-A is described in Non-Patent Document 1.
[0039] Furthermore, 3GPP is considering using small eNBs (sometimes referred to as "small-scale base station equipment") that constitute small cells to cope with the enormous traffic of the future. For example, technologies are being considered to increase communication capacity by improving frequency utilization efficiency by installing a large number of small eNBs to constitute a large number of small cells. Specifically, this includes dual connectivity (DC), in which a UE connects to and communicates with two eNBs. DC is described in Non-Patent Document 1.
[0040] In some cases, among eNBs that perform dual connectivity (DC), one is called the "master eNB (abbreviated as MeNB)" and the other is called the "secondary eNB (abbreviated as SeNB)".
[0041] Mobile network traffic is on the rise, and communication speeds are also increasing. Further speed increases are expected once LTE and LTE-A are fully operational.
[0042] Furthermore, in response to the increasing sophistication of mobile communications, a fifth-generation (sometimes referred to as "5G") wireless access system is being considered, with the goal of launching services after 2020. For example, in Europe, the METIS organization has compiled the requirements for 5G (see Non-Patent Document 5).
[0043] In 5G wireless access systems, the requirements include achieving 1000 times the system capacity, 100 times the data transmission speed, one-tenth (1 / 10) the data processing delay, and 100 times the number of simultaneous connections for communication terminals compared to LTE systems, while also achieving further reductions in power consumption and equipment costs.
[0044] To meet these requirements, 3GPP is working on the 5G standard as Release 15 (see Non-Patent Documents 6-18). The technology for the wireless portion of 5G is called "New Radio Access Technology" ("New Radio" is abbreviated as "NR").
[0045] The NR system is being developed based on the LTE system and LTE-A system, but the following changes and additions have been made compared to the LTE system and LTE-A system.
[0046] For NR access, OFDM is used for the downstream direction, and OFDM and DFT-s-OFDM (DFT-spread-OFDM) are used for the upstream direction.
[0047] NR allows for the use of higher frequencies compared to LTE, in order to improve transmission speed and reduce processing delays.
[0048] In NR (Noise Reduction), cell coverage is ensured by forming a narrow beam-shaped transmission and reception range (beamforming) and changing the direction of the beam (beam sweeping).
[0049] In NR's frame configuration, various subcarrier intervals, i.e., various numerologies, are supported. In NR, regardless of the numerology, one subframe is 1 millisecond, and one slot consists of 14 symbols. Furthermore, the number of slots contained in one subframe is one for a numerology with a subcarrier interval of 15 kHz, and increases proportionally with the subcarrier interval for other numerologies (see Non-Patent Document 13 (TS38.211 V16.0.0)).
[0050] In NR, the downlink synchronization signal is transmitted from the base station as a synchronization signal burst (SS burst) at a predetermined period and for a predetermined duration. The SS burst consists of a synchronization signal block (SS block) for each beam of the base station. The base station transmits the SS block for each beam, changing beams within the duration of the SS burst. The SS block consists of P-SS, S-SS, and PBCH.
[0051] In noise reduction (NR), the effect of phase noise is reduced by adding a Phase Tracking Reference Signal (PTRS) as the downstream reference signal. Similarly, a PTRS is also added to the upstream reference signal.
[0052] In NR, Slot Format Indication (SFI) information has been added to the PDCCH to allow for flexible switching between DL / UL within a slot.
[0053] Furthermore, in NR, the base station pre-configures a portion of the carrier frequency band (hereinafter sometimes referred to as the Bandwidth Part (BWP)) for the UE, and the UE performs transmission and reception with the base station in the BWP, thereby reducing the power consumption of the UE.
[0054] 3GPP is considering several data center configurations, including a data center with LTE and NR base stations connected to an EPC, a data center with NR base stations connected to a 5G core system, and a data center with LTE and NR base stations connected to a 5G core system (see Non-Patent Documents 12, 16, and 19).
[0055] Furthermore, 3GPP is considering several new technologies. For example, RAN slicing, which allocates RAN (Radio Access Network) resources exclusively for each communication service, is being considered (see Non-Patent Documents 16, 20, and 21). Note that RAN resources allocated exclusively for each communication service are sometimes referred to as RAN slices. In addition, support for services using side-link (SL) communication is being considered in both EPS and 5G core systems (see Non-Patent Documents 1, 22, 26, 27, and 28). Examples of services using SL communication include V2X services and proximity services. [Prior art documents] [Non-patent literature]
[0056] [Non-Patent Document 1] 3GPP TS 36.300 V16.0.0 [Non-Patent Document 2] 3GPP S1-083461 [Non-Patent Document 3] 3GPP TR 36.814 V9.2.0
Non-licensed Document 4
Non-licensed Document 5
Non-licensed Document 6
Non-licensed Document 7
Non-licensed Document 8
Non-licensed literature 9
Non-licensed literature 10
Non-licensed Document 11
Non-licensed Document 12
Non-licensed Document 13
Non-licensed Document 14
Non-licensed Document 15
Non-licensed Document 16
Non-licensed Document 17
Non-licensed Document 18
Non-licensed Document 19
[0057] During UE registration with the network, the UE notifies the AMF of the RAN slice it wishes to use for communication. The AMF uses this notification and the RAN slices supported by the cell to which the UE is connected to determine which RAN slices the UE is permitted to use for communication. However, there may be cases where the UE's cell selection and / or cell re-selection do not support the UE's desired slice. In this case, the AMF will not permit registration using the UE's desired slice. As a result, the UE will be unable to communicate using the desired slice. Consequently, there is a risk that the quality of service (QoS) of communication may not be ensured.
[0058] Furthermore, support for various services using SL communication (also known as PC5 communication) is being considered in both EPS and 5G core systems (Non-Patent Documents 1, 20, 21, 22, 23). In SL communication, communication takes place between terminals. In SL communication, not only direct communication between terminals but also indirect communication via relays has been proposed (Non-Patent Document 24). In such indirect communication via relays, the issues are how to satisfy the QoS required for the service, how to improve the reliability of the service, and how to improve the utilization efficiency of resources used for SL communication.
[0059] In light of the above-mentioned issues, one of the objectives of this disclosure is to provide good communication by ensuring the QoS required for the service. [Means for solving the problem]
[0060] The communication system according to this disclosure comprises a communication terminal device and a base station device that performs wireless communication with the communication terminal device. The communication terminal device is configured to receive a System Information Block (SIB) from the base station device, which contains first information relating to a slice of a Radio Access Network (RAN). The first information includes second information relating a cell to a plurality of slices supported in that cell. The communication terminal device is configured to reselect a cell using the second information and to transmit a random access preamble to the reselected cell, which contains information indicating a desired plurality of slices. [Effects of the Invention]
[0061] According to this disclosure, good communication can be provided.
[0062] The purpose, features, aspects, and advantages of this disclosure will become more apparent from the following detailed description and accompanying drawings. [Brief explanation of the drawing]
[0063] [Figure 1] This is an explanatory diagram showing the configuration of wireless frames used in LTE communication systems. [Figure 2] This block diagram shows the overall configuration of the LTE communication system 200 as discussed in 3GPP. [Figure 3] This is a block diagram showing the overall configuration of the NR communication system 210 as discussed in 3GPP. [Figure 4] This is a diagram illustrating the configuration of a data center using eNBs and gNBs connected to the EPC. [Figure 5] This is a diagram showing the configuration of the DC using gNB connected to the NG core. [Figure 6] This is a diagram showing the configuration of the DC with eNBs and gNBs connected to the NG core. [Figure 7] This is a diagram showing the configuration of the DC with eNBs and gNBs connected to the NG core. [Figure 8] Figure 2 is a block diagram showing the configuration of the mobile terminal 202. [Figure 9] Figure 2 is a block diagram showing the configuration of base station 203. [Figure 10] This block diagram shows the configuration of MME. [Figure 11] This is a block diagram showing the configuration of 5GC. [Figure 12] This is a flowchart illustrating the general process from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. [Figure 13] This figure shows an example of a cell configuration in an NR system. [Figure 14] This sequence diagram illustrates an example of the operation in Embodiment 1, in which the UE uses broadcast information from the base station to connect to a base station capable of supporting the desired slice. [Figure 15] This figure illustrates an example of allocating supported RAN slices to PCI in Embodiment 1. [Figure 16]This is a sequence diagram illustrating the operation of the UE in Embodiment 1, where the UE connects to a base station capable of supporting the desired slice using the cell's PCI. [Figure 17] This is a sequence diagram illustrating the operation of the UE in Embodiment 1, where the UE connects to a base station capable of supporting the desired slice using a random access response from a base station. [Figure 18] This is a sequence diagram showing the operation of the base station in determining whether or not to register the UE in Embodiment 1. [Figure 19] The second embodiment is a sequence diagram illustrating an example of an operation in which a UE connected to a base station that does not support the desired slice handover to a base station that does support the desired slice. [Figure 20] The second embodiment is a sequence diagram illustrating an example of an operation in which a UE connected to a base station that does not support the desired slice handover to a base station that does support the desired slice. [Figure 21] The second embodiment is a sequence diagram showing a first example of the operation in which a UE connected to a base station that does not support the desired slice reconnects to a base station that does support the desired slice. [Figure 22] The second embodiment is a sequence diagram showing a first example of the operation in which a UE connected to a base station that does not support the desired slice reconnects to a base station that does support the desired slice. [Figure 23] The second embodiment is a sequence diagram showing a second example of the operation in which a UE connected to a base station that does not support the desired slice reconnects to a base station that does support the desired slice. [Figure 24] The second embodiment is a sequence diagram showing a second example of the operation in which a UE connected to a base station that does not support the desired slice reconnects to a base station that does support the desired slice. [Figure 25] This sequence diagram shows an example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, according to Embodiment 4. [Figure 26]This sequence diagram shows an example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, according to a modified example 1 of Embodiment 4. [Figure 27] This sequence diagram shows an example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, according to a modified example 7 of Embodiment 4. [Figure 28] This sequence diagram shows an example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, according to a modified example 7 of Embodiment 4. [Figure 29] This sequence diagram shows an example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, according to a modified example 7 of Embodiment 4. [Figure 30] This sequence diagram shows a first example of a method for setting QoS and SLRB in indirect communication between UEs via a relay UE, as shown in Modification 8 of Embodiment 4. [Figure 31] This sequence diagram shows a first example of a method for setting QoS and SLRB in indirect communication between UEs via a relay UE, as shown in Modification 8 of Embodiment 4. [Figure 32] This sequence diagram shows a second example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, as shown in Modification 8 of Embodiment 4. [Figure 33] This sequence diagram shows a second example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, as shown in Modification 8 of Embodiment 4. [Figure 34] This sequence diagram shows a third example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, as shown in Modification 8 of Embodiment 4. [Figure 35] This sequence diagram shows a third example of how to configure QoS and SLRB in indirect communication between UEs via a relay UE, as shown in Modification 8 of Embodiment 4. [Figure 36] This sequence diagram shows a first example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, as shown in a modified example 9 of Embodiment 4. [Figure 37] This sequence diagram shows a first example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, as shown in a modified example 9 of Embodiment 4. [Figure 38] This sequence diagram shows a second example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 39] This sequence diagram shows a second example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 40] This sequence diagram shows a third example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 41] This sequence diagram shows a third example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 42] This sequence diagram shows a first example of how to set up the SLRB when an HO occurs at UE-TX in indirect UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 43] This sequence diagram shows a first example of how to set up the SLRB when an HO occurs at UE-TX in indirect UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 44] This sequence diagram shows a second example of how to set up the SLRB when an HO occurs at UE-TX in indirect UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 45] This sequence diagram shows a second example of how to set up the SLRB when an HO occurs at UE-TX in indirect UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 46] This sequence diagram shows a second example of how to set up the SLRB when an HO occurs at UE-TX in indirect UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 47] This sequence diagram shows a second example of how to set up the SLRB when an HO occurs at UE-TX in indirect UE-to-UE communication using SL, as shown in the modified example 9 of Embodiment 4. [Figure 48] This sequence diagram shows a first example of a method for notifying a UE-TX of an SLRB setting to a UE-RX in indirect UE-to-UE communication using SL, as a modified example 10 of Embodiment 4. [Figure 49] This sequence diagram shows a second example of a method for notifying a UE-TX to a UE-RX of SLRB settings in indirect UE-to-UE communication using SL, as a modified example 10 of Embodiment 4. [Modes for carrying out the invention]
[0064] Embodiment 1. Figure 2 is a block diagram showing the overall configuration of the LTE communication system 200 being discussed in 3GPP. Figure 2 will be explained below. The radio access network is called E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201. The mobile terminal equipment (hereinafter referred to as "User Equipment: UE") 202, which is a communication terminal device, can communicate wirelessly with the base station equipment (hereinafter referred to as "Base Station (E-UTRAN NodeB: eNB)") 203 and transmits and receives signals wirelessly.
[0065] Here, "communication terminal equipment" includes not only mobile terminal equipment such as portable mobile phone terminal equipment, but also stationary devices such as sensors. In the following explanation, "communication terminal equipment" may sometimes be simply referred to as "communication terminal."
[0066] If the control protocol for the mobile terminal 202, such as RRC (Radio Resource Control), and the user plane (hereinafter sometimes referred to as U-Plane), such as PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), are terminated at base station 203, then E-UTRAN is composed of one or more base stations 203.
[0067] The control protocol RRC (Radio Resource Control) between the mobile terminal 202 and the base station 203 performs functions such as broadcasting, paging, and RRC connection management. The states of the base station 203 and the mobile terminal 202 in RRC are RRC_IDLE and RRC_CONNECTED.
[0068] In RRC_IDLE mode, tasks such as PLMN (Public Land Mobile Network) selection, System Information (SI) notification, paging, cell re-selection, and mobility are performed. In RRC_CONNECTED mode, mobile terminals have an RRC connection and can send and receive data with the network. In RRC_CONNECTED mode, tasks such as handover (HO) and neighbor cell measurement are also performed.
[0069] Base station 203 consists of one or more eNB207 units. The system, comprising the core network EPC (Evolved Packet Core) and the wireless access network E-UTRAN201, is called EPS (Evolved Packet System). The EPC and E-UTRAN201 are sometimes collectively referred to as the "network."
[0070] The eNB207 is connected via an S1 interface to a Mobility Management Entity (MME), or a Serving Gateway (S-GW), or an MME / S-GW unit (hereinafter sometimes referred to as "MME unit") 204 that includes both an MME and an S-GW, and control information is communicated between the eNB207 and the MME unit 204. Multiple MME units 204 may be connected to a single eNB207. The eNB207s are connected to each other via an X2 interface, and control information is communicated between the eNB207s.
[0071] The MME unit 204 controls the connection between the higher-level device, specifically the higher-level node, which is the base station eNB 207, and the mobile terminal (UE) 202. The MME unit 204 constitutes the core network EPC. The base station 203 constitutes the E-UTRAN 201.
[0072] The base station 203 may constitute one cell or multiple cells. Each cell has a predetermined range called coverage, which is the range within which it can communicate with the mobile terminal 202, and wireless communication is performed with the mobile terminal 202 within that coverage. When one base station 203 constitutes multiple cells, each cell is configured to communicate with the mobile terminal 202.
[0073] Figure 3 is a block diagram showing the overall configuration of the 5G communication system 210 being discussed in 3GPP. Figure 3 will now be explained. The radio access network is called NG-RAN (Next Generation Radio Access Network) 211. UE 202 can communicate wirelessly with NR base station equipment (hereinafter referred to as "NR base station (NG-RAN NodeB: gNB)") 213 and transmits and receives signals wirelessly. The core network is called the 5G Core (5GC).
[0074] If the control protocol for UE202, such as RRC (Radio Resource Control), and the user plane (hereinafter sometimes referred to as U-Plane), such as SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), are terminated at the NR base station 213, then the NG-RAN is composed of one or more NR base stations 213.
[0075] The functionality of the Radio Resource Control (RRC) control protocol between UE202 and NR base station 213 is the same as in LTE. The states of NR base station 213 and UE202 in RRC are RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE.
[0076] RRC_IDLE and RRC_CONNECTED are the same as in the LTE system. RRC_INACTIVE means that the connection between the 5G core and NR base station 213 is maintained while system information (SI) broadcasting, paging, cell re-selection, and mobility are performed.
[0077] The gNB217 is connected via an NG interface to an Access and Mobility Management Function (AMF), a Session Management Function (SMF), or a User Plane Function (UPF), or an AMF / SMF / UPF unit (hereinafter sometimes referred to as the "5GC unit") 214 that includes AMF, SMF, and UPF. Control information and / or user data are communicated between the gNB217 and the 5GC unit 214. The NG interface is a collective term for the N2 interface between the gNB217 and AMF, the N3 interface between the gNB217 and UPF, the N11 interface between AMF and SMF, and the N4 interface between UPF and SMF. Multiple 5GC units 214 may be connected to a single gNB217. The gNB217s are connected to each other via an Xn interface, and control information and / or user data are communicated between them.
[0078] Like base station 203, NR base station 213 may also consist of one or more cells. When one NR base station 213 consists of multiple cells, each cell is configured to communicate with UE 202.
[0079] The gNB217 may be divided into a Central Unit (CU) 218 and a Distributed Unit (DU) 219. One CU218 is configured within the gNB217. One or more DU219s are configured within the gNB217. The CU218 is connected to the DU219 via an F1 interface, and control information and / or user data are communicated between the CU218 and the DU219.
[0080] In a 5G communication system, the Unified Data Management (UDM) function and Policy Control Function (PCF) described in Non-Patent Document 27 (3GPP TS23.501 V16.3.0) may be included. The UDM and / or PCF may be included in the 5GC section in Figure 3.
[0081] In a 5G communication system, the Non-3GPP Interworking Function (N3IWF) described in Non-Patent Document 27 (3GPP TS23.501 V16.3.0) may be included. In non-3GPP access with the UE, the N3IWF may terminate the Access Network (AN) with the UE.
[0082] Figure 4 shows the configuration of a DC with eNBs and gNBs connected to the EPC. In Figure 4, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 4, eNB223-1 acts as the master base station, and gNB224-2 acts as the secondary base station (this DC configuration is sometimes referred to as EN-DC). Figure 4 shows an example where the U-Plane connection between the MME unit 204 and gNB224-2 is made via eNB223-1, but it may also be made directly between the MME unit 204 and gNB224-2.
[0083] Figure 5 shows the configuration of a DC with gNBs connected to the NG core. In Figure 5, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 5, gNB224-1 acts as the master base station, and gNB224-2 acts as the secondary base station (this DC configuration is sometimes referred to as NR-DC). Figure 5 shows an example where the U-Plane connection between 5GC unit 214 and gNB224-2 is made via gNB224-1, but it may also be made directly between 5GC unit 214 and gNB224-2.
[0084] Figure 6 shows the configuration of a DC with eNBs and gNBs connected to the NG core. In Figure 6, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 6, eNB226-1 acts as the master base station, and gNB224-2 acts as the secondary base station (this DC configuration is sometimes referred to as NG-EN-DC). Figure 6 shows an example where the U-Plane connection between 5GC unit 214 and gNB224-2 is made via eNB226-1, but it may also be made directly between 5GC unit 214 and gNB224-2.
[0085] Figure 7 shows another configuration of a DC with eNBs and gNBs connected to the NG core. In Figure 7, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 7, gNB224-1 acts as the master base station, and eNB226-2 acts as the secondary base station (this DC configuration is sometimes referred to as NE-DC). Figure 7 shows an example where the U-Plane connection between 5GC unit 214 and eNB226-2 is made via gNB224-1, but it may also be made directly between 5GC unit 214 and eNB226-2.
[0086] Figure 8 is a block diagram showing the configuration of the mobile terminal 202 shown in Figure 2. The transmission process of the mobile terminal 202 shown in Figure 8 will now be explained. First, control data from the protocol processing unit 301 and user data from the application unit 302 are stored in the transmission data buffer unit 303. The data stored in the transmission data buffer unit 303 is passed to the encoder unit 304, where encoding processing such as error correction is performed. There may be data that is output directly from the transmission data buffer unit 303 to the modulation unit 305 without undergoing encoding processing. The data encoded by the encoder unit 304 is then modulated in the modulation unit 305. Precoding in MIMO may be performed in the modulation unit 305. The modulated data is converted into a baseband signal, then output to the frequency conversion unit 306, where it is converted to a wireless transmission frequency. After that, the transmission signal is sent from antennas 307-1 to 307-4 to the base station 203. Figure 8 illustrates the case where there are four antennas, but the number of antennas is not limited to four.
[0087] Furthermore, the reception processing of the mobile terminal 202 is performed as follows: A radio signal from the base station 203 is received by antennas 307-1 to 307-4. The received signal is converted from the radio reception frequency to a baseband signal by the frequency conversion unit 306, and demodulation processing is performed by the demodulation unit 308. Weight calculation and multiplication processing may also be performed in the demodulation unit 308. The demodulated data is passed to the decoder unit 309, where decoding processing such as error correction is performed. Of the decoded data, the control data is passed to the protocol processing unit 301, and the user data is passed to the application unit 302. The series of processes of the mobile terminal 202 are controlled by the control unit 310. Therefore, although the control unit 310 is omitted in Figure 8, it is connected to each of the units 301 to 309. In Figure 8, the number of antennas used by the mobile terminal 202 for transmission and the number of antennas used for reception may be the same or different.
[0088] Figure 9 is a block diagram showing the configuration of the base station 203 shown in Figure 2. The transmission process of the base station 203 shown in Figure 9 will now be explained. The EPC communication unit 401 transmits and receives data between the base station 203 and the EPC (MME unit 204, etc.). The 5GC communication unit 412 transmits and receives data between the base station 203 and the 5GC (5GC unit 214, etc.). The other base station communication unit 402 transmits and receives data with other base stations. The EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402 each exchange information with the protocol processing unit 403. Control data from the protocol processing unit 403, as well as user data and control data from the EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402, are stored in the transmission data buffer unit 404.
[0089] The data stored in the transmission data buffer unit 404 is passed to the encoder unit 405, where it undergoes encoding processing such as error correction. Some data may be output directly from the transmission data buffer unit 404 to the modulation unit 406 without undergoing encoding processing. The encoded data is then modulated in the modulation unit 406. Precoding in MIMO may be performed in the modulation unit 406. The modulated data is converted to a baseband signal, then output to the frequency conversion unit 407, where it is converted to a wireless transmission frequency. Subsequently, the transmission signal is sent from antennas 408-1 to 408-4 to one or more mobile terminals 202. Figure 9 illustrates the case with four antennas, but the number of antennas is not limited to four.
[0090] Furthermore, the reception processing of the base station 203 is performed as follows: A radio signal from one or more mobile terminals 202 is received by the antenna 408. The received signal is converted from the radio reception frequency to a baseband signal by the frequency conversion unit 407, and demodulation processing is performed by the demodulation unit 409. The demodulated data is passed to the decoder unit 410, where decoding processing such as error correction is performed. Of the decoded data, the control data is passed to the protocol processing unit 403, the 5GC communication unit 412, the EPC communication unit 401, or the other base station communication unit 402, while the user data is passed to the 5GC communication unit 412, the EPC communication unit 401, and the other base station communication unit 402. The series of processes of the base station 203 are controlled by the control unit 411. Therefore, although the control unit 411 is omitted in Figure 9, it is connected to each of the units 401 to 410. In Figure 9, the number of antennas used by the base station 203 for transmission and the number of antennas used for reception may be the same or different.
[0091] Figure 9 is a block diagram showing the configuration of base station 203, but base station 213 may have a similar configuration. Also, in Figures 8 and 9, the number of antennas on mobile terminal 202 and base station 203 may be the same or different.
[0092] Figure 10 is a block diagram showing the configuration of the MME. Figure 10 shows the configuration of the MME204a included in the MME unit 204 shown in Figure 2 above. The PDN GW communication unit 501 transmits and receives data between the MME204a and the PDN GW. The base station communication unit 502 transmits and receives data between the MME204a and the base station 203 via the S1 interface. If the data received from the PDN GW is user data, the user data is passed from the PDN GW communication unit 501 to the base station communication unit 502 via the user-plane communication unit 503 and transmitted to one or more base stations 203. If the data received from the base station 203 is user data, the user data is passed from the base station communication unit 502 to the PDN GW communication unit 501 via the user-plane communication unit 503 and transmitted to the PDN GW.
[0093] If the data received from the PDN GW is control data, the control data is passed from the PDN GW communication unit 501 to the control plane control unit 505. If the data received from the base station 203 is control data, the control data is passed from the base station communication unit 502 to the control plane control unit 505.
[0094] The control plane control unit 505 includes the NAS security unit 505-1, the SAE bearer control unit 505-2, and the idle state mobility management unit 505-3, and performs all processing for the control plane (hereinafter sometimes referred to as C-Plane). The NAS security unit 505-1 performs security for NAS (Non-Access Stratum) messages, etc. The SAE bearer control unit 505-2 performs management of SAE (System Architecture Evolution) bearers, etc. The idle state mobility management unit 505-3 performs mobility management in the standby state (also called LTE-IDLE state or simply idle), generation and control of paging signals in the standby state, addition, deletion, updating, searching, and tracking area management for one or more mobile terminals 202 under its umbrella.
[0095] The MME204a distributes paging signals to one or more base stations 203. The MME204a also performs mobility control in the idle state. The MME204a manages the tracking area list when the mobile terminal is in the idle state and when it is in the active state. The MME204a initiates the paging protocol by sending paging messages to cells belonging to the registered tracking area of the UE. The management of the CSG, CSG ID, and whitelist of the eNB207 connected to the MME204a may be performed by the idle state mobility management unit 505-3.
[0096] Figure 11 is a block diagram showing the configuration of the 5GC. Figure 11 shows the configuration of the 5GC unit 214 shown in Figure 3. Figure 11 shows the case where the 5GC unit 214 shown in Figure 5 includes the configurations of AMF, SMF, and UPF. The Data Network communication unit 521 transmits and receives data between the 5GC unit 214 and the Data Network. The base station communication unit 522 transmits and receives data via the S1 interface between the 5GC unit 214 and the base station 203, and / or the NG interface between the 5GC unit 214 and the base station 213. If the data received from the Data Network is user data, the user data is passed from the Data Network communication unit 521 to the base station communication unit 522 via the user-plane communication unit 523, and transmitted to one or more base stations 203 and / or base station 213. If the data received from base station 203 and / or base station 213 is user data, the user data is passed from base station communication unit 522 to Data Network communication unit 521 via user plane communication unit 523 and transmitted to the Data Network.
[0097] If the data received from the Data Network is control data, the control data is passed from the Data Network communication unit 521 to the session management unit 527 via the user-plane communication unit 523. The session management unit 527 passes the control data to the control-plane control unit 525. If the data received from base station 203 and / or base station 213 is control data, the control data is passed from base station communication unit 522 to the control-plane control unit 525. The control-plane control unit 525 passes the control data to the session management unit 527.
[0098] The control plane control unit 525 includes the NAS security unit 525-1, the PDU session control unit 525-2, and the idle state mobility management unit 525-3, and performs all processing for the control plane (hereinafter sometimes referred to as C-Plane). The NAS security unit 525-1 performs security for NAS (Non-Access Stratum) messages, etc. The PDU session control unit 525-2 manages PDU sessions between the mobile terminal 202 and the 5GC unit 214, etc. The idle state mobility management unit 525-3 performs mobility management in the standby state (also referred to as RRC_IDLE state or simply idle), generation and control of paging signals in the standby state, addition, deletion, updating, searching, and tracking area list management for one or more mobile terminals 202 under its umbrella.
[0099] The 5GC unit 214 distributes paging signals to one or more base stations 203 and / or base station 213. The 5GC unit 214 also performs mobility control in the idle state. The 5GC unit 214 manages the tracking area list when the mobile terminal is in the idle state, inactive state, and active state. The 5GC unit 214 initiates the paging protocol by sending a paging message to a cell belonging to the tracking area where the UE is registered.
[0100] Next, an example of a cell search method in a communication system is shown. Figure 12 is a flowchart illustrating the process from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. When the communication terminal starts a cell search, in step ST601, it synchronizes the slot timing and frame timing using the first synchronization signal (P-SS) and the second synchronization signal (S-SS) transmitted from the surrounding base station.
[0101] P-SS and S-SS together are called the Synchronization Signal (SS). Each PCI assigned to a cell has a synchronization code that corresponds one-to-one with that PCI. 504 different PCI combinations are being considered. These 504 PCI combinations are used for synchronization, and the PCI of the synchronized cell is detected (identified).
[0102] Next, for the synchronized cell, step ST602 detects the cell-specific reference signal (CRS), which is a reference signal (RS) transmitted from the base station to each cell, and measures the received power (RSRP) of the RS. The reference signal (RS) uses a code that corresponds one-to-one with the PCI. By correlating with this code, it is possible to isolate it from other cells. By deriving the code for the RS of the cell from the PCI identified in step ST601, it becomes possible to detect the RS and measure the received power of the RS.
[0103] Next, in step ST603, from among the one or more cells detected up to step ST602, the cell with the best RS reception quality, for example, the cell with the highest RS reception power, i.e., the best cell, is selected.
[0104] Next, in step ST604, the PBCH of the best cell is received to obtain the broadcast information, which is the BCCH. The BCCH on the PBCH is mapped to the MIB (Master Information Block), which contains cell configuration information. Therefore, by receiving the PBCH and obtaining the BCCH, the MIB can be obtained. MIB information includes, for example, the DL (downlink) system bandwidth (also called transmission bandwidth configuration: dl-bandwidth), the number of transmitting antennas, and the SFN (System Frame Number).
[0105] Next, in step ST605, the DL-SCH of the cell is received based on the cell configuration information of the MIB, and SIB (System Information Block) 1 is obtained from the broadcast information BCCH. SIB1 contains information about accessing the cell, information about cell selection, and scheduling information for other SIBs (SIBk; an integer k ≥ 2). SIB1 also contains the Tracking Area Code (TAC).
[0106] Next, in step ST606, the communication terminal compares the TAC of the SIB1 received in step ST605 with the TAC portion of the Tracking Area Identity (TAI) in the Tracking Area List already held by the communication terminal. The Tracking Area List is also called the TAI list. TAI is identification information for identifying a tracking area and consists of MCC (Mobile Country Code), MNC (Mobile Network Code), and TAC (Tracking Area Code). MCC is the country code. MNC is the network code. TAC is the code number of the tracking area.
[0107] If, as a result of the comparison in step ST606, the TAC received in step ST605 is the same as a TAC included in the tracking area list, the communication terminal enters a waiting state in that cell. If, after comparison, the TAC received in step ST605 is not included in the tracking area list, the communication terminal requests a change in the tracking area through that cell to the Core Network (EPC), which includes the MME, etc., in order to perform a Tracking Area Update (TAU).
[0108] In the example shown in Figure 12, an example of the operation from cell search to standby in the LTE system is shown. However, in the NR system, in step ST603, the best beam may be selected in addition to the best cell. Also in the NR system, in step ST604, beam information, such as a beam identifier, may be obtained. Also in the NR system, in step ST604, scheduling information for the Remaining Minimum SI (RMSI) may be obtained. In the NR system, in step ST605, the RMSI may be received.
[0109] The devices constituting the core network (sometimes referred to as "core network devices") update the tracking area list based on the identification number (UE-ID, etc.) of the communication terminal sent from the communication terminal along with the TAU request signal. The core network devices send the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) its TAC list based on the received tracking area list. After that, the communication terminal enters a waiting state in that cell.
[0110] The proliferation of smartphones and tablet devices has led to an explosive increase in cellular wireless communication traffic, raising concerns about a shortage of wireless resources worldwide. To address this, efforts are being made to improve frequency utilization efficiency by reducing the number of cells and promoting spatial separation.
[0111] In conventional cell configurations, cells composed of eNBs have relatively wide coverage. Traditionally, cells are configured to cover a certain area through the relatively wide coverage of multiple cells composed of multiple eNBs.
[0112] When subdivided into smaller cells, the cells composed of eNBs have narrower coverage than cells composed of conventional eNBs. Therefore, as before, a larger number of subdivided eNBs are needed to cover a given area compared to conventional eNBs.
[0113] In the following explanation, cells with relatively high coverage, such as those composed of conventional eNBs, will be referred to as "macrocells," and the eNBs that make up macrocells will be referred to as "macro eNBs." Similarly, cells with relatively low coverage, such as those that have been resized into smaller cells, will be referred to as "small cells," and the eNBs that make up small cells will be referred to as "small eNBs."
[0114] Macro eNB may be, for example, a "Wide Area Base Station" as described in Non-Patent Document 7.
[0115] A small eNB may be, for example, a low-power node, a local area node, or a hotspot. Alternatively, a small eNB may be a pico eNB constituting a picocell, a femto eNB constituting a femtocell, a HeNB, an RRH (Remote Radio Head), an RRU (Remote Radio Unit), an RRE (Remote Radio Equipment), or an RN (Relay Node). Furthermore, a small eNB may be a "Local Area Base Station" or "Home Base Station" as described in Non-Patent Document 7.
[0116] Figure 13 shows an example of a cell configuration in NR. In an NR cell, a narrow beam is formed and transmitted by changing its direction. In the example shown in Figure 13, base station 750 uses beam 751-1 to transmit and receive with a mobile terminal at a certain time. At other times, base station 750 uses beam 751-2 to transmit and receive with a mobile terminal. Similarly, base station 750 uses one or more of beams 751-3 to 751-8 to transmit and receive with a mobile terminal. In this way, base station 750 configures a wide-area cell.
[0117] Figure 13 shows an example where the base station 750 uses eight beams, but the number of beams may be different from eight. Also, in the example shown in Figure 13, the base station 750 uses one beam simultaneously, but it may use multiple beams.
[0118] In 3GPP, Side Link (SL) is supported for D2D (Device to Device) and V2V (Vehicle to Vehicle) communication (see Non-Patent Document 1). SL is defined by the PC5 interface.
[0119] The physical channels used in SL (see Non-Patent Document 1) are described below. The Physical Sidelink Broadcast Channel (PSBCH) carries system and synchronization-related information and is transmitted from the UE.
[0120] The Physical Sidelink Discovery Channel (PSDCH) carries sidelink discovery messages from the UE (Union Engine).
[0121] The Physical Sidelink Control Channel (PSCCH) carries control information from the UE for sidelink communication and V2X sidelink communication.
[0122] The Physical Sidelink Shared Channel (PSSCH) carries data from the UE for sidelink communication and V2X sidelink communication.
[0123] The transport channels used in SL (see Non-Patent Document 1) are described below. The Sidelink broadcast channel (SL-BCH) has a predetermined transport format and is mapped to the physical channel PSBCH.
[0124] The Sidelink Discovery Channel (SL-DCH) has periodic broadcast transmissions in a fixed size and predetermined format. The SL-DCH supports both UE autonomous resource selection and resource allocation scheduled by the eNB. UE autonomous resource selection carries a risk of collisions, while there are no collisions when the UE allocates individual resources via the eNB. The SL-DCH supports HARQ combining but not HARQ feedback. The SL-DCH is mapped to the physical channel PSDCH.
[0125] Sidelink shared channels (SL-SCH) support broadcast transmission. SL-SCH supports both UE autonomous resource selection and resource allocation scheduled by the eNB. UE autonomous resource selection carries a collision risk, while there is no collision when the UE allocates individual resources via the eNB. SL-SCH also supports HARQ combining but not HARQ feedback. Furthermore, SL-SCH supports dynamic link adaptation by changing transmit power, modulation, and coding. SL-SCH is mapped to the physical channel PSSCH.
[0126] This section describes the logical channels used in SL (see Non-Patent Document 1). The Sidelink Broadcast Control Channel (SBCCH) is a sidelink channel used to broadcast sidelink system information from one UE to another. The SBCCH is mapped to the transport channel SL-BCH.
[0127] A Sidelink Traffic Channel (STCH) is a one-to-many sidelink traffic channel for transmitting user information from one UE to another. STCH is used only between UEs with sidelink communication capabilities and UEs with V2X sidelink communication capabilities. One-to-one communication between two UEs with sidelink communication capabilities is also achieved via STCH. STCH is mapped to the transport channel SL-SCH.
[0128] 3GPP is considering supporting V2X communication in NR as well. The study of V2X communication in NR is progressing based on the LTE system and LTE-A system, but the following changes and additions have been made from the LTE system and LTE-A system.
[0129] In LTE, SL communication was limited to broadcast only. In NR, support for unicast and groupcast in addition to broadcast is being considered for SL communication (see Non-Patent Document 21 (TS23.287)).
[0130] Support for HARQ feedback (Ack / Nack) and CSI reporting is being considered for unicast and groupcast communications.
[0131] In SL communication, in addition to broadcast, support for unicast and groupcast is being considered, and therefore support for PC5-S signaling is being explored (see Non-Patent Document 21 (TS23.287)). For example, PC5-S signaling is implemented to establish a link for SL, i.e., PC5 communication. This link is implemented at the V2X layer and is also referred to as a Layer 2 link.
[0132] Furthermore, support for RRC signaling in SL communication is being considered (see Non-Patent Document 21 (TS23.287)). RRC signaling in SL communication is also referred to as PC5 RRC signaling. For example, it has been proposed to notify UEs of their capabilities between UEs performing PC5 communication, and to notify AS layer settings for performing V2X communication using PC5 communication.
[0133] During UE registration with the NW, the UE notifies the AMF of the RAN slice it wishes to use for communication (hereinafter sometimes referred to as the desired slice). The UE may include information about the desired slice, such as S-NSSAI (Single Network Slice Selection Assistance Information), in the requested NSSAI (requested Network Slice Selection Assistance Information). This notification may be made via the base station. The AMF may use this notification to determine which RAN slices to allow the UE to communicate. The AMF may use information about the RAN slices supported by the cell to which the UE is connected in its determination. The AMF may notify the UE of the permitted RAN slices via the base station. The AMF may notify the UE of the permitted RAN slices as an Allowed NSSAI. The UE may use the RAN slices permitted by the AMF for communication with the NW.
[0134] As described above, the following problem arises: the cells selected and / or re-selected by the UE may not support the UE's desired slice. In this case, the AMF will not allow registration using the UE's desired slice. As a result, the UE will be unable to communicate using the desired slice. Consequently, the QoS of communication may not be ensured, potentially leading to problems such as being unable to achieve the desired communication rate or meet the desired latency.
[0135] This first embodiment discloses a method for solving the aforementioned problems.
[0136] The base station broadcasts information about one or more RAN slices that it can support. This information may, for example, be information about S-NSSAI (Single Network Slice Selection Assistance Information) that the base station can support. This information may include information about SST (Slice / Service Type), information about SD (Slice Differentiator), or both of the above.
[0137] The information may include information about one or more RAN slices supported by a cell within the base station. It may also include information about the cell, such as its identifier (e.g., PCI). It may also include information about a combination of the cell and the RAN slices supported by the cell.
[0138] The information may include details about one or more RAN slices supported by other cells within the base station. This allows, for example, the UE to quickly re-select a cell that supports a desired RAN slice.
[0139] Information regarding RAN slices supported by other cells within the same base station may be associated with information about those cells. This association may be, for example, in the form of a list. The list may include information about RAN slices supported by the cell itself.
[0140] The information may include information about one or more RAN slices supported by a DU within the base station. It may also include information about the DU, such as the DU's identifier (e.g., DU-ID). It may also include information about a combination of the information about the DU and the information about the RAN slices supported by the DU.
[0141] The information may include details about one or more RAN slices supported by other DUs within the base station. This allows, for example, a UE to quickly switch connections to a DU that supports a desired RAN slice.
[0142] Information regarding RAN slices supported by other DUs within the base station may be associated with information about those DUs. This association may take the form of a list, for example. The list may contain information about RAN slices supported by the DU.
[0143] The information may include information about one or more RAN slices supported by the TRP within the base station. It may also include information about the TRP, such as its identifier. Furthermore, it may include information about a combination of the TRP information and the RAN slices supported by the TRP.
[0144] The information may include details about one or more RAN slices supported by other TRPs within the base station. This allows, for example, the UE to quickly switch connections to a TRP that supports a desired RAN slice.
[0145] Information regarding RAN slices supported by other TRPs within the base station may be associated with information about those TRPs. This association may take the form of a list, for example. The list may include information about RAN slices supported by the base station's TRP.
[0146] The base station may broadcast the information using broadcast information. This broadcast information may be, for example, a MIB (Mental Information Block). This allows the base station to broadcast the information quickly.
[0147] As another example, the broadcast information may be SIB1. This allows, for example, the base station to quickly notify a large amount of information. As yet another example, the broadcast information may be Other SI. This allows, for example, the base station to broadcast even more information. The aforementioned Other SI may be an existing SIB, or a new SIB may be established. The aforementioned new SIB may be, for example, an SIB for information regarding RAN slicing.
[0148] The aforementioned information regarding RAN slices that can be supported by a base station may be provided for each base station, each cell, each DU, each TRP (Transmission Reception Point), or each antenna panel. This allows for flexible control of RAN slicing in a communication system, for example. This information may include information about base stations, cells, DUs, and / or TRPs. This information may be used in combination with information about base stations, cells, DUs, and / or TRPs. This allows, for example, a UE to identify the RAN slices that can be supported for each base station, cell, DU, and / or TRP. As a result, the UE can connect to base stations, cells, DUs, and / or TRPs that can support the desired slice.
[0149] The notification information may include information regarding access control, such as information regarding barring. Barring may be performed for each RAN slice. The notification information may also include information regarding barring for each RAN slice. This enables flexible access control, for example, in a communication system.
[0150] The base station may individually notify the UE of information regarding the RAN slices it can support. For example, the base station may include this information in the UE's RRC startup instruction. The base station may include this information in the UE's RRC restart instruction. The base station may include this information in the UE's RRC reset instruction. The base station may also include information regarding the destination base station's RAN slices in the handover request. This can, for example, reduce the amount of signaling information required for broadcasting.
[0151] The UE may use the broadcast information and / or notification from the base station to determine whether or not to access the base station. For example, the UE may connect only to base stations that support the RAN slice it wants to use (hereinafter sometimes referred to as the desired slice), or only to cells, DUs, and / or TRPs that can support the desired slice. The UE may perform this process during cell selection. This allows the UE to quickly start communication using the desired slice after power-up. As another example, the UE may perform this process during cell re-selection. This allows a UE in the RRC_IDLE or RRC_INACTIVE state to quickly restore communication with a base station using the desired slice.
[0152] For example, the criteria for determining a "suitable cell" in a UE (see Non-Patent Document 30 (TS38.304)) may include the case where the cell can support the desired slice. This would enable the UE to use a "suitable cell" to achieve communication that satisfies the desired QoS.
[0153] The decision in the UE may be made between cells, DUs, and / or TRPs of different frequencies. For example, if different RAN slices can be supported at different frequencies, the UE may use only frequencies that can support the desired slice for cell selection and / or cell re-selection. This can reduce the processing load on the UE during cell selection and / or cell re-selection. As another example, the decision in the UE may be made between cells, DUs, and / or TRPs of the same frequency. For example, when selecting the strongest cell within the same frequency during cell selection and / or cell re-selection, the UE may exclude cells that do not support the desired slice from the selection. This can prevent the UE from selecting cells that do not support the desired slice. As a result, QoS can be ensured in the UE's communications.
[0154] Figure 14 is a sequence diagram showing how the UE connects to a base station capable of supporting the desired slice using broadcast information from the base station. In the example shown in Figure 14, the UE's desired slice is S-NSSAI#2, gNB#1 supports S-NSSAI#1, and gNB#2 supports S-NSSAI#2.
[0155] In procedure 1401 shown in Figure 14, settings regarding supported RAN slices are made between the gNBs (gNB#1, gNB#2) and the AMF. This procedure may be, for example, the NG Setup disclosed in Non-Patent Document 23 (TS38.413). In step ST1410, gNB#1 notifies the AMF of information regarding the S-NSSAIs that gNB#1 supports. In the example shown in Figure 14, gNB#1 notifies the AMF of information indicating that gNB#1 supports S-NSSAI#1. The notification in step ST1410 may be included in, for example, the NG SETUP REQUEST disclosed in Non-Patent Document 23 (TS38.413). In step ST1412, the AMF holds the information received in step ST1410. In step ST1414, gNB#2 notifies the AMF of information regarding the S-NSSAIs that gNB#2 supports. In the example shown in Figure 14, gNB#2 notifies AMF of information indicating that gNB#2 supports S-NSSAI#2. The notification in step ST1414 may be included in an NG SETUP REQUEST, for example, as disclosed in Non-Patent Document 23 (TS38.413). In step ST1416, AMF holds the information received in step ST1414.
[0156] In step ST1420 shown in Figure 14, gNB#1 transmits broadcast information to its subordinate UEs. The broadcast information in step ST1420 includes information indicating that gNB#1 supports S-NSSAI#1. In step ST1422, the UE decides not to select gNB#1's cell as a connection destination. The UE may use the information contained in step ST1420 in making this decision.
[0157] In step ST1424 shown in Figure 14, gNB#2 transmits broadcast information to its subordinate UEs. The broadcast information in step ST1424 includes information indicating that gNB#2 supports S-NSSAI#2. In step ST1426, the UE decides to select gNB#2's cell as the connection destination. The UE may use the information contained in step ST1424 in this decision.
[0158] In step ST1430 shown in Figure 14, random access processing is performed between the UE and gNB#2. In step ST1430, a connection is established between the UE and gNB#2. In step ST1435, the UE makes a registration request to the NW to gNB#2. The UE notifies the request, including that the requesting NSSAI is S-NSSAI#2. In step ST1437, gNB#2 forwards the registration request from step ST1435 to the AMF.
[0159] In step ST1438 shown in Figure 14, the AMF performs operations related to the registration of the UE. For example, the AMF determines the authorization NSSAI and the denial NSSAI for the UE. In the example shown in Figure 14, using the fact that S-NSSAI#2 included in the request NSSAI from the UE is supported by gNB#2, the AMF includes S-NSSAI#2 in the authorization NSSAI. In step ST1440, the AMF determines the RFSP (RAT / Frequency Selection Priority) (see Non-Patent Document 27 (TS23.501)) that the base station uses to determine the UE's RAT and frequency.
[0160] In step ST1442 shown in Figure 14, the AMF notifies gNB#2 of information indicating that it accepts the registration of the UE. This notification may include information about the authorized NSSAI for the UE, or information about the RFSP, for example, the RFSP index (see Non-Patent Document 27 (TS23.501)). This notification may be made using the interface between the AMF and the base station (for example, the N2 interface). In the example shown in Figure 14, the AMF notifies S-NSSAI#2 as the authorized NSSAI. In step ST1444, gNB#2 notifies the UE that it has accepted the registration. This notification in step ST1444 may include information about the authorized NSSAI for the UE. In the example shown in Figure 14, gNB#2 notifies S-NSSAI#2 as the authorized NSSAI. The UE uses this notification to communicate using S-NSSAI#2.
[0161] The UE may connect to a cell, DU, and / or TRP that does not support the desired slice. For example, if none of the cells, DUs, and / or TRPs that the UE can connect to support the UE's desired cell, the UE may perform the actions described above. For example, the AMF may decide that the UE will communicate using the default S-NSSAI. The UE may connect to the NW using the default S-NSSAI. Another example of a situation where the UE's desired cell is not supported is the use of a RAN slice other than the desired slice. For example, if the UE's desired slice is a URLLC RAN slice and the cell to which the UE connects does not support URLLC, the AMF may decide to communicate using an eMBB RAN slice. The AMF may include S-NSSAIs that are not included in the UE's requested NSSAI in the Allowed NSSAI and notify the base station. The base station may forward the notification to the UE. The UE may use the notification to communicate using a RAN slice different from the desired slice. This enables communication between the UE and the NW even when, for example, there are no cells around the UE that support the desired slice of the UE.
[0162] Priorities may be assigned to RAN slices that are determined by the AMF as RAN slices other than the desired slices. These priorities may be assigned to each desired slice. These priorities may be determined by the standard or by the AMF. These priorities may be determined by the base station and notified to the AMF. As another example, the UE may have information regarding these priorities and notify the AMF. For example, the UE may have information regarding these priorities on the SIM card.
[0163] As an example of this priority order, when the desired slice is URLLC, the RAN slices to be set may be eMBB, mMTC, and V2X in that order. For example, considering that RAN slices capable of high-capacity communication often have short symbol lengths, even if an eMBB RAN slice is selected when URLLC RAN slices are not supported, communication latency can be reduced. The desired slice may be included in this priority order. This makes it possible to use this priority order to determine which RAN slice to use, regardless of whether the desired slice is supported or not. As a result, complexity in the RAN slice selection process can be avoided.
[0164] The UE may use information about the frequency band when selecting a cell that supports the desired slice. For example, the UE may use information about whether the cell's frequency band is F1 or F2, or information about the frequency bands of the cell, DU, and / or TRP, to determine whether it supports the desired slice. For example, a UE using eMBB services may select an F2 band cell capable of high-capacity transmission. This allows the UE to quickly connect to a cell that supports the desired slice.
[0165] The UE may use information about frequency bandwidth in selecting cells that support the desired slice. For example, the UE may use information about the frequency bandwidth of cells, DUs, and / or TRPs to determine whether they support the desired slice. For example, a UE using eMBB services may select cells with a frequency bandwidth greater than a predetermined value. This allows the UE to quickly connect to cells that support the desired slice.
[0166] As another example, the UE may use information about symbol length when selecting cells that support the desired slice. For example, a UE using the URLLC service may select cells with shorter symbol lengths. This can achieve the same effect as described above.
[0167] The UE may preferentially use cells that support the frequency and / or symbol length used in the desired slice during cell selection and / or cell reselection. If no suitable cell is found as described above, the UE may perform normal cell selection and / or cell reselection. This allows the UE to quickly select and / or reselect cells that support the desired slice.
[0168] The frequencies of RAN slices and cells may be associated with each other. The symbol lengths of RAN slices and cells may be associated with each other. The combinations of RAN slices and cell frequencies and symbol lengths may be associated with each other.
[0169] The aforementioned mapping may be predetermined in the standard. The UE may use the mapping defined in the standard to select the cells that support the desired slice. This allows the UE to quickly detect the desired slice, for example.
[0170] As another example, the UE may have the aforementioned mapping information pre-configured. For instance, this information may be stored in the UE's SIM (Subscriber Identity Module). This would allow, for example, the telecommunications carrier to flexibly change the mapping.
[0171] As another example, the UE may use information from the previous registration as the information for the aforementioned mapping. The UE may retain information about the cell frequency and / or symbol length, and information about the supported RAN slices, obtained at the time of the previous registration, as the information for the mapping. This allows the UE to quickly detect cells that support the desired slices when registering again.
[0172] Other solutions are disclosed. The cell identifier is assigned information corresponding to the supported RAN slices. The cell identifier may be, for example, PCI. Certain bits of PCI may be assigned to RAN slices, for example, SSTs. That is, certain bits of PCI may represent the compatibility of each RAN slice, for example, each SST. For example, a bit for a compatible RAN slice may be set to 1, and a bit for an incompatible RAN slice may be set to 0. Another example is that a bit for a compatible RAN slice may be set to 0, and a bit for an incompatible RAN slice may be set to 1. The values of bits other than the predetermined bits that make up the PCI value may be given for cell identification.
[0173] Each cell may be assigned a supported slice. The UE may connect to a cell in the base station that supports the desired slice. This allows the base station to support a variety of RAN slices, for example.
[0174] Figure 15 shows an example of allocating supported RAN slices to PCI. In the example shown in Figure 15, PCI consists of a total of 9 bits, from bit 0 to bit 8, and is given one of the values from 0 to 511 represented by these 9 bits. The 8th bit is assumed to be the MSB (Most Significant Bit).
[0175] In the example shown in Figure 15, eMBB is assigned to the 8th bit, URLLC to the 7th bit, mMTC to the 6th bit, and V2X to the 5th bit. In the example shown in Figure 15, for a PCI of a cell that only supports URLLC, the 8th, 6th, and 5th bits are 0, and the 7th bit is 1. The values of bits 0 through 4 may be arbitrarily assigned by the cell. For example, a base station may determine the values of bits 0 through 4 so that the PCI does not overlap with that of surrounding cells.
[0176] The UE may use the cell's PCI to obtain information about the RAN slices that the cell can support. The UE may then use this information to determine the cell to connect to. This allows the UE to quickly connect to a cell that supports the desired slice, for example.
[0177] The base station may broadcast to the UE information about whether the PCI contains information about the RAN slices that the cell can support. The UE may use this broadcast information to determine whether the PCI contains information about the RAN slices that can be supported. This allows, for example, cells with PCI containing information about RAN slices and cells without PCI to coexist.
[0178] As another example, the base station may notify the UE in random access processing whether information about RAN slices is included in the PCI. For example, the base station may include information about whether information about RAN slices is included in the PCI in the Random Access Response (RAR). This can prevent, for example, the base station from overloading the number of PCIs that can be allocated to the cell. The UE may use the information about whether information about RAN slices is included in the PCI to obtain information about the RAN slices that the cell can support. The UE may stop random access processing if the cell does not support the desired slice. For example, in the aforementioned case, the UE may not send message 3 in random access processing. As another example in the aforementioned case, the UE may complete the random access processing. After completing the random access processing, the UE may release the RRC connection with the base station.
[0179] Figure 16 is a sequence diagram showing how a UE connects to a base station capable of supporting the desired slice using the cell's PCI. In the example shown in Figure 16, the UE's desired slice is S-NSSAI#2, gNB#1 supports S-NSSAI#1, and gNB#2 supports S-NSSAI#2. In Figure 16, the same numbering is used for processes similar to those in Figure 14, and common explanations are omitted.
[0180] Procedure 1401 in Figure 16 is the same as in Figure 14.
[0181] In step ST1520, shown in Figure 16, gNB#1 transmits an SS block. The PCI of gNB#1 included in step ST1520 is assigned to a cell that supports S-NSSAI#1. In step ST1521, gNB#1 transmits broadcast information to its subordinate UE. The broadcast information in step ST1521 includes information indicating that the PCI contains information about the RAN slices supported by the cell of gNB#1. Through steps ST1520 and ST1521, the UE obtains information about the RAN slices that the cell of gNB#1 can support. In step ST1522, the UE decides not to connect to gNB#1.
[0182] In step ST1524 shown in Figure 16, gNB#2 transmits an SS block. The PCI of gNB#2 included in step ST1524 is assigned to a cell that supports S-NSSAI#2. In step ST1525, gNB#2 transmits broadcast information to its subordinate UE. The broadcast information in step ST1525 includes information indicating that the PCI contains information about the RAN slices supported by the cell of gNB#2. Through steps ST1524 and ST1525, the UE obtains information about the RAN slices that the cell of gNB#2 can support. In step ST1526, the UE decides to connect to gNB#2.
[0183] Steps ST1430 to ST1444 shown in Figure 16 are the same as those in Figure 14.
[0184] As another example, the base station may notify the UE of the information regarding the RAN slices it can support during random access processing. For example, the base station may include information in the Random Access Response (RAR) regarding the RAN slices that it, the cell, the DU, and / or the TRP can support. This can, for example, avoid design complexity in the communication system. The UE may use this information to obtain information about the RAN slices that the cell, the DU, and / or the TRP can support. The UE may stop random access processing if the cell does not support the desired slice. For example, in the aforementioned case, the UE may not send message 3 during random access processing. As another example in the aforementioned case, the UE may complete the random access processing. After completing the random access processing, the UE may release the RRC connection with the base station. As another example in the aforementioned case, the UE may send message 3 during random access processing to the base station. Message 3 may include, for example, information indicating that the UE is discontinuing random access processing. The base station may use this information to discontinue random access processing with the UE. This allows, for example, the base station to quickly terminate random access processing with the UE, resulting in improved communication efficiency at the base station.
[0185] Figure 17 is a sequence diagram showing how a UE obtains information about supported RAN slices from a random access response from a base station and connects to a base station that can support the desired slice. In the example shown in Figure 17, the UE's desired slice is S-NSSAI#2, gNB#1 supports S-NSSAI#1, and gNB#2 supports S-NSSAI#2. In Figure 17, the same numbering is used for processes similar to those in Figure 14, and common explanations are omitted.
[0186] Procedure 1401 in Figure 17 is the same as in Figure 14.
[0187] In step ST1620 shown in Figure 17, gNB#1 transmits an SS block. The UE uses the SS block from step ST1620 to establish downlink synchronization with gNB#1.
[0188] In step ST1621 shown in Figure 17, the UE sends a PRACH to gNB#1. In step ST1622, gNB#1 sends a random access response to the UE. The random access response from gNB#1 contains information about the RAN slices that the cell in gNB#1 can support. In the example shown in Figure 17, the random access response in step ST1622 contains information indicating that gNB#1 supports S-NSSAI#1. In the example shown in Figure 17, since gNB#1 does not support S-NSSAI#2, which is the slice desired by the UE, the UE terminates the connection with gNB#1 in step ST1623. That is, the UE terminates the random access process with gNB#1.
[0189] In step ST1624 shown in Figure 17, gNB#2 transmits an SS block. The UE uses the SS block from step ST1624 to establish downlink synchronization with gNB#2.
[0190] In step ST1625 shown in Figure 17, the UE sends a PRACH to gNB#2. In step ST1626, gNB#2 sends a random access response to the UE. The random access response from gNB#2 contains information about the RAN slices that the cell in gNB#2 can support. In the example shown in Figure 17, the random access response in step ST1626 contains information indicating that gNB#2 supports S-NSSAI#2. In the example shown in Figure 17, since gNB#2 supports S-NSSAI#2, which is the slice desired by the UE, the UE continues the connection with gNB#2 in step ST1627. That is, the UE continues the random access process with gNB#2. In step ST1630, random access messages 3 and 4 are sent and received between the UE and gNB#2.
[0191] Steps ST1435 to ST1444 shown in Figure 17 are the same as those in Figure 14.
[0192] Other solutions are disclosed. The base station determines whether the UE can register. The base station may also determine whether the UE can access the network. The registration request from the UE may be used in the base station's determination. The base station may use information about the UE's desired slice to determine whether the UE can register. For example, the base station may decide not to register the UE if its cell does not support the UE's desired slice. The base station may notify the UE that registration is not possible. The notification may include the reason for the denial of registration, for example, that its cell does not support the UE's desired slice. This prevents, for example, the UE from registering with the AMF via a cell that does not support the desired slice. As a result, the UE can ensure the desired QoS.
[0193] As an example of how a base station can determine whether access is permitted, the base station may use information about the network that the UE wants to connect to (for example, the PLMN-ID) to determine whether the UE can access the network.
[0194] The base station may include in the notification information about cells, DUs, and / or TRPs that support the UE's desired slice. The base station may obtain information about RAN slices supported by surrounding cells, DUs, and / or TRPs. The base station may obtain this information, for example, using the method disclosed in Modification 1 of Embodiment 1. The UE may use this information to reconnect to cells, DUs, and / or TRPs that support its desired slice. This information may include information about the UE's desired slice. This information may be combined with information about the UE's desired slice. This allows, for example, the UE to quickly connect to a cell that supports the desired slice.
[0195] If the cell, DU, and / or TRP to which the UE is connected supports the UE's desired slice, the base station may decide to allow the UE to register. If the base station decides to allow the UE to register, it may forward the registration request from the UE to the AMF.
[0196] The base station may choose not to notify the UE of information indicating that it has approved the UE's registration. This could, for example, reduce signaling between the UE and the base station.
[0197] Figure 18 is a sequence diagram showing the operation in which the base station determines whether or not to register a UE during UE registration. In the example shown in Figure 18, the desired slice for the UE is S-NSSAI#2, gNB#1 supports S-NSSAI#1, and gNB#2 supports S-NSSAI#2. In Figure 18, the same numbering is used for processes similar to those in Figures 14 and 17, and common explanations are omitted.
[0198] Procedure 1401, shown in Figure 18, is the same as in Figure 14.
[0199] Step ST1620, shown in Figure 18, is the same as in Figure 16. In step ST1722, the UE performs random access processing with gNB#1.
[0200] In step ST1723 shown in Figure 18, the UE requests registration with AMF from gNB#1. The registration request in step ST1723 includes information indicating that the UE's desired slice is S-NSSAI#2. In step ST1724, gNB#1 determines whether to register the UE with AMF. In the example shown in Figure 18, gNB#1 does not support S-NSSAI#2, which is the UE's desired slice, so gNB#1 determines that registration of the UE is not permitted. In step ST1725, gNB#1 notifies the UE that registration with AMF has been rejected. The notification in step ST1725 may include the reason for the rejection, for example, information indicating that the UE's desired slice is not supported. The notification in step ST1725 may also include information about cells that support the UE's desired slice. In the example in Figure 18, the information about cells that support the UE's desired slice may be information about gNB#2's cells, for example, the PCI of those cells. The UE may use the notification in step ST1725 to perform the receiving operation on the cell of gNB#2.
[0201] Step ST1624 shown in Figure 18 is the same as in Figure 17.
[0202] Steps ST1430 and ST1435 shown in Figure 18 are the same as in Figure 14. In step ST1736, gNB#2 determines whether the UE can be registered with the AMF. In the example shown in Figure 18, gNB#2 supports S-NSSAI#2, which is the desired slice of the UE, so it determines that the UE can be registered.
[0203] Steps ST1437 to ST1444 shown in Figure 18 are the same as those in Figure 14.
[0204] Other solutions are disclosed. The UE may notify the base station of information regarding the desired slice upon initial access. This notification may use, for example, a random access preamble. A random access preamble may be assigned to each desired slice. This allows, for example, the UE to quickly notify the base station of information regarding the desired slice.
[0205] The allocation may be such that, for example, the random access preamble value is assigned to each RAN slice, or for example, each SST. For example, 0-15 may be assigned to eMBB, 16-31 to URLLC, 32-47 to mMTC, and 48-63 to V2X. This makes it possible to secure a large number of preambles that can be assigned to UEs in the same desired slice. As a result, it becomes possible to secure a large number of UEs that can be accommodated in the same desired slice.
[0206] Another example of such assignment is that a RAN slice, such as an SST, may be assigned to a predetermined bit in the random access preamble. That is, a predetermined bit in the random access preamble may represent whether each RAN slice, such as each SST, is compatible or not. For example, a bit for compatible RAN slices may be set to 1, and a bit for uncompatible RAN slices may be set to 0. Another example is that a bit for compatible RAN slices may be set to 0, and a bit for uncompatible RAN slices may be set to 1. This makes it possible, for example, to notify information for multiple desired slices.
[0207] When a UE has multiple desired slices, the first cell the UE accesses may be, for example, the cell that the UE first determines to be a "suitable cell" as disclosed in Non-Patent Document 30 (TS38.304). This allows the UE to quickly connect to a base station. The cell that the UE first determines to be a suitable cell may be a cell that supports any of the UE's desired slices. The UE may determine whether a cell supports a desired slice using the method disclosed in Embodiment 1, for example, a method of obtaining the RAN slices supported by the cell from broadcast information. This allows the UE to quickly connect to a cell that supports a desired slice.
[0208] Another example regarding the cell that the UE first accesses is that a priority order may be set for each RAN slice. For example, the priority order for the cell that the UE first accesses may be cells that support URLLC, cells that support eMBB, cells that support mMTC, and cells that support V2X. The UE may determine whether a cell supports a desired slice using the method disclosed in Embodiment 1, for example, a method of obtaining the RAN slices that the cell supports from broadcast information. This allows for rapid initiation of communication, for example, in communications where low latency is required.
[0209] The cell that a UE first accesses may be determined, for example, by the cell's frequency. For instance, the UE may connect to cells in order from highest frequency. This allows the UE to preferentially connect to higher-frequency cells with narrower coverage, thereby increasing the number of UEs that can be accommodated in the communication system. Alternatively, the UE may connect to cells in order from lowest frequency. This allows the UE to preferentially connect to cells with wider coverage, thereby reducing the number of UE handovers.
[0210] The cell that the UE first accesses may be determined, for example, by the cell's frequency bandwidth. For instance, the UE may connect to cells in order of increasing frequency bandwidth. This allows the UE to preferentially connect to cells with higher transmission capacity, thereby improving the communication speed between the UE and the base station.
[0211] The first cell accessed by the UE may be determined by a standard. This can, for example, avoid complexity in the communication system. Alternatively, the base station may determine and broadcast or notify the UE which cell the UE will access first. For example, the aforementioned broadcast or notification may include a parameter regarding cell priority. The UE may use this priority information to determine which cell to connect to. This can, for example, improve flexibility in the communication system. Alternatively, the AMF may determine and broadcast or notify the UE which cell the UE will access first. This broadcast or notification may be made via the base station. This can, for example, reduce the processing required at the base station to determine which cell the UE will access first.
[0212] Other solutions are disclosed. The UE may notify the base station of the desired slice when establishing an RRC connection with the base station. For example, the UE may notify the base station of the desired slice by including it in the signaling of an RRC setup request (RRCSetupRequest) disclosed in Non-Patent Document 24 (TS38.331). The base station may use this information to determine whether or not to start the UE's RRC. The base station may refuse to start the UE's RRC, for example, if its own cell does not support the UE's desired slice. In the aforementioned case, the base station may notify the UE of an RRC rejection (RRCReject). The base station may include in the notification information indicating that it does not support the UE's desired slice. This information may be included, for example, as a parameter in the “Cause” included in the notification. This allows the UE to understand, for example, that the base station does not support the desired slice. The base station may notify the UE of the cell that supports the UE's desired slice. This information may, for example, be included in the RRCReject signaling described above. The UE may use this information to reconnect to a cell that supports the desired slice. This allows the UE to quickly connect to a cell that supports the desired slice.
[0213] Another solution is disclosed. The base station may include information about the RAN slice required for the communication service in the paging it transmits to the UE. The UE may use this information to determine which RAN slice to use. The UE may also use this information to determine the destination cell, CU-UP, DU, and / or TRP. This allows the UE to use the RAN slice required for the communication service, even when downlink communication occurs.
[0214] In this embodiment 1, the AMF may determine the RFSP using information about the UE's desired slice. The AMF may notify the base station of the determined RFSP information. The base station may notify the UE of the information. This notification may be included, for example, in registration acceptance signaling or registration rejection signaling. Alternatively, the AMF may notify the UE directly (for example, using NAS signaling). The UE may use the information to determine the cell to connect to and / or reconnect to. This allows the UE to select a cell that supports the desired slice, for example.
[0215] The method disclosed in Embodiment 1 may be applied to a base station that is separated into a CU and a DU. For example, a DU may inform a UE of information regarding the RAN slices it supports, or notify the UE individually. The UE may use this information to connect to the DU relating to the cell that supports the desired slice. This allows, for example, a UE to connect to a DU that supports the desired slice even in a base station that is separated into a CU and a DU.
[0216] This embodiment 1 enables the UE to quickly connect to and / or reconnect to cells that support the desired slice.
[0217] Modification 1 of Embodiment 1. A base station may broadcast or notify a UE of information regarding RAN slices that can be supported by other base stations. The UE may use this information to connect to a cell that supports the desired slice.
[0218] As described above, the following problem arises: The method for a base station to obtain information about RAN slices that can be supported by other base stations is not disclosed. As a result, the base station cannot broadcast or notify the UE of this information.
[0219] This modified example 1 discloses a method for resolving the aforementioned problems.
[0220] The UE notifies the base station of information regarding RAN slices that can be supported by other base stations. The UE may obtain such information regarding RAN slices using the method disclosed in Embodiment 1, for example, using broadcast information from the base station. The UE may notify the base station of such information by including it in a measurement report. Alternatively, the UE may notify the base station of such information using other RRC signaling, MAC signaling, or L1 / L2 signaling. The UE making the aforementioned notification may be different from the UE receiving the aforementioned broadcast or notification from the base station. A new RRC signaling for such notification may be provided.
[0221] Other solutions are disclosed. The AMF notifies the base station of information about surrounding base stations capable of supporting a given RAN slice. The AMF may notify in the NG Setup procedure. For example, the AMF may notify using the NG SETUP RESPONSE signaling disclosed in Non-Patent Literature 23 (TS38.413). Alternatively, the AMF may notify using other N2 signaling, such as a signaling for acceptance of UE registration or a signaling for rejection of UE registration. A new N2 signaling for this notification may be provided. This would reduce, for example, the signaling between the UE and the base station.
[0222] As another example, the AMF may issue the notification at a predetermined interval. This would allow, for example, a base station to quickly become aware of updates to the information. The predetermined interval may be defined by the standard or determined by the AMF.
[0223] As another example, the AMF may issue such notification when the configuration of a base station within the TA changes. This would allow the base station to more quickly become aware of updates to the information.
[0224] As another example, the AMF may issue such a notification when the configuration of a base station within the RNA (RAN Notification Area) is changed. This would, for example, reduce the amount of signaling between the base station and the AMF.
[0225] Other solutions are disclosed. A base station notifies surrounding base stations of information about one or more RAN slices that it can support. This information may include information about RAN slices that can be supported in cells, DUs, and / or TRPs within its own base station. This information may include information about base stations, cells, DUs, and / or TRPs, such as identifiers. Combinations of the aforementioned information may be notified. A base station may request other base stations to provide information about RAN slices that they can support. Xn signaling may be used for this notification and / or request. This can reduce, for example, the amount of signaling between the base station and the AMF.
[0226] As another example, a base station may directly obtain information from a neighboring base station regarding the RAN slices it can support. The base station may obtain this information, for example, by using cell search. The neighboring base station may broadcast information regarding the RAN slices it can support using the method disclosed in Embodiment 1. This allows the base station to obtain this information without using an inter-base station interface, for example. As a result, the amount of signaling on the inter-base station interface can be reduced.
[0227] Another solution is disclosed. The OAM (Operation, Administration and Management / Maintenance) notifies the base station of information regarding RAN slices that can be supported by surrounding base stations. The base station may request this information from the OAM. The base station may also notify the OAM of information regarding RAN slices that can be supported by its own base station. The OAM may request this information from the base station. This, for example, can achieve the same effect as described above.
[0228] Other solutions are disclosed. The Network Data Analytics Function (NWDAF) described in Non-Patent Document 22 notifies base stations of information regarding RAN slices that can be supported by surrounding base stations. Base stations may request this information from the NWDAF. Base stations may also notify the NWDAF of information regarding RAN slices that can be supported by their own base station. The NWDAF may request information regarding RAN slices that can be supported by the base station. This can achieve, for example, the same effects as described above. The aforementioned notifications and / or requests may be made via the AMF. This can avoid, for example, complexity in the communication system.
[0229] This modification 1 enables the base station to acquire information about slices supported by other cells and to broadcast or notify the UE of this information. As a result, the UE can quickly connect to a cell that can support the desired slice.
[0230] Embodiment 2. During UE registration, the AMF may reject a connection using a RAN slice that is not supported by the cell to which the UE is connected. The AMF may also notify the UE of the RAN slice information via the base station. For example, the AMF may notify the UE of the RAN slice in a rejected NSSAI.
[0231] As described above, the following problem arises: If the UE's desired slice is rejected (NSSAI), the UE will not be able to connect using the desired slice. As a result, it becomes difficult to ensure the necessary QoS.
[0232] This second embodiment discloses a method for solving the aforementioned problems.
[0233] The UE performs deregistration. The UE reconnects to a different cell than the one it was registered in.
[0234] The UE may retain information about the cells it was connected to before unregistering. The UE may also choose not to connect to those cells. This prevents repeated re-registration by reconnecting to cells that do not support the desired slice, for example.
[0235] The UE may exclude the cell from measurement during cell selection and / or cell re-selection. This can, for example, reduce the amount of measurement processing required by the UE. As another example, the UE may exclude the cell from judgment during cell selection and / or cell re-selection. This can, for example, avoid complexity in the operation of cell selection and / or cell re-selection.
[0236] The AMF may notify base stations of information regarding cells and / or base stations capable of supporting the UE's desired slice. This notification may include information regarding frequencies that support the UE's desired slice. The notification may also include information indicating that the base station to which the UE is connected does not support the desired slice. This information may be included in the notification, for example, as the Cause.
[0237] The base station may notify the AMF of information regarding base stations, cells, DUs, and / or TRPs that can support the UE's desired slice. The OAM may notify the base station of information regarding RAN slices that can be supported by the base station, cell, DU, and / or TRP. The base station may use this information to configure the RAN slices it supports. The base station may use this information from the OAM to derive information regarding base stations, cells, DUs, and / or TRPs that can support the UE's desired slice. This eliminates the need for base stations to notify the AMF in advance about the RAN slices they can support, and as a result, reduces signaling between the base station and the AMF.
[0238] The AMF may notify the base station of information regarding CU-UPs (Central Unit-User Planes) capable of supporting the desired slice of the UE, or it may notify the base station of information regarding DU-UPs (Distributed Unit-User Planes) capable of supporting the slice. This operation may be performed, for example, when CP-UP separation is performed in the communication network. The CU-CP (Central Unit-User Plane) may notify the AMF of information regarding the RAN slices that can be supported by each of its subordinate CU-UPs. This allows for similar effects to be obtained, for example, in a communication network where CP-UP separation is performed.
[0239] The base station may notify the AMF of information regarding CU-UPs that can support the UE's desired slice. The OAM may notify the base station of information regarding RAN slices that can be supported by the CU-UP. The base station may use this information to configure the RAN slices supported by each CU-UP. The base station may use this information from the OAM to derive information regarding CU-UPs that can support the UE's desired slice. This eliminates the need for the base station to notify the AMF in advance about the RAN slices that can be supported, and as a result, signaling between the base station and the AMF can be reduced.
[0240] The base station may notify the UE of the notification from the AMF. After deregistration, the UE may use the notification to reconnect to a base station, cell, CU-UP, DU, and / or TRP that supports the desired slice. This enables, for example, the UE to quickly perform communication using the desired slice.
[0241] Another solution is disclosed. The AMF permits registration for a RAN slice that is not supported by the cell to which the UE connects. The AMF includes the desired slice of the UE in Allowed NSSAI and notifies the base station thereof. The base station forwards the notification from the AMF to the UE. The notification may be included in N2 signaling that contains information indicating that registration of the UE is permitted. The AMF may include, in the notification, information related to a base station, CU-UP, DU, TRP, and / or cell that supports the desired slice of the UE. The notification may include information related to the desired slice of the UE. Information related to the desired slice of the UE may be combined with information related to a base station, CU-UP, DU, TRP, and / or cell that supports the desired slice of the UE. This enables, for example, the UE to quickly identify a cell that can support the desired slice. As another example, the notification does not have to include information related to the desired slice of the UE. This enables, for example, a reduction in the signaling size of the notification.
[0242] The UE may maintain the RRC_CONNECTED state. Handover of the UE may be performed. The base station may instruct the UE to perform handover. This enables, for example, a reduction in signaling between the UE and the base station related to RRC state transition of the UE.
[0243] The base station may instruct the UE to measure base stations, cells, CP-CUs, DUs, and / or TRPs that support the UE's desired slice. Such instructions may or may not be included in the registration acceptance signaling from the base station to the UE. As another example, such instructions for measurement may be implicit. For example, the UE may implicitly perform measurements of base stations, cells, CP-CUs, DUs, and / or TRPs that support the UE's desired slice using the registration acceptance notification. This would, for example, reduce the signaling between the UE and the base station.
[0244] The instruction for measurement from the base station to the UE may include information about the base stations, cells, CP-CUs, DUs, and / or TRPs that support the UE's desired slice. As another example, the instruction for measurement from the base station to the UE may include information about the UE's desired slice. The UE may use this information to derive information about the base stations, cells, CP-CUs, DUs, and / or TRPs being measured. This can, for example, reduce the magnitude of the signaling from the base station to the UE.
[0245] The UE may use the instructions from the base station to perform measurements on other base stations, cells, CP-CUs, DUs, and / or TRPs. The UE may notify the base station of the measurement results. The base station may use the notification to determine the UE's handover destination.
[0246] The notification of measurement results from the UE to the base station may include information about the desired slice, or information about one or more RAN slices that can be supported at the base station, cell, CP-CU, DU, and / or TRP being measured. The base station may use this information to determine the UE's handover destination. This allows the base station to select a base station, cell, CP-CU, DU, and / or TRP that can support the UE's desired slice as the handover destination, and as a result, the UE can communicate while maintaining the desired QoS even after the handover.
[0247] Figures 19 and 20 are sequence diagrams illustrating the operation of a UE connected to a base station that does not support the desired slice, handing over to a base station that does support the desired slice. Figures 19 and 20 are connected at the boundary line BL1920. In Figures 19 and 20, the same steps as in Figures 14, 17, and 18 are given the same step numbers, and common explanations are omitted.
[0248] Procedure 1401 in Figure 19 is the same as in Figure 14.
[0249] Step ST1620 in Figure 19 is the same as in Figure 17.
[0250] Steps ST1722 and ST1723 in Figure 19 are the same as in Figure 18.
[0251] In step ST1937 in Figure 19, gNB#1 notifies AMF of the registration request from UE. In step ST1938, AMF uses the presence of a base station supporting S-NSSAI#2 under its command to authorize S-NSSAI#2 to the UE.
[0252] Step ST1440 in Figure 19 is the same as in Figure 14.
[0253] In step ST1942 in Figure 19, the AMF notifies gNB#1 of information indicating that it accepts the registration of the UE. This notification may include information about the authorized NSSAI to the UE, or it may include information about the RFSP, such as the RFSP index. This notification may be made using the interface between the AMF and the base station (e.g., the N2 interface). In the example shown in Figure 19, the AMF notifies S-NSSAI#2 as the authorized NSSAI. The notification in step ST1942 may include information about the base station that supports S-NSSAI#2, which is the authorized NSSAI. In the example shown in Figure 19, the AMF notifies gNB#2 of information about the base station that supports S-NSSAI#2.
[0254] In step ST1944 in Figure 19, gNB#1 notifies the UE of registration acceptance. This notification in step ST1944 may include information about authorized NSSAIs to the UE, or it may include information about base stations that support the authorized NSSAIs. In the example shown in Figure 19, gNB#1 notifies S-NSSAI#2 as the authorized NSSAI, and also notifies gNB#2 as information about base stations that support S-NSSAI#2, which is the authorized NSSAI. In step ST1946, the UE maintains the RRC_CONNECTED state.
[0255] Step ST1624 in Figure 19 is the same as in Figure 17.
[0256] In step ST1950 in Figure 20, the UE measures the downlink signal from the cell of gNB#2. In the example shown in Figures 19 and 20, the UE measures the SS block in step ST1624 as the downlink signal. In step ST1952, the UE reports the measurement result to gNB#1. In step ST1954, gNB#1 decides to hand over the UE to gNB#2. In step ST1956, gNB#1 sends a handover request to gNB#2. In step ST1958, gNB#2 sends a handover request acknowledgment to gNB#1. In step ST1960, gNB#1 instructs the UE to hand over to gNB#2. This instruction may be given, for example, using RRCReconfiguration signaling. The UE uses the instruction in step ST1960 to initiate the handover operation to gNB#2.
[0257] In step ST1964 in Figure 20, the UE receives an SS block from gNB#2. In step ST1966, the UE establishes downlink synchronization with gNB#2.
[0258] Step ST1430 in Figure 20 is the same as in Figure 14.
[0259] In step ST1970 in Figure 20, the UE notifies gNB#2 that the handover is complete. This notification may include, for example, the RRC Reconfiguration Complete signaling. In step ST1972, gNB#2 requests AMF to reroute the UE's data. In step ST1974, AMF notifies gNB#2 of its acknowledgment of the reroute request.
[0260] As another example, the UE may transition to the RRC_IDLE state. The base station may instruct the UE to perform RRC release. The UE may perform cell reselection. The UE may reconnect to a cell that supports a desired slice by using a notification from the base station. This eliminates the need, for example, for the UE to report measurement results to the base station, and as a result, signaling between the UE and the base station can be reduced.
[0261] The RRC release instruction from the base station to the UE may include information on a base station and / or a cell that supports the UE's desired slice. A notification from the base station to the UE indicating that registration of the UE is permitted does not have to include information on a base station and / or a cell that supports the UE's desired slice. This makes it possible, for example, to reduce the signaling size in the notification of permission for UE registration.
[0262] The notification from the base station to the UE indicating that registration of the UE is permitted and the RRC release instruction may be integrated into one piece of signaling. For example, the notification indicating that registration of the UE is permitted may include the RRC release instruction, or the RRC release instruction may include the notification indicating that registration of the UE is permitted. This enables, for example, a reduction in signaling between the base station and the UE. The integrated signaling may include information on a base station and / or a cell that supports the UE's desired slice. This enables, for example, the UE to reselect a base station and / or a cell that can support the desired slice.
[0263] FIG. 21 and FIG. 22 are sequence diagrams showing a first example of an operation in which a UE connected to a base station that does not support a desired slice performs cell reconnection to a base station that supports the desired slice. FIG. 21 and FIG. 22 are connected at the position of boundary line BL2122. FIG. 21 and FIG. 22 illustrate an example where the UE transitions to RRC_IDLE. In FIG. 21 and FIG. 22, the same step numbers are assigned to processes same as those in FIG. 14, FIG. 17, FIG. 18, FIG. 19, and FIG. 20, and common descriptions are omitted.
[0264] Procedure 1401 in Figure 21 is the same as in Figure 14.
[0265] Step ST1620 in Figure 21 is the same as in Figure 17.
[0266] Steps ST1722 and ST1723 in Figure 21 are the same as in Figure 18.
[0267] Steps ST1937 and ST1938 in Figure 21 are the same as in Figure 19.
[0268] Step ST1440 in Figure 21 is the same as in Figure 14.
[0269] Steps ST1942 and ST1944 in Figure 21 are the same as in Figure 19.
[0270] In step ST2045 in Figure 21, gNB#1 instructs the UE to release the RRC. This instruction may be signaled, for example, by RRC release (RRCRelease). In step ST2046, the UE transitions to RRC_IDLE.
[0271] Step ST1624 in Figure 21 is the same as in Figure 17.
[0272] In step ST2067 in Figure 22, the UE decides to reselect the cell to gNB#2.
[0273] Step ST1430 in Figure 22 is the same as in Figure 14.
[0274] In step ST2070 in Figure 22, the UE transitions to RRC_CONNECTED. In step ST2071, the UE notifies gNB#2 that RRC setup is complete. This notification may use, for example, RRCSetupComplete signaling.
[0275] In step ST2072 in Figure 22, gNB#2 sends an initial UE message to AMF. In step ST2074, AMF requests gNB#2 to set the initial context. In step ST2076, the initial context is set between the UE and gNB#2. In step ST2078, gNB#2 notifies AMF of the initial context setting response.
[0276] As another example, the UE may transition to the RRC_INACTIVE state. The base station may instruct the UE to stop RRC. The UE may perform cell reselection. The UE may use the notification from the base station to reconnect to a cell that supports the desired slice. This would achieve the same effect as described above, for example, and would also allow the UE to quickly return to the RRC_CONNECTED state.
[0277] The instruction from the base station to the UE to stop the RRC may include information about the base stations and / or cells that support the UE's desired slice. The notification from the base station to the UE authorizing the UE's registration may not include information about the base stations and / or cells that support the UE's desired slice. This can, for example, reduce the size of the signaling in the notification authorizing the UE's registration.
[0278] The notification from the base station to the UE allowing the UE to register and the instruction to stop the RRC may be integrated into a single signaling. For example, the notification allowing the UE to register may include the instruction to stop the RRC, and the instruction to stop the RRC may include the notification allowing the UE to register. This can reduce the signaling between the base station and the UE, for example. The integrated signaling may include information about base stations and / or cells that support the UE's desired slice. This allows the UE to re-select base stations and / or cells that can support the desired slice, for example.
[0279] Figures 23 and 24 are sequence diagrams illustrating a second example of an operation in which a UE connected to a base station that does not support the desired slice reconnects to a base station that does support the desired slice. Figures 23 and 24 are connected at the boundary line BL2324. Figures 23 and 24 show an example in which the UE transitions to RRC_IDLE. In Figures 23 and 24, the same steps as in Figures 14, 17, 18, 19, 20, 21, and 22 are given the same step numbers, and common explanations are omitted.
[0280] Procedure 1401 in Figure 23 is the same as in Figure 14.
[0281] Step ST1620 in Figure 23 is the same as in Figure 17.
[0282] Steps ST1722 and ST1723 in Figure 23 are the same as in Figure 18.
[0283] Steps ST1937 and ST1938 in Figure 23 are the same as in Figure 19.
[0284] Step ST1440 in Figure 23 is the same as in Figure 14.
[0285] Steps ST1942 and ST1944 in Figure 23 are the same as in Figure 19.
[0286] In step ST2145 in Figure 23, gNB#1 instructs the UE to suspend RRC. This instruction may be signaled, for example, by RRC suspension (RRCSuspend). In step ST2146, the UE transitions to RRC_INACTIVE.
[0287] Step ST1624 in Figure 23 is the same as in Figure 17.
[0288] Step ST2067 in Figure 24 is the same as in Figure 22.
[0289] Step ST1430 in Figure 24 is the same as in Figure 14.
[0290] Step ST2070 in Figure 24 is the same as in Figure 22.
[0291] In step ST2071 in Figure 24, the UE notifies gNB#2 that the RRC restart is complete. This notification may use, for example, an RRC restart completion (RRCResumeComplete) signaling.
[0292] Steps ST1972 and ST1974 in Figure 24 are the same as in Figure 20.
[0293] Disclose other solutions. Modify the registration of the UE. The registration modification may, for example, change the desired slice of the UE from a denied NSSAI to an allowed NSSAI.
[0294] The cell to which the UE is connected may be changed. The method disclosed in the above solution may be used for such change. The change may be performed by a handover; that is, the UE may maintain RRC_CONNECTED. As another example, the change may be performed by cell reselection; that is, the UE may transition to RRC_IDLE or to RRC_INACTIVE.
[0295] After a change in the UE's connected cell, the denial NSSAI information held by the UE may be cleared. This can, for example, reduce memory usage in the UE. Alternatively, the denial NSSAI information held by the UE may be retained after a change in the UE's connected cell. This can, for example, avoid design complexity in the communication system.
[0296] The UE may request the AMF to change its registration. This request from the UE may be made after the UE has changed its connected cell. Signaling for registration changes may be provided. This signaling may be RRC signaling, N2 signaling, NAS signaling, or a combination of several of the above.
[0297] The signaling for the request may include information about RAN slices. For example, the signaling for the request may include information about S-NSSAIs to be added to an authorized NSSAI, information about S-NSSAIs to be removed from an authorized NSSAI, information about S-NSSAIs to be removed from a denied NSSAI, or information about S-NSSAIs that have been added to a denied NSSAI.
[0298] The registration modification procedure may be similar to, for example, the registration procedure disclosed in Section 4.2.2.2.2 of Non-Patent Document 25 (TS23.502). In the foregoing, the signaling for registration requests may be replaced with the signaling for registration modification requests. A signaling for acceptance of registration modifications may be provided. In the foregoing, the signaling for registration acceptance may be replaced with the signaling for registration modification acceptance. This makes it possible to avoid design complexities in communication systems, for example.
[0299] The method disclosed in this second embodiment may also be applied to a base station that is separated into a CU and a DU. For example, the destination of the UE may be switched to a DU that supports the desired slice. This allows the UE to connect to a DU that supports the desired slice, even to a base station that is separated into a CU and a DU.
[0300] This second embodiment allows the UE to recover from connection rejection using the desired slice. As a result, communication that satisfies a predetermined QoS becomes possible.
[0301] Embodiment 3. During a UE handover, the pre-mobile base station may query the destination base station about the availability of support for the RAN slice used by the UE. This query may be made, for example, using handover request signaling. The destination base station may notify the pre-mobile base station about the availability of support for the RAN slice. This notification may be made, for example, using handover request acknowledgment signaling or handover rejection signaling.
[0302] As described above, the following problem arises: If the base station to which the UE is to be handed over does not support the desired slice of the UE, the UE cannot hand over to that base station. As a result, the UE's communication service will be interrupted.
[0303] This third embodiment discloses a method for solving the aforementioned problems.
[0304] The destination base station authorizes the handover of the UE. The destination base station notifies the AMF of information regarding the RAN slices it can support. The AMF notifies the destination base station to use the default S-NSSAI. The destination base station notifies the pre-location base station to use the default S-NSSAI. The pre-location base station notifies the UE to use the default S-NSSAI. This notification from the pre-location base station to the UE may be made using handover instruction signaling, such as RRCReconfiguration signaling.
[0305] The registration of the UE may be changed. The method disclosed in Embodiment 2 may be used for such change of registration.
[0306] Other RAN slices may be used in communication between the UE and the destination base station. These RAN slices may be RAN slices authorized by the UE, RAN slices supported by the destination base station, or RAN slices authorized by the UE and supported by the destination base station. The UE's PDU session may be modified. For example, the mapping between RAN slices and PDU sessions may be changed. For example, the procedure disclosed in section 4.3.3.2 of Non-Patent Document 25 (TS23.502) may be used to modify the PDU session. This makes it possible to use other RAN slices authorized by the UE, for example. As a result, QoS can be ensured in the UE's communication.
[0307] The method disclosed in Embodiment 3 may be applied to UE handover using multiple RAN slices. For example, in a PDU session using a RAN slice not supported by the destination base station, the default S-NSSAI may be used, or other RAN slices may be used. This makes it possible to prevent the interruption of some PDU sessions even in UE handover using multiple RAN slices.
[0308] As another example, communication using a RAN slice not supported by the destination base station may be performed using another base station (which may be referred to as the DC destination base station). For example, DC may occur in conjunction with a UE handover. This allows the UE to ensure QoS of communication even after the handover.
[0309] The destination base station may determine whether or not a DC is possible. The destination base station may determine the destination base station for the DC. The destination base station may make the determination of whether or not a DC is possible and / or determine the destination base station for the DC using, for example, information it possesses about RAN slices supported by other base stations. The destination base station may request the destination base station for a DC using the UE's desired slice. This request may be made, for example, using a Secondary Base Station Addition Request (SN Addition Request). This request may include information about the UE's desired slice. The destination base station may determine whether or not a DC is possible using information about the UE's desired slice. The destination base station may notify the destination base station of its response to the request. This response may be, for example, an SN Addition Request Acknowledgement or an SN Addition Request Reject.
[0310] This DC configuration may be used in situations other than handover. For example, it may be used when a UE connects to a NW. For instance, if the base station to which the UE connects does not support the desired slice, a base station that does support the desired slice may be configured as a secondary base station.
[0311] This DC configuration may also be used, as another example, when adding services at a UE. For example, if a base station does not support the RAN slice required for a service added at a UE, the base station may add a base station that supports the RAN slice as a secondary base station. The UE may notify the base station of information regarding the RAN slice required for the added service. The base station may use this notification to decide which base station to add as a secondary base station. This allows the communication system to respond flexibly to the addition of services at the UE, for example.
[0312] As another example, the DC configuration may be implemented using base stations that support the same RAN slice. That is, the master base station and the secondary base station may support the same RAN slice. This allows for flexible switching of bearers between the master and secondary base stations, for example.
[0313] This third embodiment allows the UE to continue communication even after handover to a base station that does not support the desired slice.
[0314] Embodiment 4. In SL communication, in addition to direct communication between UEs, indirect communication via relay has been proposed (see Non-Patent Document 29 (3GPP TR 23.703 V12.0.0)). Relays between UEs are sometimes referred to as UE-to-UE relays or inter-UE relays. In this disclosure, a UE that implements an inter-UE relay may be referred to as a relay UE.
[0315] For example, when multiple UEs traveling in a convoy approach an intersection, direct communication between UEs may become impossible due to blocking by buildings or other obstacles. Furthermore, UEs may need to communicate not only with nearby UEs but also with multiple UEs located further away. In such cases, using inter-UE relays can be considered. For instance, SL communication between a transmitting UE (sometimes referred to as UE-TX) and a receiving UE (sometimes referred to as UE-RX) can be performed via a relay UE. SL communication between UEs via a relay UE is sometimes referred to as inter-UE indirect communication.
[0316] Services (or applications) that use SL communication between UEs are conducted between UE-TX and UE-RX. Therefore, in direct UE-to-UE communication, QoS for SL communication and SL wireless bearer (sometimes called SLRB) settings are configured between UE-TX and UE-RX to meet the QoS requirements of the service. However, in indirect UE-to-UE communication using relay UEs, communication is mediated through the relay UEs, resulting in SL communication between UE-TX and the relay UE, and between the relay UE and UE-RX. Consequently, the conventional direct UE-to-UE communication method cannot perform the necessary QoS and SLRB settings between UE-TX and the relay UE, and between the relay UE and UE-RX, which are required for indirect UE-to-UE communication using relay UEs. As a result, the QoS requirements of the service cannot be met.
[0317] This fourth embodiment discloses a method for solving these problems.
[0318] Configure the SLRB settings for both the SL between UE-TX and relay UE, and the SL between relay UE and UE-RX. Alternatively, the SLRB settings between UE-TX and relay UE may be used to configure the SLRB between relay UE and UE-RX. This allows the SLRB between relay UE and UE-RX to be set to the same value as the SLRB between UE-TX and relay UE.
[0319] For SL communication between UE-TX and relay UE, an SLRB setting corresponding to the service performed between UE-TX and UE-RX may be used. For QoS between UE-TX and relay UE, the QoS required for the service performed between UE-TX and UE-RX may be used. The SLRB setting for SL communication between UE-TX and relay UE may be derived using information regarding the QoS required for the service between UE-TX and UE-RX. In this way, the SLRB between UE-TX and relay UE can be configured to satisfy the QoS required for the service. Furthermore, by combining the method of using the SLRB setting between UE-TX and relay UE with the SLRB setting between relay UE and UE-RX described above, an SLRB setting corresponding to the service performed between UE-TX and UE-RX can be configured for SL communication between relay UE and UE-RX. The SLRB between relay UE and UE-RX can be configured to satisfy the QoS required for the service performed between UE-TX and UE-RX.
[0320] Information regarding QoS may include PC5 QoS parameters (sometimes simply referred to as QoS parameters, omitting PC5). PC5 QoS parameters may include, for example, PQI (see Non-Patent Document 26 (TS23.287 V16.1.0)). Information regarding QoS may also include QoS characteristics (see Non-Patent Document 26 (TS23.287 V16.1.0)). PC5 QoS parameters and QoS characteristics may be collectively referred to as a QoS profile.
[0321] When a service using SL communication occurs between UE-TX and UE-RX, UE-TX derives the service type of the service (e.g., PSID, ITS-AID, etc.), the request for the service, the identifier of the destination UE, and the identifier of the source UE. Using the service type of the service (e.g., PSID, ITS-AID, etc.) and the request for the service, UE-TX derives one or more PC5 QoS parameters required for the service.
[0322] If a PC5 QoS flow exists that corresponds to a PC5 QoS parameter, UE-TX updates the PC5 QoS flow to suit that parameter. If a PC5 QoS flow does not exist that corresponds to a PC5 QoS parameter, UE-TX creates a new PC5 QoS flow that suits that parameter. A new PC5 QoS flow identifier (sometimes referred to as PFI) may be set to identify the PC5 QoS flow.
[0323] The UE-TX derives PC5 QoS rules for mapping service data to a configured PC5 QoS flow. The PC5 QoS rules may include PC5 packet filters. The UE-TX may store the PC5 QoS parameters, V2X service types, and PC5 QoS rules for the UE-RX.
[0324] Some or all of the derivation of PC5 QoS parameters, PC5 QoS flow configuration, PFI configuration, and PC5 QoS rule derivation may be performed at a layer higher than SDAP, or between SDAP and the application layer. A layer having some or all of the processing functions may be provided in UE-TX, and some or all of the processing may be performed in the V2X layer of UE-TX.
[0325] The PC5 QoS flow is mapped to the SLRB used for SL communication. This mapping may be performed at the SDAP layer of the UE-TX. The SLRB configuration for SL communication between the UE-TX and the relay UE is derived using information about the QoS required for the service between the UE-TX and the UE-RX. The SLRB configuration may be made to satisfy the said QoS information. The SLRB configuration may be derived, for example, by a pre-configured method within the UE-TX. This method may be applied when the UE-TX is not under the gNB umbrella and / or when the UE-TX is outside the coverage.
[0326] In direct communication between UEs, an SDAP is provided for each destination UE. However, no documentation has been disclosed on how to configure an SDAP when indirect communication between UEs is performed via a relay UE. This document discloses how to configure an SDAP when indirect communication between UEs is performed via a relay UE.
[0327] The SDAP in UE-TX may be the same for both indirect and direct inter-UE communication. If the destination UE is the same for both indirect and direct inter-UE communication, the SDAP in UE-TX may be the same for both. Doing so makes it possible to reduce the number of SDAPs that make up UE-TX and relay UEs. It also makes it easier to configure UE-TX and relay UEs.
[0328] We will disclose other methods.
[0329] The SDAP in UE-TX may be separated for indirect inter-UE communication and for direct inter-UE communication. Even if the destination UE is the same for both indirect and direct inter-UE communication, the SDAP in UE-TX may be provided separately for indirect and direct inter-UE communication. By doing so, different SDAPs can be used for indirect and direct inter-UE communication in UE-TX and relay UE. This reduces malfunctions and improves the reliability of indirect inter-UE communication via relay UE.
[0330] The SDAP configuration method described above may also be applied to the SDAP configuration method in the relay UE. Similar effects can be obtained between the relay UE and the UE-RX.
[0331] The UE-TX notifies the relay UE of the SLRB settings. The UE-TX may also notify the relay UE of the configured PFI and the SLRB settings of the SLRB that maps the PFI to the PC5 QoS flow. This notification may be made during the PC5-S link establishment process. This notification may also be made using PC5-S signaling. For example, this notification may be made during the direct communication process in PC5. This allows for earlier notification. As another notification method, PC5's RRC signaling may be used. The information to be notified may be included in a PC5 RRC message and notified using PC5 RRC signaling. When notifying of PFI and SLRB settings, the PFI and SLRB settings may be notified using different signaling. This allows for flexible timing of configuration. In this way, the UE-TX can notify the relay UE of the PFI and / or SLRB settings.
[0332] The UE-TX may notify the relay UE of information regarding services that use SL communication. PC5-S signaling may be used for these notifications. For example, direct communication in PC5 may be used. Another notification method may be PC5 RRC signaling. In combination with the aforementioned SLRB notifications, the service and SLRB settings may be associated and notified. The relay UE will then be able to recognize the service and the corresponding SLRB setting.
[0333] SLRB settings include SLRB parameters that are relevant only to the sender, SLRB parameters that are relevant to both the sender and receiver, and SLRB parameters that are relevant only to the receiver. Examples of SLRB parameters that are relevant only to the sender include the ROHC profile and the MaxRetxThreshold. Examples of SLRB parameters that are relevant to both the sender and receiver include the SLRB identifier (sometimes called the SLRB ID) and one or more QoS flows mapped to the SLRB. Examples of SLRB parameters that are relevant only to the receiver include the reordering timer (T-reordering timer), which indicates the time during which data can be rearranged, and the reassembly timer (T-Reassembly timer), which indicates the time during which data can be reassembled.
[0334] In direct communication between UEs, the UE-TX only needs to notify the UE-RX of SLRB parameters relevant to both the sender and receiver in order to ensure consistency in SLRB settings between the sender and receiver. However, in indirect communication between UEs, the UE-TX notifies the relay UE of not only SLRB parameters relevant to both the sender and receiver, but also SLRB parameters relevant only to the sender. The UE-TX may also notify the relay UE of SLRB parameters relevant only to the receiver. This allows for SLRB configuration for SL communication between the relay UE and the UE-RX. Information regarding SLRB settings notified between each node is sometimes referred to as SLRB-related information.
[0335] The relay UE uses the SLRB-related information received from the UE-TX to configure the SLRB settings for SL communication between the relay UE and the UE-RX. The relay UE may also configure the SLRB settings for SL communication between the relay UE and the UE-RX to be the same as the SLRB settings for SL communication between the UE-TX and the relay UE.
[0336] The relay UE may configure the SLRB for SL communication between the relay UE and the UE-RX using SLRB-related information received from the UE-TX, regardless of the RRC connection status of the Uu.
[0337] Alternatively, the SLRB configuration method may be varied depending on the RRC connection status of the relay UE's Uu. Furthermore, the SLRB configuration method may be varied depending on whether the relay UE is within the coverage of a RAN node. For example, if the relay UE is outside the coverage of a RAN node, the relay UE uses the aforementioned method to configure the SLRB for SL communication between the relay UE and the UE-RX using the SLRB-related information received from the UE-TX. If the relay UE is within the coverage of a RAN node, the relay UE uses the method disclosed in Modification 8 of Embodiment 4 to configure the SLRB for SL communication between the relay UE and the UE-RX using the SLRB-related information received from the RAN node.
[0338] These configuration methods may be predetermined by standards, or they may be notified in advance from the CN or RAN node, or they may be notified to the UE-TX or relay UE. This allows for flexible SLRB configuration according to the connection status of each node.
[0339] The PFI between UE-TX and relay UE may be used as the PFI between relay UE and UE-RX. The PFI between UE-TX and relay UE may be used as the identifier for the PC5 QoS flow between relay UE and UE-RX. Relay UE may set the PFI received from UE-TX as the PFI between relay UE and UE-RX.
[0340] The relay UE does not need to configure a PC5 QoS flow to map the data to be relayed. The relay UE maps the data received from the UE-TX to the SLRB configured for SL communication between the relay UE and the UE-RX.
[0341] The relay UE may configure a PC5 QoS flow to map the data to be relayed. For example, a PC5 QoS flow for relaying may be configured. A default PC5 QoS flow may be provided. The default PC5 QoS flow may be used as the PC5 QoS flow for relaying. The default PC5 QoS flow may be predetermined by standards, or it may be notified in advance from the core network or RAN nodes, or it may be pre-configured within the relay UE. It is advisable to configure the aforementioned PFI in the configured PC5 QoS flow. The relay UE may map the data received from the UE-TX to the configured PC5 QoS flow. The relay UE maps the configured PC5 QoS flow to the SLRB configured for SL communication between the relay UE and the UE-RX.
[0342] A relay UE does not need to provide a service policy between the relaying UE-TX and UE-RX. Examples of service policies (sometimes referred to as PC5 policies) include mapping settings from V2X service types to PC5 QoS parameters (sometimes referred to as PC5 QoS mapping settings), and mapping settings of SLRB settings and PC5 QoS profiles to SLRB (see Non-Patent Document 26 (TS23.287 V16.1.0)).
[0343] For example, the CN (Core Network) or RAN does not need to provide a PC5 policy to the relay UE. For example, the PC5 policy does not need to be pre-configured within the relay UE.
[0344] The relay UE notifies the UE-RX of the PFI and SLRB settings configured for SL communication between the relay UE and the UE-RX. The relay UE may notify only the SLRB parameters related to the sender and receiver as the SLRB settings. This notification may be made during the PC5-S link establishment process. This notification may also be made using PC5-S signaling. For example, this notification may be made during the direct communication process in PC5. This allows for earlier notification. As another notification method, PC5's RRC signaling may be used. The information to be notified may be included in a PC5 RRC message and notified using PC5 RRC signaling. When notifying PFI and SLRB settings, the PFI and SLRB settings may be notified using different signaling. This allows for flexible timing of configuration. In this way, the relay UE can notify the UE-RX of the PFI and / or SLRB settings. The UE-RX receives the PFI and SLRB-related information from the relay UE and configures the SLRB for SL communication between the relay UE and the UE-RX.
[0345] The relay UE may notify the UE-RX of information regarding services that use SL communication. PC5-S signaling may be used for these notifications. For example, direct communication in PC5 may be used. Another notification method may be PC5 RRC signaling. In combination with the aforementioned SLRB notifications, the services and SLRB settings may be associated and notified. The UE-RX will then be able to recognize the services and their corresponding SLRB settings.
[0346] A default SLRB may be provided for use in notifications from UE-TX to relay UE and from relay UE to UE-RX. The default SLRB setting may be predetermined by standards, notified in advance from the core network or RAN node, or pre-configured within UE-TX or relay UE. The default SLRB may also be used as an SRB. PFI and SLRB configuration information may be treated as control information. The default SLRB may also be used as a DRB. PFI and SLRB configuration information may also be treated as data. In this way, prior to configuring the SLRB for service data communication using SL communication, the configuration information necessary for said configuration can be notified between UE-TX and relay UE, and between relay UE and UE-RX.
[0347] This allows for the configuration of QoS and SLRB for SL communication between UE-TX and Relay UE, and between Relay UE and UE-RX. As a result, service data generated between UE-TX and UE-RX can be transmitted between UE-TX and UE-RX via Relay UE.
[0348] Figure 25 is a sequence diagram showing an example of how to configure QoS and SLRB in inter-UE indirect communication via a relay UE for Embodiment 4. Figure 25 shows the case where a V2X service occurs at UE-TX. Service data is transmitted from UE-TX to UE-RX via the relay UE.
[0349] In step ST4101, the UE-TX derives QoS-related information from the service that occurred. In step ST4102, the UE-TX configures the PFI using the QoS-related information. As mentioned above, for example, if there is no PC5 QoS flow that is suitable for the PC5 QoS parameters derived from the service, a new PC5 QoS flow is created and the PFI is configured for that PC5 QoS flow.
[0350] In step ST4103, the UE-TX configures the SLRB for SL communication between the UE-TX and the relay UE. This SLRB configuration may be derived using QoS-related information required for the service between the UE-TX and the UE-RX. The example in Figure 25 discloses the case where the UE-TX is not under the umbrella of the gNB and is out of coverage (sometimes referred to as OOC (Out Of Coverage)). If the UE-TX is OOC, the SLRB configuration may be derived using QoS-related information required for the service from information pre-configured within the UE, such as PC5 QoS parameters and SLRB configuration information. The UE-TX uses the derived SLRB configuration for SL communication between the UE-TX and the relay UE.
[0351] In step ST4104, the UE-TX notifies the relay UE of the configured PFI and SLRB-related information. The UE-TX notifies not only the SLRB parameters related to both the transmitter and receiver, but also the SLRB parameters related only to the transmitter. The UE-TX may also notify the SLRB parameters related only to the receiver.
[0352] In step ST4105, the relay UE uses the information related to the transmitter and receiver from the SLRB-related information between the UE-TX and the relay UE, which it received from the UE-TX, to configure the SLRB for SL communication between the UE-TX and the relay UE.
[0353] In steps ST4106 and ST4107, the relay UE configures the SLRB for SL communication between the relay UE and the UE-RX. In step ST4106, the relay UE sets the PFI notified by the UE-TX to the PFI between the relay UE and the UE-RX. In step ST4107, the relay UE uses all the SLRB-related information notified by the UE-TX to set the SLRB configuration between the relay UE and the UE-RX to be the same as the SLRB configuration between the UE-TX and the relay UE.
[0354] In step ST4108, the relay UE notifies the UE-RX of the SLRB-related information configured for SL communication between the relay UE and the UE-RX. Here, the relay UE only needs to notify the information related to the transmitter and receiver from the SLRB-related information. In step ST4109, the UE-RX uses the SLRB-related information received from the relay UE to configure the SLRB for SL communication between the relay UE and the UE-RX.
[0355] In step ST4110, UE-RX notifies relay UE that the SLRB configuration between relay UE and UE-RX is complete. UE-RX may include PFI in the completion notification. Upon receiving the completion notification from UE-RX, relay UE, in step ST4111, notifies UE-TX that the SLRB configuration between UE-TX and relay UE is complete, and that the SLRB configuration between relay UE and UE-RX is complete. Relay UE may include PFI in the completion notification.
[0356] In step ST4112, UE-TX transmits service data to relay UE using the SLRB configuration between UE-TX and relay UE. In step ST4113, relay UE receives the data transmitted from UE-TX using the SLRB configuration between UE-TX and relay UE, and maps the received data to the SLRB between relay UE and UE-RX. In step ST4114, relay UE transmits the mapped data to UE-RX using the SLRB configuration between relay UE and UE-RX.
[0357] In this way, service data generated at UE-TX can be transmitted to UE-RX via relay UE.
[0358] The notification in step ST4111, i.e., the notification that the SLRB configuration between the UE-TX and the relay UE is complete, may be made by the relay UE to the UE-TX after the relay UE has completed the SLRB configuration between the UE-TX and the relay UE in step ST4105. For example, the notification that the SLRB configuration between the UE-TX and the relay UE is complete may be made before the processing from step ST4106 to step ST4110, i.e., before the SLRB configuration between the relay UE and the UE-RX. This allows the UE-TX to recognize that communication of service data using SL communication is now possible between the UE-TX and the relay UE. Upon receiving the notification from the relay UE that the SLRB configuration between the UE-TX and the relay UE is complete, the UE-TX may send service data to the relay UE.
[0359] The relay UE may store the service data received from the UE-TX until the SLRB configuration between the relay UE and the UE-RX is complete. It is advisable to provide a buffer on the relay UE to store the received service data. In the case of an L2 (Layer 2) relay, the received service data may be stored in PDCP PDU format or RLC SDU format. This allows for the assignment of an RLC SN (Sequence number) between the relay UE and the UE-RX independently of the RLC SN between the UE-TX and the relay UE, providing greater flexibility in the operation of the communication system. In the case of an L3 (Layer 3) relay, the received service data may be stored in packet data format or SDAP SDU format. After the SLRB configuration between the relay UE and the UE-RX is complete, the relay UE should transmit the stored service data to the UE-RX.
[0360] This approach allows service data to be transmitted from the relay UE to the UE-RX soon after the SLRB configuration between the relay UE and the UE-RX is complete. This enables low-latency communication of service data from the UE-TX to the UE-RX via the relay UE.
[0361] The method described above can also be applied to modifying the SLRB settings for each SL communication. Simply change the settings of each SL communication's SLRB to the modified SLRB settings for that specific SL communication. A similar effect can be achieved. For subsequent notifications of modified SLRB settings between nodes, only the modified parameters may be notified. Alternatively, the difference from the previous SLRB settings may be notified. This reduces the amount of information that needs to be notified.
[0362] Information indicating incomplete SLRB configuration may be provided. Information indicating rejection of SLRB configuration may be provided. Signaling to notify such information may be provided. The incomplete or rejection information for SLRB configuration may be provided on a per-link basis. The signaling may be a PC5-S signaling or a PC5 RRC signaling. There may be cases where the relay UE cannot configure the SLRB. For example, the relay UE may not be able to configure the SLRB for SL communication between the relay UE and the UE-RX due to insufficient wireless resources. In such cases, the relay UE may notify the UE-TX of the SLRB configuration rejection signaling for SL communication between the relay UE and the UE-RX.
[0363] Reasons for rejection may be provided. For example, insufficient buffer space. For example, information indicating the buffer space value may be provided. The buffer space value may be notified along with the rejection reason information. In this way, UE-TX can recognize that SLRB configuration is not possible on the relay UE.
[0364] A UE-TX that receives an SLRB configuration rejection signaling may configure the SLRB settings. The UE-TX may also notify the relay UE of the changed SLRB settings. This makes it easier for the relay UE to configure the SLRB settings.
[0365] If SLRB configuration is not possible on the relay UE, the default SLRB may be used for service data communication. The default DRB may be used as the default SLRB. For example, if SLRB configuration between the relay UE and the UE-RX is not possible on the relay UE, the relay UE notifies the UE-TX of an SLRB configuration denial signaling between the relay UE and the UE-RX. The relay UE then performs SL communication using the default DRB as the SLRB configuration between the relay UE and the UE-RX. The relay UE may also notify the UE-TX that it will use the default DRB for SL communication between the relay UE and the UE-RX. This notification may be sent together with the SLRB configuration denial information notified from the relay UE to the UE-TX. In this way, SL communication can be performed even if the desired SLRB configuration is not possible on the relay UE.
[0366] By using the method disclosed in Embodiment 4, the SLRB between UE-TX and relay UE can be configured to satisfy the QoS required for the service. Furthermore, by using the SLRB settings between UE-TX and relay UE for the SLRB between relay UE and UE-RX, it becomes possible to satisfy the same QoS for services between relay UE and UE-RX as for services between UE-TX and relay UE. In indirect UE-to-UE communication via relay UE, it becomes possible to satisfy the QoS required for services using said communication.
[0367] Furthermore, the same SLRB settings can be used between UE-TX and relay UE, and between relay UE and UE-RX. This simplifies the SLRB settings on relay UEs and reduces malfunctions in indirect communication between UEs via relays.
[0368] Multiple SLRB settings may be provided for SL communication. These may be referred to as SLRB setting candidates. The UE-TX may provide multiple SLRB settings and configure one of them as the SLRB for SL communication between the UE-TX and the relay UE.
[0369] The UE-TX may notify the relay UE of SLRB configuration candidates. The relay UE may select one of the SLRB configuration candidates as the SLRB configuration for SL communication between the relay UE and the UE-RX.
[0370] An identifier may be provided to distinguish each SLRB setting within the list of SLRB setting candidates.
[0371] The UE-TX may notify the relay UE of the SLRB setting candidates, along with an identifier indicating the SLRB setting to be used for SL communication between the relay UE and the UE-RX. For example, the relay UE sets the SLRB setting identified by the identifier indicating the SLRB setting as the SLRB for SL communication between the relay UE and the UE-RX.
[0372] This approach allows for the implementation of SLRB settings for each SL communication, taking into account the QoS required for services that perform indirect communication between UEs via relay UEs, as well as the wireless resource usage of each node.
[0373] Candidate SLRB settings and identifiers for identifying specific SLRB settings within those candidates may be notified using different signaling. For example, candidate SLRB settings may be notified using PC5-S signaling, and identifiers for identifying specific SLRB settings within those candidates may be notified using PC5 RRC signaling. This allows for flexible SLRB configuration.
[0374] SL communications include unicast communications, which perform one-to-one bidirectional communication; groupcast communications, which allow one UE to communicate with a group of one or more UEs; and broadcast communications, which allow one UE to transmit to one or more UEs. In indirect inter-UE communication via relay UEs, even if the SL communication on each link is not limited to unicast communications, but also includes groupcast and broadcast communications, the methods described above may be appropriately applied to the QoS and SLRB settings.
[0375] For example, when configuring SLRB settings, you should use SLRB parameters related to unicast communication for unicast communication, SLRB parameters related to groupcast communication for groupcast communication, and SLRB parameters related to broadcast communication for broadcast communication.
[0376] For example, if unicast communication is used between UE-TX and relay UE, and unicast communication is used between relay UE and UE-RX, UE-TX should notify relay UE of the SLRB parameters for unicast communication as the SLRB settings between UE-TX and relay UE, and the SLRB parameters for unicast communication as the SLRB settings between relay UE and UE-RX. Relay UE will then be able to configure the SLRB for unicast communication between UE-TX and relay UE, and will also be able to configure the SLRB for unicast communication between relay UE and UE-RX.
[0377] For example, if unicast communication is used between UE-TX and relay UE, and groupcast communication is used between relay UE and UE-RX, UE-TX should notify relay UE of the SLRB parameters for unicast communication as the SLRB settings between UE-TX and relay UE, and the SLRB parameters for groupcast communication as the SLRB settings between relay UE and UE-RX. Relay UE will then be able to configure the SLRB for unicast communication between UE-TX and relay UE, and will be able to configure the SLRB for groupcast communication between relay UE and UE-RX.
[0378] This allows for QoS and SLRB settings to be configured not only when using unicast communication but also when using groupcast communication or broadcast communication in each SL for indirect communication between UEs via relay UEs.
[0379] Modification 1 of Embodiment 4. Modification 1 of this embodiment 4 discloses another method for solving the problems described in embodiment 4. The main points to be described are the differences from the method disclosed in embodiment 4.
[0380] Relay UE configures the SLRB between Relay UE and UE-RX.
[0381] The relay UE may configure the PFI between the relay UE and the UE-RX. The relay UE may configure the PC5 QoS flow.
[0382] The UE-TX may notify the relay UE of QoS-related information required for services between the UE-TX and the UE-RX. The relay UE may use the QoS-related information received from the UE-TX to configure the PC5 QoS flow and / or PFI. As a configuration method, the method disclosed in Embodiment 4, in which the UE-TX configures the PC5 QoS flow and / or PFI, may be applied. The relay UE may store the PC5 QoS parameters for the UE-RX.
[0383] The relay UE may configure the SLRB between the relay UE and the UE-RX using the PC5 QoS parameters notified by the UE-TX. The relay UE may arbitrarily configure the relevant information for the SLRB to be configured. The relay UE may configure the SLRB to satisfy the PC5 QoS parameters. Alternatively, for example, the SLRB configuration may be derived by a pre-configured method within the relay UE. This method may be applied when the relay UE is not under the gNB umbrella and / or when the UE-TX is outside the coverage.
[0384] The UE-TX notifies the relay UE of the configured PFI and the SLRB settings for the SLRB that maps the PFI to the corresponding PC5 QoS flow. The UE-TX may also notify the relay UE of only the SLRB parameters related to the sender and receiver. The relay UE can then configure the SLRB for SL communication between the UE-TX and the relay UE.
[0385] Figure 26 is a sequence diagram showing an example of how to configure QoS and SLRB in indirect UE communication via a relay UE, for a modified example 1 of Embodiment 4. Figure 26 shows the case when a V2X service occurs at UE-TX. Service data is transmitted from UE-TX to UE-RX via the relay UE. In Figure 26, steps common to Figure 25 are given the same step numbers, and common explanations are omitted.
[0386] In step ST4201, the UE-TX notifies the relay UE of the derived QoS-related information, the configured PFI, and the SLRB-related information of the SLRB that maps the PC5 QoS flow corresponding to the PFI. The SLRB-related information may consist only of SLRB parameters related to the sender and receiver.
[0387] In steps ST4202 and ST4203, the relay UE configures the SLRB for SL communication between the relay UE and the UE-RX. In step ST4202, the relay UE uses the QoS-related information notified by the UE-TX to configure the PC5 QoS flow and the PFI to identify the PC5 QoS flow.
[0388] The PC5 QoS flow configuration may be a PC5 QoS flow configuration specifically for relays. This QoS flow may be separate from the PC5 QoS flow configured when a service using SL communication occurs in the relay UE. The relay UE does not need to configure a PC5 QoS flow for relays. The relay UE may map data received from UE-TX to a transmission SLRB to UE-RX without using a PC5 QoS flow to UE-RX. Even if a PC5 QoS flow is not configured, PFI may still be configured.
[0389] In step ST4203, the relay UE uses the QoS-related information notified by the UE-TX to configure the SLRB between the relay UE and the UE-RX. The relay UE configures the SLRB to satisfy the QoS-related information notified by the UE-TX.
[0390] This allows for the configuration of QoS and SLRB for SL communication between UE-TX and Relay UE, and between Relay UE and UE-RX. As a result, service data generated between UE-TX and UE-RX can be transmitted between UE-TX and UE-RX via Relay UE.
[0391] By using the method disclosed in Modification 1 of Embodiment 4, the SLRB between the UE-TX and the relay UE can be configured to satisfy the QoS required for the service. Furthermore, by notifying the relay UE of the QoS-related information derived by the UE-TX, the relay UE can recognize the QoS-related information (QoS-related information) required for the service between the UE-TX and the UE-RX. The relay UE can then use this QoS-related information to configure the SLRB between the relay UE and the UE-RX. This makes it possible to satisfy the QoS required for the service between the UE-TX and the UE-RX in SL communication between the relay UE and the UE-RX. It also makes it possible to satisfy the QoS required for the service using indirect UE-to-UE communication via the relay UE.
[0392] Furthermore, since the relay UE configures the SLRB between the relay UE and the UE-RX, it is possible to configure the SLRB to suit the relay UE's wireless resources and the radio wave propagation environment between the relay UE and the UE-RX. This improves the efficiency of the relay UE's wireless resource utilization and enhances the communication quality of SL communication between the relay UE and the UE-RX.
[0393] The UE-TX may configure multiple QoS-related information sets required for services between the UE-TX and the UE-RX. These multiple QoS-related information sets between the UE-TX and the UE-RX may be referred to as QoS-related information candidates. The UE-TX may also configure multiple QoS-related information sets and notify the relay UE of one of them.
[0394] The UE-TX may notify the relay UE of candidate QoS-related information. The relay UE may select one of the candidate QoS-related information for SL communication between the relay UE and the UE-RX, and use the selected QoS-related information to configure the SLRB.
[0395] An identifier may be provided to identify each QoS-related piece of information within the candidate QoS-related information.
[0396] The UE-TX may notify the relay UE of a candidate for QoS-related information, along with an identifier indicating QoS-related information for SL communication between the relay UE and the UE-RX. For example, the relay UE uses the QoS-related information identified by the identifier indicating the QoS-related information to configure the SLRB for SL communication between the relay UE and the UE-RX.
[0397] In this way, by providing multiple candidate QoS settings required for services that perform indirect communication between UEs via relay UEs, it becomes possible to configure SLRB settings for each SL communication using a QoS suitable for, for example, the wireless resource usage of each node or the communication quality between each node.
[0398] Candidate QoS-related information and identifiers for identifying the QoS-related information within those candidates may be notified using different signaling. For example, candidate QoS-related information may be notified using PC5-S signaling, and identifiers for identifying the QoS-related information within those candidates may be notified using PC5 RRC signaling. This allows for flexible notification of QoS-related information.
[0399] SL communications include unicast communications, which perform one-to-one bidirectional communication; groupcast communications, which allow one UE to communicate with a group of one or more UEs; and broadcast communications, which allow one UE to transmit to one or more UEs. In indirect inter-UE communication via relay UEs, even if the SL communication on each link is not limited to unicast communications, but also includes groupcast and broadcast communications, the methods described above may be appropriately applied to the QoS and SLRB settings.
[0400] For example, when configuring SLRB settings, you should use SLRB parameters related to unicast communication for unicast communication, SLRB parameters related to groupcast communication for groupcast communication, and SLRB parameters related to broadcast communication for broadcast communication.
[0401] For example, if unicast communication is used between UE-TX and relay UE, and unicast communication is used between relay UE and UE-RX, UE-TX should notify relay UE of the SLRB parameters for unicast communication as the SLRB settings between UE-TX and relay UE, and the SLRB parameters for unicast communication as the SLRB settings between relay UE and UE-RX. Relay UE will then be able to configure the SLRB for unicast communication between UE-TX and relay UE, and will also be able to configure the SLRB for unicast communication between relay UE and UE-RX.
[0402] For example, if unicast communication is used between UE-TX and relay UE, and groupcast communication is used between relay UE and UE-RX, UE-TX should notify relay UE of the SLRB parameters for unicast communication as the SLRB settings between UE-TX and relay UE, and the SLRB parameters for groupcast communication as the SLRB settings between relay UE and UE-RX. Relay UE will then be able to configure the SLRB for unicast communication between UE-TX and relay UE, and will be able to configure the SLRB for groupcast communication between relay UE and UE-RX.
[0403] This allows for QoS and SLRB settings to be configured not only when using unicast communication but also when using groupcast communication or broadcast communication in each SL for indirect communication between UEs via relay UEs.
[0404] Modification 2 of Embodiment 4. In direct communication between UEs, a PFI is assigned a unique identifier within the same source and destination UE range (see Non-Patent Document 26 (TS23.287 V16.1.0)). That is, the same identifier cannot be assigned to multiple PFIs set up within the same source and destination UE range. The identifier indicating the source UE is sometimes called the Source L2ID (SRC L2ID). The identifier indicating the destination UE is sometimes called the Destination L2ID (DST L2ID).
[0405] In indirect communication between UEs using relay UEs, the transmitting and receiving nodes for SL communication on each link are different from the transmitting and receiving nodes for V2X services. In such cases, it becomes unclear whether the DST L2ID should be used for the receiving node of SL communication on each link or the receiving node of the V2X service. As a result, inconsistencies can occur in the processing at each node in indirect communication between UEs using relay UEs, leading to malfunctions and problems where communication fails to function properly.
[0406] Modification 2 of this embodiment 4 discloses a method for solving these problems.
[0407] Set the DST L2ID to the receiving node of the V2X service. Set the DST L2ID to UE-RX.
[0408] A unique identifier may be assigned as the PFI between the UE-TX and the UE-RX. This PFI is used for SL communication between the UE-TX and the relay UE, and for SL communication between the relay UE and the UE-RX. The UE-TX may set the PFI to be used for SL communication between the UE-TX and the relay UE, and for SL communication between the relay UE and the UE-RX. The UE-TX may set the PFI to be used for SL communication between the UE-TX and the relay UE, and the relay UE may set this PFI as the PFI between the relay UE and the UE-RX.
[0409] The method described above may also be applied to the method disclosed in Embodiment 4 and Modification 1 of Embodiment 4. In Modification 1 of Embodiment 4, it was disclosed that the relay UE may use the QoS-related information received from the UE-TX to configure the PC5 QoS flow and / or the PFI. In this PFI configuration, the PFI configured by the UE-TX may be configured. The UE-TX may notify the relay UE of the configured PFI. The UE-TX may notify the configured PFI along with the QoS-related information.
[0410] This approach allows for the assignment of a unified DST L2ID between UE-TX and UE-RX, enabling consistent processing at each node. Furthermore, it simplifies processing at each node.
[0411] In the method described above, the PFI that UE-TX has set as the sole identifier between UE-TX and UE-RX may become the same as the PFI that the relay UE has set as the sole identifier between the relay UE and UE-RX when the relay UE transmits service data that has occurred between the relay UE and UE-RX.
[0412] For services performed between UE-TX and UE-RX, the SRC L2ID for SL communication between the relay UE and UE-RX may be the same as that of the source relay UE. This allows for the use of a unified SRC L2ID for data transmitted from the relay UE to the UE-RX, simplifying processing.
[0413] In such a case, the UE-RX will be unable to determine whether the data received from the relay UE is service data between the UE-TX and the UE-RX, or service data between the relay UE and the UE-RX. This is because the PFI, DST L2ID, and SRC L2ID will be the same for both types of data.
[0414] We will disclose methods for solving these problems.
[0415] The PFI between the relay UE and UE-RX is reconfigured. The relay UE determines whether the PFI set by UE-TX is the same as the PFI already set for UE-RX. If the PFIs are the same, the relay UE reconfigures the PFI between the relay UE and UE-RX to avoid duplication. The PFI set by UE-TX may be left unchanged. The relay UE notifies UE-RX of the reconfigured PFI. The relay UE may also notify the SLRB setting corresponding to the reconfigured PFI. The relay UE may also notify the SLRB ID.
[0416] The relay UE may notify the UE-RX of the PFI set by the UE-TX. The relay UE may notify the UE-RX of the PFI set by the UE-TX and the PFI that the relay UE has reconfigured. The relay UE may associate the PFI set by the UE-TX with the PFI that the relay UE has reconfigured and notify the UE-RX of this association.
[0417] Along with resetting the PFI, it may be possible to change the settings of the SLRB for SL communication between the relay UE and UE-RX. This allows for more flexible SLRB configuration. Alternatively, it may be possible to reset only the PFI without changing the SLRB settings. This eliminates the need to reset the SLRB.
[0418] The relay UE determines whether the PFI set by the UE-TX is the same as the PFI already set for the UE-RX. If the PFIs are different, the relay UE uses the PFI set by the UE-TX.
[0419] This allows for different PFIs (Personal Frequency Indicators) to be used for service data between UE-TX and UE-RX, and for service data between relay UE and UE-RX. As a result, UE-RX can determine which service data it is receiving.
[0420] We will now disclose other methods for solving the aforementioned problems.
[0421] The PFI between UE-TX and UE-RX is reconfigured. A PFI reconfiguration request may be provided. The relay UE determines whether the PFI configured by UE-TX is the same as the PFI already configured for UE-RX. If the PFIs are the same, the relay UE notifies UE-TX of a PFI reconfiguration request. The relay UE may notify PFI information already in use by its own relay UE. The relay UE may notify PFI information available to its own relay UE. The relay UE may notify PFI information already in use by its own relay UE or PFI information available to its own relay UE along with the information for the request. The relay UE may include PFI information already in use by its own relay UE or PFI information available to its own relay UE in the message for the request. Repeated PFI reconfiguration on UE-TX can be avoided.
[0422] When UE-TX receives a PFI reset request from relay UE, it resets the PFI between itself and UE-RX. Based on the PFI information received with the request, UE-TX may reset the PFI so as not to overlap with the PFI between relay UE and UE-RX. UE-TX may also reset the PC5 QoS flow. UE-TX may reset the PC5 QoS flow in order to reset the PFI.
[0423] A PC5 QoS flow reset request may be provided. Upon receiving a PC5 QoS flow reset request, the UE-TX will reset the PC5 QoS flow. The PC5 QoS flow reset request may also include a PFI reset request. Upon receiving a PC5 QoS flow reset request, the UE-TX will reset both the PC5 QoS flow and the PFI.
[0424] The UE-TX notifies the relay UE of the reconfigured PFI. The UE-TX may also notify the reconfigured PFI and the corresponding SLRB settings. The UE-TX may also notify the SLRB ID.
[0425] Along with the PFI reconfiguration, it may be possible to change the settings of the SLRB for SL communication between UE-TX and UE-RX. This allows for more flexible SLRB configuration. Alternatively, it may be possible to reconfigure only the PFI without changing the SLRB settings, thus eliminating the need for SLRB reconfiguration.
[0426] The relay UE uses the reconfigured PFI received from the UE-TX.
[0427] The relay UE determines whether the PFI set by the UE-TX is the same as the PFI already set for the UE-RX. If the PFIs are different, the relay UE uses the PFI set by the UE-TX.
[0428] This allows for different PFIs (Personal Frequency Indicators) to be used for service data between UE-TX and UE-RX, and for service data between relay UE and UE-RX. As a result, UE-RX can determine which service data it is receiving.
[0429] We will now disclose other methods for solving the aforementioned problems.
[0430] In addition to the PFI assigned between UE-TX and UE-RX, a separate PFI may be provided between relay UE and UE-RX. Relay UE sets this PFI as the PFI between relay UE and UE-RX. Relay UE should associate the PFI between UE-TX and UE-RX with the PFI between relay UE and UE-RX.
[0431] The UE-TX may notify the relay UE of the PFI to be assigned between the UE-TX and the UE-RX. The relay UE will then be able to recognize the PFI assigned between the UE-TX and the UE-RX.
[0432] Relay UE may notify UE-RX of the PFI allocated between UE-TX and UE-RX. Relay UE may notify UE-RX of the PFI to be allocated between Relay UE and UE-RX. Relay UE may notify UE-RX of the PFI allocated between UE-TX and UE-RX and the PFI to be allocated between Relay UE and UE-RX. Relay UE may associate the PFI allocated between UE-TX and UE-RX with the PFI to be allocated between Relay UE and UE-RX and notify UE-RX of this association.
[0433] For setting the SLRB for SL communication between the relay UE and UE-RX, either the setting by UE-TX or the setting by the relay UE may be used.
[0434] This allows for different PFIs (Personal Frequency Indicators) to be used for service data between UE-TX and UE-RX, and for service data between relay UE and UE-RX. As a result, UE-RX can determine which service data it is receiving.
[0435] This document discloses the PFI to be set in the header of the SDAP PDU. In the UE-TX's SDAP, the PFI to be set as the header of the SDAP PDU is the PFI set between the UE-TX and the UE-RX. In the relay UE's SDAP, the PFI to be set as the header of the SDAP PDU may be the PFI set between the UE-TX and the UE-RX. The relay UE maps the service data received from the UE-TX to the SLRB for SL communication between the relay UE and the UE-RX using the PFI between the UE-TX and the UE-RX.
[0436] In the relay UE's SDAP, the PFI set as the header of the SDAP PDU may be the same as the PFI set between the relay UE and the UE-RX. The relay UE maps the service data received from the UE-TX to the SLRB for SL communication between the relay UE and the UE-RX, using the PFI between the relay UE and the UE-RX, which is associated with the PFI between the UE-TX and the UE-RX.
[0437] We will now disclose other methods for solving the aforementioned problems.
[0438] The SRC L2IDs for service data between UE-TX and UE-RX are different from those for service data between the relay UE and UE-RX. For example, the identifier of UE-TX is set as the SRC L2ID for services between UE-TX and UE-RX, and the identifier of the relay UE is set as the SRC L2ID for services between the relay UE and UE-RX.
[0439] The UE-RX should use the SRC L2ID to determine whether the data received from the relay UE is service data between the UE-TX and the UE-RX, or service data between the relay UE and the UE-RX. Regardless of the PFI configuration, the UE-RX can differentiate between service data between the UE-TX and the UE-RX and service data between the relay UE and the UE-RX.
[0440] Another method for solving the problems shown in Modification 2 of this Embodiment 4 is disclosed.
[0441] The DST L2ID is set as the receiving node for SL communication on each link. In SL communication between UE-TX and relay UE, the DST L2ID is set as the relay UE. In SL communication between relay UE and UE-RX, the DST L2ID is set as the UE-RX.
[0442] A unique identifier may be assigned as the PFI between UE-TX and relay UE. This PFI is used for SL communication between UE-TX and relay UE. A unique identifier may also be assigned as the PFI between relay UE and UE-RX. This PFI is used for SL communication between relay UE and UE-RX. UE-TX may set the PFI used for SL communication between UE-TX and relay UE. Relay UE may set the PFI used for SL communication between relay UE and UE-RX.
[0443] Relay UE should be configured to associate the PFI between UE-TX and UE-RX with the PFI between Relay UE and UE-RX.
[0444] The methods described above may be applied to the methods disclosed in Embodiment 4 and Modification 1 of Embodiment 4. It has been disclosed that the UE-TX may configure the PC5 QoS flow and / or the PFI. In this PFI configuration, the PFI between the UE-TX and the relay UE may be configured. In Embodiment 4, it has been disclosed that the relay UE may configure the PFI received from the UE-TX as the PFI between the relay UE and the UE-RX. In this PFI configuration, the relay UE may configure the PFI used for SL communication between the relay UE and the UE-RX. The SLRB for SL communication between the relay UE and the UE-RX may be configured by the UE-TX or by the relay UE.
[0445] For the PFI to be set in the SDAP PDU header, the method described above should be applied as appropriate. The same effect can be obtained.
[0446] In this way, the destination node for each link in inter-UE indirect communication via relay UEs can be set to the DST L2ID, enabling consistent processing at each node. Furthermore, since the destination node settings for each link can be considered the same as the destination node settings for inter-UE direct communication, it becomes easier for each node to support inter-UE indirect communication.
[0447] Another method for solving the problems shown in Modification 2 of this Embodiment 4 is disclosed.
[0448] Multiple DST L2IDs will be provided. One DST L2ID will be set for the receiving node of the V2X service, and another DST L2ID will be set for the receiving node in the SL communication for each link.
[0449] A unique identifier is assigned as the PFI between UE-TX and UE-RX. Similarly, a unique identifier is assigned as the PFI between UE-TX and relay UE, and a unique identifier is assigned as the PFI between relay UE and UE-RX. The PFI between UE-TX and relay UE is used for SL communication between UE-TX and relay UE. The PFI between relay UE and UE-RX is used for SL communication between relay UE and UE-RX. UE-TX may set the PFI used for SL communication between UE-TX and relay UE. Relay UE may set the PFI used for SL communication between relay UE and UE-RX.
[0450] UE-TX may associate the PFI between UE-TX and UE-RX with the PFI between UE-TX and relay UE. Relay UE may associate the PFI between UE-TX and relay UE with the PFI between relay UE and UE-RX.
[0451] Relay UE may associate the PFI between UE-TX and UE-RX with the PFI between Relay UE and UE-RX.
[0452] The method described above may be applied to the method disclosed in Embodiment 4 and Modification 1 of Embodiment 4. It has been disclosed that PC5 QoS flow settings and / or PFI settings may be performed. In this PFI setting, a PFI between UE-TX and relay UE may be set, which is associated with the PFI between UE-TX and UE-RX. In Embodiment 4, it has been disclosed that relay UE may set the PFI received from UE-TX as the PFI between relay UE and UE-RX. In this PFI setting, relay UE may set the PFI used for SL communication between relay UE and UE-RX. The setting of the SLRB for SL communication between relay UE and UE-RX may be set by UE-TX or by relay UE.
[0453] UE-TX may notify the relay UE of multiple configured PFIs. UE-TX may also notify the configured PFIs in association with each other. This enables the relay UE to relay service data. The relay UE may notify the UE-RX of the PFI between the relay UE and the UE-RX. Alternatively, the relay UE may notify the UE-RX of the PFI between the relay UE and the UE-RX, and the PFI between the UE-TX and the UE-RX. The relay UE may also notify these PFIs in association with each other. This enables the UE-RX to receive service data from the relay UE.
[0454] This document discloses the PFI to be set in the header of the SDAP PDU. In the UE-TX's SDAP, the PFI to be set as the header of the SDAP PDU may be the same as the PFI set between the UE-TX and the UE-RX. The UE-TX maps the service data to be transmitted to the SLRB for SL communication between the UE-TX and the relay UE, using the PFI between the UE-TX and the relay UE, which is associated with the PFI between the UE-TX and the UE-RX.
[0455] In the relay UE's SDAP, the PFI set as the header of the SDAP PDU may be the same as the PFI set between the UE-TX and UE-RX. The relay UE maps the service data received from the UE-TX to the SLRB for SL communication between the relay UE and UE-RX, using the PFI between the relay UE and UE-RX, which is associated with the PFI between the UE-TX and UE-RX.
[0456] Other methods for setting the PFI in the SDAP PDU header are disclosed. In the UE-TX's SDAP, the PFI set as the header of the SDAP PDU may be the PFI set between the UE-TX and the UE-RX. In the relay UE's SDAP, the PFI set as the header of the SDAP PDU may be the PFI set between the relay UE and the UE-RX. The relay UE maps the service data received from the UE-TX to the SLRB for SL communication between the relay UE and the UE-RX using the PFI between the relay UE and the UE-RX, which is associated with the PFI between the UE-TX and the UE-RX.
[0457] Another method for setting the PFI in the SDAP PDU header is disclosed. In the UE-TX's SDAP, the PFI set as the header of the SDAP PDU may be the PFI set between the UE-TX and the relay UE. The UE-TX maps the service data to be transmitted to the SLRB for SL communication between the UE-TX and the relay UE, using the PFI between the UE-TX and the relay UE, which is associated with the PFI between the UE-TX and the UE-RX. In the relay UE's SDAP, the PFI set as the header of the SDAP PDU may be the PFI set between the relay UE and the UE-RX. The relay UE maps the service data received from the UE-TX to the SLRB for SL communication between the relay UE and the UE-RX, using the PFI between the UE-TX and the UE-RX, or the PFI between the relay UE and the UE-RX, which is associated with the PFI between the UE-TX and the relay UE.
[0458] This document discloses alternative methods for setting PFIs in the header of the SDAP PDU. In the UE-TX's SDAP, multiple PFIs are set in the header of the SDAP PDU. The PFI set between the UE-TX and UE-RX, and the PFI set between the UE-TX and the relay UE are set as the header of the SDAP PDU. In the relay UE's SDAP, multiple PFIs are set as the header of the SDAP PDU. The PFI set between the UE-TX and UE-RX, and the PFI set between the relay UE and UE-RX are set as the header of the SDAP PDU. The relay UE maps the service data received from the UE-TX to the SLRB for SL communication between the relay UE and the UE-RX, using the PFI between the relay UE and the UE-RX, which is associated with the PFI between the UE-TX and the UE-RX.
[0459] Information indicating that multiple PFIs are configured may be provided in the SDU PDU header. Information indicating the number of PFIs configured in the SDU PDU header may also be provided. For example, the number of PFIs configured in the SDU PDU header may be set to two. For example, there may be two PFIs: one configured between UE-TX and UE-RX, and another configured between UE-TX and relay UE, or between relay UE and UE-RX.
[0460] The UE-TX may notify the relay UE of the information. The relay UE may notify the UE-RX of the information. For example, the information may be notified using PC5 RRC signaling. The information may be provided as an SDU PDU header. The information may be set in the header of the SDU PDU notified from the UE-TX to the relay UE. The information may be set in the header of the SDU PDU notified from the relay UE to the UE-RX. The receiving node will be able to recognize that multiple PFIs are configured.
[0461] This allows PFI to be configured for each set DST L2ID. This enables consistent processing at each node. Furthermore, by individually configuring the destination node corresponding to the service and the destination node on each link, the mapping between the service and each link becomes clear. This reduces malfunctions in indirect communication processing between UEs via relays.
[0462] By using the method disclosed in Modification 2 of this Embodiment 4, even in cases where the transmitting and receiving nodes for SL communication on each link and the transmitting and receiving nodes for V2X services are different, such as in indirect UE communication between UEs using relay UEs, the destination node can be clearly configured. This reduces malfunctions in processing at each node in indirect UE communication between UEs using relay UEs. As a result, the reliability of the communication can be improved.
[0463] Modification 3 of Embodiment 4. In direct communication between UEs, a portion of the SRC L2ID and DST L2ID is included in the SCI (Sidelink Control Information), and the remaining portion is included in the MAC header. The receiving UE can determine whether the data mapped to the PSSCH corresponding to the SCI is intended for its own UE by receiving the portion of the DST L2ID included in the SCI. Similarly, the receiving UE can determine whether the MAC PDU is intended for its own UE by receiving the remaining portion of the DST L2ID included in the MAC header. The SCI is control information for SL communication and is mapped to the PSCCH.
[0464] In indirect communication between UEs using relay UEs, the transmitting and receiving nodes for SL communication on each link are different from the transmitting and receiving nodes for the service. In such cases, it becomes unclear whether the DST L2ID should be for the receiving node of the SL communication on each link or for the receiving node of the service. For example, in SL communication from UE-TX to relay UE, if the DST L2ID is set to UE-RX, the relay UE will not be able to determine that a portion of the DST L2ID included in the SCI (sometimes called the L1ID) is addressed to its own UE, and will not receive the PSSCH. Furthermore, even if the relay UE receives the PSSCH, it will not be able to determine that the remaining portion of the DST L2ID included in the MAC header (DST L2ID-MAC) is addressed to its own UE, and will not receive the MAC PDU. As a result, the relay UE will not be able to receive data from UE-TX.
[0465] We will disclose methods for solving these problems.
[0466] The DST L2ID for SL communication on each link should be set to the receiving node in the SL communication for that link. The DST L2ID for the service and the DST L2ID for SL communication may be different. The DST L2ID between UE-TX and relay UE should be set to relay UE. The DST L2ID between relay UE and UE-RX should preferably be set to UE-RX.
[0467] As described above, the method disclosed in Modification 2 of Embodiment 4 may be applied as appropriate.
[0468] We will disclose other methods.
[0469] Multiple DST L2IDs may be provided. A DST L2ID may be set for the service receiving node, and a DST L2ID may be set for the receiving node in the SL communication for each link. For SL communication on each link, it is preferable to use the DST L2ID set for the receiving node in the SL communication for each link. The DST L2ID between UE-TX and relay UE should be set to relay UE. The DST L2ID between relay UE and UE-RX should be set to UE-RX.
[0470] As described above, the method disclosed in Modification 2 of Embodiment 4 may be applied as appropriate.
[0471] The SCI may include the DST L2ID set for the receiving node in the SL communication for each link, and the DST L2ID set for the receiving node of the service. The MAC header may also include the DST L2ID set for the receiving node in the SL communication for each link, and the DST L2ID set for the receiving node of the service.
[0472] Information may be provided indicating that multiple DST L2IDs are configured. Information may also be provided indicating the number of DST L2IDs to be configured. For example, the number of DST L2IDs may be set to two. For example, there may be two DST L2IDs: one for the service and one for SL communication for each link.
[0473] UE-TX may notify the relay UE of the information. The relay UE may notify the UE-RX of the information. For example, the information may be included in the SCI and notified. For example, different SCI formats may be provided depending on whether or not there are multiple pieces of the information. Different SCI identifiers may be provided depending on whether or not there are multiple pieces of the information. Different PSCCH formats may be provided depending on whether or not there are multiple pieces of the information. The information may be provided as a MAC header. The information may be provided as a MAC CE. Different MAC CEs may be used depending on whether or not there are multiple pieces of the information. Different MAC CE identifiers may be used depending on whether or not there are multiple pieces of the information. In this way, the receiving node can recognize that multiple DST L2IDs are set.
[0474] If a DST L2ID is set on the receiving node of the service and a DST L2ID is set on the receiving node in the SL communication of each link, a unique identifier may be assigned to the PFI between UE-TX and UE-RX. It is not necessary to set a PFI for each link. The DST L2ID set on the receiving node in the SL communication of each link does not depend on the PFI. The DST L2ID set on the receiving node in the SL communication of each link identifies the receiving node of the SL communication for each link.
[0475] This allows the relay UE to receive data from the UE-TX.
[0476] As mentioned above, in direct communication between UEs, the SRC L2ID and DST L2ID are partially included in the SCI and the remaining portion is included in the MAC header. The receiving UE can identify the source UE of the data mapped to the PSSCH corresponding to the SCI by receiving the portion of the SRC L2ID included in the SCI. Similarly, the receiving UE can identify the source UE of the MAC PDU by receiving the remaining portion of the SRC L2ID included in the MAC header.
[0477] In indirect communication between UEs using relay UEs, the transmitting and receiving nodes for SL communication on each link are different from the transmitting and receiving nodes for services. In such cases, it becomes unclear whether the SRC L2ID should be for the transmitting node of SL communication on each link or for the transmitting node of services. For example, in SL communication from a relay UE to a UE-RX, if the SRC L2ID is set to the relay UE, the UE-RX will not be able to determine that the data received from the relay UE is service data from the UE-TX. As a result, the UE-RX will not be able to receive service data from the UE-TX.
[0478] We will disclose methods for solving these problems.
[0479] The SRC L2ID for SL communication on each link should be set to the service transmitting node. The SRC L2ID between UE-TX and relay UE should be set to UE-TX. The SRC L2ID between relay UE and UE-RX should also be set to UE-TX. This allows UE-RX to identify service data from UE-TX.
[0480] We will disclose other methods.
[0481] Multiple SRC L2IDs may be provided. For example, an SRC L2ID set on the service's transmitting node and an SRC L2ID set on the transmitting node for SL communication on each link may be provided. For SL communication on each link, it is preferable to use the SRC L2ID set on the receiving node for SL communication on each link. The SRC L2ID between UE-TX and relay UE should be UE-TX. The SRC L2ID between relay UE and UE-RX should be relay UE.
[0482] The SCI may include the SRC L2ID set for the transmitting node in the SL communication of each link and the SRC L2ID set for the receiving node of the service. The MAC header may also include the SRC L2ID set for the receiving node in the SL communication of each link and the SRC L2ID set for the receiving node of the service. In this way, the UE-RX can identify the service data from the UE-TX.
[0483] Information may be provided indicating that multiple SRC L2IDs are configured. Information may also be provided indicating the number of SRC L2IDs to be configured. For example, the number of SRC L2IDs may be set to two. For example, there may be two SRC L2IDs: one for the service and one for SL communication for each link.
[0484] UE-TX may notify the relay UE of the information. The relay UE may notify the UE-RX of the information. For example, the information may be included in the SCI and notified. For example, different SCI formats may be provided depending on whether or not there are multiple pieces of the information. Different SCI identifiers may be provided depending on whether or not there are multiple pieces of the information. Different PSCCH formats may be provided depending on whether or not there are multiple pieces of the information. The information may be provided as a MAC header. The information may be provided as a MAC CE. Different MAC CEs may be used depending on whether or not there are multiple pieces of the information. Different MAC CE identifiers may be used depending on whether or not there are multiple pieces of the information. In this way, the receiving node can recognize that multiple SRC L2IDs are set.
[0485] If an SRC L2ID is set on the service's transmitting node and an SRC L2ID is set on the transmitting node in the SL communication for each link, a unique identifier may be assigned to the PFI between UE-TX and UE-RX. It is not necessary to set a PFI for each link. The SRC L2ID set on the transmitting node in the SL communication for each link does not interact with the PFI. The SRC L2ID set on the transmitting node in the SL communication for each link identifies the transmitting node of the SL communication for each link.
[0486] We will disclose other methods.
[0487] The SRC L2ID for SL communication on each link is set to the transmitting node in the SL communication on each link. The SRC L2ID for the service and the SRC L2ID for SL communication may be different. The SRC L2ID between UE-TX and relay UE is set to UE-TX. The SRC L2ID between relay UE and UE-RX may be set to relay UE. UE-RX may identify service data from UE-TX using methods other than the SRC L2ID. For example, UE-RX may identify service data from UE-TX using the PFI associated with the data transmitted from relay UE. The method for setting the PFI may be appropriately applied using the method disclosed in Modification 2 of Embodiment 4.
[0488] In this way, the UE-RX can receive service data from the UE-TX in the data it receives from the relay UE.
[0489] By using the method disclosed in Modification 3 of this Embodiment 4, communication is made possible even when the transmitting and receiving nodes for SL communication on each link and the transmitting and receiving nodes for V2X services are different, such as indirect UE communication between UEs using relay UEs. Moreover, malfunctions in processing at each node can be reduced, and the reliability of the communication can be improved.
[0490] In signaling control information in PC5, an identifier for the destination UE may be set. The method disclosed in Modification 2 of Embodiment 4 or Modification 3 of Embodiment 4 may be applied as appropriate. As a method for setting the destination UE identifier for the signaling that notifies the aforementioned SLRB-related information, the method disclosed in Modification 2 of Embodiment 4 or Modification 3 of Embodiment 4 may be applied as appropriate.
[0491] In the signaling of control information in PC5, the source UE identifier may be set. The method disclosed in Modification 3 of Embodiment 4 may be applied as appropriate. As a method for setting the source UE identifier for the signaling that notifies the aforementioned SLRB-related information, the method disclosed in Modification 3 of Embodiment 4 may be applied as appropriate.
[0492] By doing so, a similar effect can be obtained in the signaling of control information in PC5. Applying this to the signaling of control information makes it possible to further improve the reliability of indirect communication between UEs via relay UEs, for example.
[0493] Modification 4 of Embodiment 4. In direct communication between UEs, different DST L2IDs are not multiplexed into the same MAC PDU. Only data with the same DST L2ID is multiplexed into the MAC PDU.
[0494] In inter-UE indirect communication using relay UEs, SL communication takes place between UE-TX and the relay UE, and between the relay UE and UE-RX. In SL communication between UE-TX and the relay UE, if the DST L2ID is set to the relay UE, the service data between UE-TX and UE-RX, and the service data between UE-TX and the relay UE, may be multiplexed onto the same MAC PDU at UE-TX. This is because in both cases, the relay UE is set as the DST L2ID in the SL communication between UE-TX and the relay UE.
[0495] When different service data is multiplexed onto the same MAC PDU in this way, the problem arises as to how the relay UE distinguishes between each service data.
[0496] Modification 4 of this embodiment discloses a method for solving these problems.
[0497] Different LCIDs should be configured for different services. The UE-TX notifies the relay UE of the configured LCID. The UE-TX may also include the configured LCID in the SLRB-related information and notify the relay UE of that information.
[0498] In this way, even if the service data between UE-TX and UE-RX and the service data between UE-TX and relay UE are multiplexed onto the same MAC PDU in UE-TX, the relay UE can distinguish between services using the LCID set for each service. If the relay UE receives data that has the LCID of the service between UE-TX and UE-RX set, it transmits that data to UE-RX.
[0499] We will disclose other methods.
[0500] Different RLC channels may be configured for different services. An RLC channel identifier may be provided to identify the RLC channel. Different RLC bearers may also be configured for different services. An RLC bearer identifier may be provided to identify the RLC bearer. The RLC channel identifier may be included in the RLC PDU header. The RLC bearer identifier may be included in the RLC PDU header.
[0501] In this way, the relay UE can identify the service using the RLC channel identifier or RLC bearer identifier configured for each service. If the received data contains the RLC channel identifier or RLC bearer identifier of the service between the UE-TX and UE-RX, the relay UE transmits the data to the UE-RX.
[0502] We will disclose other methods.
[0503] It is prohibited to duplicate data from different services onto the same MAC PDU. Alternatively, it may be stated that it is not permitted to duplicate data from different services onto the same MAC PDU. Data from the same service is duplicated onto the same MAC PDU.
[0504] The relay UE can identify a service by receiving a MAC PDU for each service. As a method for identifying a service, methods disclosed in other embodiments of this disclosure may be applied as appropriate.
[0505] The different services may be services using direct inter-UE communication and services using indirect inter-UE communication. For example, when services using both indirect and direct inter-UE communication are performed between UE-TX and relay UE, or when services using both indirect and direct inter-UE communication are performed between relay UE and UE-RX, the methods described above may be applied as appropriate. Similar effects can be obtained.
[0506] By using the method disclosed in Modification 4 of Embodiment 4, the relay UE can distinguish between service data between UE-TX and UE-RX and service data between UE-TX and the relay UE. Therefore, the relay UE can relay data that needs to be sent to UE-RX to UE-RX. This reduces malfunctions in the relay UE's processing.
[0507] Modification 5 of Embodiment 4. In 3GPP, there is no discussion whatsoever regarding how data should be relayed by a relay UE in indirect UE-to-UE communication via a relay UE. For example, it is unclear how a relay UE should map data received from UE-TX to which SLRB. As a result, the relay UE cannot properly relay data, leading to the problem of indirect UE-to-UE communication being impossible via the relay UE.
[0508] Modification 5 of this embodiment 4 discloses a method for solving these problems.
[0509] This document discloses a case where the SLRB setting between the UE-TX and the relay UE is used between the relay UE and the UE-RX. In indirect UE-to-UE communication via relay, it is preferable to use an SDAP PDU with a PFI header. The relay UE relays data between the V2X layer and the SDAP. The relay UE may use the PFI set in the header of the SDAP PDU received from the UE-TX to map the data to the SLRB for transmission to the UE-RX. The methods for setting, mapping, and notifying the PFI may be the same as those disclosed in the embodiments and modifications described above.
[0510] In this way, the relay UE can relay the data properly.
[0511] An alternative method is disclosed for the case where an SLRB setting is used between the relay UE and UE-RX, and between the UE-TX and the relay UE. In inter-UE indirect communication, the relay UE relays data between the RLC and PDCP. The relay UE may relay data using an RLC bearer, or the relay UE may relay data using an RLC channel.
[0512] In indirect communication between UEs via relays, a new layer for relays may be provided between the RLC and PDCP of the relay UE. A new protocol stack may also be provided. This layer or protocol stack may have the function of routing data received from UE-TX to UE-RX. This layer or protocol stack may also have the function of mapping data received from UE-TX to RLC for transmission to UE-RX.
[0513] The same RLC channel identifier used between the relay UE and the UE-RX is used as the RLC channel identifier between the UE-TX and the relay UE. The relay UE may use the RLC channel identifier of the RLC channel received from the UE-TX to map the data to an RLC channel with the same identifier for transmission to the UE-RX. Alternatively, an RLC bearer may be used instead of an RLC channel. The relay UE may use the RLC bearer identifier of the RLC bearer received from the UE-TX to map the data to an RLC bearer with the same identifier for transmission to the UE-RX.
[0514] A leg may be used instead of an RLC bearer. An identifier may be provided to identify the leg. The relay UE may use the leg identifier of the leg received from the UE-TX to map the data to the leg with the same identifier for transmission to the UE-RX. Legs may be configured, for example, in a DC (Dual Connectivity). Each RLC bearer of multiple RLC bearers configured in the DC is configured as a leg. In SL communication, the RLC bearers configured on each link may be configured as legs.
[0515] The relay UE may use the SLRB settings received from the UE-TX for the RCL channel, RLC bearer, and leg between the relay UE and the UE-RX. SLRB-related information may also be used. SLRB settings related to the RCL channel and RLC bearer, as well as corresponding RLC channel identifiers and RLC bearer identifiers, may be included in the SLRB parameters related to the transmitter and receiver. For SLRB configuration methods, mapping methods, and notification methods, the methods disclosed in the embodiments and modifications described above may be applied.
[0516] In this way, the relay UE can relay the data properly.
[0517] This document discloses another method for a relay UE to relay data between an RLC and a PDCP in inter-UE indirect communication. The same LCID used between the UE-TX and the relay UE is used as the LCID between the relay UE and the UE-RX. The relay UE may use the LCID received from the UE-TX to map the data to an SLRB having the same LCID for transmission to the UE-RX.
[0518] The relay UE may use the SLRB setting received from the UE-TX as the LCID between the relay UE and the UE-RX. SLRB-related information may also be used. The LCID may be included in the SLRB parameters related to the transmitter and receiver. For the SLRB setting method, mapping method, and notification method, the methods disclosed in the above embodiments and modifications may be applied.
[0519] In this way, the relay UE can relay the data properly.
[0520] This document discloses the case where the UE-TX and relay UE configure the SLRB for each link. In indirect communication between UEs via relay, it is preferable to use an SDAP PDU with a PFI header. The relay UE relays data between the V2X layer and the SDAP. The relay UE uses the PFI set in the header of the SDAP PDU received from the UE-TX to map the PDU to the SLRB for transmission to the UE-RX. The relay UE maps the PFI data set by the UE-TX to the PFI data set by the relay UE. For the method of setting, mapping, and notifying the PFI, it is preferable to apply the methods disclosed in the embodiments and modifications described above.
[0521] In this way, the relay UE can relay the data properly.
[0522] An alternative method is disclosed for when the UE-TX and relay UE configure the SLRB for each link. In inter-UE indirect communication, the relay UE relays data between the RLC and PDCP. The relay UE may relay the data on the RLC bearer, or the relay UE may relay the data on the RLC channel.
[0523] In indirect communication between UEs via relays, a new layer for relays may be provided between the RLC and PDCP of the relay UE. A new protocol stack may also be provided. The method described above is recommended.
[0524] The RLC channel identifier between the relay UE and the UE-RX is set by the relay UE. The relay UE may use the RLC channel identifier of the RLC channel received from the UE-TX to map the data to the RLC channel having the RLC identifier set by the relay UE for transmission to the UE-RX. Alternatively, an RLC bearer may be used instead of an RLC channel. The relay UE may use the RLC bearer identifier of the RLC bearer received from the UE-TX to map the data to the RLC bearer having the identifier set by the relay UE for transmission to the UE-RX.
[0525] A leg may be used instead of an RLC bearer. An identifier may be provided to identify the leg. The relay UE may use the leg identifier of the leg received from the UE-TX to map the data to the leg with the same identifier for transmission to the UE-RX. In SL communication, the RLC bearer set up on each link may be set as a leg.
[0526] The relay UE may use the SLRB settings configured by the relay UE for the RCL channel and RLC bearer between the relay UE and the UE-RX. SLRB-related information may also be used. SLRB settings related to the RCL channel and RLC bearer, as well as corresponding RLC channel identifiers and RLC bearer identifiers, may be included in the SLRB parameters related to the transmitter and receiver. For SLRB configuration methods, mapping methods, and notification methods, the methods disclosed in the embodiments and modifications described above may be applied.
[0527] In this way, the relay UE can relay the data properly.
[0528] This document discloses another method for a relay UE to relay data between an RLC and a PDCP in inter-UE indirect communication. The LCID between the relay UE and the UE-RX is set by the relay UE. The relay UE may use the LCID received from the UE-TX to map the data to an SLRB having the LCID set by the relay UE for transmission to the UE-RX.
[0529] The relay UE may use the SLRB setting configured by the relay UE for the LCID between the relay UE and the UE-RX. SLRB-related information may also be used. The LCID may be included in the SLRB parameters related to the transmitter and receiver. For the SLRB setting method, mapping method, and notification method, the methods disclosed in the above embodiments and modifications may be applied.
[0530] In this way, the relay UE can relay the data properly.
[0531] When a relay UE relays data between an RLC and a PDCP, the relay UE may only configure the RLC bearer. When a relay UE relays data between an RLC and a PDCP, the relay UE may only be permitted to configure the RLC bearer. When a relay UE relays data between an RLC and a PDCP, the relay UE may not configure the PFI. When a relay UE relays data between an RLC and a PDCP, the relay UE may not configure the SDAP. When a relay UE relays data between an RLC and a PDCP, the relay UE may not configure the PDCP.
[0532] When data is relayed between the RLC and PDCP in a relay UE, the SLRB settings that the UE-TX notifies the relay UE of may only contain information about the RLC bearer, or they may only contain information about the settings of layers lower than the RLC.
[0533] When a relay UE relays data between the RLC and PDCP, the data does not pass through the SDAP and PDCP in the relay UE. Therefore, if the SDAP and PDCP settings are changed between the UE-TX and the relay UE, or between the relay UE and the UE-RX, the relay UE will be unable to establish the necessary mappings. As a result, the UE-RX will not be able to receive data from the UE-TX properly. By using the method described above, when the relay UE relays data between the RLC and PDCP, the relay UE does not need to establish the necessary mappings, and the UE-RX will be able to receive data from the UE-TX properly.
[0534] The data may include information indicating relaying. The data may also include information indicating whether or not relaying will be performed. The UE-TX includes relaying information in the data it sends to the relay UE and transmits it. If the relay UE receives data from the UE-TX that includes relaying information, it transmits that data to the UE-RX.
[0535] Information indicating a relay can be set, for example, as the header of the SDAP, the header of the PDCP, the header of the RLC, the header of the MAC, or included in the SCI. This relay information can be set separately from existing information. By setting it separately from existing information, malfunctions in relay processing can be reduced. In this way, the relay UE can determine whether or not to relay the data received from the UE-TX.
[0536] The settings for relay information may be combined with the methods described above as appropriate. The relay UE can clearly determine whether or not to perform a relay. This reduces malfunctions in relay processing.
[0537] By using the method disclosed in Modification 5 of Embodiment 4, the relay UE can map the data received from UE-TX to the SLRB for transmission to UE-RX. As a result, the relay UE can relay data that requires relaying to UE-TX. This reduces malfunctions in relay processing in the relay UE and improves the reliability of indirect communication between UEs via the relay UE. Furthermore, the relay UE can perform appropriate mapping between SLRBs, making it possible to satisfy the QoS requirements for service from UE-TX to UE-RX.
[0538] Modification 6 of Embodiment 4. Modification 6 of this embodiment 4 discloses another method for solving the problems described in Modification 5 of embodiment 4.
[0539] Information is provided to indicate whether or not to use the SLRB setting configured for SL communication between UE-TX and Relay UE as the SLRB setting for SL communication between Relay UE and UE-RX. This information can be represented by, for example, one bit (it can be reflected in one bit). For example, if the state of the bit is "1", the bit indicates that the SLRB setting configured for SL communication between UE-TX and Relay UE will be used as the SLRB setting for SL communication between Relay UE and UE-RX. For example, if the state of the bit is "0", the bit indicates that the SLRB setting configured for SL communication between UE-TX and Relay UE will not be used as the SLRB setting for SL communication between Relay UE and UE-RX. The information that indicates (reflects) whether or not to use the SLRB setting configured for SL communication between UE-TX and Relay UE as the SLRB setting for SL communication between Relay UE and UE-RX is sometimes referred to as reflection information.
[0540] The following are six specific examples of how to configure the reflected information.
[0541] (1) Set the reflection information in the SDAP PDU. For example, you can set the reflection information in the SDAP PDU header.
[0542] (2) Set the reflection information in the PDCP PDU. For example, you can set the reflection information in the header of the PDCP PDU.
[0543] (3) Set the reflection information in the RLC PDU. For example, you can set the reflection information in the header of the RLC PDU.
[0544] (4) Set the reflection information in the MAC PDU. For example, you can set the reflection information in the header of the MAC PDU.
[0545] (5) Include the reflection information in SCI.
[0546] (6) A combination of (1) through (5).
[0547] These configuration methods may be predetermined by static standards or other specifications. Alternatively, these configuration methods may be notified in advance from the CN node to the UE-TX. Alternatively, these configuration methods may be notified in advance from the RAN node to the UE-TX. Alternatively, these configuration methods may be pre-configured in the UE-TX.
[0548] When the reflection information is set to (1) the SDAP PDU or (2) the PDCP PDU, the relay UE can recognize the reflection information at the SDAP or PDCP layer. Therefore, this is suitable when relaying is performed at a layer higher than the SDAP layer. For example, it is suitable for L3 relays. When the reflection information is set to (3) the RLC PDU, (4) the MAC PDU or (5) the SCI layer, the relay UE can recognize the reflection information at the RLC, MAC, or PHY layer. Therefore, this is suitable when relaying is performed at a layer higher than the RLC layer. For example, it is suitable for L3 relays and L2 relays.
[0549] The UE-TX sets reflection information in the service data it transmits to the UE-RX via the relay UE. For example, if the SLRB setting for SL communication between the relay UE and the UE-RX is used, the UE-TX sets the reflection information to "1". If the SLRB setting for SL communication between the relay UE and the UE-RX is not used, the UE-TX sets the reflection information to "0".
[0550] If the reflection information is set to "0", for example, the relay UE may use the SLRB setting set by the relay UE as the setting for SLRB for SL communication between the relay UE and the UE-RX. For example, a method such as the one disclosed in Modification 1 of Embodiment 4 may be applied as appropriate.
[0551] The relay UE can configure the SLRB for SL communication between the relay UE and the UE-RX using the reflection information set in the service data received from the UE-TX. As mentioned above, if the reflection information is set to "1", the relay UE will configure the SLRB for SL communication between the relay UE and the UE-RX using the SLRB setting configured for SL communication between the UE-TX and the relay UE. The relay UE will then send the service data received from the UE-TX to the UE-RX using the SLRB configured for SL communication between the relay UE and the UE-RX.
[0552] This configuration enables indirect inter-UE communication between UE-TX and UE-RX via the relay UE. UE-TX can transmit generated service data to UE-RX via the relay UE. UE-RX can receive service data from UE-TX via the relay UE.
[0553] The UE-TX notifies the relay UE of the SLRB settings configured for SL communication between the UE-TX and the relay UE. The UE-TX notifies the relay UE of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. The UE-TX may also notify SLRB parameters related only to the receiver. In this way, the relay UE can configure the SLRB for SL communication with the UE-TX, and for SL communication between the relay UE and the UE-RX.
[0554] The relay UE may configure the SLRB for SL communication between the relay UE and the UE-RX after receiving the SLRB configuration between the UE-TX and the relay UE. Alternatively, the relay UE may configure the SLRB when it receives service data from the UE-TX and the reflection information associated with that data (in the example above, if "1" is set).
[0555] The relay UE notifies the UE-RX of the SLRB settings configured for SL communication between the UE-TX and the relay UE. The relay UE may also notify only the SLRB parameters related to the transmitter and receiver as the SLRB settings. In this way, the UE-RX can perform the SLRB settings for SL communication between the relay UE and the UE-RX.
[0556] The method disclosed in Modification 6 of Embodiment 4 may be applied to the method disclosed in Embodiment 4. Similar effects can be obtained.
[0557] As disclosed in Modification 6 of this Embodiment 4, the relay UE receives reflection information associated with the service data from the UE-TX, and then uses the SLRB settings between the UE-TX and the relay UE to transmit the service data from the UE-TX to the UE-RX. This makes it possible to satisfy the QoS required for the service in the SL communication between the relay UE and the UE-RX. Furthermore, by using reflection information, relay processing in the relay UE can be simplified, reducing malfunctions. This makes it possible to improve the reliability of indirect communication between UEs via the relay UE.
[0558] Another example of how to configure reflection information is disclosed. Reflection information may be included in the PC5 RRC message. The UE-TX notifies the relay UE of the reflection information using PC5 RRC signaling. The method described above should be applied to configure the reflection information. The reflection information may also be notified in association with information that identifies the service using SL communication for which the reflection information is configured. For example, the reflection information may be notified in association with SL communication SLRB configuration-related information, PFI, or QoS-related information. The relay UE can use the reflection information received from the UE-TX to configure the SLRB for SL communication between the relay UE and the UE-RX for the service. In this way, the amount of information notified to the relay UE can be reduced compared to the specific example described above.
[0559] The reflection information may be changed semi-statically. The UE-TX may change the reflection information semi-statically to the relay UE. The UE-TX can notify the relay UE of the change in SLRB settings by notifying it of the changed reflection information. When the relay UE receives the changed reflection information, it changes the SLRB setting method. In this way, the SLRB settings for each SL communication can be flexibly implemented.
[0560] For SL communication from UE-RX to UE-TX, the SLRB settings configured for SL communication from UE-TX to UE-RX may be used. For SL communication from UE-RX to relay UE, the SLRB settings configured for SL communication from relay UE to UE-RX may be used. For SL communication from relay UE to UE-TX, the SLRB settings configured for SL communication from UE-TX to relay UE may be used.
[0561] For SL communication from UE-RX to UE-TX, information may be provided indicating whether or not to use the SLRB settings configured for SL communication from UE-TX to UE-RX. For SL communication from UE-RX to relay UE, information may be provided indicating whether or not to use the SLRB settings configured for SL communication from relay UE to UE-RX. For SL communication from relay UE to UE-TX, information may be provided indicating whether or not to use the SLRB settings configured for SL communication from UE-TX to relay UE.
[0562] The aforementioned reflection information may be applied as appropriate to this information. Reflection information may also be provided individually for each link.
[0563] You may combine the SLRB settings for each link with the reflection information.
[0564] For example, the UE-RX sets reflection information between the UE-TX and the relay UE in the service data it sends to the relay UE. If the reflection information between the UE-TX and the relay UE is set to "1", the relay UE uses the SLRB setting configured for SL communication from the UE-TX to the relay UE to configure the SLRB for SL communication from the relay UE to the UE-TX.
[0565] For example, the relay UE sets reflection information between the relay UE and the UE-RX in the service data it sends to the UE-RX. If the reflection information between the relay UE and the UE-RX is set to "1", the UE-RX uses the SLRB setting configured for SL communication from the relay UE to the UE-RX to configure SL communication from the UE-RX to the relay UE.
[0566] In this way, by combining the SLRB settings and reflection information for each link, SLRB can be configured flexibly. Even if SLRB settings are not made from UE-RX to relay UE, or from relay UE to UE-TX, SLRB settings can still be made for each link. The amount of signaling required for SLRB configuration can be reduced. In indirect communication between UEs via relay UE, relay processing in bidirectional communication can be simplified, reducing malfunctions. The reliability of indirect communication between UEs via relay UE can be improved.
[0567] The method described above can be applied not only to indirect communication between UEs but also to direct communication between UEs. Similar effects can be obtained in direct communication between UEs as well.
[0568] Modification 7 of Embodiment 4. As previously disclosed, it is not necessary to provide a PC5 policy to the relay UE. Modification 7 of this embodiment 4 discloses another method.
[0569] The relay UE is provided with a PC5 policy. For example, the CN or RAN provides the PC5 policy to the relay UE. For example, the PC5 policy may be pre-configured within the relay UE.
[0570] The QoS policy provided to the relay UE may be the QoS policy for services that the relay UE can perform relay processing for. A QoS policy may not be provided for services that the relay UE cannot perform relay processing for.
[0571] For example, in the registration process performed by a relay UE with respect to a CN, the CN may provide the relay UE with a QoS policy for services that can be relayed. For example, in the authentication process performed by a relay UE with respect to a CN, the CN may provide the relay UE with a QoS policy for services that can be relayed. The CN may notify the relay UE of the QoS policy via a RAN node.
[0572] The relay UE may configure the SLRB between the relay UE and the UE-RX using the PC5 policy provided to the relay UE and the PC5 QoS parameters notified by the UE-TX. The SLRB configuration may be performed to satisfy the PC5 QoS parameters.
[0573] UE-TX may notify the relay UE of information regarding the service to be performed with UE-RX. This information may include the service type, the service request, the identifier of the destination UE, and the identifier of the source UE. The relay UE uses the aforementioned QoS policy and the information regarding the service to derive one or more QoS parameters required for the service.
[0574] If a relay UE has a PC5 QoS flow for SL communication to the UE-RX that corresponds to the PC5 QoS parameter, it updates the PC5 QoS flow to suit the PC5 QoS parameter. If a relay UE does not have a PC5 QoS flow for SL communication to the UE-RX that corresponds to the PC5 QoS parameter, it creates a new PC5 QoS flow that suits the PC5 QoS parameter. A new PC5 QoS flow identifier (sometimes referred to as PFI) may be set to identify the PC5 QoS flow.
[0575] The relay UE derives PC5 QoS rules to map service data to a configured PC5 QoS flow. The PC5 QoS rules may include PC5 packet filters. The relay UE may store the PC5 QoS parameters for the UE-RX, the V2X service type, and the PC5 QoS rules.
[0576] The derivation of PC5 QoS parameters, configuration of PC5 QoS flows, configuration of PFIs, and derivation of PC5 QoS rules may be performed at the V2X layer of the relay UE.
[0577] The PC5 QoS flow is mapped to the SLRB used for SL communication. This mapping may be performed at the relay's SDAP layer. The SLRB configuration for SL communication between the relay UE and UE-RX is derived using PC5 QoS parameters derived using information about the service received by the relay UE from UE-TX. The SLRB configuration may be set to satisfy these PC5 QoS parameters.
[0578] The relay UE transmits the service data received from the UE-TX to the UE-RX using the SLRB configured between the relay UE and the UE-RX. The method for configuring the DST L2ID and PFI, and the method for relaying data at the relay UE, should be appropriately applied using the methods disclosed in the above embodiments and modifications.
[0579] Figures 27 to 29 are sequence diagrams showing an example of how to configure QoS and SLRB in indirect UE communication via relay UEs, according to Modification 7 of Embodiment 4. Figures 27 to 29 are connected at the boundary lines BL2728 and BL2829. Figures 27 to 29 show the case when a V2X service occurs at UE-TX. Service data is transmitted from UE-TX to UE-RX via relay UE. In Figures 27 to 29, steps common to Figure 25 are given the same step numbers, and common explanations are omitted.
[0580] In steps ST4301 to ST4307, a QoS policy provision process is performed between the relay UE and the CN. For example, a registration process may be used for the QoS policy provision process. In step ST4301, the relay UE notifies the RAN node (which may also be a gNB) of its V2X capability, indicating that it supports the relay function of the V2X service. In step ST4302, the RAN node notifies the AMF of the relay UE's V2X capability, along with the relay UE's identifier. The AMF can then recognize that the relay UE has V2X capability.
[0581] In step ST4303, AMF requests PCF to authenticate the relay UE. Along with the authentication request, AMF notifies PCF of the relay UE's request for a QoS policy. In step ST4304, PCF performs authentication on the relay and, if it determines that the relay has the functionality to relay V2X services, derives the services that the relay can relay and the corresponding QoS policies.
[0582] In step ST4305, the PCF notifies the AMF of the V2X communication-related information of the relay UE. The PCF may notify the AMF of the service-related information for the relay UE and the QoS policy for the service, which it has derived as V2X communication-related information. In step ST4306, the AMF notifies the RAN node connected to the relay UE of the V2X communication-related information of the relay UE. In step ST4307, the RAN node notifies the relay UE of the V2X communication-related information of the relay UE. In this way, the relay UE is able to receive the services it can relay and the QoS policy corresponding to those services.
[0583] In step ST4308, the UE-TX notifies the relay UE of the configured PFI and SLRB-related information, as well as information about the service. The UE-TX only needs to notify the SLRB parameters related to the transmitter and receiver as SLRB-related information. In step ST4105, the relay UE uses the SLRB-related information between the UE-TX and the relay UE, which it received from the UE-TX, to configure the SLRB for SL communication between the UE-TX and the relay UE.
[0584] In step ST4309, the relay UE derives QoS-related information using the service information received from the UE-TX, the relayable services received from the RAN node in step ST4307, and the corresponding QoS policies. In step ST4310, the relay UE configures the PFI using the QoS-related information. As mentioned above, for example, if there is no PC5 QoS flow suitable for the PC5 QoS parameters, the relay UE creates a new PC5 QoS flow and configures the PFI for that PC5 QoS flow.
[0585] In step ST4311, the relay UE configures the SLRB for SL communication between the relay UE and the UE-RX. This SLRB configuration should be derived using the QoS-related information derived by the relay UE. Figures 27 to 29 disclose the case where the relay UE is under the umbrella of the gNB (sometimes referred to as IC (In Coverage)). If the relay UE is outside the coverage of the gNB, the SLRB configuration should be derived using the QoS-related information derived by the relay UE from the PC5 QoS parameters and SLRB configuration information that have been set up in the relay UE beforehand. The relay UE uses the derived SLRB configuration for SL communication between the relay UE and the UE-RX.
[0586] In this way, the relay UE can be provided with a PC5 policy. Furthermore, the relay UE can use the PC5 policy to configure the SLRB for SL communication between the relay UE and the UE-RX.
[0587] By using the method disclosed in Modification 7 of this Embodiment 4, the SLRB between the relay UE and the UE-RX can be configured to satisfy the QoS required for the service. This makes it possible to satisfy the QoS required for the service using indirect UE communication via the relay UE.
[0588] Furthermore, since the relay UE can derive QoS-related information and configure SLRB between the relay UE and the UE-RX, settings can be adjusted according to the relay UE's load status, resource usage, and radio wave propagation conditions with the UE-RX. This makes it possible to improve the communication quality of SL communication from the relay UE to the UE-RX. Inter-UE indirect communication via the relay UE can be performed with high reliability.
[0589] Modification 8 of Embodiment 4. This document discloses a method for configuring the SLRB for each link in inter-UE indirect communication via a relay UE.
[0590] This document discloses how to configure the SLRB between a UE-TX and a relay UE. A UE-TX in the connected state (RRC_Connected state) that is within the coverage of a gNB notifies the gNB of QoS-related information required for the service between the UE-TX and the UE-RX. The UE-TX may also notify PC5 QoS parameters. The UE-TX may also notify PC5 QoS profiles. Along with the QoS-related information, the UE-TX notifies the configured PFI. The gNB uses the QoS-related information received from the UE-TX to configure the SLRB. The gNB notifies the UE-TX of the configured SLRB and the corresponding PFI. RRC signaling on the Uu may be used for these notifications.
[0591] The UE-TX should use the SLRB settings received from the gNB for the SLRB between the UE-TX and the relay UE. In this way, the UE-TX can implement SLRB settings suitable for the service between the UE-TX and the UE-RX.
[0592] We will disclose other methods.
[0593] The gNB broadcasts QoS-related information and the corresponding SLRB settings in its broadcast information. There may be more than one QoS-related information item, and there may also be more than one SLRB setting item. UE-TX units in an idle state (RRC_Idle state) or non-operational state (RRC_Inactive state) within the gNB's coverage receive the QoS-related information broadcast by the gNB and the corresponding SLRB settings. The UE-TX uses this received information to derive the SLRB settings between the UE-TX and the relay UE from the QoS-related information required for the service between the UE-TX and the UE-RX.
[0594] The UE-TX should use the SLRB settings received from the gNB for the SLRB between the UE-TX and the relay UE. In this way, the UE-TX can implement SLRB settings suitable for the service between the UE-TX and the UE-RX.
[0595] RAN nodes should have QoS-related information and corresponding SLRB configuration information in advance. This information may be provided, for example, from a CN node. For example, this information may be provided from a PCF via an AMF. Alternatively, this information may be provided from an OAM. For example, this information may be provided via an AMF.
[0596] We will disclose other methods.
[0597] Within the UE-TX, QoS-related information and the corresponding SLRB settings are pre-configured. There may be more than one QoS-related information item, and there may also be more than one SLRB setting item. UE-TX located outside the gNB's coverage uses this pre-configured information to derive the SLRB settings between the UE-TX and the relay UE from the QoS-related information required for the service between the UE-TX and the UE-RX.
[0598] QoS-related information pre-configured on the UE-TX, and SLRB configuration information corresponding to the QoS-related information, may be provided, for example, from the CN node. For example, this information may be provided during the authentication process when the UE-TX performs V2X services. This information may also be provided via the PCF, AMF, and RAN nodes.
[0599] The QoS-related information configured within the UE-TX, and the corresponding SLRB settings, may be updated with the QoS-related information received by the UE-TX from the gNB that most recently entered coverage, using the method described above, and the corresponding SLRB settings. This allows the QoS-related information and the corresponding SLRB settings to be updated to the new settings, enabling the SLRB to be configured based on more recent conditions.
[0600] Figures 30 and 31 are sequence diagrams showing a first example of how to configure QoS and SLRB in inter-UE indirect communication via a relay UE, for a modification 8 of Embodiment 4. Figures 30 and 31 are connected at the boundary line BL3031. Figures 30 and 31 show the case where a V2X service occurs at UE-TX. Service data is sent from UE-TX to UE-RX via the relay UE. Figures 30 and 31 disclose the case where UE-TX is connected to gNB. In Figures 30 and 31, steps common to Figure 25 are given the same step numbers, and common explanations are omitted.
[0601] In step ST4401, the UE-TX notifies the gNB of the QoS-related information derived from the service between the UE-TX and the UE-RX, and the configured PFI. In step ST4402, the gNB configures the SLRB using the QoS-related information received from the UE-TX. In step ST4403, the gNB notifies the UE-TX of the configured SLRB and the corresponding PFI. In step ST4103, the UE-TX uses the SLRB configuration received from the gNB for the SLRB between the UE-TX and the relay UE.
[0602] In this way, the UE-TX can configure the SLRB for SL communication between the UE-TX and the relay UE to be suitable for the service between the UE-TX and the UE-RX.
[0603] The method described above may also be applied to setting up an SLRB for SL communication between UE-TX and UE-RX, as disclosed in Modification 10 of Embodiment 4. Similar effects can be obtained.
[0604] This document discloses a method for configuring the SLRB between a relay UE and a UE-RX. A relay UE in a connected state (RRC_Connected state) within the coverage of a gNB notifies the gNB of QoS-related information. This QoS-related information may be derived by the relay UE, or it may be QoS-related information notified to the relay UE by the UE-TX. The relay UE may notify the PC5 QoS parameters derived by the relay UE, or the PC5 QoS parameters notified to the relay UE by the UE-TX. The relay UE may also notify the PC5 QoS profile derived by the relay UE, or the PC5 QoS profile notified to the relay UE by the UE-TX. Along with the QoS-related information, the relay UE notifies the configured PFI. The gNB uses the QoS-related information received from the relay UE to configure the SLRB. The gNB notifies the relay UE of the configured SLRB and the corresponding PFI. RRC signaling in the Uu may be used for these notifications.
[0605] The relay UE should use the SLRB settings received from the gNB for the SLRB between the relay UE and the UE-RX. In this way, the relay UE can implement SLRB settings suitable for the service between the UE-TX and the UE-RX.
[0606] We will disclose other methods.
[0607] The gNB broadcasts QoS-related information and the corresponding SLRB settings in its broadcast information. There may be more than one QoS-related information item, and there may also be more than one SLRB setting item. Relay UEs in an idle state (RRC_Idle state) or non-operating state (RRC_Inactive state) that are within the gNB's coverage receive the QoS-related information broadcast by the gNB and the corresponding SLRB settings. Using this received information, the relay UE derives the SLRB settings between the relay UE and the UE-RX from the QoS-related information derived by the relay UE, or from the QoS-related information notified to the relay UE by the UE-TX.
[0608] The relay UE should use the SLRB settings received from the gNB for the SLRB between the relay UE and the UE-RX. In this way, the relay UE can implement SLRB settings between the relay UE and the UE-RX that are suitable for service between the UE-TX and the UE-RX.
[0609] RAN nodes should have QoS-related information and corresponding SLRB configuration information in advance. This information may be provided, for example, from a CN node. For example, this information may be provided from a PCF via an AMF. Alternatively, this information may be provided from an OAM. For example, this information may be provided via an AMF.
[0610] We will disclose other methods.
[0611] Within the relay UE, QoS-related information and the corresponding SLRB settings are pre-configured. There may be more than one QoS-related information item, and there may also be more than one SLRB setting item. A relay UE located outside the gNB's coverage uses this pre-configured information to derive the SLRB settings between the relay UE and the UE-RX from the QoS-related information derived by the relay UE, or from the PC5 QoS-related information notified to the relay UE by the UE-TX.
[0612] QoS-related information pre-configured in the relay UE, and SLRB configuration information corresponding to the QoS-related information, may be provided, for example, from the CN node. For example, this information may be provided during the authentication process when the relay UE performs V2X services as a relay. This information may also be provided via the PCF, AMF, and RAN nodes.
[0613] The QoS-related information configured within the relay UE and the corresponding SLRB settings may be updated with the QoS-related information received by the relay UE from the gNB that most recently entered coverage, using the method described above, and the corresponding SLRB settings. This allows the QoS-related information and the corresponding SLRB settings to be updated to the new settings, enabling the SLRB to be configured based on more recent conditions.
[0614] Figures 32 and 33 are sequence diagrams showing a second example of how to configure QoS and SLRB in inter-UE indirect communication via a relay UE, for a modification 8 of Embodiment 4. Figures 32 and 33 are connected at the boundary line BL3233. Figures 32 and 33 show the case where a V2X service occurs at UE-TX. Service data is transmitted from UE-TX to UE-RX via the relay UE. Figures 32 and 33 disclose the case where UE-TX and relay UE are connected to gNBs. Figures 32 and 33 disclose the case where the gNB connected to UE-TX and the gNB connected to relay UE are different. In Figures 32 and 33, steps common to Figures 25, 30, and 31 are given the same step numbers, and common explanations are omitted.
[0615] In steps ST4401 to ST4403, the UE-TX performs the process of obtaining the SLRB settings between the UE-TX and the relay UE from the gNB1.
[0616] In step ST4501, the UE-TX notifies the relay UE of QoS-related information derived from the service between the UE-TX and the UE-RX, the configured PFI, and SLRB-related information.
[0617] In step ST4502, the relay UE notifies the gNB2 of the QoS-related information received from the UE-TX and the configured PFI. In step ST4503, the gNB configures the SLRB using the QoS-related information received from the relay UE. In step ST4504, the gNB notifies the relay UE of the configured SLRB and the corresponding PFI. In step ST4107, the relay UE uses the SLRB configuration received from the gNB for the SLRB between the relay UE and the UE-RX.
[0618] The method described above can also be applied when gNB1 connected to the UE-TX and gNB2 connected to the relay UE are the same. If gNB1 and gNB2 are the same, and the PFI and / or QoS-related information received from the UE-TX is the same as the PFI and / or QoS-related information received from the relay UE, the SLRB settings configured for the UE-TX and the SLRB settings configured for the relay UE may be the same.
[0619] In this way, the relay UE can configure the SLRB for SL communication between the relay UE and the UE-RX to be suitable for the service between the UE-TX and the UE-RX.
[0620] In the preceding section, a method was disclosed for a RAN node to configure the SLRB between the UE-TX and the relay UE, and between the relay UE and the UE-RX. For example, the UE-TX notifies the RAN node of QoS-related information, and the RAN node uses this QoS-related information to configure the SLRB between the UE-TX and the relay UE. For example, the relay UE notifies the RAN node of QoS-related information derived by its own UE, or QoS-related information received from the UE-TX, and the RAN node uses this QoS-related information to configure the SLRB between the relay UE and the UE-RX. The RAN node to which the UE-TX is connected and the RAN node to which the relay UE is connected may be the same or different.
[0621] When QoS-related information is notified between UE-TX and RAN nodes, between UE-TX and relay UEs, and between relay UEs and RAN nodes, the amount of information that needs to be notified between each node increases. This also increases the wireless resources required for communication between each node.
[0622] This document discloses methods for solving these problems.
[0623] The relay UE notifies the connected RAN node of the PFI but does not notify it of QoS-related information. The UE-TX notifies the relay UE of the configured PFI. The relay UE notifies the connected RAN node of the PFI received from the UE-TX.
[0624] A RAN node notifies surrounding RAN nodes of PFI and QoS-related information notified by its subordinate UE-TX. The RAN node may notify PFI and QoS-related information using an inter-base station interface, such as an Xn interface. Alternatively, the RAN node may notify PFI and QoS-related information using Xn signaling. Or, the RAN node may notify PFI and QoS-related information via AMF. In this way, the RAN node can recognize the PFI and QoS-related information set by the UE-TX under the surrounding RAN node.
[0625] The RAN node connected to the relay UE uses the PFI received from the relay UE and the PFI and QoS-related information received from surrounding RAN nodes to derive QoS-related information corresponding to the PFI received from the relay UE. The RAN node uses the derived QoS-related information to configure the SLRB. The RAN node notifies the relay UE of the configured SLRB configuration. The RAN node may also notify the PFI along with the SLRB configuration. In this way, the relay UE can receive the SLRB configuration corresponding to the PFI notified from the UE-TX.
[0626] The relay UE sets the SLRB received from the RAN node as the SLRB between the relay UE and the UE-RX. In this way, the relay UE can configure the SLRB setting between the relay UE and the UE-RX to meet the QoS requirements for the service between the UE-TX and the UE-RX.
[0627] The UE-TX may notify the RAN node of its own UE identifier along with the PFI, the UE-TX may notify the relay UE, the relay UE may notify the RAN node, and the RAN node may notify the surrounding RAN node. In addition to or instead of this, the DST L2ID and / or SRC L2ID corresponding to the PFI may be notified.
[0628] In this way, the RAN node to which the relay UE is connected can recognize the UE-TX or the DST L2ID and / or SRC L2ID to which the PFI corresponding to the PFI notified by the surrounding RAN node is set. When the RAN node to which the relay UE is connected uses the PFI received from the relay UE and the PFI and QoS-related information received from the surrounding RAN node to derive QoS-related information corresponding to the PFI received from the relay UE, using the aforementioned information, malfunctions can be reduced.
[0629] Figures 34 and 35 are sequence diagrams showing a third example of how to configure QoS and SLRB in inter-UE indirect communication via a relay UE, according to a modification 8 of Embodiment 4. Figures 34 and 35 are connected at the boundary line BL3435. Figures 34 and 35 show the case when a V2X service occurs at UE-TX. Service data is transmitted from UE-TX to UE-RX via the relay UE. Figures 34 and 35 disclose the case when UE-TX is connected to RAN node 1 and the relay UE is connected to RAN node 2. In Figures 34 and 35, steps common to Figures 25 and 30-33 are given the same step numbers, and common explanations are omitted.
[0630] In step ST4601, RAN node 1 notifies surrounding RAN nodes of the PFI and QoS-related information received from UE-TX. RAN node 2 is included as a surrounding RAN node. This allows RAN node 2 to obtain the PFI and QoS-related information set by the UE-TX under RAN node 1.
[0631] In step ST4602, the UE-TX notifies the relay UE of the configured PFI and SLRB-related information between the UE-TX and the relay UE. The SLRB-related information between the UE-TX and the relay UE may be SLRB parameters related to the transmitter and receiver.
[0632] In step ST4106, relay UE sets the PFI received from UE-TX to the PFI between relay UE and UE-RX.
[0633] In step ST4603, the relay UE notifies the connected RAN node 2 of the configured PFI. In step ST4604, RAN node 2 uses the PFI received from the relay UE and the PFI and QoS-related information configured by the UE-TX received from RAN node 1 to derive QoS-related information corresponding to the PFI received from the relay UE. RAN node 2 also uses the derived QoS-related information to configure the SLRB. In this way, RAN node 2 can configure the SLRB corresponding to the PFI notified by the relay UE. RAN node 2 can also configure the SLRB corresponding to the PFI even if it is notified of QoS-related information from the relay UE.
[0634] In step ST4605, RAN node 2 notifies relay UE of the PFI and the associated SLRB information corresponding to the PFI. The SLRB associated information may be all parameters of the SLRB configuration. In step ST4107, relay UE sets the SLRB associated information received from RAN node 2 in the SLRB between relay UE and UE-RX.
[0635] In this way, the relay UE can configure the SLRB for SL communication between the relay UE and the UE-RX to be suitable for the service between the UE-TX and the UE-RX. Furthermore, it eliminates the need to notify QoS-related information between the UE-TX and the RAN node, between the UE-TX and the relay UE, and between the relay UE and the RAN node. As a result, the amount of information notified between each node can be reduced, and the increase in wireless resources required for communication between each node can be avoided.
[0636] RAN node 1 may notify surrounding RAN nodes of the SLRB settings. For example, RAN node 1 notifies surrounding RAN nodes of the SLRB settings set in step ST4402. RAN node 1 may also notify surrounding RAN nodes of the SLRB settings set in step ST4402, along with PFI. In step ST4601, SLRB settings may be notified instead of QoS-related information. RAN node 2 is included as a surrounding RAN node. This allows RAN node 2 to obtain the SLRB settings for SL communication set by RAN node 1.
[0637] RAN node 2 may, in step ST4605, notify the relay UE of the SLRB settings received from RAN node 1. Doing so will achieve the same effect as described above. Furthermore, since RAN node 2 does not need to perform the process of setting the SLRB from QoS-related information, the processing load on RAN node 2 can be reduced. In addition, malfunctions on RAN node 2 can be reduced.
[0638] Modification 9 of Embodiment 4. When a UE performing direct inter-UE communication via SL moves, a handover (HO) of the gNB to which the UE is connected may occur. When a UE performs a handover, the method for configuring the SLRB for SL communication becomes an issue, but no disclosure of this method exists.
[0639] This document discloses methods for solving these problems.
[0640] This document discloses how to configure the SLRB when a UE-TX handover occurs from the HO source gNB (sometimes referred to as the Source gNB (S-gNB)) to the HO destination gNB (sometimes referred to as the Target gNB (T-gNB)) in direct UE-to-UE communication using SL.
[0641] SLRB configuration is performed between the UE-TX and the HO destination gNB after the UE-TX has handed over.
[0642] After the UE-TX connects to the HO destination gNB via HO processing, the UE-TX notifies the HO destination gNB of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication. This notification may also be performed via RRC signaling on the Uu. By receiving the QoS-related information from the connected UE-TX, the HO destination gNB can recognize the QoS-related information required for the service performed by the UE-TX. The HO destination gNB uses the QoS-related information to configure the SLRB. The HO destination gNB then notifies the UE-TX of information regarding the configured SLRB. This notification may also be performed via RRC signaling on the Uu.
[0643] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. The HO destination gNB may notify the UE-TX of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver. In this way, it becomes possible to configure the SLRB for SL communication between the UE-TX and UE-RX.
[0644] The UE-TX receives SLRB-related information for SL communication from the HO destination gNB. The UE-TX uses the SLRB-related information received from the HO destination gNB to configure the SLRB for SL communication. The UE-TX also notifies the UE-RX of the SLRB-related information. This notification may be performed by PC5's RRC signaling. The SLRB-related information notified from the UE-TX to the UE-RX may consist only of SLRB parameters related to the transmitter and receiver. The UE-RX uses the SLRB-related information received from the UE-TX to configure the SLRB for SL communication.
[0645] This allows UE-TX to perform services using SL communication with UE-RX after the handover.
[0646] Figures 36 and 37 are sequence diagrams showing a first example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, according to a modified example 9 of Embodiment 4. Figures 36 and 37 are connected at the boundary line BL3637. In Figures 36 and 37, steps common to Figures 30 and 31 are given the same step numbers, and common explanations are omitted.
[0647] The UE-TX is connected to the S-gNB and receives SLRB-related information from the S-gNB in step ST4403. In step ST4701, the UE-TX uses the SLRB-related information received from the S-gNB to configure the SLRB settings between the UE-TX and the UE-RX. In step ST4702, the UE-TX notifies the UE-RX of the configured PFI and SLRB-related information. The SLRB-related information may consist only of SLRB parameters relevant to the transmitter and receiver.
[0648] In step ST4703, the UE-RX uses the SLRB-related information received from the UE-TX to configure the SLRB between the UE-TX and the UE-RX. In step ST4704, the UE-RX notifies the UE-TX that the SLRB configuration between the UE-TX and the UE-RX is complete. This completion notification may include a PFI (Private Finance Initiative). This enables the communication of service data between the UE-TX and the UE-RX using SL communication. In step ST4706, the UE-TX sends service data to the UE-RX.
[0649] In step ST4706, the UE-TX performs a measurement. The measurement settings may be notified to the UE-TX in advance by the S-gNB. In step ST4707, the UE-TX reports the measurement results to the S-gNB. In step ST4708, the S-gNB uses the measurement results reported by the UE-TX to determine the HO to the T-gNB.
[0650] In step ST4709, S-gNB notifies T-gNB of an HO request. The notification of the HO request may include the identifier of the UE-TX performing the HO. In step ST4710, T-gNB determines whether to accept the UE-TX's HO. If T-gNB decides to accept the HO, in step ST4711, T-gNB notifies S-gNB of an HO request response. The notification of the HO request response may include the identifier of the UE-TX performing the HO.
[0651] In step ST4712, S-gNB notifies UE-TX of an HO instruction. The HO instruction may include the identifier of T-gNB. The HO instruction may also be notified using the RRCReconfiguration message. Upon receiving the HO instruction, UE-TX performs synchronization with T-gNB in step ST4713 and initiates access. It may also perform RACH processing and notify the RRCReconfigurationComplete message. In this way, UE-TX performs an HO from S-gNB to T-gNB.
[0652] In step ST4714, the UE-TX notifies the T-gNB of the QoS-related information derived in step ST4101. The UE-TX may also notify the PFI set in step ST4102 together with the QoS-related information, or include it in the QoS-related information. In step ST4715, the T-gNB configures the SLRB using the QoS-related information received from the UE-TX. In step ST4716, the T-gNB notifies the UE-TX of the configured PFI and SLRB-related information. As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. The HO destination gNB may notify the UE-TX of SLRB parameters related to both the sender and receiver, as well as SLRB parameters related only to the sender. It may also notify SLRB parameters related only to the receiver.
[0653] In step ST4717, the UE-TX uses the SLRB-related information received from the T-gNB to configure the SLRB settings between the UE-TX and the UE-RX. In step ST4718, the UE-TX notifies the UE-RX of the PFI and SLRB-related information. The SLRB-related information may consist only of SLRB parameters relevant to the transmitter and receiver.
[0654] In step ST4719, the UE-RX uses the SLRB-related information received from the UE-TX to configure the SLRB between the UE-TX and the UE-RX. In step ST4720, the UE-RX notifies the UE-TX that the SLRB configuration between the UE-TX and the UE-RX is complete. This completion notification may include a PFI (Private First Inspection). This enables the communication of service data between the UE-TX and the UE-RX using SL communication. In step ST4721, the UE-TX sends service data to the UE-RX.
[0655] This allows UE-TX to perform services using SL communication with UE-RX after a handover. For example, even if a HO occurs due to UE-TX movement or changes in the radio wave propagation environment, services using SL communication between UE-TX and UE-RX can be performed.
[0656] When performing indirect UE-to-UE communication via a relay UE using SL, not only the UE-TX and UE-RX move, but also the relay UE. Even if these UEs do not move, the surrounding radio wave propagation environment may change, potentially causing HOs in the gNB connected to the UE-TX or the gNB connected to the relay UE. These HOs do not necessarily occur simultaneously. Thus, when performing indirect UE-to-UE communication via a relay UE, the method for configuring the SLRB for SL communication when HOs occur in the UE-TX or relay UE becomes an issue. However, no disclosure has been made regarding this method.
[0657] This document discloses methods for solving these problems.
[0658] In inter-UE indirect communication via relay UEs in SL, the SLRB is configured between UE-TX and HO destination gNB after UE-TX has performed a handover, and the relay UE configures the SLRB for SL communication with UE-RX.
[0659] The HO source gNB connected to the UE-TX may be referred to as HO source gNB1 (S-gNB1), and the HO destination gNB may be referred to as HO destination gNB1 (T-gNB1). The HO source gNB connected to the relay UE may be referred to as HO source gNB2 (S-gNB2), and the HO destination gNB may be referred to as HO destination gNB2 (T-gNB2).
[0660] After the UE-TX connects to the HO destination gNB1 via HO processing, the UE-TX notifies the HO destination gNB1 of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication. This notification may also be performed via RRC signaling on the Uu. By receiving the QoS-related information from the connected UE-TX, the HO destination gNB1 can recognize the QoS-related information required for the service performed by the UE-TX. The HO destination gNB1 sets up the SLRB using the QoS-related information. The HO destination gNB1 notifies the UE-TX of the information regarding the set SLRB. This notification may also be performed via RRC signaling on the Uu.
[0661] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. HO destination gNB1 may notify UE-TX of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver.
[0662] The UE-TX receives SLRB-related information for SL communication from the HO destination gNB1. The UE-TX uses the SLRB-related information received from the HO destination gNB1 to configure the SLRB for SL communication with the relay UE. The UE-TX also notifies the relay UE of the SLRB-related information. This notification may also be performed by RRC signaling on the PC5. The SLRB-related information notified from the UE-TX to the relay UE includes some or all of the parameters required for SLRB configuration. Not only are SLRB parameters related to both the transmitter and receiver notified, but also SLRB parameters related only to the transmitter. SLRB parameters related only to the receiver may also be notified.
[0663] The relay UE uses the SLRB-related information received from the UE-TX to configure the SLRB for SL communication with the UE-TX. The relay UE also notifies the UE-RX of the SLRB-related information received from the UE-TX. This notification may be performed by RRC signaling on the PC5. The SLRB-related information notified from the relay UE to the UE-RX may consist only of SLRB parameters related to the transmitter and receiver. The UE-RX uses the SLRB-related information received from the relay UE to configure the SLRB for SL communication with the relay UE.
[0664] Even if a HO occurs in the gNB connected to the relay UE, the SLRB setting will not be changed due to that HO. The relay UE can avoid the effects of the relay UE's HO processing by using the SLRB setting notified by the UE-TX for the SLRB between it and the UE-RX.
[0665] This method allows for SLRB configuration for SL communication between UE-TX and relay UE, and between relay UE and UE-RX, even when HO occurs in the gNB connected to UE-TX or the gNB connected to relay UE. This enables the execution of services using SL communication between UE-TX and UE-RX via relay UE. The method disclosed here may be combined with the method disclosed in Embodiment 4. This simplifies processing in relay UE. It reduces malfunctions in inter-UE indirect communication via relay UE using SL communication and improves reliability.
[0666] This document discloses alternative methods for configuring SLRB when an HO occurs in UE-TX or relay UE.
[0667] In inter-UE indirect communication via relay UEs in SL, the SLRB configuration between UE-TX and relay UE is performed between UE-TX and HO destination gNB after UE-TX has performed a handover, and the SLRB configuration between relay UE and UE-RX is performed between relay UE and HO destination gNB after relay UE has performed a handover.
[0668] After the UE-TX connects to the HO destination gNB1 via HO processing, the UE-TX notifies the HO destination gNB1 of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication. This notification may also be performed via RRC signaling on the Uu. By receiving the QoS-related information from the connected UE-TX, the HO destination gNB1 can recognize the QoS-related information required for the service performed by the UE-TX. The HO destination gNB1 sets up the SLRB using the QoS-related information. The HO destination gNB1 notifies the UE-TX of the information regarding the set SLRB. This notification may also be performed via RRC signaling on the Uu.
[0669] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. HO destination gNB1 may notify UE-TX of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver.
[0670] The UE-TX receives SLRB-related information for SL communication from the HO destination gNB1. The UE-TX uses the SLRB-related information received from the HO destination gNB1 to configure the SLRB for SL communication with the relay UE. The UE-TX also notifies the relay UE of the SLRB-related information. This notification may be performed by RRC signaling on the PC5. The SLRB-related information notified from the UE-TX to the relay UE may consist only of SLRB parameters related to the transmitting and receiving sides. The relay UE uses the SLRB-related information received from the UE-TX to configure the SLRB for SL communication with the UE-TX.
[0671] The UE-TX notifies the relay UE of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication. This notification may also be performed by the RRC signaling of PC5.
[0672] After the relay UE connects to the HO destination gNB2 via HO processing, the relay UE notifies the HO destination gNB2 of the QoS-related information received from the UE-TX. This notification may also be performed via RRC signaling on the Uu. By receiving the QoS-related information from the connected relay UE, the HO destination gNB2 can recognize the QoS-related information required for the service performed by the UE-TX. The HO destination gNB2 uses the QoS-related information to configure the SLRB. The HO destination gNB2 then notifies the relay UE of the information regarding the configured SLRB. This notification may also be performed via RRC signaling on the Uu.
[0673] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. The HO destination gNB2 may notify the relay UE of not only the SLRB parameters related to both the transmitter and receiver, but also the SLRB parameters related only to the transmitter. It may also notify the SLRB parameters related only to the receiver.
[0674] The relay UE notifies the UE-RX of SLRB-related information received from the HO destination gNB2. This notification may also be performed by RRC signaling on the PC5. The SLRB-related information notified from the relay UE to the UE-RX may consist only of SLRB parameters related to the transmitter and receiver. The UE-RX uses the SLRB-related information received from the relay UE to configure the SLRB for SL communication with the relay UE.
[0675] If a High Occurrence (HO) occurs on the UE-TX and / or relay UE, the destination of the HO may not need to notify the relay UE of QoS-related information from the UE-TX. QoS-related information is derived from services performed between the UE-TX and UE-RX using SL communication. The UE-TX only needs to notify the relay UE of QoS-related information when performing indirect UE-to-UE communication via relay with the UE-RX. By not requiring the destination of the HO to notify the relay UE of QoS-related information when a High Occurrence (HO) occurs on the UE-TX and / or relay UE, the amount of signaling can be reduced.
[0676] The UE-TX's HO does not have to occur before the relay UE's HO. The timing of the UE-TX's HO and the relay UE's HO are not limited. As long as QoS-related information has been notified from the UE-TX to the relay UE, the aforementioned method can be implemented at any time.
[0677] If a change in service between UE-TX and UE-RX is made by HO, or if a change is made in QoS-related information derived from such service, the UE-TX may notify the relay UE of the QoS-related information. This notification may be made by RRC signaling. This notification may be made not only by HO, but also when a change is made in service between UE-TX and UE-RX, or when a change is made in QoS-related information derived from such service. This notification may also be made when QoS-related information is updated. This makes it possible to update QoS-related information, which can reduce problems such as service interruptions due to QoS not being met and SL communication being interrupted.
[0678] This method allows for the setting of SLRBs for SL communication between UE-TX and Relay UE, and between Relay UE and UE-RX, even when there are HOs in gNB1 connected to UE-TX or gNB2 connected to Relay UE. This enables the execution of services using SL communication between UE-TX and UE-RX via Relay UE. The method disclosed here may be combined with the method disclosed in Modification 1 of Embodiment 4. Relay UE can set the SLRB set by HO destination gNB2 as the SLRB between Relay UE and UE-RX.
[0679] With the method described above, the SLRB settings are processed after the HO of the UE-TX or relay UE, resulting in a large delay.
[0680] This section discloses alternative methods for solving these problems.
[0681] This document discloses a method for configuring the SLRB when a UE-TX performs a handover from the HO source gNB to the HO destination gNB in direct UE-to-UE communication using SL.
[0682] The HO source gNB connected to the UE-TX notifies the surrounding gNBs in advance of QoS-related information derived from services performed between the UE-TX and UE-RX using SL communication. In this way, the surrounding gNBs can obtain the QoS-related information derived by the UE-TX.
[0683] The HO source gNB connected to the UE-TX may pre-notify the surrounding gNBs of SLRB-related information derived from QoS-related information. This SLRB-related information may include some or all of the parameters required for SLRB configuration. The HO source gNB may notify the surrounding gNBs of not only SLRB parameters related to both the transmitter and receiver, but also SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver. In this way, the surrounding gNBs can obtain the SLRB settings for SL communication between the UE-TX and the UE-RX.
[0684] The method for notifying QoS-related information from the HO source gNB to the surrounding gNB may be appropriately applied to the method disclosed in Modification 8 of Embodiment 4. The method for notifying SLRB-related information from the HO source gNB to the surrounding gNB may be appropriately applied to the method disclosed in Modification 8 of Embodiment 4.
[0685] Figures 38 and 39 are sequence diagrams showing a second example of how to set up the SLRB when an HO occurs at a UE in direct UE-to-UE communication using SL, for a modified example 9 of Embodiment 4. Figures 38 and 39 are connected at the boundary line BL3839. In Figures 38 and 39, steps common to Figures 36 and 37 are given the same step numbers, and common explanations are omitted.
[0686] In step ST4401, the UE-TX notifies the connected gNB (HO source gNB) of QoS-related information derived from a service performed between the UE-TX and UE-RX using SL communication. Information to identify the service from which the QoS-related information was derived may also be notified. This information may be, for example, the identifier of the UE-TX, the identifier of the destination UE of the service, the identifier of the source UE of the service, or the PFI set on the UE-TX. A combination of this information may also be used. This notification may be performed via RRC signaling on the Uu.
[0687] The HO source gNB connected to the UE-TX may store the QoS-related information received from the UE-TX in association with the information that identifies the service.
[0688] In step ST4801, the HO source gNB connected to the UE-TX notifies the surrounding gNBs in advance of the QoS-related information and service identification information received from the UE-TX. This notification may be made on Xn or X2. The surrounding gNBs that receive this information from the HO source gNB may store the received QoS-related information and service identification information in association with each other.
[0689] In step ST4713, after the UE-TX has connected with the HO destination gNB via HO processing, in step ST4715, the HO destination gNB configures the SLRB using the QoS-related information and service-identifying information received from the HO source gNB in step ST4801. In step ST4716, the HO destination gNB notifies the UE-TX of the configured SLRB information. This notification may be made via RRC signaling on the Uu.
[0690] Before the UE-TX connects to the HO destination gNB via HO processing, the surrounding gNB may configure the SLRB using the QoS-related information and service-identifying information received from the HO source gNB. This allows for earlier SLRB configuration.
[0691] After the UE-TX connects to the HO destination gNB via HO processing, in step ST4802, it may notify the HO destination gNB of information indicating a request for SLRB configuration. It may also notify information identifying the service. The information mentioned above may be applied as appropriate to identify the service. This notification may also be made via RRC signaling on the Uu. Upon receiving information indicating a request for SLRB configuration from the UE-TX, the HO destination gNB notifies the UE-TX of information regarding the SLRB configured for the service in step ST4716. This notification may also be made via RRC signaling on the Uu.
[0692] This configuration allows UE-TX to perform services using SL communication with UE-RX after a handover. Furthermore, since QoS-related information is communicated between gNBs in advance, UE-TX can receive SLRB settings from the HO-destined gNB early after a handover. Even if a HO occurs on UE-TX, services using SL at the HO-destined location can be performed with low latency.
[0693] As mentioned above, when performing indirect communication between UEs via a relay UE, the method for configuring the SLRB for SL communication when an HO occurs in UE-TX or relay UE becomes an issue. Here, we disclose an alternative method to solve this problem.
[0694] In inter-UE indirect communication via relay UEs in SL, the HO source gNB1 connected to the UE-TX notifies the surrounding gNBs in advance of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication.
[0695] As mentioned above, instead of QoS-related information, SLRB-related information derived from QoS-related information may be used.
[0696] The method for notifying QoS-related information from the HO source gNB1 to the surrounding gNBs may appropriately apply the method disclosed in Modification 8 of Embodiment 4. The method for notifying SLRB-related information from the HO source gNB to the surrounding gNBs may appropriately apply the method disclosed in Modification 8 of Embodiment 4.
[0697] The UE-TX notifies the connected gNB (HO source gNB1) of QoS-related information derived from services performed between the UE-TX and UE-RX using SL communication. Information to identify the service from which the QoS-related information was derived may also be notified. This information may be, for example, the identifier of the UE-TX, the identifier of the destination UE of the service, the identifier of the source UE of the service, or the PFI set on the UE-TX. A combination of this information may also be used. This notification may be performed via RRC signaling on the Uu.
[0698] The HO source gNB1 to which the UE-TX is connected may store the QoS-related information received from the UE-TX in association with the information that identifies the service.
[0699] The HO source gNB1 connected to the UE-TX notifies the surrounding gNBs in advance of the QoS-related information and service identification information received from the UE-TX. This notification may be made on Xn or X2. The surrounding gNBs that receive this information from the HO source gNB may store the received QoS-related information and service identification information in association with each other.
[0700] After the UE-TX connects to the HO destination gNB1 via HO processing, the HO destination gNB1 configures the SLRB using the QoS-related information and service-specific information received from the HO source gNB1. The HO destination gNB1 then notifies the UE-TX of the configured SLRB. This notification may be performed via RRC signaling on the Uu.
[0701] Before the UE-TX connects to the HO destination gNB1 via HO processing, the surrounding gNB may configure the SLRB using the QoS-related information and service-specific information received from the HO source gNB1. This allows for earlier SLRB configuration.
[0702] After UE-TX connects to the HO destination gNB1 via HO processing, it may notify the HO destination gNB1 of information indicating a request for SLRB configuration. It may also notify information that identifies the service. The information mentioned above may be applied as appropriate to identify the service. This notification may also be made via RRC signaling on Uu.
[0703] Upon receiving information from UE-TX indicating a request for SLRB configuration, HO destination gNB1 notifies UE-TX of the information regarding the SLRB configured for that service. This notification may also be made via RRC signaling on Uu.
[0704] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. HO destination gNB1 may notify UE-TX of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver.
[0705] The UE-TX receives SLRB-related information for SL communication from the HO destination gNB1. The UE-TX uses the SLRB-related information received from the HO destination gNB1 to configure the SLRB for SL communication with the relay UE. The UE-TX also notifies the relay UE of the SLRB-related information. This notification may also be performed by RRC signaling on the PC5. The SLRB-related information notified from the UE-TX to the relay UE includes all parameters for the SLRB configuration. Not only are SLRB parameters related to both the transmitter and receiver notified, but also SLRB parameters related only to the transmitter. SLRB parameters related only to the receiver may also be notified.
[0706] The relay UE uses the SLRB-related information received from the UE-TX to configure the SLRB for SL communication with the UE-TX.
[0707] The relay UE notifies the UE-RX of SLRB-related information received from the UE-TX. This notification may also be performed by RRC signaling on the PC5. The SLRB-related information notified from the relay UE to the UE-RX may consist only of SLRB parameters related to the transmitter and receiver. The UE-RX uses the SLRB-related information received from the relay UE to configure the SLRB for SL communication with the relay UE.
[0708] Even if a HO occurs in the gNB connected to the relay UE, the SLRB setting will not be changed due to that HO. The relay UE can avoid the effects of the relay UE's HO processing by using the SLRB setting notified by the UE-TX for the SLRB between it and the UE-RX.
[0709] This method allows for SLRB configuration for SL communication between UE-TX and the relay UE, and between the relay UE and the UE-RX, even when a HO occurs in the gNB connected to the UE-TX or the gNB connected to the relay UE. This enables the execution of services using SL communication between UE-TX and UE-RX via the relay UE. Furthermore, since QoS-related information is notified between gNBs in advance, SLRB configuration can be received early from the HO-destination gNB after the UE-TX has handed over. Even if a HO occurs in the UE-TX or relay UE, services using SL at the HO destination can be implemented with low latency.
[0710] The method disclosed herein may be combined with the method disclosed in Embodiment 4. This makes it possible to simplify processing in the relay UE. It is possible to reduce malfunctions in inter-UE indirect communication via the relay UE using SL communication and improve reliability.
[0711] This document discloses alternative methods for configuring SLRB when an HO occurs in UE-TX or relay UE.
[0712] In inter-UE indirect communication via relay UEs in SL, HO source gNB1, to which UE-TX is connected, notifies the surrounding gNBs in advance of QoS-related information derived from the services performed between UE-TX and UE-RX using SL communication. Similarly, HO source gNB2, to which relay UE is connected, notifies the surrounding gNBs in advance of QoS-related information derived from the services performed between UE-TX and UE-RX using SL communication, as notified by the relay UE. HO source gNB2, to which relay UE is connected, may also notify the surrounding gNBs in advance of QoS-related information derived from the services performed between UE-TX and UE-RX using SL communication, as notified by the surrounding gNBs.
[0713] As mentioned above, instead of QoS-related information, SLRB-related information derived from QoS-related information may be used.
[0714] The UE-TX notifies the connected gNB (HO source gNB1) of QoS-related information derived from services performed between the UE-TX and UE-RX using SL communication. Information to identify the service from which the QoS-related information was derived may also be notified. This information may be, for example, the identifier of the UE-TX, the identifier of the destination UE of the service, the identifier of the source UE of the service, or the PFI set on the UE-TX. A combination of this information may also be used. This notification may be performed via RRC signaling on the Uu.
[0715] The HO source gNB1 to which the UE-TX is connected may store the QoS-related information received from the UE-TX in association with the information that identifies the service.
[0716] The HO source gNB1 connected to the UE-TX notifies the surrounding gNBs in advance of the QoS-related information and service identification information received from the UE-TX. This notification may be made on Xn or X2. The surrounding gNBs that receive this information from the HO source gNB1 may store the received QoS-related information and service identification information in association with each other.
[0717] After the UE-TX connects to the HO destination gNB1 via HO processing, the HO destination gNB1 configures the SLRB using the QoS-related information and service-specific information received from the HO source gNB1. The HO destination gNB1 then notifies the UE-TX of the configured SLRB. This notification may be performed via RRC signaling on the Uu.
[0718] Before the UE-TX connects to the HO destination gNB1 via HO processing, the surrounding gNB may configure the SLRB using the QoS-related information and service-identifying information received from the HO source gNB1. This allows for earlier SLRB configuration.
[0719] After UE-TX connects to the HO destination gNB1 via HO processing, it may notify the HO destination gNB1 of information indicating a request for SLRB configuration. It may also notify information that identifies the service. The information mentioned above may be applied as appropriate to identify the service. This notification may also be made via RRC signaling on Uu.
[0720] Upon receiving information from UE-TX indicating a request for SLRB configuration, HO destination gNB1 notifies UE-TX of the information regarding the SLRB configured for that service. This notification may also be made via RRC signaling on Uu.
[0721] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. HO destination gNB1 may notify UE-TX of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver.
[0722] The UE-TX receives SLRB-related information for SL communication from the HO destination gNB1. The UE-TX uses the SLRB-related information received from the HO destination gNB1 to configure the SLRB for SL communication with the relay UE. The UE-TX also notifies the relay UE of the SLRB-related information. This notification may be performed by RRC signaling on the PC5. The SLRB-related information notified from the UE-TX to the relay UE may consist only of SLRB parameters related to the transmitter and receiver.
[0723] The UE-TX notifies the relay UE of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication. This notification may also be performed by the RRC signaling of PC5.
[0724] The relay UE notifies the connected gNB (HO source gNB2) of the QoS-related information received from the UE-TX. Information to identify the service from which the QoS-related information was derived may also be notified. This information may be, for example, the identifier of the relay UE, the identifier of the UE-TX, the identifier of the destination UE of the service, the identifier of the source UE of the service, the PFI set on the UE-TX, or the PFI set on the relay UE. A combination of this information may also be used. This notification may be performed via RRC signaling on the Uu.
[0725] The HO source gNB2 to which the relay UE is connected may store the QoS-related information received from the relay UE in association with the information that identifies the service.
[0726] The HO source gNB2 connected to the relay UE notifies the surrounding gNBs in advance of the QoS-related information and service identification information received from the relay UE. This notification may be made on Xn or X2. The surrounding gNBs that receive this information from the HO source gNB2 may store the received QoS-related information and service identification information in association with each other.
[0727] After the relay UE connects with the HO destination gNB2 via HO processing, the HO destination gNB2 configures the SLRB using the QoS-related information and service-specific information received from the HO source gNB2. The HO destination gNB2 then notifies the relay UE of the configured SLRB information. This notification may be performed via RRC signaling on the Uu.
[0728] Before the relay UE connects to the HO destination gNB2 via HO processing, the surrounding gNB may configure the SLRB using the QoS-related information and service-identifying information received from the HO source gNB2. This allows for earlier configuration of the SLRB.
[0729] After the relay UE connects to the HO destination gNB2 via HO processing, it may notify the HO destination gNB2 of information indicating a request for SLRB configuration. It may also notify information that identifies the service. The information mentioned above may be used as appropriate to identify the service. This notification may also be made via RRC signaling on the Uu.
[0730] Upon receiving information from the relay UE indicating a request for SLRB configuration, the HO destination gNB2 notifies the relay UE of the information regarding the SLRB configured for that service. This notification may also be made via RRC signaling on the Uu.
[0731] As SLRB-related information, some or all of the parameters required for SLRB configuration are notified. The HO destination gNB2 may notify the UE-TX of SLRB parameters related to both the transmitter and receiver, as well as SLRB parameters related only to the transmitter. It may also notify SLRB parameters related only to the receiver.
[0732] The relay UE receives SLRB-related information for SL communication from the HO destination gNB2. The relay UE uses the SLRB-related information received from the HO destination gNB2 to configure the SLRB for SL communication between the relay UE and the UE-RX. The relay UE also notifies the UE-RX of the SLRB-related information. This notification may be performed by RRC signaling on the PC5. The SLRB-related information notified from the relay UE to the UE-RX may consist only of SLRB parameters related to the transmitting and receiving sides. The UE-RX uses the SLRB-related information received from the relay UE to configure the SLRB for SL communication with the relay UE.
[0733] If a High Occurrence (HO) occurs on the UE-TX and / or relay UE, the destination of the HO may not need to notify the relay UE of QoS-related information from the UE-TX. QoS-related information is derived from services performed between the UE-TX and UE-RX using SL communication. The UE-TX only needs to notify the relay UE of QoS-related information when performing indirect UE-to-UE communication via relay with the UE-RX. By not requiring the destination of the HO to notify the relay UE of QoS-related information when a High Occurrence (HO) occurs on the UE-TX and / or relay UE, the amount of signaling can be reduced.
[0734] The UE-TX's HO does not have to occur before the relay UE's HO. The timing of the UE-TX's HO and the relay UE's HO are not limited. As long as QoS-related information has been notified from the UE-TX to the relay UE, the aforementioned method can be implemented at any time.
[0735] If a change in service between UE-TX and UE-RX is made by HO, or if a change is made in QoS-related information derived from such service, the UE-TX may notify the relay UE of the QoS-related information. This notification may be made by RRC signaling. This notification may be made not only by HO, but also when a change is made in service between UE-TX and UE-RX, or when a change is made in QoS-related information derived from such service. This notification may also be made when QoS-related information is updated. This makes it possible to update QoS-related information, which can reduce problems such as service interruptions due to QoS not being met and SL communication being interrupted.
[0736] This method allows for SLRB configuration for SL communication between UE-TX and the relay UE, and between the relay UE and the UE-RX, even when a HO occurs in the gNB connected to the UE-TX or the gNB connected to the relay UE. This enables the execution of services using SL communication between UE-TX and UE-RX via the relay UE. Furthermore, since QoS-related information is notified between gNBs in advance, SLRB configuration can be received early from the HO-destined gNB after the UE-TX and / or relay UE have performed a handover. Even if a HO occurs in the UE-TX or relay UE, services using SL at the HO destination can be implemented with low latency.
[0737] The method disclosed herein may be combined with the method disclosed in Modification 1 of Embodiment 4. Relay UE can set the SLRB set by HO destination gNB to the SLRB between relay UE and UE-RX.
[0738] This document discloses a method that enables even lower latency service using SL at the destination of a UE when a HO occurs in a UE performing direct or indirect UE-to-UE communication.
[0739] This document discloses a method for configuring the SLRB when a UE-TX performs a handover from the HO source gNB to the HO destination gNB in direct UE-to-UE communication using SL.
[0740] The HO source gNB connected to the UE-TX notifies the HO destination gNB of QoS-related information derived from the service performed between the UE-TX and UE-RX using SL communication, during the UE-TX's HO processing. In this way, the HO destination gNB can obtain the QoS-related information derived by the UE-TX.
[0741] The HO source gNB connected to the UE-TX may notify the HO destination gNB of SLRB-related information derived from QoS-related information during the UE-TX's HO processing (or even during HO preparation processing). As SLRB-related information, all parameters of the SLRB settings are notified. The HO source gNB notifies the HO destination gNB not only of SLRB parameters related to both the sender an...
Claims
1. A communication terminal device in a communication system, The communication system comprises a communication terminal device and a base station device that performs wireless communication with the communication terminal device. The communication terminal device is configured to receive a System Information Block (SIB) from the base station device, which contains first information relating to a RAN (Radio Access Network) slice. The first information includes a second piece of information that associates a cell with a plurality of slices supported in that cell, The communication terminal device is configured to reselect a cell using the second information, The communication terminal device is configured to transmit a random access preamble having information indicating a desired number of slices to the re-selected cell. Communication terminal device.
2. The second piece of information is information that associates a PCI (Physical Cell Identifier) for identifying the cell with identification information for identifying the plurality of slices. The communication terminal device according to claim 1.
3. The aforementioned communication system further includes an AMF (Access and Mobility Management Function) node, which is a core network node. The communication terminal device is configured to transmit a registration request containing information about the desired slice to the AMF node. The communication terminal device according to claim 1.
4. A base station device in a communication system, The communication system comprises a communication terminal device and a base station device that performs wireless communication with the communication terminal device. The base station device is configured to transmit a System Information Block (SIB) containing first information relating to a RAN (Radio Access Network) slice to the communication terminal device. The first information includes a second piece of information that associates a cell with a plurality of slices supported in that cell, The base station device is configured to receive a random access preamble from the communication terminal device, which has information indicating a plurality of slices desired by the communication terminal device. Base station equipment.
5. A communication system comprising a communication terminal device and a base station device that performs wireless communication with the communication terminal device, The communication terminal device is configured to receive a System Information Block (SIB) from the base station device, which contains first information relating to a RAN (Radio Access Network) slice. The first information includes a second piece of information that associates a cell with a plurality of slices supported in that cell, The communication terminal device is configured to reselect a cell using the second information, The communication terminal device is configured to transmit a random access preamble having information indicating a desired number of slices to the re-selected cell. Communication system.