Unicast session over direct communication link

Abstract

This invention relates to unicast sessions via direct communication links. Apparatus and methods for determining whether an active unicast session can be reused are disclosed. An apparatus (107) receives (305) a first request, for example from an internal application or operating system (107), to establish a unicast session to a first UE (105) via a direct communication link. Here, the first request indicates a source application layer identifier of the apparatus and a target application layer identifier of the first UE (105). It is determined whether an active unicast session already exists between the source application layer identifier and the target application layer identifier. If an active unicast session already exists between the source application layer identifier and the target application layer identifier, the apparatus reuses (315) the existing active unicast session. Otherwise, the apparatus establishes (320) a new unicast session between the apparatus and the first UE.

Description

[0001] This application is a divisional application of PCT application number PCT / IB2020 / 000348, which entered the Chinese national phase on November 1, 2021, with an international filing date of May 4, 2020, Chinese application number 202080032763.8, and an invention titled "Unicast Session via Direct Communication Link".

[0002] Cross-reference to related applications

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 842,406, filed May 2, 2019, entitled “Unicast Session over a Direct Communication Link” (inventors Dimitrios Karampatsis, Prateek Basu Mallick, and Joachim Loehr), which is incorporated herein by reference. Technical Field

[0004] The topics disclosed in this article generally relate to wireless communication, and in particular to the transmission of unicast sessions via direct communication links. Background Technology

[0005] The following abbreviations are hereby defined, and at least a portion thereof is used in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation Core Network (“5CG”), 5th Generation System (“5GS”), Absolute Radio Channel Number (“ARFCN”), Authentication, Authorization and Accounting (“AAA”), Access and Mobility Management Function (“AMF”), Access Restricted Local Operator Services (“ARLOS”), Positive Acknowledgment (“ACK”), Application Programming Interface (“API”), Certification Authority (“AuC”), Access Layer (“AS”), Autonomous Uplink (“AUL”), AUL Downlink Feedback Information (“AUL-DFI”), Base Station (“BS”), Binary Phase Shift Keying (“BPSK”), Bandwidth Component (“BWP”), Cryptographic Key (“CK”), Idle Channel Assessment (“CCA”), Control Element (“CE”), Cyclic Prefix (“CP”), Cyclic Redundancy Remainder Check (“CRC”), Channel State Information (“CSI”), Common Search Space (“CSS”), Connectivity Mode (“CM”, which is the NAS state in 5GS), Core Network (“CN”), Control Plane (“CP”), Data Radio Bearer (“DRB”), Dedicated Short Range Communication (“DSRC”), Discrete Fourier Transform Extended (“DFTS”), Downlink Control Information (“DCI”), Downlink (“DL”), Downlink Pilot Time Slots (“DwPTS”), Dual Connectivity (“DC”), Dual Registration Mode (“DR Mode”), Discontinuous Transmission (“DTX”), Enhanced Idle Channel Assessment (“eCCA”), Enhanced Licensed Assisted Access (“eLAA”), Enhanced Mobile Broadband (“eMBB”), Evolved Node B (“eNB”), Evolved Packet Core (“EPC”), Evolved Packet System (“EPS”), EPS Mobility Management (“EMM”),This includes the NAS status in EPS, Evolved UMTS Terrestrial Radio Access (“E-UTRA”), E-UTRA Absolute Radio Channel Number (“EARFCN”), Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), European Telecommunications Standards Institute (“ETSI”), Frame-Based Equipment (“FBE”), Frequency Division Duplex (“FDD”), Frequency Division Multiple Access (“FDMA”), Frequency Division Orthogonal Coverage Code (“FD-OCC”), General Packet Radio Service (“GPRS”), General Public Service Identifier (“GPSI”), Protection Period (“GP”), Global System for Mobile Communications (“GSM”), Globally Unique Temporary UE Identifier (“GUTI”)), Hybrid Automatic Repeat Request (“HARQ”), Home Subscriber Server (“HSS”), Home Public Land Mobile Network (“HPLMN”), Message Element (“IE”), and Integrity Key (“IK”). Internet of Things (“IoT”), International Mobile Subscriber Identity (“IMSI”), Key Derivation Function (“KDF”), License-Assisted Access (“LAA”), Load-Based Device (“LBE”), Listen-After-Speak (“LBT”), Long Term Evolution (“LTE”), Multiple Access (“MA”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Modulation and Coding Scheme (“MCS”), Machine Type Communication (“MTC”), Multiple-Input Multiple-Output (“MIMO”), International Subscriber Number of Mobile Stations (“MSISDN”), Multi-User Shared Access (“MUSA”), Narrowband (“NB”), Negative Acknowledgment (“NACK”) or (“NAK”), Next Generation (“5G”) Node B (“gNB”), Next Generation Radio Access Network (“NG-RAN”, RAN for 5GS Networks), New Radio (“NR”, 5G Radio Access Technology; also known as “5G”) NR), Next Hop ("NH"), Next Hop Chain Counter ("NCC"), Non-Access Stratum ("NAS"), Network Exposure Function ("NEF"), Non-Orthogonal Multiple Access ("NOMA"), Network Slice Selection Auxiliary Information ("NSSAI"), Operation and Maintenance System ("OAM"), Orthogonal Frequency Division Multiplexing ("OFDM"), Packet Data Unit ("PDU", used in conjunction with "PDU Session"), Packet Switching ("PS"),Examples include packet switching domain or packet switching service, primary cell (“PCell”), physical broadcast channel (“PBCH”), physical cell identifier (“PCI”), physical downlink control channel (“PDCCH”), physical downlink shared channel (“PDSCH”), mode segmentation multiple access (“PDMA”), physical hybrid ARQ indicator channel (“PHICH”), physical random access channel (“PRACH”), physical resource block (“PRB”), physical uplink control channel (“PUCCH”), physical uplink shared channel (“PUSCH”), public land mobile network (“PLMN”), quality of service (“QoS”), quadrature phase shift keying (“QPSK”), radio access network (“RAN”), radio access technology (“RAT”), radio resource control (“RRC”), random access channel (“RACH”), random access response (“RAR”), radio network temporary identifier (“RNTI”), reference signal (“RS”), registration area (“RA”, similar to the tracking area list used in LTE / EPC), registration management (“RM”),Representing NAS layer processes and states), Remaining Minimum System Information (“RMSI”), Resource Extended Multiple Access (“RSMA”), Round Trip Time (“RTT”), Receive (“RX”), Radio Link Control (“RLC”), Sparse Code Multiple Access (“SCMA”), Scheduling Request (“SR”), Single Carrier Frequency Division Multiple Access (“SC-FDMA”), Secondary Cell (“SCell”), Shared Channel (“SCH”), Session Management (“SM”), Session Management Function (“SMF”), Service Provider (“SP”), Signal-to-Interference-plus-Noise Ratio (“SINR”), Single Network Slice Selection Aid Information (“S-NSSAI”), Single Registration Mode (“SR Mode”)), Sounding Reference Signal (“SRS”), System Information Block (“SIB”), Synchronization Signal (“SS”), Supplementary Uplink (“SUL”), Subscriber Identification Module (“SIM”), Tracking Area (“TA”), Transport Block (“TB”), Transport Block Size (“TBS”), Time Distributed duplex (“TDD”), Time Division Multiplexing (“TDM”), Time Division Orthogonal Cover Code (“TD-OCC”), Transmission Time Interval (“TTI”), Transmission (“TX”), Unified Access Control (“UAC”), Unified Data Management (“UDM”), User Data Repository (“UDR”), Uplink Control Information (“UCI”), User Entity / Equipment (Mobile Terminal) (“UE”), UE Configuration Update (“UCU”), UE Routing Policy (“URSP”), Uplink (“UL”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), UMTS Subscriber Identity Module (“USIM”), UMTS Terrestrial Radio Access (“UTRA”), UMTS Terrestrial Radio Access Network (“UTRAN”), Uplink Pilot Time Slots (“UpPTS”), Ultra Reliable and Low Latency Communication (“URLLC”), Access to Public Land Mobile Networks (“VPLMN”), and Global Microwave Access Interoperability (“WiMAX”). As used herein, HARQ-ACK can uniformly represent positive acknowledgment (“ACK”), negative acknowledgment (“NACK”), and discontinuous transmission (“DTX”). ACK means that the TB was received correctly, while NACK (or NAK) means that the TB was received incorrectly. DTX indicates that the TB was not detected.

