CN111726781A - Apparatus and method for PC5QoS authorization for V2X service - Google Patents

Abstract

The present disclosure provides an apparatus and method for PC5QoS authorization for V2X services. An aspect of the present disclosure provides an apparatus for a UE. The apparatus includes a Radio Frequency (RF) interface and a processor circuit coupled with the RF interface. The RF interface is for receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message including vehicle-to-everything (V2X) policy/parameter information. The V2X policy/parameter information includes a mapping between V2X service type and PC5 quality of service (QoS) parameters. The processor circuit is to: determining a PC5QoS parameter for the UE based on the mapping and the V2X service type of the UE; and performing V2X communication based on the PC5QoS parameters for the UE. Other embodiments may be disclosed and claimed.

Description

Apparatus and method for PC5QoS authorization for V2X service

Priority declaration

This application is based on and claims priority from U.S. provisional application serial No. 62/821,948 filed on 21/3/2019, the entire contents of which are hereby incorporated by reference in their entirety.

Technical Field

Embodiments of the present disclosure relate generally to the field of wireless communications, and in particular, to an apparatus and method for PC5 quality of service (QoS) authorization for vehicle-to-anything (V2X) services to User Equipment (UE) and a Radio Access Network (RAN).

Background

With the development of wireless communication, V2X service may be implemented by various types of V2X applications, for example, vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and the like. V2X communications may be used to support V2X services using the Uu reference point and/or the PC5 reference point. Appropriate QoS parameters are necessary to enable V2X communication.

Disclosure of Invention

An aspect of the present disclosure provides an apparatus for a UE, the apparatus comprising: a Radio Frequency (RF) interface; and a processor circuit coupled with the RF interface, wherein the RF interface is to: receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is to: determining a PC5QoS parameter for the UE based on the mapping and the V2X service type of the UE; and performing V2X communication based on the PC5QoS parameters for the UE.

AN aspect of the present disclosure provides AN apparatus for AN Access Node (AN), the apparatus comprising: a Radio Frequency (RF) interface; and a processor circuit coupled with the RF interface, wherein the RF interface is to: receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is to: determining PC5QoS parameters for a User Equipment (UE) based on the mapping; and scheduling PC5 radio resources for V2X communications for the UE based on the PC5QoS parameters for the UE.

AN aspect of the present disclosure provides AN apparatus for AN Access Node (AN), the apparatus comprising: a Radio Frequency (RF) interface; and a processor circuit coupled with the RF interface, wherein the RF interface is to: receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between a destination layer 2 ID and a sidelink quality of service (QoS) parameter, and wherein the processor circuit is to: determining a sidelink QoS parameter for a User Equipment (UE) based on the mapping; and scheduling sidelink radio resources for V2X communication of the UE based on the sidelink QoS parameter for the UE.

Drawings

Embodiments of the present disclosure will be described by way of example, and not limitation, in the figures of the accompanying drawings in which like references indicate similar elements.

Fig. 1 illustrates an example architecture of a system according to some embodiments of the present disclosure.

Fig. 2 illustrates an example architecture of a system including a first Core Network (CN) in accordance with some embodiments of the present disclosure.

Figure 3 illustrates an example architecture of a system including a second CN in accordance with some embodiments of the present disclosure.

Fig. 4 illustrates a process diagram for provisioning of PC5QoS authorization information for V2X services to a UE and a RAN in accordance with some embodiments of the present disclosure.

Fig. 5 illustrates a flow diagram of a method for provisioning a UE with PC5QoS authorization information for V2X services from the perspective of the UE, in accordance with some embodiments of the present disclosure.

Fig. 6 illustrates a flow diagram of a method for provisioning the RAN with PC5QoS authorization information for V2X services from the perspective of the RAN in accordance with some embodiments of the present disclosure.

Fig. 7 illustrates a flow diagram of a method for provisioning the RAN with PC5QoS authorization information for V2X services from the perspective of the RAN in accordance with some embodiments of the present disclosure.

Fig. 8 illustrates a flow diagram of a method for provisioning a UE with PC5QoS authorization information for V2X services from the perspective of a second CN in accordance with some embodiments of the present disclosure.

Fig. 9 illustrates a flow diagram of a method for provisioning the RAN with PC5QoS authorization information for V2X services from the perspective of the second CN in accordance with some embodiments of the present disclosure.

Fig. 10 illustrates example components of a device according to some embodiments of the present disclosure.

Fig. 11 illustrates an example interface of a baseband circuit according to some embodiments of the present disclosure.

Fig. 12 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methodologies discussed herein, according to some example embodiments.

Detailed Description

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. However, it will be readily appreciated by those skilled in the art that many alternative embodiments may be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternative embodiments may be practiced without the specific details. In other instances, well-known features may be omitted or simplified in order not to obscure the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrases "in an embodiment," "in one embodiment," and "in some embodiments" are used repeatedly herein. The phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrases "A or B" and "A/B" mean "(A), (B) or (A and B)".

For V2X communications, there are two modes of operation, V2X communications over the PC5 reference point and V2X communications over the Uu reference point. The UE may use these two modes of operation independently for transmission and reception.

Long Term Evolution (LTE) and/or New Radio (NR) support V2X communications over a PC5 reference point. Evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access (E-UTRA) connected to the 5GC and/or NR connected to the 5GC support V2X communications over a Uu reference point. The present disclosure is primarily described with respect to V2X communications over a PC5 reference point. In particular, a solution for provisioning the UE and RAN with PC5QoS authorization information for V2X services will be described in detail in this disclosure. However, embodiments of the present disclosure are applicable to V2X communications over the Uu reference point, and are not limited in this respect.

Fig. 1 illustrates an example architecture of a system 100 according to some embodiments of the present disclosure. The following description is provided for an example system 100 operating in conjunction with the Long Term Evolution (LTE) system standard and the 5G or New Radio (NR) system standard provided by the 3GPP Technical Specification (TS). However, the example embodiments are not limited in this respect and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, Institute of Electrical and Electronics Engineers (IEEE)802.16 protocols (e.g., wireless Metropolitan Area Network (MAN), Worldwide Interoperability for Microwave Access (WiMAX), etc.), and so forth.

As shown in FIG. 1, the system 100 can include a UE101 a and a UE101 b (collectively referred to as "UE(s) 101"). As used herein, the term "user equipment" or "UE" may refer to devices having radio communication capabilities and may describe remote users of network resources in a communication network. The terms "user equipment" or "UE" may be considered synonyms and may be referred to as a client, a mobile phone, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access agent, a user agent, a receiver, a radio, a reconfigurable mobile, and the like. Furthermore, the terms "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface. In this example, the UE101 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronic device, a cellular phone, a smartphone, a feature phone, a tablet, a wearable computer device, a Personal Digital Assistant (PDA), a pager, a wireless handheld device, a desktop computer, a laptop computer, an in-vehicle infotainment system (IVI), an in-vehicle entertainment (ICE) device, an Instrument panel (Instrument Cluster, IC), a head-up display (HUD) device, an in-vehicle diagnostics (OBD) device, a dashboard mobile Device (DME), a Mobile Data Terminal (MDT), an Electronic Engine Management System (EEMS), an electronic/Engine Control Unit (ECU), an electronic/Engine Control Module (ECM), a mobile computing device(s), a mobile computing device, a mobile, Embedded systems, microcontrollers, control modules, Engine Management Systems (EMS), networked or "smart" devices, Machine Type Communication (MTC) devices, machine-to-machine (M2M), internet of things (IoT) devices, and/or the like.

In some embodiments, any of the UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via PLMNs, proximity-based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks. The data exchange of M2M or MTC may be a machine initiated data exchange. An IoT network describes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

UE101 may be configured to connect (e.g., communicatively couple) with AN or RAN 110. In an embodiment, RAN110 may be a Next Generation (NG) RAN or a 5G RAN, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), or a legacy RAN, such as a UTRAN (UMTS terrestrial radio access network) or a GERAN (GSM (global system for Mobile communications or group Sp specific Mobile) EDGE (GSM evolution) radio access network). As used herein, the term "NG RAN" or the like may refer to RAN110 operating in an NR or 5G system 100, and the term "E-UTRAN" or the like may refer to RAN110 operating in an LTE or 4G system 100. The UE101 utilizes connections (or channels) 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" may refer to any tangible or intangible transmission medium that communicates data or a stream of data. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term denoting a path or medium through which data is communicated. In addition, the term "link" may refer to a connection between two devices for the purpose of transmitting and receiving information over a Radio Access Technology (RAT).

In this example, connections 103 and 104 are shown as air interfaces to enable communicative 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, and/or any other communication protocol discussed herein. In an embodiment, the UE101 may exchange communication data directly via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a Sidelink (SL) interface 105 and may include one or more logical channels including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a physical sidelink shared channel (PSCCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

UE101 b is shown configured to access an Access Point (AP)106 (also referred to as "WLAN node 106", "WLAN terminal 106", or "WT 106", etc.) via a connection 107. The connection 107 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where the AP 106 would comprise a wireless fidelity (WiFi) router. In this example, the AP 106 is shown connected to the internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE101 b, RAN110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operations and/or WLAN LTE/WLAN radio level integration (LWIP) operations with IPsec tunneling. LWA operation may involve UE101 b in RRC _ CONNECTED being configured by RAN node 111 to utilize radio resources of LTE and WLAN. The LWIP operation may involve the UE101 b using WLAN radio resources (e.g., connection 107) via an internet protocol security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) sent over the connection 107. An IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

RAN110 may include one or more AN nodes or RAN nodes 111a and 111b (collectively referred to as "RAN node(s) 111") that enable connections 103 and 104. As used herein, the terms "access node," "access point," and the like may describe a device that provides radio baseband functionality for data and/or voice connections between a network and one or more users. These access nodes may be referred to as Base Stations (BSs), next generation node BS (gnbs), RAN nodes, evolved nodebs (enbs), nodebs, Road Side Units (RSUs), transmission reception points (TRxP or TRP), etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the term "NG RAN node" or the like may refer to a RAN node 111 (e.g., a gNB) operating in the NR or 5G system 100, and the term "E-UTRAN node" or the like may refer to a RAN node 111 (e.g., an eNB) operating in the LTE or 4G system 100. According to various embodiments, the RAN node 111 may be implemented as one or more dedicated physical devices such as a macro cell base station and/or a Low Power (LP) base station for a femto cell, pico cell or other similar cell providing a smaller coverage area, smaller user capacity or higher bandwidth than a macro cell.

