Apparatus, system, method, and computer readable medium for connection-operated vehicle-to-x (VTX) communication in 5g

Abstract

The present disclosure relates to an apparatus, a system, a method, and a computer-readable medium for connection-oriented vehicle-to-X (VTX) communication in 5G. A first apparatus includes: a processor; a memory; and a communication circuit. The first device is connected to a communication network via the communication circuitry. The first device further includes computer executable instructions stored in the memory that, when executed by the processor, cause the first device to: discover a second device with which the first device is capable of communicating; obtaining equipment information related to the second device; and configuring a radio protocol of the first device for direct sidelink communication with the second device.

Description

[0001] This application is a divisional application of the invention patent application with the application date of February 13, 2020, application number 202080014447.8, and invention name “Device, system, method and computer-readable medium for connection-oriented vehicle-to-X (VTX) communication in 5G”.

[0002] Citation of Related Applications

[0003] This application claims priority to U.S. Provisional Application No. 62 / 805,121, filed February 13, 2019, and U.S. Provisional Application No. 62 / 841,579, filed May 1, 2019, the entire contents of which are incorporated herein by reference in their entirety. Technical Field

[0004] The present disclosure relates generally to wireless communications and, more particularly, to wireless communication systems, devices, methods, and computer-readable media for vehicle-to-vehicle communications. Background Art

[0005] The "background" description provided herein is intended to generally present the context of the present disclosure. To the extent described in this background section, the work of the presently named inventors, as well as aspects of the description that may not constitute prior art at the time of filing this application, are not admitted, either explicitly or implicitly, to be prior art against the present invention.

[0006] Existing vehicle-to-vehicle (V2X) systems and methods are connectionless and do not support the higher data rates, higher reliability, and lower latency required in 5G systems. Furthermore, connectionless transmission in existing systems leads to several disadvantages, such as high protocol overhead, high processing overhead, and difficulty in implementing physical layer feedback. Summary of the Invention

[0007] An example embodiment of the present disclosure provides a first device, comprising: a processor; a memory; and communication circuitry. The first device is connected to a communication network via the communication circuitry. The first device further comprises computer-executable instructions stored in the memory that, when executed by the processor, cause the first device to: discover a second device with which the first device can communicate; obtain device information associated with the second device; and configure a radio protocol of the first device for direct sidelink communication with the second device.

[0008] Example embodiments of the present disclosure provide a method for direct sidelink communication using a first device, the first device comprising a processor, a memory, and a communication circuit, and the first device being connected to a communication network via the communication circuit. The method includes: discovering a second device with which the first device can communicate; obtaining device information associated with the second device; and configuring a radio protocol of the first device for direct sidelink communication with the second device.

[0009] Example embodiments of the present disclosure provide a non-transitory computer-readable storage medium having computer-readable instructions tangibly recorded thereon, which, when executed by a processing circuit, cause the processing circuit to perform a method for direct sidelink communication using a first device. The method includes: discovering a second device with which the first device can communicate; obtaining device information associated with the second device; and configuring a radio protocol of the first device for direct sidelink communication with the second device.

[0010] This Summary is provided to introduce in simplified form some of the concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages mentioned in any section of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The scope of the present disclosure may be better understood from the following detailed description of example embodiments when read in conjunction with the accompanying drawings, in which:

[0012] Figure 1A is a system diagram representing an example 3GPP architecture;

[0013] Figure 1B is a system diagram of an example apparatus or device configured for wireless communication;

[0014] Figure 1C is a system diagram showing examples of a radio access network (RAN) architecture and a core network architecture;

[0015] Figure 1D is a system diagram showing examples of a radio access network (RAN) architecture and a core network architecture;

[0016] Figure 1E is a system diagram showing examples of a radio access network (RAN) architecture and a core network architecture;

[0017] Figure 1Fis a system diagram showing an example of a computing system for use in a communications network;

[0018] Figure 1G is a system diagram representing an example 3GPP architecture;

[0019] Figure 2 represents a control plane protocol stack for one-to-one sidelink communications according to an example embodiment;

[0020] Figure 3 shows the establishment of a secure layer 2 link through PC 5 according to an example embodiment;

[0021] Figure 4 represents a user plane protocol stack for sidelink communications according to an example embodiment;

[0022] Figure 5 presents a summary of 5G V2X requirements versus LTE V2V R14 requirements according to example embodiments;

[0023] Figure 6 represents an SDAP sublayer structure for V2X sidelink communications according to an example embodiment;

[0024] Figure 7 represents an L2 structure for V2X sidelink communication according to an example embodiment;

[0025] Figure 8 represents an L2 structure for V2X sidelink communication according to an example embodiment;

[0026] Figure 9 represents an L2 structure for V2X sidelink communication according to an example embodiment;

[0027] Figure 10 represents a functional view of the SDAP layer for V2X sidelink communication according to an example embodiment;

[0028] Figure 11 represents a UL or DL ​​sidelink SDAP data PDU format with an SDAP header according to an example embodiment;

[0029] Figure 12 1. A method for transmit-side V2X communication according to an example embodiment is shown;

[0030] Figure 13 1. A method for receiving-side V2X communication according to an example embodiment is shown;

[0031] Figure 14 shows a transmit-side unicast method for layer 2 link management according to an example embodiment;

[0032] Figure 15 shows a receive-side unicast method for layer 2 link management according to an example embodiment;

[0033] Figures 16A-16C Represents a unicast connection establishment method according to an example embodiment in which an initiating UE (initiating UE) RRC configures a target UE, or assists in the configuration of a target UE;

[0034] Figures 17A-17C represents a unicast connection establishment method according to an example embodiment in which an initiating UE PC5 configures a target UE, or assists in the configuration of a target UE;

[0035] Figures 18A-18C Represents a unicast connection establishment method according to an example embodiment in which an initiating UE RRC configures a target UE, or assists in the configuration of a target UE;

[0036] Figures 19A-19C represents a unicast connection establishment method according to an example embodiment in which the target UE PC5 configures the initiating UE, or assists in the configuration of the target UE;

[0037] Figures 20A-20C represents a unicast connection establishment method according to an example embodiment in which the target UE PC5 configures the initiating UE, or assists in the configuration of the target UE;

[0038] Figures 21A-21C represents a unicast connection establishment method in which a target UE RRC configures an initiating UE according to an example embodiment;

[0039] Figure 22 shows a transmit-side multicast method for layer 2 link management according to an example embodiment;

[0040] Figure 23 shows a receiving-side multicast method for layer 2 link management according to an example embodiment;

[0041] Figure 24 represents a transmission side broadcast transmission configuration according to an example embodiment;

[0042] Figure 25 represents a receiving-side broadcast transmission configuration according to an example embodiment;

[0043] Figure 26 Indicates the PC5 RRC connection status between two UEs;

[0044] Figure 27 Represents a UE with multiple RRC connections to a gNB and multiple UEs;

[0045] Figure 28 Represents the first example PC5 unicast link model;

[0046] Figure 29 Represents the second example PC5 unicast link model;

[0047] Figure 30 The third example PC5 unicast link model is shown.

[0048] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of example embodiments is for illustration only and is therefore not necessarily intended to limit the scope of the present disclosure. DETAILED DESCRIPTION

[0049] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities—including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as "5G." Development of the 3GPP NR standard is expected to continue and include the definition of next-generation radio access technologies (New RATs), which are expected to include new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backwards-compatible radio access in new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include centimeter wave (cmWave) and millimeter wave (mmWave) spectrum, which will provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0050] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and any of vehicle-to-other-entities communications. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car eCall, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, the tactile internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases, and others, are contemplated herein.

[0051] The following is a list of acronyms related to service levels and core network technologies that may appear in the following descriptions. Unless otherwise noted, acronyms used in this article refer to the corresponding terms listed below.

[0052] Abbreviations

[0053] 3GPP - Third Generation Partnership Project

[0054] 5G - fifth generation

[0055] 5QI - 5G QoS Identifier

[0056] ACK - Acknowledgement

[0057] AM-confirmed mode

[0058] AMF - Access and Mobility Function

[0059] APP-Application

[0060] AS-Access Layer

[0061] BWP-Bandwidth Part

[0062] BSD-token bucket capacity and duration

[0063] BSR-Cache Status Report

[0064] CBR-Channel Busy Rate

[0065] Config

[0066] CSR - Channel Status Report

[0067] CR-channel occupancy rate

[0068] D2D - Device to Device Communication

[0069] DCI - Downlink Control Information

[0070] eNB-Evolved Node B

[0071] eV2X - enhanced vehicle-to-X communication

[0072] E-UTRA - Evolved UMTS Terrestrial Radio Access

[0073] E-UTRAN - Evolved UMTS Terrestrial Radio Access Network

[0074] eNB-Evolved Node B

[0075] gNB-NR NodeB

[0076] GBR - Guaranteed Bit Rate

[0077] GSM - Global System for Mobile Communications

[0078] HARQ - Hybrid Automatic Repeat Request

[0079] IAB-Integrated Access Backhaul

[0080] ID - identification or identifier

[0081] Info

[0082] IP - Internet Protocol

[0083] ITS-Intelligent Transportation System

[0084] ITS-AID - ITS Application Identifier

[0085] I-UE-Initiating UE

[0086] L2 - Layer 2

[0087] LBT - Listen Before Talk

[0088] LCH - Logical Channel

[0089] LCID-Logical Channel Identifier

[0090] LCG - Logical Channel Group

[0091] LTE - Long Term Evolution

[0092] MAC - Media Access Control

[0093] MCH - Multicast Transport Channel

[0094] ME-Mobile Equipment

[0095] MTCH-Multicast Traffic Channel

[0096] MSB - Most Significant Bit

[0097] NAS-non-AS

[0098] NB-NodeB

[0099] NR - New Radio

[0100] PBR - Prioritized Bit Rate

[0101] PC3 - Reference point between UE and ProSe functions

[0102] PC5 - Reference point between a ProSe-enabled UE for control and the user plane for ProSe direct discovery, ProSe direct communication, and ProSe UE-to-network relay

[0103] PDCP - Packet Data Convergence Protocol

[0104] PDU - Protocol Data Unit

[0105] PHY - Physical Layer

[0106] PLMN - Public Land Mobile Network

[0107] PPPP-ProSe per-packet priority

[0108] PPPR-ProSe per-packet reliability

[0109] ProSe - Proximity-based Services

[0110] PSDCH - Physical Sidelink Discovery Channel

[0111] PSSCH - Physical Sidelink Shared Channel

[0112] PSID - Provider Service Identifier

[0113] QAM - Quadrature Amplitude Modulation QFI - QoS Flow Identifier QoS - Quality of Service SA1 - System Architecture Working Group 1 SAP - Service Access Point SBCCH - Sidelink Broadcast Channel SCI - Sidelink Control Information SCS - Subcarrier Spacing SDAP - Service Data Adaptation Protocol SDU - Service Data Unit SIM - Subscriber Identity Module SL - Sidelink

[0114] SL-BCH-SL Broadcast Channel SL-DCH-SL Discovery Channel SL-MCH-SL MCH SL-MTCH-SL MTCH

[0115] SR - Scheduling Request SRB - Signaling Radio Bearer RAN - Radio Access Network RAT - Radio Access Technology RLC - Radio Link Control RNTI - Radio Network Temporary Identifier ROHC - Robust Header Compression RRC - Radio Resource Control RSRP - Reference Signal Received Power RSRQ - Reference Signal Received Quality RSSI - Received Signal Strength Indicator RSU - Road Side Unit RX - Receiver or Receiver

[0116] SAP-Service Access Point

[0117] SBCCH - Sidelink Broadcast Control Channel

[0118] SCCH - Sidelink Control Channel

[0119] SL-SCH - Sidelink Shared Channel

[0120] TM-Transparent Mode

[0121] T-UE - target UE

[0122] TX - Transmitter or Transmit

[0123] UDC-Header Data Compression

[0124] UE - User Equipment

[0125] UL - Uplink

[0126] UM-Unconfirmed Mode

[0127] UMTS - Universal Mobile Telecommunications System

[0128] UpL-Upper Level

[0129] USIM - Universal Subscriber Identity Module

[0130] Uu - Uu interface that connects the UE to the RAN

[0131] V2V - Vehicle to Vehicle Communication

[0132] V2X - Vehicle to X Communication

[0133] VQI - V2X QoS Identifier

[0134] WG2 - Working Group 2

[0135] WiFi - WLAN radio access technology, used interchangeably with WLAN in this article.

[0136] WLAN-Wireless Local Area Network

[0137] The following features / processes / functions will be discussed in this disclosure:

[0138] NR V2X sidelink L2 structure.

[0139] V2 connection configuration process, including V2X upper connection configuration, V2X AS connection configuration, V2X AS support for V2X upper layer connections, and coverage of unicast, multicast, and broadcast transmission modes.

[0140] Provisions for V2X transmitter and receiver sides.

[0141] V2X RAT and interface selection.

[0142] V2X communication mode selection.

[0143] Specifically, the following concepts and topics will be discussed:

[0144] 1. Layer 2 protocol structure;

[0145] 2. Provisioning of V2X transmitters and receivers;

[0146] 3. Triggering of V2X transmission or V2X reception;

[0147] 4. RAT and interface selection on the transmitter and receiver sides, who makes the selection, and based on what standards;

[0148] 5. Transmission mode selection and selection criteria on the transmitter and receiver sides;

[0149] 6. Detailed procedures for unicast connection management, including descriptions of auxiliary parameters from the UE (e.g., receiver capabilities), and unicast configuration parameters configured into the UE by the scheduling entity or an auxiliary UE in coordination with the scheduling entity;

[0150] 7. Different alternatives for connection management;

[0151] 8. Group connection configuration and the concept of mapping V2X upper layer groups to AS layer subgroups, maintenance of the mapping table in the AS, and indication from the AS to the PHY. Broadcast configuration and various options for broadcast configuration signaling;

[0152] 9. Method for a UE to handle multiple simultaneous sidelink RRC connections;

[0153] 10. Modeling of PC5 unicast link granularity, unicast link update, and unicast link addition processes.

[0154] Example Communication Systems and Networks

[0155] Figure 1A An embodiment of an example communication system 100 is illustrated in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (generally or collectively referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Figure 1A-1E , but it should be understood that for the various use cases contemplated for wireless communication, each WTRU may include or be implemented in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, industrial equipment, a drone, a vehicle such as a car, bus or truck, a train or airplane, and the like.

[0156] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. Examples of network services may include V2X services, ProSe services, IoT services, video streaming, edge computing, and the like. The base station 114b may be any type of device configured to wirelessly interface with at least one of the remote radio heads (RRHs) 118a, 118b, transmission and reception points (TRPs) 119a, 119b, and / or roadside units (RSUs) 120a, 120b to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or networks 113. For example, the base stations 114 a and 114 b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a next-generation Node B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, etc. While the base stations 114 a and 114 b are each depicted as a single element, it will be appreciated that the base stations 114 a and 114 b may include any number of interconnected base stations and / or network elements.

[0157] Base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Cells may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, eg, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may use multiple transceivers for each sector of the cell.

[0158] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0159] The base station 114b can communicate with one or more of the RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b can be established using any suitable radio access technology (RAT).

[0160] The RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a and 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over the air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0161] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with each other, such as vehicle-to-vehicle (V2V) sidelink communications, via direct air interfaces 115d / 116d / 117d, and the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with the network service 113, such as vehicle-to-infrastructure (V2I) sidelink communications, via direct air interfaces 115e / 116e / 117e (not shown), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interfaces 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0162] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and / or the RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0163] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications). 3GPP NR technology includes NR V2X technology and interfaces (such as sidelink communication, etc.).

[0164] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, RPs 119a, 119b and / or RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0165] Figure 1AThe base station 114c in the embodiment may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a train, an airplane, a satellite, a factory, a campus, etc. In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0166] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d, 102f. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).

[0167] Although not in Figure 1A Although not shown in the figures, it will be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

[0168] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) of the TCP / IP (Transmission Control Protocol / Internet Protocol) internet protocol suite. Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include any type of packet data network (i.e., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

[0169] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102g shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0170] Although not in Figure 1A , it should be appreciated that the user equipment may establish a wired connection to the gateway. The gateway may be a residential gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It should be appreciated that many of the concepts included herein may be equally applicable to a UE that is a WTRU and a UE that connects to the network using a wired connection. For example, the concepts applied to wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to wired connections.

[0171] Figure 1B is a block diagram of an example apparatus or device, such as, for example, WTRU 102, configured for wireless communication in accordance with the embodiments described herein. Figure 1BAs shown in the example WTRU 102, it may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiment. Moreover, the embodiments contemplate that the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home evolved Node B (HeNB), a Home evolved Node B gateway, a next generation Node B (gNode-B), and a proxy node, etc.), may include Figure 1B Some or all of the elements depicted in and described herein.

[0172] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0173] The transmit / receive element 122 of the UE can be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117, or transmit signals to another UE or receive signals from another UE via air interface 115d / 116d / 117d. For example, in an embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be a transmitter / detector configured to, for example, transmit and / or receive IR, UV or visible light signals. In another embodiment, the transmit / receive element 122 can be configured to transmit and receive both RF and optical signals. It should be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless or wired signals.

[0174] Furthermore, although the transmit / receive element 122 Figure 1B Although depicted as a single element in FIG. 1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0175] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or to communicate using the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0176] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In an embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server hosted in the cloud or on an edge computing platform, or on a home computer (not shown).

[0177] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0178] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location-determination method while remaining consistent with an embodiment.

[0179] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0180] The WTRU 102 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, and vehicles (such as cars, trucks, trains, or airplanes). The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0181] Figure 1C 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Figure 1C As shown in FIG, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0182] like Figure 1C As shown, Node Bs 140a and 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, and 140c can communicate with respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can communicate with each other via an Iur interface. Each RNC 142a and 142b can be configured to control the respective Node B 140a, 140b, and 140c connected thereto. Additionally, each RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

[0183] Figure 1CThe core network 106 shown in FIG may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements is depicted as part of the core network 106, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0184] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0185] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0186] As described above, the core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0187] Figure 1D 1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0188] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0189] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink and / or downlink, etc. Figure 1D As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0190] Figure 1D The core network 107 shown in FIG may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0191] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may also provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0192] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0193] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0194] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0195] Figure 1E 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. The N3IWF 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0196] The RAN 105 may include gNode-Bs 180a and 180b, though it will be appreciated that the RAN 105 may include any number of gNode-Bs while remaining consistent with an embodiment. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. In embodiments utilizing integrated access and backhaul connectivity, the same air interface may be used between the WTRUs and the gNode-Bs, which may be the core network 109 via one or more gNBs. In embodiments, the gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the gNode-B 180a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a. It will be appreciated that the RAN 105 may utilize other types of base stations, such as eNode-Bs. It will also be appreciated that the RAN 105 may utilize more than one type of base station. For example, RAN may employ eNode-B and gNode-B.