[0006] In some wireless communication systems, unicast communication on PC5 is used to support V2X communication. However, starting with 3GPP Release 15, unicast communication on PC5 lacks a link layer mechanism. Summary of the Invention

[0007] The disclosed procedure is for determining whether an active unicast session can be reused. One method for a UE to determine whether an active unicast session can be reused includes receiving a first request from an internal application (e.g., a V2X application or OS running on the source UE) to establish a unicast session to a target UE (i.e., a second UE) via a direct communication link. Here, the first request indicates a source application layer identifier of the source UE and a target application layer identifier of the target UE. The first method includes determining whether an active unicast session already exists between the source application layer identifier and the target application layer identifier. If an active unicast session already exists between the source application layer identifier and the target application layer identifier, the first method includes reusing the existing active unicast session between the source UE and the target UE. Otherwise, if an active unicast session does not exist between the source application layer identifier and the target application layer identifier, the first method includes establishing a new unicast session between the source UE and the target UE. Attached Figure Description

[0008] A more detailed description of the embodiments briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and should therefore not be considered as limiting the scope. The embodiments will be described and explained with additional features and details using the drawings, wherein:

[0009] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system for determining whether an active unicast session can be reused;

[0010] Figure 2 This is a schematic diagram illustrating one embodiment of the process for determining whether an active unicast session can be reused;

[0011] Figure 3 This is a flowchart illustrating one embodiment of a method that can be used to determine whether an active unicast session can be reused;

[0012] Figure 4A This is a schematic diagram illustrating one embodiment of a process for reusing an existing unicast session for multiple V2X services between the same pair of UEs;

[0013] Figure 4B continue Figure 4A The process;

[0014] Figure 5A This is a schematic diagram illustrating one embodiment of the process of reusing the same RRC connection to transmit multiple unicast sessions of multiple V2X services; and

[0015] Figure 5B continue Figure 5A The process;

[0016] Figure 6 This is a schematic diagram illustrating one embodiment of a user equipment device that can be used to determine whether an active unicast session can be reused. Detailed Implementation

[0017] Those skilled in the art will understand that the various embodiments can be implemented as systems, apparatus, methods, or program products. Therefore, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware solutions.

[0018] For example, the disclosed embodiments can be implemented as hardware circuitry that includes custom very-large-scale integration (VLSI) circuitry or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors), or other discrete components. Furthermore, the disclosed embodiments can be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, or programmable logic devices. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0019] Furthermore, embodiments may take the form of a program product implemented in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not contain signals. In one embodiment, the storage device uses only signals for accessing the code.

[0020] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof.

[0021] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable compact optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0022] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet through an Internet service provider).

[0023] References to “an embodiment,” “embodiment,” or similar language in this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, the phrases “in an embodiment,” “in an embodiment,” and similar language appearing throughout this specification may, but not necessarily all, refer to the same embodiment, but rather mean “one or more, but not all, embodiments.” Unless expressly stated otherwise, the terms “comprising,” “including,” “having,” and variations thereof mean “including, but not limited to,”. Unless expressly stated otherwise, the list of items does not imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms “a,” “an,” and “the” also mean “one or more.”

[0024] Furthermore, the features, structures, or characteristics of the described embodiments can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring some aspects of the embodiments.

[0025] The following description of various aspects of the embodiments is based on schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to generate machinery, such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / operations specified in the flowcharts and / or block diagrams.

[0026] The code can also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art that implements the functions / operations specified in the flowchart and / or block diagram.

[0027] The code may also be loaded onto a computer, other programmable data processing apparatus or other device, causing a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the function / operation specified in the flowchart and / or block diagram.

[0028] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function(s).

[0029] It should also be noted that in some alternative implementations, the functions annotated in the blocks may occur in a different order than those annotated in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. Other steps and methods can be envisioned that are functionally, logically, or effectively equivalent to one or more blocks or portions thereof in the illustrated figures.

[0030] While various arrow and line types may be used in flowcharts and / or block diagrams, it should be understood that they do not limit the scope of the respective embodiments. In fact, some arrows or other connectors may be used solely to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumeration steps in a depicted embodiment. It will also be noted that each block of the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented by a system based on dedicated hardware, or a combination of dedicated hardware and code, performing a specific function or operation.

[0031] The description of the elements in each figure can be referenced to the elements in the preceding figures. The same numbers refer to the same elements in all figures, including alternative embodiments of the same elements.

[0032] Generally, this disclosure describes systems, methods, and apparatuses for determining whether an active unicast session can be reused by a UE participating in V2X communications. It is currently unclear how a source UE determines that a unicast session is being sent to the same target UE. For example, a source UE may support different V2X services, each requiring the source UE to initiate a unicast session. In 3GPP Release 15, the source UE and target UE use different Layer 2 IDs for each V2X service. Therefore, in 3GPP Release 15, it is not possible to identify whether a message is being sent to the same target UE based on the Layer 2 ID.

[0033] If the source UE knows that a unicast message is being sent to the same target UE, then the source UE can: 1) send a unicast session over the same RRC connection; 2) send a V2X message over the same unicast link. This disclosure describes a solution regarding how a UE running multiple V2X services can discover that a V2X message being communicated directly via unicast is being sent to a target UE.

[0034] Figure 1 A wireless communication system 100 for transmitting unicast sessions via a direct communication link through a V2X communication signal 125, according to an embodiment of the present disclosure, is illustrated. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (RAN) 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may consist of a base station unit 110, with which the remote unit 105 communicates using the wireless communication link 115. Although in Figure 1The diagram shows a specific number of remote units 105, base station units 110, wireless communication links 115, RAN 120, and mobile core network 140. However, those skilled in the art will recognize that any number of remote units 105, base station units 110, wireless communication links 115, RAN 120, and mobile core network 140 may be included in the wireless communication system 100.

[0035] In one implementation, RAN 120 conforms to the 5G system as defined in the 3GPP specification. In another implementation, RAN 120 conforms to the LTE system as defined in the 3GPP specification. However, more generally, the wireless communication system 100 can implement other open or proprietary communication networks, such as WiMAX, and other networks. This disclosure is not intended to limit the implementation of any particular wireless communication system architecture or protocol.

