Connectivity management solution for unicast and multicast communications on the eV2X support sidelink

Abstract

An apparatus of a first user equipment (UE) includes one or more baseband processors that generate a message for indicating to a second UE that the first UE intends to establish a new radio (NR) sidelink connection for an enhanced vehicle-to-everything (eV2X) service, and processes a response from the second UE regarding the message. The apparatus may include a memory for storing the message.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 737,515 (AB5636-Z), filed on September 27, 2018. Said application No. 62 / 737,515 is hereby incorporated by reference in its entirety. Background Art

[0003] As the use of fifth generation (5G) new radio (NR) radio access technology (RAT) becomes popular and widespread, and new ease of use for advanced vehicle-to-vehicle communications is identified, mechanisms for NR-based systems can be supported to meet the relevant requirements of these use cases. To this end, solutions for one-to-one and one-to-many connection establishment and management over NR sidelinks can be provided to allow unicast and multicast communications for enhanced vehicle-to-everything (eV2X) communications. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The claimed subject matter is particularly pointed out and distinctly described in the concluding portion of the specification. However, such subject matter may be understood by reference to the following detailed description when reading the accompanying drawings, wherein:

[0005] Figure 1 is an illustration of a generalized signaling flow for unicast connection management over a sidelink according to one or more embodiments.

[0006] Figure 2 is an illustration of a sidelink medium access control (MAC) subheader design for Long Term Evolution (LTE) according to one or more implementations.

[0007] Figure 3 is an illustration of a proposed sidelink medium access control (MAC) subheader structure for New Radio (NR) V2X according to one or more implementations.

[0008] Figure 4 The architecture of a system of networks according to some embodiments is shown.

[0009] Figure 5 Exemplary components of an apparatus according to some embodiments are shown.

[0010] It should be understood that for simplicity and / or clarity of illustration, the elements illustrated in the figures are not necessarily drawn to scale. For example, for clarity, the size of some elements may be enlarged relative to other elements. In addition, if deemed appropriate, reference numerals are repeated in the drawings to indicate corresponding and / or similar elements. DETAILED DESCRIPTION

[0011] In the following detailed description, a number of specific details are provided to provide a comprehensive understanding of the claimed subject matter. However, it will be appreciated by those skilled in the art that the claimed subject matter may be implemented without these specific details. In other cases, well-known methods, processes, components and / or circuits have not yet been described in detail.

[0012] In the following description and / or claims, the terms "coupled" and "connected" and their derivatives may be used. In a particular embodiment, "connected" may be used to indicate that two or more elements are in direct physical and / or electrical contact with each other. "Coupled" may represent that two or more elements are in direct physical and / or electrical contact. However, "coupled" may also refer to that two or more elements may not be in direct contact with each other, but may still cooperate and / or interact with each other. For example, "coupled" may refer to that two or more elements are not in direct contact with each other, but are indirectly joined together via another element or an intermediate element. Finally, the terms "on", "overlying" and "above" may be used in the following description and claims. "On", "overlying" and "above" may be used to indicate that two or more elements are in direct physical contact with each other. However, it should be noted that "above" may also refer to that two or more elements are not in direct contact with each other. For example, "above" may represent that an element is higher than another element but is not in contact with each other, and another one or more elements may be present between the two elements. Furthermore, the term "and / or" may mean "and", it may mean "or", it may mean "exclusive or", it may mean "one", it may mean "some but not all", it may mean "neither", and / or it may mean "both", but does not limit the scope of the claimed subject matter in this regard. In the following description and / or claims, the terms "include" and "comprising", along with their derivatives, may be used and are intended to be synonymous with each other.

[0013] refer to Figure 1 is an illustration of a generalized signaling flow for unicast connection management over a sidelink according to one or more embodiments. As the 3rd Generation Partnership Project (3GPP) Vehicle-to-Everything (V2X) standard evolves to incorporate advanced V2X use cases beyond road safety applications, there is a need to develop mechanisms that enable vehicle user equipment (UE) devices within communication range of each other to effectively satisfy such use cases. While these use cases are very diverse in functionality, one aspect that appears to be common among them is the need for one-to-one and one-to-many communication between different UEs. For example, for a convoy, the basic concept is that a group of vehicles of the same or different types (e.g., semi-trailers, buses, etc.) are grouped together into a convoy so that they can move in a coordinated manner while being aware of each other's status and their surroundings. This requires the lead vehicle to be able to effectively communicate with the individual vehicle UEs (V-UEs) to manage the convoy.

[0014] The LTE-based V2X design on the sidelink is inherently broadcast-based, i.e., all packets sent by the V-UE over the sidelink are sent blindly, i.e., without a specific recipient. Specifically, the destination field identifier (ID) in the media access control (MAC) subheader, which usually indicates the destination ID of the intended V-UE, is only mapped to the V2X service ID, such as the PSID or ITS-AID of the V2X application running at the transmitting UE. Therefore, it is impossible or actually unnecessary for the transmitting UE to know the UE that received the packet. In addition, there is no appropriate feedback mechanism at the receiving UE to notify the transmitting UE that it did receive the packet. Therefore, there is a clear need to solve this problem in order to meet the unicast / multicast requirements of advanced V2X use cases.