In some embodiments, all or part of the RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud Radio Access Network (CRAN) and/or a virtual baseband unit pool (vbbp). In these embodiments, the CRAN or vbbp may implement RAN functional partitioning, such as: PDCP partitioning, wherein RRC and PDCP layers are operated by the CRAN/vbbp, while other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC/PHY division, where RRC, PDCP, RLC and MAC layers are operated by the CRAN/vbup, and PHY layers are operated by individual RAN nodes 111; or "lower PHY" division, where the RRC, PDCP, RLC, MAC layers and upper parts of the PHY layers are operated by the CRAN/vbup and lower parts of the PHY layers are operated by the individual RAN node 111. The virtualization framework allows freeing up processor cores of RAN node 111 to execute other virtualized applications. In some implementations, the individual RAN nodes 111 may represent individual gNB-DUs that are connected to the gNB-CUs via individual F1 interfaces (not shown in fig. 1). In these implementations, the gbb-DUs may include one or more remote radio heads or radio front-end modules (RFEM), and the gbb-CUs may be operated by a server (not shown) located in the RAN110 or by a server pool in a similar manner to the CRAN/vbbp. Additionally or alternatively, one or more RAN nodes 111 may be next generation enbs (NG-enbs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations towards the UE101 and which are connected to a 5GC (e.g., CN 320 of fig. 3) via an NG interface (discussed below).

In the V2X scenario, one or more RAN nodes 111 may be or act as RSUs. The term "roadside unit" or "RSU" may refer to any transportation infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or a fixed (or relatively stationary) UE, where the RSU in or by the UE may be referred to as a "UE-type RSU", the RSU in or by the eNB may be referred to as an "eNB-type RSU", the RSU in or by the gNB may be referred to as a "gNB-type RSU", and so on. In one example, an RSU is a computing device coupled with radio frequency circuitry located at the curb side that provides connectivity support for a passing vehicle UE101 (vUE 101). The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9GHz Direct Short Range Communication (DSRC) band to provide very low latency communications required for high speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may operate on the cellular V2X frequency band to provide the low latency communications described above as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a WiFi hotspot (2.4GHz band) and/or provide a connection to one or more cellular networks to provide uplink and downlink communications. The computing device(s) and some or all of the radio frequency circuitry of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide wired (e.g., ethernet) connectivity to a traffic signal controller and/or a backhaul network.

Any RAN node 111 may terminate the air interface protocol and may be the first point of contact for the UE 101. In some embodiments, any RAN node 111 may fulfill various logical functions of RAN110, 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.

In an embodiment, the UEs 101 may be configured to communicate with each other or any of the RAN nodes 111 over a multicarrier communication channel in accordance with 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), using Orthogonal Frequency Division Multiplexing (OFDM) communication signals, although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any RAN node 111 to the UE101, while uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink per slot. Such a time-frequency plane representation is common practice for OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one 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 comprises a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

According to various embodiments, UE101 and RAN node 111 communicate (e.g., transmit and receive) data over a licensed medium (also referred to as "licensed spectrum" and/or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum and/or" unlicensed band "). The licensed spectrum may include channels operating in a frequency range of about 400MHz to about 3.8GHz, while the unlicensed spectrum may include a 5GHz band.

To operate in unlicensed spectrum, the UE101 and RAN node 111 may operate using Licensed Assisted Access (LAA), enhanced LAA (elaa), and/or other elaa (felaa) mechanisms. In these implementations, UE101 and RAN node 111 may perform one or more known medium sensing operations and/or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied prior to transmission in the unlicensed spectrum. The medium/carrier sensing operation may be performed according to a Listen Before Talk (LBT) protocol.

LBT is a mechanism in which a device (e.g., UE101, RAN node 111,112, etc.) senses a medium (e.g., channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include Clear Channel Assessment (CCA) that utilizes at least Energy Detection (ED) to determine whether other signals are present on the channel in order to determine whether the channel is occupied or clear. The LBT mechanism allows the cellular/LAA network to coexist with incumbent systems in unlicensed spectrum and with other LAA networks. ED may include sensing Radio Frequency (RF) energy over an expected transmission band for a period of time and comparing the sensed RF energy to a predetermined or configured threshold.

Generally, an incumbent system in the 5GHz band is a WLAN based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism known as carrier sense multiple access with collision avoidance (CSMA/CA). Here, when a WLAN node (e.g., a Mobile Station (MS) such as UE101, AP 106) intends to transmit, the WLAN node may first perform a CCA prior to the transmission. In addition, a back-off mechanism is used to avoid collisions in the case where more than one WLAN node senses the channel as idle and transmits at the same time. The back-off mechanism may be a counter drawn randomly within the Contention Window Size (CWS) that is exponentially increased when collisions occur and reset to a minimum value when a transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA/CA of WLAN. In some implementations, an LBT procedure for a DL or UL transmission burst including PDSCH or PUSCH transmissions, respectively, may have an LAA contention window of variable length between X and Y extended cca (ecca) slots, where X and Y are minimum and maximum values of a CWS for the LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μ β); however, the size of the CWS and the Maximum Channel Occupancy Time (MCOT) (e.g., transmission bursts) may be based on government regulatory requirements.

The LAA mechanism is established based on the Carrier Aggregation (CA) technique of the LTE-Advanced (LTE-Advanced) system. In CA, each aggregated carrier is referred to as a Component Carrier (CC). The CCs may have bandwidths of 1.4, 3, 5, 10, 15, or 20MHz, and may be aggregated for up to five CCs, and thus, the maximum aggregated bandwidth is 100 MHz. In a Frequency Division Duplex (FDD) system, the number of aggregated carriers may be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, individual CCs may have different bandwidths than other CCs. In a Time Division Duplex (TDD) system, the number of CCs and the bandwidth of each CC are typically the same for DL and UL.

The CA also includes individual serving cells to provide individual CCs. The coverage of the serving cell may be different, e.g., because CCs on different frequency bands will experience different path losses. A primary serving cell or primary cell (PCell) may provide a primary cc (pcc) for both UL and DL and may handle Radio Resource Control (RRC) and non-access stratum (NAS) related activities. The other serving cells are referred to as secondary cells (scells), and each SCell may provide a separate secondary cc (scc) for both UL and DL. SCCs may be added and removed as needed, while changing the PCC may require the UE101 to undergo handover. In LAA, eLAA, and feLAA, some or all scells may operate in unlicensed spectrum (referred to as "LAA scells"), and the LAA scells are assisted by pcells operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE may receive a UL grant on the configured LAASCell, the UL grant indicating different Physical Uplink Shared Channel (PUSCH) starting positions within the same subframe.

The Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to the UE 101. A Physical Downlink Control Channel (PDCCH) may carry information on a transport format and resource allocation related to a PDSCH channel, and the like. It may also inform the UE101 of transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (allocation of control and shared channel resource blocks to UEs 101b within a cell) may be performed at any RAN node 111 based on channel quality information fed back from any UE 101. The downlink resource allocation information may be sent on a PDCCH for (e.g., allocated to) each UE 101.

The PDCCH may use Control Channel Elements (CCEs) to convey control information. The PDCCH complex-valued symbols may first be organized into quadruplets before mapping to resource elements, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements called Resource Element Groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of Downlink Control Information (DCI) and channel conditions. Four or more different PDCCH formats with different numbers of CCEs may be defined in LTE (e.g., aggregation level, L ═ 1, 2, 4, or 8).

Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above-described concept. For example, some embodiments may use an Enhanced Physical Downlink Control Channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more Enhanced Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to nine sets of four physical resource elements referred to as Enhanced Resource Element Groups (EREGs). In some cases, ECCE may have other numbers of EREGs.

The RAN nodes 111 may be configured to communicate with each other via an interface 112. In embodiments where system 100 is an LTE system, interface 112 may be an X2 interface 112. An X2 interface may be defined between two or more RAN nodes 111 (e.g., two or more enbs, etc.) connected to the EPC120 and/or two enbs connected to the EPC 120. In some implementations, the X2 interfaces may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface and may be used to communicate information about user data transfer between enbs. For example, X2-U may provide specific sequence number information for user data transmitted from a master enb (menb) to a secondary enb (senb); information on successful in-order transmission of PDCP PDUs for user data from the SeNB to the UE 101; information of PDCP PDUs not delivered to the UE 101; information on a current minimum required buffer size at the SeNB for transmitting user data to the UE; and so on. X2-C may provide intra-LTE access mobility functions including context transfer from source eNB to target eNB, user plane transfer control, etc.; a load management function; and an inter-cell interference coordination function.

In embodiments where system 100 is a 5G or NR system, interface 112 may be an Xn interface 112. An Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gnbs, etc.) connected to the 5GC 120, between a RAN node 111 (e.g., a gNB) connected to the 5GC 120 and an eNB, and/or between two enbs connected to the 5GC 120. In some implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide unsecured transport of user plane PDUs and support/provide data forwarding and flow control functionality. Xn-C may provide: management and error handling functions; managing the function of the Xn-C interface; mobility support for a UE101 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality to manage CONNECTED mode UE mobility between one or more RAN nodes 111. Mobility support may include context transfer from the old (source) serving RAN node 111 to the new (target) serving RAN node 111; and control of user plane tunnels between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of the Xn-U may include a transport network layer established above an Internet Protocol (IP) transport layer and a GTP-U layer above UDP(s) and/or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol, referred to as the Xn application protocol (Xn-AP), and a transport network layer built over SCTP. SCTP can be located above the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack and/or the Xn-C protocol stack may be the same as or similar to the user plane and/or control plane protocol stack(s) shown and described herein.

RAN110 is shown communicatively coupled to a core network, in this embodiment, Core Network (CN) 120. CN120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UE 101) connected to CN120 through RAN 110. The term "network element" may describe a physical or virtualized device used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with and/or referred to as: a networking computer, network hardware, network device, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, Virtualized Network Function (VNF), Network Function Virtualization Infrastructure (NFVI), and/or the like. The components of CN120 may be implemented in one physical node or separate physical nodes, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, Network Function Virtualization (NFV) may be used to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). Logical instantiations of the CN120 may be referred to as network slices, and logical instantiations of a portion of the CN120 may be referred to as network subslices. The NFV architecture and infrastructure may be used to virtualize one or more network functions or be executed by dedicated hardware onto physical resources including a combination of industry standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components/functions.

In general, the application server 130 may be an element that provides applications that use IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.). The application server 130 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 networking services, etc.) for the UE101 via the EPC 120.

In an embodiment, the CN120 may be a 5GC (referred to as "5 GC 120" or the like), and the RAN110 may be connected with the CN120 via the NG interface 113. In an embodiment, the NG interface 113 may be divided into two parts: a NG user plane (NG-U) interface 114 that carries traffic data between RAN node 111 and User Plane Functions (UPFs); and S1 control plane (NG-C) interface 115, which is the signaling interface between RAN node 111 and the AMF. An embodiment in which the CN120 is a 5GC 120 is discussed in more detail with respect to figure 3.

In an embodiment, the CN120 may be a 5G CN (referred to as "5 GC 120," etc.), while in other embodiments, the CN120 may be an Evolved Packet Core (EPC). In the case where CN120 is an EPC (referred to as "EPC 120," etc.), RAN110 may connect with CN120 via S1 interface 113. In an embodiment, the S1 interface 13 may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries traffic data between the RAN node 111 and the serving gateway (S-GW); and S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN node 111 and the MME.

Figure 2 illustrates an example architecture of a system 200 including a first CN 220, according to some embodiments of the present disclosure.

In one embodiment, system 200 may implement the LTE standard, where CN 220 is EPC 220 corresponding to CN120 of fig. 1. Additionally, UE201 may be the same as or similar to UE101 of fig. 1, EUTRAN210 may be the same as or similar to RAN110 of fig. 1, and may include RAN node 111 previously discussed. The CN 220 may include an MME 221, an S-GW222, a Packet Data Network (PDN) gateway (P-GW)223, a Home Subscriber Server (HSS)224, and a serving General Packet Radio Service (GPRS) support node (SGSN) 225.