[0036] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart appliances (e.g., internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 may include wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as UE, subscriber unit, mobile station, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or other terms used in the art.

[0037] Remote unit 105 can communicate directly with one or more base station units 110 in RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Furthermore, the UL and DL communication signals can be carried via wireless communication link 115. Here, RAN 120 is an intermediate network providing remote unit 105 with access to the mobile core network 140.

[0038] In some embodiments, remote unit 105 communicates with application server 151 via a network connection to mobile core network 140. For example, application 107 in remote unit 105 (e.g., web browser, media client, telephone / VoIP application) can trigger remote unit 105 to establish a PDU session (or other data connection) with mobile core network 140 via RAN 120. Mobile core network 140 then uses the PDU session to relay traffic between remote unit 105 and application server 151 in packet data network 150. Note that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 140. Therefore, remote unit 105 may simultaneously have at least one PDU session for communicating with packet data network 150 and at least one PDU session for communicating with another data network (not shown).

[0039] Base station unit 110 may be distributed across a geographical area. In some embodiments, base station unit 110 may also be referred to as an access terminal, access point, base station, Node-B, eNB, gNB, home Node-B, relay node, or any other term used in the art. Base station unit 110 is typically part of a radio access network (RAN) (e.g., RAN 120) and may include one or more controllers communicatively coupled to one or more corresponding base station units 110. These and other elements of the radio access network are not shown but are well known to those skilled in the art. Base station unit 110 is connected to mobile core network 140 via RAN 120.

[0040] Base station unit 110 can provide services to multiple remote units 105 within a service area (e.g., a cell or cell sector) via wireless communication link 115. Base station unit 110 can communicate directly with one or more remote units 105 via communication signals. Typically, base station unit 110 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried on wireless communication link 115. Wireless communication link 115 can be any suitable carrier in licensed or unlicensed radio spectrum. Wireless communication link 115 facilitates communication between one or more remote units 105 and / or one or more base station units 110.

[0041] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which may be coupled to a packet data network 150, such as the Internet and private data networks, as well as other data networks. The remote unit 105 may have a subscription or other account to the mobile core network 140. Each mobile core network 140 belongs to a single Public Land Mobile Network (“PLMN”). This disclosure is not intended to limit the implementation of any particular wireless communication system architecture or protocol.

[0042] Mobile core network 140 includes several network functions (“NFs”). As shown, mobile core network 140 includes multiple user plane functions (“UPFs”) 141. Mobile core network 140 also includes multiple control plane functions, including but not limited to: Access and Mobility Management Functions (“AMFs”) 143, which serve RAN 120; Session Management Functions (“SMFs”) 145; Policy Control Functions (“PCFs”) 147; and Unified Data Management Functions (“UDMs”) 149. In some embodiments, mobile core network 140 may also include Authentication Server Functions (“AUSFs”), Network Repository Functions (“NRFs”) (used by various NFs to discover and communicate with each other via APIs), or other NFs defined for 5GC.

[0043] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection uses a specific network slice. Here, "network slice" refers to a portion of the mobile core network 140 optimized for a specific traffic type or communication service. Network instances can be identified by S-NSSAI, while the set of network slices authorized for use by the remote unit 105 is identified by NSSAI. In some embodiments, various network slices may include separate instances of network functions, such as SMF 145 and UPF 141. In some embodiments, different network slices may share some common network functions, such as AMF 143. For ease of illustration, Figure 1 Different network slices are not shown, but their support is assumed.

[0044] Although Figure 1 A specific number and type of network functions are shown, but those skilled in the art will recognize that the mobile core network 140 may include any number and type of network functions. Furthermore, in the case where the mobile core network 140 is an EPC, the depicted network functions can be replaced by appropriate EPC entities, such as MME, S-GW, P-GW, HSS, etc. In some embodiments, the mobile core network 140 may include an AAA server.

[0045] Although Figure 1The diagram illustrates components of the 5G RAN and 5G core network; however, the embodiment described for sidechain HARQ operation in NR V2X communication is applicable to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfoxx, etc. For example, in LTE variants involving EPC, AMF 143 can be mapped to the MME, SMF to the control plane portion of the PGW and / or mapped to the MME, UPF to the SGW and the user plane portion of the PGW, UDM / UDR to the HSS, etc.

[0046] In various embodiments, remote units 105 can communicate directly with each other using V2X communication signals 125 (e.g., device-to-device communication). Here, V2X transmissions can occur on V2X resources. As described above, different V2X communication resources can be provided to remote unit 105 for different V2X modes. Mode-1 corresponds to a V2X communication mode scheduled by the NR network. Mode-2 corresponds to a V2X communication mode scheduled by the NR UE. Mode-3 corresponds to a V2X communication mode scheduled by the LTE network. Mode-4 corresponds to a V2X communication mode scheduled by the LTE UE.

[0047] Currently, unicast communication mode is only supported on NR-based PC5 reference points. When the application layer (in the first UE, "UE-A") initiates a V2X service that requires PC5 unicast communication, UE-A establishes a PC5 unicast link with the corresponding UE ("UE-B").

[0048] After successfully establishing a PC5 unicast link, UE-A and UE-B use the same pair of Layer 2 IDs for subsequent PC5-S signaling message exchange and V2X service data transmission, for example, as specified in 3GPP TS 23.287 Clause 5.6.1.4 (v0.3.0). When the V2X layer of the transmitting UE sends a message over the established PC5 link, it indicates to the AS layer whether the message is for PC5-S signaling (e.g., direct communication acceptance, link layer identifier update request / response, disconnection request / response) or service data transmission. If it is a PC5-S signaling message, the receiving UE's V2X layer processes the message; if it is an application data message, the receiving UE's V2X layer forwards the message to the upper layer.

[0049] Note that unicast mode supports a per-flow QoS model. During unicast link establishment, each UE assigns itself a PC5 link identifier and associates the PC5 link identifier with the unicast link profile of the established unicast link. The PC5 link identifier is a unique value within the UE. The unicast link profile identified by the PC5 link identifier includes the application layer identifier and layer 2 ID of UE A, the application layer identifier and layer 2 ID of UE B, and one or more sets of PC5 QoS flow identifiers (one or more PFIs). Each PFI is associated with QoS parameters (e.g., PQI and optional range).

[0050] Regardless of changes to the application layer identifier and layer 2 ID, the PC5 link identifier and (one or more) PFIs remain constant for established unicast links. The UE uses the PFI to indicate PC5 QoS flows to the AS layer, so the AS layer will recognize the corresponding PC5 QoS flows even if the source and / or destination layer 2 IDs change (e.g., due to privacy support). The UE uses the PC5 link identifier to indicate PC5 unicast links to the V2X application layer, so the V2X application layer recognizes the corresponding PC5 unicast links, even if more than one unicast link is associated with a service type (e.g., for the same service type, the UE establishes multiple unicast links with multiple UEs).

[0051] In some embodiments, remote unit 105 reuses an existing unicast session for multiple V2X services between the same pair of UEs, as described below. Figures 4A to 4B Further detailed description. In some embodiments, remote unit 105 reuses the same RRC connection to transmit multiple unicast sessions on the same pair of UEs, as described below. Figures 5A to 5B Further detailed description.

[0052] In the following description, the term eNB / gNB is used for base stations, but it can be replaced by any other radio access node, such as BS, eNB, gNB, AP, NR, etc. Furthermore, the description primarily focuses on operation in the context of 5G NR. However, the proposed solution / method is equally applicable to other mobile communication systems that support serving cells / carriers configured for sidechain communication via the PC5 interface.

[0053] Figure 2A procedure 200 for establishing a unicast link on a PC5 reference point according to an embodiment of the present disclosure is illustrated. Note that the PC5 reference point may be referred to herein as a "PC5 interface". Procedure 200 involves a first UE ("UE-A") 205 and a second UE ("UE-B") 210 communicating through the PC5 reference point. Each UE is an embodiment of the remote unit 105 described above. Each UE includes an application layer 215, a V2X layer 220, and an access layer ("AS") layer 225 having one or more applications.

[0054] Currently, unicast communication mode is only supported on NR-based PC5 reference points. When the application layer 215 in UE-A 205 initiates a V2X service requesting PC5 unicast communication, the source UE-A 205 establishes a PC5 unicast link with the corresponding target UE-B 210.

[0055] After successfully establishing a PC5 unicast link, UE-A 205 and UE-B 210 use the same pair of Layer 2 IDs for subsequent PC5-S signaling message exchange and V2X service data transmission, for example, as specified in 3GPP TS 23.287 Clause 5.6.1.4 (v0.3.0). When a message is sent over the established PC5 link, the V2X layer 220 of the source / transmitting UE 205 indicates to the AS layer 225 whether the message is for a PC5-S signaling message (e.g., direct communication acceptance, link layer identifier update request / response, disconnection request / response) or service data transmission. If it is a PC5-S signaling message, the V2X layer 220 of the destination / receiving UE-B 210 processes the message; if it is an application data message, the V2X layer 220 of UE-B 210 forwards the message to the upper layer (i.e., application layer 215).

[0056] Note that unicast mode supports a per-flow QoS model. During unicast link establishment, each UE 205-210 assigns itself a PC5 link identifier and associates the PC5 link identifier with the unicast link profile of the established unicast link. The PC5 link identifier is a unique value within the UE. The unicast link profile identified by the PC5 link identifier includes the application layer identifier and layer 2 ID of UE-A 205, the application layer identifier and layer 2 ID of UE-B, and one or more sets of PC5 QoS flow identifiers (“PFI”). Each PFI is associated with QoS parameters (e.g., PQI and optional ranges).

[0057] According to 3GPP Release 15, regardless of changes to the application layer identifier and layer 2 ID, the PC5 link identifier and (one or more) PFIs remain constant for established unicast links. UEs 205-210 use the PFI to indicate PC5 QoS flows to AS layer 225, so the AS layer will recognize the corresponding PC5 QoS flows even if the source and / or destination layer 2 IDs are changed (e.g., due to privacy support). UEs 205 and 210 use the PC5 link identifier to indicate PC5 unicast links to V2X application layer 215, so V2X application layer 215 recognizes the corresponding PC5 unicast links, even if more than one unicast link is associated with a service type (e.g., for the same service type, a UE can establish multiple unicast links with multiple UEs).

[0058] To allow UEs operating multiple V2X services (e.g., UE-A 205, as shown) to discover whether V2X messages are being sent to the same target UE (e.g., UE-B 210) via unicast direct communication, the source UE 205 can reuse an existing unicast session for multiple V2X services between the same pair of UEs, as described below. Figure 3 and Figures 4A to 4B Further detailed description. In some embodiments, the source UE 205 may reuse the same RRC connection to transmit multiple unicast sessions on the same pair of UEs, as described below. Figures 5A to 5B Further detailed description. In some embodiments, source UE-A 205 may create a unicast link identifier (“ULI”), wherein UE-A 205 and UE-B 210 use the unicast link identifier to discover whether V2X messages are sent to the same target UE via unicast direct communication. Here, a PC5-RNTI may be created based on the unicast link identifier. In some embodiments, the unicast link identifier may be a combination of a source application layer ID and a target application layer ID.

[0059] Figure 3 An embodiment of a method 300 for determining whether an active unicast session can be reused, according to embodiments of the present disclosure, is shown. In various embodiments, method 300 is performed by a UE, such as the remote unit 105 described above, UE-A 205 described above, source UE 405 described below, and / or user equipment device 600 described below. In some embodiments, method 300 is performed by a processor, such as a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), etc.