[0015] In this regard, the main aspect that needs to be supported by the sidelink is the establishment of a direct connection between two or more UEs involved in V2X communication. This basically means that the UEs should be aware of each other's presence and establish a connection and exchange the necessary information and related rules to agree on a common way of communication. In the context of V2X communication, this includes but is not limited to the following messages:

[0016] Notification of support of unicast / multicast communications for a given V2X service by a given UE (UE 1), followed by receipt of messages from interested UEs (UE 2)

[0017] Connection establishment message from UE 1 for secure link establishment

[0018] Response message from UE 2 accepting or rejecting the request

[0019] Any subsequent message exchange to mediate the communication rules (including QoS and L2 destination ID)

[0020] Data transmission for related V2X services

[0021] Keep-alive, connection modification signaling and any other control signaling exchanges

[0022] Once the connection is no longer needed, a teardown message from either UE

[0023] Confirmation of connection release message

[0024] The generalized signaling flow 100 corresponding to the messages listed above is Figure 1 Shown in. Figure 1 The flow 100 shown in FIG. 1 is between a first UE (UE 1) 110 and a second UE (UE 2) 112. The messages of the flow 100 may include, for example, service notification / discovery, connection establishment request, connection establishment response (accept), quality of service (QoS) mediation, data flow, keep-alive signaling, connection release signaling, and confirmation of connection release for a unicast connection.

[0025] An additional aspect to consider here is that the New Radio (NR) resource allocation for sidelink transmissions is expected to follow the 3GPP Long Term Evolution (LTE) mechanism by providing two different modes: network scheduled transmissions where the gNB schedules specific resources and autonomous resource reservation and / or reselection mode where the UE selects resources based on sensing. Therefore, the operation mode of the UE, i.e. network scheduled or autonomous resource selection, may have a potential impact on the ability of the UE to form a unicast connection. One of the main reasons for this is expected to be to guarantee some QoS requirements that are not provided by broadcast on the sidelink. Therefore, depending on the network configuration, the following two options may exist.

[0026] In the first option, a UE operating only in network scheduled resource allocation mode can initiate unicast connection establishment (and this is not always possible, depending on the UE operation mode). In this case, it is beneficial for the next generation NodeB (gNB) to mediate the connection establishment between the two UEs over the sidelink. This also provides a better way to meet the QoS requirements of specific V2X use cases by using dedicated resources allocated by the gNB.

[0027] In the second option, the UE in either mode may initiate connection establishment for unicast communication (i.e., communication agnostic to network coverage). Although this option may appear more flexible, it is questionable whether the autonomous resource selection mechanism can meet the stringent QoS requirements of advanced V2X applications unless specific resources are allocated to avoid potential conflicts.

[0028] To support this behavior in NR via sidelink, two main options can be considered. The first option reuses the connection management features and associated signaling from the Proximity Services (ProSe) architecture developed in LTE Release 15 (Rel-15). The original intention of supporting ProSe functionality was to enable a communication path to be established directly between two or more ProSe-enabled public safety UEs, such as law enforcement, fire services, etc., even if they are outside the coverage of the LTE network. The second option relies on extending the Radio Resource Control (RRC) connection management signaling to the sidelink, which is traditionally applicable to uplink / downlink communications between the network and the UE. As described below, two options can be analyzed to provide a technical solution for support via sidelink for NR.

[0029] Figure 2is an illustration of a sidelink media access control (MAC) subheader design for Long Term Evolution (LTE) according to one or more embodiments. In some examples, extensions to ProSe signaling may be provided. The key to one-to-one direct communication for ProSe is to establish a secure link on Layer 2 through the sidelink. At its core, this feature can be extended to the NR sidelink with V2X communications in mind. To do this, unique identifiers for both UEs are required to unambiguously identify the secure link. Source and destination Layer 2 IDs are used for ProSe, and when NR V2X is considered there are two options: reuse the same L2 identifier or define a new ID for NR V2X. In one embodiment, an existing L2 ID may be reused by extending the existing L2 ID from LTE. However, this approach adds the problem that the source L2 ID and the destination L2 ID cannot be guaranteed to be unique in ProSe. This problem is addressed in LTE by defining an additional "V" field 210 in the MAC subheader 200 to distinguish between unicast and multicast communications. Therefore, to enable this behavior in NR V2X, assuming the overall header structure from the LTE sidelink is reused, two feature structures can be utilized as described below.

[0030] The first characteristic structure is shown in Figure 2 In. Figure 2 The V field 210 shown may have an additional value indicating whether the destination field corresponds to a unicast identifier or a multicast identifier for V2X communications, similar to LTE ProSe. Currently, this only applies to the case of ProSe communications, so it is proposed to extend this to NR V2X communications as well. In this way, the UE can reuse the destination ID for unicast and multicast communications. The second feature structure is shown below Figure 2 shown in and relative to Figure 2 Give a description.