The MME 221 may be similar in function to the control plane of a legacy SGSN, and may implement Mobility Management (MM) functions to track the current location of the UE 201. The MME 221 may perform various MM procedures to manage mobility aspects in access, such as gateway selection and tracking area list management. MM (also referred to as "EPS MM" or "EMM" in E-UTRAN systems) may refer to all applicable procedures, methods, data stores, etc. for maintaining knowledge about the current location of the UE201, providing user identity confidentiality and/or other similar services to the user/subscriber. Each UE201 and MME 221 may include an MM or EMM sublayer and when the attach procedure is successfully completed, an MM context may be established in the UE201 and MME 221. The MM context may be a data structure or database object that stores MM-related information of the UE 201. The MME 221 may be coupled with the HSS 224 via an S6a reference point, with the SGSN 225 via an S3 reference point, and with the S-GW222 via an S11 reference point.

The SGSN 225 may be a node that serves the individual UE201 by tracking the location of the UE201 and performing security functions. In addition, SGSN 225 may perform: inter-EPC node signaling for mobility between 2G/3G and E-UTRAN3GPP access networks; PDN and S-GW selection specified by MME 221; processing of the UE201 time zone function specified by the MME 221; and MME selection for handover to an E-UTRAN3GPP access network. The S3 reference point between the MME 221 and the SGSN 225 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle and/or active states.

The HSS 224 may include a database for network users, including subscription-related information for supporting network entities in handling communication sessions. The EPC 220 may include one or more HSS 224, depending on the number of mobile subscribers, the capacity of the devices, the organization of the network, etc. For example, the HSS 224 may provide support for routing/roaming, authentication, authorization, naming/address resolution, location dependency, and the like. An S6a reference point between HHS 224 and MME 221 may enable the transfer of subscription and authentication data for authenticating/authorizing user access to EPC 220 between HHS 224 and MME 221.

The S-GW222 may terminate the S1 interface 513 ("S1-U" in fig. 2) to the RAN210 and route data packets between the RAN210 and the EPC 220. In addition, the S-GW222 may be a local mobility anchor point for inter-RAN node handover and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement. An S11 reference point between the S-GW222 and the MME 221 may provide a control plane between the MME 221 and the S-GW 222. The S-GW222 may be coupled with the P-GW223 via an S5 reference point.

The P-GW223 may terminate the SGi interface to the Packet Data Network (PDN) 230. P-GW223 may route data packets between EPC 220 and an external network, such as a network including application server 130 (or referred to as an Application Function (AF)), via Internet Protocol (IP) interface 125 (see, e.g., fig. 1). In an embodiment, P-GW223 may be communicatively coupled to an application server (application server 130 of fig. 1 or PDN230 of fig. 2) via IP communication interface 125 (see, e.g., fig. 1). An S5 reference point between P-GW223 and S-GW222 may provide user plane tunneling and tunnel management between P-GW223 and S-GW 222. The S5 reference point may also be used for S-GW222 relocation due to UE201 mobility and if the S-GW222 needs to connect to a non-collocated P-GW223 to obtain the required PDN connection. The P-GW223 may also include nodes for policy enforcement and charging data collection (e.g., a Policy and Charging Enforcement Function (PCEF) (not shown)). Additionally, the SGi reference point between the P-GW223 and the Packet Data Network (PDN)230 may be an operator external public, private PDN or an operator internal packet data network, e.g., for providing IMS services. P-GW223 may be coupled with PCRF226 via a Gx reference point.

A policy and charging enforcement function (PCRF)226 is a policy and charging control element of the EPC 220. In a non-roaming scenario, there may be a single PCRF226 associated with a UE201 internet protocol connectivity access network (IP-CAN) session in a Home Public Land Mobile Network (HPLMN). In a roaming scenario with local traffic breakout, there may be two PCRFs associated with the UE201IP-CAN session, a home PCRF (H-PCRF) within the HPLMN, and a visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). The PCRF may be communicatively coupled to the application server 230 via the P-GW 223. Application server 230 may signal the PCRF to indicate the new service flow and select the appropriate quality of service (QoS) and charging parameters. PCRF226 may provide the rules to a Policy and Charging Enforcement Function (PCEF) (not shown) with appropriate Traffic Flow Templates (TFTs) and QoS Class Identifiers (QCIs), which initiates QoS and charging specified by application server 230. A Gx reference point between PCRF226 and P-GW223 may allow (QoS) policy and charging rules to be communicated from PCRF226 to Policy and Charging Enforcement Function (PCEF) in P-GW 223. The Rx reference point may reside between the PDN230 (or "AF 230") and the PCRF 226.

Figure 3 illustrates an example architecture of a system 300 including a second CN 320, in accordance with some embodiments of the present disclosure.

The system 300 is shown as including: a UE301, which may be the same as or similar to UE101 and UE201 discussed previously; AN310, which may be the same as or similar to RAN110 and RAN210 discussed previously, and may include RAN node 111 discussed previously; and a Data Network (DN)303, which may be, for example, an operator service, internet access, or third party service; and a 5G core network (5GC or CN) 320.

The 5GC 320 may include an authentication server function (AUSF) 222; an access and mobility management function (AMF) 321; a Session Management Function (SMF) 324; a Network Exposure Function (NEF) 323; a Policy Control Function (PCF) 326; a Network Function (NF) repository function (NRF) 325; unified Data Management (UDM) 327; an Application Function (AF) 328; a User Plane Function (UPF) 302; and a Network Slice Selection Function (NSSF) 329.

The UPF302 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session interconnect point to the DN303, and a branch point to support multi-homed PDU sessions. The UPF302 may also perform packet routing and forwarding, packet inspection, perform policy rules for the user plane part, lawful intercept packets (UP set), traffic usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS traffic mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF302 may include an uplink classifier to support routing of traffic flows to a data network. DN303 may represent various network operator services, internet access, or third party services. DN303 may include or be similar to application server 130 previously discussed. The UPF302 may interact with the SMF324 via an N4 reference point between the SMF324 and the UPF 302.

The AUSF 322 may store data for authentication of the UE301 and process authentication related functions. The AUSF 322 may facilitate a common authentication framework for various access types. The AUSF 322 may communicate with the AMF321 via an N12 reference point between the AMF321 and the AUSF 322; and may communicate with UDM 327 via an N13 reference point between UDM 327 and AUSF 322. Additionally, the AUSF 322 may expose a Nausf service based interface.

