Device and method for PC5 QoS authorization for V2X services

Abstract

The present disclosure provides an apparatus and method for PC5 QoS authorization for V2X services. One aspect of the present disclosure provides an apparatus for a UE. The apparatus includes a radio frequency (RF) interface and a processor circuit coupled to the RF interface. The RF interface is configured to receive 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 types and PC5 quality of service (QoS) parameters. The processor circuit is configured to: determine PC5 QoS parameters for the UE based on the mapping and the V2X service type of the UE; and perform V2X communication based on the PC5 QoS parameters for the UE. Other embodiments may also be disclosed and claimed.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Provisional Application No. 62 / 821,948, filed Mar. 21, 2019, the entire content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] Embodiments of the present disclosure generally relate to the field of wireless communication, and more particularly, to apparatuses and methods for PC5 Quality of Service (QoS) authorization for vehicle-to-everything (V2X) services to a user equipment (UE) and a radio access network (RAN). BACKGROUND ART

[0004] With the development of wireless communication, V2X services can be implemented through various types of V2X applications, such as vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), etc. V2X communication can be used to support V2X services using the Uu reference point and / or the PC5 reference point. Appropriate QoS parameters are necessary for implementing V2X communication. SUMMARY OF THE INVENTION

[0005] One aspect of the present disclosure provides an apparatus for a UE, the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 Quality of Service (QoS) parameters, and wherein the processor circuit is configured to: determine PC5 QoS parameters for the UE based on the mapping and the V2X service type of the UE; and perform V2X communication based on the PC5 QoS parameters for the UE.

[0006] One 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 to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 Quality of Service (QoS) parameters, and wherein the processor circuit is configured to: determine PC5 QoS parameters for a user equipment (UE) based on the mapping; and schedule PC5 radio resources for V2X communication of the UE based on the PC5 QoS parameters for the UE.

[0007] One 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 to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between a destination layer 2 ID and a sidelink quality of service (QoS) parameter, and wherein the processor circuit is configured to: determine a sidelink QoS parameter for a user equipment (UE) based on the mapping; and schedule sidelink radio resources for V2X communication of the UE based on the sidelink QoS parameter for the UE. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the drawings, embodiments of the present disclosure will be illustrated by way of example and not limitation, where like reference numerals refer to like elements.

[0009] Figure 1 An example architecture of a system according to some embodiments of the present disclosure is shown.

[0010] Figure 2 An example architecture of a system including a first core network (CN) according to some embodiments of the present disclosure is shown.

[0011] Figure 3 An example architecture of a system including a second CN according to some embodiments of the present disclosure is shown.

[0012] Figure 4 A process diagram for configuring PC5 QoS authorization information for V2X services for a UE and a RAN according to some embodiments of the present disclosure is shown.

[0013] Figure 5 A flowchart of a method for configuring PC5 QoS authorization information for V2X services for a UE from the perspective of the UE according to some embodiments of the present disclosure is shown.

[0014] Figure 6 A flowchart of a method for configuring PC5 QoS authorization information for V2X services for a RAN from the perspective of the RAN according to some embodiments of the present disclosure is shown.

[0015] Figure 7 A flowchart of a method for configuring PC5 QoS authorization information for V2X services for a RAN from the perspective of the RAN according to some embodiments of the present disclosure is shown.

[0016] Figure 8A flowchart of a method for configuring PC5 QoS authorization information for a UE for V2X services from the perspective of a second CN according to some embodiments of the present disclosure is shown.

[0017] Figure 9 A flowchart of a method for configuring PC5 QoS authorization information for a RAN for V2X services from the perspective of a second CN according to some embodiments of the present disclosure is shown.

[0018] Figure 10 An example component of a device according to some embodiments of the present disclosure is shown.

[0019] Figure 11 An example interface of a baseband circuit according to some embodiments of the present disclosure is shown.

[0020] Figure 12 A block diagram showing components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methods discussed herein according to some example embodiments is shown. Detailed Description

[0021] 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 present disclosure to others skilled in the art. However, it will be readily apparent to those skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth to provide a thorough understanding of the illustrative embodiments. However, it will be readily apparent to those skilled in the art that alternative embodiments can be practiced without these specific details. In other instances, well-known features are omitted or simplified to avoid obscuring the illustrative embodiments.

[0022] Furthermore, various operations will be described as multiple discrete operations in the manner most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must be order-dependent. In particular, these operations need not be performed in the order presented.

[0023] The phrases "in an embodiment", "in one embodiment", and "in some embodiments" are reused herein. This phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. Unless the context dictates otherwise, the terms "comprising", "having", and "including" are synonyms. The phrases "A or B" and "A / B" mean "(A), (B), or (A and B)".

[0024] For V2X communication, there are two operation modes, namely V2X communication via the PC5 reference point and V2X communication via the Uu reference point. A UE can independently use these two operation modes for transmission and reception.

[0025] Long-Term Evolution (LTE) and / or New Radio (NR) support Vehicle-to-Everything (V2X) communication via the 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 communication via the Uu reference point. This disclosure is mainly described for V2X communication via the PC5 reference point. In particular, solutions for configuring PC5 QoS authorization information for V2X services to the UE and the RAN will be described in detail in this disclosure. However, embodiments of this disclosure are applicable to V2X communication via the Uu reference point and are not limited in this regard.

[0026] Figure 1 An example architecture of a system 100 in accordance with some embodiments of the present disclosure is shown. 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 regard, 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.).

[0027] As Figure 1As shown, system 100 may include UEs 101a and 101b (collectively referred to as “(one or more) UEs 101”). As used herein, the term “user equipment” or “UE” may refer to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term “user equipment” or “UE” may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio device, reconfigurable radio device, reconfigurable mobile device, etc. Additionally, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communication interface. In this example, UE 101 is shown as a smart phone (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 consumer electronic devices, cellular phones, smart phones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI) systems, in-vehicle entertainment (ICE) devices, instrument clusters (ICs), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashboard mobile devices (DMEs), mobile data terminals (MDTs), electronic engine management systems (EEMSs), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMSs), networked or “smart” devices, machine type communication (MTC) devices, machine-to-machine (M2M), Internet of Things (IoT) devices, and / or the like.

[0028] In some embodiments, any of 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. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a PLMN, proximity-based service (ProSe), or device-to-device (D2D) communication, a sensor network, or an IoT network. The data exchange of M2M or MTC may be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) having short-term connections. The IoT UE may execute background applications (e.g., maintaining active messages, status updates, etc.) to facilitate the connection to the IoT network.

[0029] The UE 101 may be configured to connect (e.g., communicatively couple) to an AN or RAN 110. In an embodiment, the RAN 110 may be a Next Generation (NG) RAN or 5G RAN, an evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), or a legacy RAN such as UTRAN (UMTS Terrestrial Radio Access Network) or GERAN (GSM (Global System for Mobile Communications or Groupe Spécial Mobile) EDGE (GSM Evolution) Radio Access Network). As used herein, terms such as “NG RAN” may refer to the RAN 110 operating in an NR or 5G system 100, and terms such as “E-UTRAN” may refer to the RAN 110 operating in an LTE or 4G system 100. The UE 101 utilizes connections (or channels) 103 and 104 respectively, each connection including a physical communication interface or layer (discussed further below). As used herein, the term “channel” may refer to any tangible or intangible transmission medium for carrying data or a data stream. The term “channel” may be synonymous with 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 terms representing a path or medium through which data is carried. Additionally, the term “link” may refer to a connection between two devices for the purpose of sending and receiving information via a Radio Access Technology (RAT).

[0030] In this example, the connections 103 and 104 are shown as air interfaces to enable communicative coupling and may be consistent with a cellular communication protocol such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Push-to-Talk over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, Fifth Generation (5G) protocol, New Radio (NR) protocol, and / or any other communication protocol discussed herein. In an embodiment, the UE 101 may directly exchange communication data 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 (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0031] UE 101b is shown as being configured to access an access point (AP) 106 (also referred to as "WLAN node 106", "WLAN 106", "WLAN terminal 106", or "WT106", etc.) via connection 107. Connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 106 will include a Wi-Fi router. In this example, AP 106 is shown as being connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE 101b, RAN 110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operations and / or WLAN LTE / WLAN radio-level integration with IPsec tunneling (LWIP) operations. LWA operations may involve a UE 101b in RRC_CONNECTED being configured by a RAN node 111 to utilize radio resources of LTE and WLAN. LWIP operations may involve UE 101b 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 connection 107. The IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0032] RAN 110 may include one or more AN nodes or RAN nodes 111a and 111b (collectively referred to as "(one or more) RAN nodes 111") enabling connections 103 and 104. As used herein, terms such as "access node", "access point", etc. 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 (BS), next-generation node B (gNB), RAN nodes, evolved NodeB (eNB), NodeB, roadside unit (RSU), transmission and reception point (TRxP or TRP), etc., and may include a terrestrial station (e.g., a terrestrial access point) or a satellite station providing coverage within a geographical area (e.g., a cell). As used herein, terms such as "NG RAN node", etc. may refer to a RAN node 111 (e.g., gNB) operating in an NR or 5G system 100, and terms such as "E-UTRAN node", etc. may refer to a RAN node 111 (e.g., eNB) operating in an LTE or 4G system 100. According to various embodiments, RAN node 111 may be implemented as one or more dedicated physical devices such as macrocell base stations and / or low-power (LP) base stations such as femtocells, picocells, or other similar cells that provide a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell.