[0060] Method 300 begins by receiving (305) a first request from an internal application (e.g., a V2X application or OS running on the source UE) to establish a unicast session to the target UE (i.e., the second UE) via a direct communication link. Here, the first request indicates the source application layer identifier of the source UE and the target application layer identifier of the target UE. Further details of the first request are described below.

[0061] Method 300 includes determining (310) whether an active unicast session already exists between the source application layer identifier and the target application layer identifier. Further details of determining whether an active unicast session exists are described below.

[0062] Method 300 includes reusing (315) the existing active unicast session between the source UE and the target UE in response to determining that an active unicast session already exists between the source application layer identifier and the target application layer identifier. Further details of reusing the existing unicast session are described below.

[0063] Otherwise, in response to determining that an active unicast session does not exist between the source application layer identifier and the target application layer identifier, method 300 includes establishing (320) a new unicast session between the source UE and the target UE. Further details on establishing the new unicast session are described below. Method 300 ends.

[0064] Figures 4A to 4B A procedure 400 according to an embodiment of this disclosure is illustrated for determining whether an active unicast session can be reused. Procedure 400 illustrates a source UE 405 reusing an existing unicast session for multiple V2X services between the same pair of UEs (i.e., source UE 405 and target UE 410). Here, source UE 405 may be an embodiment of UE-A 205, and target UE 410 may be an embodiment of UE-B 210. Figures 4A to 4B This represents an example of a second solution for transmitting unicast sessions over a direct communication link. Process 400 can extend the method 300 described above. In various embodiments, when a V2X application requests to send a message over a unicast session of a different V2X service (e.g., a different PSID), the source UE 405 can reuse an existing unicast session between the same pair of UEs.

[0065] In some embodiments, source UE 405 initiates a new unicast session request, wherein the request includes an existing active unicast link identifier as metadata. Here, target UE 410 examines one or more unicast link identifiers included in the request and determines whether an active unicast session already exists between source UE 405 and target UE 410. If target UE 410 identifies a match, target UE 410 includes the existing unicast link identifier (“ULI”) in its unicast link session response. Note that the matching ULI can be a matching source and target application layer ID. Source UE 405 examines the response and determines whether an existing unicast link session can be reused.

[0066] exist Figure 4A In this process, process 400 begins at step 1, where an application in source UE 405 (e.g., a V2X application) requests to establish a unicast session for V2X services (see box 415). The application's request to the V2X layer 220 of source UE 405 includes application layer identifiers for both the source UE and the target UE (including target UE 410).

[0067] In step 2, the source UE 405 retrieves the default destination layer 2 ID (see box 420) of the V2X service (PSID) used to establish a unicast session (existing procedure).

[0068] In step 3, the source UE 405 self-assigns a new ULI (because the source UE 405 does not know at this time whether it can reuse the existing unicast link or whether it needs to establish a new unicast link to the same target UE), identifies all active unicast links, and includes them as metadata in the new unicast link request (see box 425). In some embodiments, the metadata includes the target application layer identifier and the source application layer identifier.

[0069] In step 4, the source UE 405 initiates a request for a unicast session by broadcasting a direct communication request (see message 430). Here, the request includes: a source application layer identifier, a target application layer identifier, a source layer 2 identifier (the layer 2 identifier of the source UE 405), a "default" destination layer 2 ID (i.e., from step 2), a generated ULI, and a set of unicast link identifiers as metadata, which is used to identify one or more active unicast sessions.

[0070] In step 5, the target UE 410 receives the unicast request and identifies itself as the target of the direct communication request based on the application layer identifier (see box 435).

[0071] In step 6, the target UE 410 identifies, based on metadata, that at least one active unicast session with the source UE already exists. The target UE 410 includes in its response all matching ULIs of the existing(one or more) active unicast sessions(see box 440).

[0072] continue Figure 4B At step 7, the target UE 410 responds to the unicast link request by sending a direct communication accept message (see message 445). Here, the direct communication accept message includes: the layer 2 identifier of the target UE 410 as the message source layer 2 ID, the layer 2 ID of the source UE 405 as the message target layer 2 ID, the generated ULI (source UE 405), and one or more matching ULIs as metadata.

[0073] In step 8, the source UE 405 determines, based on one or more matching ULIs of the metadata, that a new unicast session can be transmitted via an existing unicast link (see box 450).

[0074] In step 9, the source UE 405 constructs a unicast link profile, which includes a source application layer ID, a target application layer ID, layer 2 identifiers of the source UE 405 and the target UE 410, a ULI, and a PSID. The source UE 405 associates the unicast link with the unicast link identifier (see box 455).

[0075] In step 10, the source UE 405 instructs the target UE 410 to send a unicast session via an existing link (see message 460). As shown, this instruction can be a direct communication request for a ULI that includes a matching existing unicast link.