[0197] The N3IWF 199 may include a non-3GPP access point 180c, but it will be appreciated that the N3IWF 199 may include any number of non-3GPP access points while remaining consistent with an embodiment. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. In an embodiment, the non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using the 802.11 protocol.

[0198] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, etc. Figure 1E As shown in FIG, gNode-Bs 180a and 180b may communicate with each other via an Xn interface.

[0199] Figure 1EThe core network 109 shown in the figure may be a 5G core network (5GC). The 5GC may provide numerous communication services to customers interconnected via a radio access network. The 5G core network 109 includes a plurality of entities that perform the functions of the core network. The terms "core network entity" or "network function" as used herein refer to any entity that performs one or more functions of the core network. It should be understood that such a core network entity may be a logical entity implemented in the form of software (computer executable instructions) stored on a device configured for wireless and / or network communications, or a computer system such as a 5G core network. Figure 1F The system is stored in a memory of the system shown in FIG. 1 and executed on its processor.

[0200] like Figure 1E As shown in FIG, the 5G core network 109 may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, a user plane function (UPF) 176a and 176b, a user data management function (UDM) 197, an authentication server function (AUSF) 190, a network exposure function (NEF) 196, a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 199, an application function (AF) 188, and a user data repository (UDR) 178. Although each of the aforementioned elements is depicted as part of the 5G core network 109, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be appreciated that the 5G core network may not be composed of all of these elements, may be composed of additional elements, and may be composed of multiple instances of each of these elements. Figure 1E This indicates that the network functions are directly connected to each other, but it should be recognized that they can communicate via a routing agent (such as the Diameter routing agent) or a message bus. Figure 1E The connectivity between network functions is represented as being implemented via a set of interfaces or reference points, but it should be recognized that network functions can be emulated, described, or implemented as a set of services that are invoked or called by other network functions or services. The invocation of network function services can be achieved via direct connections between network functions, the exchange of messages on a message bus, calling software functions, etc.

[0201] The AMF 172 may be connected to the RAN 105 via the N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to and from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not Figure 1E Shown in.

[0202] The SMF 174 may be connected to the AMF 172 via the N11 interface, to the PCF 184 via the N7 interface, and to the UPF 176 via the N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and the UPF 176b, and generation of downlink data notifications to the AMF 172.

[0203] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to packet data networks (PDNs), such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be Ethernet or any other type of network that switches data packets. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to the packet data network by connecting to the packet data network using the N6 interface or by connecting to other UPFs via the N9 interface. In addition to providing access to packet data networks, UPF 176 may also be responsible for packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, and downlink packet buffering.

[0204] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170 via a radio interface technology not implemented by 3GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0205] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not in Figure 1E 102a, 102b, and 102c. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to enforce these rules. The PCF 184 may send the policy to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policy to the WTRUs 102a, 102b, and 102c via the N1 interface. The policy may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0206] UDR 178 can serve as a repository for authentication credentials and subscription information. The UDR can connect to network functions so that the network functions can add data to, read data from, and modify data in the repository. For example, UDR 178 can connect to PCF 184 via the N36 interface, UDR 178 can connect to NEF 196 via the N37 interface, and UDR 178 can connect to UDM 197 via the N35 interface.

[0207] UDM 197 may serve as an interface between UDR 178 and other network functions. UDM 197 may authorize network functions to access UDR 178. For example, UDM 197 may be connected to AMF 172 via the N8 interface, UDM 197 may be connected to SMF 174 via the N10 interface, and UDM 197 may be connected to AUSF 190 via the N13 interface. UDR 178 and UDM 197 may be tightly integrated.

[0208] The AUSF 190 performs authentication-related operations, is connected to the UDM 178 via the N13 interface, and is connected to the AMF 172 via the N12 interface.

[0209] NEF 196 exposes the capabilities and services in the 5G core network 109 to the application function 188. The exposure occurs over the N33 API interface. NEF can connect to AF 188 via the N33 interface, and it can connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0210] The application functions 188 may interact with network functions in the 5G core network 109. The interaction between the application functions 188 and the network functions may occur via a direct interface or may occur via the NEF 196. The application functions 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise that has a business relationship with the mobile network operator.

[0211] Network slicing is a mechanism that can be used by mobile network operators to support one or more 'virtual' core networks behind the operator's air interface. This involves slicing the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements (for example, in terms of functionality, performance, and isolation).

[0212] 3GPP designed the 5G core network based on the concept of network slicing. Network slicing is a promising tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) with very diverse and sometimes extreme requirements. Without network slicing, when each use case has its own specific set of performance, scalability, and availability requirements, the network architecture is likely to be insufficiently flexible and scalable to effectively support a wider range of use case requirements. Furthermore, the introduction of new network services should be made more efficient.

[0213] In a network slicing scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via the N1 interface. The AMF may logically be part of one or more slices. The AMF may coordinate the connection or communication between the WTRU and one or more UPFs 176, SMFs 174, and other network functions. Each of the UPFs 176, SMFs 174, and other network functions may be part of different or the same slice. When they are part of different slices, they may be isolated from each other in that they may utilize different computing resources, security credentials, etc.

[0214] The 5G core network 109 may facilitate communications with other networks. For example, the 5G core network 109 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include, or may communicate with, a Short Message Service (SMS) service center that facilitates communications via the Short Message Service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0215] This article describes and Figure 1A 、 1C The core network entities shown in 1D and 1E are identified by the names given to those entities in certain existing 3GPP specifications, but it should be recognized that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications released by 3GPP (including future 3GPP NR specifications). Figure 1A 、 1B The specific network entities and functions described and illustrated in , 1C, 1D and 1E are provided as examples only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0216] Figure 1F is a block diagram of an exemplary computing system 90 in which Figure 1A 、 1C, 1D, and 1E, such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other network 112, or network service 113. Computing system 90 may comprise a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed within processor 91 to cause computing system 90 to operate. Processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, or the like. Processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0217] In operation, processor 91 retrieves, decodes, and executes instructions, and transfers information to and from other resources via the computing system's primary data transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0218] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that allows information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. Data stored in RAM 82 can be read or changed by processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates virtual addresses into physical addresses when executing instructions. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; it cannot access memory within the virtual address space of another process unless memory sharing between processes has been set up.

[0219] In addition, the computing system 90 may include a peripheral device controller 83 that is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0220] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0221] Additionally, computing system 90 may contain communications circuitry such as, for example, a wireless or wired network adapter 97, which may be used to connect computing system 90 to external communications networks or devices such as Figure 1A 、 1B , RAN 103 / 104 / 105 of 1C, 1D, and 1E, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other network 112) to enable computing system 90 to communicate with other nodes or functional entities of those networks. Communication circuitry, alone or in combination with processor 91, may be used to perform the transmission and reception steps for certain devices, nodes, or functional entities described herein.

[0222] Figure 1GAn embodiment of an example communication system 111 is illustrated in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station gNB 121, a V2X server 124, and RSUs 123a and 123b, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base station gNBs, V2X networks, and / or other network elements. One, some, or all of the WTRUs A, B, C, D, and E may be outside the coverage area of ​​the access network 122. WTRUs A, B, and C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, and F may communicate with each other via the Uu interface 129a / 129b (if within the access network coverage) or via the sidelink (PC5 or NR PC5) interface 125a (if within or outside the access network coverage). WTRUs A, B, C, D, E, and F may communicate with the RSU via the vehicle-to-network (V2N) interface 126 or the sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with the V2X server 124 via the vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via the vehicle-to-person (V2P) interface 128.

[0223] It should be understood that any or all of the devices, systems, methods, and processes described herein can be implemented in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any steps, operations, or functions described herein can be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable, and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, cassettes, tapes, magnetic disk storage devices or other magnetic storage devices, or any other tangible or physical media that can be used to store desired information and can be accessed by a computing system.

[0224] Connection Management in LTE D2D Sidelink

[0225] One-to-many ProSe direct communication

[0226] In ProSe, especially in LTE D2D sidelink communication, one-to-many ProSe direct communication has the following characteristics:

[0227] One-to-many ProSe direct communication is connectionless. Thus, there is no signaling on the PC5 control plane.

[0228] • The radio layer provides user plane communication services for the transmission of IP packets between UEs participating in direct communication.

[0229] • The members of a group share a secret from which a group security key can be derived to encrypt all user data of the group.

[0230] • Authorization for one-to-many ProSe direct communication is configured in the UE by the ProSe function using the PC3 reference point.

[0231] Configure ProSe UE configuration parameters in the UE (e.g., including ProSe group IP multicast address, ProSe group ID, group security material, radio-related parameters for transmission and reception).

[0232] One-to-one ProSe direct communication

[0233] One-to-one ProSe direct communication is connection-oriented and is achieved by establishing a secure Layer 2 link between two UEs over PC5. Figure 2 The control plane for establishing, maintaining and releasing a logical connection for one-to-one sidelink communications is shown in Note that throughout this disclosure, PC5 and sidelink interface may be used interchangeably.