[0033] 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 (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN function splitting, such as: PDCP splitting, where the RRC and PDCP layers are operated by the CRAN / vBBUP, and other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC / PHY splitting, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes 111; or "lower PHY" splitting, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP, and the lower part of the PHY layer is operated by individual RAN nodes 111. This virtualization framework allows the processor cores of the RAN node 111 to be freed up to execute other virtualized applications. In some implementations, the individual RAN nodes 111 may represent individual gNB-DUs connected to the gNB-CU via individual F1 interfaces ( Figure 1 not shown). In these implementations, the gNB-DU may include one or more remote radio heads or radio front-end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in the RAN 110 or by a pool of servers in a manner similar to the CRAN / vBBUP. Additionally or alternatively, one or more RAN nodes 111 may be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol termination to the UE 101 and is connected to the 5GC via the NG interface (e.g., Figure 3 the CN 320) (discussed below).

[0034] In a V2X scenario, one or more RAN nodes 111 can be or act as an RSU. The term "roadside unit" or "RSU" can refer to any transportation infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable RAN node or a fixed (or relatively stationary) UE, where the RSU implemented in or by the UE can be referred to as a "UE type RSU", the RSU implemented in or by the eNB can be referred to as an "eNB type RSU", the RSU implemented in or by the gNB can be referred to as a "gNB type RSU", etc. In one example, the RSU is a computing device coupled to a radio frequency circuit located at the roadside, which provides connectivity support for passing vehicle UEs 101 (vUE 101). The RSU can also include an internal data storage circuit for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can operate on the 5.9 GHz direct short-range communication (DSRC) band to provide very low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can operate on the cellular V2X band to provide the above low-latency communication and other cellular communication services. Additionally or alternatively, the RSU can operate as a WiFi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. The (one or more) computing devices and some or all of the radio frequency circuits of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller to provide a wired (e.g., Ethernet) connection to a traffic signal controller and / or a backhaul network.

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

[0036] In an embodiment, the UE 101 can be configured to communicate with each other or with any RAN node 111 according to various communication technologies, using orthogonal frequency division multiplexing (OFDM) communication signals over a multi-carrier communication channel, various communication technologies such as but not limited to orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiment is not limited in this regard. The OFDM signal can include a plurality of orthogonal subcarriers.

[0037] In some embodiments, a downlink resource grid can be used for downlink transmissions from any RAN node 111 to the UE 101, and uplink transmissions can use similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resource in the downlink for each time slot. This time-frequency plane representation is a common practice in OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this can represent the smallest amount of resource that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

[0038] According to various embodiments, the UE 101 and the RAN node 111 transmit (e.g., send 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 can include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum can include the 5 GHz band.

[0039] To operate in the unlicensed spectrum, the UE 101 and the RAN node 111 can use licensed-assisted access (LAA), enhanced LAA (eLAA), and / or further enhanced LAA (feLAA) mechanisms to operate. In these implementations, the UE 101 and the RAN node 111 can 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 before transmitting in the unlicensed spectrum. The medium / carrier sensing operations can be performed according to the listen-before-talk (LBT) protocol.

[0040] LBT is a mechanism in which devices (e.g., UE 101, RAN nodes 111, 112, etc.) sense the medium (e.g., channel or carrier frequency) and transmit when the medium is sensed to be idle (or when a specific channel in the medium is sensed to be unoccupied). The medium sensing operation may include a Clear Channel Assessment (CCA) that determines whether there are other signals on the channel using at least Energy Detection (ED) to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with incumbent systems in the unlicensed spectrum and with other LAA networks. ED may include sensing radio frequency (RF) energy on the intended transmission band for a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0041] Typically, incumbent systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). Here, when a WLAN node (e.g., a mobile station (MS) such as UE 101, AP 106) intends to transmit, the WLAN node may first perform a CCA before transmission. Additionally, a backoff mechanism is used to avoid collisions in the case where more than one WLAN node senses the channel as idle and transmits simultaneously. The backoff mechanism may be a counter randomly drawn within a contention window size (CWS) that increases exponentially in the event of a collision and is reset to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA of WLAN. In some implementations, the LBT process for DL or UL transmission bursts respectively including PDSCH or PUSCH transmissions may have an LAA contention window of variable length between X and Y Extended CCA (ECCA) slots, where X and Y are the minimum and maximum values of the CWS for LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μs); however, the size of the CWS and the Maximum Channel Occupancy Time (MCOT) (e.g., transmission burst) may be based on government regulatory requirements.

[0042] The LAA mechanism is based on the carrier aggregation (CA) technology of the Long Term Evolution - Advanced (LTE - Advanced) system. In CA, each aggregated carrier is called a component carrier (CC). A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated. Thus, the maximum aggregated bandwidth is 100 MHz. In a Frequency Division Duplexing (FDD) system, the number of aggregated carriers can 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, an individual CC can have a different bandwidth from other CCs. In a Time Division Duplexing (TDD) system, for DL and UL, the number of CCs and the bandwidth of each CC are usually the same.

[0043] CA also includes separate serving cells to provide separate CCs. The coverage of the serving cells may be different. For example, CCs on different frequency bands will experience different path losses. The primary serving cell or primary cell (PCell) can provide the primary CC (PCC) for both UL and DL, and can handle radio resource control (RRC) and non - access stratum (NAS) related activities. Other serving cells are called secondary cells (SCells), and each SCell can provide a separate secondary CC (SCC) for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require the UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all SCells can operate in the unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE can receive UL grants on the configured LAA SCells, and the UL grants indicate the starting positions of different Physical Uplink Shared Channels (PUSCH) within the same sub - frame.

[0044] The Physical Downlink Shared Channel (PDSCH) can carry user data and higher - layer signaling to the UE 101. The Physical Downlink Control Channel (PDCCH) can carry information such as the transmission format and resource allocation related to the PDSCH channel. It can also notify the UE 101 of the transmission format, resource allocation, and Hybrid Automatic Repeat Request (H - ARQ) information related to the uplink shared channel. Generally, downlink scheduling (allocating control and shared channel resource blocks to the UE 101b within the cell) can be performed at any RAN node 111 based on the channel quality information fed back from any UE 101. The downlink resource allocation information can be sent on the PDCCH for each UE 101 (e.g., allocated to).

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

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

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

[0048] In an embodiment where system 100 is a 5G or NR system, interface 112 can be an Xn interface 112. The Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gNBs, etc.) connected to 5GC 120, between a RAN node 111 (e.g., gNB) connected to 5GC 120 and an eNB, and / or between two eNBs connected to 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 unguaranteed transfer of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C can provide: management and error handling functions; functions for managing the Xn-C interface; mobility support for UEs 101 in the connected mode (e.g., CM-CONNECTED), including functions for managing UE mobility in the connected mode between one or more RAN nodes 111. Mobility support can include context transfer from an old (source) serving RAN node 111 to a new (target) serving RAN node 111; and control of the user plane tunnel between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of the Xn-U can include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer on top of the (one or more) UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack can include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP can be located on top of the IP layer and can provide guaranteed transfer of application layer messages. In the transport IP layer, point-to-point transmission is used to transfer signaling PDUs. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack can be the same as or similar to the (one or more) user plane and / or control plane protocol stacks shown and described herein.

[0049] RAN 110 is shown communicatively coupled to a core network - in this embodiment, to core network (CN) 120. CN 120 may include a plurality of network elements 122, which are configured to provide various data and telecommunications services to customers / subscribers (e.g., the user of UE 101) connected to CN 120 via RAN 110. The term "network element" may describe a physical or virtualized device for providing wired or wireless communication network services. The term "network element" may be considered synonymous with and / or referred to as: networked computers, network hardware, network devices, routers, switches, hubs, bridges, radio network controllers, radio access network devices, gateways, servers, virtualized network functions (VNFs), network function virtualization infrastructure (NFVI), and / or the like. The components of CN 120 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 (described in further detail below) via executable instructions stored in one or more computer-readable storage media. The logical instantiation of CN 120 may be referred to as a network slice, and the logical instantiation of a portion of CN 120 may be referred to as a network sub-slice. The NFV architecture and infrastructure may be used to virtualize one or more network functions, or perform them from 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.

[0050] Generally, application server 130 may be an element that provides an application that uses IP bearer resources in conjunction with a core network (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.). Application server 130 may also be configured to support one or more communication services (e.g., Internet protocol voice (VoIP) sessions, PTT sessions, group communication sessions, social network services, etc.) for UE 101 via EPC 120.

[0051] In an embodiment, CN 120 may be a 5GC (referred to as "5GC 120", etc.), and RAN 110 may be connected to CN 120 via NG interface 113. In an embodiment, NG interface 113 may be divided into two parts: the NG user plane (NG-U) interface 114, which carries traffic data between RAN node 111 and the user plane function (UPF); and the S1 control plane (NG-C) interface 115, which is a signaling interface between RAN node 111 and the AMF. Regarding Figure 3More specifically, CN 120 is an embodiment of 5GC 120 will be discussed.

[0052] In an embodiment, CN 120 can be a 5G CN (referred to as "5GC 120", etc.), while in other embodiments, CN 120 can be an evolved packet core (EPC). In the case where CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 can be connected to CN 120 via the S1 interface 113. In an embodiment, the S1 interface 13 can be divided into two parts: the S1 user plane (S1-U) interface 114, which carries traffic data between the RAN node 111 and the serving gateway (S-GW); and the S1-mobility management entity (MME) interface 115, which is a signaling interface between the RAN node 111 and the MME.

[0053] Figure 2 An example architecture of a system 200 including a first CN 220 according to some embodiments of the present disclosure is shown.

[0054] In one embodiment, the system 200 can implement the LTE standard, where CN 220 is the EPC 220 corresponding to Figure 1 CN 120. Additionally, UE 201 can be the same as or similar to Figure 1 UE 101, EUTRAN 210 can be the same as or similar to Figure 1 RAN 110, and can include the RAN node 111 discussed previously. CN 220 can include an MME 221, an S-GW 222, 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.

[0055] The MME 221 can functionally resemble the control plane of a traditional SGSN and can implement mobility management (MM) functions to track the current location of the UE 201. The MME 221 can perform various MM procedures to manage the mobility aspects in access, such as gateway selection and tracking area list management. MM (also referred to as "EPS MM" or "EMM" in the E-UTRAN system) can refer to all applicable procedures, methods, data storage, etc. for maintaining knowledge of the current location of the UE 201, providing user identity confidentiality and / or other similar services for the user / subscriber. Each UE 201 and MME 221 can include an MM or EMM sublayer, and when the attachment process is successfully completed, an MM context can be established in the UE 201 and MME 221. The MM context can be a data structure or database object storing MM-related information of the UE 201. The MME 221 can be coupled to the HSS 224 via the S6a reference point, to the SGSN 225 via the S3 reference point, and to the S-GW 222 via the S11 reference point.

[0056] The SGSN 225 can be a node that serves the UE 201 by tracking the location of individual UEs 201 and performing security functions. Additionally, the SGSN 225 can perform: inter-EPC node signaling for mobility between 2G / 3G and E-UTRAN 3GPP access networks; PDN and S-GW selection specified by the MME 221; handling of the UE 201 time zone function specified by the MME 221; and MME selection for handover to the E-UTRAN 3GPP access network. The S3 reference point between the MME 221 and the SGSN 225 can enable the exchange of user and bearer information for 3GPP indirect access network mobility in the idle and / or active states.

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

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

