Unicast session over a direct communication link

Abstract

Apparatuses and methods for determining whether an active unicast session can be reused are disclosed. A device (107) receives (305), for example, from an internal application or operating system (107), a first request to establish a unicast session to a first UE (105) over a direct communication link. Here, the first request indicates a source application layer identifier of the device and a destination 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 destination application layer identifier. If an active unicast session already exists between the source application layer identifier and the destination application layer identifier, the device reuses (315) the existing active unicast session. Otherwise, the device establishes (320) a new unicast session between the device and the first UE.

Description

[0001] Cross - Reference to Related Applications

[0002] 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 hereby incorporated by reference in its entirety. TECHNICAL FIELD

[0003] The subject matter disclosed herein generally relates to wireless communications, and more particularly, to the transmission of unicast sessions over a direct communication link. BACKGROUND OF THE INVENTION

[0004] The following abbreviations are hereby defined, at least some of which are referenced in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation Core Network (“5GC”), 5th Generation System (“5GS”), Absolute Radio Frequency Channel Number (“ARFCN”), Authentication, Authorization and Accounting (“AAA”), Access and Mobility Management Function (“AMF”), Access Restricted Local Operator Service (“ARLOS”), Acknowledgement (“ACK”), Application Programming Interface (“API”), Authentication Center (“AuC”), Access Stratum (“AS”), Autonomous Uplink (“AUL”), AUL Downlink Feedback Information (“AUL-DFI”), Base Station (“BS”), Binary Phase Shift Keying (“BPSK”), Bandwidth Part (“BWP”), Cipher Key (“CK”), Clear Channel Assessment (“CCA”), Control Element (“CE”), Cyclic Prefix (“CP”), Cyclic Redundancy Check (“CRC”), Channel State Information (“CSI”), Common Search Space (“CSS”), Connected Mode (“CM”, which is a NAS state in 5GS), Core Network (“CN”), Control Plane (“CP”), Data Radio Bearer (“DRB”), Dedicated Short Range Communications (“DSRC”), Discrete Fourier Transform Spread (“DFTS”), Downlink Control Information (“DCI”), Downlink (“DL”), Downlink Pilot Time Slot (“DwPTS”), Dual Connectivity (“DC”), Dual Registration Mode (“DR mode”), Discontinuous Transmission (“DTX”), Enhanced Clear 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”,is the NAS state in EPS), Evolved UMTS Terrestrial Radio Access ("E-UTRA"), E-UTRA Absolute Radio Frequency Channel Number ("EARFCN"), Evolved UMTS Terrestrial Radio Access Network ("E-UTRAN"), European Telecommunications Standards Institute ("ETSI"), Frame-Based Equipment ("FBE"), Frequency Division Duplexing ("FDD"), Frequency Division Multiple Access ("FDMA"), Frequency Division Orthogonal Cover Code ("FD-OCC")), General Packet Radio Service ("GPRS"), General Public Service Identifier ("GPSI"), Guard 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"), Information Element ("IE"), Integrity Key ("IK"), Internet of Things ("IoT"), International Mobile Subscriber Identity ("IMSI"), Key Derivation Function ("KDF"), Licensed-Assisted Access ("LAA"), Load-Based Equipment ("LBE"), Listen-Before-Talk ("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"), Mobile Station International Subscriber Directory Number ("MSISDN"), Multi-User Shared Access ("MUSA"), NarrowBand ("NB"), Negative ACKnowledgement ("NACK") or ("NAK"), New Generation ("5G") Node B ("gNB"), New Generation Radio Access Network ("NG-RAN", the 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 Assistance Information ("NSSAI"), Operation and Maintenance System ("OAM"), Orthogonal Frequency Division Multiplexing ("OFDM"), Packet Data Unit ("PDU", used in combination with "PDU session"), Packet Switching ("PS",For example, packet switched domain or packet switched service), primary cell (“PCell”), physical broadcast channel (“PBCH”), physical cell identifier (“PCI”), physical downlink control channel (“PDCCH”), physical downlink shared channel (“PDSCH”), pattern division 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”,indicating NAS layer procedures and states), Remaining Minimum System Information (“RMSI”), Resource Spread 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 Assistance Information (“S-NSSAI”), Single Registration Mode (“SR mode”), Sounding Reference Signal (“SRS”), System Information Block (“SIB”), Synchronization Signal (“SS”), Supplementary Uplink (“SUL”), Subscriber Identity Module (“SIM”), Tracking Area (“TA”), Transport Block (“TB”), Transport Block Size (“TBS”), Time Division 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 / Device (Mobile Terminal) (“UE”), UE Configuration Update (“UCU”), UE Routing Selection 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 Slot (“UpPTS”), Ultra-Reliable and Low-Latency Communication (“URLLC”), Access Public Land Mobile Network (“VPLMN”) and Worldwide Interoperability for Microwave Access (“WiMAX”). As used herein, HARQ-ACK may be used to collectively represent positive acknowledgment (“ACK”), negative acknowledgment (“NACK”), and Discontinuous Transmission (“DTX”). ACK means that the TB was correctly received, while NACK (or NAK) means that the TB was incorrectly received. DTX indicates that the TB was not detected.,

