New Radio Vehicle Sidelink Discovery

Abstract

The present disclosure relates to new radio vehicle sidelink discovery. The discoverer user equipment sends a discovery announcement to the discovered user equipment via the sidelink service. The announcement includes criteria for the services sought by the discoverer. The discovered party evaluates the announcement and can respond to the discoverer. The discovery announcement can be a target search discovery announcement or a self-advertising discovery announcement, and can be unicast, multicast or broadcast. The discoverer and the discovered party can be synchronized to support V2X sidelink communication, and driving information related to the vehicles associated with the discoverer and the discovered party, such as driving intention, positioning and environmental information, can be collected. The discoverer can request authorization for the discovery announcement, and the request may include driving information. The information in the announcement and response may include the discoverer and the discovered party services, platform and radio capabilities, source identifiers, driving information, radio measurements, group identifiers, and protocol configuration parameters.

Description

[0001] This application is a divisional application of the invention patent application with application date of October 31, 2019, application number 201980071801.8, and titled “New Radio Vehicle Sidelink Discovery”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Application No. 62 / 753,757 filed on October 31, 2018 and U.S. Provisional Application No. 62 / 805,027 filed on February 13, 2019, both of which are entitled “Radio Vehicle Sidelink Discovery,” the contents of which are incorporated herein by reference in their entirety. Background Art

[0004] The present disclosure relates to vehicle sidelink radio communications, such as vehicle sidelink radio communications described in the following documents: 3GPP TR 22.886, Study on enhancement of 3GPP Support for 5G V2X Services; (Release 15), V15.1.0; 3GPP TS22.186, Enhancement of 3GPP support for V2X scenarios; Stage 1 (Release 15), V16.0.0; 3GPP TR 23.734, Study on enhancement of 5GS for Vertical and LAN Services; (Release 16), V16.0.0; 3GPP TS23.286, Application layer support for V2X services; Functional architecture and information flows; (Release 16), V0.3.0; and 3GPP TS23.502, Procedures for the 5G System; Stage 2; (Release 15), V15.4.1. Summary of the invention

[0005] The present disclosure describes, inter alia: provision of V2X discovery; group management and discovery control at the V2X upper layer; group management and discovery control at the AS layer; and L23 radio configuration supporting V2X discovery and V2X data transmission.

[0006] The self-advertising discovery model may include the option for a monitoring V2X UE to autonomously choose to initiate V2X communication with an announcing UE, or to join a group to which the announcing UE belongs and establish groupcast or multicast communication with the announcing UE without first matching the report with a V2X control function or other network entity.

[0007] The target search discovery model may include a discovering UE or a target search announcing UE, which may send specific information of interest to the discovered UE, but may also send information about the discovering UE.

[0008] Triggers can be used for self-advertising announcements, target search announcements, or responses to discovery messages.

[0009] The rules for mapping discovery messages to PSDCH or PSSCH based on discovery message size or discovery message type may be used for, for example, periodic and non-periodic discovery message waiting time requirements, discovery message reliability requirements, discovery message sending range requirements, or discovery message receiving range requirements.

[0010] The content of the discovery message can be customized to help the sender or receiver decide whether subsequent V2X communication should be based on unicast, multicast or broadcast.

[0011] The MAC sublayer configuration may be adjusted for discovery, for example, to support mapping of discovery messages to PSDCH, PSSCH, or PSMCH. The format and parameters of the PDU may be adjusted for SL-DCH data transmission / reception.

[0012] The Summary of the Invention section is provided to introduce in simplified form some concepts that are further described below in the Detailed Description section. The Summary of the Invention section is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all deficiencies mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings.

[0014] Figure 1 Illustrate an example PC5 interface for sidelink discovery.

[0015] Figure 2A and Figure 2B A call flow showing the first part of an exemplary V2X service provisioning and authorization.

[0016] Figure 3 FIG. 4 is a call flow diagram showing the second part of an exemplary V2X service provisioning and authorization.

[0017] Figure 4A and Figure 4B FIG. 10 is a call flow showing the second part of an example request for V2X self advertisement discovery announcement - in coverage.

[0018] Figure 5 FIG. 10 is a call flow showing the second part of an example request for V2X self advertisement discovery announcement - out of coverage.

[0019] Fig. 6A and Figure 6B Call flow for the second part of an example request showing a response to a V2X self advertisement discovery announcement - In Coverage.

[0020] Figure 7 A call flow showing an example request for a response to a V2X self advertisement discovery announcement - out of coverage.

[0021] Fig. 8A and Figure 8B Illustration of the call flow for an example request or response request for V2X target search discovery announcement - within coverage.

[0022] Fig. 9 Illustration of the call flow for an example request or response request for V2X Target Search Discovery Announcement - Out of Coverage.

[0023] Fig. 10A and Fig. 10B Shows the call flow for an example announcement of self-advertisement discovery via sidelink.

[0024] Fig.11A and Fig. 11B Represents the call flow for an example announcement of a target search discovery via a sidelink.

[0025] Fig. 12A and Fig. 12B A call flow showing an example response to a target search discovery via a sidelink.

[0026] Fig.13 is a flow chart of an example overview of sidelink transmit radio configuration for V2X discovery messaging.

[0027] Fig.14 is a flow chart of an example overview of a sidelink receive radio configuration for V2X discovery message reception.

[0028] Fig.15 The diagram illustrates an example MAC structure overview for the sidelink (SDCCH mapped to SL-DCH).

[0029] Fig.16The diagram illustrates an example sidelink channel mapping (SL-DCH mapped to PSDCH).

[0030] Fig.17 The diagram illustrates an example MAC structure overview for the sidelink (SDCCH mapped to SL-SCH).

[0031] Fig.18 The diagram illustrates an example sidelink channel mapping (SL-SCH mapped to PSSCH).

[0032] Fig.19 The diagram illustrates an example sidelink channel mapping (SL-DCH mapped to PSSCH).

[0033] Fig. 20 The diagram illustrates an example MAC structure overview for the sidelink (SDCCH mapped to SL-MCH).

[0034] Fig.21 The diagram illustrates an example MAC structure overview for the sidelink (SL-MCH mapped to PSMCH).

[0035] Fig. 22 Illustrate exemplary SL-DCH MAC sub-headers with different DST field lengths.

[0036] Fig.23 Illustrate exemplary SL-DCH MAC subheaders with different numbers of DST fields.

[0037] Fig.24 Illustration of an example of an R / R / E / LCID / F / L MAC subheader.

[0038] Fig.25 Illustration of an example of an R / R / E / LCID / F / L / QOS / CAP MAC subheader.

[0039] Fig.26 Illustration of an example of an R / R / E / LCID / F / L / QOS / CAP / DST MAC subheader.

[0040] Fig. 27 The diagram illustrates an exemplary MAC PDU (option 1) including a MAC header, a MAC SDU and optional padding.

[0041] Fig.28 The diagram illustrates another exemplary MAC PDU (Option 2) including a MAC header, a MAC SDU and optional padding.

[0042] Fig.29AAn exemplary communication system 100 is illustrated in which the methods and apparatus described and claimed herein may be embodied.

[0043] Fig.29B is a block diagram of an exemplary device or apparatus configured for wireless communication in accordance with the embodiments illustrated herein.

[0044] Fig.29C is a system diagram of an exemplary radio access network and a core network.

[0045] Fig.29D is another exemplary system diagram of a radio access network and a core network.

[0046] Fig.29E is a system diagram of a radio access network and a core network of a third example.

[0047] Fig.29F It can be concretely manifested Figures 29A-29E A block diagram of an example computing system of one or more devices of a communication network is illustrated in FIG.

[0048] Figure 29G An exemplary communication system is illustrated in which the methods and apparatus described and claimed herein may be embodied. DETAILED DESCRIPTION

[0049] The term "process" generally refers to a method of performing operations to achieve a purpose. The term "process" is used instead of "method" to avoid confusion with the special meaning of the term "method" in the context of M2M and IoT applications. The steps described with respect to a process are generally optional and may be performed in various ways and in various orders. Thus, in this document, the term "process" should not be interpreted as referring to a strict set of a series of steps, but rather should be interpreted as a general method for obtaining a result that can be adjusted in various ways.

[0050] Many of the acronyms used in this article are recorded in Table 1 in the Appendix.

[0051] Discovery in LTE D2D Sidelink

[0052] In LTE, D2D sidelink discovery is defined as a process used by a UE supporting sidelink discovery to discover other UEs in its vicinity using E-UTRA direct radio signals via PC5. Sidelink discovery is supported both when the UE is served by E-UTRAN and when the UE is out of E-UTRA coverage. There are two types of D2D sidelink direct discovery: open and restricted. Open discovery occurs without requiring explicit permission from the UE being discovered, while restricted discovery occurs only with explicit permission from the UE being discovered.

[0053] ProSe direct discovery can be a standalone service enabler, for example, it can use the information from the discovered UEs for certain applications in the UE that are allowed to use the information (e.g., "find a taxi nearby", "find a coffee shop"). In addition, depending on the information obtained, ProSe direct discovery can be used for subsequent actions, such as initiating ProSe direct communication. ProSe direct discovery can also be used for public safety purposes, mainly involving UE-to-network relay discovery functions and determination of UEs capable of ProSe communication within communication range (e.g., "group member discovery").

[0054] Two discovery models are defined in LTE; Discovery Model A and Discovery Model B. Model A defines two roles for participating UEs; a declaring UE, which announces certain information that can be used by neighboring UEs with discovery permission, and a monitoring UE, which monitors certain information of interest to neighboring declaring UEs. In this model, the declaring UE broadcasts discovery messages at pre-defined discovery intervals, and the monitoring UEs interested in these messages read and process the messages. In this model, the declaring UE broadcasts information about itself, announcing its presence ("I am here") and the services it provides. Model A supports both open and restricted discovery types.

[0055] Discovery Model B also defines two roles for participating UEs; a discoverer UE, which sends a request containing some information about what it wants to discover and whether the discovered UE can provide certain services, and a discovered UE, which receives the request message and can respond with some information related to the discoverer's request. Since the discoverer UE sends information about other UEs, this model can be summarized as "who is there" or "are you there". Model B only supports restricted discovery types.

[0056] The upper layers above the access layer handle the declaration of discovery messages and the authorization of monitoring. The content of the discovery message is transparent to the access layer (AS), and there is no distinction in the AS for the sidelink discovery model and the sidelink discovery type. However, the upper layer notifies whether the sidelink discovery declaration is related to public safety discovery or non-public safety discovery. The upper layer also notifies whether the discovery declaration / monitoring is related to ProSe UE to network relay discovery or other public safety discovery. For synchronization, the UE participating in the declaration of the discovery message can act as a synchronization source by sending SBCCH and synchronization signals based on the resource information of the synchronization signal provided in SIB19. Figure 1The control plane protocol stack on the direct link PC5 interface for discovery is illustrated in FIG. The MAC layer receives discovery messages (ProSe protocol) from the upper layer. The IP layer is not used to send discovery messages. There are two types of resource allocations for discovery message announcements; UE autonomous resource selection and network scheduled resource allocation. In either scheme, the MAC layer determines the radio resources used to announce the discovery message received from the upper layer. The MAC layer establishes a MAC PDU carrying the discovery message and sends the MAC PDU to the physical layer for transmission in the determined radio resources. No MAC header is added. The transmission is connectionless and broadcast-based.

[0057] The discovery process is used to identify a specific UE in order to initiate a one-to-one communication, or to identify a specific group of UEs in order to initiate a one-to-many communication. Prior to the one-to-many sidelink communication, the UE does not establish and maintain a logical connection with the receiving UE. The upper layer establishes and maintains a logical connection for one-to-one sidelink communication, including ProSe UE to network relay operations.

[0058] The source layer 2 ID and the destination layer 2 ID can be used for sidelink communication and V2X sidelink communication. The source layer 2 ID identifies the sender of data in the sidelink communication and V2X sidelink communication. The source layer 2 ID is 24 bits long and is used together with the destination layer 2 ID and LCID to identify the RLC UM entity and PDCP entity in the receiver.

[0059] The destination layer 2 ID identifies the destination of the data in sidelink communications and V2X sidelink communications. For sidelink (non-V2X) communications, the destination layer 2 ID is 24 bits long and is split into two bit strings at the MAC layer. One bit string is the LSB part (8 bits) of the destination layer 2 ID and is forwarded to the physical layer as the group destination ID. This bit string identifies the destination of the intended data in the sidelink control information and is used for filtering of packets at the physical layer. The second bit string is the MSB part (16 bits) of the destination layer 2 ID and is carried within the MAC header. The second bit string is used for filtering of packets at the MAC layer.

[0060] For V2X sidelink communications, the destination Layer 2 ID is not split and is carried within the MAC header.

[0061] Non-access stratum signaling is required for group formation and configuration of source layer 2ID, destination layer 2ID and group destination ID in the UE. These identifiers are either provided by the upper layer or derived from identifiers provided by the upper layer. In the case of multicast and broadcast, in the MAC layer, the ProSe UE ID provided by the upper layer is directly used as the source layer 2ID, and the ProSe layer 2 group ID provided by the upper layer is directly used as the destination layer 2ID. In the case of one-to-one communication, in the MAC layer, the ProSe UE ID provided by the upper layer is directly used as the source layer 2ID or the destination layer 2ID. In the case of V2X sidelink communication, the upper layer provides the source layer 2ID and the destination layer 2ID.

[0062] Discovery in NR V2X Sidelink