[0059] The P-GW 223 can terminate the SGi interface to the Packet Data Network (PDN) 230. The P-GW 223 can route data packets between the EPC 220 and an external network such as a network including an Application Server 130 (or referred to as Application Function (AF)) via the Internet Protocol (IP) interface 125 (see, for example Figure 1 ). In an embodiment, the P-GW 223 can be communicatively coupled to the Application Server ( Figure 1 ) via the IP communication interface 125 (see, for example Figure 1 the Application Server 130 of Figure 2 or the PDN 230 in

[0060] ). The S5 reference point between the P-GW 223 and the S-GW 222 can provide user plane tunneling and tunnel management between the P-GW 223 and the S-GW 222. Due to UE 201 mobility and if the S-GW 222 needs to connect to a non-collocated P-GW 223 to obtain the required PDN connection, the S5 reference point can also be used for S-GW 222 relocation. The P-GW 223 can also include a node for policy enforcement and charging data collection (e.g., Policy and Charging Enforcement Function (PCEF) (not shown)). Additionally, the SGi reference point between the P-GW 223 and the Packet Data Network (PDN) 230 can be a public, private PDN external to the operator or an intra-operator packet data network, e.g., for providing IMS services. The P-GW 223 can be coupled to the PCRF 226 via the Gx reference point.The Policy and Charging Rules Function (PCRF) 226 is the policy and charging control element of the EPC 220. In a non-roaming scenario, there can be a single PCRF 226 associated with a UE 201 Internet Protocol Connectivity Access Network (IP-CAN) session in the Home Public Land Mobile Network (HPLMN). In a roaming scenario with local traffic breakout, there can be two PCRFs associated with the UE 201 IP-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 can be communicatively coupled to the Application Server 230 via the P-GW 223. The Application Server 230 can signal the PCRF to indicate new service flows and select appropriate Quality of Service (QoS) and charging parameters. The PCRF 226 can 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 starts the QoS and charging as specified by the Application Server 230. The Gx reference point between the PCRF 226 and the P-GW 223 can allow the transfer of (QoS) policy and charging rules from the PCRF 226 to the Policy and Charging Enforcement Function (PCEF) in the P-GW 223. The Rx reference point can reside between the PDN 230 (or “AF 230”) and the PCRF 226.

[0061] Figure 3 An example architecture of a system 300 including a second CN 320 is shown in accordance with some embodiments of the present disclosure.

[0062] The system 300 is shown as including: a UE 301, which can be the same as or similar to the previously discussed UE 101 and UE 201; a (R)AN 310, which can be the same as or similar to the previously discussed RAN 110 and RAN 210 and can include the previously discussed RAN node 111; and a Data Network (DN) 303, which can be, for example, a carrier service, Internet access, or a third-party service; and a 5G Core Network (5GC or CN) 320.

[0063] The 5GC 320 can 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; a Unified Data Management (UDM) 327; an Application Function (AF) 328; a User Plane Function (UPF) 302; and a Network Slice Selection Function (NSSF) 329.

[0064] The UPF 302 can act as an anchor point for mobility within and between RATs, an external PDU session interconnection point to the DN 303, and a branching point for supporting multi-homed PDU sessions. The UPF 302 can also perform packet routing and forwarding, packet inspection, enforce policy rules in the user plane portion, lawful interception of packets (UP set), traffic usage reporting, perform QoS handling in 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 the uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 302 can include an uplink classifier for supporting routing of traffic flows to the data network. The DN 303 can represent various network operator services, Internet access, or third-party services. The DN 303 can include or be similar to the application server 130 discussed previously. The UPF 302 can interact with the SMF 324 via the N4 reference point between the SMF 324 and the UPF 302.

[0065] The AUSF 322 can store authentication data for the UE 301 and handle authentication-related functions. The AUSF 322 can facilitate a common authentication framework for various access types. The AUSF 322 can communicate with the AMF 321 via the N12 reference point between the AMF 321 and the AUSF 322; and can communicate with the UDM 327 via the N13 reference point between the UDM 327 and the AUSF 322. Additionally, the AUSF 322 can expose Nausf service-based interfaces.