[0005] In some wireless communication systems, unicast communication on PC5 is used to support V2X communication. However, starting from Release 15 of 3GPP, there is no link layer mechanism for unicast communication on PC5. SUMMARY OF THE INVENTION

[0006] Disclosed is a process for determining whether an active unicast session can be reused. A method for a UE to determine whether an active unicast session can be reused, for example, includes receiving a first request to establish a unicast session to a target UE (i.e., a second UE) via a direct communication link from an internal application (e.g., a V2X application or an OS running on the source UE). 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more specific description of the embodiments briefly described above will be presented by referring to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings only depict some embodiments and should not be considered as limiting the scope. The embodiments will be described and explained with additional features and details by using the drawings, where:

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

[0009] Figure 2 is a schematic diagram showing an embodiment of a process for determining whether an active unicast session can be reused;

[0010] Figure 3 is a flowchart showing an embodiment of a method that can be used to determine whether an active unicast session can be reused;

[0011] Figure 4A is a schematic diagram showing an embodiment of a process for reusing an existing unicast session for multiple V2X services between the same pair of UEs; and

[0012] Figure 4B Continue Figure 4A the process;

[0013] Figure 5A is a schematic diagram showing an embodiment of a process for reusing the same RRC connection to transmit multiple unicast sessions of multiple V2X services; and

[0014] Figure 5B Continue Figure 5A the process;

[0015] Figure 6 FIG. 2 is a schematic diagram showing an embodiment of a user equipment device that can be used to determine whether an active unicast session can be reused. DETAILED DESCRIPTION

[0016] Those skilled in the art should understand that multiple aspects of the embodiments can be embodied as a system, a device, a method, or a program product. Therefore, the embodiments can take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects.

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

[0018] In addition, the embodiments can take the form of a program product implemented in one or more computer-readable storage devices, which store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device can be tangible, non-transitory, and / or non-transmissive. The storage device may not contain a signal. In certain embodiments, the storage device only uses a signal for accessing the code.

[0019] Any combination of one or more computer-readable media can be utilized. The computer-readable medium can be a computer-readable storage medium. The computer-readable storage medium can be a storage device that stores the code. The storage device can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

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

[0021] The code for performing 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++, etc., and traditional procedural programming languages such as the "C" programming language, and / or machine languages such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone 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 connection, 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 using an Internet service provider).

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

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

[0024] Aspects of the embodiments are described below with reference to the schematic flowcharts and / or schematic block diagrams of methods, apparatuses, 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, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing device create means for implementing the functions / operations specified in the flowcharts and / or block diagrams.

[0025] The code can also be stored in a storage device that can direct 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 manufacture including the instructions that implement the functions / operations specified in the flowcharts and / or block diagrams.

[0026] The code can also be loaded onto a computer, other programmable data processing device, or other device, such that a series of operational steps are performed on the computer, other programmable device, or other device to produce a computer-implemented process, such that the code executed on the computer or other programmable device provides a process for implementing the functions / operations specified in the flowcharts and / or block diagrams.

[0027] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, 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 that includes one or more executable instructions for implementing the specified (one or more) logical functions.

[0028] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks or portions thereof of the figures shown.

[0029] Although various arrow types and line types may be employed in flowcharts and / or block diagrams, it should be understood that they do not limit the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiments. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware that performs a particular function or operation, or a combination of dedicated hardware and code.

[0030] The description of elements in each figure may refer to elements of the foregoing figures. Like numbers refer to like elements in all figures, including alternative embodiments of the same element.

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

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

[0033] Figure 1 A wireless communication system 100 is shown for transmitting a unicast session via a direct communication link over a V2X communication signal 125 in accordance with an embodiment of the present disclosure. 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 be composed of base station units 110, and the remote unit 105 communicates with the base station units 110 using wireless communication links 115. Although in Figure 1A specific number of remote units 105, base station units 110, wireless communication links 115, RAN 120, and mobile core network 140 are shown, but 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.