[0063] SA1 has identified four main groups of advanced V2X use cases: vehicle formation; extended sensors; advanced driving and remote driving. See 3GPP TR 22.886, Study on enhancement of 3GPP Support for 5G V2X Services; (Release 15), V15.1.0, and 3GPP TS 22.186, Enhancement of 3GPP support for V2X scenarios; Stage 1 (Release 15), V16.0.0.

[0064] Vehicle platooning enables vehicles to dynamically form groups that travel together. All vehicles in the platoon receive periodic data from the lead vehicle in order to operate in platooning. This information allows the distance between vehicles to become very small (e.g., the gap distance converted into time can be very small (sub-second)). Platooning applications can allow the following vehicles to drive autonomously.

[0065] Extended sensors enable the exchange of raw or processed data or real-time video data collected by local sensors between vehicles, RSUs, pedestrians’ devices and V2X application servers. Vehicles can enhance their perception of the surrounding environment beyond the range that their own sensors can detect and have a more comprehensive view of local conditions. High data rate is one of the key features.

[0066] Advanced driving enables semi-autonomous or fully autonomous driving. It is assumed that the distance between vehicles is large. Each vehicle and / or RSU shares data obtained from its local sensors with neighboring vehicles, allowing vehicles to coordinate their trajectories or maneuvers. In addition, each vehicle shares its driving intentions with neighboring vehicles. The benefits of this set of use cases are safer driving, collision avoidance, and improved traffic efficiency.

[0067] Remote driving enables remote drivers or V2X applications to operate a remote vehicle for passengers who cannot drive themselves, or to operate a remote vehicle located in a hazardous environment. For situations where changes are limited and routes are predictable, such as public transportation, cloud-based driving can be used. The main requirements are high reliability and low latency.

[0068] Each of the above use case groups may require a specific set of UEs; some form of discovery of formation leader UEs, relay UEs, or UEs with specific V2X applications or capabilities. It is believed that the 3GPP system can enable discovery of UEs supporting the same V2X application and communication between the UEs. For example, consider dynamic carpooling, a use case that enables vehicles to advertise their willingness to share capacity with other road users and enables pedestrians to indicate their intention to participate in carpooling. This type of discovery is not type critical. UEs supporting V2X applications will be able to establish direct unicast communications with other such UEs based on the discovery results. Similarly, the 3GPP system can enable UEs supporting V2X applications to discover other UEs supporting V2X applications that can provide access to the network. For example, consider network sharing (tethering) via vehicles, a use case that enables vehicles to provide network access to occupants, pedestrians, etc. Another use case that enables access to the network is the relay UE scenario. We expect that this type of discovery is not time critical.

[0069] Regarding vehicle platooning requirements, the following discovery-related use cases can be considered. Platoon discovery by vehicles that want to join the platoon; this type of discovery is not time-critical. Platoon discovery by other vehicles that are outside the platoon and do not want to join the platoon. When a platoon is formed and operating, vehicles that are not part of the platoon should be aware of the existence of the platoon, otherwise the vehicle may move into the platoon and disrupt the operation of the platoon. Thus, other vehicles outside the communication range between vehicles in the same platoon should be aware of the platoon. This form of discovery may not be time-critical. In addition, within a platoon, for a group of UEs supporting V2X applications, grouping of up to 5 UEs can be supported, implying the need to support platoon sub-group discovery. In addition, for vehicle platooning, reliable V2V communication between a specific UE supporting V2X applications and up to 19 other UEs supporting V2X applications can be supported, so that the UE can support platoon leader discovery. This discovery may not be time-critical. Discovery of changes in platoon leaders for existing platoons by platoon member UEs can also be supported. We expect that this discovery may be time-critical.

[0070] Another example of a discovery use case involves automated cooperative driving, collective sensing of the environment, and cooperative collision avoidance. Cooperative driving allows a group of vehicles to communicate automatically to enable lane changes, merging, overtaking between vehicles in the group, and inclusion / removal of vehicles in the group to improve safety and fuel economy. In terms of cooperative sensing of the environment, vehicles can exchange real-time information with each other in adjacent areas (based on vehicle sensor information or sensor data from enabled UE-type RSUs). Both traffic types (periodic and event-driven) can exist simultaneously. Discovery of surrounding vehicles and their intentions is then required. These use cases may require fast discovery (e.g., time-critical discovery).

[0071] In NR, discovery can be periodic or event-based. As in LTE, NR discovery can be model A-based discovery or model B-based discovery. Similarly, as in LTE, NR discovery can be open discovery or restricted discovery. RAN2 has started discussing NR V2X, and it is expected that a typical overall NR V2X communication step may consist of the following steps: V2X sidelink synchronization, V2X sidelink discovery, V2X session establishment, V2X radio configuration, V2X sidelink transmission, and V2X session release.

[0072] Identifying network slices

[0073] Network slices are identified by S-NSSAI (Single Network Slice Selection Assistance Information). S-NSSAI consists of Slice / Service Type (SST) and Slice Discriminator (SD).

[0074] NSSAI is a collection of S-NSSAI. There are three types of NSSAI.

[0075] The configured NSSAI is the NSSAI that the UE is configured to use. In each PLMN, the UE may have a different configured NSSAI. The configuration may include instructions on how to map the configured NSSAI to the HPLMN configured NSSAI. The requested NSSAI is provided by the UE to the network upon registration. The network will use it to determine which network nodes should serve the UE and which network slices the UE should be allowed to connect to.

[0076] When registration is complete, the network provides the UE with the allowed NSSAI, which is a list of slices that the UE is allowed to access.

[0077] Non-public network

[0078] 3GPP TR 23.734, Study on enhancement of 5GS for Vertical and LAN Services (Release 16), V16.0.0 introduces the concept of non-public networks in 5G.

[0079] A non-public network is a network used for non-public purposes. A non-public network ID (NPN-ID) identifies a non-public network. NPN-IDs support two assignment models. Locally managed NPN-IDs are assumed to be randomly selected at deployment time to avoid conflicts (and thus may not be unique in all cases). Globally managed NPN-IDs are managed by a central entity and thus are considered unique.

[0080] The gNB broadcasts the NPN-ID in the SIB to identify the non-public network to which the cell provides access.

[0081] Closed Access Group

[0082] A cell may only be accessible to certain groups of UEs. A group of UEs that can access the cell is called a closed access group (CAG). The SIB includes a CAG indication that identifies the cell as a closed access group cell. The SIB also includes a CAG ID that indicates which CAGs can access the cell.

[0083] Terminology and use cases

[0084] The UE may interact with a V2X application server. The UE may interact with more than one V2X application server. For example, the UE may interact with a local V2X application server that is geographically close to the UE and associated with a particular geographic area, and a second V2X application server associated with a second geographic area. For example, the UE may interact with a V2X application server associated with a particular portion of a road, and a second V2X application server associated with the entire PLMN. The geographic area may be identified by a GEO ID.

[0085] The upper layer application in the UE can communicate with the V2X application server. The concepts disclosed in this article can also be applied to various scenarios, such as: interaction between a V2X application-specific client and a V2X application-specific server; interaction between a V2X application enablement client and a V2X application enablement server; interaction between a location management client and a location management server; interaction between a group management client and a group management server; interaction between a configuration management client and a configuration management server; interaction between an identity management client and an identity management server; interaction between a key management client and a key management server; and interaction between a network resource management client and a network resource management server.

[0086] V2X services may be identified using a V2X service identifier (V2X service ID) as defined in 3GPP TS 23.286, Application layer support for V2X services; Functional architecture and information flows; (Release 16), V0.3.0.

[0087] The V2X Group ID is defined in reference TS23.286 as "a globally unique identifier within a V2X service that represents a group of V2X users and corresponding V2X UEs. The group of V2X users may belong to the same or different V2X service providers. It indicates the V2X application server that defines the group".

[0088] Example Challenge

[0089] In order to enable unicast and multicast communications, it is necessary to define procedures that allow UEs to discover other UEs in the vicinity that are interested in the same V2X service and willing to share something. As also discussed in the background, in LTE Sidelink (SL) V2X and LTE D2D, the RAN protocol is mainly designed with broadcast type services, including D2D neighbor discovery, in mind. As a result, there is actually no discovery procedure designed at the RAN layer to help discover UE pairs or UE groups or group leaders (e.g., fleet leaders).

[0090] The impact of the RAN in supporting LTE D2D ProSe discovery is quite limited, because the content of the discovery message is transparent to the AS layer, and there is no different processing in the AS for the two discovery models mentioned above. The discovery message is delivered in a MAC PDU consisting of only a MAC SDU without a header and with a fixed TBS of 232 bits. The UE is provided with a link layer L2 identity, such as a layer 2 address, by the upper layer for future sidelink communications.

[0091] Group management and discovery at the upper layer (above the AS)

[0092] Assuming that group management and discovery are performed at the upper layers, given the higher complexity of the V2X architecture compared to the ProSe architecture, and most importantly the advanced NR V2X requirements in terms of QoS and radio capabilities, enhancements are required to help the upper layers establish unicast / multicast communications. For example, a UE is interested in discovering other UEs at the application layer, but if the radio layer characteristics at the UE do not meet the QoS requirements of the possible connection or the established connection (e.g., communication range), or if the UE capabilities of the UE do not match the possible unicast / multicast communication, then there is no point in establishing such a connection. Consider the case where the upper layers of the UE broadcast information about the services of interest, upper layer UE identities, etc. to nearby UEs to identify nearby interested receiver UEs. Upon identifying the interested receivers for unicast and multicast sidelink communications, the interested UEs can exchange radio related information required to establish unicast and multicast sidelink communications and meet the desired QoS performance. Information is exchanged between the AS and the upper layers to help select a target UE or a group of target UEs among a group of discovered candidate UEs or a group of discovered candidate UEs, and a solution for such information exchange needs to be designed. A solution needs to be designed as to which layer selects a UE from a set of discovered candidate UEs, or which layer selects a group of UEs from a set of discovered UE candidates. In addition, triggers and rules for group formation, group disbanding, election of group leader (e.g., fleet leader), change of group leader, and discovery of such events by group members need to be considered.

[0093] Group management and discovery at the access layer

[0094] In D2D, group communication is supported and group management is handled in the application layer. The ProSe layer 2 group ID is included in the sidelink MAC subheader in each packet as a destination ID. The ProSe layer 2 group ID is pre-configured in the UE or provided from the ProSe function via the PC3 interface.

[0095] For vehicle platooning, vehicles in the same platoon share the necessary information required to support platoon operation (e.g., distance between vehicles, relative speed, updates from RSU, etc.). When vehicles are driving on the road, they are able to dynamically form a platoon. The platoon manager is responsible for platoon management. The manager should update the surrounding traffic data reported by group members in real time and report it to the RSU. At the same time, the platoon manager should receive RSU messages including road conditions and traffic information far away from its location in real time, and share the RSU messages with platoon members. All platoon members can also share information within the group through V2V. It can be seen that in NRV2X, it seems that the V2X communication group is dynamically formed by nearby vehicle UEs (e.g., with the same direction, speed or destination). And one of the vehicle UEs in the group acts as a group manager, which reports the traffic data reported by the group members to the RSU, and receives messages from the RSU and relays the messages to the group members. In ProSe D2D, although the formation of the group is also based on proximity, it is less dynamic because it does not involve moving UEs that may appear or disappear in a much more dynamic way. Since the dynamics of group formation and dissolution are much faster than ProSe D2D, group management handled in the AS layer can also be considered as an alternative to group management above the AS layer.

[0096] V2X radio configuration

[0097] The discovery process is used to identify a specific UE in order to initiate one-to-one communication, or to identify a specific UE group in order to initiate one-to-many communication. Once the UE or UE group of interest is discovered, access layer resources, including radio channels and protocol stack resources, need to be configured to support the communication. Although upper layers above the access layer can indicate QoS related information to the access layer and whether the communication should be unicast, multicast or broadcast, access layer specific rules and standards may need to be designed when deciding whether the communication should be conducted connectionlessly or in a connection-oriented manner.

[0098] The discovery models available for V2X include self-advertisement discovery and target search discovery.

[0099] Self-advertising discovery is similar to LTE D2D sidelink Model A discovery, and defines two roles for participating UEs; an announcing UE, which advertises information about itself, such as its service capabilities, including its service offerings, supported V2X applications, its group membership, etc., and information that can be used by neighboring UEs with discovery permission, and a monitoring UE, which monitors neighboring announcing UEs for certain information of interest, such as the presence of a fleet leader, the presence of UEs or UE groups with specific V2X service capabilities and service offerings or V2X applications. In this model, it is also proposed that a monitoring UE with the correct authorization credentials may also autonomously choose to respond to the announcing UE, or may autonomously choose to initiate V2X communications to the announcing UE or join the group to which the announcing UE belongs, and establish groupcast or multicast communications to the announcing UE without first matching the report with the V2X control function or other network entities.

[0100] In this model, the announcement UE sends discovery messages every pre-defined discovery interval, or in an event-based aperiodic manner. Discovery messages can be sent in unicast, groupcast, or multicast manner (for example, if the UE is already part of a group, the UE can multicast a self-advertisement discovery message to other UEs in the group). The self-advertisement discovery model supports both open discovery types and restricted discovery types.