[0031] Figure 3 1 is an illustration of a proposed sidelink media access control (MAC) subheader structure for New Radio (NR) V2X according to one or more embodiments. The mapping rules of the L2 destination ID to the V2X service ID may be enhanced compared to LTE. Specifically, for LTE V2X, the destination Layer 2 ID is simply set to the identifier provided by the upper layer, regardless of whether it is for unicast or broadcast. However, for NR V2X, once the connection has been established, it may be set to the corresponding ID of the destination UE. At the same time, since there is only a single V2X service involving unicast communications for the UE, the V2X service ID also needs to be indicated in each packet.

[0032] In a first embodiment, a simple way to handle this is to include this information separately as part of the MAC sub-header 300. Thus, each packet contains the source ID and destination ID as well as the V2X service ID, making the source ID and destination ID independent of the V2X service ID. The MAC sub-header will then look like Figure 3 As shown, the SrvID field 310 may be reserved to explicitly indicate the V2X service identifier. Note that this may be achieved in different ways, for example, by having an intermediate layer perform a mapping from the V2X service ID to a different identifier for security reasons.

[0033] Alternatively, in a second embodiment, the mapping of the destination layer 2 ID to the V2X service may still be done by upper layers, as in LTE, and may be left to the upper layers to additionally ensure that the source ID and destination ID of the UE for each V2X service ID are unique, the V2X service ID 310 may be included in the information shared between the two UEs when establishing a connection, and need not be included in every packet. Of course, this may mean that the UE establishes multiple connections, one for each V2X service of interest, which has the disadvantage of additional complexity and does not seem to be the most preferred.

[0034] The following discusses Figure 1 Detail of the connection establishment process shown. Basically, once the UE has identified the source L2 ID for the V-UE interested in establishing a unicast connection, the first UE (UE 1) 110 directly sends a connection establishment request to the second UE (UE 2) 112 to trigger the secure connection establishment process. The content of the connection establishment request may be similar to ProSe, including but not limited to the following.

[0035] User information, which includes the UE identifier and the V2X application / service ID that triggered the connection establishment

[0036] The maximum inactivity period for this connection

[0037] Security-related information, such as security keys and capabilities

[0038] QoS related parameters, such as a list of Pro-Se per-packet priority (PPPP), ProSe per-packet reliability (PPPR), and other values ​​that are allowed to be sent over the connection

[0039] The network (NW) may allocate specific resources to UEs that are authorized to optionally initiate unicast communications for this purpose. When transmitting this message, a timer may be started at UE 1 to ensure that the UE is not stuck waiting for a response message from UE 2, and the connection request process may be retried or aborted subsequently. When receiving this message at UE 2, the UE may store the L2 ID and associate it with the link. UE 2 may perform additional processes, such as analyzing the UE information included in the message, determining whether the UE may consider security aspects and whether the indicated QoS parameters / configuration are acceptable. Based on this, UE 2 may then prepare to respond to the original message. If successful, UE 2 prepares a connection establishment accept message using the appropriate identifier determined from the received message and sends it to UE 1. Otherwise, a connection reject message may be sent, which includes an error cause value related to the reason why UE 2 did not accept the request. These values ​​may be the same as those used for ProSe connection establishment. Once UE 1 receives the connection accept response message from UE 2, it is assumed that the connection is established.

[0040] One modification to the above procedure could be the additional signaling steps to be defined in case QoS management / mediation needs to be done separately from the connection establishment step. However, it should be noted that the two are closely coupled. In fact, one of the main reasons why a UE has to establish a unicast connection for V2X communications is envisaged to be the need to meet specific QoS requirements that cannot be achieved through broadcast-based communications. During the lifetime of such a connection, any data packet to be sent from UE 1 to UE 2 (or vice versa) then follows the source L2ID and destination Layer 2ID, and optionally the V2X Service ID, and maps the specific QoS rules for that connection.

[0041] Keep-alive signaling is also supported in ProSe to handle the situation where no information is exchanged between two UEs for a period of time. This can also be extended to the NR V2X case, whereby UE 1 can send a dedicated message to UE 2 indicating that the connection should be kept active. This can be based on a timer implemented on the UE side, for example. It may also be necessary to change the source layer 2 ID and / or destination layer 2 ID of either UE for any reason. In addition, the QoS requirements of the link may change at any time. This information may also be included in the keep-alive signaling. In this case, the keep-alive message may include updated user information, which includes a new identifier to be used for subsequent communications and / or updated QoS related information for the link.

[0042] Once a connection needs to be torn down, UE 1 or UE 2 may transmit a connection release message over the side link. For example, if the message is no longer needed or in the case of a change in provisioning / configuration at the UE that no longer allows the connection to exist, the message may contain information about the specific cause that triggered the release message. The other UE may then acknowledge receipt of the message and clear any relevant timers / counters associated with the link. This ensures that both UEs are aware that the link has been successfully torn down.