[0034] In one implementation, RAN 120 complies with the 5G system specified in the 3GPP specifications. In another implementation, RAN 120 complies with the LTE system specified in the 3GPP specifications. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication networks, such as WiMAX, and other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

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

[0036] The remote unit 105 may communicate directly with one or more base station units 110 in the RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, the UL and DL communication signals may be carried over the wireless communication link 115. Here, the RAN 120 is an intermediate network that provides access to the mobile core network 140 for the remote unit 105.

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

[0038] The base station unit 110 can be distributed over a geographical area. In certain embodiments, the base station unit 110 may also be referred to as an access terminal, an access point, a base point, a base station, a Node-B, an eNB, a gNB, a home Node-B, a relay node, or any other term used in the art. The base station unit 110 is generally 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. The base station unit 110 is connected to the mobile core network 140 via the RAN120.

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

[0040] 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 with the mobile core network 140. Each mobile core network 140 belongs to a single Public Land Mobile Network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0041] The mobile core network 140 includes a number of Network Functions (“NFs”). As shown, the mobile core network 140 includes multiple User Plane Functions (“UPFs”) 141. The mobile core network 140 also includes multiple control plane functions, including but not limited to: an Access and Mobility Management Function (“AMF”) 143, which serves the RAN 120; a Session Management Function (“SMF”) 145; a Policy Control Function (“PCF”) 147; and a Unified Data Management Function (“UDM”) 149. In certain embodiments, the mobile core network 140 may also include an Authentication Server Function (“AUSF”), a Network Repository Function (“NRF”) (used by various NFs to discover and communicate with each other via APIs), or other NFs defined for the 5GC.

[0042] 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, a “network slice” refers to a part of the mobile core network 140 optimized for a specific traffic type or communication service. A network instance may be identified by an S-NSSAI, while the set of network slices authorized for the remote unit 105 is identified by an NSSAI. In certain embodiments, various network slices may include separate instances of network functions, such as the SMF 145 and the UPF 141. In some embodiments, different network slices may share some common network functions, such as the AMF 143. For ease of illustration, Figure 1 the different network slices are not shown, but their support is assumed.

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

[0044] Although Figure 1Components of a 5G RAN and a 5G core network are shown, but the embodiments for sidelink HARQ operations in NR V2X communications are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth, ZigBee, Sigfox, etc. For example, in an LTE variant involving EPC, the AMF 143 can be mapped to the MME, the SMF can be mapped to the control plane part of the PGW and / or to the MME, the UPF can be mapped to the SGW and the user plane part of the PGW, the UDM / UDR can be mapped to the HSS, etc.

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

[0046] Currently, the unicast communication mode is only supported on the NR-based PC5 reference point. 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").

[0047] After successfully establishing the 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, e.g., as specified in clause 5.6.1.4 (v0.3.0) of 3GPP TS23.287. The V2X layer of the transmitting UE indicates to the AS layer 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 when sending a message through the established PC5 link. If it is a PC5-S signaling message, the V2X layer of the receiving UE processes the message, while if it is an application data message, the V2X layer of the receiving UE forwards the message to the upper layer.

[0048] Note that the unicast mode supports a per-flow QoS model. During unicast link establishment, each UE self-assigns 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 UEB, and a set of (one or more) PC5 QoS flow identifiers ((one or more) PFIs). Each PFI is associated with QoS parameters (e.g., PQI and an optional range).

[0049] Regardless of how the application layer identifier and layer 2 ID change, the PC5 link identifier and (one or more) PFIs are invariant values for an established unicast link. The UE uses the PFI to indicate the PC5 QoS flow to the AS layer, so that even if the source and / or destination layer 2 ID is changed (e.g., due to privacy support), the AS layer can identify the corresponding PC5 QoS flow. The UE uses the PC5 link identifier to indicate the PC5 unicast link to the V2X application layer, so that the V2X application layer can identify the corresponding PC5 unicast link, 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).

[0050] In some embodiments, the remote unit 105 reuses an existing unicast session for multiple V2X services between the same pair of UEs, as described in further detail below with reference to Figures 4A to 4B In some embodiments, the remote unit 105 reuses the same RRC connection to transmit multiple unicast sessions between the same pair of UEs, as described in further detail below with reference to Figures 5A to 5B In further detail.

[0051] In the following description, the term eNB / gNB is used for the base station, but it can be replaced by any other radio access node, e.g., BS, eNB, gNB, AP, NR, etc. In addition, the operations in the context of 5G NR are mainly described. However, the proposed solution / method is also equally applicable to other mobile communication systems in which the serving cell / carrier is configured for sidelink communication via the PC5 interface.

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

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