[0101] Target discovery is similar to LTE D2D sidelink Model B discovery and also defines two roles for participating UEs; a discoverer UE or target search announcing UE, which sends a request containing some information about what it wants to discover and whether the discovered UE can provide certain services (such as interested V2X applications, interested groups, service capabilities, service platform capabilities, radio capabilities), and a discovered UE, which receives the request message and can respond with some information related to the discoverer's request. The target search announcing UE can also advertise the information about itself and the search information described above for the self-advertising discovery model. The discovered party or target search monitoring UE can respond with information about itself, such as supported V2X applications, interested groups, service capabilities, service platform capabilities, radio capabilities, etc. In this model, the announcing UE can also send discovery messages every pre-defined discovery interval, or in an event-based aperiodic manner. The discovery message can be sent in a unicast, groupcast or multicast manner (for example, if the UE is already part of a group, the UE can multicast the target search discovery message to other UEs in the group). The restricted discovery type is the discovery type primarily supported by the self-advertising discovery model. However, this model may also support an open discovery type. For example, if the target search is for a UE that is already part of a group that the announced UE has joined and is part of, then the target search for members of the group may not necessarily need to be a restricted target search. The UE involved in this V2X discovery model may be a fleet leader UE, a group leader, or any UE or UE group, such as a UE with specific capabilities, whether the specific capabilities are application or service layer capabilities, network layer capabilities or transport capabilities, including radio capabilities.

[0102] In this disclosure, we will use NAS, V2X NAS, V2X upper layer and V2X higher layer interchangeably. The terms NB, eNB and gNB will also be used interchangeably.

[0103] Provision of V2X discovery and V2X communication

[0104] Figure 2A , 2BExamples of V2X provisioning procedures that can be used to configure UEs, V2X communication policies and configuration parameters, in particular V2X discovery policies and configuration parameters, are described in and 3. Few architectural options are proposed. In one option, the discovery policy is provided to the UE via a user plane bearer. In another alternative, the discovery policy can be provided to the UE via a control plane bearer. The two configuration methods can coexist in the UE. The UE can negotiate with the network which provisioning method to use. Such negotiation may require the UE to signal the network to notify the UE of its capabilities, and the network to signal the UE of its capabilities. Depending on the capabilities of the UE, V2X communications (e.g., V2X discovery policies and configuration parameters) can be provided to the UE using only a user plane bearer or a control plane bearer, or using both a user plane bearer and a control plane bearer (e.g., a UE that is only within Wi-Fi coverage can only be provided with V2X parameters by the network via the user plane, while a UE that is within cellular network coverage can be provided via the user plane or via the control plane). Examples of V2X policy configuration may include one or more of the following: a list of authorized PLMNs and validity timers for V2X discovery self-advertisement declarations; a list of authorized PLMNs and validity timers for monitoring of V2X discovery self-advertisements; a list of authorized connection types (e.g., GSM, E-UTRAN, NR, Wi-Fi) and validity timers; a list of authorized PLMNs and validity timers for V2X restricted discovery self-advertisement declarations; a list of authorized PLMNs and validity timers for restricted monitoring of V2X discovery self-advertisements; a list of authorized PLMNs and validity timers for V2X restricted discovery target search declarations; a list of authorized PLMNs and validity timers for restricted monitoring of V2X target search declarations; a list of authorized PLMNs and validity timers for responses to V2X restricted discovery target search declarations; a list of authorized PLMNs and validity timers for monitoring responses to restricted V2X target search declarations.

[0105] Examples of other discovery configuration parameters may include one or more of the following: group parameters; group member discovery parameters; fleet leader discovery parameters; group leader discovery parameters; discovery capability parameters; platform capability parameters; supported application parameters; discovery message to QoS mapping parameters; discovery frequency carrier configuration and mapping to discovery messages; frequency carrier to QoS (e.g., PPPP and PPPR) mapping parameters; resource pool configuration for out-of-coverage use, geographic validity area, and mapping to discovery messages; allowed RATs and mapping to discovery messages; allowed transmit profiles and mapping to discovery messages; allowed receive profiles and mapping to discovery messages; allowed subcarrier spacing and mapping to discovery messages; allowed BWP and mapping to discovery messages; and discovery message priority bit rate and mapping to discovery messages.

[0106] Provision of V2X discovery and V2X communication

[0107] As in Figure 2A As shown in step 4 of , the expiration of the validity period may trigger the UE to send a request for V2X configuration parameters to the network. However, other events in the UE may also trigger the UE to send a request for V2X configuration parameters to the network.

[0108] For example, alternatively, many events may occur in step 4, such as: the UE detects that it is leaving or entering a geographic area; the UE detects that the quality of the connection to the local V2X application server is deteriorating or is about to deteriorate based on the UE's planned route; the UE detects that the NPN is within range (e.g., reception of the NPN-ID in the SIB); the UE detects the CAG ID in the SIB; the UE connects to the NPN; and a user of the UE enters information in a GUI associated with the UE (e.g., using the GUI to indicate a new driver).

[0109] When a triggering event occurs and the UE is configured to use the user plane embodiment, step 5 will occur and the Figure 2A User plane embodiment of. Step 5 may represent a configuration management client on the UE, and a V2X UE configuration request may be issued. The request may include a V2X UE ID, and may also include various information, such as: a geographic area identifier (GEO ID); a list of NPN IDs detected as visible to the UE (e.g., NPN IDs detected in the SIB); an identification of the NPN to which the UE is connected; a CAG ID associated with the UE's NPN connection; a user identification identifying a driver or controller of the vehicle, such as a user identification provided via a GUI; a V2X service ID for a service that the UE desires to use; and a V2X group ID representing users associated with the UE.

[0110] In a user plane embodiment, step 5 may be issued via an IP-based PDU session. The PDU session may have been previously established by the UE on the network slice. The S-NSSAI of the network slice may have an SST value indicating a V2X service, and the DDN associated with the PDU session may have been configured in the UE to communicate with the configuration management server. The message may be addressed to the configuration management server. The configuration management server may authorize the request in step 6 and reply to the configuration management server in step 7. Figure 2A As shown in , the reply of step 7 may include a management object (MO) for configuring the UE for V2X communication. The MO may include various information, such as: the identity of the V2X application server; NPN-ID; CAG-ID; available V2X service ID; and unavailable V2X service ID.

[0111] The MO may be configured to indicate which geographic region the above information is associated with. For example, the MO may be configured to indicate that a specific V2X application server is available in a specific region, that the UE can reach the V2X application server via a specific NPN-ID, and that the UE is part of a specific CAG-ID.

[0112] The reply may also indicate what NSSAI and DDN can be used to reach the service.

[0113] Figure 2A The method in Figure 2B When a triggering event occurs and the UE is configured to use the control plane embodiment, step 9 will occur and will start Figure 2B control plane embodiment. In a control plane embodiment, steps 9, 10 and 11 may represent a NAS (e.g., UE policy provision request) message sent from the UE to the AMF and forwarded by the AMF to the PCF. The request may include the same information elements previously proposed as part of the V2X UE configuration request. When the PCF receives the message, the UE policy delivery procedure of 3GPP TS23.502, Procedures for the 5G System; Stage 2; (Release 15), V15.4.1 will be triggered. The policy delivered to the UE will include the MO described in the previous paragraph.

[0114] Alternatively, the UE's request to the V2X application server may be issued via the user plane, and the V2X application server may trigger the control plane delivery of the policy to the UE by calling the NEF API. The NEF API call may allow the V2X application server to provide the UE ID and policy information to the PCF.

[0115] When receiving an updated MO configuration, the UE shall store and update its V2X configuration, as in Figure 2B as shown in step 17.

[0116] Solutions for group management and discovery at the upper layer

[0117] In this type of solution, the decision on announcing or monitoring a V2X discovery message is controlled by an upper layer above the access stratum (AS). In addition, the decision on requesting authorization to announce a discovery message, monitor a discovery message, or respond to a discovery message is controlled by an upper layer above the AS.

[0118] V2X discovery authorization, announcement & response parameters confirmed

[0119] exist Figure 4A -B and Figure 5Examples of procedures for requesting authorization to advertise self-advertisement discovery messages when in coverage or out of coverage are described in . When the discovery process is triggered by upper layers, the authorization and parameters for the specific instance of discovery that the UE is to participate in may need to be coordinated and confirmed with the network when in coverage, otherwise the fallback default policy and configuration parameters when out of coverage are used.

[0120] In step 1, the policy and configuration parameters for V2X sidelink communication (eg, V2X sidelink discovery self-advertisement) are provided to the UE. The UE is authorized to conduct V2X communication (eg, V2X sidelink discovery self-advertisement).

[0121] In step 2, the UE collects driving intention information, positioning information, and driving environment information through sensors. The UE performs radio measurements. Such measurements may include measurements related to radio quality, such as RSRP and RSSI (for example, in RRC idle or RRC inactive state). In addition, in the connected RRC, the UE can collect measurements such as RSRQ and CQI. The UE can also collect load information and congestion-related information, such as channel busy rate (CBR) or channel occupancy rate (CR). The UE can be configured to collect information including radio measurements as a continuous background process. The information collection including radio measurements can be periodic, with one or more configured time intervals. The UE can also collect event-based information, including radio measurements.

[0122] In step 3, an authorization request for self-advertisement discovery is triggered. Examples of triggers may be one or more of the following: expiration of a validity timer for a policy or configuration parameter; a request from an application; the UE becomes a group leader or fleet leader; the UE ceases to be a group leader or fleet leader; joins a group; leaves a group; a user request or changes a user setting; a change in group size; a maximum group size; the group can no longer accept new members; the group can accept new members, etc.

[0123] In step 4, the upper layer above the AS constructs an authorization request self-advertisement message and submits it to the AS for transmission.

[0124] In step 5, the UE determines that it is within coverage. This may be based on a coverage threshold configuration.

[0125] Steps 6 to 12 include sending requests and responses exchanged between the UE and the network via the control plane or the user plane.

[0126] In step 13, the UE stores the response message in its internal database, including the strategy and parameters discovered by the self-advertisement.

[0127] The steps for authorization request for self-advertisement discovery when out of coverage are similar to those when in coverage. However, the UE does not exchange messages with the network. The V2X NAS layer exchanges stored default configuration parameters with the application layer to support the discovery process.

[0128] Fig. 6A and 6B An example of a process for requesting authorization in response to an announcement of a self-advertisement discovery message when within coverage is described in . Figure 7 An example of when out of coverage is shown in . When a response to a discovery announcement is triggered by upper layers, the authorization and parameters for the specific instance of the discovery response that the UE is to participate in when in coverage may need to be coordinated and confirmed with the network, otherwise the fallback default policy and configuration parameters for when out of coverage are used.

[0129] Fig. 8A and 8B An example of a process for requesting authorization to make a target search discovery announcement when within coverage is described in . Fig. 9 An example of when out of coverage is shown in . When a request for target search discovery announcement is triggered by upper layers, the authorization and parameters for the specific instance of target search discovery that the UE is to participate in when in coverage may need to be coordinated and confirmed with the network, otherwise the fallback default policy and configuration parameters for when out of coverage are used. Fig. 8A -B and Fig. 9 Also used to request authorization in response to a target search discovery announcement message.

[0130] V2X Self-Advertisement Discovery

[0131] Fig. 10A and 10B The diagram illustrates the process of self-advertising discovery announcements over the sidelink interface.

[0132] In step 1a to step 4, the UE involved has performed all necessary steps up to and including completing the authorization of the self-advertisement discovery declaration of the UE sending the discovery message.

[0133] In step 5, a self-advertisement discovery announcement is triggered at the application layer.

[0134] In step 6, the ASs of the possible UEs in the vicinity are configured to monitor the self-advertisement discovery messages. Fig.13 and 14 , describes the radio configuration for monitoring UE.

[0135] In step 10, the V2X NAS may also autonomously trigger a self-advertisement discovery announcement, possibly using assistance information from the application layer.

[0136] In step 13, the AS configures the radio for sending self-advertisement discovery messages. Fig.14 , describes a radio configuration for sending self-advertisement discovery messages.

[0137] In step 16 and step 18, the filtering of the discovered declaring UEs may be performed in the AS layer or in the V2X upper layer function (eg, V2X NAS). Fig.14 , describes examples of parameters used for filtering.

[0138] V2X target search and discovery

[0139] Fig.11A and 11B The process of target search discovery announcement via the sidelink interface is illustrated in FIG. The main steps are similar to the steps of self-advertisement discovery via the sidelink. Fig.14 , describes the details of the sending radio configuration and receiving radio configuration for target search discovery announcement.

[0140] Fig. 12A and 12B The diagram in FIG illustrates the process of responding to a target search discovery announcement over a sidelink interface.

[0141] In step 1a to step 4, the UE involved has performed all necessary steps up to and including completing the authorization for the UE responding to the self-advertisement discovery message to respond to the target search self-discovery announcement.

[0142] In step 5, a response target search discovery announcement is triggered at the application layer.

[0143] In step 6, the AS of the discovering UE that sent the target search discovery announcement configures its receiver radio to monitor the discovery response message from the discovered UE. Fig.13 and 14 , describes a radio configuration for monitoring responses to discovery messages.

[0144] In step 10, the V2X NAS may also autonomously trigger a response to the target search discovery announcement, possibly using assistance information from the application layer.

[0145] In step 13, the AS of the discovered UE configures its transmitting radio to send a response to the target search discovery message. Fig.14 , describes a radio configuration for sending a response to a target search discovery message.

[0146] In step 16 and step 18, the filtering of the discovered UE may be performed in the AS layer or in the V2X upper layer function (eg, V2X NAS). Fig.14 , describes examples of parameters used for filtering.

[0147] Solutions for group management and discovery in the access layer