The AMF321 may be responsible for registration management (e.g., for registering the UE301, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, as well as access authentication and authorization. The AMF321 may be a termination point of the N11 reference point between the AMF321 and the SMF 324. AMF321 may provide transport for Session Management (SM) messages between UE301 and SMF324 and act as a transparent proxy for routing SM messages. The AMF321 may also provide for transmission of Short Message Service (SMS) messages between the UE301 and an SMS function (SMSF) (not shown in fig. 3). The AMF321 may act as a security anchor function (SEA), which may include interactions with the AUSF 322 and the UE301, receiving intermediate keys established as a result of the UE301 authentication procedure. In the case where USIM-based authentication is used, the AMF321 may acquire security material from the AUSF 322. The AMF321 may also include a Security Context Management (SCM) function that receives keys from the SEA that it uses to derive access network-specific keys. Further, the AMF321 may be a termination point of the RAN CP interface, which may include or be AN N2 reference point between the (R) AN 311 and the AMF 321; the AMF321 may be the termination point of NAS (N1) signaling and performs NAS ciphering and integrity protection.

The AMF321 may also support NAS signaling with the UE301 through an N3 interworking function (IWF) interface. An N3IWF may be used to provide access to untrusted entities. The N3IWF may be the termination point of the N2 interface between the (R) AN310 and the AMF321 for the control plane and may be the termination point of the N3 reference point between the (R) AN310 and the UPF302 for the user plane. As such, AMF321 may process N2 signaling from SMF324 and AMF321 for PDU sessions and QoS, encapsulate/decapsulate packets for IPSec and N3 tunneling, label N3 user plane packets in the uplink, and perform QoS corresponding to N3 packet labeling, taking into account QoS requirements associated with such labeling received over N2. The N3IWF may also relay uplink and downlink control plane NAS signaling between the UE301 and the AMF321 via the N1 reference point between the UE301 and the AMF321, and relay uplink and downlink user plane packets between the UE301 and the UPF 302. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 301. The AMF321 may expose a Namf service based interface and may be a termination point of an N14 reference point between two AMFs 321 and an N17 reference point between the AMF321 and a 5G device identification register (5G-EIR) (not shown in fig. 3).

UE301 may need to register with AMF321 in order to receive network services. The Registration Management (RM) is used to register or deregister the UE301 with the network (e.g., the AMF 321) and establish a UE context in the network (e.g., the AMF 321). The UE301 may operate in an RM registration state or an RM deregistration state. In the RM deregistered state, the UE301 is not registered with the network and the UE context in the AMF321 does not maintain valid location or routing information for the UE301, so the AMF321 cannot reach the UE 301. In the RM registration state, the UE301 registers with the network, and the UE context in the AMF321 may maintain valid location or routing information of the UE301 so that the UE301 may be reached by the AMF 321. In the RM registration state, the UE301 may perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., to inform the network that the UE301 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

The AMF321 may store one or more RM contexts for the UE301, where each RM context is associated with a particular access to the network. The RM context may be a data structure, database object, etc. that indicates or stores registration status and periodic update timers, etc. for each access type. The AMF321 may also store a 5GC MM context, which may be the same as or similar to the (E) MM context discussed previously. In various embodiments, AMF321 may store CE mode B restriction parameters for UE301 in an associated MM context or RM context. The AMF321 may also derive this value from the UE's usage setting parameters already stored in the UE context (and/or MM/RM context) when needed.

Connection Management (CM) may be used to establish and release the signaling connection between UE301 and AMF321 over the N1 interface. The signaling connection is used to enable NAS signaling exchange between UE301 and CN120 and includes AN Access Network (AN) signaling connection (e.g., RRC connection or UE-N3IWF connection for non-3 GPP) between the UE and the AN and AN N2 connection for UE301 between the AN (e.g., RAN310) and AMF 321. UE301 may operate in one of two CM states: a CM IDLE (CM-IDLE) mode or a CM CONNECTED (CM-CONNECTED) mode. When the UE301 is operating in the CM-IDLE state/mode, the UE301 may not have AN NAS signaling connection established with the AMF321 over the N1 interface, and there may be AN (R) AN310 signaling connection (e.g., N2 and/or N3 connection) for the UE 301. When the UE301 is operating in the CM-CONNECTED state/mode, the UE301 may have AN NAS signaling connection established with the AMF321 over the N1 interface, and there may be AN (R) AN310 signaling connection (e.g., AN N2 and/or N3 connection) for the UE 301. Establishing the N2 connection between the (R) AN310 and the AMF321 may transition the UE301 from the CM-IDLE mode to the CM-CONNECTED mode, and when releasing N2 signaling between the (R) AN310 and the AMF321, the UE301 may transition from the CM-CONNECTED mode to the CM-IDLE mode.

SMF324 may be responsible for: session Management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address assignment and management (including optional authorization); selecting and controlling the UP function; configuring traffic steering at the UPF to route traffic to the correct destination; terminating the interface to the policy control function; controlling a portion of policy enforcement and QoS; lawful interception (for SM events and interface with LI system); NAS message terminating SM part; a downlink data notification; the originator of the AN specific SM message, sent to the AN through N2 via AMF; the SSC pattern for the session is determined. SM may refer to the management of a PDU session, which may refer to a PDU connection service that provides or enables the exchange of PDUs between UE301 and a Data Network (DN)303 identified by a Data Network Name (DNN). The PDU session may be established upon request of the UE301, modified upon request of the UE301 and 5GC 320, and released upon request of the UE301 and 5GC 320 using NAS SM signaling exchanged over the N1 reference point between the UE301 and SMF 324. The 5GC 320 may trigger a specific application in the UE301 based on a request from an application server. In response to receiving the trigger message, UE301 may communicate the trigger message (or related portion/information of the trigger message) to one or more identified applications in UE 301. The identified application(s) in UE301 may establish a PDU session to a particular DNN. SMF324 may check whether UE301 request conforms to user subscription information associated with UE 301. In this regard, SMF324 may retrieve and/or request to receive update notifications from UDM 327 regarding SMF 324-level subscription data.

SMF324 may include the following roaming functions: processing the local enforcement to apply a QoS SLA (VPLMN); a charging data collection and charging interface (VPLMN); lawful interception (in the interface of VPLMN and LI systems for SM events); interaction with the foreign DN is supported for signaling PDU session authorization/authentication through the foreign DN. An N16 reference point between two SMFs 324 may be included in system 300, which may be between another SMF324 in a visited network and a SMF324 in a home network in a roaming scenario. Additionally, SMF324 may expose an Nsmf service based interface.

The NEF323 may provide a means for securely exposing services and capabilities provided by 3GPP network functions for third parties, internal exposure/re-exposure, application functions (e.g., AF 328), edge computing or fog computing systems, and the like. In such embodiments, NEF323 may authenticate, authorize, and/or restrict AF. NEF323 may also translate information exchanged with AF328 and with internal network functions. For example, the NEF323 may convert between the AF service identifier and the internal 5GC information. The NEF323 may also receive information from other Network Functions (NFs) based on their exposed capabilities. This information may be stored as structured data in the NEF323 or in the data storage NF using a standardized interface. The stored information may then be re-exposed by the NEF323 to other NFs and AFs, and/or used for other purposes, such as analysis. In addition, the NEF323 may expose an interface based on the Nnef service.

NRF 325 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF 325 also maintains information of available NF instances and the services it supports. As used herein, the term "instantiation" or the like may refer to the creation of an instance, and "instance" may refer to the specific occurrence of an object, which may occur, for example, during execution of program code. Additionally, NRF 325 may expose an interface based on nrrf services.

PCF 326 may provide policy rules to control plane function(s) to enforce them, and may also support a unified policy framework to manage network behavior. PCF 326 may also implement a Front End (FE) to access subscription information related to policy decisions in the UDR of UDM 327. PCF 326 may communicate with AMF321 via an N15 reference point between PCF 326 and AMF321, which may include PCF 326 in a visited network and AMF321 in a roaming scenario. PCF 326 may communicate with AF328 via an N5 reference point between PCF 326 and AF 328; and communicates with SMF324 via an N7 reference point between PCF 326 and SMF 324. The system 200 and/or CN120 may also include an N24 reference point between the PCF 326 (in the home network) and the PCF 326 in the visited network. In addition, PCF 326 may expose an interface based on Npcf services.

UDM 327 may process subscription related information to support processing of communication sessions by network entities and may store subscription data for UE 301. For example, subscription data may be transferred between UDM 327 and AMF321 over an N8 reference point (not shown in FIG. 3) between UDM 327 and AMF 321. UDM 327 may include two parts: an application FE and a User Data Repository (UDR) (the FE and UDR are not shown in fig. 3). The UDR may store subscription data and policy data for UDM 327 and PCF 326, and/or structured data and application data for exposure (including Packet Flow Description (PFD) for application detection, application request information for multiple UEs 201) for NEF 323. UDR 221 may expose an Nudr service-based interface to allow UDM 327, PCF 326, and NEF323 to access a particular set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM FE that is responsible for credential handling, location management, subscription management, and the like. Several different front ends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and executes authentication credential processing; user identification processing; access authorization; registration/mobility management; and subscription management. UDR may interact with SMF324 via an N10 reference point between UDM 327 and SMF 324. UDM 327 may also support SMS management, where an SMS-FE implements similar application logic as previously described. Additionally, UDM 327 may expose a numm service based interface.

The AF328 can provide application impact on traffic routing, access Network Capability Exposure (NCE), and interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC 320 and the AF328 to provide information to each other via the NEF323, which may be used for edge computing implementation. In such an implementation, network operator and third party services may be hosted near the UE301 access connection point to enable efficient service delivery with reduced end-to-end delay and load on the transport network. For edge calculation implementations, the 5GC may select a UPF302 close to the UE301 and perform traffic steering from the UPF302 to the DN303 via the N6 interface. This may be based on UE subscription data, UE location and information provided by the AF 328. In this way, the AF328 may affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow AF328 to interact directly with the relevant NFs when AF328 is considered a trusted entity. Additionally, the AF328 may expose a Naf service based interface.

NSSF 329 may select a set of network slice instances that serve UE 301. NSSF 329 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and mapping to a single NSSAI (S-NSSAI) of the subscription, if needed. The NSSF 329 may also determine the set of AMFs or list of candidate AMFs 221 for serving the UE301 based on a suitable configuration and possibly by querying the NRF 325. Selection of a set of network slice instances for UE301 may be triggered by AMF321 (which registers UE301 by interacting with NSSF 329), which may result in a change in AMF 321. NSSF 329 may interact with AMF321 via the N22 reference point between AMF321 and NSSF 329; and may communicate with another NSSF 329 in the visited network over an N31 reference point (not shown in fig. 3). Additionally, NSSF 329 may expose an interface based on the NSSF service.

As previously described, CN 320 may include an SMSF, which may be responsible for SMS subscription checking and verification, and relaying SM messages to/from UE301 from/to other entities, such as SMS-GMSC/IWMSC/SMS routers. The SMS may also interact with AMF321 and UDM 327 for notification procedures that UE301 may use for SMS delivery (e.g., set a UE unreachable flag, and notify UDM 327 when UE301 is available for SMS).

CN120 may also include other elements not shown in fig. 3, such as a data storage system/architecture, 5G device identity register (5G-EIR), Secure Edge Protection Proxy (SEPP), and so forth. The data storage system may include a structured data storage network function (SDSF), an unstructured data storage network function (UDSF), and so forth. Any NF may store unstructured data into or retrieve unstructured data (e.g., UE context) from the UDSF via the N18 reference point (not shown in fig. 3) between any NF and the UDSF. The individual NFs may share a UDSF for storing their respective unstructured data, or the individual NFs may each have their own UDSF located at or near the individual NFs. Additionally, the UDSF may expose an interface based on the Nudsf service (not shown in fig. 3). The 5G-EIR may be a NF that checks the status of a permanent device identifier (PEI) to determine if a particular device/entity is blacklisted from the network; the SEPP may be a non-transparent proxy that performs topology hiding, message filtering and policing on the inter-PLMN control plane interface.

Additionally, there may be more reference points and/or service-based interfaces between NF services in the NF; however, these interfaces and reference points are omitted from FIG. 3 for clarity. In one example, CN 320 may include an Nx interface, which is an inter-CN interface between an MME (e.g., MME 221) and AMF321, in order to enable interworking between CN 320 and CN 220. Other example interfaces/references these points may include an N5G-EIR service based interface exposed by 5G-EIR, an N27 reference point between the NRF in the visited network and the NRF in the home network; and an N31 reference point between the NSSF in the visited network and the NSSF in the home network.

In some embodiments, the system 300 may include a UE331, which may be the same as or similar to the UEs 101, 201, and 301 discussed previously. As shown in fig. 3, UE301 and UE331 may perform V2X communication with each other via a PC5 reference point. The PC5 reference points may include LTE-based PC5 and/or NR-based PC 5. In some embodiments, PC5 is a side link, and thus in these embodiments, the terms comprising "PC 5" and the terms comprising "side link" may be interchangeable.

Provisioning of PC5QoS authorization information for V2X services will be discussed below.

Fig. 4 illustrates a process diagram 400 for provisioning of PC5QoS authorization information for V2X services to a UE and a RAN in accordance with some embodiments of the present disclosure.

UE401 (e.g., UE(s) 101 in fig. 1, UE201 in fig. 2, UE301 in fig. 3, etc.) may connect to RAN402 (e.g., RAN110 in fig. 1, EUTRAN210 in fig. 2, RAN310 in fig. 3, etc.). The UE401 may communicate with the AMF403 of the 5GC (e.g., the AMF321 in fig. 3) via the N1 reference point. The RAN402 may communicate with the AMF403 via the N2 reference point. The AMF403 may communicate with the PCF 404 of the 5GC (e.g., PCF 326 in fig. 3) via the N15 reference point.

As shown in fig. 4, at 410, the PCF 404 may determine V2X policy/parameter information for PC5QoS authorization. The determination may be triggered based on various trigger conditions.

In one embodiment, the UE401 may generate a UE policy provisioning request (UE policy provisioning request) for the V2X policy/parameter information and send the UE policy provisioning request to the AMF403, as shown at 408. AMF403 may then send a UE policy provisioning request to PCF 404, as shown at 409. PCF 404 may trigger the determination of V2X policy/parameter information in response to receiving a UE policy provisioning request.

In one embodiment, PCF 404 may trigger the determination of V2X policy/parameter information in response to a network-triggered update of V2X policy/parameter information (e.g., a UE location change, a subscribed S-NSSAI change), which is not shown in fig. 4.

After determining the V2X policy/parameter information, the PCF 404 may send the V2X policy/parameter information to the AMF403 at 420, e.g., via a Namf _ Communication _ N1N2MessageTransfer message.

At 430, AMF403 may send V2X policy/parameter information to UE401, e.g., via NAS message.

In one embodiment, the V2X policy/parameter information may include a mapping between V2X service types and PC5QoS parameters. In one embodiment, the mapping between V2X service types and PC5QoS parameters may be differentiated for unicast, multicast, and broadcast. For example, the mapping between V2X service types and PC5QoS parameters may include: mapping between V2X service types for unicast and PC5QoS parameters, V2X service types for multicast and PC5QoS parameters, and/or V2X service types for broadcast and PC5QoS parameters.

In one embodiment, the V2X service type may be indicated by a Provider Service Identifier (PSID) or an Intelligent Transmission System (ITS) application identifier (ITS-AID).

In one embodiment, the PC5QoS parameters may include a PC 55G QoS identifier (PQI). Different values of the PQI may correspond to respective sets of specific QoS requirements.

In one embodiment, the PC5QoS parameters may alternatively or additionally include: guaranteed Flow Bit Rate (GFBR) and Maximum Flow Bit Rate (MFBR) for Guaranteed Bit Rate (GBR) QoS flows; and GFBR and MFBR for delaying critical GBR QoS flows.

In one embodiment, the UE401 may use the V2X policy/parameter information for PC5 radio resource scheduling purposes. For example, in one embodiment, UE401 may determine PC5QoS parameters based on a mapping between V2X service types and PC5QoS parameters received in V2X policy/parameter information and the V2X service type of UE401 and perform V2X communications based on the determined PC5QoS parameters for UE 401. In one embodiment, the determined PC5QoS parameters for UE401 include one PQI value and/or one GFBR/MFBR value. In another embodiment, the determined PC5QoS parameters for UE401 include more than one PQI value and/or more than one GFBR/MFBR value.

In response to receiving the V2X policy/parameter information from AMF403 at 430, UE401 may send a response to AMF403 at 450. At 460, AMF403 may forward the response of UE401 to PCF 404, e.g., via a Namf _ Communication _ N1MessageNotify message.

In one embodiment, the PCF 404 may include the V2X Policy/parameter information in a UE Policy Container (UE Policy Container) of the Namf _ Communication _ N1N2MessageTransfer message. In the case where PCF 404 provisions V2X policy/parameter information in response to receiving a UE policy provisioning request from UE401, UE401 may send a UE policy provisioning request including a UE policy container to AMF 403; and AMF403 may forward the UE policy container to PCF 404.

Provisioning of V2X policy/parameter information to UE401 may use the procedure(s) defined in section 6.2 of 3GPP TS 23.287v0.2.0 (2019-03).

In embodiments where the UE401 performs V2X communications in network control mode, the RAN402 may need V2X policy/parameter information to assist PC5 radio resource scheduling. In one embodiment, as shown at 440, AMF403 may send V2X policy/parameter information to RAN402, for example, via NG application protocol layer (NGAP) messages.

The sequence of operations shown in fig. 4 is for illustration purposes only, and operation 440 may be performed at any time after the AMF403 receives the V2X policy/parameter information at 420.

In embodiments where UE401 performs V2X Communication in network control mode, PCF 404 may include V2X Policy/parameter information in both the UE Policy Container (for the UE) and the N2PC5 Policy Container (N2PC5 Policy Container) (for the RAN) of the Namf _ Communication _ N1N2MessageTransfer message. When the AMF403 receives such a Namf _ Communication _ N1N2MessageTransfer message, the AMF403 may forward the V2X policy/parameter information to the RAN402 via an NGAP message and forward the V2X policy/parameter information to the UE401 via a NAS message.

In one embodiment, the V2X policy/parameter information sent to RAN402 at 440 may be the same as or similar to the V2X policy/parameter information sent to UE401 at 430, i.e., the V2X policy/parameter information sent to RAN402 may include a mapping between V2X service types and PC5QoS parameters.

Similarly, in one embodiment, the mapping between V2X service types sent to RAN402 and PC5QoS parameters may be differentiated for unicast, multicast, and broadcast. For example, the mapping between V2X service types and PC5QoS parameters may include: mapping between V2X service types for unicast and PC5QoS parameters, V2X service types for multicast and PC5QoS parameters, and/or V2X service types for broadcast and PC5QoS parameters.

In one embodiment, the PC5QoS parameters in the mapping provisioned to the RAN402 may be common to all V2X service types in the mapping, unlike the mapping provisioned to the UE 401. For example, in the mapping provisioned to RAN402, all V2X service types in the mapping may be indicated by a common character, i.e., no particular V2X service type is present in the mapping.

Alternatively or additionally, in one embodiment, the V2X policy/parameter information sent to the RAN402 at 440 may include a mapping between destination layer 2 IDs and PC5QoS parameters.

In one embodiment, the mapping between the destination layer 2 ID and the PC5QoS parameters may include: mapping between default destination layer 2 ID for unicast initial unicast signaling and PC5QoS parameters; mapping between destination layer 2 ID and PC5QoS parameters for multicast; and/or a mapping between destination layer 2 ID and PC5QoS parameters for the broadcast.

In one embodiment, the PC5QoS parameters in the map may be common to all destination layer 2 IDs in the map. For example, in a map provisioned to RAN402, all destination layer 2 IDs in the map may be indicated by a common character, i.e., no particular destination layer 2 ID is present in the map.

In one embodiment, the PC5QoS parameters for the UE determined by the RAN402 from the mapping may include one or more PQI values and/or one or more GFBR/MFBR values, although not limited in this respect.

Provisioning the RAN402 with V2X policy/parameter information may use the procedure(s) defined in section 6.5 of 3GPP TS 23.287v0.2.0 (2019-03).

In one embodiment, the PC5QoS authorization information for V2X services provisioned to the UE and RAN in the procedure of fig. 4 may be used for PC5 radio resource scheduling when the PC5QoS parameters are not received from the upper layer (upper layer). However, the present disclosure is not limited in this regard.

The procedure of provisioning the UE and the RAN with PC5QoS authorization information for V2X service has been described above. A method for provisioning the UE and/or RAN with PC5QoS authorization information for V2X service will be described below from the perspective of the UE, RAN, and 5GC (e.g., PCF), respectively.

Fig. 5 illustrates a flow diagram of a method 500 for provisioning a UE with PC5QoS authorization information for V2X services from the perspective of the UE, in accordance with some embodiments of the present disclosure.

At 510, a UE (e.g., UE(s) 101 in fig. 1, UE201 in fig. 2, UE301 in fig. 3, UE401 in fig. 4, etc.) is configured to receive a message including V2X policy/parameter information from a 5GC, e.g., from PCF 404 in fig. 4 via AMF403 in fig. 4. The V2X policy/parameter information may include a mapping between V2X service types and PC5QoS parameters. The V2X policy/parameter information is described in detail above and will not be described here.

At 520, the UE may be configured to determine PC5QoS parameters for the UE based on a mapping between V2X service types and PC5QoS parameters and the V2X service type of the UE.

At 530, the UE may be configured to perform V2X communications based on the PC5QoS parameters for the UE.

Both fig. 6 and 7 show a method for provisioning the RAN with PC5QoS authorization information for V2X services from the RAN's perspective. Fig. 6 illustrates a flow diagram of a method 600 for provisioning PC5QoS authorization information for V2X services to a RAN from the perspective of the RAN in accordance with some embodiments of the present disclosure.

At 610, the RAN (e.g., RAN110 in fig. 1, EUTRAN210 in fig. 2, RAN310 in fig. 3, RAN 401 in fig. 4, etc.) may be configured to receive a message including V2X policy/parameter information from the 5GC, e.g., from PCF 404 in fig. 4 via AMF403 in fig. 4. The V2X policy/parameter information may include a mapping between V2X service types and PC5QoS parameters. The V2X policy/parameter information is described in detail above and will not be described here.

At 620, the RAN may be configured to determine PC5QoS parameters for the UE based on a mapping between V2X service types and PC5QoS parameters.

At 630, the RAN may be configured to schedule PC5 radio resources for V2X communications for the UE based on the PC5QoS parameters for the UE.

Fig. 7 illustrates a flow diagram of a method 700 for provisioning PC5QoS authorization information for V2X services to a RAN from the perspective of the RAN in accordance with some embodiments of the present disclosure.

In contrast to fig. 6, fig. 7 relates to a mapping between destination layer 2 ID and PC5QoS parameters, rather than the mapping between V2X service type and PC5QoS parameters of fig. 6.

At 710, the RAN (e.g., RAN110 in fig. 1, EUTRAN210 in fig. 2, RAN310 in fig. 3, RAN 401 in fig. 4, etc.) may be configured to receive a message including V2X policy/parameter information from a 5GC, e.g., PCF 404 in fig. 4 via AMF403 in fig. 4. The V2X policy/parameter information may include a mapping between destination layer 2 IDs and PC5QoS parameters. The V2X policy/parameter information is described in detail above and will not be described here.

At 720, the RAN may be configured to determine PC5QoS parameters for the UE based on the mapping between the destination layer 2 ID and the PC5QoS parameters.

At 730, the RAN may be configured to schedule PC5 radio resources for V2X communication for the UE based on the PC5QoS parameters for the UE.

Both fig. 8 and fig. 9 show a method for provisioning the UE and/or RAN with PC5QoS authorization information for V2X services from a 5GC perspective. Fig. 8 illustrates a flow diagram of a method 800 for provisioning UEs with PC5QoS authorization information for V2X services from a 5GC perspective in accordance with some embodiments of the present disclosure.

At 810, a 5GC (e.g., a PCF (e.g., PCF 326 in fig. 3, PCF 404 in fig. 4)) may be configured to generate V2X policy/parameter information. The V2X policy/parameter information may include a mapping between V2X service types and PC5QoS parameters. The V2X policy/parameter information is described in detail above and will not be described here.

At 820, the PCF may be configured to cause V2X policy/parameter information to be sent to the UE for V2X communication of the UE.

Fig. 9 illustrates a flow diagram of a method 900 for provisioning a RAN with PC5QoS authorization information for V2X services from a 5GC perspective in accordance with some embodiments of the present disclosure.

At 910, a 5GC (e.g., a PCF (e.g., PCF 326 in fig. 3, PCF 404 in fig. 4)) may be configured to generate V2X policy/parameter information. The V2X policy/parameter information may include a first mapping between destination layer 2 IDs and PC5QoS parameters and/or a second mapping between V2X service types and PC5QoS parameters. The V2X policy/parameter information is described in detail above and will not be described here.

At 920, the PCF may be configured to cause V2X policy/parameter information to be sent to the AN to schedule PC5 radio resources for V2X communications of the UE.

Fig. 10 illustrates example components of a device 1000 according to some embodiments. In some embodiments, device 1000 may include application circuitry 1002, baseband circuitry 1004, Radio Frequency (RF) circuitry 1006, Front End Module (FEM) circuitry 1008, one or more antennas 1010, and Power Management Circuitry (PMC)1012 coupled together at least as shown. The illustrated components of the apparatus 1000 may be included in a UE or AN. In some embodiments, the apparatus 1000 may include fewer elements (e.g., the AN may not use the application circuitry 1002, but rather include a processor/controller to process IP data received from the EPC). In some embodiments, device 1000 may include additional elements, such as memory/storage devices, displays, cameras, sensors, or input/output (I/O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., for a Cloud-RAN (C-RAN) implementation, the circuitry may be included separately in more than one device).

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

Baseband circuitry 1004 may include circuitry such as, but not limited to: one or more single-core or multi-core processors. Baseband circuitry 1004 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of RF circuitry 1006 and to generate baseband signals for the transmit signal path of RF circuitry 1006. Baseband processing circuitry 1004 may interface with application circuitry 1002 to generate and process baseband signals and control operation of RF circuitry 1006. For example, in some embodiments, the baseband circuitry 1004 may include a third generation (3G) baseband processor 1004A, a fourth generation (4G) baseband processor 1004B, a fifth generation (5G) baseband processor 1004C, or other baseband processor(s) 1004D for other existing generations, generations in development or to be developed in the future (e.g., sixth generation (6G), etc.). The baseband circuitry 1004 (e.g., one or more of the baseband processors 1004A-D) may handle various radio control functions that support communication with one or more radio networks via the RF circuitry 1006. In other embodiments, some or all of the functions of the baseband processors 1004A-D may be included in modules stored by the memory 1004G and executed via a Central Processing Unit (CPU) 1004E. 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 circuitry of baseband circuitry 1004 may include Fast Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 1004 may include convolution, tail-biting convolution, turbo, Viterbi (Viterbi), and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

In some embodiments, the baseband circuitry 1004 may include one or more audio Digital Signal Processors (DSPs) 1004F. The audio DSP(s) 1004F may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, components of the baseband circuitry may be combined as appropriate in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuitry 1004 and the application circuitry 1002 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 1004 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 1004 may support communication 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 circuitry 1004 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

The RF circuitry 1006 may support communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1006 may include switches, filters, amplifiers, and the like to facilitate communication with the wireless network. The RF circuitry 1006 may include a receive signal path that may include circuitry to down-convert RF signals received from the FEM circuitry 1008 and provide baseband signals to the baseband circuitry 1004. RF circuitry 1006 may also include a transmit signal path that may include circuitry to up-convert baseband signals provided by baseband circuitry 1004 and provide an RF output signal to FEM circuitry 1008 for transmission.

In some embodiments, the receive signal path of the RF circuitry 1006 may include a mixer circuit 1006a, an amplifier circuit 1006b, and a filter circuit 1006 c. In some embodiments, the transmit signal path of the RF circuitry 1006 may include filter circuitry 1006c and mixer circuitry 1006 a. The RF circuitry 1006 may also include synthesizer circuitry 1006d for synthesizing frequencies for use by the mixer circuitry 1006a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 1006a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 1008 based on the synthesized frequency provided by the synthesizer circuit 1006 d. The amplifier circuit 1006b may be configured to amplify the downconverted signal, and the filter circuit 1006c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 1004 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, but this is not required. In some embodiments, mixer circuit 1006a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1006a of the transmit signal path may be configured to upconvert the input baseband signal based on a synthesis frequency provided by the synthesizer circuitry 1006d to generate an RF output signal for the FEM circuitry 1008. The baseband signal may be provided by baseband circuitry 1004 and may be filtered by filter circuitry 1006 c.

In some embodiments, mixer circuitry 1006a of the receive signal path and mixer circuitry 1006a of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion, respectively.

In some embodiments, the mixer circuit 1006a of the receive signal path and the mixer circuit 1006a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, mixer circuitry 1006a of the receive signal path and mixer circuitry 1006a of the transmit signal path may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, mixer circuit 1006a of the receive signal path and mixer circuit 1006a of the transmit signal path may be configured for superheterodyne operation.

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 circuitry 1006 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 1004 may include a digital baseband interface to communicate with the RF circuitry 1006.

In some dual-mode embodiments, separate radio IC circuitry may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, synthesizer circuit 1006d may be a fractional-N synthesizer or a fractional-N/N +1 synthesizer, although the scope of embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuit 1006d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

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

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by the baseband circuitry 1004 or the application processor 1002 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application processor 1002.

Synthesizer circuit 1006d of RF circuit 1006 may include a frequency divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual-mode divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N +1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, a DLL may include a set of cascaded, tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to decompose the VCO period into at most Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this manner, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, the synthesizer circuit 1006d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used with a quadrature generator and divider circuit to generate a plurality of signals having a plurality of mutually different phases at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuitry 1006 may include an IQ/polarity converter.

FEM circuitry 1008 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 1010, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 1006 for further processing. The FEM circuitry 1008 may also include a transmit signal path that may include circuitry configured to amplify signals provided by the RF circuitry 1006 for transmission by one or more of the one or more antennas 1010. In various embodiments, amplification through the transmit signal path or the receive signal path may be done only in the RF circuitry 1006, only in the FEM 1008, or both the RF circuitry 1006 and the FEM 1008.

In some embodiments, the FEM circuitry 1008 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a Low Noise Amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuitry 1006). The transmit signal path of the FEM circuitry 1008 may include a Power Amplifier (PA) to amplify an input RF signal (e.g., provided by the RF circuitry 1006) and one or more filters to generate an RF signal for subsequent transmission (e.g., by one or more of the one or more antennas 1010).