[0043] In some embodiments, radio resource control (RRC) signaling may be utilized. The radio resource configuration protocol is defined in LTE and NR and forms the backbone of all relevant signaling between the network and the UE. There are multiple individual services and functions served by the RRC layer protocol. At the most basic level, it is used for the establishment and maintenance of a dedicated RRC connection between the UE and the NW and the management of the associated RRC protocol state. With respect to V2X sidelink operations, the RRC layer is responsible for the resource pool configuration of the V-UE within and outside of network coverage. However, the UE's ability to perform V2X communications via the sidelink is not directly affected by its RRC, i.e., UEs in RRC_IDLE and RRC_CONNECTED states can perform V2X communications with relevant resource configuration and authorization. Since the LTE V2X mechanism is essentially connectionless, the NR V2X mechanism can be enhanced to allow connection-oriented communications.

[0044] Assuming that the V-UE is expected to perform unicast communication even when out of coverage, new RRC signaling can be defined to be sent over the sidelink by the UE interested in establishing a unicast link. The content of this message can be included in a new information element (IE) and can be similar to the content of the connection establishment request message discussed in the previous section, i.e., user information, security-related parameters, QoS configuration, etc. required to establish a dedicated connection. This is exemplified in the following simple IE structure.

[0045] SidelinkConnectionRequest Message

[0046]

[0047]

[0048] The separate signaling flows for the RRC-based solution to establish a unicast connection over the sidelink are fundamentally different from the ProSe-based solution; the main difference is the specific layer used by the UE for this purpose. For ProSe, the connection management signaling will be carried directly on the PDCP layer, and the advantage is the use of existing signaling procedures and the adaptation of the procedures for the NR V2X case, which V2X UEs with LTE sidelink support are expected to have. For the RRC case, the connection management signaling will be carried on the RRC layer across the sidelink, and new RRC signaling needs to be defined for the same purpose.

[0049] In some embodiments, support for multicast communications may be provided. Generally speaking, the solution developed here is also applicable to multicast communications, because multicast can be considered as a special form of unicast, where a link is established between one sending UE and several receiving UEs. The relevant difference may be in the L2 identifier, which may be associated with a group of UEs instead of a single UE, and in this case the UE information in the connection request message refers to the destination L2 group ID instead of a single UE ID. This mediation of the group identifier is expected to be left to the upper layers, as in the case of unicast, which simplifies the access stratum (AS) layer operation.

[0050] Figure 4 The architecture of a system 400 of a network according to some embodiments is shown. System 400 is shown to include user equipment (UE) 401 and UE 402. UE 401 and 402 are shown as smart phones (e.g., handheld touch screen mobile computing devices that can connect to one or more cellular networks), but these UEs can also include any mobile or non-mobile computing devices, such as personal data assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device that includes a wireless communication interface.

[0051] In some embodiments, any of UEs 401 and 402 may include an Internet of Things (IoT) UE, which may include a network access layer designed for low-power IoT applications that utilize transient UE connections. The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity services (ProSe) or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with transient connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0052] UE 401 and 402 may be configured to connect, e.g., be communicatively coupled, to a radio access network (RAN) 410—RAN 410 may be, e.g., an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN), a next generation RAN (NGRAN), or some other type of RAN. UE 401 and 402 utilize connection 403 and connection 404, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connection 403 and connection 404 are shown as air interfaces to achieve communicatively coupling, and may be consistent with a cellular communication protocol, such as a global system for mobile communications (GSM) protocol, a code division multiple access (CDMA) network protocol, a push-to-talk (PTT) protocol, a cellular PTT (POC) protocol, a universal mobile telecommunications system (UMTS) protocol, a 3GPP long term evolution (LTE) protocol, a fifth generation (5G) protocol, a new radio (NR) protocol, etc.

[0053] In this embodiment, UEs 401 and 402 may also exchange communication data directly via the ProSe interface 405. The ProSe interface 405 may alternatively be referred to as a sidelink interface including one or more logical channels including, but not limited to, a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

[0054] UE 402 is shown as being configured to access access point (AP) 406 via connection 407. Connection 407 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 406 would include wireless fidelity. In this example, AP 406 is shown connected to the Internet without being connected to the core network of the wireless system (described in further detail below).

[0055] The RAN 410 may include one or more access nodes that enable connection 403 and connection 404. These access nodes (ANs) may be referred to as base stations (BS), NodeBs, evolved NodeBs (eNBs), next generation NodeBs (gNBs), RAN nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). The RAN 410 may include one or more RAN nodes (e.g., macro RAN nodes 411) for providing macro cells, and one or more RAN nodes (e.g., low power (LP) RAN nodes 412) for providing femto cells or pico cells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth than macro cells).

[0056] Either of the RAN nodes 411 and 412 may terminate the air interface protocol and may be the first point of contact for the UEs 401 and 402. In some embodiments, either of the RAN nodes 411 and 412 may fulfill various logical functions of the RAN 410, including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0057] According to some embodiments, UEs 401 and 402 may be configured to communicate with each other or with any of RAN nodes 411 and 412 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication techniques, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. OFDM signals may include multiple orthogonal subcarriers.