[0066] The AMF 321 can be responsible for registration management (e.g., for registering the UE 301, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, as well as access authentication and authorization. The AMF 321 can be the termination point of the N11 reference point between the AMF 321 and the SMF 324. The AMF 321 can provide transmission for session management (SM) messages between the UE 301 and the SMF 324 and act as a transparent proxy for routing SM messages. The AMF 321 can also be between the UE 301 and the SMS function (SMSF) ( Figure 3Provide transmission for Short Message Service (SMS) messages between (not shown). The AMF 321 can act as a Security Anchor Function (SEA), which can include interactions with the AUSF 322 and the UE 301, and receive the intermediate key established as a result of the UE 301 authentication process. In the case of using USIM-based authentication, the AMF 321 can obtain security material from the AUSF 322. The AMF 321 can also include a Security Context Management (SCM) function, which receives the key used by the SEA to derive the access network-specific key. In addition, the AMF 321 can be the termination point of the RAN CP interface, which can include or be the N2 reference point between the (R)AN 311 and the AMF 321; the AMF 321 can be the termination point of the NAS (N1) signaling and perform NAS encryption and integrity protection.

[0067] The AMF 321 can also support NAS signaling with the UE 301 through the N3 Interworking Function (IWF) interface. The N3IWF can be used to provide access to untrusted entities. The N3IWF can be the termination point of the N2 interface between the (R)AN 310 and the AMF 321 for the control plane, and can be the termination point of the N3 reference point between the (R)AN 310 and the UPF 302 for the user plane. In this way, the AMF 321 can process N2 signaling from the SMF 324 and the AMF 321 for PDU sessions and QoS, encapsulate / de-encapsulate packets for IPSec and N3 tunneling, mark N3 user plane packets in the uplink, and perform QoS corresponding to the N3 packet marking, taking into account the QoS requirements associated with such marking received through N2. The N3IWF can also relay uplink and downlink control plane NAS signaling between the UE 301 and the AMF 321 via the N1 reference point between the UE 301 and the AMF 321, and relay uplink and downlink user plane packets between the UE 301 and the UPF 302. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 301. The AMF 321 can expose Namf service-based interfaces and can be the termination point of the N14 reference point between two AMF 321s and the N17 reference point between the AMF 321 and the 5G Equipment Identity Register (5G-EIR) ( Figure 3 not shown).

[0068] UE 301 may need to register with the AMF 321 to receive network services. Registration Management (RM) is used to register or deregister the UE 301 with the network (e.g., the AMF 321) and establish a UE context in the network (e.g., the AMF 321). The UE 301 can operate in an RM registration state or an RM deregistration state. In the RM deregistration state, the UE 301 is not registered with the network, and the UE context in the AMF 321 does not hold the valid location or routing information of the UE 301, so the AMF 321 cannot reach the UE 301. In the RM registration state, the UE 301 is registered with the network, and the UE context in the AMF 321 can hold the valid location or routing information of the UE 301, enabling the UE 301 to be reachable by the AMF 321. In the RM registration state, the UE 301 can perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., notify the network that the UE 301 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

[0069] The AMF 321 can store one or more RM contexts for the UE 301, where each RM context is associated with a specific access to the network. The RM context can be a data structure, a database object, etc., which indicates or stores the registration state and periodic update timer for each access type, etc. The AMF 321 can also store a 5GC MM context, which can be the same as or similar to the previously discussed (E)MM context. In various embodiments, the AMF 321 can store the CE mode B restriction parameters of the UE 301 in the associated MM context or RM context. When needed, the AMF 321 can also derive this value from the UE usage setting parameters already stored in the UE context (and / or MM / RM context).

[0070] Connection Management (CM) can be used to establish and release a signaling connection between the UE 301 and the AMF 321 over the N1 interface. This signaling connection is used to enable NAS signaling exchange between the UE 301 and the CN 120 and includes an AN signaling connection between the UE and the access network (AN) (e.g., an RRC connection or a UE-N3IWF connection for non-3GPP) and an N2 connection for the UE 301 between the AN (e.g., the RAN 310) and the AMF 321. The UE 301 can operate in one of two CM states: the CM Idle (CM-IDLE) mode or the CM Connected (CM-CONNECTED) mode. When the UE 301 operates in the CM-IDLE state / mode, the UE 301 may not have a NAS signaling connection established with the AMF 321 over the N1 interface, and there may be an (R)AN 310 signaling connection (e.g., an N2 and / or N3 connection) for the UE 301. When the UE 301 operates in the CM-CONNECTED state / mode, the UE 301 may have a NAS signaling connection established with the AMF 321 over the N1 interface, and there may be an (R)AN 310 signaling connection (e.g., an N2 and / or N3 connection) for the UE 301. Establishing an N2 connection between the (R)AN 310 and the AMF 321 can cause the UE 301 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and when the N2 signaling between the (R)AN 310 and the AMF 321 is released, the UE 301 can transition from the CM-CONNECTED mode to the CM-IDLE mode.

[0071] The SMF 324 may be responsible for: Session Management (SM) (e.g., session establishment, modification, and release, including the maintenance of tunnels between the UPF and the AN node); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuration of traffic steering at the UPF to route traffic to the correct destination; termination of the interface to the Policy Control Function; control of part of the policy enforcement and QoS; lawful interception (for SM events and the interface to the LI system); termination of NAS messages for the SM part; downlink data notification; originator of AN-specific SM information, sent to the AN via the AMF over N2; determination of the SSC mode of the session. SM may refer to the management of a PDU session, and a PDU session or "session" may refer to a PDU connection service that provides or enables PDU exchange between the UE 301 and the data network (DN) 303 identified by the data network name (DNN). A PDU session may be established upon request by the UE 301, modified upon request by the UE 301 and the 5GC 320, and released using NAS SM signaling exchanged between the UE 301 and the SMF324 over the N1 reference point upon request by the UE 301 and the 5GC 320. Based on a request from the application server, the 5GC 320 may trigger a specific application in the UE 301. In response to receiving the trigger message, the UE 301 may pass the trigger message (or relevant part / information of the trigger message) to one or more identified applications in the UE 301. The identified application(s) in the UE 301 may establish a PDU session to a specific DNN. The SMF 324 may check whether the UE301 request complies with the user subscription information associated with the UE 301. In this regard, the SMF 324 may retrieve and / or request updated notifications regarding SMF 324-level subscription data from the UDM 327.

[0072] The SMF 324 may include the following roaming functions: handling local enforcement to apply the QoS SLA (VPLMN); charging data collection and charging interface (VPLMN); lawful interception (in the interface between the VPLMN of SM events and the LI system); supporting interaction with an external DN for signaling the authorization / authentication of PDU sessions over the external DN. The N16 reference point between two SMF 324s may be included in the system 300, which may be between another SMF 324 in the access network and the SMF 324 in the home network in a roaming scenario. Additionally, the SMF 324 may expose an Nsmf service-based interface.

[0073] The NEF 323 can provide means for securely exposing services and capabilities provided by 3GPP network functions to third parties, internal exposure / re - exposure, application functions (e.g., AF 328), edge computing or fog computing systems, etc. In such an embodiment, the NEF 323 can authenticate, authorize, and / or restrict the AF. The NEF 323 can also transform the information exchanged with the AF 328 and the information exchanged with internal network functions. For example, the NEF 323 can transform between an AF service identifier and internal 5GC information. The NEF 323 can also receive information from other network functions (NFs) based on their exposure capabilities. This information can be stored in the NEF 323 as structured data, or stored in a data storage device NF using a standardized interface. Then, the stored information can be re - exposed by the NEF323 to other NFs and AFs, and / or used for other purposes, such as analysis. Additionally, the NEF 323 can expose an interface based on the Nnef service.

[0074] The NRF 325 can support a service discovery function, receive an NF discovery request from an NF instance, and provide information about the discovered NF instance to the NF instance. The NRF 325 also maintains information about available NF instances and the services they support. As used herein, terms such as "instantiation" etc. can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. Additionally, the NRF 325 can expose an interface based on the Nnrf service.

[0075] The PCF 326 can provide policy rules to control one or more plane functions to enforce them, and can also support a unified policy framework to manage network behavior. The PCF 326 can also implement a front - end (FE) to access subscription information related to policy decisions in the UDR of the UDM 327. The PCF 326 can communicate with the AMF 321 via the N15 reference point between the PCF 326 and the AMF 321, which can include the PCF 326 in the access network and the AMF 321 in a roaming scenario. The PCF 326 can communicate with the AF 328 via the N5 reference point between the PCF 326 and the AF 328; and communicate with the SMF 324 via the N7 reference point between the PCF 326 and the SMF 324. The system 200 and / or the CN 120 can also include an N24 reference point between the PCF 326 (in the home network) and the PCF 326 in the access network. Additionally, the PCF 326 can expose an interface based on the Npcf service.

[0076] The UDM 327 can process subscription-related information to support the handling of communication sessions by network entities and can store the subscription data of the UE 301. For example, the subscription data can be transmitted between the UDM 327 and the AMF 321 via the N8 reference point ( Figure 3 not shown) between the UDM 327 and the AMF 321. The UDM 327 can include two parts: the application FE and the user data repository (UDR) ( Figure 3 the FE and the UDR are not shown in ). The UDR can store the subscription data and policy data for the UDM 327 and the PCF 326, and / or the structured data and application data for exposure (including the packet flow description (PFD) for application detection, the application request information for multiple UEs 201) for the NEF 323. The UDR 221 can expose an interface based on the Nudr service to allow the UDM 327, the PCF 326, and the NEF 323 to access a specific 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 can include the UDM FE, which is responsible for the handling of credentials, location management, subscription management, etc. Several different front-ends can serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing; user identification processing; access authorization; registration / mobility management; and subscription management. The UDR can interact with the SMF 324 via the N10 reference point between the UDM 327 and the SMF 324. The UDM 327 can also support SMS management, where the SMS-FE implements similar application logic as described above. Additionally, the UDM 327 can expose an interface based on the Nudm service.

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

[0078] The NSSF 329 can select a set of network slice instances to serve the UE 301. The NSSF 329 can also determine the allowed Network Slice Selection Assistance Information (NSSAI) and the mapping to the subscribed single NSSAI (S-NSSAI), if required. The NSSF 329 can also determine a set of AMFs or a list of candidate AMFs 221 for serving the UE 301 based on a suitable configuration and possibly by querying the NRF 325. The selection of a set of network slice instances for the UE 301 can be triggered by the AMF 321 (which registers the UE 301 by interacting with the NSSF 329), which can result in a change of the AMF 321. The NSSF 329 can interact with the AMF 321 via the N22 reference point between the AMF 321 and the NSSF 329; and can communicate with another NSSF 329 in the access network via the N31 reference point ( Figure 3 not shown in the figure). Additionally, the NSSF 329 can expose an interface based on the Nnssf service.

[0079] As previously mentioned, the CN 320 can include an SMSF, which can be responsible for SMS subscription checking and verification, and relaying SM messages from other entities to the UE 301 / relaying SM messages from the UE 301 to other entities, where the other entities can be, for example, an SMS-GMSC / IWMSC / SMS router. The SMS can also interact with the AMF 321 and the UDM 327 for the notification process for which the UE 301 is available for SMS transmission (e.g., setting the UE unreachable flag and notifying the UDM 327 when the UE 301 is available for SMS).

[0080] CN 120 may also include Figure 3 other elements not shown, such as a data storage system / architecture, a 5G Equipment Identity Register (5G-EIR), a Security Edge Protection Proxy (SEPP), etc. The data storage system may include a Structured Data Storage Network Function (SDSF), an Unstructured Data Storage Network Function (UDSF), etc. Any NF may store unstructured data into or retrieve unstructured data (e.g., UE context) from the UDSF via an N18 reference point ( Figure 3 not shown) between any NF and the UDSF. Separate NFs may share a UDSF for storing their respective unstructured data, or each NF may have its own UDSF located at or near each NF. Additionally, the UDSF may expose an interface based on Nudsf services ( Figure 3 not shown). The 5G-EIR may be an NF that checks the status of a Permanent Equipment Identifier (PEI) to determine whether a specific device / entity is blacklisted from the network; the SEPP may be a non-transparent proxy that performs topology hiding, message filtering, and supervision on the PLMN inter-control plane interface.

[0081] Additionally, there may be more reference points and / or service-based interfaces between NF services in the NF; however, for clarity, Figure 3 these interfaces and reference points are omitted herein. In one example, CN 320 may include an Nx interface, which is an inter-CN interface between an MME (e.g., MME 221) and an AMF 321 to enable interworking between CN 320 and CN 220. Other example interfaces / reference points may include an interface based on N5g-eir services exposed by the 5G-EIR, an N27 reference point between the NRF in the access network and the NRF in the home network; and an N31 reference point between the NSSF in the access network and the NSSF in the home network.

[0082] In some embodiments, system 300 may include a UE 331, which may be the same as or similar to the previously discussed UE 101, UE 201, and UE 301. As Figure 3 shown, UE 301 and UE 331 may perform V2X communication with each other via a PC5 reference point. The PC5 reference point may include an LTE-based PC5 and / or an NR-based PC5. In some embodiments, the PC5 is a sidelink, and thus in these embodiments, terms including "PC5" and terms including "sidelink" may be interchangeable.

[0083] The configuration of PC5 QoS authorization information for V2X services will be discussed below.

[0084] Figure 4 FIG. 400 illustrates a process for configuring PC5 QoS authorization information for V2X services to a UE and a RAN according to some embodiments of the present disclosure.

[0085] A UE 401 (e.g., Figure 1 one or more UEs 101 in Figure 2 UE201 in Figure 3 UE 301 in etc.) may be connected to a RAN 402 (e.g., Figure 1 RAN110 in Figure 2 EUTRAN 210 in Figure 3 RAN 310 in etc.). The UE 401 may communicate with the AMF 403 of the 5GC via the N1 reference point (e.g., Figure 3 AMF 321 in Figure 3 ). The RAN402 may communicate with the AMF 403 via the N2 reference point. The AMF 403 may communicate with the PCF 404 of the 5GC via the N15 reference point (e.g.,

[0086] As Figure 4 shown, at 410, the PCF 404 may determine V2X policy / parameter information for PC5 QoS authorization. This determination may be triggered based on various trigger conditions.

[0087] In one embodiment, the UE 401 may generate a UE policy provisioning request for the V2X policy / parameter information and send the UE policy provisioning request to the AMF 403, as shown at 408. Then, the AMF 403 may send the UE policy provisioning request to the PCF 404, as shown at 409. The PCF 404 may trigger the determination of the V2X policy / parameter information in response to receiving the UE policy provisioning request.

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

[0089] After determining the V2X policy / parameter information, the PCF 404 may send the V2X policy / parameter information to the AMF 403 at 420, for example, via the Namf_Communication_N1N2MessageTransfer message.

[0090] At 430, the AMF 403 can send V2X policy / parameter information to the UE 401, for example, via a NAS message.

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

[0092] In one embodiment, the V2X service type may be indicated by a provider service identifier (PSID) or an intelligent transport system (ITS) application identifier (ITS-AID).

[0093] In one embodiment, the PC5 QoS parameters may include a PC5 5G QoS identifier (PQI). Different values of the PQI may correspond to respective sets of specific QoS requirements.

[0094] In one embodiment, alternatively or additionally, the PC5 QoS parameters may include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a latency-critical GBR QoS flow.

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

[0096] In response to receiving V2X policy / parameter information from the AMF 403 at 430, the UE 401 may send a response to the AMF 403 at 450. At 460, the AMF 403 may forward the response of the UE 401 to the PCF 404, for example, via the Namf_Communication_N1MessageNotify message.

[0097] In one embodiment, the PCF 404 may include the V2X policy / parameter information in the UE Policy Container of the Namf_Communication_N1N2MessageTransfer message. In the case where the PCF 404 configures the V2X policy / parameter information in response to receiving a UE policy configuration request from the UE 401, the UE 401 may send a UE policy configuration request including the UE Policy Container to the AMF 403; and the AMF 403 may forward the UE Policy Container to the PCF 404.

[0098] Configuring the V2X policy / parameter information for the UE 401 may use the procedure(s) defined in Section 6.2 of 3GPP TS 23.287 v0.2.0 (2019-03).

[0099] In an embodiment where the UE 401 performs V2X communication in network control mode, the RAN 402 may require the V2X policy / parameter information to assist in PC5 radio resource scheduling. In one embodiment, as shown at 440, the AMF 403 may send the V2X policy / parameter information to the RAN 402, for example, via an NG application protocol layer (NGAP) message.

[0100] Figure 4 The shown order of operations is for illustrative purposes only, and operation 440 may be performed at any time after the AMF 403 receives the V2X policy / parameter information at 420.

[0101] In an embodiment where the UE 401 performs V2X communication in network control mode, the PCF 404 may include V2X policy / parameter information in both the UE policy container (for the UE) and the N2 PC5 policy container (N2PC5 Policy Container) (for the RAN) of the Namf_Communication_N1N2MessageTransfer message. When the AMF 403 receives such a Namf_Communication_N1N2MessageTransfer message, the AMF 403 may forward the V2X policy / parameter information to the RAN 402 via an NGAP message and forward the V2X policy / parameter information to the UE 401 via an NAS message.

[0102] In one embodiment, the V2X policy / parameter information sent to the RAN 402 at 440 may be the same as or similar to the V2X policy / parameter information sent to the UE 401 at 430, that is, the V2X policy / parameter information sent to the RAN 402 may include a mapping between the V2X service type and the PC5 QoS parameters.

[0103] Similarly, in one embodiment, the mapping between the V2X service type and the PC5 QoS parameters sent to the RAN 402 may be differentiated for unicast, multicast, and broadcast. For example, the mapping between the V2X service type and the PC5 QoS parameters may include: the mapping between the V2X service type and the PC5 QoS parameters for unicast, the mapping between the V2X service type and the PC5 QoS parameters for multicast, and / or the mapping between the V2X service type and the PC5 QoS parameters for broadcast.

[0104] In one embodiment, the PC5 QoS parameters in the mapping allocated to the RAN 402 may be shared for all V2X service types in the mapping, which is different from the mapping allocated to the UE 401. For example, in the mapping allocated to the RAN 402, all V2X service types in the mapping may be indicated by a shared character, that is, there is no specific V2X service type in the mapping.

[0105] Alternatively or additionally, in one embodiment, the V2X policy / parameter information sent to the RAN 402 at 440 may include a mapping between the destination layer 2 ID and the PC5 QoS parameters.

[0106] In one embodiment, the mapping between the destination layer 2 ID and the PC5 QoS parameters may include: the mapping between the default destination layer 2 ID for the initial unicast signaling of unicast and the PC5 QoS parameters; the mapping between the destination layer 2 ID for multicast and the PC5 QoS parameters; and / or the mapping between the destination layer 2 ID for broadcast and the PC5 QoS parameters.

[0107] In one embodiment, the PC5 QoS parameters in the mapping may be shared for all the destination layer 2 IDs in the mapping. For example, in the mapping configured for the RAN 402, all the destination layer 2 IDs in the mapping may be indicated by a shared character, that is, there is no specific destination layer 2 ID in the mapping.

[0108] In one embodiment, the PC5 QoS parameters determined by the RAN 402 from the mapping for the UE may include one or more PQI values and / or one or more GFBR / MFBR values, which are not limited in this regard.

[0109] Configuring the V2X policy / parameter information for the RAN 402 may use the (one or more) procedures defined in Section 6.5 of 3GPP TS 23.287 v0.2.0 (2019-03).

[0110] In one embodiment, when the PC5 QoS parameters are not received from the upper layer, the PC5 QoS authorization information configured for the V2X service for the UE and the RAN in the Figure 4 procedure may be used for the PC5 radio resource scheduling. However, the present disclosure is not limited in this regard.

[0111] The procedure for configuring the PC5 QoS authorization information for the V2X service for the UE and the RAN has been described above. The methods for configuring the PC5 QoS authorization information for the V2X service for the UE and / or the RAN will be described below from the perspectives of the UE, the RAN, and the 5GC (e.g., the PCF).

[0112] Figure 5 The flowchart of a method 500 for configuring the PC5 QoS authorization information for the V2X service for the UE from the perspective of the UE according to some embodiments of the present disclosure is shown.

[0113] At 510, the UE (e.g., Figure 1 one or more of the UEs 101 in Figure 2 the UE 201 in Figure 3 the UE301 in Figure 4UEs such as UE 401 are configured to receive a message including V2X policy / parameter information from the 5GC, e.g., via Figure 4 the AMF 403 in Figure 4 the PCF 404 in

[0114] at 520, the UE may be configured to determine the PC5 QoS parameters for the UE based on the mapping between the V2X service type and the PC5 QoS parameters and the V2X service type of the UE.

[0115] at 530, the UE may be configured to perform V2X communication based on the PC5 QoS parameters for the UE.

[0116] Figure 6 and Figure 7 both show, from the perspective of the RAN, a method for configuring the PC5 QoS authorization information for V2X services to the RAN. Figure 6 shows a flowchart of a method 600 for configuring the PC5 QoS authorization information for V2X services to the RAN from the perspective of the RAN according to some embodiments of the present disclosure.

[0117] at 610, the RAN (e.g., Figure 1 the RAN 110 in Figure 2 the EUTRAN210 in Figure 3 the RAN 310 in Figure 4 the RAN 401 in etc.) may be configured to receive a message including V2X policy / parameter information from the 5GC, e.g., via Figure 4 the AMF 403 in Figure 4 the PCF 404 in

[0118] at 620, the RAN may be configured to determine the PC5 QoS parameters for the UE based on the mapping between the V2X service type and the PC5 QoS parameters.

[0119] at 630, the RAN may be configured to schedule the PC5 radio resources for the V2X communication of the UE based on the PC5 QoS parameters for the UE.

[0120] Figure 7FIG. 700 is a flowchart of a method for configuring PC5 QoS authorization information for V2X services from the perspective of the RAN according to some embodiments of the present disclosure.

[0121] In contrast to Figure 6 compared with Figure 7 which involves mapping between the destination layer 2 ID and PC5 QoS parameters, rather than Figure 6 the mapping between the V2X service type and PC5 QoS parameters.

[0122] At 710, the RAN (e.g., RAN 110 in Figure 1 , EUTRAN 210 in Figure 2 , RAN 310 in Figure 3 , RAN 401 in Figure 4 etc.) may be configured to receive a message including V2X policy / parameter information from the 5GC, e.g., via the AMF 403 in Figure 4 receiving from the PCF 404 in Figure 4 . The V2X policy / parameter information may include the mapping between the destination layer 2 ID and PC5 QoS parameters. The V2X policy / parameter information has been introduced in detail above and will not be elaborated here.

[0123] At 720, the RAN may be configured to determine the PC5 QoS parameters for the UE based on the mapping between the destination layer 2 ID and PC5 QoS parameters.

[0124] At 730, the RAN may be configured to schedule PC5 radio resources for the UE's V2X communication based on the PC5 QoS parameters for the UE.

[0125] Figure 8 And Figure 9 both show methods for configuring PC5 QoS authorization information for V2X services from the perspective of the 5GC to the UE and / or the RAN. Figure 8 FIG. 800 is a flowchart of a method for configuring PC5 QoS authorization information for V2X services from the perspective of the 5GC to the UE according to some embodiments of the present disclosure.

[0126] At 810, the 5GC (e.g., the PCF (e.g., PCF 326 in Figure 3 , PCF 404 in Figure 4 )) may be configured to generate V2X policy / parameter information. The V2X policy / parameter information may include the mapping between the V2X service type and PC5 QoS parameters. The V2X policy / parameter information has been introduced in detail above and will not be elaborated here.

[0127] At 820, the PCF may be configured to send V2X policy / parameter information to the UE for V2X communication of the UE.

[0128] Figure 9 FIG. 900 is a flowchart of a method for the 5GC to configure the RAN with PC5 QoS authorization information for V2X services from the perspective of the 5GC according to some embodiments of the present disclosure.

[0129] At 910, the 5GC (e.g., the PCF (e.g., Figure 3 PCF 326 in Figure 4 PCF 404 in

[0130] )) may be configured to generate V2X policy / parameter information. The V2X policy / parameter information may include a first mapping between a destination layer 2 ID and PC5 QoS parameters and / or a second mapping between a V2X service type and PC5 QoS parameters. The V2X policy / parameter information has been described in detail above and will not be repeated here.

[0131] Figure 10 FIG. 1000 shows an example component of a device 1000 according to some embodiments. In some embodiments, the device 1000 may include at least application circuitry 1002, baseband circuitry 1004, radio frequency (RF) circuitry 1006, front-end module (FEM) circuitry 1008, one or more antennas 1010, and a power management circuit (PMC) 1012 coupled together as shown. The components of the shown device 1000 may be included in a UE or an AN. In some embodiments, the device 1000 may include fewer elements (e.g., the AN may not use the application circuitry 1002 but include a processor / controller to process IP data received from the EPC). In some embodiments, the device 1000 may include additional elements, such as a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, the components described below may be included in more than one device (e.g., for a Cloud-RAN (C-RAN) implementation, the circuitry may be separately included in more than one device).

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

[0133] The baseband circuit 1004 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuit 1004 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of the RF circuit 1006 and generate baseband signals for the transmit signal path of the RF circuit 1006. The baseband processing circuit 1004 may interface with the application circuit 1002 to generate and process baseband signals and control the operation of the RF circuit 1006. For example, in some embodiments, the baseband circuit 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 (one or more) other baseband processors 1004D for other existing generations, generations under development, or generations to be developed in the future (e.g., sixth-generation (6G), etc.). The baseband circuit 1004 (e.g., one or more of the baseband processors 1004A-D) may process various radio control functions that support communication with one or more radio networks via the RF circuit 1006. In other embodiments, some or all of the functions of the baseband processors 1004A-D may be included in modules stored in the memory 1004G and these functions may be executed via the central processing unit (CPU) 1004E. The radio control functions may include, but are not limited to: signal modulation / demodulation, encoding / decoding, radio frequency shift, etc. In some embodiments, the modulation / demodulation circuit of the baseband circuit 1004 may include fast Fourier transform (FFT), precoding, and / or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuit of the baseband circuit 1004 may include convolutional, tail-biting convolutional, turbo, Viterbi, and / or low density parity check (LDPC) encoder / decoder functions. Embodiments of the modulation / demodulation and encoder / decoder functions are not limited to these examples and may include other suitable functions in other embodiments.

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

[0135] In some embodiments, baseband circuit 1004 may provide communication compatible with one or more radio technologies. For example, in some embodiments, baseband circuit 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 baseband circuit 1004 is configured to support radio communication for more than one wireless protocol may be referred to as multimode baseband circuits.

[0136] RF circuit 1006 may support communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, RF circuit 1006 may include switches, filters, amplifiers, etc. to assist in communication with the wireless network. RF circuit 1006 may include a receive signal path, which may include circuitry for down-converting an RF signal received from FEM circuit 1008 and providing a baseband signal to baseband circuit 1004. RF circuit 1006 may also include a transmit signal path, which may include circuitry for up-converting the baseband signal provided by baseband circuit 1004 and providing an RF output signal to FEM circuit 1008 for transmission.

[0137] In some embodiments, the receive signal path of RF circuit 1006 may include mixer circuit 1006a, amplifier circuit 1006b, and filter circuit 1006c. In some embodiments, the transmit signal path of RF circuit 1006 may include filter circuit 1006c and mixer circuit 1006a. RF circuit 1006 may also include synthesizer circuit 1006d, which is used to synthesize the frequencies for mixer circuit 1006a of the receive signal path and the transmit signal path. In some embodiments, mixer circuit 1006a of the receive signal path may be configured to down-convert the RF signal received from FEM circuit 1008 based on the synthesized frequency provided by synthesizer circuit 1006d. Amplifier circuit 1006b may be configured to amplify the down-converted signal, and filter circuit 1006c may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuit 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 include a passive mixer, but the scope of the embodiments is not limited in this regard.

[0138] In some embodiments, mixer circuit 1006a of the transmit signal path may be configured to up-convert the input baseband signal based on the synthesized frequency provided by synthesizer circuit 1006d to generate an RF output signal for FEM circuit 1008. The baseband signal may be provided by baseband circuit 1004 and may be filtered by filter circuit 1006c.

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

[0140] In some embodiments, mixer circuit 1006a of the receive signal path and 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 circuit 1006a of the receive signal path and mixer circuit 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.

[0141] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, but the scope of the embodiments is not limited in this regard. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuit 1006 may include an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) circuit, and the baseband circuit 1004 may include a digital baseband interface for communicating with the RF circuit 1006.

[0142] In some dual-mode embodiments, separate radio IC circuits may be provided to process the signals of each spectrum, but the scope of the embodiments is not limited in this regard.

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

[0144] 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 a frequency input and a frequency divider control input. In some embodiments, the synthesizer circuit 1006d may be a fractional-N / N+1 synthesizer.

[0145] In some embodiments, the frequency input may be provided by a voltage-controlled oscillator (VCO), but this is not required. The frequency divider control input may be provided by the baseband circuit 1004 or the application processor 1002 according to the desired output frequency. In some embodiments, the frequency divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application processor 1002.

[0146] The synthesizer circuit 1006d of the RF circuit 1006 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode frequency divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N+1 (e.g., based on a carry output) to provide a fractional division ratio. In some example embodiments, the 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 bins, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO period.

[0147] 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 in conjunction with an orthogonal generator and a divider circuit to generate multiple signals having multiple different phases from each other at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 1006 may include an IQ / polarity converter.

[0148] The FEM circuit 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 an amplified version of the received signals to the RF circuit 1006 for further processing. The FEM circuit 1008 may also include a transmit signal path that may include circuitry configured to amplify signals provided by the RF circuit 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 circuit 1006, only in the FEM 1008, or in both the RF circuit 1006 and the FEM 1008.

[0149] In some embodiments, the FEM circuit 1008 may include a TX / RX switch to switch between transmit mode and receive mode operations. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include a low noise amplifier (LNA) to amplify the received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuit 1006). The transmit signal path of the FEM circuit 1008 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuit 1006) and one or more filters for generating an RF signal for subsequent transmission (e.g., by one or more of the one or more antennas 1010).

[0150] In some embodiments, the PMC 1012 may manage the power provided to the baseband circuit 1004. Specifically, the PMC 1012 may control power selection, voltage scaling, battery charging, or DC-DC conversion. When the device 1000 is capable of being powered by a battery, e.g., when the device is included in a UE, the PMC 1012 is typically included. The PMC 1012 may improve power conversion efficiency while providing desired implementation size and thermal characteristics.

[0151] Although Figure 10It is shown that PMC 1012 is only coupled to the baseband circuit 1004. However, in other embodiments, PMC 1012 may additionally or alternatively be coupled to other components and perform similar power management operations on other components, such as but not limited to the application circuit 1002, the RF circuit 1006, or the FEM 1008.

[0152] In some embodiments, PMC 1012 may control various power saving mechanisms of the device 1000 or otherwise be part of various power saving mechanisms of the device 1000. For example, if the device 1000 is in the RRC_Connected state, in which the device 1000 remains connected to the RAN node when it is expected to receive traffic soon, and then may enter a state called discontinuous reception mode (DRX) after a period of inactivity. During this state, the device 1000 may power off for short time intervals, thus saving power.

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

[0154] Additional power saving modes may allow the device to be unavailable to the network for a period longer than the paging interval (ranging from a few seconds to several hours). During this period, the device has no access to the network at all and may power off completely. Any data sent during this period will incur a large delay, and it is assumed that the delay is acceptable.

[0155] The processors of the application circuit 1002 and the baseband circuit 1004 can be used to execute elements of one or more instances of the protocol stack. For example, the processor of the baseband circuit 1004 (alone or in combination) can be used to execute layer 3, layer 2, or layer 1 functions, while the processor of the application circuit 1004 can utilize the data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., the transport control protocol (TCP) and user datagram protocol (UDP) layers). As mentioned herein, layer 3 may include the RRC layer. As mentioned herein, layer 2 may include the media access control (MAC) layer, the radio link control (RLC) layer, and the packet data convergence protocol (PDCP) layer. As mentioned herein, layer 1 may include the physical (PHY) layer of the UE / RAN node.

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