[0054] After successfully establishing the 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 clause 5.6.1.4 (v0.3.0) of 3GPP TS 23.287. When sending a message 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, disconnect request / response) or service data transmission. If it is a PC5-S signaling message, the V2X layer 220 of the target / receiving UE-B 210 processes the message, and if it is an application data message, the V2X layer 220 of UE-B 210 forwards the message to the upper layer (i.e., the application layer 215).

[0055] Note that the unicast mode supports a per-flow QoS model. During unicast link establishment, each UE 205 - 210 self-assigns 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 the set of (one or more) PC5 QoS flow identifiers ("PFI"). Each PFI is associated with QoS parameters (e.g., PQI and optional range).

[0056] According to Release 15 of 3GPP, regardless of the changes in the application layer identifier and layer 2 ID, the PC5 link identifier and the (one or more) PFIs are invariant values for an established unicast link. UEs 205 - 210 use the PFI to indicate the PC5 QoS flow to the AS layer 225. Thus, even if the source and / or destination layer 2 ID is changed (e.g., due to privacy support), the AS layer can identify the corresponding PC5 QoS flow. UEs 205, 210 use the PC5 link identifier to indicate the PC5 unicast link to the V2X application layer 215. Thus, the V2X application layer 215 can identify the corresponding PC5 unicast link 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).

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

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