[0058] In some embodiments, a downlink resource grid may be used for downlink transmissions from either of the RAN nodes 411 and 412 to the UEs 401 and 402, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is a physical resource in the downlink in each time slot. For OFDM systems, such a time-frequency plane representation is a common practice, which makes wireless resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a collection of resource elements. In the frequency domain, this may represent the minimum amount of resources that can currently be allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0059] The physical downlink shared channel (PDSCH) may convey user data and higher layer signaling to UE 401 and UE 402. The physical downlink control channel (PDCCH) may carry information about, among other things, the transport format and resource allocation associated with the PDSCH channel. It may also inform UE 401 and UE 402 of the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information associated with the uplink shared channel. Typically, downlink scheduling (allocation of control and shared channel resource blocks to UE 102 within a cell) may be performed at either of RAN nodes 411 and 412 based on channel quality information fed back from either of UE 401 and 402. Downlink resource allocation information may be sent on the PDCCH for (e.g., allocated to) each of UE 401 and UE 402.

[0060] PDCCH can use control channel elements (CCE) to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to four sets of nine physical resource elements, called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the downlink control information (DCI) and channel conditions, one or more CCEs can be used to transmit the PDCCH. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8).

[0061] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. One or more enhanced control channel elements (ECCEs) may be used to transmit EPDCCH. Similar to the above, each ECCE may correspond to four sets of nine physical resource elements, referred to as enhanced resource element groups (EREGs). In some cases, ECCEs may have other numbers of EREGs.

[0062] RAN 410 is shown as being communicatively coupled to a core network (CN) 420 via an S1 interface 413. In an embodiment, CN 420 may be an evolved packet core (EPC) network, a next generation packet core (NPC) network, or some other type of CN. In this embodiment, S1 interface 413 is divided into two parts: S1-U interface 414, which carries traffic data between RAN node 411 and RAN node 412 and serving gateway (S-GW) 422; and S1-mobility management entity (MME) interface 415, which is a signaling interface between RAN nodes 411 and 412 and MME 421.

[0063] In this embodiment, CN 420 includes MME 421, S-GW 422, Packet Data Network (PDN) Gateway (P-GW) 423 and Home Subscriber Server (HSS) 424. MME 421 may be similar in function to the control plane of a conventional Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 421 may manage mobility aspects in access, such as gateway selection and tracking area list management. HSS 424 may include a database for network users, which includes subscription-related information for supporting network entities in handling communication sessions. Depending on the number of mobile subscribers, the capacity of the equipment, the organization of the network, etc., CN420 may include one or more HSS 424. For example, HSS 424 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc.

[0064] The S-GW 422 may terminate the S1 interface 413 towards the RAN 410 and route data packets between the RAN 410 and the CN 420. In addition, the S-GW 422 may be a local mobility anchor point for inter-RAN node handovers and may also provide an anchor point for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and enforcement of certain policies.

[0065] The P-GW 423 may terminate the SGi interface toward the PDN. The P-GW 423 may route data packets between the EPC network 423 and an external network, such as a network including an application server 430 (or referred to as an application function (AF)), via an Internet Protocol (IP) interface 425. Generally speaking, the application server 430 may be an element that provides an application program (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.) that uses IP bearer resources with the core network. In this embodiment, the P-GW 423 is shown as being communicatively coupled to the application server 430 via an IP communication interface 425. The application server 430 may also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social network services, etc.) for the UEs 401 and 402 via the CN 420.

[0066] The P-GW 423 may also be a node for policy enforcement and charging data collection. The Policy and Charging Enforcement Function (PCRF) 426 is a policy and charging control element of the CN 420. In a non-roaming scenario, there may be a single PCRF in a domestic public land mobile network (HPLMN) associated with an Internet Protocol Connectivity Access Network (IP-CAN) session of the UE. In a roaming scenario with local traffic breakout, there may be two PCRFs associated with the UE's IP-CAN session: a domestic PCRF (H-PCRF) within the HPLMN and a visited PCRF (V-PCRF) within a visited public land mobile network (VPLMN). The PCRF 426 may be communicatively coupled to the application server 430 via the P-GW 423. The application server 430 may signal the PCRF 426 to indicate a new service flow and select appropriate quality of service (QoS) and charging parameters. PCRF 426 may configure the rules to a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate Communication Flow Template (TFT) and QoS Class Identifier (QCI), which initiates the QoS and charging specified by application server 430 .

[0067] Figure 5Exemplary components of a device 500 according to some embodiments are shown. In some embodiments, the device 500 may include an application circuit 502, a baseband circuit 504, a radio frequency (RF) circuit 506, a front-end module (FEM) circuit 508, one or more antennas 510, and a power management circuit (PMC) 512 (at least coupled together as shown). The components of the illustrated device 500 may be included in a UE or a RAN node. In some embodiments, the device 500 may include fewer elements (e.g., the RAN node cannot utilize the application circuit 502, but includes a processor / controller to process IP data received from the EPC). In some embodiments, the device 500 may include additional elements, such as, for example, a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, the components described below may be included in more than one device (e.g., the circuit may be separately included in more than one device for a specific implementation of a cloud-RAN (C-RAN)).