[0148] For group management and discovery in the access stratum, the decision on the announcement or monitoring of V2X discovery messages is controlled by the access stratum (AS). In addition, the decision on requesting authorization to announce a discovery message, monitor for a discovery message, or respond to a discovery message is controlled by the AS. This may be the case for V2X groups that are formed and UEs that join and leave the group are very dynamic in nature. For example, a fleet group may belong to this category. Solution ideas are described herein with reference to Figures 4-12, including the decision and triggering of discovery announcements or responses to discovery announcements controlled by the AS using assistance information from upper layers above the AS.

[0149] Solutions for V2X radio configuration for discovery

[0150] A radio configuration solution for a V2X radio configuration required for discovery in order to support a sidelink self-advertisement discovery process or a target search discovery process is described herein, for example, with reference to FIGS. 10-12 .

[0151] Send radio configuration about discovery

[0152] Fig.13 A high-level diagram of the radio configuration steps for discovery messaging is provided in .

[0153] The solution described herein assumes that at a UE involved in self-advertisement discovery or target search discovery, the following steps have been performed and the input information explained below is available.

[0154] The UE is provided with V2X communication parameters, including policies and configuration parameters for sending V2X discovery messages as described herein for in-coverage and out-of-coverage discovery (e.g., with reference to FIGS. 2 and 3 ). The UE has performed a discovery authorization procedure for a specific instance of the discovery procedure in which the UE is to participate. For example, the discovery procedure may be a discovery procedure similar to LTE Model A, in which the UE may participate in sending self-advertising discovery messages or in monitoring for self-advertising discovery messages. Fig. 10A and 10BAs described in the self-advertising process of the example in , the UE participating in the self-advertising discovery may be a fleet leader or RSU, advertising its own UE, so that other neighboring UEs or UE groups interested in the information it advertises (e.g., a specific V2X application, such as carpooling) may initiate sidelink communications to the UE or a UE monitoring self-advertisements from other UEs, so that it may discover a group leader or fleet leader in its vicinity, or a UE in its vicinity with specific application or service capabilities. The discovery process may also be a discovery process similar to LTE Model B, in which the UE performs a target search discovery, as shown in reference Fig.11A , 11B In this process, the UE participating in the discovery may make an announcement when searching for a specific UE or UE group, or the UE participating in the discovery process may respond to the target search announcement from the discoverer as the discovered party, or may be a UE or UE group monitoring the target search announcement.

[0155] To support radio configuration in the access stratum (AS) for V2X discovery message transmission, the upper layer may provide one or more of the following types of information to the access stratum.

[0156] Self-advertising discovery announcement

[0157] For self-advertising discovery announcements, QoS information for sessions or candidate sessions to be established after discovery may be used. QoS information may include one or more of the following: payload (bytes); send rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); minimum required communication range (meters); per-packet priority (e.g., ProSe per-packet priority (PPPP)); per-packet reliability (e.g., ProSe per-packet reliability (%)); or QoS flow ID. The AS uses the QoS information to decide on the radio configuration and transmission parameters of the discovery message. For example, the UE may set the transmission parameters (e.g., transmit power) of the discovery message so that UEs outside the target communication range will not receive the discovery message because they will not be able to provide the desired QoS for subsequent V2X communications or V2X sessions. One or more of these QoS parameters may also be sent with the discovery message. Such information may, for example, help with filtering and admission control on the receiving side.

[0158] The AS can use the QoS information of the discovery message to decide the radio configuration and transmission parameters of the discovery message. For example, the UE can set the transmission parameters (e.g., transmission power) of the discovery message so that UEs outside the target communication range will not receive the discovery message. This information can also be used when deciding the number of retransmissions of the discovery message (e.g., the number of automatic retransmissions without ACK).

[0159] The AS may use the indication of whether the discovery message should be unicast, multicast or broadcast to decide whether to send the discovery message using unicast, multicast or broadcast. The indication may also be included in the discovery announcement message.

[0160] Parameters indicating the service / platform capabilities and radio capabilities of the declaring UE and / or the target receiving UE may be used. The AS may use this information to set the sending parameters. This information may also be sent along with the discovery message and may be used to help the receiving party filter the monitored discovery messages, or to help the receiving party perform admission control and decide which self-advertisement announcement message to respond to.

[0161] A parameter indicating one or more destination layer 2 IDs associated with the group to which the declaring UE belongs may be used. One or more destination layer 2 IDs associated with the group to which the monitoring UE belongs. The destination layer 2 ID may be mapped to a V2X PSID or ITS-AID by upper layers. This information may be sent along with the discovery message and may help the recipient to filter the received discovery messages or be used in the receiving UE for admission control. It may also be used at the recipient to decide which declaring discovery message to respond to or with which declaring UE or UE group to establish V2X communication.

[0162] The parameter may include a source layer 2 ID (eg, announcing UE layer 2 ID) that may be used for subsequent link establishment. The parameter may be included in the discovery announce message and may be used by the recipient as a destination layer 2 ID in a response to the discovery announce message.

[0163] The parameters may include one or more discovery group IDs associated with the discovery group to which the declaring UE belongs. One or more discovery group IDs associated with the discovery group to which the monitoring UE belongs. This can be an ID assigned by the 3GPP network (for example, a layer 2 ID that can be mapped to a V2X PSID or ITS-AID by the upper layer). This information can be sent together with the discovery message and can help the recipient filter the received discovery messages, or help with admission control. It can also be used at the recipient to decide which declaring discovery message to respond to, or which declaring UE or UE group to establish V2X communication with.

[0164] The parameters may include a TX profile (e.g., the RAT and RAT version of the receiver and / or sender). For example, it may reference the TX profile of the sender UE (e.g., the TX profile used when the UE subsequently initiates V2X communication with the sender). The AS may use the TX profile to configure the transmitting radio and set the transmission parameters of the discovery message. This information may be sent along with the discovery message and may help the receiver. For example, to help the discovered UE filter received discovery messages or to help with admission control. This information may also be used at the receiver to decide which announcement discovery message to respond to, or which announcement UE or UE group to establish V2X communication with. The TX profile may also reference the TX profile that the monitoring UE should use when initiating subsequent V2X communications.

[0165] The parameter may include an authorized PLMN. This may refer to the PLMNs on which the UE is allowed to send V2X discovery messages. This parameter may be sent as part of a discovery message and may be used by a receiving UE to filter detected discovery messages, decide which message to respond to, and / or which target search announcer to establish subsequent V2X communications with.

[0166] The parameters may include radio parameters (e.g., frequency carrier, bandwidth). The parameters may be used to configure the transmitting radio for V2X discovery message transmission. The parameters may be sent as part of the V2X discovery message and may be used by the receiving UE to filter the monitored discovery messages, decide which message to respond to, and / or which target search announcer to establish subsequent V2X communication with.

[0167] The parameter may include the discovery type (e.g., periodic or event-based). The parameter may be used to configure the transmitting radio for V2X discovery message transmission. The parameter may be used to identify the resources used for discovery message transmission. It may also be sent as part of the discovery message and may be used in the receiving UE to filter the discovery message.

[0168] The parameters may include other non-application layer related filtering information (e.g., AS or NAS level filtering information) to help the AS control the sending of discovery messages. This information may be sent together with the discovery message and may help the receiver filter the received discovery messages. It may also be used by the receiving UE, i.e., the discovered UE, to decide which announcement discovery message to respond to, or with which announcement UE or UE group to establish V2X communication.

[0169] Target Search Discovery Message Parameters

[0170] The target search discovery message may include various parameters. For example, the parameters may include QoS information for the session or candidate session to be established after discovery. The QoS information may include one or more of the following: payload (bytes); transmission rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); minimum required communication range (meters); per-packet priority (e.g., ProSe per-packet priority (PPPP)); per-packet reliability (e.g., ProSe per-packet reliability (%)); QoS flow ID; QoS profile ID or equivalent 5QI. The AS uses the QoS information to determine the radio configuration and transmission parameters of the discovery message. For example, the UE may set the transmission parameters (e.g., transmission power) of the discovery message so that UEs outside the target communication range will not receive the discovery message because they will not be able to provide the desired QoS for subsequent V2X communications or V2X sessions. One or more of these QoS parameters may also be sent with the discovery message. Such information, for example, can help with filtering and admission control at the receiving end.

[0171] The parameters may include QoS information for the discovery message. The AS may use this information to determine the radio configuration and transmission parameters for the discovery message. For example, the UE may set the transmission parameters (e.g., transmission power) of the discovery message so that UEs outside the target communication range will not receive the discovery message. This information may also be used when determining the number of retransmissions of the discovery message (e.g., the number of automatic retransmissions without ACK).

[0172] The parameter may include an indication of whether to send the discovery message in the form of a unicast message and / or a multicast message and / or a broadcast message. The AS may use the parameter to decide whether to send the discovery message using unicast, multicast or broadcast. This information may also be included in the discovery announcement message.

[0173] The parameters may include the service / platform capabilities and radio capabilities of the sender UE and / or the target receiver UE. The AS may use this information to set the transmission parameters. This information may also be sent together with the discovery message and may be used to help the receiver filter the monitored discovery messages. This information may be used to help the receiver perform admission control and determine which target search discovery message to respond to, or to help determine which declaring UE or UE group to establish V2X communication with.

[0174] The parameters may include one or more destination layer 2 IDs associated with the group to which the target search announcing UE belongs. One or more destination layer 2 IDs associated with the group to which the monitoring UE belongs. The destination layer 2 ID may be mapped to a V2X PSID or ITS-AID by the upper layer. This information may help the receiver filter the received discovery messages. It may also be used at the receiver to decide which target search discovery message to respond to, or with which target search discovery UE or UE group to establish V2X communication.

[0175] The parameters may include the source layer 2 ID (eg, target search announcement UE layer 2 ID). This information may be used for subsequent link establishment.

[0176] The parameters may include one or more discovery group IDs associated with the discovery group to which the target search declaration UE and / or monitoring UE belongs. One or more discovery group IDs associated with the discovery group to which the monitoring UE belongs. This can be an ID assigned by the 3GPP network (for example, a layer 2 ID that can be mapped to a V2X PSID or ITS-AID by an upper layer). This information can be sent together with the discovery message. This information can be used by the receiving UE to filter the monitored discovery messages, or to perform access control. This information can also be used to decide which discovery message to respond to, or to establish V2X communication with which target search UE or UE group.

[0177] The parameters may include a TX profile (e.g., the RAT and RAT version of the receiver and / or sender). For example, it may reference the TX profile of the sender UE (e.g., the TX profile used when the UE subsequently initiates V2X communication with the sender). The AS may use the TX profile to configure the transmitting radio and set the transmission parameters of the discovery message. The TX profile may also reference the TX profile that the monitoring UE should use when initiating subsequent V2X communication. This information may be sent with the discovery message and may help the receiver filter the received discovery messages. This information may also be used by the receiver, i.e., the discovered UE, to decide which target search discovery message to respond to, or with which target search discovery UE or UE group to establish V2X communication.

[0178] The parameter may include an authorized PLMN. This may refer to the PLMNs on which the UE is allowed to send V2X discovery messages. This parameter may be sent as part of a discovery message and may be used by a receiving UE to filter detected discovery messages, decide which message to respond to, and / or which target search announcer to establish subsequent V2X communications with.

[0179] The parameters may include radio parameters (e.g., frequency carrier, bandwidth). The parameters may be used to configure the transmitting radio for V2X discovery message transmission. The parameters may be sent as part of the V2X discovery message and may be used by the receiving UE to filter the monitored discovery messages, decide which message to respond to, and / or which target search announcer to establish subsequent V2X communication with.

[0180] The parameter may include the discovery type (e.g., periodic or event-based). The parameter may be used to configure the transmitting radio for V2X discovery message transmission. The parameter may be used to identify the resources used for discovery message transmission. It may also be sent as part of the discovery message and may be used in the receiving UE to filter the discovery message.

[0181] The parameters may include other non-application layer related filtering information (eg, AS or NAS level filtering information) to help the AS control the sending of discovery messages.

[0182] Target search discovery response message

[0183] The target search discovery response message may include various parameters.

[0184] The parameters may include QoS information for sessions or candidate sessions that the discovered party can support. The QoS information may include one or more of the following: payload (bytes); transmission rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); minimum required communication range (meters); per-packet priority (e.g., ProSe per-packet priority (PPPP)); per-packet reliability (e.g., ProSe per-packet reliability (%)); QoS flow ID; QoS profile ID or equivalent 5QI. QoS information (e.g., QoS profile ID) may be sent with the discovery message and may be used by the AS or NAS of the target search announcer UE (discoverer) to filter the discovery response message and / or decide with which discovered party to establish V2X communication. QoS information may be used by the target search announcer UE to determine the radio configuration and transmission parameters of subsequent V2X communication messages. It may also be used by the discovered party UE to determine the radio configuration parameters for sending the target search discovery response message. For example, the UE may set the receiving range of the sent response discovery message so that discovery messages from UEs outside the range will not be received because these UEs may not meet the expected QoS requirements for subsequent V2X communications of the V2X session; this information may be included in the discovery response message, for example, in the response to the discovery announcement message. This information can help the sending UE (discovering UE) filter the received discovery response messages, or can be used in the sending UE for admission control. This information can also be used by the sending UE to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communication.

[0185] The parameters may include QoS information for the response discovery message. The AS may use this information to determine the radio configuration and transmission parameters for the response discovery message. For example, the UE may set the transmission range of the monitored discovery message so that UEs outside the range will not receive the response discovery message.