[0059] Method 300 begins and receives (305) a first request from an internal application (e.g., a V2X application or an OS running on a 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. More details of the first request are described below.

[0060] 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.

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

[0062] 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. More details of establishing a new unicast session are described below. Method 300 ends.

[0063] Figures 4A to 4B Process 400 is shown for determining whether an active unicast session can be reused according to an embodiment of the present disclosure. Process 400 shows that a source UE 405 reuses an existing unicast session for multiple V2X services between the same pair of UEs (i.e., the source UE 405 and the target UE 410). Here, the source UE 405 may be an embodiment of the UE-A 205, and the target UE 410 may be an embodiment of the UE-B 210. Figures 4A to 4B Represents an example of a second solution for transmitting a unicast session via a direct communication link. Process 400 may extend the above method 300. In various embodiments, when a V2X application requests to send a message via a unicast session for a different V2X service (e.g., a different PSID), the source UE 405 may reuse the existing unicast session between the same pair of UEs.

[0064] In some embodiments, the source UE 405 initiates a new unicast session request, where the request includes an existing active unicast link identifier as metadata. Here, the target UE 410 checks the (one or more) unicast link identifiers included in the request and determines whether there is already an active unicast session between the source UE 405 and the target UE 410. If the target UE 410 identifies a match, the target UE 410 includes the existing unicast link identifier ("ULI") in the unicast link session response. Note that the matching ULI can be a matching source and target application layer ID. The source UE 405 checks the response and determines whether the existing unicast link session can be reused.

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

[0066] In step 2, the source UE 405 retrieves the default destination layer 2 ID for the V2X service (PSID) for establishing the unicast session (existing process) (see block 420).

[0067] In step 3, the source UE 405 self-assigns a new ULI (since the source UE 405 does not know at this time whether it can reuse an existing unicast link or whether it wants 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 block 425). In some embodiments, the metadata includes the target application layer identifier and the source application layer identifier.

[0068] 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: the source application layer identifier, the target application layer identifier, the source layer 2 identifier (the layer 2 identifier of the source UE 405), the "default" destination layer 2 ID (i.e., from step 2), the generated ULI, and a set of unicast link identifiers as metadata, the set of unicast link identifiers being used to identify the (one or more) active unicast sessions.

[0069] In step 5, the target UE 410 receives the unicast request and identifies that it is the target of the direct communication request based on the application layer identifier (see block 435).

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

[0071] Continue Figure 4B , at step 7, the target UE 410 responds to the unicast link request by sending a direct communication acceptance message (see message 445). Here, the direct communication acceptance 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 the (one or more) matching ULIs as metadata.

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

[0073] In step 9, the source UE 405 constructs a unicast link profile that includes 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. The source UE 405 associates the unicast link with a unicast link identifier (see box 455).

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

[0075] In step 11, the target UE 410 constructs a unicast link profile and associates it with the existing ULI (see box 465). Here, the unicast link profile can 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.

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

[0077] 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, and the UE includes the PC5 link identifier in the request for the unicast session. The PC5 link identifier can be generated by the transmitting UE itself and signaled to the target UE in the DCR message. When the target UE receives the request for a unicast session via PC5, the UE identifies whether they are the target UE by checking the application layer identifier included in the request.

[0078] If the UE identifies that it is the target UE, the UE self-assigns a PC5 link identifier and maps it to the PC5 link identifier of the source UE. The target UE constructs a unicast link profile that includes the source link identifier and the target PC5 link identifier, layer 2 address, and application layer identifier, and maps the unicast link profile to the source link identifier and the target PC5 link identifier. Then, the target UE responds to the source UE by including the source and target PC5 link identifiers in the unicast link response over PC5. In addition, the source UE creates a unicast link profile that contains the source and target PC5 link identifiers, layer 2 address, and 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. In addition, both the source UE and the target UE announce such a unicast link identifier to the application layer.

[0079] Figures 5A to 5B Process 500 for determining whether an active unicast session can be reused according to an embodiment of the present disclosure is shown. Process 500 shows the source UE 405 reusing the same RRC connection to transmit multiple unicast sessions for multiple V2X services to the target UE 410. Figures 5A to 5B An example representing a third solution for transmitting multiple unicast sessions over a direct communication link is shown. Process 500 can extend the above method 300.

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

[0081] In step 2, the source UE 405 retrieves the default destination layer 2 ID for the V2X service (PSID) for establishing the unicast session (see block 510).

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

[0083] 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 target 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 identifying the (one or more) active unicast sessions (as metadata).

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

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

[0086] Continue Figure 5B , at step 7, the target UE 410 also identifies whether the target UE 410 has an (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).

[0087] In step 8, the target UE 410 responds to the unicast link request by sending a direct communication acceptance message (see message 540). Here, the direct communication acceptance message includes: the "actual" 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 (the ULI of the source UE 405), and the (one or more) matching ULIs as metadata.

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

[0089] In steps 10a and 10b, both applications associate the unicast link with a unicast link identifier (see boxes 550 and 555).

[0090] In steps 11a and 11b, source UE 405 and target UE 410 determine that the same RRC connection between the two UEs can be used to provide the (one or more) matching unicast sessions based on the matching ULI (see boxes 560 and 565).

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

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

[0093] According to the fourth solution for transmitting unicast sessions over a direct communication link, the source UE can create a random number of bits, e.g., 16 bits (referred to as "ULI-x"), and send the ULI-x together with metadata to the target UE. Reviewing procedures 400 and 500, both include the exchange of metadata, e.g., in the direct communication request and direct communication response. 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.

[0094] 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 UE and the target UE update their metadata accordingly. In one embodiment, the UE updates the metadata of the UE by adding the layer 2 source ID and destination ID associated with the new session ID to the existing profile for ULI-a. In another embodiment, the UE updates the metadata of the UE by creating a new context with ULI-x for the newly created session and adding the layer 2 source ID and destination ID. In the case where an existing unicast session cannot be reused, ULI-x is passed to the access stratum, and the access stratum creates a PC5-RNTI based on this. This can be done by either adopting the entire ULI (ULI-x in the current example), or a part thereof (such as the 8 MSB bits) and appending 8 randomly generated bits, or even just by generating a PC5-RNTI with 16 randomly generated bits.

[0095] In the above embodiments, 16 bits are taken as an example only, 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 dense traffic scenario) generate the same random identity. If a collision occurs (e.g., more than one transmitter UE simultaneously uses the same randomly generated identity towards 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 intended for them, e.g., based on the station ID, temporary UE identity, application ID, or the like.

[0096] In this case, 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), indicating to the receiver to discard the questionable identity (or identities) and start over by generating a new random number. As an optimization, the collision is only notified to the sender of the previous message where the collision is detected, and then that sender is responsible for starting over by generating a new random number to the (default) destination ID of the corresponding PC5-S link.

[0097] The PC5-RNTI is carried in each PC5-RRC message, and the target responds with a PC5-RRC message including the same PC5-RNTI. Part (or all) of the PC5-RNTI can also be used at the target UE for filtering in the physical layer (e.g., in the SCI).

[0098] Note that the PC5 RNTI (RRC connection on PC5) may be released explicitly by either UE when all V2X applications are terminated and upper layer identities (application identity, L2 identity, PLI and / or ULI) need to be released, or implicitly when a timer used to monitor inactivity expires.

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

[0100] In any of the above schemes, if both V2X services are operating in the same operation mode (e.g., both are in coverage or both are out of coverage), the source UE or the target UE determines whether the existing unicast session can be reused.