[0068] The application circuit 502 may include one or more application processors. For example, the application circuit 502 may include circuits such as, but not limited to, one or more single-core or multi-core processors. The processor may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled to or may include a memory / storage device, and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on the device 500. In some embodiments, the processor of the application circuit 502 may process IP data packets received from the EPC.

[0069] The baseband circuit 504 may include circuits such as, but not limited to, one or more single-core or multi-core processors. The baseband circuit 504 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of the RF circuit 506 and generate baseband signals for the transmit signal path of the RF circuit 506. The baseband processing circuit 504 may interact with the application circuit 502 to generate and process baseband signals and control the operation of the RF circuit 506. For example, in some embodiments, the baseband circuit 504 may include a third generation (3G) baseband processor 504A, a fourth generation (4G) baseband processor 504B, a fifth generation (5G) baseband processor 504C, or other baseband processors 504D of other existing generations, generations under development, or generations to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuit 504 (e.g., one or more of the baseband processors 504A-504D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuit 506. In other embodiments, some or all of the functions of the baseband processors 504A-D may be included in a module stored in the memory 504G and may be executed via the central processing unit (CPU) 504E. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuit of the baseband circuit 504 may include fast Fourier transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuit of the baseband circuit 504 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functions. The implementation of the modulation / demodulation and encoder / decoder functions is not limited to these examples, and may include other suitable functions in other embodiments.

[0070] In some embodiments, the baseband circuit 504 may include one or more audio digital signal processors (DSPs) 504F. The audio DSP 504F may include elements for compression / decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, the components of the baseband circuit may be appropriately combined in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the components of the baseband circuit 504 and the application circuit 502 may be implemented together, such as on a system on a chip (SOC).

[0071] In some embodiments, the baseband circuit 504 may provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuit 504 may support communications with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other wireless metropolitan area network (WMAN), wireless local area network (WLAN), wireless personal area network (WPAN). Embodiments in which the baseband circuit 504 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuits.

[0072] RF circuit 506 can communicate with a wireless network through a non-solid medium using modulated electromagnetic radiation. In various embodiments, RF circuit 506 may include switches, filters, amplifiers, etc. to facilitate communication with a wireless network. RF circuit 506 may include a receive signal path, which may include circuits that down-convert RF signals received from FEM circuit 508 and provide baseband signals to baseband circuit 504. RF circuit 506 may also include a transmit signal path, which may include circuits that up-convert baseband signals provided by baseband circuit 504 and provide RF output signals for transmission to FEM circuit 508.

[0073] In some embodiments, the receive signal path of the RF circuit 506 may include a mixer circuit 506a, an amplifier circuit 506b, and a filter circuit 506c. In some embodiments, the transmit signal path of the RF circuit 506 may include a filter circuit 506c and a mixer circuit 506a. The RF circuit 506 may also include a synthesizer circuit 506d for synthesizing the frequency used by the mixer circuit 506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 506a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 508 based on the synthesized frequency provided by the synthesizer circuit 506d. The amplifier circuit 506b may be configured to amplify the down-converted signal, and the filter circuit 506c may be a low pass filter (LPF) or a band pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to the baseband circuit 504 for further processing. In some embodiments, the output baseband signal can be a zero frequency baseband signal, although this is not required.In some embodiments, the mixer circuit 506a of the receive signal path can include a passive mixer, although the scope of the embodiments is not limited in this respect.

[0074] In some embodiments, mixer circuit 506a of the transmit signal path can be configured to upconvert an input baseband signal based on a synthesized frequency provided by synthesizer circuit 506d to generate an RF output signal for FEM circuit 508. The baseband signal can be provided by baseband circuit 504 and can be filtered by filter circuit 506c.

[0075] In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may include two or more mixers and may be arranged for orthogonal down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may include two or more mixers and may be arranged for image suppression (e.g., Hartley image suppression). In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may be configured for superheterodyne operation.

[0076] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuit 506 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuits, and the baseband circuit 504 may include a digital baseband interface to communicate with the RF circuit 506.

[0077] In some dual-mode embodiments, separate radio IC circuits may be provided to process signals for each spectrum, but the scope of the embodiments is not limited in this respect. In some embodiments, synthesizer circuit 506d may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the scope of the embodiments is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, synthesizer circuit 506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0078] Synthesizer circuit 506d may be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 506a of RF circuit 506. In some embodiments, synthesizer circuit 506d may be a fractional-N / N+1 synthesizer.

[0079] In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), although this is not required. The divider control input may be provided by the baseband circuit 504 or the application processor 502 according to the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by the application processor 502.