[0076] In step 11, the target UE 410 constructs a unicast link profile and associates it with an existing ULI (see box 465). Here, the unicast link profile may include the source application layer ID, the target application layer ID, the layer 2 identifiers of the source UE 405 and the target UE 410, the ULI, and the PSID.

[0077] In steps 12a and 12b, both applications associate the unicast link with the unicast link identifier (see boxes 470 and 475).

[0078] In one embodiment, when a V2X application requests to initiate a unicast session to transmit messages for a specific V2X service (e.g., a specific PSID), the source UE initiates a request for unicast communication via PC5. The UE includes a PC5 link identifier in its request for the unicast session. The PC5 link identifier can be generated by the transmitting UE and signaled to the target UE in a DCR message. When the target UE receives the request for a unicast session via PC5, it identifies whether it is the target UE by checking the application layer identifiers included in the request.

[0079] If the UE identifies itself as the target UE, it self-assigns a PC5 link identifier and maps it to the source UE's PC5 link identifier. The target UE constructs a unicast link profile including a source link identifier and a target PC5 link identifier, a Layer 2 address, and an application layer identifier, and maps the unicast link profile to the source link identifier and the target PC5 link identifier. The target UE then responds to the source UE by including the source and target PC5 link identifiers in its unicast link response on PC5. Furthermore, the source UE creates a unicast link profile containing the source and target PC5 link identifiers, a Layer 2 address, and an application layer identifier. The target UE maps the source and target PC5 link identifiers to the unicast link profile. In one embodiment, the source and target PC5 link identifiers can identify the unicast link identifier. Additionally, both the source and target UEs advertise this unicast link identifier to the application layer.

[0080] Figures 5A to 5B A procedure 500 according to an embodiment of the present disclosure is illustrated for determining whether an active unicast session can be reused. Procedure 500 illustrates that a source UE 405 reuses the same RRC connection to deliver multiple unicast sessions of multiple V2X services to a target UE 510. Figures 5A to 5B This represents an example of a third solution for transmitting multiple unicast sessions via a direct communication link. Procedure 500 can extend the above method 300.

[0081] exist Figure 5A In this process, process 500 begins at step 1, where an application in the source UE 405 (e.g., a V2X application) requests to establish a unicast session for the V2X service (see box 505). The request to the V2X layer 220 of the UE includes the application layer identifiers of the source UE and the target UE, as well as the PSID.

[0082] In step 2, the source UE 405 retrieves the default destination layer 2 ID (see box 510) for the V2X service (PSID) used to establish the unicast session.

[0083] In step 3, the source UE 405 can self-assign a new ULI (because the source UE 405 may not know whether to establish a unicast link to the same target UE 410). Furthermore, the source UE 405 can identify all active unicast links and include an identifier for each active unicast link as metadata in the new unicast link request (see box 515).

[0084] In step 4, the source UE 405 initiates a request for a unicast session by broadcasting a direct communication request (see message 520). Here, the request includes: source and destination application layer identifiers, source layer 2 identifier, "default" destination layer 2 ID (i.e., from step 2), generated ULI, and a set of unicast link identifiers (as metadata) identifying one or more active unicast sessions.

[0085] In step 5, the target UE 410 receives the unicast request and identifies itself as the target of the direct communication request based on the application layer identifier (see box 335).

[0086] In step 6, the target UE 410 constructs a unicast link profile, which includes a source application layer ID, a target application layer ID, a layer 2 identifier of the source UE 405, an “actual” layer 2 identifier of the target UE 410, a ULI, and a PSID. The target UE 410 associates the unicast link ULI provided by the source UE 405 (see box 530).

[0087] continue Figure 5B In step 7, the target UE 410 also identifies whether the target UE 410 has one or more existing active unicast sessions with the source UE 405 based on the direct communication request and includes all matching ULIs in the response (see box 535).