[0157] The baseband circuit 1004 may also include one or more interfaces to communicatively couple to other circuits / devices, such as a memory interface 1112 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 1004), an application circuit interface 1114 (e.g., an interface for sending / receiving data to / from Figure 10 the application circuit 1002), an RF circuit interface 1116 (e.g., an interface for sending / receiving data to / from Figure 10 the RF circuit 1006), a wireless hardware connection interface 1118 (e.g., an interface for sending / receiving data to / from a near - field communication (NFC) component, a Bluetooth component (e.g., Bluetooth Low Energy), a Wi - Fi component, and other communication components), and a power management interface 1120 (e.g., an interface for sending / receiving power or control signals to / from the PMC 1012).

[0158] Figure 12 is a block diagram showing 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 methods discussed herein. Specifically, Figure 12 illustrates a graphical 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), a hypervisor 1202 may be executed to provide an execution environment for one or more network slices / sub - slices to utilize the hardware resources 1200.

[0159] The 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, processors 1212 and 1214.

[0160] The memory / storage device 1220 may include a main memory, a disk memory, or any suitable combination thereof. The memory / storage device 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 devices, etc.

[0161] The communication resource 1230 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 1204 or one or more databases 1206 via the network 1208. For example, the communication resource 1230 may include a wired communication component (e.g., for coupling via a Universal Serial Bus (USB)), a cellular communication component, an NFC component, a Bluetooth component (e.g., Bluetooth Low Energy), a Wi-Fi component, and other communication components.