[0234] Each UE (e.g. Figure 2 UE A and UE B in the example have a Layer 2 ID for unicast communication, which is included in the source Layer 2 ID field of each frame sent by each UE on the Layer 2 link and in the destination Layer 2 ID of each frame received by each UE on the Layer 2 link. Conflicts between destination Layer 2 IDs used for unicast and one-to-many communications will be resolved by RAN WG2. The UE needs to ensure that the Layer 2 ID used for unicast communication is at least locally unique.

[0235] The Layer 2 link for one-to-one ProSe direct communication is identified by the combination of the Layer 2 IDs of the two UEs, which means that a UE can participate in multiple Layer 2 links for one-to-one ProSe direct communication using the same Layer 2 ID.

[0236] In ProSe, PC5-S signaling is used for connection management and security management, such as Figure 3As shown in . Figure 3 In step S302, UE-1 sends a direct communication request to UE-2. In step S304, authentication and security association are established.

[0237] The connection management process includes PC5 link establishment, link maintenance through the keep-alive function, and link release. Security management includes PC5 security mode control and (re)key generation.

[0238] Aside from security parameters, PC5-S cannot configure AS layer parameters. It is important to note that RRC is not currently used for PC5 AS configuration to support sidelink communications. RRC is only used to broadcast common sidelink configuration parameters on the Sidelink Broadcast Control Channel (SBCCH).

[0239] Support for QoS in ProSe

[0240] QoS control is based on per-packet QoS. When the ProSe upper layer (i.e., above the PC5 access layer) passes a protocol data unit for transmission to the PC5 access layer, the ProSe upper layer provides a ProSe per-packet priority (PPP) within a range of 8 possible values, and a ProSe per-packet reliability (PPPR) within a range of 8 possible values. PPPP and PPPR are independent of the destination Layer 2 ID and are applicable to one-to-one and one-to-many ProSe direct communications. PPPP and PPPR are selected by the application layer. The ProSe per-packet priority value will be assigned to the PC5-S message. The UE is configured with a ProSe per-packet priority value for transmitting any PC5-S message.

[0241] PPPP and PPPR are neutral to the mode in which the UE accesses the medium, i.e. whether it uses scheduled or autonomous transmission mode.

[0242] The ProSe access layer uses the ProSe per-packet priority associated with the protocol data unit received from upper layers to prioritize this transmission relative to other intra-UE transmissions (i.e., protocol data units associated with different priorities waiting for transmission within the same UE) and inter-UE transmissions (i.e., protocol data units associated with different priorities waiting for transmission within different UEs).

[0243] The ProSe access layer uses the PPPR associated with the protocol data unit received from upper layers to decide and adjust transmission behavior, or for example packet repetition.

[0244] PC5 Access Layer (Radio) Configuration for ProSe

[0245] like Figure 4As shown in , the user plane access protocol stack (AS) in the PC5 interface consists of PDCP, RLC, MAC and PHY.

[0246] As described above, one-to-many ProSe communication over the PC5 interface is connectionless and has no predefined specific receiver. Therefore, receiver-side control or configuration of radio protocol stack or radio resource capabilities is not required. However, as described above, one-to-one ProSe communication over the PC5 interface is connection-oriented, and the PC5-S signaling protocol used for connection establishment is not designed for AS layer parameter configuration. Consequently, for both one-to-many and one-to-one ProSe communication, the RX UE protocol stack configuration is predefined in the specification, and all features are mandatory for the RX UE. For example, there is no HARQ feedback for sidelink communication, RLC UM is used for sidelink communication, ROHC unidirectional mode is used for header compression in PDCP for sidelink communication, and uplink data compression (UDC) is not used for sidelink communication. The receiving UE is required to maintain at least one RLC UM entity for each transmitting peer UE. Configuration of the receiving RLC UM entity for sidelink communication is not required before receiving the first RLC UMD PDU. For the TX UE, AS parameters are configured or derived from QoS inputs provided by upper layers. For example, the UE can establish multiple logical channels based on QoS inputs from upper layers. The LCID included in the MAC subheader uniquely identifies a logical channel within the range of one source layer 2 ID and destination layer 2 ID combination. As described above, parameters for logical channel prioritization are not configured. The access stratum (AS) is provided with PPPP of protocol data units transmitted over the PC5 interface by a higher layer. There is PPPP associated with each logical channel. Similarly, PPPR is not configured. The AS is provided with PPPR of protocol data units transmitted over the PC5 interface by a higher layer. Radio resources for ProSe direct communication can be autonomously selected by the UE AS based on QoS inputs and radio resource configuration information provided by upper layers (when out of coverage), or can be scheduled by the eNB taking into account QoS inputs and upper layer resource configuration reported by the UE to the eNB (for example, when in coverage or when out of coverage).

[0247] Connection Management in LTE V2X Sidelink

[0248] One-to-many V2X communication

[0249] V2X communication over the PC5 reference point is a type of ProSe direct communication, where V2X communication over the PC5 reference point is connectionless and there is no signaling on the PC5 control plane for connection establishment. V2X messages are exchanged between UEs over the PC5 user plane.

[0250] One-to-one V2X communication

[0251] In LTE, there is no support for connection-oriented communication and no support for one-to-one V2X communication.

[0252] Support for QoS in V2X

[0253] QoS control for V2X sidelink communication is based on per-packet QoS and follows the same principles as for ProSe sidelink communication described in Section 2.2.3.

[0254] PC5 Access Layer (Radio) Configuration for V2X

[0255] The PC5 access layer configuration is similar to the PC5 access layer configuration used for ProSe direct communication.

[0256] One-to-many V2X communication over the PC5 interface is connectionless and has no predefined specific recipient. Consequently, no receiver-side control or configuration of radio protocol stack or radio resource capabilities is required. Consequently, the RX UE protocol stack configuration is predefined in the specification, and all features are mandatory for the RX UE. For example, there is no HARQ feedback for sidelink communication, RLC UM is used for sidelink communication, ROHC unidirectional mode is used for header compression in PDCP for sidelink communication, and uplink data compression (UDC) is not used for sidelink communication. The receiving UE is required to maintain at least one RLC UM entity for each transmitting peer UE. The receiving RLC UM entity does not need to be configured for sidelink communication before receiving the first RLC UMD PDU. For the TX UE, AS parameters are configured or derived from QoS inputs and other configuration parameters (such as TX profiles) provided by upper layers. For example, the UE can establish multiple logical channels based on QoS inputs from upper layers. The LCID included in the MAC subheader uniquely identifies a logical channel within the range of a source Layer 2 ID and destination Layer 2 ID combination. As described above, parameters for logical channel prioritization are not configured. The access stratum (AS) is provided with PPPP by the upper layers for protocol data units transmitted over the PC5 interface. There is PPPP associated with each logical channel. Similarly, PPPR is not configured. The AS is provided with PPPR by the upper layers for protocol data units transmitted over the PC5 interface. Radio resources for ProSe direct communication can be autonomously selected by the UE AS based on the QoS input and radio resource configuration information provided by the upper layers (when out of coverage), or can be scheduled by the eNB taking into account the QoS input and upper layer resource configuration reported by the UE to the eNB (for example, when within coverage or when out of coverage). The TX profile is used to decide whether to use the version 14 PHY format or the version 15 PHY format (for example, 64QAM) for V2X sidelink transmission.

[0257] NR V2X use cases

[0258] SA1 has identified four main groups of advanced V2X use cases[1][2]: platooning, extended sensors, advanced driving, and remote driving, as follows:

[0259] Vehicle platooning, which enables vehicles to dynamically form groups to travel together. All vehicles in the platoon receive periodic data from the lead vehicle to enable platooning operations. This information allows the distance between vehicles to be very small, i.e., the gap distance converted into time can be very small (sub-second). Platooning applications can allow the following vehicle to drive autonomously.

[0260] Expanded sensors enable the exchange of raw or processed data collected by local sensors, or real-time video data, between vehicles, RSUs, pedestrian devices, and V2X application servers. This allows vehicles to enhance their awareness of surroundings beyond the range of their own sensors and gain a more comprehensive view of local conditions. High data rates are a key feature.

[0261] Advanced driving, which enables semi- or fully autonomous driving. This assumes a large inter-vehicle distance. Each vehicle and / or RSU shares data from its local sensors with neighboring vehicles, allowing them to coordinate their trajectories or maneuvers. Furthermore, each vehicle shares its driving intentions with neighboring vehicles. The benefits of this use case group include safer driving, collision avoidance, and improved traffic efficiency.

[0262] Remote driving, which enables remote pilots or V2X applications to operate a remote vehicle for occupants who are unable to drive themselves, or to operate a remote vehicle in hazardous environments. Cloud-based driving can be used for situations where variability is limited and routes are predictable, such as public transportation. The main requirements are high reliability and low latency.

[0263] like Figure 5 As shown in , the requirements for NR V2X are more diverse and stringent compared to LTE V2X.

[0264] As mentioned earlier, from the AS perspective, ProSe sidelink unicast and multicast transmissions are connectionless. In addition, LTE V2X only supports multicast transmission, which is also connectionless. Considering that the requirements of NR V2X are more diverse and stringent compared to LTE V2X, AS connectionless transmission poses many challenges and may not be sufficient under the diverse and stringent requirements of NR V2X, such as in supporting requirements for higher data rates, higher reliability, and lower latency. The following are some examples of the challenges of using AS connectionless transmission for unicast and multicast to meet NR V2X requirements. Note that throughout this disclosure, groupcast and multicast are used interchangeably.

[0265] 1. Higher Protocol Overhead: For AS connectionless transmission, to allow received V2X packets to be delivered to the correct upper layer Service Access Point (SAP) in the RX UE, and to allow the SL RX UE to distinguish between different SL TX UEs, each V2X packet must carry a destination ID and a source ID. Furthermore, AS connectionless transmission, which multiplexes traffic at the MAC layer, requires that each transmitted MAC PDU carry an L2 destination ID and a source L2 ID to uniquely identify the logical channel within the context of the source and destination pair. For both the ProSe sidelink and the V2X sidelink, each MAC PDU carries an L2 source ID and an L2 destination ID, which are mapped to upper layer source and destination IDs, respectively, to limit overhead. However, despite this mapping, each V2X packet transmission still incurs the overhead of the L2 source and destination IDs. While such protocol overhead is acceptable in the case of LTE V2X transmission with relatively low data rate transmissions, such overhead can be prohibitive in the case of NR V2X.

[0266] 2. Higher Processing Overhead: The fact that each sidelink packet carries an L2 source ID and an L2 destination ID also means more packet filtering processing overhead in L2. For example, in LTE V2X, the RX PHY layer passes all successfully decoded V2X packets received on the configured RX resource pool to the RX L2, where they are then filtered in L2 using the 24-bit L2 destination ID and 24-bit L2 source ID, ensuring that only V2X packets destined for that RX UE are passed to the V2X upper layer. Similarly, for the ProSe sidelink, the PHY layer must decode all packets received on the configured RX resources, perform partial filtering based on the 8 LSB bits of the L2 destination ID in the SCI, and then pass the partially filtered packets to L2, where they are further filtered in L2 based on the 16 MSB bits of the L2 destination ID and the 24-bit source L2 ID. While such processing overhead is acceptable in the case of LTE V2X transmissions with relatively low data rates, it can be prohibitive in the case of NRV 2X.

[0267] 3. Difficulty implementing physical layer feedback: For AS connectionless transmission, L2 feedback, i.e., RLC feedback, is not supported, and HARQ feedback is not supported in traditional LTE ProSe or traditional V2X sidelink communications. There is no PHY layer UE-specific identifier (source or destination), such as C-RNTI, or a communication context dedicated to a specific UE, to support the transmission of personalized feedback from the RX UE to the TX UE. This is quite complex to implement without connection-oriented transmission.

[0268] 4. Difficulty in implementing link management to help meet QoS requirements: For AS connectionless transmission, it is unrealistic or impossible to implement UE-specific radio link management functions, such as radio link monitoring and radio link recovery, beam management, link adaptation (power control and rate control), and channel-dependent scheduling. Although the lack of these functions is acceptable for the ProSe side link or V2X side link, the diversity and stringent requirements of NR V2X, such as higher data rates coupled with higher reliability and lower latency, require more effective radio resource management. In addition, connection-based SL makes it easier to perform SL QoS control on a per-QoS flow basis, thus providing a basis for unified QoS processing through SL and Uu.

[0269] 5. Inability to support differentiated RX UE configuration: With AS connectionless transmission, it is not possible to configure the RX UE with an AS configuration specific to the RX UE, for example, based on RX UE capabilities. Consequently, all ProSe sidelink features or LTE V2X sidelink features of a given release are mandatory for all RX UEs of that release. NR V2X requirements are diverse, and it is impractical to make all NR V2 features of any given release mandatory for all NR V2X UEs of that release. SL transmission based on AS layer connections enables more flexible SL radio protocol configuration.

[0270] In view of the above-mentioned shortcomings of AS connectionless transmission in the case of NR V2X communication, support for AS connection-oriented transmission is also needed for NR V2X unicast and for NR V2X multicast.

[0271] Issues related to connection-oriented unicast transmission

[0272] In order to support AS connection-oriented unicast transmission, the following issues need to be addressed.

[0273] 1. The entire process of unicast connection establishment, connection modification / reconfiguration, and connection release

[0274] 2. Authorization and provisioning of UEs to support connection-oriented unicast transmissions (in-coverage and out-of-coverage)

[0275] 3. V2X provisioning information (UE assistance information) shared by the UE and gNB to support unicast connection establishment, modification, or release.

[0276] 4. Triggering for unicast connection reconfiguration, connection release, and connection relocation

[0277] 5. SL AS protocol configuration, including:

[0278] a. Configuration of MAC, RLC (e.g., UM vs. AM decisions), PDCP, SDAP, radio resources / radio bearers, PHY configuration (e.g., HARQ (including HARQ TX with feedback vs. HARQ TX without feedback), CSI, etc.), assuming one or more of the following: flow-based QoS vs. per-packet QoS, Mode 1 vs. Mode 2 resource allocation

[0279] b. For SL unicast, AS-level information needs to be exchanged between UEs via the sidelink, such as UE ID, UE capabilities, radio / bearer configuration, PHY information / configuration (e.g., HARQ, CSI), resource information / configuration, and QoS information

[0280] c. Enhancements to Uu to support SL connection management and QoS, and what AS-level information needs to be exchanged between the UE and gNB for SL unicast communications

[0281] d. How to exchange AS-level information between UEs via sidelink to support unicast, RRC to PC5 signaling details to be specified.

[0282] 6. Access control, how to perform access control, and which entity performs access control

[0283] 7. UE identity configuration and coordination between the TX UE and RX UE to support unicast transmission. For example, in the LTE ProSe sidelink unicast design, the UE needs to ensure that the Layer 2 ID used for unicast communication is at least locally unique. To this end, the UE should be prepared to use unspecified mechanisms to handle Layer 2 ID conflicts with neighboring UEs (for example, when a conflict is detected, it will allocate a new Layer 2 ID for unicast communication). How to ensure the uniqueness of the L2 ID used for communication for unicast connections is a problem that needs to be solved.

[0284] 8. It is expected that the discovery process will be used to identify specific UEs for initiating one-to-one communications. While upper layers above the access layer can indicate to the access layer QoS-related information and whether communications should be unicast, multicast, or broadcast, access layer-specific rules and standards may need to be developed to determine whether unicast communications should be conducted in a connectionless or connection-oriented manner. Furthermore, the interaction between discovery and unicast connection management needs to be addressed, as well as how the output of discovery can be used to support unicast connection establishment, connection release, or connection relocation decisions.

[0285] Issues related to connection-oriented multicast transmission

[0286] Similarly, the problems described above in the section entitled "Problems Related to Connection-Oriented Unicast Transmission" need to be solved with respect to connection-oriented multicast transmission. Specifically, in order to support AS connection-oriented multicast transmission, the following problems need to be solved.

[0287] 1. The entire process of multicast connection establishment, connection modification / reconfiguration, and connection release

[0288] 2. Authorization and provisioning of UEs to support connection-oriented multicast transmissions (in-coverage and out-of-coverage)

[0289] 3. V2X provisioning information (e.g., UE assistance information) shared by the UE and gNB to support multicast connection establishment, modification, or release.

[0290] 4. For example, triggering of multicast connection establishment between a group member and a group leader, and triggering of multicast connection reconfiguration, connection release, and connection relocation by a group member to another group leader.

[0291] 5. SL AS protocol configuration, including:

[0292] a. Configuration of MAC, RLC (e.g., UM vs. AM decision), PDCP, SDAP, radio resources / radio bearers, PHY configuration (e.g., HARQ (including HARQ TX with feedback vs. HARQ TX without feedback), CSI, etc.), assuming one or more of the following: flow-based QoS vs. per-packet QoS, Mode 1 vs. Mode 2 resource allocation.

[0293] b. For SL multicast, AS-level information such as UE ID, UE capabilities, radio / bearer configuration, PHY information / configuration (e.g., HARQ, CSI), resource information / configuration, and QoS information needs to be exchanged between UEs via the side link.

[0294] c. Enhancements to Uu to support SL connection management and QoS, and what AS-level information needs to be exchanged between the UE and gNB for SL multicast communications

[0295] d. How to exchange AS-level information between UEs via sidelink to support unicast, RRC to PC5 signaling details to be specified.

[0296] 6. Access control, how to perform access control, and which entity performs access control.

[0297] 7. UE identity configuration and coordination between TX and RX UEs to support multicast transmission. RX UEs can participate in the reception of more than one multicast communication. Similarly, TX UEs can participate in the transmission of more than one multicast communication. It is necessary to ensure that the Layer 2 ID used for multicast communication is at least locally unique. Ensuring the uniqueness of the Layer 2 ID used for connection-oriented multicast communication is a challenge that needs to be addressed.

[0298] 8. It is expected that the discovery process will be used to identify a specific UE or group of UEs for initiating one-to-many communication. While upper layers above the access layer can indicate QoS-related information to the access layer and whether communications should be unicast, multicast, or broadcast, access layer-specific rules and standards may need to be developed for determining whether multicast communications should be conducted in a connectionless or connection-oriented manner. Furthermore, the interaction between discovery and multicast connection management and how the output of discovery is used to support multicast connection establishment, connection release, or connection relocation decisions need to be addressed. A related issue is whether V2X group management should be performed only in the V2X upper layers, only in the AS layer, or in both layers. If so, what is the relationship between the AS group and the V2X upper layer group? For example, if the UE members in the upper layer group are distributed over a large geographic area, a single AS layer group may not cover all UE members. To enable successful communication between all UEs in the upper layer UE group, multiple AS layer groups may be required. For each AS group, member UEs can establish and maintain an AS layer group connection with the AS group leader. When a member UE moves around, it is released from the original AS layer group and reconnected to another AS layer group. The procedures, configurations, and interactions between the upper layers and the AS layer for establishing and maintaining AS multicast connections and mapping to upper layer sessions / connections need to be designed and specified.

[0299] Overview of the proposed solution

[0300] In this disclosure, the following solutions are proposed to support unicast connection management:

[0301] 1. Layer 2 protocol structure, including the following:

[0302] A new proposal to have one SDAP entity per V2X destination and only have a QoS flow ID in the SDAP protocol header, as there is no need to support the Reflective QoS feature on the sidelink;

[0303] MAC SDUs that are subject to connection-oriented transmission and MAC SDUs that are subject to connectionless transmission are multiplexed separately;

[0304] MAC PDUs subject to connection-oriented transmission do not carry a source ID or a destination ID;

[0305] Supports sidelink multicast control channel and sidelink multicast transport channel;

[0306] 2. Provisioning of V2X transmitters and receivers;

[0307] 3. Triggering V2X transmission or V2X reception;

[0308] 4. RAT and interface selection on the transmitter and receiver sides, which entity makes the selection, and based on what criteria;

[0309] 5. Transmission mode selection on the transmitter and receiver sides, and criteria for such selection;

[0310] 6. Detailed procedures for unicast connection management, including descriptions of auxiliary parameters from the UE (e.g., receiver capabilities), and unicast configuration parameters configured into the UE by the scheduling entity or an auxiliary UE in coordination with the scheduling entity;

[0311] 7. Describes different alternatives for the connection management process, including the following options:

[0312] PC5 RRC signaling is used to carry both V2X upper layer connection configuration and AS layer connection configuration. The T-UE is configured by the scheduling entity or collaboratively configured by the I-UE and I-UE; see Figure 16.

[0313] Use PC5-S signaling to carry both V2X upper layer connection configuration and AS layer connection configuration. T-UE is configured by the scheduling entity or collaboratively configured by I-UE and I-UE; see Figure 17;

[0314] PC5 RRC signaling is used to carry both V2X upper layer configuration information and AS layer connection configuration for supporting AS layer connection. The T-UE is configured by the scheduling entity or in collaboration between the I-UE and the I-UE. In addition, PC5-S signaling is used to perform V2X upper layer connection configuration independently of the AS connection configuration. See Figure 18.

[0315] PC5-S signaling is used to carry both V2X upper layer configuration information and AS layer connection configuration for supporting AS layer connection. The I-UE is configured by the scheduling entity or by the T-UE and I-UE in collaboration. In addition, PC5-S signaling is used to perform V2X upper layer connection configuration independently of the AS connection configuration; see Figure 19.

[0316] Use PC5-S signaling to carry both V2X upper layer connection configuration and AS layer connection configuration. The I-UE is configured by the scheduling entity or the T-UE and the scheduling entity jointly configure it; see Figure 20;

[0317] PC5 RRC signaling is used to carry both V2X upper layer connection configuration and AS layer connection configuration. The I-UE is configured by the scheduling entity or the T-UE and the scheduling entity jointly configure it; see Figure 21;

[0318] 8. The concept of group connection configuration and mapping of V2X upper layer groups to AS layer subgroups, maintenance of the mapping table in the AS, and indication by the AS to the PHY of one or more of the following:

[0319] Group layer 2 destination ID;

[0320] A list of V2X UE IDs of group members (e.g., ProSe UE ID, UE ID, or any other identifier that a UE can use as a source ID for member UEs);

[0321] Subgroup layer 2 destination ID;

[0322] A list of V2X UE IDs (e.g., ProSe UE ID, UE ID, or any other identifier that a UE can use as a source ID for member UEs) of the subgroup members;

[0323] • For each sub-group, an indication requesting that data received for that sub-group be relayed or not.

[0324] 9. Various options for broadcast configuration and broadcast configuration signaling.

[0325] 10. Method for UE to handle multiple simultaneous sidelink RRC connections.

[0326] 11. Modeling of PC5 unicast link granularity, unicast link update, and unicast link addition processes.

[0327] UE operations before V2X communication

[0328] Layer 2 protocol structure

[0329] Figure 6 、 7 , 8 and 9 depict the NR V2X layer 2 side link structure.

[0330] Figure 6An illustration of the Service Data Adaptation Protocol (SDAP) sublayer is provided. It is proposed that there be one SDAP entity per V2X destination. In one embodiment, the V2X destination may be a peer V2X UE destination. In such an embodiment, if a UE has concurrent V2X communications with n peer V2X UEs, the UE then maintains n SDAP entities, one for each peer V2X destination UE. Each SDAP entity maintains a set of bearers specific to the peer V2X destination UE. Since there may be multiple concurrent V2X services between a UE (in this case, the source UE) and a peer V2X destination UE, the L2 destination IDs to which those services are mapped and the radio bearers associated with those services are mapped to the same SDAP entity associated with that particular peer V2X destination UE. Regardless of the transmission broadcast type (i.e., unicast, multicast, or broadcast), V2X packets associated with a given peer V2X destination UE are mapped to the corresponding bearer or SDAP entity to which the destination Layer 2 ID is mapped. In the case of broadcast or multicast, the corresponding bearer and associated Layer 2 destination ID can be mapped to any SDAP entity even if the AS does not explicitly know the peer V2X destination UE; alternatively, there can be one or more SDAP entities dedicated to supporting broadcast communications, or one or more SDAP entities supporting multicast communications, or one or more SDAP entities supporting both multicast and broadcast communications.

[0331] In another embodiment, the services may be arranged in groups that are (pre)configured or provided to the UE. Figure 6 The V2X destination in refers to a group of V2X services.

[0332] In an alternative embodiment, for V2X sidelink communication, each UE can have one SDAP entity. In this case, the V2X communication bearer identifier needs to be unique within the UE.

[0333] Figure 7Depicts the layer 2 structure supporting V2X communications in an AS broadcast configuration, and the mapping of the sidelink broadcast control channel (SBCCH) to the transmit sidelink broadcast channel (SL-BCH). Multiplexing of the sidelink service logical channel (STCH) on the transmit sidelink shared channel (SL-SCH) assumes that each MAC PDU includes a source ID and a destination ID that are unique with respect to its logical channel identifier in order to support MAC multiplexing. It is also proposed to introduce a sidelink control channel (SCCH) that can be multiplexed with the logical STCH onto the SL-SCH. It is also proposed to introduce a sidelink signaling radio bearer (SL-SRB) to which logical channels such as SCCH can be mapped. The SL-SRB can be used for signaling of connection management (e.g., connection proposal, connection reconfiguration, or connection release), or for configuration and reporting of sidelink measurements.

[0334] Figure 8Describes a Layer 2 architecture supporting V2X communications in an AS unicast connection-oriented configuration, with the peer V2X receiver configured with a dedicated unicast V2X configuration taking into account, for example, the peer V2X UE capabilities. In this case, the multiplexing of the Sidelink Traffic Logical Channel (STCH) on the Transmit Sidelink Shared Channel (SL-SCH) does not assume that each MAC PDU includes a source ID and destination ID with respect to which the Logical Channel Identifier is unique to support MAC multiplexing. Instead, the multiplexing on the STCH assumes that a separate instance of the SL-SCH is configured at connection establishment and bound to a HARQ entity dedicated to the transmission of V2X unicast traffic or SL-RRC signaling in an AS connection-oriented manner. At connection establishment, a MAC Service Access Point (SAP) for each instance of the SL-SCH is created and communicated to the PHY, which then creates and maintains a corresponding instance of a PHY channel (e.g., Physical Sidelink Shared Channel, PSSCH) associated with the instance of the SL-SCH indicated by the MAC. As part of the connection context, for each V2X service or data radio bearer included in the connection context, a Layer 2 destination ID mapped to the V2X service is maintained in association with the logical channel and corresponding radio bearer. In this approach, and to support PHY-layer multiplexing of traffic onto a shared channel, a unique physical layer (PHY) identifier for connection-oriented reception, e.g., a PC5 sidelink RNTI identifying both V2X UEs, can be assigned to each peer UE and configured in both peer UEs. Alternatively, each peer UE can autonomously derive its own PHY identifier and exchange it with each other as part of the connection configuration. The TX UE uses the peer RX V2X UE PHY identifier to identify the peer V2X UE to which data is destined. For example, the TX UE can scramble or mask transmitted data with the peer RX V2X UE PHY identifier. The RX UE uses its PHY identifier, already used by the transmitting party, to identify the RX UE of the data. Once decoded, the RX UE is able to correctly route the received data to the correct MAC SAP based on the association between the PHY and MAC SAPs created at connection establishment. In an alternative option where there is no PHY layer multiplexing (e.g., traffic from the peer V2X UE is carried on dedicated PHY resources (pre-)configured or provisioned into the UE), a PHY identifier that uniquely identifies the peer UE involved in the connection may not be required. In this case, the RX UE identifies the correct routing SAP in the peer V2X transmitting UE and MAC based on the PHY resource on which the V2X packet was received.The AS may provide the PHY with a peer V2X UE source ID (e.g., in the case of unicast) or a peer V2X UE destination Layer 2 ID (e.g., similar to a ProSe Layer 2 Group ID or a ProSe Application Layer Group ID) in the case of multicast. The PHY may use such an ID to derive an RNTI for identifying the peer V2X UE to which the transmission is destined. In addition, as part of the connection configuration, a logical channel (e.g., SCCH) carrying control information mapped to a sidelink signaling radio bearer (SL-SRB) may be multiplexed with a logical channel (STCH) carrying sidelink traffic mapped to a sidelink data radio bearer (SL-DRB) onto the SL-SCH transport channel configured for connection-oriented reception. For unicast, it is proposed that a logical SL control channel, denoted as the Sidelink Control Channel (SCCH), be introduced for configuration and control of unicast traffic. The SCCH may be associated with an SL-SRB. The SL-SRB to which the SBCCH is mapped may be denoted as SL-SRB0. The SL-SRB to which the SCCH is mapped and transmitted in a broadcast manner (AS connectionless) may be denoted as SL-SRB1. The SL-SRB to which the SCCH is mapped and transmitted in a connection-oriented manner may be denoted as SL-SRB2.

[0335] Figure 9Describes a Layer 2 architecture supporting V2X communications in an AS multicast connection-oriented configuration, with the peer V2X receiver configured with a dedicated multicast V2X configuration that takes into account, for example, the peer V2X UE's capabilities. In this case, the multiplexing of sidelink traffic logical channels (e.g., SL-MTCH) on the transmit sidelink shared channel (SL-SCH) does not assume that each MAC PDU includes a source ID and destination ID unique with respect to the logical channel identifier to support MAC multiplexing. Instead, multiplexing on the SL-MCH assumes that a separate instance of the SL-MCH is configured at connection establishment and bound to a HARQ entity dedicated to the transmission of V2X multicast traffic or SL-RRC signaling in an AS connection-oriented manner. At connection establishment, a MAC Service Access Point (SAP) for each instance of the SL-MCH is created and communicated to the PHY, which then creates and maintains a corresponding instance of a PHY channel (e.g., Physical Sidelink Shared Channel, PSMCH) associated with the instance of the SL-MCH indicated by the MAC. As part of the connection context, for each V2X service or data radio bearer included in the connection context, a Layer 2 destination ID mapped to the V2X service is maintained in association with the logical channel and corresponding radio bearer. In this approach, and to support PHY-layer multiplexing of traffic onto multicast channels, a unique physical layer (PHY) identifier for connection-oriented reception, e.g., a PC5 sidelink RNTI identifying the TX V2X UE and a unique physical layer identifier identifying the RX group member UE, may be assigned to each UE in the group and configured within each UE. Alternatively, each peer UE may autonomously derive its own PHY identifier and exchange it with each other as part of the connection configuration. The TX UE uses the peer RX V2X UE PHY group identifier to identify the peer V2X group member UE to which data is destined. For example, the TX UE may scramble or mask transmitted data with the peer RX V2X group member UE PHY identifier. The RX UE uses its PHY group identifier, already used by the transmitting party, to identify the RX UE for the data. Once decoded, the RX UE is able to correctly route the received data to the correct MAC SAP based on the association between the PHY and MAC SAPs created at connection establishment. In alternative options where there is no PHY layer multiplexing for multicast traffic (e.g., multicast traffic is transmitted on dedicated PHY resources (pre-)configured or provisioned into the UE), a PHY group identifier that uniquely identifies the peer UEs involved in the connection may not be required. In this case, the RX member UEs identify the correct routing SAP in the multicast traffic MAC based on the PHY resource on which the multicast traffic was received.The AS may provide the PHY with the UE's own source ID, as well as the peer V2X UE source ID (e.g., to support unicast), or, for example, the peer V2X UE destination Layer 2 ID (e.g., similar to a ProSe Layer 2 group ID or a ProSe application layer group ID) in the case of multicast communications. The PHY may use such IDs to derive the RNTI used to identify the peer V2X UE to which the transmission is destined. In addition, as part of the connection configuration, a logical channel (e.g., SL-MCCH) carrying sidelink multicast control information mapped to a sidelink signaling radio bearer (SL-SRB) may be multiplexed with a logical channel (SL-MTCH) carrying sidelink multicast traffic mapped to a sidelink data radio bearer (SL-DRB) onto the SL-MCH transport channel configured for connection-oriented reception. For multicast, a logical sidelink control channel, denoted as a Sidelink Multicast Control Channel (SL-MCCH), may be introduced for configuration and control of multicast traffic. The MCCH may be associated with the SL-SRB. The SL-SRB to which the SBCCH is mapped may be denoted as SL-SRB0. The SL-SRB to which the MCCH is mapped and transmitted in a broadcast manner (AS connectionless) may be denoted as SL-SRB1. The SL-SRB to which the MCCH is mapped and transmitted in a connection-oriented manner may be denoted as SL-SRB2.

[0336] Figure 10 Provides a functional view of the SDAP sublayer. It proposes not to support reflective QoS in the V2X side link. Figure 11 As shown in the figure, it is proposed to simplify the SDAP header and make it the same between the downlink and uplink. The QoS flow identifier (QFI) can be 6 bits or less, and the remaining bits of the header can be reserved or used to carry data, thereby minimizing the overhead of supporting QoS flows on the V2X sidelink.

[0337] Transmitter Operation

[0338] Figure 12 An example transmitter-side high-level illustration of UE operations including the intermediate processes in the UE leading to the decision of whether to conduct V2X communication via AS broadcast, AS unicast, or AS multicast is provided in FIG.

[0339] In step S1200, the UE is either pre-configured (in the SIM or ME) or provided with information supporting V2X operations by a V2X control function located in the core network, i.e., a discovery process. The UE discovers other devices for V2X communication and, for V2X communication, communicates with the other V2X devices as required by the V2X applications running on the V2X devices. Communication between the UE and the V2X control function for provisioning V2X operating parameters can occur via the user plane or the control plane. Provisioning parameters for NR V2X operation, particularly those supporting unicast or multicast communication, is described below in the section entitled "Provisioning of Transmitter-Side V2X Communication." Upon triggering V2X communication in step S1202, the UE may synchronize, if not already synchronized, in step S1204. The UE may also perform discovery to identify a peer UE or group of UEs with which it can communicate, as specified by the triggering conditions for communication. For example, an application in the application layer may trigger the V2X upper layer to discover a peer UE or group of UEs, if not already discovered, and initiate V2X communication with such a UE or group of UEs. Output from the discovery process, such as the Layer 2 Link ID of the discovered UE or group of UEs, may be used by the UE in subsequent V2X operations, such as connection establishment to a specific UE or group of UEs or configuration of broadcast resources for V2X transmissions. In steps S1206 and S1208, the UE performs RAT selection and interface (e.g., sidelink vs. Uu interface) selection. Although steps S1206 and S1208 are listed as separate steps, these two steps can be performed concurrently, as described below in the section entitled "Transmitter-Side RAT Selection and Interface Selection." In step S1210, a determination is made as to whether the SL interface is selected. If so, a determination is made as to the SL transmission mode (step S1212). If the SL transmission mode is broadcast mode, AS configuration for broadcast transmission is performed in step S1218. If the SL transmission mode is unicast mode, Layer 2 link configuration for unicast transmission is performed in step S1214. If the SL transmission mode is multicast mode, Layer 2 link configuration for multicast reception is performed in step S1216. If the SL interface is not selected in step S1210, transmission via the Uu interface is initiated (step S1220).

[0340] Provisioning of V2X communications on the transmitter side

[0341] To support unicast transmission, multicast transmission, broadcast transmission, or flow-based QoS, the NR V2X UE may be pre-configured or provisioned with the following system parameters; the configuration may be on a per-interface basis, such as the NR sidelink interface, NR Uu interface, LTE sidelink interface, LTE Uu interface, WLAN sidelink interface, or WLAN-to-network interface:

[0342] A list of authorized V2X services and the transmission mode (transmission type) for each service, i.e., whether the service is broadcast-based, multicast-based, or unicast-based. The transmission mode of a service can be defined based on PLMN or PLMN group, or based on cell or cell group, or based on geographic area or geographic area group.

[0343] A list of authorized V2X services and, for each service, whether the transmission is connectionless or connection-oriented in the V2X upper layer. For example, a broadcast transmission may be connectionless, while a unicast or multicast transmission may be connection-oriented or connectionless in the V2X upper layer.

[0344] A list of authorized V2X services and, for each service, whether the transmission is connectionless at the AS layer or connection-oriented at the V2X AS layer. For example, a broadcast transmission can be connectionless, while a unicast or multicast transmission can be connection-oriented or connectionless at the AS layer.

[0345] Authorization to act as a scheduler or dispatching entity, or a local controller or dispatching node, for other UEs. This authorization can be defined on a PLMN or PLMN group basis, a cell basis, a cell group basis, a geographic area basis, or a geographic area group basis. In this disclosure, the terms local controller, dispatching entity, or dispatching entity are used interchangeably. For example, authorization to act as a dispatching entity can be provided to a fleet leader. This authorization can also be defined on a service basis or a service group basis.

[0346] • Authorization of the secondary UE to act as a scheduling entity. Such authorization can be defined on a PLMN or PLMN group basis, on a cell or cell group basis, or on a geographical area or geographical area group basis.

[0347] · Authorization for duplication across radio interfaces, i.e., transmission of the same data across two or more radio interfaces, e.g., across two or more of the following radio interfaces: NR sidelink interface, NR Uu interface, LTE sidelink interface, LTE Uu interface, WLAN sidelink interface, or WLAN to network interface. Such duplication may be defined based on reliability requirements (e.g., ProSe per-packet reliability value in case of a per-packet QoS model, or packet error rate or QoS identifier value in case of a QoS flow or bearer based QoS model). Such authorization may be defined on a per-service basis. Furthermore, such authorization may be defined on a per-cell or per-cell group basis, or on a per-geographical area or per-geographical area group basis, or on a per-PLMN or per-PLMN group basis. In the context of V2X, we denote the QoS identifier as V2X QoS Identifier (VQI).

[0348] · List of V2X QoS identifiers. For each VQI, corresponding QoS profile parameters may be configured. The QoS profile may include one or more of the following: priority (i.e., scheduling priority), payload, transmission rate, maximum end-to-end delay, reliability, data rate, minimum required communication range, preemption priority (i.e., admission preemption priority). In another alternative, the QoS profile may include one or more of the following: priority (i.e., scheduling priority), resource type (e.g., GBR, delay-critical GBR, or non-GBR), packet delay budget, packet error rate, average window, maximum data burst size. Such configuration may be defined on a per-PLMN or per-PLMN group basis, on a per-cell or per-cell group basis, or on a per-geographic area or per-geographic area group basis.

[0349] A list of QoS Flow Identifiers (QFIs). For each QFI, there is a mapping between the QFI and the VQI. QoS flows are the finest granularity for QoS differentiation. This configuration can be defined on a per-PLMN or per-PLMN group basis, per-cell or per-cell group basis, or per-geographic area or per-geographic area group basis.

[0350] Configuration of resource pools for connection-oriented transport and the signaling supporting these connections.

[0351] • Resource pool configuration for PC5 signaling or SL RRC signaling to support connection establishment and maintenance of the connection. This resource pool may be a shared resource pool also used for connectionless PC5 data transmission.

[0352] The various provisioning parameters defined above can be defined based on whether the UE is served by a radio access network or not. In addition, when not served by a radio access network, the provisioning parameters can be configured based on whether the carrier frequency used for V2X communication is operator-managed or non-operator-managed.

[0353] The UE may also be pre-configured (e.g. on the SIM or Mobile Equipment (ME)) with the following capability parameters:

[0354] Support for AS-based unicast transmission

[0355] Support for AS-based multicast transmission

[0356] Support for unicast transmission based on V2X UpL

[0357] Support for multicast transmission based on V2X UpL

[0358] Support for AS connectionless transmission

[0359] Support for AS connection-oriented transport

[0360] Support for packet duplication across radio interfaces

[0361] Support for capabilities as a scheduling entity

[0362] Support of the ability to assist UEs as a scheduler entity

[0363] Support for QoS flow-based QoS models, e.g., the ability to support a QoS model in which QoS flows are used to indicate QoS requirements for packets transmitted from the V2X upper layers to the V2X AS.

[0364] Support for per-packet QoS mode, e.g., the ability to support a QoS model where each packet transmitted from the V2X upper layers to the V2X AS carries its QoS requirements (e.g., PPPP or PPPR).

[0365] Transmitter-side triggering for V2X communication

[0366] exist Figure 12 In the context of the high-level diagram of V2X operations described in

[15] , one or more of the following events may trigger the V2X communication process including the connection establishment process in the UE:

[0367] A V2X packet is submitted by a V2X application for transmission. In this case, the process is triggered as a result of an event originating from the application layer;

[0368] Discovery is triggered by the application layer;

[0369] The communication quality of the current / existing V2X communication no longer meets the quality threshold. The quality threshold may be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.). In this case, the V2X upper layer of the V2X UE may initiate communication to another UE or another group of UEs in order to continue the V2X communication initiated by the application layer;