[0186] The parameter may include an indication of whether to send the response discovery message in the form of a unicast discovery message and / or a multicast message and / or a broadcast message. The AS may use the parameter to decide whether to send the discovery message using unicast, multicast or broadcast.

[0187] The parameters may include the service / platform capabilities and radio capabilities of the UE sending the discovery response message. The recipient of the discovery response message may use this information to configure the subsequent transmission of V2X communications. The UE sending the response discovery message may also use this information to configure the transmitting radio for sending the discovery response message. It may also be used to filter the response discovery message at the sender UE of the target search discovery message. Specifically, the information may be included in the discovery response message (a response to the discovery announcement message) and may help the sender UE (discoverer UE) filter the received discovery response message. The information may be used in the sender UE for access control. It may also be used by the sender UE to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communication.

[0188] The parameters may include one or more destination layer 2IDs associated with the group to which the responding UE belongs. The destination layer 2ID may be mapped to a V2X PSID or an ITS-AID by an upper layer. This information may be used for filtering of monitored response discovery messages. It may also be used to decide with which responding UE or UE group to establish V2X communication. Specifically, this information may be included in a discovery response message (a response to a discovery announcement message) and may help the sending UE (discovering UE) filter the received discovery response message. This information may be used in the sending UE for access control. It may also be used by the sending UE to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communication.

[0189] The parameters may include a source layer 2 ID (e.g., a responding UE layer 2 ID). This information may be used for subsequent link establishment. This information may be included in a discovery response message (a response to a discovery announcement message) and may help the sender UE filter received discovery response messages, or may be used for admission control at the sender UE (discoverer UE). This information may also be used by the sender UE to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communication. This information may be used as a destination layer 2 ID in a data packet sent by the discoverer UE to the discovered UE in subsequent V2X communications.

[0190] The parameters may include one or more discovery group IDs associated with the discovery group to which the responding UE belongs. This may be an ID assigned by the 3GPP network (for example, a layer 2 ID that can be mapped to a V2X PSID or ITS-AID by an upper layer). This information can be used for filtering of monitored response discovery messages. It can also be used to decide which discovery message to respond to, or with which responding UE or UE group to establish V2X communication. Specifically, this information may be included in a discovery response message (a response to a discovery announcement message), and may help the sending UE (discovering UE) filter the received discovery response message. This information may be used at the sending UE for access control. This information may also be used by the sending UE to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communication.

[0191] The parameters may include a TX profile (e.g., the RAT and RAT version of the receiver and / or sender). For example, it may refer to the TX profile of the responding UE (e.g., the TX profile that the responding UE uses to configure its transmit radio and set the transmit parameters of the response discovery message). It may also refer to the TX profile of the target search announcement UE (e.g., the TX profile used when the target search announcement UE initiates V2X communication with the responding UE). Specifically, this information may be included in a discovery response message (a response to a discovery announcement message) and may help the sender UE (discoverer UE) filter the received discovery response messages, or may be used at the sender UE for admission control. It may also be used by the sender UE to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communication.

[0192] The parameters may include authorized PLMNs. This may refer to the PLMNs in which the corresponding UE is allowed to perform V2X communications. The parameter may be used by the target search declaring UE (discoverer) to filter the monitored response discovery messages, and / or to decide with which responding UE to establish subsequent V2X communications. Specifically, the information may be included in a discovery response message (a response to a discovery declaration message), and may help the sending UE (discoverer UE) filter the received discovery response messages, or may be used at the sending UE for access control. It may also be used by the sending UE (discoverer UE) to decide with which responding UE (discovered UE or discovered UE group) to establish V2X communications.

[0193] The parameters may include radio parameters (e.g., frequency carrier, bandwidth). The parameters may be used by the target search announcement UE (discoverer) to filter the monitored response discovery messages and / or decide with which responding UE to establish subsequent V2X communication.

[0194] The parameter may include the discovery type (e.g., periodic or event-based). The parameter may be used to identify the resource to send in response to the discovery message. It may also be used to filter the response discovery messages.

[0195] The parameters may include other non-application layer related filtering information (eg, AS or NAS level filtering information) to help the AS control the sending of the response discovery message.

[0196] Radio Configuration Decisions

[0197] The radio configuration may address many factors, such as whether discovery messages are sent on a PSDCH resource pool, on PSSCH, or on both in the case of duplication, as this may be dictated by the reliability requirements of the discovery messages. For example, a dedicated PSDCH resource pool may be assigned to periodic transmissions of V2X discovery messages. Similarly, a PSSCH resource pool may be configured to support event-based transmissions of aperiodic discovery messages. Such a pool may or may not be shared with periodic discovery messages. Similarly, such a resource pool may or may not be shared by other V2X data transmissions.

[0198] Other factors may include whether the discovery message is sent as a broadcast, multicast, or unicast; for example, if the UE has joined a group, the discovery message may be targeted to that specific group, or the group may be prioritized for discovery of a particular service or application. In this case, it may be beneficial to send the discovery message as a multicast or unicast. In this case, the QoS requirements of the message may also require some form of feedback (e.g., ARQ feedback), which facilitates unicast or multicast transmission.

[0199] Other factors may include whether to set up a specific bearer or use a pre-configured specific bearer to transmit the discovery message, or to use a per-packet QoS architecture in which each discovery message packet carries its own QoS requirement information, such as priority information (e.g., PPPP) and reliability information (e.g., PPPPR).

[0200] Other factors may include which mode of RLC is configured, whether it is RLC TM, RLC UM or RLC AM.

[0201] Other factors may include PDCP configuration (eg, security protection and compression of discovery messages).

[0202] Other factors may include MAC configuration and mapping of discovery messages to logical channels for multiplexing with other discovery messages or with V2X transmissions on PSSCH.

[0203] Other factors may include the configuration of the PHY (eg, for PHY resource grant allocation).

[0204] The UE AS (e.g., RRC) uses information received from upper layers, pre-configured or specified rules, and measurements performed by the UE to decide on the radio configuration for discovery message transmission. Examples of measurements may include channel load measurements, channel congestion measurements; channel busy rate (CBR), channel occupancy rate (CR) measurements, LBT failure statistics (e.g., LBT failure rate), RSRP measurements, and RSSI measurements. In the case where the decision involves selecting unicast or multicast to send a discovery message, additional measurements such as RSRQ measurements and CSI measurements may also be considered.

[0205] Rules for PSSCH or PSDCH transmission of discovery messages

[0206] Rules can be specified for using PSSCH or PSDCH to send discovery messages. In the example below, a rule can be set that fixed-size discovery messages are always mapped to PSDCH, while variable-size discovery messages are always mapped to PSSCH. The rules can specify that periodic discovery messages are always sent on PSDCH, while event-based aperiodic discovery messages are always sent on PSSCH, or that periodic discovery messages are always sent on a dedicated PSDCH resource pool, while event-based aperiodic discovery messages are always sent on a dedicated PSSCH resource pool. Similarly, the rules may require that discovery messages are always sent on a dedicated PSSCH resource pool and not multiplexed with other V2X data transmissions.

[0207] Rules can be established to specify transmission on PSSCH or PSDCH based on whether the characteristics of the discovery message are above or below certain thresholds. For example, a rule can be set to send discovery messages on PSSCH (or on PSDCH) with a size above (or below) a given threshold. Similarly, a rule can be set to send discovery messages on PSSCH or on PSDCH with an allowed waiting time above or below a certain threshold. A rule can be established to send discovery messages on PSSCH or on PSDCH with an allowed reliability above or below a given threshold. Similarly, a rule can be established to send discovery messages on PSSCH or on PSDCH with an allowed transmission range above or below a given threshold.

[0208] About the received radio configuration found

[0209] Fig.14 A high-level diagram of the radio configuration steps for discovery message reception is provided in The described solution herein assumes that at a UE involved in monitoring for self advertisement discovery announcement messages or monitoring for target search discovery messages, the following steps have been performed and the input information described below is available.

[0210] The UE is provided with V2X communication parameters, including policies and configuration parameters for the transmission of V2X discovery messages as described for in-coverage and out-of-coverage discovery (e.g., with reference to FIGS. 2 and 3 ). The UE has undergone a discovery authorization procedure for the specific instance of the discovery procedure in which the UE is to participate. For example, the discovery procedure may be a discovery procedure similar to LTE Model A, in which the UE may participate in monitoring for self-advertising discovery messages from other UEs. As described in reference to Fig. 10A -B, the UE participating in the monitoring of the self-advertisement discovery message may be a fleet leader or RSU, a group member, or a UE monitoring self-advertisements from other UEs, so that it can discover the group leader, fleet leader, and UE with specific application or service capabilities in its vicinity. The discovery process may also be a discovery process similar to LTE model B, in which the UE (discovered party) monitors the target search discovery message announcement from other UEs (discovered parties), or the UE (discovered party) monitors the response to the target search message from other UEs (discovered parties), as described in reference to Figures 11 and 12. In this process, the UE participating in the discovery may be a UE or a UE group monitoring the target search announcement from other UEs.

[0211] To support radio configuration in the access stratum (AS) for reception of V2X discovery messages, the upper layer may provide information to the access stratum. The AS may be configured with separate parameter sets for self-advertising discovery message monitoring, for target search discovery message monitoring and / or for responses to target search discovery message monitoring. This information may also be included in a response message sent by the discovered UE to the discovering UE.

[0212] Self-advertising discovery monitoring

[0213] For self-advertising discovery monitoring, many parameters may be used. For example, the parameters may include QoS information for the session or candidate session to be established after discovery. The QoS information may include one or more of the following: payload (bytes); send rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); minimum required communication range (meters); per-packet priority (e.g., ProSe per-packet priority (PPPP)); per-packet reliability (e.g., ProSe per-packet reliability (%)); QoS flow ID; and QoS profile ID or equivalent 5QI. The AS or NAS may use the QoS information to filter discovery messages, decide on admission control, and / or whether to respond to the discovery message. The QoS information (e.g., QoS profile ID) may be used by the AS to decide on the radio configuration and reception parameters of the discovery message. The UE may set the reception range of the monitored discovery message so that a discovery message from a UE outside the range will not be received or heard because it will not meet the expected QoS requirements for subsequent V2X communications of the V2X session.

[0214] The parameters may include QoS information of the discovery message. The AS may use this information to determine the radio configuration and reception parameters of the discovery message. For example, the UE may set the reception range of the monitored discovery message so that the discovery message from the UE outside the range will not be received or intercepted.

[0215] The parameters may include an indication of whether to monitor for unicast discovery messages, multicast messages, and / or broadcast messages.

[0216] The parameters may include the service / platform capabilities, radio capabilities of the sender UE and / or the receiver UE. The information may also be used by the receiver to configure the reception parameters of the discovery message. It may also be used to perform admission control, filter the monitored messages, and decide which monitored messages to respond to.

[0217] The parameters may include one or more destination layer 2 IDs associated with the group to which the declaring UE belongs. One or more destination layer 2 IDs associated with the group to which the monitoring UE belongs. The destination layer 2 ID may be mapped to a V2X PSID or ITS-AID by the upper layers. This information may be used for filtering of the monitored discovery messages. It may also be used to decide which discovery messages to respond to and with which discovered UE or UE group to establish V2X communication.

[0218] The parameters may include a source layer 2 ID (eg, announcing a UE layer 2 ID). This information may be used for subsequent link establishment.

[0219] The parameters may include one or more discovery group IDs associated with the discovery group to which the declaring UE and / or monitoring UE belongs. One or more discovery group IDs associated with the discovery group to which the monitoring UE belongs. This can be an ID assigned by the 3GPP network (e.g., Layer 2 ID), which can be mapped to a V2X PSID or ITS-AID by an upper layer. This information can be used for filtering of monitored discovery messages. It can also be used to decide which discovery messages to respond to and with which discovered UE or UE group to establish V2X communication.

[0220] The parameters may include a TX profile, e.g., the RAT version of the receiver and / or sender. It may reference the TX profile of the monitoring UE (e.g., TX profile) to be used when the UE subsequently initiates V2X communication with the sender. Or the TX profile may reference the TX profile of the self-advertisement discovery message.

[0221] The parameter may include an authorized PLMN. This may refer to the PLMNs in which the receiving UE is allowed to monitor or establish V2X communications. The parameter may be used by the receiving UE to filter the monitored discovery messages, decide which messages to respond to and / or which announcer to establish subsequent V2X communications with.

[0222] The parameters may include radio parameters, such as frequency carrier, bandwidth, etc. The parameters may be used by the receiving UE to filter the monitored discovery messages, decide which message to respond to and / or which announcer to establish subsequent V2X communication with.

[0223] The parameter may include the discovery type, for example, periodic or event-based. This parameter may be used to identify the resource to monitor for discovery messages. It may also be used to filter discovery messages.

[0224] The parameters may include other non-application layer related filtering information, such as AS or NAS level filtering information, to help the AS control the sending of discovery messages.

[0225] For target search discovery messages:

[0226] Targeted search for discovery messages. For example, the parameters may include QoS information for a session or candidate session to be established after discovery. The QoS information may include one or more of the following: payload (bytes); send rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); minimum required communication range (meters); per-packet priority (e.g., ProSe per-packet priority (PPPP)); per-packet reliability (e.g., ProSe per-packet reliability (%)); QoS flow ID; and QoS profile ID; or equivalent 5QI. QoS information, such as a QoS profile ID, may be used by the AS or NAS to filter discovery messages, decide on admission control and / or whether to respond to discovery messages. QoS information may be used by the AS to determine radio configuration and reception parameters for discovery messages. For example, the UE may set the reception range of the monitored discovery messages so that a discovery message from a UE outside the range will not be received or heard because it will not meet the expected QoS requirements for subsequent V2X communications of the V2X session.