[0101] In any of the above schemes, if a unicast session is lost, both UEs can resume the unicast session by advertising the unicast link identifiers of all active unicast sessions. The UE transmits the unicast link identifier based on a preconfigured timer. If the timer expires, the UE deletes the unicast link identifier and the associated unicast link profile.

[0102] In any of the above solutions, instead of the source UE transmitting the active ULI as metadata (e.g., step 4 in processes 400 and 500), the target UE may include all active ULIs in the DCR response (an advantage is that this approach does not require all active ULIs to be transmitted in a 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 (embodiment 1) and / or notifies the target UE that the same unicast session can be used (embodiment 2).

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

[0104] According to a fifth solution for transmitting unicast sessions over direct communication links, a transmitter UE and a receiving UE solicit and provide PC5 HARQ feedback for PSSCH transmissions by the transmitter UE (i.e., the source UE) to one or more receiver UEs. In various embodiments, the transmitter UE is aware of the total number of member UEs in the group based on upper layer information, e.g., upper layer(s) provide the total number of UEs in the group to lower layer(s). This knowledge at the physical layer is accurate to the extent required for physical layer functionality at any given point in time; even if group membership is updated, the physical layer is notified within a relatively short timeframe.

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

[0106] When SL HARQ feedback is enabled for unicast, in the case of 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.

[0107] When SL HARQ feedback is enabled for multicast, using the TX-RX distance and / or RSRP to decide whether to send HARQ feedback is supported. In the case of non-CBG operation, the following two options are supported:

[0108] According to SL HARQ feedback option 1, if the corresponding TB fails to be decoded after decoding the associated PSCCH, the receiver UE (i.e., the target UE) transmits a 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, no HARQ-ACK is transmitted on the PSFCH).

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

[0110] Based on the knowledge of the total number of member UEs in the group, the physical layer of the transmitter UE can determine the number of feedback resources required. The determination of the required feedback resources will be based on the physical layer structure yet to be finally determined in 3GPP. The transmitter UE making this decision will compare the number of group member UEs, the number of available feedback resources, and the reliability required for a specific V2X message. The 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 5 "9s", 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 can be used. For lower required reliability, if the total number of member UEs in the group is higher compared to the available feedback resources, option 1 can be used alone; or, options 1 and 2 can be used in combination.

[0111] As shown above, the resources actually utilized for HARQ feedback can be less than those determined by the transmitter. This is because HARQ feedback is only required from the (one or more) receiver UEs within the MCR (Minimum Communication Range). At first, this may sound like a waste of resources, but in fact it avoids the high complexity that would occur if the transmitter had to know in advance the real-time distance of each receiver UE.

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

[0113] Different thresholds for each of these items can lead to a combination of using either option or a certain hybrid of these options.

[0114] 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 case of a shortage of feedback resources, based on the distance threshold, Option 1 is used for the remaining UEs closer to the transmitter. The distance threshold is calculated as the ratio of the remaining UEs in the group to the total receiver UEs multiplied by the MCR (Minimum Communication Range).

[0115] 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, Option 1 is used.

[0116] In V2X communication in Mode 1 (i.e., V2X based on network scheduling of NR), in addition to the (re)transmission resources, the transmitter UE also needs to request feedback resources from the gNB. Therefore, the transmitter UE needs to inform the gNB of the number of member UEs in the group destination (to which the transmitter will send the expected V2X message(s)). For each destination of the group destination that the transmitter expects to transmit to, this information, together with the size, period, etc. of the V2X message, needs to be informed to the gNB. This information can be carried in a message similar to the sidelink UE information and / or NR UE assistance information defined in the LTE RRC (36.331) specification. For each group that 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, etc. of the V2X message.

[0117] After receiving a UE request, the gNB provides transmission resources and PC5 HARQ feedback time-frequency and code resources accordingly in V2X communication of mode 1. As a signaling optimization, a certain time-frequency offset can be used to link the feedback resources with the PSSCH transmission resources. All codes can be used by the transmitting UE, or can be signaled explicitly by the gNB to the transmitter.

[0118] The number of PC5 feedback resources for retransmission can be the same as the number of PC5 feedback resources for transmission and can be obtained in a similar way as for transmission, as described above. Thus, in V2X communication of mode 1, the time-frequency PC5 HARQ feedback resources for (re)transmission are obtained explicitly from the gNB or using an offset relative to the PSSCH resources. For PC5 HARQ feedback transmission, all codes can be used by the transmitting UE, or all codes can be signaled explicitly by the gNB to the transmitter.

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