[0370] Radio link failure, beam failure, or beam failure recovery failure. In this case, the V2X upper layer of the V2X AS can initiate communication with another UE or another group of UEs to continue the V2X communication initiated by the application layer;

[0371] The radio link quality no longer meets the quality threshold;

[0372] Congestion is higher than the threshold;

[0373] The transmit power is higher than the threshold or the path loss is higher than the threshold;

[0374] The V2X upper layer of the V2X AS may initiate communication to another UE or another group of UEs in order to continue the mobility event of the V2X communication initiated by the application layer. The mobility event may be related to the UE's own mobility or may be related to the mobility of a peer UE;

[0375] • Receipt of a connection release, e.g. from a peer UE or from a scheduling entity controlling resource allocation to that UE;

[0376] • Receipt of a connection establishment request from a peer UE or from a scheduling entity controlling resource allocation to that UE;

[0377] • Receipt of a handover request from a peer UE or from a scheduling entity controlling resource allocation to that UE;

[0378] Failure of connection reconfiguration.

[0379] The V2X upper layer can trigger Figure 12 Similarly, the V2X AS layer can trigger Figure 12 V2X communication operations as described in.

[0380] RAT selection and interface selection on the transmitting side

[0381] The V2X upper layer may perform RAT selection or interface selection. The V2X upper layer may perform RAT selection and interface selection sequentially or concurrently. The V2X AS may provide auxiliary information such as availability information to the V2X upper layer for the selection of the RAT or interface. For example, the AS of the RAT may determine the availability of the RAT. In addition, the AS may determine the availability of interfaces related to a specific RAT. In an example embodiment, the RAT may be one or more of the following: NR RAT, LTE RAT, Wi-Fi, or WLAN RAT. Similarly, the interface may be one or more of the following: sidelink NR RAT, Uu RAT, sidelink LTE RAT, UuLTE RAT, sidelink Wi-Fi or WLAN RAT, and the radio interface between the WLAN and the network. The AS may determine the availability of the RAT or the availability of the interface associated with a specific RAT based on one or more of the following:

[0382] Communication quality threshold. The quality threshold can be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.);

[0383] Radio link quality threshold;

[0384] Congestion threshold. The congestion threshold may be related to, for example, the channel busy rate (CBR) and / or the channel occupancy rate (CR);

[0385] Radio link failure, beam failure, or failure of beam failure recovery;

[0386] Out of coverage or partially out of coverage detection;

[0387] Expected transmit power threshold or path loss threshold;

[0388] UE capabilities.

[0389] Availability information may include one or more of the following:

[0390] Available or unavailable;

[0391] Communication quality threshold;

[0392] Radio link quality threshold;

[0393] Congestion threshold;

[0394] Out of coverage or partially out of coverage detection;

[0395] UE capabilities.

[0396] Communication mode selection on the transmission side

[0397] The V2X upper layer can select a transmission type (i.e., broadcast vs. multicast vs. unicast) and indicate the selected transmission type to the V2X AS layer. The V2X upper layer can indicate the transmission type of each packet submitted to the AS layer to the V2X AS layer. This approach can be considered a per-packet transmission type indication from the V2X upper layer to the V2X AS layer. The V2X upper layer can use the per-packet transmission type indication, for example, in conjunction with a per-packet QoS specification. In an alternative embodiment, the V2X upper layer and the AS layer can specify a service access point (SAP) for each transmission type. For each example, for each transmission type (i.e., unicast, multicast, or broadcast), the AS layer exposes one or more transmission type-specific SAPs to the V2X upper layer. The V2X upper layer submits packets to the AS layer SAP according to the transmission type. The AS derives the packet's transmission type from the SAP through which the packet was submitted to the AS. The V2X AS layer transmits packets received through a specific V2X upper layer SAP according to the transmission broadcast type associated with the SAP through which the packet was received from the upper layer.

[0398] The V2X upper layer can establish a connection supporting a secure Layer 2 link and create a V2X upper layer context for this connection with an association between the source ID and the destination ID (including a security association). From the perspective of the V2X upper layer, the transmission can be connection-oriented, in which case the Layer 2 link connection context is maintained by the V2X upper layer, or connectionless, in which case no context is established and associated between the source and destination before the transmission begins. When a Layer 2 link connection exists, the V2X upper layer can indicate this to the V2X AS. The AS layer can decide to establish an AS-level connection and associate the context of this connection with the upper layer connection context in the UE. The AS context for the AS connection can include the connection-oriented AS protocol stack configuration and the security association between the source and destination. Alternatively, the AS may not establish an AS-level connection for a particular V2X upper layer connection. In this case, the SAP for the connection from the upper layer is submitted to the AS so that the transmitted upper layer packets can be transmitted in a connectionless manner at the AS level (e.g., via broadcast transmission at the AS level).

[0399] The V2X upper layer decides whether to use unicast, multicast, or broadcast transmission mechanisms.

[0400] The V2X upper layer may decide to use the transmission broadcast type based on one or more of the following:

[0401] Instructions from the application layer;

[0402] Communication quality threshold. The quality threshold can be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, scheduling priority, preemption priority, etc.);

[0403] Service type or traffic type, for example, signaling or application data;

[0404] Service authorization configuration;

[0405] ·ability;

[0406] Destination ID, or the number of destination UEs;

[0407] Configuration of the UE, including pre-configuration (e.g., ME, SIM), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types.

[0408] Link quality

[0409] The AS layer decides whether to use unicast, multicast, or broadcast transmission mechanisms.

[0410] The V2X AS layer may decide to use the transmission broadcast type based on one or more of the following:

[0411] Instructions from the V2X upper layer;

[0412] Communication quality threshold. The quality threshold can be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.);

[0413] Service type or traffic type (e.g., signaling or application data);

[0414] Service authorization configuration;

[0415] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.);

[0416] Destination ID or number of destination UEs;

[0417] Configuration of the UE, including pre-configuration (e.g., ME, SIM), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types;

[0418] Radio link quality.

[0419] The V2X upper layer decides whether to use a connection-oriented transmission or a connectionless transmission mechanism.

[0420] The V2X upper layer may decide whether to use connection-oriented or connectionless transmission based on one or more of the following:

[0421] Instructions from the application layer;

[0422] Communication quality threshold. The quality threshold can be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.);

[0423] Service type or traffic type (e.g., signaling or application data);

[0424] Service authorization configuration;

[0425] Capabilities, e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities;

[0426] Destination ID or number of destination UEs;

[0427] Configuration of the UE, including pre-configuration (e.g., ME, SIM, etc.), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types.

[0428] Link quality;

[0429] • Security requirements (eg, security thresholds). Security requirements may be requirements related to authentication, integrity, or encryption.

[0430] Next, we will explain how the AS layer decides whether to use connection-oriented or connectionless transmission. The V2X AS layer can decide whether to use the transmission broadcast type based on one or more of the following:

[0431] Instructions from the V2X upper layer;

[0432] Communication quality threshold. The quality threshold can be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.);

[0433] Service type or traffic type (e.g., signaling or application data);

[0434] Service authorization configuration;

[0435] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.);

[0436] Destination ID or number of destination UEs;

[0437] Configuration of the UE, including pre-configuration (e.g., ME, SIM, etc.) and network provisioning of the UE (e.g., configuration of the V2X control function or scheduling entity for the UE). Configuration may include mapping of services to transmission broadcast types;

[0438] Radio link quality;

[0439] • Security requirements (eg, security thresholds). Security requirements may be requirements related to integrity or encryption.

[0440] Receiver Operation

[0441] Figure 13 An example receiver-side high-level illustration of UE operations including the intermediate processes in the UE leading to the decision of whether to conduct V2X communication via AS broadcast, AS unicast, or AS multicast is provided in FIG.

[0442] In step S1300, the UE is either pre-configured (in the SIM or ME) or provided with information supporting V2X operations by a V2X control function located in the core network, i.e., a discovery process, whereby the UE discovers other devices for V2X communication and, in turn, communicates with the other V2X devices for V2X communication. Communication between the UE and the V2X control function for provisioning V2X operating parameters can occur via the user plane or the control plane. Provisioning parameters for NR V2X operation, particularly parameters supporting the reception of unicast or multicast communications, is described below in the section entitled "V2X Communication Provisioning on the Receiver Side." Upon triggering V2X communication in step S1302, the UE may synchronize, if not already synchronized, in step S1304. The UE may also perform discovery to identify a peer UE or group of UEs from which it can receive V2X communications. Outputs from the discovery process, such as the Layer 2 link IDs of the discovered UE or group of UEs, can be used by the UE in subsequent V2X operations, such as monitoring the reception of V2X communications, establishing connections to a specific UE or group of UEs, or configuring broadcast resources for receiving V2X communications. In steps S1306 and S1308, the UE performs RAT selection and interface (e.g., sidelink versus Uu interface) selection. Although steps S1306 and S1308 are listed as separate steps, these two steps can be performed concurrently, as described below in the section titled "Receiver-Side RAT Selection and Interface Selection." In step S1310, a determination is made as to whether the SL interface is selected. If so, a determination is made as to the SL reception mode (step S1312). If the SL reception mode is broadcast mode, AS configuration for broadcast reception is performed in step S1318. If the SL reception mode is unicast mode, Layer 2 link configuration for unicast reception is performed in step S1314. If the SL reception mode is multicast mode, then layer 2 link configuration for multicast reception is performed at step S1316. At step S1310, if the SL interface is not selected, configuration for reception over the Uu interface is initiated (step S1320).

[0443] Provisioning of V2X communications on the receiving side

[0444] To support unicast reception, multicast reception, broadcast reception, connection-oriented reception, or flow-based QoS, the NR V2X UE may be pre-configured or provisioned with the following system parameters; the configuration may be on a per-interface basis, such as the NR sidelink interface, NR Uu interface, LTE sidelink interface, LTE Uu interface, WLAN sidelink interface, or WLAN-to-network interface:

[0445] A list of authorized V2X services and the reception mode (reception broadcast type) for each service, i.e., whether the service is based on broadcast, multicast, or unicast reception; the reception mode of a service can be defined based on PLMN or PLMN group, or based on cell or cell group, or based on geographic area or geographic area group.

[0446] A list of authorized V2X services and, for each service, whether the reception is connectionless or connection-oriented at the V2X upper layer. For example, broadcast reception can be connectionless, while unicast or multicast reception can be connection-oriented or connectionless at the V2X upper layer.

[0447] A list of authorized V2X services and, for each service, whether the reception is connectionless at the AS layer or connection-oriented at the V2X AS layer. For example, broadcast reception can be connectionless, while unicast or multicast reception can be connection-oriented or connectionless at the V2X AS layer.

[0448] Authorization to act as a scheduler or dispatching entity, or a local controller or dispatching node, for other UEs. This authorization can be defined on a PLMN or PLMN group basis, a cell basis, a cell group basis, a geographic area basis, or a geographic area group basis. In this disclosure, the terms local controller, dispatching entity, or dispatching entity are used interchangeably. For example, authorization to act as a dispatching entity can be provided to a fleet leader. This authorization can also be defined on a service basis or a service group basis.

[0449] • Authorization of the secondary UE to act as a scheduling entity. Such authorization can be defined on a PLMN or PLMN group basis, on a cell or cell group basis, or on a geographical area or geographical area group basis.

[0450] Authorization for repeated reception across radio interfaces, i.e., reception of the same data across two or more radio interfaces, e.g., across two or more of the following radio interfaces: NR sidelink interface, NR Uu interface, LTE sidelink interface, LTE Uu interface, WLAN sidelink interface, or WLAN to network interface. Such repetition may be defined based on reliability requirements (e.g., ProSe per-packet reliability value in the case of a per-packet QoS model, or packet error rate or QoS identifier value in the case of a QoS flow or bearer based QoS model). Such authorization may be defined on a per-service basis. Furthermore, such authorization may be defined on a per-cell or per-cell group basis, or on a per-geographical area or per-geographical area group basis, or on a per-PLMN or per-PLMN group basis. In the context of V2X, we denote the QoS identifier as V2X QoS Identifier (VQI).

[0451] · List of V2X QoS identifiers. For each VQI, corresponding QoS profile parameters may be configured. The QoS profile may include one or more of the following: priority (i.e., scheduling priority), payload, transmission rate, maximum end-to-end delay, reliability, data rate, minimum required communication range, preemption priority (i.e., admission preemption priority). In another alternative, the QoS profile may include one or more of the following: priority (i.e., scheduling priority), resource type (e.g., GBR, delay-critical GBR, or non-GBR, etc.), packet delay budget, packet error rate, average window, maximum data burst size. Such configuration may be defined on a per-PLMN or per-PLMN group basis, on a per-cell or per-cell group basis, or on a per-geographic area or per-geographic area group basis.

[0452] A list of QoS Flow Identifiers (QFIs). For each QFI, there is a mapping between the QFI and the VQI. QoS flows are the finest granularity for QoS differentiation. This configuration can be defined on a per-PLMN or per-PLMN group basis, per-cell or per-cell group basis, or per-geographic area or per-geographic area group basis.

[0453] • Resource pool configuration for connection-oriented reception and signaling to support maintenance of these connections.

[0454] • Resource pool configuration for PC5 signaling or SL RRC signaling that supports the reception of signaling for connection establishment and maintenance of that connection. This resource pool may be a shared resource pool that is also used for connectionless PC5 data transmission.

[0455] The various provisioning parameters defined above can be defined based on whether the UE is served by a radio access network or not. In addition, when not served by a radio access network, the provisioning parameters can be configured based on whether the carrier frequency used for V2X communication is operator-managed or non-operator-managed.

[0456] The UE may also be pre-configured (e.g. on the SIM or Mobile Equipment (ME)) with the following capability parameters:

[0457] Support for AS-based unicast reception;

[0458] Support for AS-based multicast reception;

[0459] Support for unicast reception based on V2X UpL;

[0460] Support for multicast reception based on V2X UpL;

[0461] Support for AS connectionless reception;

[0462] Support for AS connection-oriented reception;

[0463] Support for duplicate reception of packets across radio interfaces

[0464] Support for the ability to act as a scheduling entity.

[0465] Support of the ability to assist UEs as a scheduler entity

[0466] Support for QoS flow-based QoS specifications, e.g., the ability to support a QoS model in which the V2X AS layer supports mapping of packets from radio bearers to QoS flow SAPs when it delivers received packets to the V2X upper layers.

[0467] Support for per-packet QoS mode, e.g., the ability to support a QoS model where each packet transmitted from the V2X AS to the V2X upper layers carries its QoS requirements (e.g., PPPP or PPPR).

[0468] Receiver-side triggering for V2X reception

[0469] exist Figure 13 In the context of the high-level diagram of V2X receive operations described in

[15] , one or more of the following events may trigger a V2X receive process, including monitoring for connection management related messages, such as the receipt of a connection establishment message:

[0470] A trigger for transmission from a V2X application. In this case, the process is triggered as a result of an event originating from the application layer;

[0471] Discovery is triggered by the application layer;

[0472] Regular monitoring of reception on the V2X reception resource pool

[0473] The communication quality of the current / existing V2X communication no longer meets a quality threshold. The quality threshold may be associated with one or more QoS profile metrics (e.g., packet error rate, latency, reliability, communication range, etc.). In this case, the V2X upper layer of the V2X AS may initiate communication with another UE or another group of UEs to continue receiving the V2X communication initiated by the application layer. For example, if the UE is a formation leader, then upon detecting that the V2X reception quality no longer meets the quality threshold, the UE may initiate communication with another formation leader UE.

[0474] Radio link failure, beam failure, or beam failure recovery failure. In this case, the V2X upper layer of the V2X AS may initiate reception of communication to another UE or another group of UEs in order to continue the V2X communication initiated by the application layer;

[0475] The radio link quality of the current / existing V2X communication no longer meets the quality threshold;

[0476] The congestion of current / existing V2X communications is above a threshold;

[0477] The transmit power of the current / existing V2X communication is higher than a threshold or the path loss is higher than a threshold.

[0478] The V2X upper layer of the V2X AS may initiate the reception of V2X communications to another UE or another group of UEs in order to continue the mobility event of the V2X communications initiated by the application layer. The mobility event may be related to the UE's own mobility or may be related to the mobility of a peer UE;

[0479] • Receipt of a connection release, e.g. from a peer UE or from a scheduling entity controlling resource allocation to that UE;

[0480] • Receipt of a connection establishment request from a peer UE or from a scheduling entity controlling resource allocation to that UE;

[0481] • Receipt of a handover request from a peer UE or from a scheduling entity controlling resource allocation to that UE;

[0482] Failure of connection reconfiguration for current / existing V2X communications.

[0483] The V2X upper layer can trigger Figure 13 Similarly, the V2X AS layer can trigger the reception of the V2X communication operation described in Figure 13 Reception of V2X communication operations illustrated in FIG.

[0484] RAT selection and interface selection on the receiver side

[0485] Similar to the transmitter-side operations described above, the V2X upper layers may perform RAT selection or interface selection. In one embodiment, the receiver-side RAT of a given UE may be the same as the transmitter-side RAT, i.e., set to the same as the transmitter-side RAT. Similarly, the receiver-side interface may be the same as the transmitter-side interface, i.e., set to the same as the transmitter interface. In another embodiment, the receiver-side RAT may be different from the transmitter-side RAT. Similarly, the receiver-side interface may be different from the transmitter-side interface. The V2X upper layers may perform RAT selection and interface selection sequentially or concurrently. The V2X AS may provide auxiliary information, such as availability information, to the V2X upper layers for RAT or interface selection. For example, the AS for a RAT may determine the availability of that RAT. Additionally, the AS may determine the availability of interfaces associated with a specific RAT. In example embodiments, the RAT may be one or more of the following: NR RAT, LTE RAT, Wi-Fi RAT, etc. Similarly, the interface may be one or more of the following: sidelink NR RAT, Uu RAT, sidelink LTE RAT, Uu LTE RAT, sidelink Wi-Fi RAT, and the radio interface between Wi-Fi and the network. The AS may determine the availability of a RAT or an interface associated with a particular RAT for V2X reception based on one or more of the following:

[0486] Communication quality threshold. The quality threshold can be related to one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.);

[0487] Radio link quality threshold;

[0488] Congestion threshold. The congestion threshold can be related to, for example, the channel busy rate (CBR), channel occupancy rate (CR), etc.

[0489] Radio link failure or beam failure or failure of beam failure recovery.

[0490] Out of coverage or partially out of coverage detection;

[0491] Expected receive power threshold or path loss threshold;

[0492] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.).

[0493] Availability information may include one or more of the following:

[0494] Available or unavailable;

[0495] Communication quality threshold

[0496] Radio link quality threshold

[0497] Congestion threshold

[0498] Out of coverage or partially out of coverage detection

[0499] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.).

[0500] Receiver side link communication mode selection

[0501] This section describes how the V2X upper layer determines whether to use unicast, multicast, or broadcast for V2X reception. The V2X upper layer may determine the type of reception based on one or more of the following:

[0502] Instructions from the application layer;

[0503] An indication from a peer V2X UE transmitter, for example as part of a connection establishment procedure or other connection management procedure (such as a connection reconfiguration procedure);

[0504] Communication quality threshold. The quality threshold may be associated with one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.). For example, a formation group member UE may decide to request switching from multicast communication to unicast communication based on the communication reception quality threshold, or may decide to switch to receiving communication from another member UE acting as a relay UE based on unicast communication.

[0505] Service type or traffic type, for example, signaling or application data;

[0506] Service authorization configuration;

[0507] Capabilities, such as UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.

[0508] Configuration of the UE, including pre-configuration (e.g., ME, SIM, etc.), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types.

[0509] Link quality

[0510] The AS layer decides whether to use unicast, multicast, or broadcast transmission mechanisms.

[0511] The V2X AS layer may decide to use the receive broadcast type based on one or more of the following:

[0512] Instructions from the V2X upper layer;

[0513] An indication from a peer V2X UE transmitter, for example as part of a connection establishment procedure or other connection management procedure (such as a connection reconfiguration procedure);

[0514] Communication quality threshold. The quality threshold may be associated with one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.). For example, a formation group member UE may decide to request switching from multicast communication to unicast communication based on the communication reception quality threshold, or may decide to switch to receiving communication from another member UE acting as a relay UE based on unicast communication.

[0515] Service type or traffic type, for example, signaling or application data;

[0516] Service authorization configuration;

[0517] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.);

[0518] Configuration of the UE, including pre-configuration (e.g., ME, SIM, etc.), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types;

[0519] Radio link quality;

[0520] The V2X upper layer decides whether to use a connection-oriented reception or a connectionless reception mechanism.

[0521] The V2X upper layer may decide whether to use connection-oriented or connectionless reception based on one or more of the following:

[0522] Instructions from the application layer;

[0523] An indication from a peer V2X UE transmitter, for example as part of a connection establishment procedure or other connection management procedure (such as a connection reconfiguration procedure);

[0524] Communication quality threshold. The quality threshold may be associated with one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.); for example, a formation group member UE may decide to request switching from connectionless reception to connection-oriented reception based on the quality threshold, or may decide to switch to receiving communication from another member UE acting as a relay UE based on connection-oriented reception.

[0525] Service type or traffic type, for example, signaling or application data;

[0526] Service authorization configuration;

[0527] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.);

[0528] Configuration of the UE, including pre-configuration (e.g., ME, SIM, etc.), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types.

[0529] Link quality

[0530] Security requirements, such as security thresholds. Security requirements can be related to authentication, integrity, or encryption.

[0531] The AS layer decides whether to use a connection-oriented or connectionless reception mechanism.

[0532] The V2X AS layer may decide to use the transmission broadcast type based on one or more of the following:

[0533] Instructions from the V2X upper layer;

[0534] An indication from a peer V2X UE transmitter, for example as part of a connection establishment procedure or other connection management procedure (such as a connection reconfiguration procedure);

[0535] Communication quality threshold. The quality threshold may be associated with one or more QoS profile indicators (e.g., packet error rate, latency, reliability, communication range, etc.). For example, a formation group member UE may decide to request a switch from connectionless reception to connection-oriented reception based on the quality threshold, or may decide to switch to receiving communications from another member UE acting as a relay UE based on connection-oriented reception.

[0536] Service type or traffic type, for example, signaling or application data;

[0537] Service authorization configuration;

[0538] Capabilities (e.g., UE capabilities, peer V2X UE capabilities, scheduling entity capabilities, gNB or network capabilities, etc.);

[0539] Configuration of the UE, including pre-configuration (e.g., ME, SIM, etc.), network (e.g., V2X control function) provisioning of the UE, or configuration of the UE by a scheduling entity. Configuration may include mapping of services to transmission broadcast types;

[0540] Radio link quality;

[0541] Security requirements, such as security thresholds. Security requirements can be requirements related to integrity or encryption.

[0542] Unicast connection management

[0543] Advanced unicast connection management process

[0544] Figure 14 This is a high-level diagram of transmitter-side operations for unicast Layer 2 link management, including connection establishment. In step S1400, a determination is made as to whether the AS is connection-oriented. Steps S1402 and S1410 involve unicast connection establishment and connection context association in the V2X upper layer (V2X UpL) between peer V2X UEs. As shown in step S1404, prior to the transmission of unicast packets, a unicast connection may also be established in the AS layer through connection establishment signaling between peer V2X UEs for configuration and association of an AS context between the peer V2X UEs. In this case, the receiver in the peer V2X UE is configured with dedicated configuration, possibly including dedicated radio resource configuration for unicast reception, taking into account the UE capabilities of the receiving UE. As part of the unicast connection establishment process, the UE may associate the unicast AS context with the corresponding V2X upper layer unicast context. In the alternative embodiment illustrated in step S1410, the AS may support V2X upper layer unicast connections through an AS connectionless configuration. In this case, the AS is configured in an AS connectionless manner, where AS resources are configured in a connectionless manner without taking into account, for example, the UE capabilities of the receiving UE. In this case, no signaling for receiving UE configuration is required prior to V2X packet reception. The receiving AS is configured with common default parameters for V2X packet reception, and from the perspective of the AS MAC, the transmitting party transmits packets in a broadcast manner, with received packets filtered based on the source and destination IDs encapsulated in the received MAC PDU. For the connection-oriented AS resource configuration described in step S1404, before data packet transmission occurs, the PHY, MAC, RLC, PDCP, and SDAP (where applicable) are configured for that specific connection in both the receiving and transmitting UEs. Prior to data packet transmission, an AS context is created in both the transmitting and receiving UEs, consisting of configurations such as PHY channel configuration (possibly including radio resource configuration), transport channel configuration, HARQ entity configuration, logical channel configuration, bearer configuration (possibly including security configuration), QoS flow configuration, and the association of these configurations between the AS protocol sublayers. Once step S1402 and step S1404 or step S1410 and step S1412 are completed, the transmitting UE and the receiving UE may exchange packets (data or signaling) in a connection-oriented communication manner.

[0545] Step S1406 involves link monitoring in the case of a connection-oriented AS. Link monitoring can be implemented in the AS, for example, based on radio link monitoring and beam management procedures. Link monitoring can trigger the execution of connection maintenance procedures such as connection reconfiguration, beam recovery, connection relocation, or connection release. The link maintenance procedure can be triggered by the transmitting UE, the receiving UE, or a third entity such as a scheduling entity. In the case of connectionless AS communication, the link monitoring mentioned in step S1414 can be implemented in the V2X upper layer, for example, based on the link keepalive procedure performed by the V2X upper layer. In this case, link monitoring can trigger the execution of reconfiguration, connection relocation, or connection release on the transmitting side. Alternatively, in this case, the link maintenance procedure can be triggered by the transmitting UE, the receiving UE, or a third entity such as a scheduling entity. In step S1408, the link is released. In step S1416, the link is released.