[0227] The parameters may include QoS information of the discovery message. The AS may use this information to determine the radio configuration and reception parameters of the discovery message. For example, the UE may set the reception range of the monitored discovery message so that the discovery message from the UE outside the range will not be received or intercepted.

[0228] The parameters may include an indication of whether to monitor for unicast discovery messages, multicast messages, and / or broadcast messages.

[0229] The parameters may include the service / platform capabilities, radio capabilities of the sender UE and / or the receiver UE. The information may also be used by the receiver to configure the reception parameters of the discovery message. It may also be used to perform admission control, filter the monitored messages, and decide which monitored messages to respond to.

[0230] The parameters may include one or more destination layer 2 IDs associated with the group to which the target search announcing UE belongs. One or more destination layer 2 IDs associated with the group to which the monitoring UE belongs. The destination layer 2 ID may be mapped to a V2X PSID or ITS-AID by the upper layer. This information may be used for filtering of monitored discovery messages. It may also be used to decide which target search discovery messages to respond to, or with which target search announcing UE or UE group to establish V2X communications.

[0231] The parameters may include the source layer 2 ID (eg, target search announcement UE layer 2 ID). This information may be used for subsequent link establishment.

[0232] The parameters may include one or more discovery group IDs associated with the discovery group to which the target search declaration UE and / or monitoring UE belongs. One or more discovery group IDs associated with the discovery group to which the monitoring UE belongs. This can be an ID assigned by the 3GPP network (e.g., Layer 2 ID), which can be mapped to a V2X PSID or ITS-AID by an upper layer. This information can be used for filtering of monitored discovery messages. It can also be used to decide which discovery messages to respond to, or with which target search declaration UE or UE group to establish V2X communication.

[0233] The parameters may include a TX profile, for example, the RAT version of the receiver and / or sender. It may refer to the TX profile of the monitoring UE (e.g., TX profile) to be used when the UE subsequently initiates V2X communication with the sender. Or the TX profile may refer to the TX profile of the target search announcer UE.

[0234] The parameter may include an authorized PLMN. This may refer to the PLMNs in which the receiving UE is allowed to monitor or establish V2X communications. The parameter may be used by the receiving UE to filter the monitored discovery messages, decide which messages to respond to and / or which target search announcer to establish subsequent V2X communications with.

[0235] The parameters may include radio parameters, such as frequency carrier, bandwidth, etc. The parameters may be used by the receiving UE to filter the monitored discovery messages, decide which message to respond to and / or which target search announcer to establish subsequent V2X communication with.

[0236] The parameter may include the discovery type, for example, periodic or event-based. This parameter may be used to identify the resource to monitor for discovery messages. It may also be used to filter discovery messages.

[0237] The parameters may include other non-application layer related filtering information, such as AS or NAS level filtering information, to help the AS control the sending of discovery messages.

[0238] Receiver Radio Configuration Considerations

[0239] The receiving radio configuration may address many factors. For example, various aspects addressed in the configuration may include whether discovery messages are received only on the PSDCH resource pool, on the PSSCH, or on both in the case of replication, as this may be determined by the reliability requirements of the discovery messages. For example, a dedicated PSDCH resource pool may be assigned to the reception of periodic transmissions of V2X discovery messages. Similarly, a PSSCH resource pool may be configured to support the reception of event-based aperiodic discovery messages. Such a pool may or may not be shared with periodic discovery messages. Similarly, such a resource pool may or may not be shared for the reception of other V2X data.

[0240] Various aspects of the determination may also include whether to receive broadcast discovery messages, multicast discovery messages, and / or unicast discovery messages. For example, if the UE has joined a group, the discovery message may be intended for that particular group, or the group may be prioritized for receipt of discovery of a particular service or application. In this case, it may be beneficial to receive the discovery message in a multicast or unicast manner and monitor other broadcast discovery messages. In this case, the QoS requirements of the message may also require some form of feedback (e.g., ARQ feedback), which facilitates unicast or multicast transmission.

[0241] Various aspects of the determination may include whether to set up a specific bearer or use a pre-configured specific bearer to receive the discovery message, or to receive the discovery message based on a per-packet QoS architecture, in which each discovery message packet carries its own QoS requirement information, such as priority information (e.g., PPPP) and reliability information (e.g., PPPPR).

[0242] Various aspects of the determination may include which mode of RLC is configured; whether RLC TM or RLC UM or RLC AM.

[0243] Various aspects determined may include PDCP configuration, such as security protection and compression of discovery messages.

[0244] Various aspects of the determination may include a MAC configuration for demultiplexing of received discovery.

[0245] Various aspects of the determination may include configuration of the PHY for discovery message reception.

[0246] For the UE AS, for example, RRC uses information received from upper layers, pre-configured or specified rules and measurements made by the UE to decide on the radio configuration for discovery message reception. Examples of measurements may include channel load measurements, channel congestion measurements (e.g., channel busy rate (CBR)), channel occupancy rate (CR) measurements, LBT failure statistics (e.g., LBT failure rate), RSRP measurements, and RSSI measurements. In cases where the decision involves selecting unicast or multicast to send a discovery message, additional measurements such as RSRQ measurements and CSI measurements may also be considered.

[0247] Optional rules for receiving discovery messages using PSSCH or PSDCH

[0248] One or more rules may be specified for using PSSCH or PSDCH to receive discovery messages. For example, a rule may specify that fixed-size discovery messages are always mapped to PSDCH, while variable-size discovery messages are always mapped to PSSCH. Similarly, a rule may require that periodic discovery messages are always sent on PSDCH, while event-based aperiodic discovery messages are always sent on PSSCH, or that periodic discovery messages are always sent on a dedicated PSDCH resource pool, while event-based aperiodic discovery messages are always sent on a dedicated PSSCH resource pool, or that discovery messages are always received on a dedicated PSSCH resource pool and are not multiplexed with other V2X data transmissions;

[0249] For example, a rule may be set to always monitor discovery messages on PSSCH, or on PSDCH, or also on PSDCH for sizes above (or below) a given threshold. Similar rules may be designed in which latency, reliability, or reception range are compared to thresholds.

[0250] About the discovered MAC sublayer configuration

[0251] MAC Architecture

[0252] For V2X, we propose that discovery messages may be sent via PSDCH, PSSCH or PSMCH. Which physical channel to use to send discovery messages may be predetermined, e.g., semi-statically configured by upper layers based on pre-configured rules, based on rules obtained from PCF / V2XCF via NAS messaging, based on rules obtained from V2XCF via an IP-based protocol such as ANDSF, QoS requirements and measurements, as per the standard.

[0253] In one example, the discovery message is mapped to the SL-DCH, which is subsequently mapped to the PSDCH. The discovery message may first be mapped to a separate logical channel (e.g., the Sidelink Discovery Control Channel (SDCCH)). The MAC structure may support (de)multiplexing of multiple discovery messages, in which case the LCP and (de)multiplexing functions are included in the SL-DCH processing path. In this embodiment, the discovery message mapped to the SDCCH is not multiplexed with the V2X message mapped to the Sidelink Traffic Channel (STCH). Filtering of received SL-DCH PDUs may also be performed by the receiving UE. For example, filtering may be based on source address, destination address, service / platform capabilities, and QoS. HARQ processing may also be performed to retransmit the SL-DCH PDU. Fig.15 and Fig.16 The possible MAC structure and channel mapping for this example are shown in FIG.

[0254] In another example, the discovery message is mapped to the SL-SCH, which is subsequently mapped to the PSSCH. The discovery message may first be mapped to a separate logical channel (e.g., SDCCH). The SDCCH message may then be multiplexed with other V2X messages carried via the sidelink traffic channel (STCH). Alternatively, the MAC structure may be defined such that the SL-SCH PDU consists only of one or more SDCCH logical channels or only of one or more STCH logical channels. LCP and (de)multiplexing functions are included in the SL-SCH processing path. For example, filtering of received SL-SCH PDUs may also be performed by the receiving UE. Filtering may be based on source address, destination address, service / platform capabilities, and QoS. HARQ processing may also be performed to retransmit the SL-SCH PDU. Fig.17 and Fig.18 The possible MAC structure and channel mapping for this example are shown in FIG.

[0255] In another example, the discovery message is mapped to the SL-DCH, which is subsequently mapped to the PSSCH. For some scenarios, such as where the UE can only send one transport block at a time on the sidelink, the MAC decides which transport channel (e.g., SL-DCH or SL-SCH) to generate the transport block for. How the MAC makes this decision can be rule-based (e.g., traffic on the SL-DCH takes precedence over the SL-SCH). Alternatively, the decision may be more dynamic (e.g., based on the relative priority of SDCCH and STCH traffic).

[0256] In another set of examples, transparent MAC may be used for SL-DCH, where SL-DCH may be mapped to PSDCH or PSSCH.

[0257] In another example, the discovery message is mapped to the SL-MCH, which is then mapped to the PSMCH. Fig. 20 and Fig.21 The possible MAC structure and channel mapping for this example are shown in FIG.

[0258] Protocol Data Unit

[0259] MAC PDU (SL-DCH)

[0260] For embodiments where the discovery message is sent via the SL-DCH, the MAC PDU may consist of a MAC header, one or more MAC service data units (MAC SDUs), and optional padding. Both the MAC header and the MAC SDU may be variable size.

[0261] For example, the MAC PDU header may consist of one SL-DCH subheader and one or more MAC PDU subheaders; wherein each subheader except the SL-DCH subheader corresponds to a MAC SDU or padding.

[0262] The SL-DCH subheader may include SRC and DST fields. If different SL-DCH subheader formats need to be supported, a version field may also be included. For example, different formats with different DST field lengths may be defined for versions. Fig. 22 is an illustration of examples of SL-DCH subheaders that can be used for SL-DCH formats with different DST field lengths.

[0263] In another example, different formats with different numbers of DST fields are defined for each version in the SL-DCH subheader. Such a format can be used in scenarios where SDUs with different DST fields are multiplexed in a PDU. Alternatively, the DST field associated with each MAC SDU can be included in the MAC PDU subheader, in which case the SL-DCH MAC subheader can include only the SRC field. Fig.23 is an illustration of examples of SL-DCH subheaders that may be used for SL-DCH formats with different numbers of DST fields.

[0264] The MAC PDU subheader may include fields with SDU specific information (e.g., LCID, length, QoS, and platform / radio capabilities). An extension field may also be included to indicate whether there are more fields in the MAC header.

[0265] Fig.24 is an illustration of an example of a MAC PDU subheader that may be used to indicate the LCID, length, and presence / absence of additional MAC subheaders.

[0266] Fig.25 is a diagram of an exemplary MAC PDU sub-header that also indicates QoS and capability information.

[0267] Fig.26 is an illustration of an exemplary MAC PDU sub-header which also indicates the DST address.

[0268] The last subheader in the MAC PDU subheader may exclude the length and format fields, since the length of the last SDU may be determined based on other information provided. The last MAC PDU subheader may correspond to padding, if padding is required.

[0269] The MAC PDU may be constructed such that the MAC subheaders are gathered at the beginning of the MAC PDU. In one example, the MAC PDU subheaders have the same order as the corresponding MAC SDU and padding.

[0270] Padding may appear at the end of a MAC PDU and may have an arbitrary value that is ignored by the MAC entity. When padding is performed at the end of a MAC PDU, zero or more padding bytes may be allowed. Alternatively, when 1-byte or 2-byte padding is required, one or two MAC PDU subheaders corresponding to the padding may be placed after the SL-DCH subheader and before any other MAC PDU subheader. Fig. 27 An example of a MAC PDU is shown in FIG.

[0271] In another alternative, the MAC subheader may be placed directly before the corresponding MAC SDU and padding, such as Fig.28 as shown in .

[0272] For embodiments in which the MAC CE is included in the SL MAC PDU, the MAC CE may be aggregated and placed before the MAC SDU or after the MAC SDU. The MAC subheader corresponding to the MAC CE may be included in the MAC header, such as Fig. 27 or directly before the corresponding MAC CE, such as Fig.28 As described in.

[0273] MAC PDU (SL-SCH)

[0274] The solutions described in this disclosure with respect to SL-DCH MAC PDU may also be applied to SL-SCH MAC PDU.

[0275] Format and parameters

[0276] MAC header (SL-DCH)

[0277] The MAC header may be of fixed or variable size and may consist of some or all of the following fields. A receiving UE may use one or more of the following fields in the MAC header, or their equivalents, to filter for PDUs: V, SRC, DST, LCID, L, F, E, QoS, CAP, and R. These fields are described below.

[0278] V: The format version number field indicates which version of the SL-DCH subheader is used. Different versions may consist of different fields and different field lengths. The V field size may be a fixed size (e.g., 4 bits). For embodiments that support only one format, the format version number field may be excluded.

[0279] SRC: Source Layer 2 ID field carries the identification of the source. This may correspond to the discovery group ID. The SRC field may be of fixed size (e.g., 24 bits). For scenarios where the UE belongs to multiple discovery groups, multiple SRC fields may be included in the MAC header. An additional field may be used to indicate the number of SRC fields in the MAC header. Alternatively, different versions may be defined for formats consisting of different numbers of SRC fields.