[0080] The synthesizer circuit 506d of the RF circuit 506 may include a frequency divider, a delay locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode frequency divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a cascaded, tunable, delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these embodiments, the delay element may be configured to divide the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0081] In some embodiments, the synthesizer circuit 506d can be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and can be used with a quadrature generator and divider circuit to generate multiple signals with multiple different phases relative to each other at the carrier frequency. In some embodiments, the output frequency can be the LO frequency (fLO). In some embodiments, the RF circuit 506 can include an IQ / polarity converter.

[0082] The FEM circuitry 508 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 510, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry 506 for further processing. The FEM circuitry 508 may also include a transmit signal path that may include circuitry configured to amplify signals provided by the RF circuitry 506 for transmission for transmission by one or more of the one or more antennas 510. In various embodiments, amplification by either the transmit signal path or the receive signal path may be accomplished only in the RF circuitry 506, only in the FEM 508, or in both the RF circuitry 506 and the FEM 508.

[0083] In some embodiments, the FEM circuit 508 may include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include an LNA for amplifying a received RF signal and providing the amplified received RF signal as an output (e.g., provided to the RF circuit 506). The transmit signal path of the FEM circuit 508 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuit 506); and one or more filters for generating an RF signal for subsequent transmission (e.g., through one or more of the one or more antennas 510).

[0084] In some embodiments, PMC 512 can manage the power provided to baseband circuit 504. Specifically, PMC 512 can control power selection, voltage scaling, battery charging, or DC-DC conversion. When device 500 is capable of being powered by a battery, for example, when the device is included in a UE, PMC 512 can generally be included. PMC 512 can improve power conversion efficiency while providing the desired specific implementation size and heat dissipation characteristics.

[0085] Although Figure 5 PMC 512 is shown coupled only to baseband circuit 504. However, in other embodiments, PMC 512 may additionally or alternatively be coupled to other components (such as, but not limited to, application circuit 502, RF circuit 506, or FEM 508) and perform similar power management operations.

[0086] In some embodiments, the PMC 512 may control or otherwise be part of various power saving mechanisms of the device 500. For example, if the device 500 is in the RRC_Connected state, where the device is still connected to the RAN node as expected to receive traffic in the near future, then after a period of inactivity, the device may enter a state known as discontinuous reception mode (DRX). During this state, the device 500 may be powered off for short time intervals, thereby saving power.

[0087] If there is no data traffic activity for an extended period of time, the device 500 may transition to the RRC_Idle state, in which the device is disconnected from the network and does not perform operations such as channel quality feedback, handover, etc. The device 500 enters a very low power state and performs paging, in which the device periodically wakes up again to listen to the network and then powers down again. The device 500 cannot receive data in this state, and in order to receive data, it must transition back to the RRC_Connected state.

[0088] An additional power saving mode can keep a device from using the network for longer than the paging interval (which can range from a few seconds to several hours). During this time, the device is completely unable to connect to the network and can be completely powered down. Any data sent during this time will be significantly delayed, and it is assumed that the delay is acceptable.

[0089] The processor of the application circuit 502 and the processor of the baseband circuit 504 can be used to execute elements of one or more instances of the protocol stack. For example, the processor of the baseband circuit 504 can be used alone or in combination to perform layer 3, layer 2, or layer 1 functions, while the processor of the application circuit 504 can utilize data received from these layers (e.g., packet data) and further perform layer 4 functions (e.g., transport communication protocol (TCP) and user datagram protocol (UDP) layers). As mentioned herein, layer 3 may include a radio resource control (RRC) layer, which will be described in further detail below. As mentioned herein, layer 2 may include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, which will be described in further detail below. As described herein. Layer 1 may include a physical (PHY) layer of a UE / RAN node, which will be described in further detail below.

[0090] The following is an exemplary implementation of the subject matter described herein. In Example 1, an apparatus of a first user equipment (UE) includes one or more baseband processors for generating a message for indicating to a second UE that the first UE intends to establish a new air interface (NR) side link connection for an enhanced vehicle-to-everything (eV2X) service and processing a response from the second UE regarding the message, and a memory for storing the message. In Example 2, the message is configured for a unicast communication mode. In Example 3, the message is configured for a multicast communication mode. In Example 4, the message is configured for proximity service (ProSe) signaling on the NR side link. In Example 5, the message includes an identifier in an NR media access control (MAC) subheader for indicating unicast, multicast, or broadcast communication. In Example 6, the message includes an identifier in an NR media access control (MAC) subheader for indicating a V2X service identifier (ID) of a related V2X packet. In Example 7, the upper layer ensures that the source identifier (ID) and destination ID of the first UE for each V2X service ID are uniquely defined. In example eight, the message is configured for radio resource control (RRC) signaling on the NR side link. In example nine, the message includes an RRC signaling information element (IE) for connection establishment on the NR side link. In example ten, the message is configured for multicast communication to accommodate N additional UE receptions solely for unicast connection management.