[0546] Figure 15 A high-level diagram of receiver-side operations, including Layer 2 link management for connection establishment, is provided. In step S1500, a determination is made as to whether the AS is connection-oriented. If so, in step S1502, V2X upper layer configuration is performed for Layer 2 unicast link connection establishment. If not, in step S1510, V2X upper layer configuration is performed for Layer 2 unicast link connection establishment. In step S1512, V2X SL RX AS configuration is performed for Layer 2 unicast link connection establishment—either pre-configured or based on public signaling or non-signaling. In step S1514, link monitoring and maintenance are performed in the V2X upper layer. In step S1516, link release is performed. In step S1504, V2X SL RX AS configuration is performed for Layer 2 unicast link connection establishment—based on dedicated signaling. In step S1506, link monitoring and maintenance are performed in the AS. In step S1508, link release is performed.

[0547] Detailed process of establishing a unicast connection

[0548] Figures 16, 17, 18, 19, 20 and 21 provide different alternative embodiments of detailed process steps to support unicast connection establishment and subsequent data transmission. Figure 14 and Figure 15. The process is built around three entities. An initiating UE (I-UE), which is the UE that initiates the connection establishment procedure, a target UE (T-UE), which is the final recipient UE of the connection establishment request, and a scheduling entity, which is the entity that provides resource configuration or resource scheduling functionality. The scheduling entity can be a gNB, a UE that controls or assists in resource configuration for other UEs, an RSU-UE (i.e., a roadside unit (RSU) that acts as a UE), an RSU-gNB (i.e., an RSU that acts as a gNB), a UE-to-network relay (i.e., an entity that acts as a relay node for other UEs (e.g., an IAB node)), or any other local controller that provides resource configuration to the UEs under its control. In the remainder of this disclosure, we will further expand the definitions of I-UE and T-UE as follows: a T-UE with respect to a configuration procedure over an interface (e.g., a PC5 interface or a Uu interface) is a UE that is the recipient UE of a configuration request. The I-UE with respect to the configuration procedure over an interface (eg, PC5 interface or Uu interface) is the UE that transmits the configuration request. The configuration request may be one or more of: connection establishment request, connection reconfiguration or modification, connection relocation, or connection release.

[0549] These figures also assume that Figure 12 and Figure 13 With respect to resource allocation, each of these figures further proposes that after both the T-UE and the I-UE are configured with radio resource configurations via RRC signaling or PC5-S signaling, the T-UE may select autonomous resources for transmission, or may be dynamically scheduled by a scheduling entity or the I-UE. Similarly, the I-UE may select autonomous resources for transmission, or may be dynamically scheduled by a scheduling entity or the T-UE.

[0550] Figure 16A Figure C illustrates the steps for connection establishment, where the T-UE is configured by the I-UE or by the I-UE in collaboration with a scheduling entity. Furthermore, in this embodiment of the connection establishment process, the T-UE's V2X upper layer configuration is carried along with the T-UE's AS layer configuration from the I-UE to the T-UE using SL RRC signaling.

[0551] Figure 16A-C includes a target UE / RSU UP stack 1602, a target UE / RSU RRC 1604, a target UE / RSU-V2X higher layer function 1606, an initiating UE / RSU RRC 1608, an initiating UE / RSU UP stack 1610, an initiating UE / RSU-V2X higher layer function 1612, and a gNB / RSU / scheduling entity 1614. At step S1600, direct communication is transmitted from the UE / RSU-V2X higher layer function 1612. At step S1602, an SL RRC signaling - target device information request is transmitted from the initiating UE / RSU RRC 1608. At step S1604, an upper layer information request is transmitted from the target UE / RSU RRC 1604. At step S1606, an upper layer information response is transmitted from the target UE / RSU-V2X higher layer function 1606. At step S1608, the target UE / RSU RRC 1604 sends an SL RRC Signaling-Target Device Information Response. At step S1610, the initiating UE / RSU RRC 1608 sends an RRC Signaling-Direct Security Mode Command. At step S1612, resource allocation may be performed. At optional step S1614, the connection establishment criteria may be verified, and a connection may be established if necessary; otherwise, resource allocation may be performed. At step S1610a, security procedures may be performed.

[0552] At step S1616, the initiating UE / RSU RRC 1608 sends an RRC Signaling V2X Connection Configuration Information Request. At step S1618, admission control and a decision regarding SL transmission configuration parameters are performed. At step S1620, the gNB / RSU / scheduling entity 1614 sends an RRC Signaling V2X Signaling Information Response. At step S1622, the target UE / RSU RRC 1604 sends an RRC Signaling Direct Security Mode Complete message. At step S1624, the initiating UE / RSU RRC 1608 sends an SL RRC Signaling Direct Communication Request.

[0553] In step S1628, upper layer configuration information is sent. In step S1630, the T-UE protocol stack is configured. In step S1632, a SL RRC Signaling - Direct Communication Accept message is sent. In step S1634, an SR / BSR message is sent. In step S1636, SL resource grant DCI information is sent from the gNB / RSU / scheduling entity 1614. In optional step S1638, the initiating UE / RSU UP stack 1610 may send the SL resource grant DCI information to the target UE / RSU UP stack 1602. In an alternative embodiment, steps S1640 and S1642 are performed. In step S1640, an SR / BSR is sent from the target UE / RSU UP stack 1602 to the initiating UE / RSU UP stack 1610, and then in step S1642, the initiating UE / RSU UP stack 1610 sends the SL resource grant DCI information to the target UE / RSU UP stack 1602. In another alternative embodiment, steps S1644 and S1646 are performed. In step S1644, an SR / BSR is sent from the target UE / RSU UP stack 1602 to the gNB / RSU / scheduling entity 1614. Then, in step S1646, the gNB / RSU / scheduling entity 1614 sends SL resource grant DCI information to the target UE / RSU UP stack 1602. In step S1648, SL data reception or transmission may occur. In step S1650, reception or transmission may occur. In step S1652, radio link monitoring may be performed. In step S1654, the radio link may be released.

[0554] Figure 17A -C illustrates the steps for connection establishment, where the T-UE is configured by the I-UE or by the I-UE in collaboration with the scheduling entity. In addition, in this embodiment of the connection establishment process, the V2X upper layer configuration of the T-UE and the AS layer configuration of the T-UE are carried from the I-UE to the T-UE using PC5 signaling. Figure 17A -C, steps S1600, S1602, S1604, S1606, S1608, S1610, S1610a, S1612, S1614, S1616, S1618, S1620, and S1622 are Figure 16A-C. In step S1656, AS SL configuration information is transmitted. In step S1658, PC5 signaling - direct communication request is performed. In step S1660, AS SL configuration information is transmitted. In step S1662, the I-UE protocol stack is configured. In step S1664, the T-UE protocol stack is configured. In step S1666, PC5 signaling - direct communication acceptance is performed. In step S1668 (which may be optional), for example, to support Mode 2-d or Mode 2-b resource allocation, an SR / BSR may be sent to the gNB / RSU / scheduling entity 1614. In step S1670 (which may also be optional), a SL resource grant DCI may be sent from the gNB / RSU / scheduling entity 1614. In step 1672 (which may also be optional), a SL resource grant DCI is sent from the initiating UE / RSU UP stack 1610. Steps S1674 and S1676 represent Alternative Solution 1, while steps S1678 and S1680 represent Alternative Solution 2. In step S1674, an SR / BSR is sent from the target UE / RSU UP stack 1602. In step S1676, a SL resource grant (SCI) is sent from the initiating UE / RSU UP stack 1610. In step S1678, an SR / BSR is sent from the target UE / RSU UP stack 1602 to the gNB / RSU / scheduling entity 1614. In step S1680, a SL resource grant (SCI) is sent from the gNB / RSU / scheduling entity 1614 to the target UE / RSU UP stack 1602. In step S1682, SL data reception or transmission is performed. In step S1684, SL data reception or transmission is performed. In step S1686, radio link monitoring is performed. In step S1688, radio link release is performed.

[0555] Figure 18AFigure C illustrates the steps for connection establishment, where the T-UE is configured by the I-UE or by the I-UE in collaboration with a scheduling entity. Furthermore, in this embodiment of the connection establishment process, the T-UE's V2X upper layer configuration and the T-UE's AS layer configuration are carried from the I-UE to the T-UE using RRC signaling. Furthermore, the V2X upper layer connection establishment process is performed independently of the V2X AS layer connection establishment process. In step S1800, the initiating UE / RSU-V2X higher layer function 1612 sends a PC5 Signaling - Direct Communication Request. In step S1802, the target UE / RSU-V2X higher layer function 1606 sends a PC5 Signaling - Direct Security Mode Command. In step S1806, the target UE / RSU-V2X higher layer function 1606 sends a PC5 Signaling - Direct Communication Acceptance message. In step S1808, direct communication is established. Steps S1810, S1812, S1814, and S1816 are optional. At step S1810, the initiating UE / RSU RRC 1608 sends a SL RRC Signaling-Target Device Information Request. At step S1812, the target UE / RSU RRC 1604 sends an Upper Layer Information Request. At step S1814, the target UE / RSU-V2X higher layer function 1606 sends an Upper Layer Information Response. At step S1816, the target UE / RSU RRC 1604 sends a SL RRC Signaling-Target Device Information Response. At step S1818, resource allocation may be performed (Alternative 1). Steps S1820, S1822, S1824, and S1826 are Alternative 2. At step S1820 (which may be optional), the criteria for connection establishment are verified and a connection is established if necessary; otherwise, resource allocation is performed. At step S1822, the initiating UE / RSU RRC 1608 sends an RRC Signaling V2X Connection Configuration Information Request. In step S1824, admission control and decision-making regarding SL transmission configuration parameters are performed. In step S1826, an RRC signaling V2X signaling configuration information response is sent from the gNB / RSU / scheduling entity 1614.

[0556] In step S1828, SL RRC signaling - Direct AS connection request is sent from the initiating UE / RSU RRC 1608. In step S1830, the I-UE protocol stack is configured. In step S1832, upper layer configuration is performed. In step S1834, the T-UE protocol stack is configured. In step S1836, SL RRC signaling - Direct AS connection acceptance signal is sent. Steps S1838 and S1840 are optional. In step S1838, SR / BSR is sent from the initiating UE / RSU UP stack 1610. In step S1840, the initiating UE / RSU UP stack 1610 receives SL resource grant DCI. Alternative 1 includes optional steps S1842, S1844 and S1846. In step S1842, the target UE / RSU UP stack 1602 receives the SL resource grant DCI. In step S1844, the target UE / RSU UP stack 1602 sends an SR / BSR. In step S1846, the target UE / RSU UP stack 1602 receives a SL resource grant (SCI). Alternative 2 includes optional steps S1848 and S1850. In step S1848, the target UE / RSU UP stack 1602 sends an SR / BSR to the gNB / RSU / scheduling entity 1614. In step S1850, the target UE / RSU UP stack 1602 receives a SL resource grant (DCI). In step S1852, the target UE / RSU UP stack 1602 performs SL data reception or transmission. In step S1854, the initiating UE / RSU UP stack 1610 performs SL data reception or transmission. In step S1856, radio link monitoring is performed. In step S1858, the radio link is released.

[0557] Figure 19A Figure C illustrates the steps for connection establishment, where the I-UE is configured by the T-UE or by the T-UE in collaboration with a scheduling entity. Furthermore, in this embodiment of the connection establishment process, the I-UE's V2X upper layer configuration and the I-UE's AS layer configuration are carried together from the T-UE to the I-UE using PC5-S signaling. Furthermore, the V2X upper layer connection establishment process is performed independently of the V2X AS layer connection establishment process.

[0558] Figure 19AFigure C shows the initiating / RSU UP stack 1902, the initiating UE / RSU RRC 1904, the initiating UE / RSU-V2X higher layer function 1906, the target UE / RSU RRC 1908, the target UE / RSU UP stack 1910, the target UE / RSU-V2X higher layer function 1912, and the gNB / RSU / scheduling entity 1614. In step S1900, a PC5 signaling-direct communication request is sent. In step S1902, a PC5 signaling-direct security mode command is sent. In step S1904, a PC5 signaling-direct mode response complete message is sent. In step S1906, a PC5 signaling-direct communication accept message is sent. In step S1908, direct communication is established. In step S1910, a direct AS connection request is sent. In step S1912, the initiating UE / RSU-V2X higher layer function 1906 sends a PC5 signaling direct AS connection request to the target UE / RSU-V2X higher layer function 1912. In step S1914, a direct AS connection resource request is sent. In step S1916 (Alternative 1), resource allocation is performed. Alternative 2 may include steps S1918, S1920, S1922, and S1924. In step S1918 (optional), the connection establishment criteria are verified and a connection is established if necessary. Otherwise, resource allocation is performed. In step S1920, an RRC signaling V2X connection configuration information request is sent. In step S1922, admission control and decision-making for SL transmission configuration parameters are performed. In step S1924, an RRC signaling V2X signaling configuration information response is sent. In step S1926, a direct AS connection resource response is sent.

[0559] In step S1928, a PC5 Signaling - Direct AS Connection Accept message is sent. In step S1930, a Direct AS Connection Accept message is sent. In step S1932, the T-UE protocol stack is configured. In step S1934, the I-UE protocol stack is configured. Steps S1936 and S1938 are optional. In step S1936, an SR / BSR is sent from the target UE / RSU RRC 1908 to the gNB / RSU / scheduling entity 1614. In step S1938, a SL Resource Grant DCI is sent from the gNB / RSU / scheduling entity 1614 to the target UE / RSU UP stack 1910. Steps S1940, S1942, and S1944 are also optional steps for Alternative 1, while steps S1946 and S1948 are optional steps for Alternative 2. In step S1940, an SL Resource Grant DCI message is sent. In step S1942, an SR / BSR is sent. In step S1944, a SL resource grant (SCI) is sent. In alternative 2, in step S1946, an SR / BSR is sent from the initiating / RSU UP stack 1902 to the gNB / RSU / scheduling entity 1614. In step S1948, a SL resource grant (DCI) is sent from the gNB / RSU / scheduling entity 1614 to the initiating / RSU UP stack 1902. In step S1950, the initiating / RSU UP stack 1902 performs SL data reception or transmission. In step S1952, the target UE / RSU UP stack 1910 performs SL data reception or transmission. In step S1954, radio link monitoring is performed. In step S1956, the radio link is released.

[0560] Figure 20A Figure C illustrates the steps for connection establishment, where the I-UE is configured by the T-UE or by the T-UE in collaboration with a scheduling entity. Furthermore, in this embodiment of the connection establishment process, the I-UE's V2X upper layer configuration is carried along with the I-UE's AS layer configuration from the T-UE to the I-UE using PC5-S signaling.

[0561] Figure 20A-C represents the initiating UE / RSU UP stack 2002, the initiating UE / RSU RRC 1904, the initiating UE / RSU-V2X higher layer function 1906, the target UE / RSU RRC 1908, the target UE / RSU UP stack 1910, the target UE / RSU-V2X higher layer function 1912, and the gNB / RSU / scheduling entity 1614. In step S2000, a direct communication AS information request is sent from the initiating UE / RSU-V2X higher layer function 1906 to the initiating UE / RSU RRC 1904. In step S2002, a direct communication AS information response is sent from the initiating UE / RSU RRC 1904 to the initiating UE / RSU-V2X higher layer function 1906. In step S2004, SL PC5 signaling - direct communication request is sent from the initiating UE / RSU-V2X higher layer function 1906 to the target UE / RSU-V2X higher layer function 1912. In step S2006 , a direct communication AS information request is sent from the target UE / RSU-V2X higher layer function 1912 to the target UE / RSU RRC 1908 .

[0562] Steps S2008, S2010, S2012, S2014, and S2016 may be optional. In step S2008 (Alternative 1), resource allocation may be performed. Alternative 2 consists of steps S2010, S2012, S2014, and S2016. In step S2010, the criteria for establishing a connection are verified and, if necessary, a connection is established; otherwise, resource allocation is performed. In step S2012, an RRC signaling V2X connection configuration information request is sent from the target UE / RSU RRC 1908. In step S2014, admission control and a decision regarding SL transmission configuration parameters are performed. In step S2016, an RRC signaling V2X signaling configuration information response is sent from the gNB / RSU / scheduling entity 1614 to the target UE / RSU RRC 1908. At step S2018, the target UE / RSU RRC 1908 sends an RRC Signaling Direct Security Mode Command to the initiating UE / RSU RRC 1904. At step S2018a, security procedures may be performed. At step S2020, the initiating UE / RSU RRC 1904 sends an RRC Signaling Direct Security Mode Complete message to the target UE / RSU RRC 1908. At step S2022, the target UE / RSU RRC 1908 sends a Direct Communication AS Information Response to the target UE / RSU-V2X higher layer function 1912.

[0563] In step S2024, the T-UE protocol stack is configured. In step S2026, a SL PC5 Signaling - Direct Communication Accept message is sent from the target UE / RSU-V2X higher layer function 1912 to the initiating UE / RSU-V2X higher layer function 1906. In step S2028, an AS Layer Configuration Information Transfer message is sent from the initiating UE / RSU-V2X higher layer function 1906 to the initiating UE / RSU RRC 1904. In step S2030, the I-UE protocol stack is configured. Steps S2032 and S2034 are optional. In step S2032, an SR / BSR is sent from the target UE / RSU UP stack 1910 to the gNB / RSU / scheduling entity 1614. In step S2034, a SL Resource Grant DCI is sent from the gNB / RSU / scheduling entity 1614 to the target UE / RSU UP stack 1910.

[0564] In step S2036 (optional), a SL resource grant DCI may be sent from the target UE / RSU UP stack 1910 to the initiating UE / RSU UP stack 2002. Steps S2038 and S2040 are optional steps and represent Alternative 1. In step S2038, an SR / BSR is sent from the initiating UE / RSU UP stack 2002 to the target UE / RSU UP stack 1910. In step S2040, an SL resource grant SCI is sent from the target UE / RSU UP stack 1910 to the initiating UE / RSU UP stack 2002. In Alternative 2, in step S2042, an SR / BSR is sent from the initiating UE / RSU UP stack 2002 to the gNB / RSU / scheduling entity 1614. In step S2044, the gNB / RSU / scheduling entity 1614 sends the SL resource grant DCI to the initiating UE / RSU UP stack 2002. In step S2046, sidelink data transmission or reception is performed. In step S2048, sidelink data transmission or reception is performed. In step S2050, radio link monitoring is performed. In step S2052, radio link release is performed.