[0280] DST: The DST field may have different fixed sizes (e.g., 16 bits or 24 bits). If it is 16 bits, it carries the 16 most significant bits of the destination layer 2 ID. If it is 24 bits, it is set to the destination layer 2 ID. The destination layer 2 ID may be set to a value provided by an upper layer that may correspond to the discovery group ID, the ProSe layer 2 group ID, and the ProSe UE ID.

[0281] LCID: The Logical Channel ID field uniquely identifies a logical channel instance or padding within the range of a pair of source Layer 2 ID and destination Layer 2 ID of the corresponding MAC SDU, as described in Table 2 of the Appendix. There is one LCID field for each MAC SDU or padding included in the MAC PDU. In addition, when 1-byte or 2-byte padding is required but cannot be achieved by padding at the end of the MAC PDU, one or two additional LCID fields are also included in the MAC PDU. The LCID field can be a fixed size (e.g., 5 bits).

[0282] L: The length field indicates the length of the corresponding MAC SDU in bytes. Each MAC PDU subheader has an L field except the last subheader. The size of the L field can be indicated by the F field, or have a fixed size (e.g., 5 bits). For embodiments in which the MAC SDU is a fixed size, the length field can be excluded.

[0283] F: The format field indicates the size of the length field. Example lengths are shown in Table 3 of the Appendix. Each MAC PDU subheader has an F field except the last subheader. The F field can be a fixed size (e.g., 1 bit). If the size of the MAC SDU is less than a certain size (e.g., 128 bytes), the value of the F field is set to zero, otherwise it is set to 1. For embodiments in which the length field is excluded from the message or has a fixed size, the format field can be excluded.

[0284] E: The extension field is a flag indicating whether there are more fields in the MAC header. The E field is set to "1" to indicate that there is another set of fields. The E field is set to "0" to indicate that the MAC SDU or padding starts at the next byte. For embodiments in which the MAC PDU consists of 1 MAC SDU, the extension field can be excluded.

[0285] QoS: The QoS field may be used to indicate the QoS of a session or candidate session to be established after discovery. The QoS field may be a fixed size (e.g., 4 bits). The one or more sets of QoS may be standardized or provided by an upper layer using a preconfigured list. In one embodiment, the QoS field corresponds to an index that may be used to determine QoS information for a session or candidate session to be established after discovery, as described herein.

[0286] CAP: The Capability field may be used to indicate the service / platform capabilities and / or radio capabilities of the declaring UE and / or the target receiving UE. The one or more sets of capabilities may be standardized or provided by the upper layer using a preconfigured list. The CAP field may be a fixed size (e.g., 4 bits).

[0287] R: Reserved bit set to "0".

[0288] Note: The field descriptions include example field lengths. Other lengths are contemplated and can be used with the solutions presented in this document. The MAC header and subheaders are octet aligned. See Tables 2 and 3 in the Appendix.

[0289] MAC header (SL-SCH)

[0290] The solutions described in this disclosure with respect to the SL-DCH MAC header may also be applied to the SL-SCH MAC header.

[0291] Solutions for V2X radio configuration for unicast, multicast or broadcast V2X data communications

[0292] The solution described in the present disclosure regarding the configuration of the transmitting radio and the receiving radio for the case of discovery messages is also applicable to the transmission and reception of V2X sidelink data other than discovery messages.

[0293] Example Solution

[0294] It will be appreciated that the techniques described herein may be applied in various ways. For example, a user device may act as a discoverer by sending a discovery announcement via a sidelink service, the discovery announcement describing the criteria for one or more services sought by the discoverer user device. The discoverer user device may configure its communication circuit accordingly to monitor responses to the announcement from one or more discovered user devices. Like the announcement, the response may include criteria for one or more services provided by the discovered device that made the response. For example, the discovery announcement may be a target search discovery announcement, or a self-advertising discovery announcement. The discovery announcement may be sent in a unicast, multicast, or broadcast manner.

[0295] The discovery announcement may include information about the discoverer user equipment, such as service capabilities, service platform capabilities, radio capabilities, one or more source identifiers, driving information (e.g., driving intention information, positioning information, or environmental information), radio measurements, one or more identifiers of one or more groups to which the first device belongs, and protocol configuration parameters for V2X communication. Similarly, instead of or in addition to information about the discoverer, the discovery announcement may include such information about the discoverer user equipment.

[0296] The criteria contained in the announcement or the response to the announcement regarding the service sought by the discoverer may include, for example: the service or service type of interest; QoS requirements for the service, TX profile, or authorized PLMN for the service.

[0297] The user equipment of the discovering party may include a mobile terminal unit that implements radio transmission / reception and related functions, and may include a terminal device unit that implements application functions. For example, in addition to the information contained in the discovery announcement, the mobile terminal unit may also filter or control the user equipment of the discovering party based on the information contained in the response to the announcement, such as supported services, service capabilities, service platform capabilities, radio capabilities, driving information, source identifier of the second device, supported QoS requirements for services, TX profiles of one or more supported services or services of interest to the second device, radio carrier frequency parameters of the service, or authorized PLMN. The mobile terminal unit may then provide the results of the filtering to the terminal device.

[0298] The discovery announcement may be sent by the discovering user equipment or received by the discovered user equipment device on a logical channel, for example, by using a logical channel identifier predefined in the protocol specification. Similarly, the response of the responding discovered user equipment device to the discovery announcement may be sent by the discovered user equipment device or received by the discovered user equipment device on a logical channel, for example, by using a logical channel identifier predefined in the protocol specification.

[0299] The discovering user equipment may be synchronized before participating in V2X communication including sending a discovery announcement or receiving a response to a discovery announcement.

[0300] The discoverer and the discovered user equipment device may collect driving information related to the vehicle associated with the corresponding device. The driving information may be shared, for example, in a discovery announcement or in a response to a discovery announcement, and may be further used to evaluate or filter the received discovery announcement or response, or may also be used for admission control of the discovered user equipment device that responds by the discoverer user equipment device, or may also be used for admission control of the discoverer user equipment device by the discovered user equipment device. Similarly, the driving information may include information such as driving intention, positioning, and driving environment information.

[0301] The discovering user equipment may send an authorization request for the discovery announcement, and may include the driving information in the authorization request.

[0302] The user equipment to be discovered can receive authorization for sidelink V2X communication, including authorization for specific V2X communication services and monitoring and responding to related discovery announcements, can receive vehicle communication sidelink service parameters, and configure communication circuits to monitor discovery announcements from one or more discovery user equipment devices. The user equipment to be discovered can then receive a discovery announcement via the sidelink service, the discovery announcement containing one or more criteria for the service sought by the discovery user equipment device, and evaluate the discovery announcement. If the user equipment to be discovered can provide the service sought by the first device, the user equipment to be discovered can send a discovery response to the discovery user equipment via the sidelink service. Similarly, the discovery announcement can be a target search discovery announcement or a self-advertising discovery announcement, and can be received in a unicast, multicast or broadcast manner. The user equipment to be discovered can synchronize the sidelink service. And similarly, the discovery announcement and the response to the discovery announcement can include various information described in relation to the operation of the discovery user equipment, and the discovered party can evaluate whether to respond to the discovery announcement accordingly. Specifically, the response to the discovery announcement may include information about the user equipment of the discovered party, such as service capabilities, service platform capabilities, radio capabilities, one or more identifiers of one or more groups to which the user equipment of the discovered party belongs, driving information including one or more of driving intention information, positioning information, and environmental information, and radio measurements. Similarly, the response to the discovery announcement may include information about the supported services or services of interest to the user equipment of the discovered party. Such information may include QoS requirements, TX profiles, radio carrier frequency parameters, and one or more authorized PLMNs. The user equipment of the discovered party may collect driving information (intention, positioning, environment, etc.) about the vehicle associated with the discovered party, and in addition to including such driving information in the response message to the discovery announcement, such driving information may also be used to evaluate the discovery announcement, or such driving information may be included in the response to the discovery announcement.

[0303] The discoverer user device and the discovered user device may receive vehicle sidelink communication parameters or authorization from a third device. For example, the third device may provide vehicle communication sidelink service parameters to one or more discoverer user devices and one or more discovered user devices. The third device may then send authorization for discovery announcement to the discoverer user device, and send authorization for response discovery announcement to the discovered user device.

[0304] The discovering user equipment or the discovered user equipment may be a vehicle group leader, a fleet leader, or be capable of acting as a group leader or a fleet leader, and may indicate such service capabilities in a discovery announcement or a response to a discovery announcement.

[0305] Example Solution Architecture

[0306] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation of cellular technology called New Radio (NR) (also referred to as "5G"). 3GPP NR standard development is expected to include the definition of the next generation of radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be reused together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access (such as indoor applications and hotspots). In particular, ultra-mobile broadband is expected to share common design architectures with sub-6 GHz flexible radio access, with cmWave and mmWave-specific design optimizations.

[0307] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation of cellular technology called New Radio (NR) (also referred to as "5G"). 3GPP NR standard development is expected to include the definition of the next generation of radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be reused together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access (such as indoor applications and hotspots). In particular, ultra-mobile broadband is expected to share common design architectures with sub-6 GHz flexible radio access, with cmWave and mmWave-specific design optimizations.

[0308] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, and energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other-entities communications. Specific services and applications in these categories include, to name a few, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, and virtual reality. All of these and other use cases are contemplated herein.

[0309] Fig.29A An embodiment of an exemplary communication system 100 in which the methods and apparatus described and claimed herein may be embodied is illustrated. As shown, the exemplary communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be generally or collectively referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figures 29A-29EAlthough described as a handheld wireless communication device, it should be understood that for the various use cases envisioned for 5G wireless communications, each WTRU may include or be embodied by any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop computer, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a truck, a train or an airplane.

[0310] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a, 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRH 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRP 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSU 120a, 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. For example, the base stations 114a, 114b may be base transceiver stations (BTS), Node-B, eNode B, Home Node B, Home eNode B, site controllers, access points (APs), and wireless routers. Although the base stations 114a, 114b are depicted as single elements, it is to be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0311] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), and relay nodes. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), and relay nodes. Base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Base station 114b may be configured to send and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into 3 sectors. Thus, in an embodiment, the base station 114a may include three transceivers (e.g., one transceiver for each sector of the cell). In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may use multiple transceivers for each sector of the cell.

[0312] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, and 102c via an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, and mmWave). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0313] The base station 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b via a wired or air interface 129B / 116b / 117b, which may be any suitable wired (e.g., cable and fiber) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, and mmWave). The air interface 129B / 116b / 117b may be established using any suitable radio access technology (RAT).

[0314] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 129c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, and mmWave). The air interface 129c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0315] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another via an air interface 129D / 116d / 117d (not shown), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, and mmWave). The air interface 129D / 116d / 117d may be established using any suitable radio access technology (RAT).

[0316] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may utilize Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 129c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0317] In an embodiment, the base station 114a and the WTRU 102a, 102b, 102c, or the RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b and the WTRU 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may utilize Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish an air interface 115 / 116 / 117 or 129c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communications).

[0318] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0319] Fig.29AThe base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, or a campus. In an embodiment, the base station 114c and the WTRU 102e may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, and LTE-A) to establish a pico cell or a femto cell. Fig.29A As shown in FIG, base station 114b may be directly connected to Internet 110. Thus, base station 114c may not be required to access Internet 110 via core network 106 / 107 / 109.

[0320] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, and video distribution, and / or perform high-level security functions such as user authentication.

[0321] Although not in Fig.29A 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with other RANs (not shown) that employ a GSM radio technology.

[0322] The core network 106 / 107 / 109 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d, and 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that utilize common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, or a different RAT.

[0323] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.29A The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0324] Fig.29B 1 is a block diagram of an exemplary device or apparatus, such as WTRU 102, configured for wireless communication according to embodiments described herein. Fig.29B As shown in the example WTRU 102, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136 and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the above elements while still being consistent with the embodiment. In addition, the embodiment may contemplate that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, such as but not limited to base transceiver stations (BTS), Node-Bs, site controllers, access points (APs), home Node-Bs, evolved home Node-Bs (eNodeBs), home evolved Node-Bs (HeNBs), home evolved Node-B gateways and proxy nodes, etc., described herein may include Fig.29BSome or all of the elements shown in .

[0325] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, and / or one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and a state machine. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.29B The processor 118 and the transceiver 120 are depicted as separate components, although it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0326] The send / receive element 122 may be configured to send or receive signals to or from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the send / receive element 122 may be an antenna configured to send and / or receive RF signals. For example, in an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive IR, UV, or visible light signals. In another embodiment, the send / receive element 122 may be configured to send and receive both RF signals and optical signals. It is to be appreciated that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0327] In addition, although the transmit / receive element 122 is Fig.29B Although described as a single element in the embodiment, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0328] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122, and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0329] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) so as to receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card. In an embodiment, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as a memory on a server or a home computer (not shown).

[0330] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, and fuel cells.

[0331] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. The WTRU 102 may receive location information from a base station (e.g., base stations 114a and 114b) over the air interface 115 / 116 / 117 in addition to or in lieu of the information from the GPS chipset 136, and / or determine its location based on the timing of receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may utilize any suitable location-determination method to acquire location information while remaining consistent with an embodiment.

[0332] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, or Internet browser.

[0333] The WTRU 102 may be included in other devices or apparatuses, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0334] Fig.29C 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Fig.29C As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while still being consistent with an embodiment.

[0335] like Fig.29CAs shown in, Node-B 140a and 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node-B 140a, 140b and 140c to which it is connected. In addition, each of RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security function and data encryption.

[0336] Fig.29C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements are described as being part of the core network 106, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0337] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.