[0091] In example eleven, one or more machine-readable media have instructions stored thereon that, when executed by a device of a first user equipment (UE), result in generating a message for indicating to a second UE that the first UE intends to establish a new air interface (NR) side link connection for an enhanced vehicle-to-everything (eV2X) service and processing a response from the second UE regarding the message. In example twelve, the message is configured for a unicast communication mode. In example thirteen, the message is configured for a multicast communication mode. In example fourteen, the message is configured for proximity service (ProSe) signaling on an NR side link. In example fifteen, the message includes an identifier in an NR media access control (MAC) subheader for indicating unicast, multicast, or broadcast communication. In example sixteen, the message includes an identifier in an NR media access control (MAC) subheader for indicating a V2X service identifier (ID) of a related V2X packet. In example seventeen, the upper layer ensures that the source identifier (ID) and destination ID of the first UE for each V2X service ID are uniquely defined. In Example 18, the message is configured for radio resource control (RRC) signaling on the NR side link. In Example 19, the message includes an RRC signaling information element (IE) for connection establishment on the NR side link. In Example 20, the message is configured for multicast communication to accommodate N additional UE receptions solely for unicast connection management.

[0092] While the claimed subject matter has been described with a certain degree of particularity, it will be appreciated that elements of the claimed subject matter may be varied by those skilled in the art without departing from the spirit and / or scope of the claimed subject matter. It is believed that the subject matter relating to a connection management solution for unicast and multicast communications on an eV2X supporting sidelink and its many attendant utilities will be understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction and / or arrangement of its components without departing from the scope and / or spirit of the claimed subject matter, or without sacrificing all of its material advantages, the forms described above being merely illustrative embodiments of the components and / or further providing no substantial changes thereto. It is the intent of the claims to cover and / or include such variations.

Claims

1. A device of a first user equipment UE, comprising: One or more baseband processors, the one or more baseband processors are used to generate a message for indicating to a second UE that the first UE intends to establish a new air interface NR sidelink connection for a vehicle-to-everything (V2X) service, and process a response to the message from the second UE; and a memory, the memory being used to store the message, The message is a radio resource control RRC signaling, the RRC signaling includes an RRC signaling information element IE, the RRC signaling IE includes at least a quality of service QoS related parameter for the NR side link connection, a source identifier ID for the first UE, a destination ID for the second UE, a V2X service ID for the V2X service, and security-related information including one or more security keys for the NR side link connection, and The one or more baseband processors are further configured to transmit keep-alive signaling KAS to the second UE, wherein the KAS includes at least one of the following: i) updated QoS-related parameters, ii) an updated source ID for the first UE, or iii) an updated destination ID for the second UE.

2. The apparatus of claim 1, wherein the message is configured for a unicast communication mode. The apparatus of claim 1 , wherein the message is configured for a multicast communication mode.

4. The apparatus according to any one of claims 1-3, wherein the message is configured for proximity service (ProSe) signaling on the NR side link. 5 . The apparatus according to claim 4 , wherein the QoS-related parameters include a list of ProSe per-packet priority (PPPP) and ProSe per-packet reliability (PPPR).

6. The apparatus according to any one of claims 1-3, wherein the source ID for the first UE is a first layer 2 ID and the destination ID for the second UE is a second layer 2 ID.

7. The apparatus according to any one of claims 1-3, wherein an upper layer ensures that a source ID and a destination ID for each V2X service ID are uniquely defined.

8. The apparatus according to any one of claims 1-3, wherein the response is a connection establishment accept message.

9. One or more machine-readable media having instructions stored thereon, which, when executed by a device of a first user equipment UE, result in: Generate a message for indicating to a second UE that the first UE intends to establish a new radio interface NR sidelink connection for a vehicle-to-everything (V2X) service; processing a response to the message from the second UE, wherein: The message is a radio resource control RRC signaling, the RRC signaling includes an RRC signaling information element IE, and the RRC signaling IE includes at least a quality of service QoS related parameter for the NR side link connection, a source identifier ID for the first UE, a destination ID for the second UE, a V2X service ID of the V2X service, and security related information including one or more security keys for the NR side link connection; as well as A keep-alive signaling KAS for the second UE is generated, the KAS including at least one of the following: i) updated QoS-related parameters, ii) an updated source ID for the first UE, or iii) an updated destination ID for the second UE.

10. The one or more machine-readable media of claim 9, wherein the message is configured for a unicast communication mode.

11. The one or more machine-readable media of claim 9, wherein the message is configured for a multicast communication mode.

12. One or more machine-readable media according to any one of claims 9-11, wherein the message is configured for proximity service (ProSe) signaling on the NR sidelink.

13. The one or more machine-readable media of claim 12, wherein the QoS-related parameters include a list of ProSe per-packet priority (PPPP) and ProSe per-packet reliability (PPPR).

14. The one or more machine-readable media of any one of claims 9-11, wherein the source ID for the first UE is a first layer 2 ID and the destination ID for the second UE is a second layer 2 ID.

15. One or more machine-readable media according to any of claims 9-11, wherein upper layers ensure that a source ID and a destination ID for each V2X service ID are uniquely defined.

16. One or more machine-readable media according to any one of claims 9-11, wherein the response is a connection establishment accept message.

Images