In some embodiments, PMC1012 may manage power provided to baseband circuitry 1004. Specifically, PMC1012 may control power selection, voltage scaling, battery charging, or DC-DC conversion. PMC1012 may generally be included when device 1000 is capable of being powered by a battery, for example, when the device is included in a UE. PMC1012 may improve power conversion efficiency while providing desired implementation size and heat dissipation characteristics.

Although figure 10 shows PMC1012 coupled only to baseband circuitry 1004. However, in other embodiments, PMC1012 may additionally or alternatively be coupled with and perform similar power management operations on other components, such as, but not limited to, application circuitry 1002, RF circuitry 1006, or FEM 1008.

In some embodiments, PMC1012 may control or otherwise be part of various power saving mechanisms of device 1000. For example, if the device 1000 is in an RRC _ Connected state where it is still Connected to the RAN node when the device 1000 expects to receive traffic soon, then after a period of inactivity it may enter a state called discontinuous reception mode (DRX). During this state, device 1000 may be powered down for a brief interval of time, thereby conserving power.

If there is no data traffic activity for an extended period of time, device 1000 can transition to an RRC _ Idle state in which device 1000 is disconnected from the network and no operations such as channel quality feedback, handover, etc. are performed. The device 1000 enters a very low power state and performs paging, where the device 1000 again wakes up periodically to listen to the network and then powers down again. Device 1000 may not receive data in this state and may transition back to the RRC Connected state in order to receive data.