[0088] In step 8, the target UE 410 responds to the unicast link request by sending a direct communication accept message (see message 540). Here, the direct communication accept message includes: the target UE 410's "actual" Layer 2 identifier as the message source Layer 2 ID, the source UE 405's Layer 2 ID as the message target Layer 2 ID, the generated ULI (the source UE 405's ULI), and one or more matching ULIs as metadata.

[0089] In step 9, the source UE 405 also constructs a unicast link profile, which includes a source application layer ID, a target application layer ID, layer 2 identifiers of the source UE 405 and the target UE 410, a ULI, and a PSID. The source UE 405 associates the unicast link with the unicast link identifier (see box 545).

[0090] In steps 10a and 10b, both applications associate the unicast link with the unicast link identifier (see boxes 450 and 455).

[0091] In steps 11a and 11b, the source UE 405 and the target UE 410 determine, based on the matching ULI, that one or more matching unicast sessions can be provided through the same RRC connection between the two UEs (see boxes 460 and 465).

[0092] In step 12, AS layer 225 uses the same PC5 RNTI to send data from a unicast session with a matching ULI via an RRC connection. This applies to both the source UE to target UE direction and the target UE to source UE direction.

[0093] In one embodiment, V2X layer 220 associates a unicast session of a matching ULI with a link profile (i.e., the link is associated with the same pair of source and destination UEs). V2X layer 220 notifies AS layer 225 of the unicast session associated with the same destination UE 410. AS layer 225 uses the same PC5 RNTI to transmit data from the unicast session with the matching ULI over an RRC connection. This applies to both the source UE to destination UE direction and the destination UE to source UE direction.

[0094] According to the fourth solution for transmitting unicast sessions over a direct communication link, the source UE can create a random number of bits, such as 16 bits (referred to as "ULI-x"), and send ULI-x along with metadata to the target UE. Reviewing procedures 400 and 500, both involve exchanging metadata, for example, in direct communication requests and responses. According to the fourth solution, the metadata includes all ULIs (e.g., ULI-a, ULI-b, etc.), and the target UE verifies whether it recognizes one of the received ULIs.

[0095] If so, the same ULI (e.g., ULI-a) is also used for the second session. If not, the identifier ULI-x is adopted by the target UE and indicates acceptance to the source UE. Both the source and target UEs thus update their metadata. In one embodiment, the UE updates its metadata by adding the Layer 2 source ID and destination ID associated with the new session ID to the existing profile used for ULI-a. In another embodiment, the UE updates its metadata by creating a new context with ULI-x for the newly created session and adding the Layer 2 source ID and destination ID. In cases where an existing unicast session cannot be reused, ULI-x is passed to the access layer, which creates a PC5-RNTI based on it. This can be done by either adopting the entire ULI (ULI-x in the current example), or a portion of it (e.g., 8 MSB bits) with 8 randomly generated bits appended, or even simply by generating a PC5-RNTI with 16 randomly generated bits.

[0096] In the above embodiment, only 16 bits are used as an example, but any other bit length for the ID is also possible. The length of the identity must be sufficient to minimize the probability that any two UEs (from a large set of UEs in a high-traffic situation) generate the same random identity. If a conflict occurs (e.g., more than one transmitter UE simultaneously uses the same randomly generated identity toward the same destination UE), the upper layer of any involved UE (one or more transmitter UEs and / or receiver UEs) can detect that the received V2X message is not directed to them, for example, based on the station ID, temporary UE identity, application ID, or something similar.

[0097] In this scenario, the UE that detects the collision can send a unicast PC5-S and / or PC5-RRC message including the questionable conflicting identity (ULI and / or PC5-RNTI), instructing the receiver to discard the questionable identity (or multiple identities) and restart by generating a new random number. As an optimization, the collision is only notified to the sender of the previous message that detected the collision, and that sender is then responsible for restarting by generating a new random number for the (default) destination ID of the corresponding PC5-S link.

[0098] The PC5-RNTI is carried in each PC5-RRC message, and the target responds with a PC5-RRC message that includes the same PC5-RNTI. At the physical layer (e.g., in SCI), some (or all) of the PC5-RNTI may also be used to implement filtering at the target UE.

[0099] Note that when all V2X applications terminate and the upper-layer identity (application identity, L2 identity, PLI and / or ULI) needs to be released, the PC5 RNTI (RRC connection on PC5) can be explicitly released by any UE, or implicitly released when the timer used to monitor inactivity expires.

[0100] In either of the above schemes, instead of transmitting the ULI of the active unicast session as metadata in plaintext, the source UE transmits a hashed version of this identifier. Here, both the source and destination UEs must use the same hash function.

[0101] In either of the above scenarios, if both V2X services are operating in the same operating mode (e.g., both within coverage or both outside coverage), the source UE or target UE determines whether an existing unicast session can be reused.

[0102] In either of the above schemes, if a unicast session is lost, both UEs can resume the unicast session by announcing the unicast link identifiers of all active unicast sessions. The UE transmits the unicast link identifiers based on a pre-configured timer. If the timer expires, the UE deletes the unicast link identifier and the associated unicast link profile.

[0103] In any of the above schemes, instead of the source UE transmitting the active ULI as metadata (e.g., step 4 in procedures 400 and 500), the target UE can include the ULI of all activities in the DCR response (the advantage of this method is that it does not require transmitting the ULI of all activities in the broadcast). Here, the source UE determines whether there are any existing active ULIs based on the active ULIs and notifies the AS layer that the same RRC connection can be used (Example 1) and / or notifies the target UE that the same unicast session can be used (Example 2).

[0104] In any of the above schemes, the ULI identifier corresponds to the source tier 2 ID and target tier 2 ID of the source UE and target UE, respectively.

[0105] According to the fifth solution for transmitting unicast sessions via direct communication links, the transmitter UE and the receiver UE solicit and provide PC5 HARQ feedback for PSSCH transmissions performed by the transmitter UE (i.e., the source UE) to one or more receiver UEs. In various embodiments, the transmitter UE learns the total number of member UEs in the group based on upper-layer information, for example, one or more upper layers provide the total number of UEs in the group to one or more lower layers. Here, this knowledge at the physical layer is accurate at any given point in time to the extent required for the physical layer's functionality; even if the group membership is updated, the physical layer is notified within a fairly fast time frame.

[0106] For SL unicast and multicast, HARQ feedback and HARQ combined at the physical layer can be supported. In various embodiments, HARQ-ACK feedback for PSSCH is carried via PSFCH in one or more SFCI formats in resource allocation modes 1 and 2.

[0107] When SL HARQ feedback is enabled for unicast, in non-CBG operation, if the receiver UE successfully decodes the corresponding TB, a HARQ-ACK is generated. If the corresponding TB is not successfully decoded after decoding the associated PSCCH targeted at the receiver UE, a HARQ-NACK is generated.

[0108] When SL HARQ feedback is enabled for multicast, TX-RX distance and / or RSRP can be used to determine whether to send HARQ feedback. In non-CBG operation, the following two options are supported:

[0109] According to SL HARQ feedback option 1, if the corresponding TB is not decoded after decoding the associated PSCCH, the receiver UE (i.e., the target UE) transmits HARQ-NACK on the PSFCH; otherwise, no signal is transmitted on the PSFCH (i.e., if the Rx UE (receiver UE) successfully decodes the corresponding TB, HARQ-ACK is not transmitted on the PSFCH).

[0110] According to SL HARQ feedback option 2, if the corresponding TB is successfully decoded, the receiver UE (Rx UE) transmits HARQ-ACK on the PSFCH. Furthermore, if the corresponding TB is not successfully decoded after decoding the associated PSCCH targeted at the receiver UE, the Rx UE transmits HARQ-NACK on the PSFCH.

[0111] Based on the knowledge of the total number of member UEs in the group, the physical layer of the transmitter UE can determine the required amount of feedback resources. The determination of the required feedback resources will be based on the physical layer structure in 3GPP, which is still pending finalization. The transmitter UE making this decision will compare the number of member UEs in the group, the amount of available feedback resources, and the reliability required for a specific V2X message. Reliability can be directly derived from the VQI / priority indicated by the upper layer for the corresponding packet for transmission. As an example, if the required reliability is five "9 seconds," for example, for "emergency trajectory alignment between UEs supporting V2X applications" and "sensor information sharing between UEs supporting V2X application scenarios," then only feedback option 2 must be used. For lower reliability requirements, if the total number of member UEs in the group is higher than the available feedback resources, option 1 can be used alone; or, options 1 and 2 can be used in combination.

[0112] The actual resources used for HARQ feedback can be less than those determined by the transmitter, as shown above. This is because only one or more receiver UEs within the MCR (Minimum Communication Range) need to provide HARQ feedback. This may sound like a waste of resources at first, but it actually avoids the high complexity that would arise if the transmitter had to know the real-time distance of each receiver UE in advance.

[0113] Consider the following three aspects to reveal detailed (transmitter) UE behavior to choose between Option 1, Option 2 (or a combination): 1) the total number of member UEs in the group; 2) the amount of available HARQ feedback resources; and 3) the reliability required for the corresponding V2X PSSCH packet transmission.

[0114] The different thresholds for each of these projects can lead to the use of either one option or some combination of those options.

[0115] As a first example, if the reliability is greater than the threshold reliability, option 2 is used for as many UEs as possible. In the event of a shortage of feedback resources, option 1 is used for the remaining UEs closer to the transmitter, based on a distance threshold. The distance threshold is calculated as the ratio of the remaining UEs in the group to the total number of receiver UEs multiplied by the MCR (Minimum Communication Range).

[0116] As a second example, if the reliability is less than the threshold reliability and the total number of receiver UEs in the group is greater than the maximum threshold of option 2, then option 1 is used.

[0117] In Mode 1 V2X communication (i.e., NR-based V2X with network scheduling), in addition to (re)transmitting resources, the transmitter UE also needs to request feedback resources from the gNB. Therefore, the transmitter UE needs to notify the gNB of the number of member UEs in the group destinations to which the transmitter will send the expected (one or more) V2X messages. This information, along with the size and period of the V2X message, needs to be notified to the gNB for each group destination to which the transmitter expects to transmit. This information can be carried in messages similar to the sidechain UE information and / or NR UE assistance information defined in the LTE RRC (36.331) specification. For each group to which the transmitter is interested in transmitting data to the gNB, these messages carry the number of member UEs in the group, the corresponding size, period, priority / VQI of the V2X message, etc.

[0118] Upon receiving a UE request, the gNB accordingly provides transport resources and PC5 HARQ feedback time and code resources in Mode 1 V2X communication. As a signaling optimization, the feedback resources can be linked to the PSSCH transport resources using a certain time-frequency offset. All codes can be used by the transmitter UE, or can be explicitly notified to the transmitter via signals from the gNB.

[0119] The number of PC5 feedback resources used for retransmission can be the same as the number of PC5 feedback resources used for transmission, obtained in a manner similar to transmission, as described above. Therefore, in Mode 1 V2X communication, the time-frequency PC5 HARQ feedback resources used for (re)transmission are explicitly obtained from the gNB, or obtained using an offset relative to the PSSCH resources. For PC5 HARQ feedback transmission, all codes can be used by the transmitter UE, or all codes can be explicitly notified to the transmitter via signals from the gNB.

[0120] The transmitting UE needs to allocate feedback resources to group member UEs. This can be accomplished using PC5 RRC, where the transmitter semi-statically configures the UE with either Option 1 or Option 2 resources simultaneously. The actual use of the option (either one or both) and the corresponding conditions (e.g., Option 1 is used when the Tx-Rx distance is less than a certain threshold A, and Option B is used for the rest) are controlled and indicated in SCI and depend on transmission reliability / priority, etc.