[0565] Figure 21A Figure C illustrates the steps for connection establishment, where the I-UE is configured by the T-UE or by the T-UE in collaboration with a scheduling entity. Furthermore, in this embodiment of the connection establishment process, the I-UE's V2X upper layer configuration and the I-UE's AS layer configuration are carried from the T-UE to the I-UE using RRC signaling.

[0566] At step S2100, a direct communication request is sent from the initiating UE / RSU-V2X higher layer function 1906 to the initiating UE / RSU RRC 1904. At step S2102, SL RRC Signaling - Direct Communication Request is sent from the initiating UE / RSU RRC 1904 to the target UE / RSU RRC 1908. At step S2104, a direct communication V2X UPL Information Request is sent from the target UE / RSU RRC 1908 to the target UE / RSU-V2X higher layer function 1912. At step S2106, a direct communication V2X UPL Information Response is sent from the target UE / RSU-V2X higher layer function 1912 to the target UE / RSU RRC 1908. At step S2108 (Alternative 1), resources are allocated. Alternative 2 includes steps S2110, S2112, S2114, and S2116. In step S2110 (optional), the connection establishment criteria are verified and a connection is established if necessary. Otherwise, resource allocation is performed. In step S2112, an RRC Signaling V2X Connection Configuration Information Request is sent from the target UE / RSU RRC 1908 to the gNB / RSU / scheduling entity 1614. In step S2114, admission control and decisions regarding SL transmission configuration parameters may be performed. In step S2116, the gNB / RSU / scheduling entity 1614 sends an RRC Signaling V2X Signaling Configuration Information Response to the target UE / RSU RRC 1908. In step S2118, an RRC Signaling Direct Security Mode Command is sent from the target UE / RSU RRC 1908 to the initiating UE / RSU UP stack 2002. In step S2118a, security procedures are performed. At step S2120 , an RRC signaling-direct security mode complete message is sent from the initiating UE / RSU RRC 1904 to the target UE / RSU RRC 1908 .

[0567] In step S2122, the T-UE protocol stack is configured. In step S2124, a SL RRC Signaling - Direct Communication Accept message is sent from the target UE / RSU RRC 1908 to the initiating UE / RSU RRC 1904. In step S2126, the I-UE protocol stack is configured. In step S2128 (optional), an SR / BSR is sent from the target UE / RSU UP stack 1910 to the gNB / RSU / scheduling entity 1614. In step S2130, the gNB / RSU / scheduling entity 1614 sends a SL Resource Grant DCI message to the target UE / RSU UP stack 1910. In step S2132 (optional), the target UE / RSU UP stack 1910 sends the SL Resource Grant DCI message to the initiating UE / RSU UP stack 2002. Steps S2134 and S2136 represent Alternative Solution 1. Steps S2138 and S2140 represent Alternative Solution 2. In step S2134, the initiating UE / RSU UP stack 2002 sends an SR / BSR message to the target UE / RSU UP stack 1910. In step S2136, the target UE / RSU UP stack 1910 sends an SL Resource Grant (SCI) message to the initiating UE / RSU UP stack 2002. In step S2138, the initiating UE / RSU UP stack 2002 sends an SR / BSR message to the gNB / RSU / scheduling entity 1614. In step S2142, the initiating UE / RSU UP stack 2002 performs sidelink data transmission or reception. In step S2144, the target UE / RSU UP stack 1910 performs sidelink data transmission or reception. In step S2146, radio link monitoring is performed. In step S2148, the radio link is released.

[0568] Unicast connection configuration parameters

[0569] UE assistance information

[0570] To support unicast connection configuration, multicast connection configuration, or broadcast connection configuration, the T-UE may provide one or more of the following configuration parameters to the I-UE or to the scheduling entity. Such information may be provided by the T-UE as a receiving UE configured with a protocol stack across the PC5 interface, so that it may be configured by the scheduling entity, or may be configured by the I-UE or by the I-UE in collaboration with the scheduling entity. Examples of relevant use cases are illustrated in Figures 16, 17, or 18. In alternative embodiments, the I-UE may provide one or more of the following configuration parameters to the T-UE or to the scheduling entity. Such information may be provided by the I-UE as a receiving UE configured with a protocol stack across the PC5 interface, so that it may be configured by the scheduling entity, or may be configured by the T-UE or by the T-UE in collaboration with the scheduling entity. Examples of relevant use cases are illustrated in Figures 18, 20, or 21. One or more of the following information may be provided to the scheduling entities of both the I-UE and the T-UE to assist the scheduling entities with configuration of the I-UE or the T-UE.

[0571]

[0572]

[0573] Configuration parameters of T-UE or I-UE

[0574] One or more of the following parameters may be configured by the scheduling entity, or by the I-UE in collaboration with the scheduling entity, into the T-UE to support connection configuration. Examples of such connection configurations may be the connection establishment procedures shown in Figures 16, 17, and 18. Similarly, one or more of the following parameters may be configured by the scheduling entity, or by the T-UE in collaboration with the scheduling entity, into the I-UE to support connection configuration. Examples of such connection configurations may be the connection establishment procedures shown in Figures 19, 20, and 21.

[0575]

[0576]

[0577]

[0578]

[0579] Multicast connection management

[0580] Advanced multicast connection management process

[0581] Figure 22This is a high-level diagram of the transmitter-side operations for multicast Layer 2 link management, including connection establishment. In step S2200, a determination is made as to whether the AS is connection-oriented. Steps S2202 and S2210 involve multicast connection establishment and connection context association in the V2X upper layer (V2X UpL) between peer V2X UEs. As shown in step S2204, prior to the transmission of multicast packets, a multicast connection may also be established in the AS layer through connection establishment signaling between the group leader UE and group member V2X UEs for configuration and association of AS contexts between the group UEs and the group member V2X UEs. In this case, the receivers of the group member V2X UEs are configured with dedicated configuration, possibly including dedicated radio resource configuration for unicast reception, taking into account the capabilities of the group member UEs. As part of the multicast connection establishment process, UEs participating in the multicast communication may associate the multicast AS context with the corresponding V2X upper layer multicast context. In the alternative embodiment illustrated in step S2210, the AS may support V2X upper layer multicast connections through an AS connectionless configuration.

[0582] In this case, the AS is configured in an AS connectionless manner, where AS resources are configured in a connectionless manner without taking into account, for example, the capabilities of the group member UEs. In this case, no signaling for configuration of the receiving group member UEs is required prior to reception of the V2X packets. The receiving group member ASs are configured with common default parameters for V2X multicast packet reception, and from the perspective of the AS MAC, the transmitting party transmits packets in a broadcast manner, where filtering of received packets is performed based on the source ID and destination ID encapsulated in the received MAC PDU. For the connection-oriented AS resource configuration described in step S2204, the PHY, MAC, RLC, PDCP, and SDAP (where applicable) are configured in the receiving UE and the transmitting UE for that particular multicast connection before the transmission of the data packet occurs. Prior to transmission of a multicast data packet, a multicast AS context is created in both the transmitting UE and the receiving UE. The context consists of configurations such as a PHY channel configuration (which may include a physical layer multicast radio resource configuration), a transport channel configuration, a HARQ entity configuration, a logical channel configuration, a bearer configuration (which may include a security configuration), a QoS flow configuration, and the association of these configurations between the AS protocol sublayers. Once steps S2202 and S2204 or steps S2210 and S2212 are completed, the transmitting UE and the receiving UE can exchange packets (data or signaling) in a multicast connection-oriented communication manner.

[0583] Step S2206 involves link monitoring in the case of connection-oriented AS multicast communication. Link monitoring can be implemented in the AS, for example, based on radio link monitoring and beam management procedures. Link monitoring can trigger the execution of connection maintenance procedures such as connection reconfiguration, beam recovery, connection relocation, or connection release. Link maintenance procedures can be triggered by the transmitting UE, the receiving UE, or a third entity such as a scheduling entity. In the case of connectionless AS multicast communication, the link monitoring mentioned in step S2214 can be implemented in the V2X upper layer, for example, based on the link keepalive procedure performed by the V2X upper layer. In this case, link monitoring can trigger the execution of transmitter-side reconfiguration, connection relocation, connection release, or group reconfiguration including leaving a group and joining a new group. In this case, the link maintenance procedure can also be triggered by the transmitting UE, the receiving UE, or a third entity such as a scheduling entity. In step S2208, link release is performed. In step S2216, link release is also performed.

[0584] Figure 23 A high-level diagram of receiver-side operations for multicast Layer 2 link management, including connection establishment, is provided. In step S2300, a determination is made as to whether the AS is connection-oriented. If so, in step S2302, V2X upper layer configuration is performed for Layer 2 unicast link connection establishment. If not, in step S2310, V2X upper layer configuration is performed for Layer 2 multicast link connection establishment. In step S2304, V2X SL RX AS configuration is performed for Layer 2 multicast link connection establishment—SL RX AS configuration based on dedicated signaling. In step S2306, link monitoring and maintenance are performed within the AS. In step S2308, link release is performed. In step S2312, V2X SL RX AS configuration is performed for Layer 2 multicast link connection establishment—SL RX AS configuration based on pre-configured or public signaling or non-signaling. In step S2314, link monitoring and maintenance are performed within the V2X upper layer. In step S2316, link release is performed.

[0585] The details of the multicast connection establishment process are similar to the unicast process. The configuration parameters are similar to the configuration parameters described above in the section entitled "Configuration parameters for T-UE or I-EU" and "UE assistance information".

[0586] In one embodiment, groupcast communications may be configured by group member UEs through individual configuration using the unicast configuration procedure described in the section entitled “Unicast Connection Management.” Similarly, connections for new group members may be added using the unicast connection configuration procedure.

[0587] In an alternative embodiment, the multicast connections are configured in groups. For a given group, certain UE capabilities for supporting connection-oriented communications for the given group may be requested from the group member UEs. Such capabilities may be pre-configured into the UE (e.g., SIM or ME), configured into the UE, for example, by broadcast signaling from a scheduling entity (e.g., a UE or group leader that acts as a scheduling entity or assists a scheduling entity in resource configuration), or pre-configured into the UE by the V2X control function. Auxiliary information, such as scheduling information including group members requesting connection configuration or discovering connection configuration information, may be configured into the UE. Such information may be provided to the group member UEs in dedicated signaling, or may be provided in a multicast manner using, for example, the SL-MCCH (SL multicast control channel), or may be provided in a broadcast manner using the SCCH (sidelink control channel) on the SL-SCH (SL shared channel) or the STCH (sidelink traffic channel) on the SL-SCH (SL shared channel), or may be provided in a broadcast manner using the SBCCH (sidelink broadcast control channel). The multicast connection configuration information may be signaled on the SL-MCCH, or may be provided in a broadcast manner using the SCCH (Sidelink Control Channel) on the SL-SCH (SL Shared Channel) or the STCH (Sidelink Traffic Channel) on the SL-SCH (SL Shared Channel), or using the SBCCH (Sidelink Broadcast Control Channel). The configuration information may be signaled periodically.

[0588] In the configuration parameters documented in the section entitled "Configuration Parameters for T-UE or I-UE", the destination ID in the bearer configuration will be the multicast group identifier.

[0589] When the V2X upper layer or application layer performs group management functions, the group provided to the AS by the V2X upper layer may be too large for multicast connection management, which is effective and efficient from the perspective of radio resource management. The AS can subdivide the upper layer V2X group into subgroups, which are passed to the PHY layer to support multicast communication. The AS can assign a layer 2 destination ID to each subgroup through a mapping between the AS subgroup ID and the corresponding larger group layer 2 destination ID. The AS protects the mapping table between the subgroup layer 2 destination ID and the corresponding larger group ID. The multicast connection configuration configured into the UE may include a mapping table between the subgroup layer 2 destination ID and the corresponding larger group layer 2 destination ID. In one embodiment, in addition to the association table between the subgroup destination ID and the group destination ID, the multicast connection configuration for the UE may include an indication of whether the V2X data of the subgroup destination ID should be relayed, and an indication of whether the UE is requested to relay the received data. For a given multicast, the AS can configure the PHY with one or more of the following information:

[0590] Group layer 2 destination ID;

[0591] A list of V2X UE IDs of group members (e.g., ProSe UE ID, UE ID, or any other identifier that can be used by a UE as a source ID for member UEs);

[0592] Subgroup layer 2 destination ID;

[0593] A list of V2X UE IDs of the sub-group members (e.g., ProSe UE ID, U ID, or any other identifier that can be used by the UE as a source ID for the member UEs);

[0594] • For each sub-group, an indication of requesting to relay or not relay data received for that sub-group.

[0595] Configuration for V2X broadcast communication

[0596] Figure 24 On the transmission side, Figure 25 A high-level illustration of the AS configuration for broadcast V2X communication is provided in relation to the receiver side. In an AS broadcast V2X communication scenario, the T-UE, i.e. the UE that is the receiving UE of the configuration request, is not provided with a dedicated configuration based on, for example, UE capabilities. Instead, the AS protocol stack is configured based on a configuration that is, for example, specified as default parameters in the specification, or based on a configuration that is pre-configured into the UE (SIM or ME) or pre-provisioned into the UE by, for example, a V2X control function. It should be noted that although the AS is configured with broadcast resources, where each MAC PDU carries a Layer 2 Source ID and a Layer 2 Destination ID, thus making the transmission connectionless from the perspective of the AS protocol stack configuration, upper layers may still maintain a unicast connection or a multicast connection in the V2X upper layers in which the Layer 2 context is configured, as well as maintain associations between peer V2X upper layer contexts maintained in the V2X upper layers. In Figure 24 Step S2400 of V2X SL TX AS configuration is performed - for broadcast-based transmission, pre-configuration of SL TX AS configuration or configuration based on public signaling or dedicated signaling is used. Signaling for configuration of upper layer V2X connections and context configuration including association between peer V2X UEs (e.g., to support secure data links) may use one or more of the following:

[0597] • PC5-S signaling over the user plane in a connectionless manner, where each MAC PDU carries a source ID and a destination ID.

[0598] PC5-S signaling over the user plane in an AS connection-oriented manner. This may be the case if an AS connection (e.g., unicast) already exists between the two V2X UEs involved in this sidelink communication PC5-S messages embedded in RRC signaling messages.

[0599] exist Figure 25 In step S2500 , V2X SL RX AS configuration is performed - for broadcast-based reception, pre-configuration of SL RX AS configuration or configuration based on public signaling or not based on signaling is used.

[0600] In the following sections, the method by which a UE handles multiple simultaneous sidelink RRC connections is described.

[0601] PC5 RRC connection status

[0602] Based on the explanations in the previous sections, before communicating over a V2X communication link, two peer UEs may need to start a PC5 RRC connection. The steps to establish such a PC5 connection are described below and shown in Figure 26 middle:

[0603] Step S2600: PC5-S signaling (DIRECT_COMMUNICATION_REQUEST) for determining whether the peer is willing to communicate via the PC5 interface

[0604] Step S2602: UE capability exchange between two peer UEs

[0605] Step S2604: Access Stratum (AS) configuration of peer UE to allow V2X communication

[0606] Step S2606: UE-to-UE communication via PC5

[0607] During steps S2600 to S1604, the UE may be in the PC5_RRC_IDLE state. In this state, the UE monitors the (pre-)configured communication reception pool to determine any possible PC5-S signaling messages from the peer UE. In this state, all communications to and from the UE may be considered to pass through the sidelink common control channel (SL_CCCH). Upon receiving a valid DIRECT_COMMUNICATION_REQUEST, the PC5 signaling layer in the UE will determine whether a direct link is allowed and respond to the peer UE. If allowed, the UE will send DIRECT_COMMUNICATON_ACCEPT. Subsequently, the RRC layer will initiate a UE capability exchange and an access layer configuration exchange with the peer UE. These exchanges may also be via the SL_CCCH. After successful completion of these exchanges, the UE may be considered to have established a PC5RRC connection and may transition to the PC5_RRC_CONNECTED state. In this state, the UE:

[0608] Control information can be transmitted via the Sidelink Dedicated Control Channel (S_DCCH) and user data can be transmitted via the Sidelink Dedicated Traffic Channel (SL_DTCH);

[0609] A sidelink radio bearer for communicating with a peer UE may be set up;

[0610] May be required to send reference signals to assist peer UEs in making channel quality measurements;

[0611] Can be required to act as a synchronization reference source and send system information signals; and

[0612] • The status of the side link can be monitored to assess link quality, declare link failure, and take action in response to link failure.

[0613] In the above, it is assumed that the PC5 RRC connection is established immediately after the AS configuration exchange. Alternatively, the PC5 RRC connection can be established after a subsequent signaling exchange between UE1 and UE2 using the PC5RRCConnectionSetup message.

[0614] A PC5 RRC connection between two peer UEs may cause one UE to behave as the master of the connection and one UE to behave as the slave of the connection. Only the master of the connection can modify or delete the PC5 RRC connection. For example, if UE1 initiates a PC5 RRC connection with UE2, the UE may be the master of the PC5 RRC connection and UE2 may be the slave. Alternatively, after the capability exchange shown in step S2602, UE1 may determine that UE2 should be the master of the PC5 RRC connection and it may request UE2 to act as the master (e.g., in the AS configuration step, or optionally in a dedicated PC5RRCConnecctionSetup step). UE1 may make its decision based on a number of factors, including one or more of the following:

[0615] Current load: For example, if it has many active RRC connections, it may require UE2 to act as the master;

[0616] Connectivity to the cellular network / quality of the Uu link: If UE1 is out of coverage, it can ask UE2 to act as the master;

[0617] Power state: If UE2 has more power available, or is powered by a power source (e.g., plugged into a socket), then UE1 can ask UE2 to act as the master device;

[0618] Capability: UE1 is not capable of acting as a master device and can request UE2 to act as a master device.

[0619] Multiple PC5 RRC connections for a UE

[0620] A typical UE will have one or more RRC connections (see Figure 27 ). One of these connections may be a connection to a gNB, and one or more of these connections may be connections to a peer UE. These latter connections are PC5 RRC connections. For each PC5 RRC connection, the UE may be either the master or the slave of the connection. For example, Figure 27 Four types of PC5RRC connections are shown:

[0621] 1. PC5 RRC connection 1: UE1←→UE2

[0622] a.UE2 is the connected master device, UE1 is the connected slave device

[0623] 2. PC5 RRC connection 2: UE1←→UE3

[0624] a.UE1 is the connected master device, UE3 is the connected slave device

[0625] 3. PC5 RRC connection 3: UE1←→UE4

[0626] a.UE1 is the connected master device, UE4 is the connected slave device

[0627] 4. PC5 RRC connection 4: UE1←→UEk

[0628] a.UEk is the connected master device, UE1 is the connected slave device