The additional power-save mode may allow the device to be unavailable to the network for a period longer than the paging interval (ranging from a few seconds to a few hours). During this time, the device is completely unable to access the network and may be completely powered down. Any data transmitted during this period will incur a significant delay and the delay is assumed to be acceptable.

A processor of the application circuitry 1002 and a processor of the baseband circuitry 1004 may be used to execute elements of one or more instances of a protocol stack. For example, a processor of the baseband circuitry 1004, alone or in combination, may be configured to perform layer 3, layer 2, or layer 1 functions, while a processor of the application circuitry 1004 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., Transmission Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include an RRC layer. As referred to 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. As referred to herein, layer 1 may comprise the Physical (PHY) layer of the UE/RAN node.

Fig. 11 illustrates an example interface of a baseband circuit according to some embodiments. As described above, the baseband circuitry 1004 of FIG. 10 may include processors 1004A-1004E and memory 1004G used by the processors. Each of the processors 1004A-1004E may include a memory interface 1104A-1104E, respectively, to send and receive data to and from the memory 1004G.

The baseband circuitry 1004 may also include one or more interfaces, to communicatively couple to other circuitry/devices, such as a memory interface 1112 (e.g., an interface for sending/receiving data to/from memory external to baseband circuitry 1004), an application circuitry interface 1114 (e.g., an interface for sending/receiving data to/from application circuitry 1002 of fig. 10), an RF circuitry interface 1116 (e.g., an interface for sending/receiving data to/from RF circuitry 1006 of fig. 10), a wireless hardware connection interface 1118 (e.g., an interface for sending/receiving data to/from Near Field Communication (NFC) components, bluetooth components (e.g., bluetooth low power), Wi-Fi components, and other communication components), and a power management interface 1120 (e.g., an interface for sending/receiving power or control signals to/from PMC 1012).

Fig. 12 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 12 shows a diagrammatic representation of hardware resources 1200, which includes one or more processors (or processor cores) 1210, one or more memory/storage devices 1220, and one or more communication resources 1230, each of which may be communicatively coupled via a bus 1240. For embodiments utilizing node virtualization (e.g., NFV), hypervisor 1202 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 1200.

Processor 1210 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP) such as a baseband processor, an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1212 and processor 1214.

The memory/storage device 1220 may include a main memory, a disk storage, or any suitable combination thereof. The memory/storage 1220 may include, but is not limited to, any type of volatile or non-volatile memory, such as Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state storage, and the like.

The communication resources 1230 may include interconnection or network interface components or other suitable devices to communicate with one or more peripherals 1204 or one or more databases 1206 via a network 1208. For example, the communication resources 1230 can include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, bluetooth components (e.g., bluetooth low energy), Wi-Fi components, and other communication components.