[0120] Figure 6 A user equipment device 600 is shown that can be used to determine whether an active unicast session can be reused according to an embodiment of the present disclosure. In various embodiments, the user equipment device 600 is used to implement one or more of the above solutions. The user equipment device 600 can be an embodiment of the above remote unit 105, UE-A 205, and / or source UE 405. In addition, the user equipment device 600 can 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 touch screen. In certain 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 can 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.

[0121] In one embodiment, processor 605 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, processor 605 can be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or a 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.

[0122] In various embodiments, processor 605 controls user equipment device 600 to implement the above UE behavior. In some embodiments, processor 605 receives, for example, a first request 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 the source application layer identifier of the device and the 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.

[0123] If an active unicast session already exists between the source application layer identifier and the target application layer identifier, processor 605 re-uses the existing active unicast session between device 600 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, processor 605 establishes a new unicast session between device 600 and the target UE.

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

[0125] In some embodiments, processor 605 generates a link identifier for the requested unicast session. In such an embodiment, the link identifier maps the source and target application layer identifiers to the unicast session.

[0126] 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, the response including a set of link identifiers. In such an 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 certain embodiments, the response from the target UE includes all existing active unicast sessions of the target UE as metadata.

[0127] In some embodiments, the processor 605 maintains a second set of link identifiers for the device, each link identifier 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 the response includes determining whether there is a matching link identifier among the set of link identifiers included in the response and the second set of link identifiers.

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

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

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

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

[0132] In one embodiment, the output device 620 is designed to output visual, audible, and / or tactile signals. In some embodiments, the output device 620 includes an electronically controllable display or display device capable of outputting visual data to the user. For example, the output device 620 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to the user. As another non-limiting example, the output device 620 may include a wearable display, independent of but communicatively coupled to the remainder of the user equipment device 600 (such as a smartwatch, smart glasses, a head-up display, etc.). Additionally, the output device 620 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0133] In certain embodiments, the output device 620 includes one or more speakers for generating sound. For example, the output device 620 may generate an audible alert or notification (such as a beep or a chime). In some embodiments, the output device 620 includes one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the output device 620 may be integrated with the input device 615. For example, the input device 615 and the output device 620 may form a touch screen or a similar touch-sensitive display. In other embodiments, the output device 620 may be placed near the input device 615.

[0134] The transceiver 625 includes at least a transmitter 630 and at least one receiver 635. One or more transmitters 630 may be used to send messages to the RAN as described herein. Similarly, one or more receivers 635 may 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 device 600 may have any suitable number of transmitters 630 and receivers 635. Additionally, the (one or more) transmitters 630 and the (one or more) receivers 635 may be any suitable type of transmitter and receiver.

[0135] According to an embodiment of the present disclosure, a first apparatus for determining whether an active unicast session can be reused is disclosed herein. The first apparatus may be implemented by 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, from an internal application or operating system, a first request to establish a unicast session to a first UE (i.e., the target UE) via a direct communication link. Herein, 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.

[0136] 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, where the processor modifies the unicast link profile of the existing active unicast session to add the first V2X service. In certain embodiments, the unicast link profile is associated with an RRC connection, and reusing the existing active unicast session further includes reusing an existing RRC connection between the apparatus and the first UE.

[0137] In some embodiments, the processor generates a link identifier for the requested unicast session. In such an embodiment, the link identifier maps the source and target application layer identifiers to the unicast session.

[0138] 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 that contains a set of link identifiers. In such an 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 certain embodiments, the response from the first UE includes all existing active unicast sessions of the first UE as metadata.

[0139] In some embodiments, the processor maintains a second set of link identifiers of the apparatus, each link identifier associated with a pair of source and target application layer identifiers, where determining whether an active unicast session with the first UE already exists according to the response includes determining whether there is a matching link identifier among the set of link identifiers included in the response and the second set of link identifiers.

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

[0141] According to an embodiment of the present disclosure, a first method for determining whether an active unicast session can be reused is disclosed herein. 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, from an internal application (e.g., a V2X application or an OS running on the source UE), a first request 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 an 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. 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 does not exist between the source application layer identifier and the target application layer identifier.

[0142] In some embodiments, the first request is for a first V2X service and the existing active unicast session is associated with a second V2X service different from the first V2X service. In such an 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 such an embodiment, reusing the existing active unicast session further includes reusing the existing RRC connection between the source UE and the target UE.

[0143] In some embodiments, the first method includes generating a link identifier for the requested unicast session. In such an embodiment, the link identifier maps the source and target application layer identifiers to the unicast session.