[0629] When a UE has multiple simultaneous RRC connections (e.g. Figure 27 (as shown for UE1 in the figure), the UE may need to have a process for managing the relationship / links between these connections.

[0630] Keep UE1 in connected mode

[0631] The process can monitor the number of simultaneous PC5 RRC connections. If this number is greater than a configurable threshold (K), the UE1 should maintain its RRC connection with the gNB in ​​RRC_CONNECTED mode. This allows the UE1 to send buffer status request (BSR) reports to the gNB without first sending a scheduling request. This can speed up resource allocation for sidelink transmissions on PC5. If the UE1 is in RRC_IDLE mode (relative to the gNB) and the number of PC5 RRC connections exceeds this threshold, the UE can initiate an RRC connection with the gNB with the establishment cause set to indicate to the gNB that the UE1 is requesting this connection so that a BSR can be sent for sidelink transmissions. For example, the establishment cause could be "SidelinkResourceAllocation."

[0632] Release all RRC connections

[0633] The process may receive a request from the gNB to stop all sidelink communications. A UE in RRC_IDLE mode (relative to the gNB) may still transmit on the sidelink using autonomous resource selection. In some cases, the gNB may need to stop all sidelinks to limit interference to neighboring cells and / or reduce the load on the cell. In such cases, it may be useful to provide the gNB with a mechanism to inform the UE to enter RRC_IDLE and stop all sidelink transmissions. For example, the gNB may cause UE1 to transition to RRC_IDLE by releasing the RRC connection. The message may also include an indication to release one or more or all PC5 RRC connections. Upon receiving this message from the gNB, UE1 will release all PC5 RRC connections for which it is the primary device. Based on Figure 27 , which will be for PC5 RRC connection 2 and PC5 RRC connection 3. At the same time, UE1 can send PC5RRCConnectionReleaseIndication messages to UE2 and UEk to enable these UEs to release their PC5 RRC connections with UE1. PC5RCConnectionReleaseIndication can include the reason for the release (e.g., 'gNBrelease').

[0634] Manage the priority of PC5 RRC connections

[0635] Each PC5 RRC connection may be assigned a priority when it is set up. Processing in UE1 may monitor the priorities of all PC5 RRC connections and may decide to suspend or release one or more of these PC5 RRC connections based on a number of factors such as available power, load, proximity to peer UEs, etc. Figure 27For example, PC5 RRC connection 3 may have the highest priority. If necessary, the UE may suspend or release PC5 RRC connections 1, 2, and 4. UE1 will release all PC5 RRC connections for which it is the primary device. Figure 27 , which will be for PC5 RRC connection 2. At the same time, UE1 can send PC5RRCConnectionReleaseIndication message to UE2 and UEk to make these UEs release their PC5RRC connections with UE1. PC5RCConnectionReleaseIndication can include the reason for release (such as 'priority release').

[0636] PC5 unicast link granularity, unicast link update, and unicast link addition process

[0637] In LTE D2D, the direct link setup procedure is used to establish a secure direct link between two ProSe-enabled UEs. No AS configuration is exchanged between the initiating and target UEs. In NR V2X, unicast link establishment requires the exchange of AS (Access Stratum) configuration between the initiating and target UEs, as described in this document. An example of such configuration is bearer-related configuration. This bearer configuration at the AS level requires the configuration in the V2X layer of corresponding QoS flows associated with the V2X services to be supported over the unicast link. A QoS flow (identified by a QoS Flow Identifier (QFI), i.e., the finest-grained QoS level available, consists of QoS characteristics identified by a PQI and QoS rules with a packet filter set, which are mapped to the AS bearer configuration associated with the V2X services to be supported over the PC5 unicast link. A V2X application running on a UE can support one or more services, where data traffic associated with each service can be mapped to one or more QoS flows. Several V2X applications can run concurrently on a UE, and within each application, the UE can generate data supporting different services, where data from each service can be mapped to one or more QoS flows.

[0638] Based on the above, it is proposed that for NR V2X, in addition to configuring QoS flows in the V2X layer to support the service data to be carried on the PC5 link, the direct PC5-S link setup procedure also configures a secure link between two V2X peer UEs. Therefore, a PC5 direct unicast link setup procedure is proposed for establishing a security context for the secure link between peer V2X UEs, as well as for configuring QoS flows to support the service data(s) to be transmitted on the unicast link.

[0639] Unicast link modeling

[0640] Model 1

[0641] like Figure 28 As shown in FIG, there is only one unicast link between two peer V2X UEs. The PC5 unicast link establishment procedure creates a secure link between the two peer V2X UEs and also configures QoS flows for one or more services, where the services are mapped to one or more applications. The establishment of a security context during the unicast link establishment procedure is mandatory. In this model, it is proposed to implement subsequent QoS flow addition via the PC5 unicast link update procedure. After the unicast link is established, the procedure essentially configures additional QoS flows, which are mapped to data for one or more services to be transmitted over the PC5 unicast link. The security context may not be updated as part of the unicast link update procedure, and thus security parameters may not be exchanged between the V2X peer UEs during the unicast link update procedure.

[0642] Model 2

[0643] In this model, there can be more than one PC5 unicast link between two peer UEs, where for each pair of two peer UEs there is one unicast link between the two peer applications, e.g. Figure 29 As shown in .

[0644] In this embodiment, the PC5 unicast link establishment procedure establishes a secure link between two peer V2X UEs and also configures QoS flows for one or more services, where services are mapped to one application. In an alternative embodiment, more than one unicast link can be established concurrently during the same unicast link establishment procedure, where the PC5 unicast link establishment procedure establishes a secure link between two peer V2X UEs and also configures QoS flows for one or more services, where services are mapped to more than one application. In this model, it is proposed to implement subsequent QoS flow addition via the PC5 unicast link update procedure. After the unicast link is established, this procedure essentially configures additional QoS flows, which are mapped to data for one or more services to be transmitted over the PC5 unicast link. The one or more services added to the PC5 unicast link can belong to existing applications with unicast links established during the unicast link establishment procedure. In this model, it is also proposed to introduce a new unicast link management procedure, namely the PC5 unicast link addition procedure. This procedure adds an additional link between two peer V2X applications and configures one or more QoS flows to support one or more services of the V2X application for which the new unicast link is being added. This procedure can concurrently add more than one unicast link. The security context may not be updated as part of the unicast link update procedure, and therefore, security parameters may not be exchanged between peer V2X UEs during the unicast link update procedure.

[0645] Model 3

[0646] In this model, there can be more than one PC5 unicast link between two peer UEs, where for every two peer UEs, there is one unicast link per service, e.g. Figure 30 As shown in .

[0647] In this embodiment, the PC5 unicast link establishment procedure establishes a secure link between two peer V2X UEs and also configures a QoS flow for a service. In an alternative embodiment, more than one unicast link can be established concurrently within the same unicast link establishment procedure. The PC5 unicast link establishment procedure establishes a secure link between two peer V2X UEs and also configures QoS flows for one or more V2X services, where these services are mapped to one or more applications. In this model, the PC5 unicast link update procedure is proposed to enable the subsequent addition of QoS flows. After the unicast link is established, this procedure essentially configures additional QoS flows that map to data for one or more existing services to be transmitted over the PC5 unicast link. The one or more services added to the PC5 unicast link can belong to existing applications with unicast links established during the unicast link establishment procedure. This model also proposes the introduction of a new unicast link management procedure, the PC5 unicast link addition procedure. This procedure adds an additional link between two peer UEs for the new service and configures one or more QoS flows to support the V2X service for which the new unicast link is added. More than one unicast link may be added concurrently through this procedure. The security context may not be updated as part of the unicast link update procedure, and thus security parameters may not be exchanged between V2X peer UEs during the unicast link update procedure.

[0648] Example embodiments of the present disclosure provide a first apparatus (UE, e.g., mobile device 102a, computer, vehicle (e.g., car 102b, motorcycle, boat, etc.), etc.), comprising: a processor (e.g., processor 118); memory (e.g., non-removable memory 130, removable memory 132, etc.); and communication circuitry (e.g., including transceiver 120). The first apparatus is connected to a communication network (e.g., RAN 103 / 104 / 105 / 103b / 104b / 105b) via the communication circuitry. The first apparatus also includes computer-executable instructions stored in the memory that, when executed by the processor, cause the first apparatus to: discover a second apparatus (a second UE, e.g., mobile device 102a, computer, vehicle (e.g., car 102b, motorcycle, boat, etc.), etc.) with which the first apparatus can communicate; obtain device information associated with the second apparatus; and configure the first apparatus's radio protocol (e.g., PC5 signaling protocol) for direct sidelink communication with the second apparatus.

[0649] In an example embodiment, the first device may send a request for device information related to the second device to the second device (see, for example, Figure 16A , SL RRC signaling-target device information request), initiating the acquisition of device information related to the second device.

[0650] In an example embodiment, the first apparatus may receive a response to a request for device information associated with the second apparatus. The response (e.g., see Figure 16A , SL RRC signaling-target device information response) includes device information related to the second device.

[0651] In an example embodiment, the device information associated with the second apparatus includes one or more of the following: device capabilities, QoS configuration parameters for V2X communication, and sidelink measurements. Device capabilities may, for example, relate to one or more of the following: V2X upper layer capabilities (e.g., security capabilities), SDAP capabilities, PDCP capabilities, RLC capabilities, MAC capabilities, baseband capabilities, and RF capabilities including RF bands and subbands. Sidelink measurements may, for example, include RSRP, RSRQ, RSSI, CBR, CR, and the like.

[0652] In an example embodiment, the first device may determine the radio protocol configuration parameters of the first device and determine the radio protocol configuration parameters of the second device. Alternatively, the first device may request the radio protocol configuration parameters of the first device and the radio protocol configuration parameters of the second device from a third device (e.g., a scheduling entity) and receive the radio protocol configuration parameters of the first device and the radio protocol configuration parameters of the second device.

[0653] In an example embodiment, the determination of the radio protocol configuration parameters of the second apparatus takes into account device information related to the second apparatus. In an example embodiment, the determination of the radio protocol configuration parameters of the second apparatus takes into account device information related to the second apparatus and device information related to the first apparatus.

[0654] In an example embodiment, the first device may send the radio protocol configuration parameters of the second device to the second device, or the second device may receive the radio protocol configuration parameters of the second device from the third device. In an example embodiment, the radio configuration parameters of the second device sent to the second device are used by the second device to configure its radio protocol.

[0655] In an example embodiment, the first apparatus may send device information related to the first apparatus to the second apparatus. In an example embodiment, the device information related to the first apparatus includes one or more of the following: device capabilities, QoS configuration parameters for V2X communication, and sidelink measurement values.

[0656] In an exemplary embodiment, the PC5 interface (see, for example, Figure 10 ) allows communication between the first device and the second device using PC5 RRC signaling or PC5-S signaling over a PC5 interface. In an example embodiment, the PC5 interface allows communication between the first device and the third device, or the PC5 interface allows communication between the second device and the third device. In an example embodiment, PC5 RRC signaling or PC5-S signaling may be used over the PC5 interface.

[0657] In an exemplary embodiment, the radio protocol includes, for example, an SDAP layer, a PDCP layer, an RLC layer, a MAC layer, and a PHY layer. Figure 2 and Figure 6 .

[0658] In an exemplary embodiment, the first device or the second device is a vehicle. Both the first device and the second device can be vehicles. One of the first device and the second device can be a mobile device, and the other can be a vehicle.

[0659] In an example embodiment, the first device may transmit data from the first device to the second device through a transceiver (eg, transceiver 120 ).

[0660] In an example embodiment, the third device is a roadside unit (e.g., RSU 120b), a base station (e.g., base stations 114a, 114b), a relay node, a vehicle (e.g., vehicle 102b), or an integrated access and backhaul unit.

[0661] In an example embodiment, the second device includes a processor (e.g., processor 118), a memory (e.g., non-removable memory 130, removable memory 132), and communication circuitry (e.g., including transceiver 120). The second device is connected to a communication network via the communication circuitry. The second device includes computer-executable instructions stored in the memory that, when executed by the processor, cause the second device to: 1) determine radio protocol configuration parameters for the first device and determine radio protocol configuration parameters for the second device; or 2) request the radio protocol configuration parameters for the first device and the second device from a third device and receive the radio protocol configuration parameters for the first device and the second device. In an example embodiment, the determination of the radio protocol configuration parameters for the first device considers device information related to the first device, or the determination of the radio protocol configuration parameters for the first device considers device information related to the second device and device information related to the first device. In an example embodiment, the second device may send the radio protocol configuration parameters for the first device to the first device, or the first device may receive the radio protocol configuration parameters for the first device from the third device. In an example embodiment, the radio configuration parameters for the first device sent to the first device are used by the first device to configure its radio protocol.

[0662] In an example embodiment, the first device may send device information related to the first device to the second device. The device information related to the first device includes one or more of the following: device capabilities, QoS configuration parameters for V2X communication, and sidelink measurement values. The second device includes a processor, a memory, and a communication circuit. The second device is connected to a communication network via the communication circuit. The second device includes computer-executable instructions stored in the memory, which, when executed by the processor, cause the second device to: determine radio protocol configuration parameters of the first device, and determine radio protocol configuration parameters of the second device. Alternatively, the second device may request the radio protocol configuration parameters of the first device and the radio protocol configuration parameters of the second device from a third device, and receive the radio protocol configuration parameters of the first device and the radio protocol configuration parameters of the second device.

[0663] Example embodiments of the present disclosure provide a method for direct sidelink communication using a first device, the first device comprising a processor, a memory, and a communication circuit, and the first device being connected to a communication network via the communication circuit. The method includes: discovering a second device with which the first device can communicate; obtaining device information associated with the second device; and configuring a radio protocol of the first device for direct sidelink communication with the second device.

[0664] Example embodiments of the present disclosure provide a non-transitory computer-readable storage medium having computer-readable instructions tangibly recorded thereon, which, when executed by a processing circuit, cause the processing circuit to perform a method for direct sidelink communication using a first device. The method includes: discovering a second device with which the first device can communicate; obtaining device information associated with the second device; and configuring a radio protocol of the first device for direct sidelink communication with the second device.

[0665] In an example embodiment, the PC5 interface is a unicast link between the first device and the second device, the unicast link allowing communication between one or more pairs of peer services in the first device and the second device.

[0666] In an example embodiment, all services using the same PC5 unicast link use the same application.

[0667] In an example embodiment, a PC5 unicast link supports one or more service types if the one or more service types are associated with at least one pair of peer applications of the PC5 unicast link.

[0668] It should be understood that any of the methods and processes described herein can be implemented in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium. When executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, etc., the instructions perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described above can be implemented in the form of such computer-executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium that can be used to store the desired information and can be accessed by a computing system.

[0669] In describing preferred embodiments of the subject matter of the present disclosure as illustrated in the figures, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[0670] Thus, it will be appreciated by those skilled in the art that the disclosed systems and methods can be implemented in other specific forms without departing from their spirit or essential characteristics. Thus, the presently disclosed embodiments are to be considered in all respects to be illustrative and not restrictive. It is not exhaustive and does not limit the present disclosure to the precise form disclosed. In view of the above teachings, various modifications and variations are possible, or various modifications and variations can be obtained from the practice of the present disclosure without departing from the breadth or scope of the present disclosure. Thus, although specific configurations are discussed herein, other configurations may also be adopted. The present disclosure enables numerous modifications and other embodiments (e.g., combinations, rearrangements), and the numerous modifications and other embodiments are within the scope of those skilled in the art and are considered to fall within the scope of the disclosed subject matter and any equivalents thereof. The features of the disclosed embodiments can be combined, rearranged, omitted, etc. within the scope of the present invention to produce additional embodiments. In addition, certain features are sometimes advantageous when used without corresponding use of other features. Thus, the applicant intends to include all such replacements, modifications, equivalents, and variations within the spirit and scope of the disclosed subject matter.

[0671] Unless explicitly stated, reference to a singular element does not mean "there is one and only one," but rather "one or more." Where a phrase similar to "at least one of A, B, or C" is used in the claims, it is intended that the phrase be interpreted to mean that A can exist alone in an embodiment, B can exist alone in an embodiment, C can exist alone in an embodiment, or any combination of A, B, and C can exist in an embodiment; for example, A and B, A and C, B and C, or A and B and C.

[0672] Unless a claim element is expressly referenced herein using the phrase "means for...", that claim element is not to be construed under 35 U.S.C. 112(f). As used herein, the terms "comprise," "comprising," or any other variations thereof are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that includes a list of elements does not include only those elements but may include other elements not expressly listed or inherent to the process, method, article, or apparatus. The scope of the invention is defined by the appended claims, not by the foregoing description, and all changes that come within the meaning and scope and range of equivalence thereof are intended to be embraced therein.

Claims

1. A first device, comprising: processor; Memory; and a communication circuit, wherein the first device is connected to a communication network via the communication circuit, the first device further comprising computer executable instructions stored in the memory, which, when executed by the processor, cause the first device to: discovering a second device with which the first device can communicate; obtaining device information related to the second device; and A radio protocol of the first device is configured for direct sidelink communication with the second device.

2. The first apparatus of claim 1, wherein the computer executable instructions further cause the first apparatus to: The obtaining is initiated by sending a request to the second device for device information related to the second device.

3. The first apparatus of claim 2, wherein the computer executable instructions further cause the first apparatus to: A response to the request for device information associated with the second device is received, wherein the response includes device information associated with the second device.

4. The first device of claim 3, wherein the device information associated with the second device comprises one or more of: device capabilities, QoS configuration parameters for V2X communication, and sidelink measurement values.

5. The first apparatus of claim 1, wherein the computer executable instructions further cause the first apparatus to: Determine a radio protocol configuration parameter of the first device, and determine a radio protocol configuration parameter of the second device; or The radio protocol configuration parameters of the first device and the radio protocol configuration parameters of the second device are requested from a third device, and the radio protocol configuration parameters of the first device and the radio protocol configuration parameters of the second device are received.

6. The first device according to claim 5, wherein the determination of the radio protocol configuration parameters of the second device takes into account device information related to the second device, or the determination of the radio protocol configuration parameters of the second device takes into account device information related to the second device and device information related to the first device.

7. The first apparatus of claim 5, wherein the computer executable instructions further cause the first apparatus to: The radio protocol configuration parameters of the second device are sent to the second device, or the second device receives the radio protocol configuration parameters of the second device from the third device.

8. The first device of claim 7, wherein the radio configuration parameters of the second device sent to the second device are used by the second device to configure its radio protocol.

9. A method of direct sidelink communication using a first device, the first device comprising a processor, a memory, a communication circuit, and the first device is connected to a communication network via the communication circuit, the method comprising: discovering a second device with which the first device can communicate; obtaining device information related to the second device; and A radio protocol of the first device is configured for direct sidelink communication with the second device.

10. A non-transitory computer-readable storage medium having computer-readable instructions tangibly recorded thereon, which, when executed by a processing circuit, cause the processing circuit to perform a method of direct sidelink communication using a first device, the method comprising: discovering a second device with which the first device can communicate; obtaining device information related to the second device; and A radio protocol of the first device is configured for direct sidelink communication with the second device.

Images