[0162] The instructions 1250 may include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors 1210 to perform any one or more of the methods discussed herein. The instructions 1250 may reside, in whole or in part, in at least one of the processor 1210 (e.g., within the buffer memory of the processor), the memory / storage device 1220, or any suitable combination thereof. Additionally, any part of the instructions 1250 may be transferred from any combination of the peripheral devices 1204 or the database 1206 to the hardware resource 1200. Thus, the memories of the processor 1210, the memory / storage device 1220, the peripheral devices 1204, and the database 1206 are examples of computer-readable and machine-readable media.

[0163] The following paragraphs describe examples of various embodiments.

[0164] Example 1 includes an apparatus for a user equipment (UE), the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is configured to: determine PC5 QoS parameters for the UE based on the mapping and the V2X service type of the UE; and perform V2X communication based on the PC5 QoS parameters for the UE.

[0165] Example 2 includes the apparatus described in Example 1, wherein the mapping between the V2X service type and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

[0166] Example 3 includes the apparatus described in Example 1 or 2, wherein the V2X service type of the UE is indicated by a provider service identifier (PSID) or an intelligent transportation system (ITS) application identifier (ITS-AID).

[0167] Example 4 includes the apparatus described in any one of Examples 1 to 3, wherein the PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

[0168] Example 5 includes the apparatus described in Example 4, wherein the PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

[0169] Example 6 includes the apparatus described in any one of Examples 1 to 5, wherein the processor circuit is configured to: generate a UE policy configuration request for the V2X policy / parameter information and cause the UE policy configuration request to be sent to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy configuration request.

[0170] Example 7 includes the apparatus described in 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.

[0171] Example 8 includes the apparatus described in any one of Examples 1 to 7, wherein the RF interface is configured to receive the message from a policy control function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5GC.

[0172] Example 9 includes an apparatus for an access node (AN), the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is configured to: determine PC5 QoS parameters for a user equipment (UE) based on the mapping; and schedule PC5 radio resources for V2X communication of the UE based on the PC5 QoS parameters for the UE.

[0173] Example 10 includes the apparatus of Example 9, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

[0174] Example 11 includes the apparatus of Example 9 or 10, wherein if all V2X service types in the mapping are indicated by a common character, the PC5 QoS parameters in the mapping are common for all V2X service types.

[0175] Example 12 includes the apparatus of any one of Examples 9 to 11, wherein the PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

[0176] Example 13 includes the apparatus of Example 12, wherein the PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

[0177] Example 14 includes the apparatus of any one of Examples 9 to 13, wherein the message is sent from the 5GC in response to a UE policy configuration request for the V2X policy / parameter information received by the 5GC from the UE.

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

[0179] Example 16 includes the apparatus of any one of Examples 9 to 15, wherein the RF interface is configured to receive the message from a policy control function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5GC.

[0180] Example 17 includes the apparatus according to any one of Examples 9 to 16, wherein the AN includes a next-generation NodeB (gNB).

[0181] Example 18 includes an apparatus for an access node (AN), the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between a destination layer 2 ID and a sidelink quality of service (QoS) parameter, and wherein the processor circuit is configured to: determine a sidelink QoS parameter for a user equipment (UE) based on the mapping; and schedule sidelink radio resources for V2X communication of the UE based on the sidelink QoS parameter for the UE.

[0182] Example 19 includes the apparatus according to Example 18, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameter includes: a mapping between a default destination layer 2 ID for initial unicast signaling for unicast and the sidelink QoS parameter; a mapping between the destination layer 2 ID and the sidelink QoS parameter for multicast; or a mapping between the destination layer 2 ID and the sidelink QoS parameter for broadcast.

[0183] Example 20 includes the apparatus according to Example 18 or 19, wherein if all the destination layer 2 IDs in the mapping are indicated by a common character, the sidelink QoS parameters in the mapping are common for all the destination layer 2 IDs.

[0184] Example 21 includes the apparatus according to any one of Examples 18 to 20, wherein the sidelink QoS parameter for the UE includes a PC5 5G QoS identifier (PQI).

[0185] Example 22 includes the apparatus according to Example 21, wherein the sidelink QoS parameter for the UE further includes: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

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

[0187] Example 24 includes the apparatus according to 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.

[0188] Example 25 includes the apparatus according to any one of Examples 18 to 24, wherein the RF interface is used to receive the message from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0189] Example 26 includes the apparatus according to any one of Examples 18 to 25, wherein the AN includes a next-generation NodeB (gNB).

[0190] Example 27 includes an apparatus for a 5G core network (5GC) of a fifth-generation (5G) system (5GS), the apparatus comprising: interface circuitry; and processor circuitry coupled to the interface circuitry, wherein the processor circuitry is configured to: generate 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 cause the V2X policy / parameter information to be sent to a user equipment (UE) for V2X communication of the UE.

[0191] Example 28 includes the apparatus of Example 27, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

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

[0193] Example 30 includes the apparatus according to any one of Examples 27 to 29, wherein the processor circuitry is configured to: generate the V2X policy / parameter information in response to receiving a UE policy configuration request for the V2X policy / parameter information from the UE.

[0194] Example 31 includes the apparatus according to any one of Examples 27 to 29, wherein the processor circuitry is configured to: generate the V2X policy / parameter information in response to a network-triggered update of the V2X policy / parameter information.