[0121] Figure 6 A user equipment device 600, according to embodiments of the present disclosure, is illustrated for determining whether an active unicast session can be reused. In various embodiments, the user equipment device 600 is used to implement one or more of the solutions described above. The user equipment device 600 may be an embodiment of the remote unit 105, UE-A 205, and / or source UE 405 described above. Furthermore, the user equipment device 600 may include a processor 605, a memory 610, an input device 615, an output device 620, and a transceiver 625. In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touchscreen. In some embodiments, the user equipment device 600 may not include any input device 615 and / or output device 620. In various embodiments, the user equipment device 600 may include one or more of the following: processor 605, memory 610, and transceiver 625, and may not include input device 615 and / or output device 620.

[0122] In one embodiment, processor 605 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 605 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, processor 605 executes instructions stored in memory 610 to perform the methods and routines described herein. Processor 605 may be communicatively coupled to memory 610, input device 615, output device 620, and transceiver 625.

[0123] In various embodiments, processor 605 controls user equipment device 600 to implement the UE behavior described above. In some embodiments, processor 605 receives a first request, for example, from an internal application or operating system, to establish a unicast session via a direct communication link to a first UE (i.e., the target UE). Here, the first request indicates a source application layer identifier of the device and a target application layer identifier of the target UE. Processor 605 determines whether an active unicast session already exists between the source application layer identifier and the target application layer identifier.

[0124] If an active unicast session already exists between the source application layer identifier and the target application layer identifier, the processor 605 reuses the existing active unicast session between the device 600 and the target UE. Otherwise, if an active unicast session has not existed between the source application layer identifier and the target application layer identifier, the processor 605 establishes a new unicast session between the device 600 and the target UE.

[0125] In some embodiments, the first request is for a first V2X service, and an existing active unicast session is associated with a second V2X service different from the first V2X service. The processor 605 modifies the unicast link profile of the existing active unicast session to add the first V2X service. In some embodiments, the unicast link profile is associated with an RRC connection, and reusing an existing active unicast session also includes reusing an existing RRC connection between the device 600 and the target UE.

[0126] In some embodiments, processor 605 generates a link identifier for the requested unicast session. In this embodiment, the link identifier maps source and destination application layer identifiers to the unicast session.

[0127] In some embodiments, the processor 605 transmits a second request to the target UE to establish a unicast session and receives a response from the target UE containing a set of link identifiers. In this embodiment, determining whether an active unicast session already exists between the source application layer identifier and the target application layer identifier is based on the response from the target UE. In some embodiments, the response from the target UE includes all existing active unicast sessions of the target UE as metadata.

[0128] In some embodiments, the processor 605 maintains a second set of link identifiers, each link identifier being associated with a pair of source and target application layer identifiers, wherein determining whether an active unicast session with the target UE already exists based on a response includes determining whether a matching link identifier exists in the set of link identifiers and the second set of link identifiers included in the response.

[0129] In some embodiments, the second request includes a second set of link identifiers as metadata. In some embodiments, the response includes an indication of a matching link identifier. In some embodiments, reusing an existing active unicast session includes selecting a matching link identifier and constructing a unicast link profile that maps the unicast session requested in the first request to an existing active unicast session.

[0130] In one embodiment, memory 610 is a computer-readable storage medium. In some embodiments, memory 610 includes volatile computer storage media. For example, memory 610 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 610 includes non-volatile computer storage media. For example, memory 610 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 610 includes both volatile and non-volatile computer storage media.

[0131] In some embodiments, memory 610 stores data related to SL HARQ operations. For example, memory 610 may store V2X communication resources, ULI, etc. In some embodiments, memory 610 also stores program code and related data, such as an operating system or other controller algorithms running on remote unit 105.

[0132] In one embodiment, input device 615 may include any known computer input device, including a touch panel, button, keyboard, stylus, microphone, etc. In some embodiments, input device 615 may be integrated with output device 620, such as as a touchscreen or similar touch-sensitive display. In some embodiments, input device 615 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0133] In one embodiment, output device 620 is designed to output visual, audible, and / or tactile signals. In some embodiments, output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 620 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 620 may include a wearable display, independently but communicatively coupled to the rest of user equipment device 600 (e.g., smartwatches, smart glasses, heads-up displays, etc.). Furthermore, output device 620 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0134] In some embodiments, output device 620 includes one or more speakers for generating sound. For example, output device 620 may generate an audible alarm or notification (e.g., a beep or alert tone). In some embodiments, output device 620 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 620 may be integrated with input device 615. For example, input device 615 and output device 620 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 620 may be placed near input device 615.

[0135] Transceiver 625 includes at least a transmitter 630 and at least one receiver 635. One or more transmitters 630 can be used to send messages to the RAN, as described herein. Similarly, one or more receivers 635 can be used to receive messages from the RAN, as described herein. Although only one transmitter 630 and one receiver 635 are shown, the user equipment apparatus 600 can have any suitable number of transmitters 630 and receivers 635. Furthermore, transmitter(s) 625 and receiver(s) 630 can be of any suitable type.

[0136] According to embodiments of this disclosure, a first apparatus for determining whether an active unicast session can be reused is disclosed. The first apparatus may be implemented via a source UE, such as remote unit 105, UE-A 205, source UE 405, and / or user equipment device 600. The first apparatus includes a transceiver and a processor that receives, for example, a first request from an internal application or operating system to establish a unicast session to a first UE (i.e., a target UE) via a direct communication link. Here, the first request indicates a source application layer identifier of the apparatus and a target application layer identifier of the first UE. The processor determines whether an active unicast session already exists between the source application layer identifier and the target application layer identifier. In response to determining that an active unicast session already exists between the source application layer identifier and the target application layer identifier, the processor reuses the existing active unicast session between the apparatus and the first UE. Otherwise, in response to determining that an active unicast session does not exist between the source application layer identifier and the target application layer identifier, the processor establishes a new unicast session between the apparatus and the first UE.

[0137] In some embodiments, the first request is for a first V2X service, and an existing active unicast session is associated with a second V2X service different from the first V2X service. The processor modifies the unicast link profile of the existing active unicast session to add the first V2X service. In some embodiments, the unicast link profile is associated with an RRC connection, and reusing an existing active unicast session further includes reusing an existing RRC connection between the device and the first UE.

[0138] In some embodiments, the processor generates a link identifier for the requested unicast session. In this embodiment, the link identifier maps source and destination application layer identifiers to the unicast session.

[0139] In some embodiments, the processor transmits a second request to the first UE to establish a unicast session and receives a response from the first UE containing a set of link identifiers. In this embodiment, determining whether an active unicast session already exists between the source application layer identifier and the target application layer identifier is based on the response from the first UE. In some embodiments, the response from the first UE includes all existing active unicast sessions of the first UE as metadata.

[0140] In some embodiments, the processor maintenance device has a second set of link identifiers, each link identifier being associated with a pair of source and target application layer identifiers, wherein determining whether an active unicast session with the first UE already exists based on a response includes determining whether a matching link identifier exists in the link identifier set included in the response and the second link identifier set.

[0141] In some embodiments, the second request includes a second set of link identifiers as metadata. In some embodiments, the response includes an indication of a matching link identifier. In some embodiments, reusing an existing active unicast session includes selecting a matching link identifier and constructing a unicast link profile that maps the unicast session requested in the first request to an existing active unicast session.