[0144] In some embodiments, the first method further includes transmitting a second request to a target UE to establish a unicast session and receiving a response from the target UE, the response including a set of link identifiers (e.g., a set of ULIs). In such an 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 certain embodiments, the response from the target UE includes all existing active unicast sessions of the target UE as metadata.

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

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

[0147] Embodiments may be practiced in other specific forms. The embodiments are to be considered illustrative rather than restrictive in all respects. Accordingly, the scope of the invention is indicated by the appended claims rather than the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A method for a first User Equipment (UE), the method comprising: Receiving, from an internal application, a first request to establish a unicast session to a second UE via a direct communication link, wherein the first request indicates a source application layer identifier of the first UE and a target application layer identifier of the second UE; Determining 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, reusing the existing active unicast session between the first UE and the second UE; And In response to determining that no active unicast session exists between the source application layer identifier and the target application layer identifier, establishing a new unicast session between the first UE and the second UE.

2. The method according to claim 1, wherein, The first request is for a first Vehicle-to-Everything (V2X) service, and wherein the existing active unicast session is associated with a second V2X service different from the first V2X service, the method further comprising modifying the unicast link profile of the existing active unicast session to add the first V2X service.

3. The method according to claim 2, wherein The unicast link profile is associated with a Radio Resource Control (RRC) connection, wherein reusing the existing active unicast session further comprises reusing the RRC connection existing between the first UE and the second UE.

4. The method according to claim 1, further comprising: Generating a link identifier for the requested unicast session, the link identifier mapping the source application layer identifier and the target application layer identifier to the unicast session.

5. The method according to claim 1, further comprising: Transmitting a second request to the second UE to establish a unicast session; And Receiving a response from the second UE, the response comprising a set of link identifiers, wherein 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 second UE.

6. The method according to claim 5, wherein The response from the second UE includes all existing active unicast sessions of the second UE as metadata.

7. The method according to claim 5, further comprising: Maintaining a second set of link identifiers of the first UE, each link identifier associated with a pair of source application layer identifier and target application layer identifier, wherein determining whether an active unicast session with the second UE already exists according to the response includes determining whether there is a matching link identifier among the set of link identifiers included in the response and the second set of link identifiers.

8. The method according to claim 7, wherein The second request includes the second set of link identifiers as metadata.

9. The method according to claim 7, wherein, The response includes an indication of the matching link identifier.

10. The method according to claim 7, wherein Reusing the existing active unicast session includes selecting the matching link identifier and constructing a unicast link profile that maps the unicast session requested in the first request to the existing active unicast session.

11. A first User Equipment (UE) comprising: A transceiver; And A processor, wherein the processor performs: Receive a first request from an internal application to establish a unicast session to a second UE via a direct communication link, where the first request indicates a source application layer identifier of the first UE and a target application layer identifier of the second UE; Determine 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, reuse the existing active unicast session between the first UE and the second UE; and In response to determining that no active unicast session exists between the source application layer identifier and the target application layer identifier, establish a new unicast session between the first UE and the second UE.

12. The first UE according to claim 11, wherein, The first request is for a first vehicle-to-everything V2X service, and where the existing active unicast session is associated with a second V2X service different from the first V2X service, where the processor modifies the unicast link profile of the existing active unicast session to add the first V2X service.

13. The first UE according to claim 12, wherein, The unicast link profile is associated with a radio resource control RRC connection, where reusing the existing active unicast session further includes reusing the RRC connection existing between the first UE and the second UE.

14. The first UE according to claim 11, wherein, The processor generates a link identifier for the requested unicast session, the link identifier mapping the source application layer identifier and the target application layer identifier to the unicast session.

15. The first UE according to claim 11, wherein, The processor further performs: Transmit a second request to the second UE to establish a unicast session; And Receive a response from the second UE, the response containing a set of link identifiers, where 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 second UE.

16. The first UE according to claim 15, wherein, The response from the includes all existing active unicast sessions of the second UE, as metadata.

17. The first UE according to claim 15, wherein, The processor maintains a second set of link identifiers for the first UE, each link identifier associated with a pair of source application layer identifier and target application layer identifier, where determining whether an active unicast session with the second UE already exists according to the response includes determining whether there is a matching link identifier among the set of link identifiers included in the response and the second set of link identifiers.

18. The first UE according to claim 17, wherein, The second request includes the second set of link identifiers, as metadata.

19. The first UE according to claim 17, wherein, The response includes an indication of the matching link identifier.

20. The first UE according to claim 17, wherein, Reusing the existing active unicast session includes selecting the matching link identifier and constructing a unicast link profile that maps the unicast session requested in the first request to the existing active unicast session.

Images