[0195] Example 32 includes an apparatus for a 5G core network (5GC) of a fifth-generation (5G) system (5GS), the apparatus including: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: generate vehicle-to-everything (V2X) policy / parameter information, where the V2X policy / parameter information includes a first mapping between a destination layer 2 ID and a PC5 quality of service (QoS) parameter or a second mapping between a V2X service type and a PC5 QoS parameter; and cause the V2X policy / parameter information to be sent to an access node (AN) to schedule PC5 radio resources for V2X communication of a user equipment (UE).

[0196] Example 33 includes the apparatus of Example 32, wherein the first mapping between a destination layer 2 ID and a PC5 QoS parameter includes: a mapping between a default destination layer 2 ID for initial unicast signaling for unicast and a PC5 QoS parameter; a mapping between a destination layer 2 ID and a PC5 QoS parameter for multicast; or a mapping between a destination layer 2 ID and a PC5 QoS parameter for broadcast.

[0197] Example 34 includes the apparatus of Example 32 or 33, wherein if all destination layer 2 IDs in the first mapping are indicated by a common character, the PC5 QoS parameters in the first mapping are common for all destination layer 2 IDs.

[0198] Example 35 includes the apparatus of Example 32, wherein the second mapping between a V2X service type and a PC5 QoS parameter includes: a mapping between a V2X service type and a PC5 QoS parameter for unicast; a mapping between a V2X service type and a PC5 QoS parameter for multicast; or a mapping between a V2X service type and a PC5 QoS parameter for broadcast.

[0199] Example 36 includes the apparatus of Example 32 or 35, wherein if all V2X service types in the second mapping are indicated by a common character, the PC5 QoS parameters in the second mapping are common for all V2X service types.

[0200] Example 37 includes the apparatus of any one of Examples 32 to 36, wherein the interface circuit is configured to: send the V2X policy / parameter information to the AN via an access and mobility management function (AMF) of the 5GC.

[0201] Example 38 includes the apparatus of any one of Examples 32 to 37, wherein the processor circuit is configured to: generate the V2X policy / parameter information in response to receiving a UE policy configuration request for V2X policy / parameter information from the UE.

[0202] Example 39 includes the apparatus according to any one of Examples 32 to 37, wherein the processor circuit is configured to: generate the V2X policy / parameter information in response to a network-triggered update of the V2X policy / parameter information.

[0203] Example 40 includes the apparatus according to any one of Examples 32 to 39, wherein the AN includes a next-generation NodeB (gNB).

[0204] Example 41 includes a method performed by a user equipment (UE), the method including: receiving, from a 5G core network (5GC) of a fifth-generation (5G) system (5GS), a message that includes vehicle-to-everything (V2X) policy / parameter information, wherein the V2X policy / parameter information includes a mapping between a V2X service type and a PC5 quality of service (QoS) parameter; determining, based on the mapping and the V2X service type of the UE, a PC5 QoS parameter for the UE; and performing V2X communication based on the PC5 QoS parameter for the UE.

[0205] Example 42 includes the method according to Example 41, wherein the mapping between the V2X service type and the PC5 QoS parameter is differentiated for unicast, multicast, and broadcast.

[0206] Example 43 includes the method according to Example 41 or 42, wherein the V2X service type of the UE is indicated by a provider service identifier (PSID) or an intelligent transport system (ITS) application identifier (ITS-AID).

[0207] Example 44 includes the method according to any one of Examples 41 to 43, wherein the PC5 QoS parameter for the UE includes a PC5 5G QoS identifier (PQI).

[0208] Example 45 includes the method according to Example 44, wherein the PC5 QoS parameter for the UE further includes: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a latency-critical GBR QoS flow.

[0209] Example 46 includes the method according to any one of Examples 41 to 45, further including: generating a UE policy configuration request for the V2X policy / parameter information; and sending the UE policy configuration request to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy configuration request.

[0210] Example 47 includes the method according to 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.

[0211] Example 48 includes the method according to any one of Examples 41 to 47, wherein the message is received from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0212] Example 49 includes a method for an access node (AN), the method including: receiving, from a 5G core network (5GC) of a fifth-generation (5G) system (5GS), a message that includes 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; determining, based on the mapping, PC5 QoS parameters for a user equipment (UE); and scheduling, based on the PC5 QoS parameters for the UE, PC5 radio resources for V2X communication of the UE.

[0213] Example 50 includes the method according to Example 49, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

[0214] Example 51 includes the method according to Example 49 or 50, wherein if all V2X service types in the mapping are indicated by a common character, the PC5 QoS parameters in the mapping are common for all V2X service types.

[0215] Example 52 includes the method according to any one of Examples 49 to 51, wherein the PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

[0216] Example 53 includes the method according to Example 52, wherein the PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

[0217] Example 54 includes the method according to any one of Examples 49 to 53, wherein the message is sent from the 5GC in response to a UE policy configuration request for the V2X policy / parameter information received by the 5GC from the UE.

[0218] Example 55 includes the method according to 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.

[0219] Example 56 includes the method according to any one of Examples 49 to 55, wherein the message is received from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0220] Example 57 includes the method according to any one of Examples 49 to 56, wherein the AN includes a next-generation NodeB (gNB).

[0221] Example 58 includes a method for an access node (AN), the method comprising: receiving, from a 5G core network (5GC) of a fifth-generation (5G) system (5GS), a 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, based on the mapping, sidelink QoS parameters for a user equipment (UE); and scheduling sidelink radio resources for V2X communication of the UE based on the sidelink QoS parameters for the UE.

[0222] Example 59 includes the method according to Example 58, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameters comprises: a mapping between a default destination layer 2 ID for initial unicast signaling for unicast and the sidelink QoS parameters; a mapping between the destination layer 2 ID and the sidelink QoS parameters for multicast; or a mapping between the destination layer 2 ID and the sidelink QoS parameters for broadcast.

[0223] Example 60 includes the method according to Example 58 or 59, wherein if all the destination layer 2 IDs in the mapping are indicated by a common character, the sidelink QoS parameters in the mapping are common for all the destination layer 2 IDs.

[0224] Example 61 includes the method according to any one of Examples 58 to 60, wherein the sidelink QoS parameters for the UE comprise a PC5 5G QoS identifier (PQI).

[0225] Example 62 includes the method according to Example 61, wherein the sidelink QoS parameters for the UE further comprise: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

[0226] Example 63 includes the method according to any one of Examples 58 to 62, wherein the message is sent from the 5GC in response to a UE policy configuration request for the V2X policy / parameter information received by the 5GC from the UE.

[0227] Example 64 includes the method according to 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.

[0228] Example 65 includes the method according to any one of Examples 58 to 64, wherein the message is received from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0229] Example 66 includes the method according to any one of Examples 58 to 65, wherein the AN includes a next-generation NodeB (gNB).

[0230] Example 67 includes a method for a 5G core network (5GC) of a fifth-generation (5G) system (5GS), the method including: 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 causing the V2X policy / parameter information to be sent to a user equipment (UE) for V2X communication of the UE.

[0231] Example 68 includes the method of Example 67, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

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

[0233] Example 70 includes the method according to any one of Examples 67 to 69, wherein the V2X policy / parameter information is generated in response to a UE policy configuration request for the V2X policy / parameter information received from the UE.

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

[0235] Example 72 includes a method for a 5G core network (5GC) of a fifth-generation (5G) system (5GS), the method including: generating vehicle-to-everything (V2X) policy / parameter information, where the V2X policy / parameter information includes a first mapping between a destination layer 2 ID and a PC5 quality of service (QoS) parameter or a second mapping between a V2X service type and a PC5 QoS parameter; and causing the V2X policy / parameter information to be sent to an access node (AN) to schedule PC5 radio resources for V2X communication of a user equipment (UE).

[0236] Example 73 includes the method of Example 72, where the first mapping between the destination layer 2 ID and the PC5 QoS parameter includes: a mapping between a default destination layer 2 ID for initial unicast signaling for unicast and the PC5 QoS parameter; a mapping between the destination layer 2 ID and the PC5 QoS parameter for multicast; or a mapping between the destination layer 2 ID and the PC5 QoS parameter for broadcast.

[0237] Example 74 includes the method of Example 72 or 73, where if all destination layer 2 IDs in the first mapping are indicated by a common character, the PC5 QoS parameter in the first mapping is common for all the destination layer 2 IDs.

[0238] Example 75 includes the method of Example 72, where the second mapping between the V2X service type and the PC5 QoS parameter includes: a mapping between the V2X service type for unicast and the PC5 QoS parameter; a mapping between the V2X service type and the PC5 QoS parameter for multicast; or a mapping between the V2X service type and the PC5 QoS parameter for broadcast.

[0239] Example 76 includes the method of Example 72 or 75, where if all V2X service types in the second mapping are indicated by a common character, the PC5 QoS parameter in the second mapping is common for all the V2X service types.

[0240] Example 77 includes the method according to any one of Examples 72 to 76, where the V2X policy / parameter information is sent to the AN via an access and mobility management function (AMF) of the 5GC.

[0241] Example 78 includes the method according to any one of Examples 72 to 77, where the V2X policy / parameter information is generated in response to a UE policy configuration request for V2X policy / parameter information received from the UE.

[0242] Example 79 includes the method according to any one of Examples 72 to 77, wherein the V2X policy / parameter information is generated in response to a network-triggered update of the V2X policy / parameter information.

[0243] Example 80 includes the method according to any one of Examples 72 to 79, wherein the AN includes a next-generation NodeB (gNB).

[0244] Example 81 includes an apparatus for a user equipment (UE), the apparatus including: components 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, wherein the V2X policy / parameter information includes a mapping between a V2X service type and PC5 quality of service (QoS) parameters; components for determining PC5 QoS parameters for the UE based on the mapping and the V2X service type of the UE; and components for performing V2X communication based on the PC5 QoS parameters for the UE.

[0245] Example 82 includes the apparatus according to Example 81, wherein the mapping between the V2X service type and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

[0246] Example 83 includes the apparatus according to Example 81 or 82, wherein the V2X service type of the UE is indicated by a provider service identifier (PSID) or an intelligent transport system (ITS) application identifier (ITS-AID).

[0247] Example 84 includes the apparatus according to any one of Examples 81 to 83, wherein the PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

[0248] Example 85 includes the apparatus according to Example 84, wherein the PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a latency-critical GBR QoS flow.

[0249] Example 86 includes the apparatus according to any one of Examples 81 to 85, further including: components for generating a UE policy configuration request for the V2X policy / parameter information and sending the UE policy configuration request to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy configuration request.

[0250] Example 87 includes the apparatus according to 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.