[0142] According to embodiments of this disclosure, a first method is disclosed for determining whether an active unicast session can be reused. The first method can be performed by a source UE, such as remote unit 105, UE-A 205, source UE 405, and / or user equipment device 600. The first method includes receiving a first request from an internal application (e.g., a V2X application or OS running on the source UE) to establish a unicast session to a target UE (i.e., a second UE) via a direct communication link. Here, the first request indicates a source application layer identifier of the source UE and a target application layer identifier of the target UE. The first method includes determining whether an active unicast session already exists between the source application layer identifier and the target application layer identifier. The first method includes reusing the existing active unicast session between the source UE and the target UE in response to determining that an active unicast session between the source application layer identifier and the target application layer identifier already exists. Otherwise, the first method includes establishing a new unicast session between the source UE and the target UE in response to determining that an active unicast session between the source application layer identifier and the target application layer identifier does not exist.

[0143] In some embodiments, the first request is directed to a first V2X service, and an existing active unicast session is associated with a second V2X service different from the first V2X service. In this embodiment, the first method includes modifying the unicast link profile of the existing active unicast session to add the first V2X service. In some embodiments, the unicast link profile is associated with an RRC connection. In this embodiment, reusing an existing active unicast session also includes reusing an existing RRC connection between the source UE and the target UE.

[0144] In some embodiments, the first method includes generating a link identifier for the requested unicast session. In this embodiment, the link identifier maps source and destination application layer identifiers to the unicast session.

[0145] In some embodiments, the first method further includes transmitting a second request to the target UE to establish a unicast session and receiving a response from the target UE containing a set of link identifiers (e.g., a ULI set). In this embodiment, determining whether an active unicast session already exists between the source application layer identifier and the target application layer identifier is based on the response from the target UE. In some embodiments, the response from the target UE includes all existing active unicast sessions of the target UE as metadata.

[0146] In some embodiments, the first method further includes maintaining a second set of link identifiers for the source UE, each link identifier being associated with a pair of source and target application layer identifiers. In this embodiment, determining whether an active unicast session with the target UE already exists based on the response includes determining whether a matching link identifier exists in the link identifier set included in the response and the second link identifier set.

[0147] In some embodiments, the second request includes a second set of link identifiers as metadata. In some embodiments, the response includes an indication of a matching link identifier. In some embodiments, reusing an existing active unicast session includes selecting a matching link identifier and constructing a unicast link profile that maps the unicast session requested in the first request to an existing active unicast session.

[0148] The embodiments may be practiced in other specific forms. These embodiments should be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All variations falling within the equivalent meaning and scope of the claims should be covered within their scope.

Claims

1. A user equipment (UE), comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured to cause the UE to: Receive a sidechain license for sidechain communication, wherein the sidechain license is associated with a plurality of candidate feedback resources, and wherein Hybrid Automatic Repeat Request (HARQ) feedback is enabled for multicast sidechain communication; The HARQ feedback mode for the sidechain communication is selected based at least in part on the group size of the UE group including the UE and the number of candidate feedback resources; The range requirements for the sidechain communication are determined, at least in part, based on the selected HARQ feedback mode; and The sidechain communication is performed based on one or more of the selected HARQ feedback mode or the determined scope requirements of the sidechain communication.

2. The UE of claim 1, wherein, The HARQ feedback modes include a negative-only confirmation mode or a positive-negative confirmation mode.

3. The UE of claim 1, wherein, The at least one processor is configured to enable the UE to transmit a semi-static configuration of the Physical Sidechain Feedback Channel (PSFCH) resources.

4. The UE of claim 3, wherein, The semi-static configuration indicates the conditions for using the corresponding HARQ feedback mode.

5. The UE according to claim 1, wherein, The at least one processor is configured to cause the UE to: transmit sidechain control information (SCI), the SCI indicating the use of a first HARQ feedback mode based on a transmitter-receiver distance satisfying a threshold.

6. The UE according to claim 1, wherein, The at least one processor is configured to cause the UE to: send a sidechain control information (SCI) indicating the use of a first HARQ feedback mode based on a priority threshold for sidechain communication.

7. The UE according to claim 1, wherein, The at least one processor is configured to cause the UE to: determine the reliability requirements corresponding to the sidechain communication, and wherein, in order to select the HARQ feedback mode, the at least one processor is configured to cause the UE to: further select based on the reliability requirements.

8. The UE according to claim 7, wherein, The at least one processor is configured to cause the UE to: send a sidechain control information (SCI) indicating the use of a first HARQ feedback mode based on the reliability requirement meeting a threshold.

9. The UE according to claim 8, wherein, The threshold is based on the minimum communication range (MCR) associated with the sidechain communication.

10. The UE according to claim 7, wherein, In order to select the HARQ feedback mode, the at least one processor is configured to make the UE: At least in part based on the reliability requirement meeting the threshold, the first HARQ feedback mode is assigned to a subset of the UE group; as well as Assign the second HARQ feedback mode to the rest of the UE group. The HARQ feedback mode includes a positive-negative confirmation mode, and the second HARQ feedback mode includes a negative-only confirmation mode.

11. A processor for wireless communication, comprising: At least one controller, coupled to at least one memory, and configured to cause the processor to: Receive a sidechain license for sidechain communication, wherein the sidechain license is associated with a plurality of candidate feedback resources, and wherein Hybrid Automatic Repeat Request (HARQ) feedback is enabled for multicast sidechain communication; The HARQ feedback mode for the sidechain communication is selected based at least in part on the group size of the UE group and the number of candidate feedback resources; The range requirements for the sidechain communication are determined, at least in part, based on the selected HARQ feedback mode; and The sidechain communication is performed based on one or more of the selected HARQ feedback mode or the determined sidechain communication range requirements.

12. The processor according to claim 11, wherein, The HARQ feedback modes include a negative-only confirmation mode or a positive-negative confirmation mode.

13. The processor according to claim 11, wherein, The at least one controller is configured to cause the processor to: send a semi-static configuration of the Physical Sidechain Feedback Channel (PSFCH) resources, wherein the semi-static configuration indicates conditions for using the corresponding HARQ feedback mode.

14. The processor of claim 11, wherein, The at least one controller is configured to cause the processor to: send a sidechain control information (SCI) indicating the use of a first HARQ feedback mode based on a transmitter-receiver distance satisfying a threshold.

15. The processor according to claim 11, wherein, The at least one controller is configured to cause the processor to: send a sidechain control information (SCI) indicating the use of a first HARQ feedback mode based on a priority threshold for sidechain communication.

16. The processor of claim 11, wherein, The at least one controller is configured to cause the processor to: determine the reliability requirements corresponding to the sidechain communication, and wherein, in order to select the HARQ feedback mode, the at least one controller is configured to cause the processor to: further select based on the reliability requirements.

17. The processor of claim 16, wherein, The at least one controller is configured to cause the processor to: send a sidechain control information (SCI) indicating the use of a first HARQ feedback mode based on the reliability requirement meeting a threshold.

18. The processor of claim 17, wherein, The threshold is based on the minimum communication range (MCR) associated with the sidechain communication.

19. The processor of claim 16, wherein, In order to select the HARQ feedback mode, the at least one controller is configured to cause the processor to: At least in part based on the reliability requirement meeting the threshold, the first HARQ feedback mode is assigned to a subset of the UE group; as well as Assign the second HARQ feedback mode to the rest of the UE group. The HARQ feedback mode includes a positive-negative confirmation mode, and the second HARQ feedback mode includes a negative-only confirmation mode.

20. A method performed by a user equipment (UE), the method comprising: Receive a sidechain license for sidechain communication, wherein the sidechain license is associated with a plurality of candidate feedback resources, and wherein Hybrid Automatic Repeat Request (HARQ) feedback is enabled for multicast sidechain communication; The HARQ feedback mode for the sidechain communication is selected based at least in part on the group size of the UE group including the UE and the number of candidate feedback resources; The range requirements for the sidechain communication are determined, at least in part, based on the selected HARQ feedback mode; and The sidechain communication is performed based on one or more of the selected HARQ feedback mode or the determined sidechain communication range requirements.

Images