[0338] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0339] As described above, core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0340] Fig.29D1 is a system diagram of the RAN 104 and the core network 107 in accordance with an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0341] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0342] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink and / or downlink, etc. Fig.29D As shown in FIG. 1 , eNode-Bs 160a , 160b , and 160c may communicate with each other via an X2 interface.

[0343] Fig.29D The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements is described as being part of the core network 107, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0344] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0345] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, and managing and storing the context of the WTRUs 102a, 102b, and 102c.

[0346] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0347] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0348] Fig.29E 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As further described below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0349] like Fig.29EAs shown in the RAN 105, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while still being consistent with the embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, and quality of service (QoS) policy enforcement. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, and routing to the core network 109 .

[0350] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0351] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and data transfer between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0352] like Fig.29EAs shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the aforementioned elements is described as part of the core network 109, it is to be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0353] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0354] Although not in Fig.29E 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0355] Described in this article and Fig.29A , 29CThe core network entities illustrated in 29D and 29E are identified by the names given to these entities in certain existing 3GPP specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications released by 3GPP, including future 3GPP NR specifications. Fig.29A , 29B The specific network entities and functions described and illustrated in 29C, 29D and 29E are provided as examples only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0356] Fig.29F This can be specifically reflected in Fig.29A , 29C , 29D and 29E, such as one or more devices of the communication network illustrated in some nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110 or other networks 112. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may take the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, or one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and / or a state machine. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0357] In operation, processor 91 retrieves, decodes, and executes instructions, and transfers information to and from other resources via the computing system's primary data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines the medium for data exchange. System bus 80 generally includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0358] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily changed. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by the virtual address space of its own process; it cannot access memory within the virtual address space of other processes unless memory sharing between processes is set.

[0359] In addition, the computing system 90 may include a peripheral device controller 83 responsible for transmitting instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0360] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0361] In addition, the computing system 90 may include communication circuits such as a network adapter 97, which may be used to connect the computing system 90 to an external communication network, such as Fig.29A , 29B , RAN 103 / 104 / 105 of 29C, 29D and 29E, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 to enable computing system 90 to communicate with other nodes or functional entities of these networks. Alone or in combination with processor 91, the communication circuit can be used to perform the sending and receiving steps of certain devices, nodes or functional entities recorded in this document.

[0362] Figure 29GThe diagram illustrates one embodiment of an exemplary communication system 111 that may embody the methods and apparatus described and claimed herein. As shown, the exemplary communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station, a V2X server, and RSUs A and B. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One, several, or all of the WTRUs A, B, C, D, and E may be outside the range of the network (e.g., outside the cell coverage boundary represented as a dashed line in the figure). WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members. WTRUs A, B, C, D, E, and F may communicate via a Uu interface or a sidelink (PC5) interface.

[0363] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computing system.

[0364] appendix

[0365] Table 1 - Acronyms

[0366]

[0367]

[0368]

[0369]

[0370]

[0371]

[0372] Table 2: LCID values ​​for SL-DCH

[0373] index LCID value 0000 reserve Range #1 Logical channel identification Range #2 reserve 11111 filling

[0374] Table 3: Values ​​of the F field

[0375] index Size of the length field (bits) 0 7 1 15

Claims

1. A discoverer user equipment device, comprising a processor, a memory, a communication circuit, and computer executable instructions stored in the memory, when executed by the processor, the computer executable instructions cause the discoverer user equipment device to: issuing a discovery announcement via a sidelink communication logical channel, the discovery announcement comprising a logical channel identifier of the sidelink communication logical channel, the discovery announcement further comprising one or more criteria regarding one or more services sought by the discovering user equipment device; configuring the communication circuitry to monitor a sidelink communication logical channel for a response to the discovery announcement; as well as A discovery response is received from a discovered user equipment device, the discovery response being related to the discovery announcement and including a logical channel identifier of a sidelink communication logical channel, the discovery response also including one or more criteria regarding one or more services provided by the discovered user equipment device.

2. The discoverer user equipment device according to claim 1, wherein the discovery announcement comprises discoverer information, the discoverer information comprises one or more of the following data related to the discoverer user equipment device: service capabilities; service platform capabilities; radio capabilities; one or more source identifiers; driving information including one or more of driving intent information, positioning information, and environmental information; radio measurements; One or more identifiers of one or more groups to which the discovering user equipment device belongs; and protocol configuration parameters for future V2X communications.

3. A discovery party user equipment device according to claim 1, wherein the one or more criteria regarding one or more services include one or more of the following: one or more services of interest, QoS requirements for one or more services of interest, TX profiles of one or more services of interest, radio carrier parameters of one or more services of interest, and one or more authorized PLMNs for one or more services of interest.

4. The discoverer user equipment device according to claim 3, wherein the discovery announcement includes discovered party information, the discovered party information is related to one or more discovered party user equipment devices and includes one or more of the following: service capabilities; service platform capabilities; radio capabilities; one or more identifiers of one or more groups to which the one or more discovered user equipment devices belong; and protocol configuration parameters regarding future V2X communications.

5. The discovering user equipment device according to claim 1, further comprising a mobile terminal unit for implementing radio transmission / reception and related functions, wherein the mobile terminal unit is adapted to: performing filtering or admission control of one or more discovered user equipment devices, the filtering or admission control being based at least in part on information in the discovery announcement and information in the discovery response; and One or more of the filtering or admission control results are provided to the terminal device.

6. The discoverer user equipment device according to claim 1, wherein the logical channel identifier is predefined in a protocol specification.

7. A user equipment device of a discovered party, comprising a processor, a memory, a communication circuit, and computer executable instructions stored in the memory, wherein when executed by the processor, the computer executable instructions cause the discovered party user equipment device to: configuring the communication circuit to monitor for discovery announcements; receiving a discovery announcement via a sidelink communication logical channel, the discovery announcement comprising a logical channel identifier of the sidelink communication logical channel, the discovery announcement further comprising one or more criteria regarding a service sought by a discovering user equipment device; evaluating the discovery announcement; as well as If the discovered user equipment device can provide the service sought by the discovering user equipment device, a discovery response is sent to the discovering user equipment device via the sidelink communication logical channel.

8. The user equipment device of the discovered party according to claim 7, wherein: The discovery announcement also includes information about the discoverer and the person being discovered; The discoverer information is related to the discoverer device and includes one or more of the following: service capabilities; service platform capabilities; radio capabilities; one or more source identifiers; driving information including one or more of driving intent information, positioning information, and environmental information; radio measurements; one or more identifiers of one or more groups to which the discovering user equipment device belongs; and protocol configuration parameters for future V2X communications; The discovered party information is related to one or more discovered party user equipment devices and includes one or more of the following: service capabilities; service platform capabilities; radio capabilities; one or more identifiers of one or more groups to which the one or more discovered user equipment devices belong; and protocol configuration parameters for future V2X communications; and Evaluating the discovery advertisement includes comparing the discoverer information, the discovered party information, and one or more criteria regarding services sought by the discoverer user equipment device with information regarding services provided by the discovered party user equipment device.

9. The discovered user equipment device according to claim 7, wherein the discovery response comprises one or more of a V2X communication establishment request, a V2X protocol configuration parameter for future V2X communication, and a V2X communication service data packet.

10. The discovered user equipment device according to claim 7, wherein the discovery response comprises information related to the discovered device, the information comprising one or more of the following: service capabilities; service platform capabilities; radio capabilities; one or more source identifiers; one or more identifiers of one or more groups to which the discovered user equipment device belongs; radio measurements; QoS requirements, TX profiles, radio carrier parameters, one or more authorized PLMNs from the discovered party's point of view; and driving information, the driving information including one or more of driving intention information, positioning information, and environment information.

11. The discoverer user equipment device according to claim 1, wherein the sidelink communication logical channel is a separate logical channel dedicated to the transmission of the discovery announcement.

12. The discoverer user equipment device according to claim 1, wherein the sidelink communication logical channel is a sidelink discovery control channel SDCCH, and wherein the SDCCH is multiplexed with a sidelink service channel STCH.

13. The discoverer user equipment device according to claim 1, wherein a sidelink communication specific radio bearer is used for sending the discovery message.

14. The discoverer user equipment device according to claim 1, wherein a pre-configured radio bearer specific to discovery sidelink communication is used for sending the discovery announcement.

15. The discovered user equipment device according to claim 7, wherein the sidelink communication logical channel is a separate logical channel dedicated to the reception of discovery announcements.

16. The discovered user equipment device according to claim 7, wherein the sidelink communication logical channel is a sidelink discovery control channel SDCCH, and wherein the SDCCH is demultiplexed together with a sidelink service channel STCH.

17. The discovered party user equipment device according to claim 7, wherein a sidelink communication specific radio bearer is used for receiving the discovery announcement.

18. The discovered user equipment device according to claim 7, wherein a pre-configured radio bearer specific to discovery sidelink communication is used for receiving the discovery announcement.

19. A wireless transmit / receive unit WTRU, comprising a processor, wherein the processor is configured to: receiving configuration information associated with ProSe user equipment UE to network relay discovery, the configuration information comprising one or more destination layer 2 identifiers IDs for ProSe UE to network relay discovery messages; transmitting the ProSe UE to network relay discovery message using at least one identification ID of the one or more layer 2 identification IDs, wherein the ProSe UE to network relay discovery message is sent using a sidelink logical channel configured to transmit the ProSe discovery message, and the sidelink logical channel is indicated in a media access control MAC protocol data unit PDU for sending the ProSe UE to network relay discovery message; and A response to the ProSe UE-to-network relay discovery message is received, the response being received via the sidelink logical channel configured to transmit the ProSe discovery message.

20. The WTRU of claim 19, wherein the ProSe UE to network relay discovery message is transmitted via a Physical Sidelink Shared Channel (PSSCH) transmission.

21. The WTRU of claim 19, wherein the ProSe UE-to-network relay discovery message includes an indication of one or more services that the WTRU attempts to access via the UE-to-network relay.

22. The WTRU of claim 21, wherein the one or more services include one or more Vehicle-to-Everything (V2X) services.

23. The WTRU of claim 19, wherein the configuration information comprises one or more radio access parameters associated with transmissions sent to the UE to a network relay.

24. The WTRU of claim 19, wherein the configuration information includes an indication of one or more authorized public land mobile networks (PLMNs).

25. The WTRU of claim 19, wherein the sidelink logical channel configured for transmitting the ProSe discovery message corresponds to a predefined logical channel.

26. The WTRU of claim 19, wherein the sidelink logical channel configured to transmit the ProSe discovery message is associated with a preconfigured radio bearer.

27. A method implemented by a wireless transmit / receive unit WTRU, the method comprising: receiving configuration information associated with ProSe user equipment UE to network relay discovery, the configuration information comprising one or more destination layer 2 identifiers IDs for ProSe UE to network relay discovery messages; transmitting the ProSe UE to network relay discovery message using at least one identification ID of the one or more layer 2 identification IDs, wherein the ProSe UE to network relay discovery message is sent using a sidelink logical channel configured to transmit the ProSe discovery message, and the sidelink logical channel is indicated in a media access control MAC protocol data unit PDU for sending the ProSe UE to network relay discovery message; A response to the ProSe UE-to-network relay discovery message is received, the response being received via the sidelink logical channel configured to transmit the ProSe discovery message.

28. The method according to claim 27, wherein the ProSe UE-to-network relay discovery message is transmitted via a Physical Sidelink Shared Channel (PSSCH) transmission.

29. The method of claim 27, wherein the ProSe UE-to-network relay discovery message includes an indication of one or more services that the WTRU attempts to access via the UE-to-network relay.

30. The method of claim 29, wherein the one or more services include one or more vehicle-to-everything (V2X) services.

31. The method of claim 27, wherein the configuration information includes one or more radio access parameters associated with transmissions sent to the UE to a network relay.

32. The method of claim 27, wherein the configuration information includes an indication of one or more authorized public land mobile networks (PLMNs).

33. The method according to claim 27, wherein the sidelink logical channel configured for transmitting the ProSe discovery message corresponds to a predefined logical channel.

34. A discoverer user equipment device, comprising a processor, a memory, a communication circuit, and computer executable instructions stored in the memory, which, when executed by the processor, cause the discoverer user equipment device to: sending, via a sidelink communication, a discovery announcement comprising one or more destination layer 2 identifiers associated with one or more groups to which the discovering user equipment device belongs; monitoring a response to the discovery announcement from one or more discovered user equipment devices, the response being configured to include a destination layer 2 identifier from the discovery announcement; processing the response to determine compatibility of one or more discovered user equipment devices for establishing communications; as well as The responses are filtered based on criteria defined in the discovery announcement.

35. The discoverer user equipment device according to claim 34, wherein the discovery announcement further includes a service profile, and the service profile includes at least one of the following: service capabilities, service platform requirements, radio communication capabilities, or quality of service QoS standards.

36. A discovering user equipment device according to claim 34, wherein the communication circuit is further configured to send filtering parameters to one or more discovered user equipment devices, and the filtering parameters enable the one or more discovered user equipment devices to determine whether the compatibility criteria are matched.

37. A discovering user equipment device according to claim 34, wherein processing the response includes determining whether the one or more discovered user equipment devices meet at least one of radio frequency configuration requirements, group membership criteria, or V2X communication protocol compliance parameters.

38. The discovering user equipment device of claim 34, wherein the communication circuit is configured to prioritize responses from discovered user equipment devices based on a hierarchical order defined by one or more parameters in the discovery announcement.

Images