[0251] Example 88 includes the apparatus according to any one of Examples 81 to 87, wherein the message is received from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0252] Example 89 includes an apparatus for an access node (AN), the apparatus including: components 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters; components for determining PC5 QoS parameters for a user equipment (UE) based on the mapping; and components for scheduling PC5 radio resources for V2X communication of the UE based on the PC5 QoS parameters for the UE.

[0253] Example 90 includes the apparatus according to Example 89, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

[0254] Example 91 includes the apparatus according to Example 89 or 90, wherein if all V2X service types in the mapping are indicated by a common character, the PC5 QoS parameters in the mapping are common for all V2X service types.

[0255] Example 92 includes the apparatus according to any one of Examples 89 to 91, wherein the PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

[0256] Example 93 includes the apparatus according to Example 92, wherein the PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

[0257] Example 94 includes the apparatus according to any one of Examples 89 to 93, wherein the message is sent from the 5GC in response to a UE policy configuration request for the V2X policy / parameter information received by the 5GC from the UE.

[0258] Example 95 includes the apparatus according to 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.

[0259] Example 96 includes the apparatus according to any one of Examples 89 to 95, wherein the message is received from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0260] Example 97 includes the apparatus according to any one of Examples 89 to 96, wherein the AN includes a next-generation NodeB (gNB).

[0261] Example 98 includes an apparatus for an access node (AN), the apparatus comprising: components 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, wherein the V2X policy / parameter information includes a mapping between a destination layer 2 ID and sidelink quality of service (QoS) parameters; components for determining sidelink QoS parameters for a user equipment (UE) based on the mapping; and components for scheduling sidelink radio resources for V2X communication of the UE based on the sidelink QoS parameters for the UE.

[0262] Example 99 includes the apparatus according to Example 98, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameters includes: a mapping between a default destination layer 2 ID for initial unicast signaling for unicast and the sidelink QoS parameters; a mapping between the destination layer 2 ID and the sidelink QoS parameters for multicast; or a mapping between the destination layer 2 ID and the sidelink QoS parameters for broadcast.

[0263] Example 100 includes the apparatus according to Example 98 or 99, wherein if all the destination layer 2 IDs in the mapping are indicated by a common character, the sidelink QoS parameters in the mapping are common for all the destination layer 2 IDs.

[0264] Example 101 includes the apparatus according to any one of Examples 98 to 100, wherein the sidelink QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

[0265] Example 102 includes the apparatus according to Example 101, wherein the sidelink QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a delay-critical GBR QoS flow.

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

[0267] Example 104 includes the apparatus according to 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.

[0268] Example 105 includes the apparatus according to any one of Examples 98 to 104, wherein the message is received from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

[0269] Example 106 includes the apparatus according to any one of Examples 98 to 105, wherein the AN includes a next-generation NodeB (gNB).

[0270] Example 107 includes an apparatus for a 5G core network (5GC) of 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 a component for causing the V2X policy / parameter information to be sent to a user equipment (UE) for V2X communication of the UE.

[0271] Example 108 includes the apparatus of Example 107, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

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

[0273] Example 110 includes the apparatus according to any one of Examples 107 to 109, wherein the V2X policy / parameter information is generated in response to receiving a UE policy configuration request for the V2X policy / parameter information from the UE.

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

[0275] Example 112 includes an apparatus for a 5G core network (5GC) of a fifth-generation (5G) system (5GS), the apparatus including: components for generating vehicle-to-everything (V2X) policy / parameter information, where the V2X policy / parameter information includes a first mapping between a destination layer 2 ID and a PC5 quality of service (QoS) parameter or a second mapping between a V2X service type and a PC5 QoS parameter; and components for causing the V2X policy / parameter information to be sent to an access node (AN) to schedule PC5 radio resources for V2X communication of a user equipment (UE).

[0276] Example 113 includes the apparatus of Example 112, where the first mapping between a destination layer 2 ID and a PC5 QoS parameter includes: a mapping between a default destination layer 2 ID for initial unicast signaling for unicast and a PC5 QoS parameter; a mapping between a destination layer 2 ID and a PC5 QoS parameter for multicast; or a mapping between a destination layer 2 ID and a PC5 QoS parameter for broadcast.

[0277] Example 114 includes the apparatus of Example 112 or 113, where if all the destination layer 2 IDs in the first mapping are indicated by a common character, the PC5 QoS parameters in the first mapping are common for all the destination layer 2 IDs.

[0278] Example 115 includes the apparatus of Example 112, where the second mapping between a V2X service type and a PC5 QoS parameter includes: a mapping between a V2X service type and a PC5 QoS parameter for unicast; a mapping between a V2X service type and a PC5 QoS parameter for multicast; or a mapping between a V2X service type and a PC5 QoS parameter for broadcast.

[0279] Example 116 includes the apparatus of Example 112 or 115, where if all the V2X service types in the second mapping are indicated by a common character, the PC5 QoS parameters in the second mapping are common for all the V2X service types.

[0280] Example 117 includes the apparatus according to any one of Examples 112 to 116, where the V2X policy / parameter information is sent to the AN via an access and mobility management function (AMF) of the 5GC.

[0281] Example 118 includes the apparatus according to any one of Examples 112 to 117, where the V2X policy / parameter information is generated in response to receiving a UE policy configuration request for V2X policy / parameter information from the UE.

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

[0283] Example 120 includes the apparatus according to any one of Examples 112 to 119, wherein the AN includes a next-generation NodeB (gNB).

[0284] Example 121 includes one or more computer-readable media having instructions stored thereon that, when executed by a processor circuit, cause the processor circuit to perform the method according to any one of Examples 41 to 48.

[0285] Example 122 includes one or more computer-readable media having instructions stored thereon that, when executed by a processor circuit, cause the processor circuit to perform the method according to any one of Examples 49 to 66.

[0286] Example 123 includes one or more computer-readable media having instructions stored thereon that, when executed by a processor circuit, cause the processor circuit to perform the method according to any one of Examples 67 to 80.

[0287] Example 124 includes a user equipment (UE) as described and shown in the specification.

[0288] Example 125 includes an access node (AN) as described and shown in the specification.

[0289] Example 126 includes a policy control function (PCF) as described and shown in the specification.

[0290] Example 127 includes a method performed at a user equipment (UE) as described and shown in the specification.

[0291] Example 128 includes a method performed at an access node (AN) as described and shown in the specification.

[0292] Example 129 includes a method performed at a policy control function (PCF) as described and shown in the specification.

[0293] Although certain embodiments have been illustrated and described herein for purposes of description, various alternative and / or equivalent embodiments or implementations planned for the same purpose 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. Accordingly, it is readily understood that the embodiments described herein are limited only by the appended claims and their equivalent scope.

Claims

1. An apparatus for a user equipment (UE), the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is configured to: determine PC5 QoS parameters for the UE based on the mapping and the V2X service type of the UE; and perform V2X communication based on the PC5 QoS parameters for the UE, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

2. The device according to claim 1, wherein, The V2X service type of the UE is indicated by a provider service identifier (PSID) or an intelligent transportation system (ITS) application identifier (ITS-AID).

3. The device according to claim 1 or 2, wherein, The PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

4. The apparatus according to claim 3, wherein, The PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a latency-critical GBR QoS flow.

5. The device according to claim 1, wherein The processor circuit is configured to: generate a UE policy configuration request for the V2X policy / parameter information and cause the UE policy configuration request to be sent to the 5GC, and wherein the message is sent from the 5GC in response to the UE policy configuration request.

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

7. The apparatus according to claim 1, wherein The RF interface is configured to receive the message from a policy control function (PCF) of the 5GC via an access and mobility management function (AMF) of the 5GC.

8. An apparatus for an access node (AN), the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between V2X service types and PC5 quality of service (QoS) parameters, and wherein the processor circuit is configured to: determine PC5 QoS parameters for a user equipment (UE) based on the mapping; and schedule PC5 radio resources for V2X communication of the UE based on the PC5 QoS parameters for the UE, wherein the mapping between the V2X service types and the PC5 QoS parameters is differentiated for unicast, multicast, and broadcast.

9. The apparatus according to claim 8, wherein, If all V2X service types in the mapping are indicated by a common character, the PC5 QoS parameters in the mapping are common for all V2X service types.

10. The apparatus according to claim 8, wherein, The PC5 QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

11. The apparatus according to claim 10, wherein, The PC5 QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a latency-critical GBR QoS flow.

12. The apparatus according to claim 8, wherein, The message is sent from the 5GC in response to the 5GC receiving a UE policy configuration request for the V2X policy / parameter information from the UE.

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

14. The device according to claim 8, wherein, The RF interface is used to receive the message from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

15. The apparatus according to any one of claims 8 to 14, wherein The AN includes a next-generation NodeB (gNB).

16. An apparatus for an access node (AN), the apparatus comprising: a radio frequency (RF) interface; and a processor circuit coupled to the RF interface, wherein the RF interface is configured to: receive 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, wherein the V2X policy / parameter information includes a mapping between a destination layer 2 ID and a sidelink quality of service (QoS) parameter, and wherein the processor circuit is configured to: determine sidelink QoS parameters for a user equipment (UE) based on the mapping; and schedule sidelink radio resources for V2X communication of the UE based on the sidelink QoS parameters for the UE, wherein the mapping between the destination layer 2 ID and the sidelink QoS parameter is differentiated for unicast, multicast, and broadcast.

17. The apparatus according to claim 16, wherein, The mapping between the destination layer 2 ID and the sidelink QoS parameter includes: a mapping between a default destination layer 2 ID for initial unicast signaling and the sidelink QoS parameter for unicast; a mapping between the destination layer 2 ID and the sidelink QoS parameter for multicast; or a mapping between the destination layer 2 ID and the sidelink QoS parameter for broadcast.

18. The apparatus according to claim 16, wherein, If all destination layer 2 IDs in the mapping are indicated by a common character, the sidelink QoS parameters in the mapping are common for all destination layer 2 IDs.

19. The apparatus according to claim 16, wherein The sidelink QoS parameters for the UE include a PC5 5G QoS identifier (PQI).

20. The apparatus according to claim 19, wherein, The sidelink QoS parameters for the UE further include: a guaranteed flow bit rate (GFBR) and a maximum flow bit rate (MFBR) for a guaranteed bit rate (GBR) QoS flow; and a GFBR and an MFBR for a latency-critical GBR QoS flow.

21. The apparatus according to claim 16, wherein The message is sent from the 5GC in response to a UE policy configuration request for the V2X policy / parameter information received by the 5GC from the UE.

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

23. The device according to any one of claims 16 to 22, wherein, The RF interface is used to receive the message from the policy control function (PCF) of the 5GC via the access and mobility management function (AMF) of the 5GC.

Images