Instructions 1250 may include software, programs, applications, applets, apps, or other executable code for causing at least any of processors 1210 to perform any one or more of the methods discussed herein. The instructions 1250 may reside, completely or partially, within at least one of the processor 1210 (e.g., within a processor's cache memory), the memory/storage 1220, or any suitable combination thereof. Further, any portion of instructions 1250 may be communicated to hardware resource 1200 from any combination of peripheral devices 1204 or databases 1206. Thus, the memories of processor 1210, memory/storage device 1220, peripheral devices 1204, and database 1206 are examples of computer-readable and machine-readable media.

The following paragraphs describe examples of various embodiments.

Example 1 includes an apparatus for a User Equipment (UE), the apparatus comprising: a Radio Frequency (RF) interface; and processor circuitry coupled with the RF interface, wherein the RF interface is to: receive a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is to: determining PC5QoS parameters for the UE based on the mapping and a V2X service type of the UE; and performing V2X communication based on the PC5QoS parameters for the UE.

Example 2 includes the apparatus of example 1, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 3 includes the apparatus of examples 1 or 2, wherein the V2X service type of the UE is indicated by a Provider Service Identifier (PSID) or an Intelligent Transmission System (ITS) application identifier (ITS-AID).

Example 4 includes the apparatus of any one of examples 1 to 3, wherein the PC5QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 5 includes the apparatus of example 4, wherein the PC5QoS parameters for the UE further include: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 6 includes the apparatus of any one of examples 1 to 5, wherein the processor circuit is to: generating a UE policy provisioning request for the V2X policy/parameter information and causing the UE policy provisioning request to be sent to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy provisioning request.

Example 7 includes the apparatus of any one of examples 1 to 5, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 8 includes the apparatus of any one of examples 1 to 7, wherein the RF interface is to receive the message from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 9 includes AN apparatus for AN Access Node (AN), the apparatus comprising: a Radio Frequency (RF) interface; and processor circuitry coupled with the RF interface, wherein the RF interface is to: receive a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is to: determining a PC5QoS parameter for a User Equipment (UE) based on the mapping; and scheduling PC5 radio resources for V2X communications for the UE based on the PC5QoS parameters for the UE.

Example 10 includes the apparatus of example 9, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 11 includes the apparatus of examples 9 or 10, wherein the PC5QoS parameters in the map are common to all V2X service types in the map if all V2X service types in the map are indicated by a common character.

Example 12 includes the apparatus of any one of examples 9 to 11, wherein the PC5QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 13 includes the apparatus of example 12, wherein the PC5QoS parameters for the UE further include: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 14 includes the apparatus of any one of examples 9 to 13, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request for the V2X policy/parameter information from the UE.

Example 15 includes the apparatus of any one of examples 9 to 13, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 16 includes the apparatus of any one of examples 9 to 15, wherein the RF interface is to receive the message from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 17 includes the apparatus of any one of examples 9 to 16, wherein the AN comprises a next generation nodeb (gnb).

Example 18 includes AN apparatus for AN Access Node (AN), the apparatus comprising: a Radio Frequency (RF) interface; and processor circuitry coupled with the RF interface, wherein the RF interface is to: receive a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between a destination layer 2 ID and a sidelink quality of service (QoS) parameter, and wherein the processor circuit is to: determining a sidelink QoS parameter for a User Equipment (UE) based on the mapping; and scheduling sidelink radio resources for V2X communication for the UE based on the sidelink QoS parameter for the UE.

Example 19 includes the apparatus of example 18, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameter comprises: mapping between default destination layer 2 ID for unicast initial unicast signaling and sidelink QoS parameters; mapping between destination layer 2 ID and sidelink QoS parameters for multicast; or a mapping between the destination layer 2 ID for the broadcast and the sidelink QoS parameters.

Example 20 includes the apparatus of example 18 or 19, wherein the sidelink QoS parameter in the map is common to all destination layer 2 IDs in the map if the all destination layer 2 IDs are indicated by a common character.

Example 21 includes the apparatus of any one of examples 18 to 20, wherein the sidelink QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 22 includes the apparatus of example 21, wherein the sidelink QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 23 includes the apparatus of any one of examples 18 to 22, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request for the V2X policy/parameter information from the UE.

Example 24 includes the apparatus of any one of examples 18 to 22, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 25 includes the apparatus of any one of examples 18 to 24, wherein the RF interface is to receive the message from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 26 includes the apparatus of any one of examples 18 to 25, wherein the AN comprises a next generation nodeb (gnb).

Example 27 includes an apparatus of a 5G core network (5GC) for a fifth generation (5G) system (5GS), the apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: generating vehicle-to-anything (V2X) policy/parameter information, wherein the V2X policy/parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters; and causing transmission of the V2X policy/parameter information to a User Equipment (UE) for V2X communication of the UE.

Example 28 includes the apparatus of example 27, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 29 includes the apparatus of example 27 or 28, wherein the interface circuitry is to send the V2X policy/parameter information to the UE via an access and mobility management function (AMF) of the 5 GC.

Example 30 includes the apparatus of any one of examples 27 to 29, wherein the processor circuit is to: generating the V2X policy/parameter information in response to receiving a UE policy provisioning request for V2X policy/parameter information from the UE.

Example 31 includes the apparatus of any one of examples 27 to 29, wherein the processor circuit is to: generating the V2X policy/parameter information in response to a network-triggered update to V2X policy/parameter information.

Example 32 includes an apparatus of a 5G core network (5GC) for a fifth generation (5G) system (5GS), the apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: generating vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information includes a first mapping between destination layer 2 IDs and PC5 quality of service (QoS) parameters or a second mapping between V2X service types and PC5QoS parameters; and causing transmission of the V2X policy/parameter information to AN Access Node (AN) to schedule PC5 radio resources for V2X communications of a User Equipment (UE).

Example 33 includes the apparatus of example 32, wherein the first mapping between the destination layer 2 ID and the PC5QoS parameter comprises: mapping between default destination layer 2 ID for unicast initial unicast signaling and PC5QoS parameters; mapping between destination layer 2 ID and PC5QoS parameters for multicast; or a mapping between the destination layer 2 ID for the broadcast and the PC5QoS parameters.

Example 34 includes the apparatus of example 32 or 33, wherein the PC5QoS parameter in the first map is common to all destination layer 2 IDs in the first map if the all destination layer 2 IDs are indicated by a common character.

Example 35 includes the apparatus of example 32, wherein the second mapping between V2X service types and PC5QoS parameters comprises: mapping between V2X service types for unicast and PC5QoS parameters; mapping between V2X service type and PC5QoS parameters for multicast; or mapping between V2X service types for broadcast and PC5QoS parameters.

Example 36 includes the apparatus of example 32 or 35, wherein the PC5QoS parameters in the second map are common to all V2X service types if all V2X service types in the second map are indicated by a common character.

Example 37 includes the apparatus of any one of examples 32 to 36, wherein the interface circuitry is to: transmitting the V2X policy/parameter information to the AN via AN access and mobility management function (AMF) of the 5 GC.

Example 38 includes the apparatus of any one of examples 32 to 37, wherein the processor circuit is to: generating the V2X policy/parameter information in response to receiving a UE policy provisioning request for V2X policy/parameter information from the UE.

Example 39 includes the apparatus of any one of examples 32 to 37, wherein the processor circuit is to: generating the V2X policy/parameter information in response to a network triggered update to V2X policy/parameter information.

Example 40 includes the apparatus of any one of examples 32 to 39, wherein the AN comprises a next generation nodeb (gnb).

Example 41 includes a method performed by a User Equipment (UE), the method comprising: receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters; determining PC5QoS parameters for the UE based on the mapping and a V2X service type of the UE; and performing V2X communication based on the PC5QoS parameters for the UE.

Example 42 includes the method of example 41, wherein the mapping between the V2X service type and the PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 43 includes the method of example 41 or 42, wherein the V2X service type of the UE is indicated by a Provider Service Identifier (PSID) or an Intelligent Transmission System (ITS) application identifier (ITS-AID).

Example 44 includes the method of any one of examples 41 to 43, wherein the PC5QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 45 includes the method of example 44, wherein the PC5QoS parameters for the UE further include: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 46 includes the method of any one of examples 41 to 45, further comprising: generating a UE policy provisioning request for the V2X policy/parameter information; and transmitting the UE policy provisioning request to the 5GC, and wherein the message is transmitted from the 5GC in response to the UE policy provisioning request.

Example 47 includes the method of any one of examples 41 to 45, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 48 includes the method of any one of examples 41 to 47, wherein the message is received from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 49 includes a method for AN Access Node (AN), the method comprising: receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters; determining a PC5QoS parameter for a User Equipment (UE) based on the mapping; and scheduling PC5 radio resources for V2X communications for the UE based on the PC5QoS parameters for the UE.

Example 50 includes the method of example 49, wherein the mapping between the V2X service type and the PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 51 includes the method of examples 49 or 50, wherein the PC5QoS parameters in the map are common to all V2X service types in the map if all V2X service types in the map are indicated by a common character.

Example 52 includes the method of any one of examples 49 to 51, wherein the PC5QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 53 includes the method of example 52, wherein the PC5QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 54 includes the method of any one of examples 49 to 53, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request for the V2X policy/parameter information from the UE.

Example 55 includes the method of any one of examples 49 to 53, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 56 includes the method of any one of examples 49 to 55, wherein the message is received from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 57 includes the method of any one of examples 49-56, wherein the AN includes a next generation nodeb (gnb).

Example 58 includes a method for AN Access Node (AN), the method comprising: receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between a destination layer 2 ID and sidelink quality of service (QoS) parameters; determining a sidelink QoS parameter for a User Equipment (UE) based on the mapping; and scheduling sidelink radio resources for V2X communication for the UE based on the sidelink QoS parameter for the UE.

Example 59 includes the method of example 58, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameter comprises: mapping between default destination layer 2 ID for unicast initial unicast signaling and sidelink QoS parameters; mapping between destination layer 2 ID and sidelink QoS parameters for multicast; or a mapping between the destination layer 2 ID for the broadcast and the sidelink QoS parameters.

Example 60 includes the method of example 58 or 59, wherein the sidelink QoS parameter in the map is common to all destination layer 2 IDs in the map if the all destination layer 2 IDs in the map are indicated by a common character.

Example 61 includes the method of any one of examples 58 to 60, wherein the sidelink QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 62 includes the method of example 61, wherein the sidelink QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 63 includes the method of any one of examples 58 to 62, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request for the V2X policy/parameter information from the UE.

Example 64 includes the method of any one of examples 58 to 62, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 65 includes the method of any one of examples 58 to 64, wherein the message is received from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 66 includes the method of any one of examples 58 to 65, wherein the AN comprises a next generation nodeb (gnb).

Example 67 includes a method of a 5G core network (5GC) for a fifth generation (5G) system (5GS), the method comprising: generating vehicle-to-anything (V2X) policy/parameter information, wherein the V2X policy/parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters; and causing transmission of the V2X policy/parameter information to a User Equipment (UE) for V2X communication of the UE.

Example 68 includes the method of example 67, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 69 includes the method of example 67 or 68, wherein the V2X policy/parameter information is sent to the UE via an access and mobility management function (AMF) of the 5 GC.

Example 70 includes the method of any one of examples 67 to 69, wherein the V2X policy/parameter information is generated in response to receiving a UE policy provisioning request for V2X policy/parameter information from the UE.

Example 71 includes the method of any one of examples 67 to 69, wherein the V2X policy/parameter information is generated in response to a network-triggered update to V2X policy/parameter information.

Example 72 includes a method of a 5G core network (5GC) for a fifth generation (5G) system (5GS), the method comprising: generating vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information includes a first mapping between destination layer 2 IDs and PC5 quality of service (QoS) parameters or a second mapping between V2X service types and PC5QoS parameters; and causing transmission of the V2X policy/parameter information to AN Access Node (AN) to schedule PC5 radio resources for V2X communications of a User Equipment (UE).

Example 73 includes the method of example 72, wherein the first mapping between the destination layer 2 ID and the PC5QoS parameter comprises: mapping between default destination layer 2 ID for unicast initial unicast signaling and PC5QoS parameters; mapping between destination layer 2 ID and PC5QoS parameters for multicast; or a mapping between the destination layer 2 ID for the broadcast and the PC5QoS parameters.

Example 74 includes the method of example 72 or 73, wherein the PC5QoS parameter in the first map is common to all destination layer 2 IDs in the first map if all destination layer 2 IDs in the first map are indicated by a common character.

Example 75 includes the method of example 72, wherein the second mapping between V2X service types and PC5QoS parameters comprises: mapping between V2X service types for unicast and PC5QoS parameters; mapping between V2X service type and PC5QoS parameters for multicast; or mapping between V2X service types for broadcast and PC5QoS parameters.

Example 76 includes the method of example 72 or 75, wherein the PC5QoS parameters in the second map are common to all V2X service types if all V2X service types in the second map are indicated by a common character.

Example 77 includes the method of any one of examples 72 to 76, wherein the V2X policy/parameter information is sent to the AN via AN access and mobility management function (AMF) of the 5 GC.

Example 78 includes the method of any one of examples 72 to 77, wherein the V2X policy/parameter information is generated in response to receiving a UE policy provisioning request for V2X policy/parameter information from the UE.

Example 79 includes the method of any of examples 72 to 77, wherein the V2X policy/parameter information is generated in response to a network-triggered update to V2X policy/parameter information.

Example 80 includes the method of any one of examples 72 to 79, wherein the AN comprises a next generation nodeb (gnb).

Example 81 includes an apparatus for a User Equipment (UE), the apparatus comprising: a component for receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters; means for determining PC5QoS parameters for the UE based on the mapping and a V2X service type of the UE; and means for performing V2X communications based on the PC5QoS parameters for the UE.

Example 82 includes the apparatus of example 81, wherein the mapping between the V2X service type and the PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 83 includes the apparatus of examples 81 or 82, wherein the V2X service type of the UE is indicated by a Provider Service Identifier (PSID) or an Intelligent Transmission System (ITS) application identifier (ITS-AID).

Example 84 includes the apparatus of any one of examples 81 to 83, wherein the PC5QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 85 includes the apparatus of example 84, wherein the PC5QoS parameters for the UE further include: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 86 includes the apparatus of any one of examples 81 to 85, further comprising: a component for generating and sending a UE policy provisioning request for the V2X policy/parameter information to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy provisioning request.

Example 87 includes the apparatus of any one of examples 81 to 85, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 88 includes the apparatus of any one of examples 81 to 87, wherein the message is received from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 89 includes AN apparatus for AN Access Node (AN), the apparatus comprising: a component for receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters; means for determining PC5QoS parameters for a User Equipment (UE) based on the mapping; and means for scheduling PC5 radio resources for V2X communications for the UE based on the PC5QoS parameters for the UE.

Example 90 includes the apparatus of example 89, wherein the mapping between the V2X service type and the PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 91 includes the apparatus of examples 89 or 90, wherein the PC5QoS parameters in the map are common to all V2X service types in the map if all V2X service types in the map are indicated by a common character.

Example 92 includes the apparatus of any one of examples 89 to 91, wherein the PC5QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 93 includes the apparatus of example 92, wherein the PC5QoS parameters for the UE further include: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 94 includes the apparatus of any one of examples 89 to 93, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request for the V2X policy/parameter information from the UE.

Example 95 includes the apparatus of any one of examples 89 to 93, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 96 includes the apparatus of any one of examples 89 to 95, wherein the message is received from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 97 includes the apparatus of any one of examples 89 to 96, wherein the AN comprises a next generation nodeb (gnb).

Example 98 includes AN apparatus for AN Access Node (AN), the apparatus comprising: a component for receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between a destination layer 2 ID and sidelink quality of service (QoS) parameters; means for determining a sidelink QoS parameter for a User Equipment (UE) based on the mapping; and means for scheduling sidelink radio resources for V2X communication for the UE based on the sidelink QoS parameter for the UE.

Example 99 includes the apparatus of example 98, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameter comprises: mapping between default destination layer 2 ID for unicast initial unicast signaling and sidelink QoS parameters; mapping between destination layer 2 ID and sidelink QoS parameters for multicast; or a mapping between the destination layer 2 ID for the broadcast and the sidelink QoS parameters.

Example 100 includes the apparatus of example 98 or 99, wherein the sidelink QoS parameter in the map is common to all destination layer 2 IDs in the map if the all destination layer 2 IDs are indicated by a common character.

Example 101 includes the apparatus of any one of examples 98 to 100, wherein the sidelink QoS parameters for the UE include a PC 55G QoS identifier (PQI).

Example 102 includes the apparatus of example 101, wherein the sidelink QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

Example 103 includes the apparatus of any one of examples 98 to 102, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request for the V2X policy/parameter information from the UE.

Example 104 includes the apparatus of any one of examples 98 to 102, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

Example 105 includes the apparatus of any one of examples 98 to 104, wherein the message is received from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Example 106 includes the apparatus of any one of examples 98 to 105, wherein the AN comprises a next generation nodeb (gnb).

Example 107 includes an apparatus of a 5G core network (5GC) for a fifth generation (5G) system (5GS), the apparatus comprising: a component for generating vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters; and means for causing V2X policy/parameter information to be sent to a User Equipment (UE) for V2X communication of the UE.

Example 108 includes the apparatus of example 107, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

Example 109 includes the apparatus of example 107 or 108, wherein the V2X policy/parameter information is sent to the UE via an access and mobility management function (AMF) of the 5 GC.

Example 110 includes the apparatus of any one of examples 107 to 109, wherein the V2X policy/parameter information is generated in response to receiving a UE policy provisioning request for V2X policy/parameter information from the UE.

Example 111 includes the apparatus of any one of examples 107 to 109, wherein the V2X policy/parameter information is generated in response to a network-triggered update to V2X policy/parameter information.

Example 112 includes an apparatus of a 5G core network (5GC) for a fifth generation (5G) system (5GS), the apparatus comprising: a component for generating vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information includes a first mapping between destination layer 2 IDs and PC5 quality of service (QoS) parameters or a second mapping between V2X service types and PC5QoS parameters; and means for causing V2X policy/parameter information to be transmitted to AN Access Node (AN) for scheduling PC5 radio resources for V2X communications of a User Equipment (UE).

Example 113 includes the apparatus of example 112, wherein the first mapping between the destination layer 2 ID and the PC5QoS parameter comprises: mapping between default destination layer 2 ID for unicast initial unicast signaling and PC5QoS parameters; mapping between destination layer 2 ID and PC5QoS parameters for multicast; or a mapping between the destination layer 2 ID for the broadcast and the PC5QoS parameters.

Example 114 includes the apparatus of example 112 or 113, wherein the PC5QoS parameter in the first map is common to all destination layer 2 IDs in the first map if all destination layer 2 IDs in the first map are indicated by a common character.

Example 115 includes the apparatus of example 112, wherein the second mapping between V2X service types and PC5QoS parameters comprises: mapping between V2X service types for unicast and PC5QoS parameters; mapping between V2X service type and PC5QoS parameters for multicast; or mapping between V2X service types for broadcast and PC5QoS parameters.

Example 116 includes the apparatus of example 112 or 115, wherein the PC5QoS parameters in the second map are common to all V2X service types if all V2X service types in the second map are indicated by a common character.

Example 117 includes the apparatus of any one of examples 112 to 116, wherein the V2X policy/parameter information is sent to the AN via AN access and mobility management function (AMF) of the 5 GC.

Example 118 includes the apparatus of any one of examples 112 to 117, wherein the V2X policy/parameter information is generated in response to receiving a UE policy provisioning request for V2X policy/parameter information from the UE.

Example 119 includes the apparatus of any one of examples 112 to 117, wherein the V2X policy/parameter information is generated in response to a network-triggered update to V2X policy/parameter information.

Example 120 includes the apparatus of any one of examples 112 to 119, wherein the AN comprises a next generation nodeb (gnb).

Example 121 includes one or more computer-readable media having instructions stored thereon, which when executed by a processor circuit, cause the processor circuit to perform the method of any of examples 41 to 48.

Example 122 includes one or more computer-readable media having instructions stored thereon, which when executed by a processor circuit, cause the processor circuit to perform the method of any of examples 49-66.

Example 123 includes one or more computer-readable media having instructions stored thereon, which when executed by a processor circuit, cause the processor circuit to perform the method of any of examples 67 to 80.

Example 124 includes a User Equipment (UE) as described and illustrated in the specification.

Example 125 includes AN Access Node (AN) as described and illustrated in the specification.

Example 126 includes a Policy Control Function (PCF) as described and illustrated in the specification.

Example 127 includes a method performed at a User Equipment (UE) as described and illustrated in the specification.

Example 128 includes a method performed at AN Access Node (AN) as described and illustrated in the specification.

Example 129 includes a method performed at a Policy Control Function (PCF) as described and illustrated in the specification.

Although certain embodiments have been illustrated and described herein for purposes of description, various alternative and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments described herein be limited only by the claims and the equivalents thereof.

Claims (25)

1. An apparatus for a User Equipment (UE), the apparatus comprising:

a Radio Frequency (RF) interface; and

a processor circuit coupled with the RF interface,

wherein the RF interface is to:

receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters, and

wherein the processor circuit is to:

determining PC5QoS parameters for the UE based on the mapping and a V2X service type of the UE; and

performing V2X communications based on the PC5QoS parameters for the UE.

2. The apparatus of claim 1, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

3. The apparatus of claim 1, wherein the V2X service type of the UE is indicated by a Provider Service Identifier (PSID) or an Intelligent Transmission System (ITS) application identifier (ITS-AID).

4. The apparatus of any of claims 1-3, wherein the PC5QoS parameters for the UE comprise a PC 55G QoS identifier (PQI).

5. The apparatus of claim 4, wherein the PC5QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBRQoS flows.

6. The apparatus of claim 1, wherein the processor circuit is to: generating a UE policy provisioning request for the V2X policy/parameter information and causing the UE policy provisioning request to be sent to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy provisioning request.

7. The apparatus of claim 1, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

8. The apparatus of claim 1, wherein the RF interface is to receive the message from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

9. AN apparatus for AN Access Node (AN), the apparatus comprising:

a Radio Frequency (RF) interface; and

a processor circuit coupled with the RF interface,

wherein the RF interface is to:

receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between V2X service types and PC5 quality of service (QoS) parameters, and

wherein the processor circuit is to:

determining a PC5QoS parameter for a User Equipment (UE) based on the mapping; and

scheduling PC5 radio resources for V2X communications for the UE based on the PC5QoS parameters for the UE.

10. The apparatus of claim 9, wherein the mapping between the V2X service type and PC5QoS parameters is differentiated for unicast, multicast, and broadcast.

11. The apparatus of claim 9, wherein the PC5QoS parameters in the map are common to all V2X service types in the map if all V2X service types in the map are indicated by a common character.

12. The apparatus of claim 9, wherein the PC5QoS parameters for the UE comprise a PC 55G QoS identifier (PQI).

13. The apparatus of claim 12, wherein the PC5QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

14. The apparatus of claim 9, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request from the UE for the V2X policy/parameter information.

15. The apparatus of claim 9, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

16. The apparatus of claim 9, wherein the RF interface is to receive the message from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

17. The apparatus of any of claims 9-16, wherein the AN comprises a next generation nodeb (gnb).

18. AN apparatus for AN Access Node (AN), the apparatus comprising:

a Radio Frequency (RF) interface; and

a processor circuit coupled with the RF interface,

wherein the RF interface is to:

receiving a message from a 5G core network (5GC) of a fifth generation (5G) system (5GS), the message comprising vehicle-to-everything (V2X) policy/parameter information, wherein the V2X policy/parameter information comprises a mapping between a destination layer 2 ID and sidelink quality of service (QoS) parameters, and

wherein the processor circuit is to:

determining a sidelink QoS parameter for a User Equipment (UE) based on the mapping; and

scheduling sidelink radio resources for V2X communication for the UE based on the sidelink QoS parameter for the UE.

19. The apparatus of claim 18, wherein the mapping between destination layer 2 ID and sidelink QoS parameters comprises:

mapping between default destination layer 2 ID for unicast, initial unicast signaling and sidelink QoS parameters;

mapping between destination layer 2 ID and sidelink QoS parameters for multicast; or

Mapping between destination layer 2 ID and sidelink QoS parameters for broadcast.

20. The apparatus of claim 18, wherein a side link QoS parameter in the map is common to all destination layer 2 IDs in the map if the all destination layer 2 IDs in the map are indicated by a common character.

21. The apparatus of claim 18, wherein the sidelink QoS parameters for the UE comprise a PC 55 GQoS identifier (PQI).

22. The apparatus of claim 21, wherein the sidelink QoS parameters for the UE further comprise: a guaranteed stream bit rate (GFBR) and a maximum stream bit rate (MFBR) for a Guaranteed Bit Rate (GBR) QoS stream; and GFBR and MFBR for delaying critical GBR QoS flows.

23. The apparatus of claim 18, wherein the message is sent from the 5GC in response to the 5GC receiving a UE policy provisioning request from the UE for the V2X policy/parameter information.

24. The apparatus of claim 18, wherein the message is sent from the 5GC in response to a network-triggered update of the V2X policy/parameter information.

25. The apparatus of any one of claims 18 to 24, wherein the RF interface is to receive the message from a Policy Control Function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5 GC.

Images