NR V2X mobility

Abstract

Mobility of a UE can have significant impact on sidelink communication and Uu mobility procedures for UEs engaged in SL communication or SL group communication. Methods are designed for optimized handover procedures, cell reselection procedures, and transition to RRC_IDLE and RRC_INACTIVE for UEs with ongoing SL communication. Methods for PLMN selection for UEs requiring sidelink communication or with active sidelink communication are disclosed herein, as well as methods for providing priority-based resource allocation while using exceptional transmission resource pools. Also, SL group management procedures are provided to handle the impact of UE mobility.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of the filing date of U.S. Provisional Patent Application No. 62 / 892,327, filed August 27, 2019, entitled “NR V2X Mobility.” BACKGROUND

[0003] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, 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 standardization of the next generation of cellular technology, referred to as New Radio (NR), also referred to as “5G.” BRIEF DESCRIPTION OF DRAWINGS

[0004] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0005] Where:

[0006] Figure 1A FIGURE 1 illustrates an example communications system.

[0007] Figure 1B , 1C And FIG. 1D is a system diagram of an example RAN and core network.

[0008] Figure 1E FIGURE 2 illustrates another example communications system.

[0009] Figure 1F FIG. 3 is a block diagram of an example apparatus or device, such as a WTRU.

[0010] Figure 1G FIG. 4 is a block diagram of an example computing system.

[0011] Figure 2 FIG. 5 illustrates an example V2X deployment.

[0012] Figure 3 FIG. 6 illustrates an example of V2X mobility.

[0013] Figure 4 FIG. 7 is an example of a call flow for V2X communications impacting cell handover.

[0014] Figure 5 FIG. 8 is an example of a call flow for V2X communications impacting cell reselection.

[0015] Figure 6 FIG. 9 illustrates an example of delayed cell reselection.

[0016] Figure 7 This is a call flow example illustrating the impact of cell handover on V2X communication.

[0017] Figure 8 This is a call flow example illustrating the impact of cell reselection on V2X communication in mode 2(d).

[0018] Figure 9 This is a call flow example of alternative solution 3 to the scheduled exception resource pool.

[0019] Figure 10 This is an example of a call flow that is split into groups for coverage.

[0020] Figure 11 This is an example of a call flow that is split into groups for scheduling efficiency.

[0021] Figure 12 The diagram illustrates multiple subgroup use cases.

[0022] Figure 13 This is an example of a call flow for subgroup reorganization.

[0023] Figure 14 This is an example of an election call flow for a new group management entity.

[0024] Figure 15 This is an example of the call flow for the election of a new scheduling entity. Detailed Implementation

[0025] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications 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), LTE-Advanced, and New Radio (NR), also known as “5G.” The development of 3GPP NR standards is expected to continue and include definitions for next-generation radio access technologies (new RATs), including new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backward-compatible radio access in the new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with varying requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with flexible radio access below 7 GHz, featuring design optimizations specific to cmWave and mmWave.

[0026] 3GPP has identified various use cases that are expected to be supported by NR, 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 (eMBB) ultra-reliable low-latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to- everything (eV2X) communications (which can include vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities). Particular services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, emergency personnel connectivity, automotive emergency call, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases and others are contemplated herein.

[0027] Figure 1A An example communications system 100 is illustrated in which the systems, methods, and apparatus described and claimed herein can be used. The communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (generally or collectively referred to as WTRUs 102 or WTRUs 102). The communications system 100 can include 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 Network Services 113. The Network Services 113 can include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, among others.

[0028] It will be recognized that the concepts disclosed herein can be utilized with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 can be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In Figure 1A In an example, each of the WTRUs 102 is configured to transmit to and / or receive from each of the base stations 114a, 114b, 114c, 114d, 114e, and / or 114f over the air interface 115 / 116 / 117 / 118 / 119. Each of the base stations 114a, 114b, 114c, 114d, 114e, and / or 114f can be any type of device configured to wirelessly communicate with the WTRUs 102 over the air interface 115 / 116 / 117 / 118 / 119. In one example, each of the base stations 114a, 114b, 114c, 114d, 114e, and / or 114f can be a base transceiver station (BTS), a Node-B, an eNode-B, a Home Node-B, a Home eNode-B, a gNB, a gNode-B, a relay node, a femto cell, a picocell, and / or the like. In another example, each of the base stations 114a, 114b, 114c, 114d, 114e, and / or 114f can be a wireless router, a wireless modem, a personal computer (PC) card, a personal digital assistant (PDA), and / or the like. Figures 1A-1EWTRUs 102a, 102b, 102c, 102d can be dispersed throughout the communications system 100, and each WTRU can be fixed or mobile. A WTRU can also be referred to or described as a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device (such as a smart watch or smart clothing), a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle (such as a small car, a bus or truck, a train, or an airplane), etc. Each WTRU can communicate with zero, one, or multiple base stations 114a, 114b, 114c.

[0029] The communication system 100 can also include base stations 114a and 114b. In Figure 1A In an example, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b can include any number of interconnected base stations and / or network elements. Base station 114a can be any type of device configured to wirelessly interface with at least one of 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, the network 113, and / or other networks 112. Similarly, base station 114b can be any type of device configured to wirelessly interface with at least one of remote radio heads (RRHs) 118a, 118b, transmission and reception points (TRPs) 119a, 119b, and / or roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. RRHs 118a, 118b can be any type of device configured to wirelessly interface with at least one of WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0030] The TRPs 119a, 119b can be any type of device configured to wirelessly interface to 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, Network Services 113, and / or other networks 112. The RSUs 120a and 120b can be any type of device configured to wirelessly interface to 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 Network Services 113. By way of example, the base stations 114a, 114b can be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node-B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.

[0031] The base station 114a can be part of the RAN 103 / 104 / 105, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Similarly, the base station 114b can be part of the RAN 103b / 104b / 105b, which can also include other base stations and / or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base station 114a can be configured to transmit and / or receive wireless signals within a particular geographic area known as a cell (not shown). Similarly, the base station 114b can be configured to transmit and / or receive wired and / or wireless signals within a particular geographic area, which can be known as a cell (not shown). The cell can further be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, for example, the base station 114a can include three transceivers, one for each sector of the cell. The base station 114a can employ multiple-input multiple-output (MIMO) technology and, thus, can utilize multiple transceivers for each sector of the cell.

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

[0033] The base stations 114a and 114b can communicate with one or more of the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b over a wired or wireless interface 115a / 116a / 117a, which can be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115a / 116a / 117a can be established using any suitable RAT.

[0034] The RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b can communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c can be established using any suitable RAT.

[0035] The WTRUs 102 can communicate with one another using direct air interface 115d / 116d / 117d, such as sidelink communication, which can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d can be established using any suitable RAT.

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

[0037] The base station 114a in the RAN 103 / 104 / 105 and WTRUs 102a, 102b, 102c, and 102g, or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and WTRUs 102c, 102d can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 115 / 116 / 117 or 115c / 116c / 117c respectively using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technology can include LTE D2D and / or V2X technology and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technology can include NR V2X technology and interfaces (such as sidelink communications, etc.).

[0038] The base stations 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f can implement radio technologies 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), GSM EDGE (GERAN), and the like.

[0039] For example, Figure 1A The base station 114c in the RAN 103 / 104 / 105 can be a wireless router, Home Node-B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a train, an airplane, a satellite, a manufactory, a campus, and the like. The base station 114c and the WTRUs 102 (e.g., WTRU 102e) can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRUs 102 (e.g., WTRU 102d) can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRUs 102 (e.g., WTRU 102e) can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114c can have a direct connection to the Internet 110. Thus, the base station 114c can not be required to access the Internet 110 via the core network 106 / 107 / 109. Figure 1A

[0040] ​The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b can be in communication with the core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, messaging, authorization, and / or authentication services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 can include a

[0041] Although not shown in Figure 1A RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, and / or the core network 106 / 107 / 109 can communicate directly or indirectly with one or more 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 can be utilizing E-UTRA radio technology, the core network 106 / 107 / 109 can also be in communication with another RAN (not shown) that employs GSM or NR radio technologies.

[0042] The core network 106 / 107 / 109 can also serve as a gateway for the WTRUs 102 to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice, video, and / or data services to users. The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP / IP internet suite. The other networks 112 can include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which can employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

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

[0044] Although Figure 1A Although not shown, it will be understood that a user equipment (UE) can establish a wired connection to a gateway. The gateway may be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It will be appreciated that many of the ideas contained herein can be equivalently applied to UEs acting as WTRUs and UEs using wired connections to connect to the network. For example, ideas applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c can be equivalently applied to wired connections.

[0045] Figure 1B This is a system diagram of example RAN 103 and core network 106. As described above, RAN 103 can use UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 1B As shown, RAN 103 may include Node-B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via air interface 115. Node-B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNC 142a and 142b. It will be appreciated that RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

[0046] like Figure 1BAs shown in FIG. 1C, the Node-Bs 140a, 140b can communicate with the RNC 142a. Also, the Node-B 140c can communicate with the RNC 142b. The Node-Bs 140a, 140b and 140c can communicate with the respective RNCs 142a and 142b via an Iub interface. The RNCs 142a and 142b can be in communication with one another via an Iur interface. Each of the RNCs 142a and 142b can be configured to control the respective Node-Bs 140a, 140b and 140c to which it is connected. In addition, each of the RNCs 142a and 142b can be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, etc.

[0047] Figure 1B The core network 106 shown in FIG. 1A can 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. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the core network operator.

[0048] The RNC 142a in the RAN 103 can also be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 can 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, 102c, and traditional

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

[0050] The core network 106 can also be connected to the other networks 112, which can include other wired or wireless networks that are owned and / or operated by other service providers.

[0051] Figure 1Cis a system diagram of an example RAN 104 and core network 107. As described above, the RAN 104 can employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 can also be in communication with the core network 107.

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

[0053] Each of the eNode-Bs 160a, 160b, and 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the downlink and / or uplink, and the like. As shown, the eNode-Bs 160a, 160b, and 160c can communicate with one another over an X2 interface. Figure 1C

[0054] Figure 1C The core network 107 as shown in FIG. 1 can include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the core network operator.

[0055] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 can 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.

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

[0057] The serving gateway 164 can also be connected to the PDN gateway 166, which can 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, 102c, and IP-enabled devices.

[0058] The core network 107 can facilitate communications with other networks. For example, the core network 107 can 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, 102c, and traditional land-line communications devices. For example, the core network 107 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 can provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which can include other wired or wireless networks that are owned or operated by other service providers.

[0059] Figure 1D is a system diagram of an example RAN 105 and core network 109. The RAN 105 can employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 can also be in communication with the core network 109. The non-3GPP interworking function (N3IWF) 199 can employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 can also be in communication with the core network 109.

[0060] The RAN 105 can include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 can include any number of gNode-Bs. The gNode-Bs 180a and 180b can each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When using integrated access and backhaul connectivity, the same air interface can be used between the WTRUs and the gNode-Bs, which can be a core network 109 via one or more gNBs. The gNode-Bs 180a and 180b can implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the gNode-B 180a, for example, can use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It will be appreciated that the RAN 105 can employ other types of base stations such as eNode-Bs. It will also be appreciated that the RAN 105 can include more than one type of base station. For example, the RAN can include eNode-Bs and gNode-Bs.

[0061] The N3IWF 199 can include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 can include any number of non-3GPP access points. The non-3GPP access point 180c can include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c can use 802.11 protocols to communicate with the WTRU 102c over the air interface 198.

[0062] Each of the gNode-Bs 180a and 180b can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the downlink and / or uplink, and the like. As shown in FIG. 1 A, the gNode-Bs 180a and 180b can communicate with one another over an Xn interface. Figure 1D

[0063] Figure 1D The core network 109 shown in FIG. 1 A can be a 5G core network (5GC). The core network 109 can provide a plurality of communication services to customers that are interconnected through a radio access network. The core network 109 includes a plurality of entities that perform the functions of the core network. As used herein, the term “core network entity” or “network function” refers to any entity that performs one or more functions of the core network. It will be appreciated that such a core network entity can be a logical entity that is implemented in the form of computer-executable instructions (software) stored in the memory of a device or computer system (such as the system 90 shown in FIG. 1 B) that is configured for wireless and / or network communications and executed on the processor(s) thereof. Figure 1G The system 90 shown in FIG. 1 B can implement a core network entity. As used herein, the term “core network entity” or “network function” refers to any entity that performs one or more functions of the core network. It will be appreciated that such a core network entity can be a logical entity that is implemented in the form of computer-executable instructions (software) stored in the memory of a device or computer system (such as the system 90 shown in FIG. 1 B) that is configured for wireless and / or network communications and executed on the processor(s) thereof.​

[0064] In Figure 1D the example of FIG. 1, the 5G core network 109 can include an Access and Mobility Management Function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPFs) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, a User Data Repository (UDR) 178. While each of the foregoing elements are depicted as part of the 5G core network 109, it will be recognized that any of these elements can be owned and / or operated by an entity other than the core network operator. It will also be recognized that a 5G core network can not be composed of all of these elements, can be composed of additional elements, and can be composed of multiple instances of each of these elements. Figure 1D The network functions are shown directly connected to each other, but it will be recognized that they can communicate via a routing agent such as a diameter routing agent or a message bus.

[0065] In Figure 1D the example of FIG. 1, connectivity between network functions is implemented via a set of interfaces or reference points. It will be recognized that network functions can be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services can be implemented via direct connections between network functions, exchange of messages passed on a message bus, calling software functions, etc.

[0066] The AMF 172 can be connected to the RAN 105 via an N2 interface and can serve as a control node. For example, the AMF 172 can be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF can be responsible for forwarding user plane tunnel configuration information to the RAN 105 via an N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via an N11 interface. The AMF 172 can generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via an N1 interface. The N1 interface is not shown in Figure 1D .

[0067] The SMF 174 can be connected to the AMF 172 via an N11 interface. Similarly, the SMF can be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 can serve as a control node. For example, the SMF 174 can be responsible for session management, IP address allocation for WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.

[0068] The UPF 176a and UPF 176b can 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 other devices. The UPF 176a and UPF 176b can also provide the WTRUs 102a, 102b, and 102c with access to other types of packet-switched networks. For example, the other networks 112 can be an Ethernet network or any type of network that exchanges packets of data. The UPF 176a and UPF 176b can receive traffic steering rules from the SMF 174 via an N4 interface. The UPF 176a and UPF 176b can provide access to packet-switched networks by connecting the packet-switched networks with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet-switched networks, the UPF 176 can be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling of user plane traffic, downlink packet buffering.

[0069] The AMF 172 can also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via a radio interface technology that is not defined by 3GPP. The AMF can interact with the N3IWF in the same or similar manner as it interacts with the RAN 105.

[0070] The PCF 184 can be connected to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not defined by 3GPP, and the PCF 184 can interact with the AMF 172 and the AF 188 in any suitable manner. Figure 1DThe PCF 184 can provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, allowing the control plane nodes to enforce the rules. The PCF 184 can send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c, so that the AMF can deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0071] The UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions so that the network functions can add to the repository, read, and modify data in the repository. For example, the UDR 178 can connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 can connect to the NEF 196 via an N37 interface, and the UDR 178 can connect to the UDM 197 via an N35 interface.

[0072] The UDM 197 can act as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can connect to the AMF 172 via an N8 interface, and the UDM 197 can connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 can connect to the AUSF 190 via an N13 interface. The UDR 178 and the UDM 197 can be tightly integrated.

[0073] The AUSF 190 performs authentication-related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.

[0074] The NEF 196 exposes capabilities and services in the 5G core network 109 to application functions (AFs) 188. The exposure can occur over an N33 API interface. The NEF can connect to the AF 188 via an N33 interface and it can connect to other network functions in order to expose capabilities and services of the 5G core network 109.

[0075] The application functions 188 can interact with network functions in the 5G core network 109. Interactions between the application functions 188 and the network functions can occur via a direct interface or can occur via the NEF 196. The application functions 188 can be considered part of the 5G core network 109 or can be external to the 5G core network 109 and deployed by enterprises that have a business relationship with the mobile network operator.

[0076] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs running across a single RAN or different service types. Network slicing enables operators to create networks that are customized to provide optimized solutions for different market scenarios that require different requirements (e.g., in terms of functionality, performance, and isolation).

[0077] 3GPP has designed the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without the use of network slicing technology, the network architecture can not be flexible and scalable enough to efficiently support the wide range of use case requirements when each use case has its own specific set of performance, scalability, and availability requirements. In addition, the introduction of new network services should be made more efficient.

[0078] Referring again to Figure 1D In network slicing scenarios, the WTRUs 102a, 102b, or 102c can connect to the AMF 172 via an N1 interface. The AMF can be logically part of one or more slices. The AMF can coordinate the WTRU's 102a, 102b, or 102c connection or communication with one or more UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and the other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in terms of the different computing resources, security credentials, etc. that they can utilize.

[0079] The core network 109 can facilitate communications with other networks. For example, the core network 109 can include, or can communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and a PSTN 108. For example, the core network 109 can include, or can communicate with, a short message service (SMS) service center that facilitates communication via the short message service. For example, the 5G core network 109 can facilitate the exchange of non-IP data packets, such as session initiation protocol (SIP) packets, between the WTRUs 102a, 102b, and 102c and server or applications functions 188. In addition, the core network 170 can provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which can include other wired or wireless networks that are owned and / or operated by other service providers.

[0080] Described herein and in theFigure 1A , 1C The core network entities shown in FIGS. 1C, 1D, and 1E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functions can be identified by other names, and that certain entities or functions can be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functions described and shown in FIGS. 1C, 1D, and 1E are provided by way of example only, and it is to be understood that the subject matter disclosed and claimed herein can be practiced in any similar communication system, whether currently defined or defined in the future. Figure 1A , 1B The particular network entities and functions described and shown in FIGS. 1C, 1D, and 1E are provided by way of example only, and it is to be understood that the subject matter disclosed and claimed herein can be practiced in any similar communication system, whether currently defined or defined in the future.

[0081] Figure 1E An example communication system 111 in which the systems, methods, apparatuses described herein can be used is illustrated. The communication system 111 can include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One, some, or all of the WTRUs A, B, C, D, E, and F can be outside the range of access network coverage 131. The WTRUs A, B, and C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members.

[0082] If WTRUs A, B, C, D, E, and F are within access network coverage 131, they can communicate with each other via the gNB 121 over the Uu interface 129. In the example shown, WTRUs B and F are shown to be within access network coverage 131. WTRUs A, B, C, D, E, and F can communicate directly with each other via a sidelink interface (e.g., PC5 or NR PC5) such as interfaces 125a, 125b, or 128, for example, that they are within or outside of access network coverage 131. For example, in the example shown, WTRU D, which is outside of access network coverage 131, communicates with WTRU F, which is inside of coverage 131. Figure 1E Figure 1E

[0083] ​​WTRUs A, B, C, D, E, and F can communicate with RSU 123a or 123b via a vehicle-to-network (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F can communicate with a V2X server 124 via a vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via a vehicle-to-person (V2P) interface 128.

[0084] Figure 1F is a block diagram of an example apparatus or device WTRU 102 that can be configured to wirelessly communicate and operate in accordance with the systems, methods, and apparatuses described herein, such as Figure 1A , 1B WTRU 102 of 1C, 1D, or 1E. As shown in Figure 1F , the example WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements, and that the base stations 114a and 114b and / or nodes that the base stations 114a and 114b can represent, such as but not limited to transceiver station (BTS), Node-B, site controller, access point (AP), home Node-B, evolved home Node-B (eNode B), home evolved Node-B (HeNB), Home eNode B gateway, next generation Node-B (gNode-B), and proxy nodes, among others, can include some or all of the elements depicted and described herein. Figure 1F some or all of the elements depicted and described herein.

[0085] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can 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 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1FThe processor 118 and transceiver 120 are depicted as separate components, but it should be recognized that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0086] The UE's transmit / receive element 122 can be configured to transmit data to the base station (e.g., via air interface 115 / 116 / 117). Figure 1A The base station 114a) transmits or receives signals from it, or transmits or receives signals to or from another UE via air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0087] Furthermore, although the transmitting / receiving element 122 is in Figure 1F While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0088] Transceiver 120 can be configured to modulate signals transmitted by transmit / receive element 122 and demodulate signals received by transmit / receive element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or via multiple beams to the same RAT at different RRHs, TRPs, RSUs, or nodes.

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

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

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

[0092] The processor 118 can further be coupled to other peripherals 138, which can 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 can include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnection modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0093] The WTRU 102 can include, among other things, 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, etc. The WTRU 102 can be connected to other components, modules, or systems of such devices via one or more interconnect interfaces, such as the interconnect interface that can include one of the peripheral devices 138.

[0094] Figure 1G is a block diagram of an example computing system 90 in which one or more devices of the communication networks shown in Figure 1A , 1C 1D and 1E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112, or network services 113. The computing system 90 can comprise a computer or server and can be controlled primarily by computer readable instructions, which can be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions can be executed within a processor 91 to cause computing system 90 to do work. The processor 91 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor that can perform additional functions or assist the processor 91. The processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and devices disclosed herein.

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

[0096] Memory that is coupled to system bus 80 includes random access memory (RAM) 82 and read only memory (ROM) 93. Such memory stores instructions and data that are meant for use by processor 91. ROM 93 is a non- volatile memory device that typically has a smaller memory storage capacity than a memory device, such as RAM 82. The memory devices provide storage of information as well as access to store and retrieve that information. RAM 82 can also comprise solid-state disk drives and / or flash memory devices. The RAM 82 stores information within the computer system 90, such as data that is being acted upon by the processor 91, as well as data used by the computer system 90 for application programs or other software routines. The ROM 93 is used to store instructions and perhaps data that are read during the boot-up of the computer system 90 and can contain CD ROM and / or DVD ROM instructions and data. The RAM 82 and / or ROM 93 can also provide storage of temporary variables or other intermediate information used during the execution of instructions by the processor 91. Access to storage elements within the RAM 82 and / or ROM 93 is typically controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and protects system processes from user processes. Thus, a program running in a first mode can only access memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between processes has been set up.

[0097] In addition, the computing system 90 can contain peripherals controller 83 responsible for communicating instructions from the processor 91 to peripherals, such as a printer 94, keyboard 84, mouse 95, and disk drives 85.

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

[0099] Further, the computing system 90 can contain communication circuitry, such as, for example, a wireless or wired network adapter 97, which can be used to connect the computing system 90 to an external communications network or device (such as the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, WTRUs 102, or other networks 112 of FIG. 1C, 1D, and 1E) to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91, can be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein. Figure 1A 、 1B The communication circuitry, alone or in combination with the processor 91, can be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0100] It should be appreciated that any one or all of the apparatuses, systems, methods, and processes described herein can be embodied in the form of computer executable instructions embodied in a computer readable storage medium, that when executed by a processor, such as processor 118 or 91, cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein can be implemented in the form of such computer executable instructions that are executed by a processor of an apparatus or computing system configured for wireless and / or wired network communications. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information such as computer readable instructions, data structures, program code, computer programs, metadata, and / or other data. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and that can be accessed by a computing system.

[0101] The following is a list of acronyms that can appear in the following description. Acronyms used herein refer to the corresponding term listed below, unless otherwise stated:

[0102] BSR Buffer Status Report

[0103] DCI Downlink Control Information

[0104] DL Downlink Link

[0105] eNB Evolved-Node-B

[0106] GME Group Management Entity

[0107] gNB NR NodeB

[0108] IE Information Element

[0109] IS Is Synchronized

[0110] L1 Layer 1

[0111] L2 Layer 2

[0112] L3 Layer 3

[0113] LTE Long Term Evolution

[0114] MAC Medium Access Control

[0115] MAC CE MAC Control Element

[0116] NR New Radio

[0117] PHY Physical Layer

[0118] PLMN Public Land Mobile Network

[0119] RAN Radio Access Network

[0120] RB Radio Bearer

[0121] RLC Radio Link Control

[0122] RLF Radio Link Failure

[0123] RRC Radio Resource Control

[0124] RS Reference Signal

[0125] RSRP Reference Signal Received Power

[0126] RSRQ Reference Signal Received Quality

[0127] RSSI Received Signal Strength Indication

[0128] RSU Road Side Unit

[0129] RX Reception

[0130] SCI System Control Information

[0131] SBSR Sidelink BSR

[0132] SPS Semi-Persistent Scheduling (also referred to as Configured Grant in NR)

[0133] SSR Sidelink SR

[0134] SI System Information

[0135] SL Sidelink

[0136] SR Scheduling Request

[0137] UE User Equipment

[0138] UL Uplink

[0139] V2X Vehicle-to-Everything

[0140] VPMLN Visited PLMN

[0141] SL group

[0142] An SL group is a number of UEs that can communicate with each other over the sidelink. An SL group can also have a group management entity.

[0143] Group mobility

[0144] Group mobility can indicate SL group mobility - when group members move, the SL group can also move.

[0145] Group topology

[0146] Group topology can indicate SL group configuration - when group members move, the shape or topology of the SL group can also change. For example, all member UEs can be on a single-lane road, or all member UEs can bunch up at a multi-lane intersection.

[0147] Member UE

[0148] Member UE is a UE that can be part of a SL group.

[0149] Control entity

[0150] Control entity can be an entity that provides radio resource control to the UEs involved in SL communication.

[0151] Scheduling entity

[0152] Scheduling entity can be an entity that allocates resources for SL communication if SL communication uses a scheduled allocation mode. Two types of scheduling entities can be defined: SL-based scheduling entity and Uu-based scheduling entity. SL-based scheduling entity can communicate with the UEs it is scheduling via sidelink. In this case, the scheduling entity can be another UE or RSU. Uu-based scheduling entity communicates with the UEs it is scheduling via Uu interface. In this case, the scheduling entity can be a gNB.

[0153] Group management entity

[0154] Group management entity can be an entity that performs group management functions, including group formation (e.g., initial group formation, subgroup formation, subgroup leader selection / election), group member addition, group member removal, or group disbanding.

[0155] Unscheduled sidelink transmission

[0156] Unscheduled sidelink transmission can be a sidelink transmission that relies on resource allocation mode 2(a). Such transmission can be based on sensing and the UE can autonomously make scheduling decisions.

[0157] Scheduled sidelink transmission

[0158] Scheduled sidelink transmission can be a sidelink transmission that relies on resource allocation mode 1 or mode 2(d). Such transmission is either scheduled by a gNB or by a scheduling entity.

[0159] SL communication

[0160] SL communication can be a sidelink communication between two peer UEs.

[0161] SL group communication

[0162] SL group communication can be a sidelink communication between more than two UEs. The transmission between groups can be unicast, groupcast or broadcast.

[0163] As used herein, the terms “SL communication” and “SL group communication” can refer to any direct communication between two or more UEs. For example, such direct communication can involve communication between two or more UEs associated with vehicle-to-everything (V2X), non-V2X, or pedestrian-to-everything (P2X).

[0164] LTE V2X mobility and NR V2X mobility

[0165] An NR UE can support one of the following resource allocation modes:

[0166] • Mode 1, in which a base station (e.g., gNB) can schedule SL resource(s) for a UE for SL transmission(s);

[0167] • Mode 2(a), in which a UE can determine (i.e., base station cannot schedule) SL transmission resource(s) within SL resources configured by a base station / network or pre-configured SL resources. The UE can autonomously select SL resources for transmission;

[0168] • Mode 2(c), in which a UE can determine (i.e., base station cannot schedule) SL transmission resource(s) within SL resources configured by a base station / network or pre-configured SL resources. The UE can be configured with a NR configured grant (e.g., Type-1, etc.) for SL transmission; and

[0169] • Mode 2(d), in which a UE can determine (i.e., base station cannot schedule) SL transmission resource(s) within SL resources configured by a base station / network or pre-configured SL resources. The UE can schedule SL transmission of other UEs. The UE can be provided with a set of resources it can allocate for SL transmission.

[0170] LTE SL resource configuration can be provided through (pre-)configuration, or through system information or through dedicated signaling. The SL resource configuration can contain information about resource pools, such as a reception pool, a normal transmission pool, and an exceptional transmission pool.

[0171] The exceptional transmission resource pool can be used during a period when a UE can not be ready to use the normal transmission pool. This can occur when:

[0172] • The UE can have radio connectivity issues with its serving cell;

[0173] • The UE has been instructed to perform a handover but has not yet synchronized with the target cell; and

[0174] • The UE has performed cell reselection to a new cell and is waiting for SL sensing results.

[0175] The following guidelines have been agreed for NR V2X Uu mobility procedures.

[0176] • The network can provide resource pools where the UE can autonomously select a sidelink grant for a sidelink unicast, groupcast or broadcast via broadcast system information and / or dedicated signaling.

[0177] • During handover, the transmission and reception of V2X SL communications can be performed based at least on the configuration of the exceptional transmission resource pool and reception resource pool of the target cell that the UE can use during handover, which can be provided in the handover command.

[0178] • Cell selection and reselection for V2X SL communications can be performed based on at least the following criteria and configurations:

[0179] - The carrier frequencies where V2X SL resource configurations or inter- frequency configurations can be provided can be (pre)configured;

[0180] - The frequencies providing inter-frequency V2X SL configurations can be prioritized during cell (re)selection; and

[0181] - How to minimize the interruption of V2X SL transmission and reception during cell reselection depends on the UE implementation.

[0182] The UE can have multiple simultaneous sidelink communications. The SL communications can be unicast, groupcast or broadcast. Each of these can be configured as a SL RB.

[0183] Problem statement

[0184] Due to UE mobility, SL communication between two UEs or a group of UEs can change topology. For example, for a group of UEs constituting a platoon, the group topology can change when the UEs move from a single lane to a two-lane road, or when the UEs take a turn on the road. In addition, the group can also move. Using the same platoon example, as the UEs travel along the road, the actual platoon or group also travels along the road. Therefore, it can be expected that the UEs involved in the SL communication must handle multiple mobility events. These mobility events can include, for example, cell reselection, handover, or moving out of coverage. If not handled with care, SL communication can struggle to support the diversity and stringent QoS requirements of certain sidelink services. Therefore, the following problems can be addressed.

[0185] Problem 1: Impact of V2X on UE mobility procedures

[0186] Today, V2X communication and UE mobility behavior are not tightly linked in the specifications. It is expected that a UE that can only use a certain frequency for SL transmission will prioritize that frequency during inter-frequency cell reselection. However, the impact of V2X communication on procedures such as PLMN selection, paging, or reading system information has not been considered. In addition, V2X communication can offer certain possibilities for optimization of UE mobility procedures.

[0187] Problem 2: Impact of mobility events on V2X communication

[0188] Mobility events are unavoidable, but their impact on V2X communication can be minimized. For example, mobility events typically result in the UE having to change its TX resource pool and RX resource pool. Dynamically changing resource pools can have an impact on communication on the sidelink, especially in the case of scheduled sidelink transmissions. In addition, these mobility events are typically characterized by small periods in which the UE is not ready or cannot use the allocated resource pool. In such cases, the UE is expected to use exceptional resource pools. However, these pools can rely on random access for resource selection and can negatively impact the QoS of SL services.

[0189] Problem 3: Impact of V2X mobility on group management

[0190] Some V2X services are inherently group-based, such as cars in a platoon setup. Due to the mobility of the UEs, multiple triggers will change the dynamics of the group - and this happens frequently. When the dynamics of the group change, SL communication degrades. Each trigger can require a unique set of actions to cope with the SL performance degradation.

[0191] ABSTRACT

[0192] UE mobility can have a significant impact on sidelink communication between peer UEs as well as on SL group communication among a group of UEs. Moreover, since these mobile UEs can be involved in SL communication or SL group communication, their Uu mobility procedures are also impacted. This application discloses systems and methods for optimizing handover procedures for UEs with ongoing SL communication, cell reselection procedures for UEs with ongoing SL communication, and transition of UEs with ongoing SL communication to RRC_IDLE and RRC_INACTIVE. Also, systems and methods for PLMN selection for UEs requiring sidelink communication or having active sidelink communication, and systems and methods for providing priority-based resource allocation while using exceptional transmission resource pools are disclosed. Moreover, SL group management procedures to handle the impact of UE mobility are disclosed herein.

[0193] Network architecture with V2X mobility

[0194] A UE communicating over SL can communicate over a unicast link, a groupcast link, or a broadcast link. For some V2X services, SL communication between only two UEs can be required, and typically such communication is unicast. For other V2X services, SL communication between one UE and multiple other UEs - which form a group - can be required. For example, in a platooning scenario, SL communication between all UEs in the platoon can be required. In this case, SL communication between group members can be unicast, groupcast, broadcast, or any combination of these links - i.e., unicast links to some UEs and groupcast links to other UEs. A UE communicating over SL can be out of coverage of a cellular network or in coverage of a cellular network. A UE that can be in coverage also has a Uu interface to the serving cell.

[0195] When we have V2X mobility, multiple entities can be required to assist or allow proper SL communication. These entities can be a scheduling entity, a control entity, and a group management entity, as briefly described below.

[0196] If SL communication uses a scheduled allocation mode, then a scheduling entity can be an entity that allocates resources for SL communication. The scheduling entity can be connected to UEs involved in SL communication over an SL interface (e.g., another UE or RSU) or over a Uu interface (e.g., gNB or RSU). Either interface (SL or Uu) can be through a relay node. The former can be referred to as an SL-based scheduling entity, while the latter can be referred to as a Uu-based scheduling entity. Alternatively, the scheduling entity can be one of the UEs involved in SL communication. If SL communication uses an unscheduled allocation mode, then a scheduling entity can not be required for that communication.

[0197] The control entity can be an entity that provides radio resource control to the UEs involved in the SL communication. This can include, for example, assigning TX resource pool, RX resource pool, or synchronization information. The control entity can be connected to the UEs participating in the SL communication through an SL interface (e.g., the control entity is another UE or RSU) or through a Uu interface (e.g., the control entity is a gNB or RSU). Either interface (SL or Uu) can be through a relay node. The former can be referred to as SL-based control entity, while the latter can be referred to as Uu-based control entity. Alternatively, the control entity can be one of the UEs participating in the SL communication.

[0198] The group management entity can be an entity that performs group management functions, including, for example, group formation (e.g., initial group formation, subgroup formation, subgroup leader selection / election), group member addition / removal, and group disbanding. The subgroup leader can act as a relay for the subgroup. The group management entity can have context about the group, such as an entity acting as a scheduling entity or a control entity for each group member. The group management entity can be connected to the UEs participating in the SL communication through an SL interface (e.g., another UE or RSU) or through a Uu interface (e.g., a gNB or RSU). Either interface (SL or Uu) can be through a relay node. The former will be referred to as SL-based group management entity, while the latter will be referred to as Uu-based group management entity. The group management entity can also have control entity functions, providing radio resource control for all members of the group.

[0199] Figure 2 An example V2X deployment is shown in FIG. 1. Figure 2 SL communication cases (SL between 2 UEs) and SL group communication cases are shown. In the latter, the SL transmission is between one UE and K other UEs (K > 1). Figure 2 All UEs in FIG. 1 can be within the coverage of a serving cell or outside the coverage. UE1 and UE2 can communicate through unicast SL. As shown, these UEs can be scheduled by a scheduling entity and can be controlled by a control entity. The scheduling entity and the control entity can be in the same physical node, e.g., in a gNB. UE3, UE4, UE5, UE6 form a group. UE5 can send SL transmissions to UE3 and UE4 using groupcast and can send SL transmissions to UE6 using unicast. As shown, the group can be controlled by a group management entity and the communication within the group can be scheduled by a scheduling entity. The group management entity and the scheduling entity can be a function of one of the UEs of the group, e.g., UE4 can host the group management entity. The group management entity and / or the scheduling entity can also be hosted in another UE (e.g., UE7). In this case, UE7 can be part of the group to allow proper control and scheduling of group transmissions.

[0200] Although entities can be described herein individually, it should be understood that the functionality associated with each of these entities can be shared among one or more physical entities.

[0201] Due to UE mobility, SL communication between two UEs or a group of UEs can change topology. For example, for a group of UEs that can make up a platoon, the group topology can change when the UEs move from a single lane to a two-lane road or when the UEs pass a bend on the road. In addition, the group can also move. Using the same platoon example, as the UEs travel along the road, the platoon or group effectively travels along the road as well. Finally, each UE can transition between different RRC states. For example, the state between RRC IDLE, RRC INACTIVE, RRC CONNECTED changes when the UE transmission requirements on the Uu interface change. A typical V2X mobility example is shown in Figure 3 .

[0202] Due to UE mobility, events such as topology change of the UEs or dynamic RRC state change of the UEs can occur. Such events can include the following events.

[0203] • A UE can change its serving cell; for UEs in RRC IDLE and RRC CONNECTED modes.

[0204] • A UE in-coverage can fall out-of-coverage (and vice versa).

[0205] • A UE can change its configured TX resource pool. The resource pool can change depending on the following factors: geographical zone when out-of-coverage, serving cell, validity area (if SL configuration is preserved across all cells of the validity area), in-coverage versus out-of-coverage, RRC state (IDLE versus INACTIVE versus CONNECTED).

[0206] • A UE can use exceptional TX resource pools. These resource pools can be used when the UE encounters some problems on its radio link with the serving cell, during the transition from RRC IDLE to RRC CONNECTED, during the handover procedure, during cell reselection, when sensing results are not available, etc.

[0207] • A UE can lose the right to transmit on the SL. This can happen, for example, in IDLE mode when the UE performs a periodic PLMN search and selects a PLMN that does not allow SL communication. This can also happen in IDLE mode when the UE performs inter-frequency cell reselection to a frequency that does not support SL communication. This can also happen in CONNECTED mode when the UE performs inter-frequency handover to a frequency that does not support SL communication. This can also happen when the UE moves to a geographical area (zone) that does not allow SL communication.

[0208] • A UE can lose SL connectivity to each other. This can be based, for example, on the distance or interference between UEs. A UE can lose connectivity to a group management entity, a scheduling entity, a controlling entity, or other UEs with which it communicates on the SL.

[0209] The above described events can result in problems associated with SL communication, described with respect to three deployment options: out-of-coverage, partial coverage, in-coverage. For each of these options, tables are presented below that describe the problems that can occur when one or more of the above events occur and the corresponding solutions. As disclosed herein, it can be assumed that a SL group has been established by a group management entity in the case of SL communication between a group of UEs, it has been selected whether the group must be divided into subgroups, it has been determined the communication mode to be used in the group, and one or more scheduling entities for the group.

[0210] In an out-of-coverage deployment, all UEs involved in SL communication can be out of coverage of a cell that supports SL communication. Table 1 describes potential problems for SL group communication where SL communication is between more than two UEs. Table 2 describes potential problems for SL communication where SL communication is between two UEs.

[0211] Table 1: Potential problems for SL group communication when more than two UEs can be out of coverage

[0212]

[0213] Table 2: Potential problems for SL communication when two UEs can be out of coverage

[0214]

[0215]

[0216] In an in-coverage deployment, all member UEs can be in coverage of a cell that supports SL communication. Table 3 describes potential problems for SL group communication where SL communication is between more than two UEs. Table 4 describes potential problems for SL communication where SL communication is between two UEs.

[0217] Table 3: Potential issues for SL group communication when more than two UEs can be in coverage

[0218]

[0219]

[0220] Table 4: Potential issues for SL communication when two UEs can be in coverage

[0221]

[0222]

[0223] In partial coverage deployments, some UEs can be in coverage of a cell that supports SL communication, while the remaining UEs can be out of coverage of a cell that supports SL communication. In this case of SL group communication, the group can have been split into two subgroups, as the UEs will not be able to use the same TX resource pool - one subgroup for in-coverage UEs, and a second subgroup for out-of-coverage UEs. Table 5 describes potential issues for SL group communication, where SL communication is among more than two UEs. Table 6 describes potential issues for SL communication, where SL communication is between two UEs.

[0224] Table 5: Potential issues for SL group communication when more than two UEs can be in partial coverage

[0225]

[0226]

[0227] Table 6: Potential issues for SL communication when two UEs can be in partial coverage

[0228]

[0229]

[0230] Solutions are proposed below for the three issues of impact of V2X on UE mobility procedures, impact of mobility events on V2X communication, and impact of V2X mobility on group management.

[0231] Solution for Issue 1: Impact of V2X on UE mobility procedures

[0232] To support the solution for Issue 1, the UE can provide the SL communication context to its serving gNB. This context can be used by the gNB to assist SL communication during mobility events. The UE can provide the following information to the gNB:

[0233] • Resource allocation mode used by the UE: Mode 1, Mode 2, both Mode 1 and Mode 2;

[0234] • In case the UE has a special SL role - the UE acts as a scheduling entity, a controlling entity or a group management entity - the UE can provide an indication of the number of UEs it is controlling, scheduling or managing;

[0235] • Number of SL RBs;

[0236] • Broadcast type for each SL RB (e.g., unicast, groupcast, broadcast) and size of the group for groupcast;

[0237] • For each SL RB, an indication whether this SL RB should be transferred to the target cell (some SL RBs can be dropped or released at cell handover, cell reselection, transition to RRC_IDLE or transition to RRC_INACTIVE);

[0238] • For each SL RB, the scheduling entity, the controlling entity or the group management entity of the UE; and

[0239] • RLC mode for each SL RB.

[0240] In case the mobility event is a handover event, UE1 and UE2 can be involved in SL communication, and then UE2 can experience a cell handover from the source cell to the target cell. The impact of V2X communication on cell handover is illustrated by the call flow shown in Figure 4 In Figure 4 In step 1, UE2 can send a measurement report to gNB1. The report can indicate that it would be better for the UE to be served by the target cell than the current source cell. The target cell can be “better” than the source cell based on a measurement quantity (e.g., RSRP, RSRQ or SINR) or based on an event (e.g., when the measurement quantity of the source cell is above or below a threshold, when the measurement quantity of the target cell is above or below a threshold, or when the measurement quantity of the target cell becomes better than the source cell by an offset (see specification 38.331)). In step 2, gNB1 can decide to handover UE2 to gNB2. Thus, in step 3, gNB1 can send a handover command to gNB2. This command can include an indication of the requirements for the SL communication between UE1 and UE2 or any other assistance information such as the location and at least for periodic traffic: traffic periodicity, timing offset and message size. Furthermore, gNB1 can include information related to the sidelink communication of UE2. This can include:

[0241] • Resource allocation mode used by the UE: Mode 1, Mode 2, both Mode 1 and Mode 2;

[0242] • SPS configured for UE sidelink transmissions in case of mode 1 or (mode 1 and mode 2 simultaneously), received measurement results for sidelink transmissions, and available scheduling information for the UE (e.g., pending SR, BSR reports);

[0243] • Broadcast type (unicast, groupcast, broadcast) for each SL RB, where for groupcast it can provide the size of the group;

[0244] • If the UE has a special SL role - the UE acts as a scheduling entity, control entity or group management entity - the UE can provide an indication of the number of UEs it is controlling, scheduling or managing;

[0245] • For each SL RB, an indication whether this SL RB should be transferred to the target cell (some SL RBs can be dropped or released at cell handover); and

[0246] • For each SL RB, the UE’s scheduling entity, control entity or group management entity.

[0247] In step 4, if gNB2 accepts the handover request, it can send a handover response. This response message can include SL configuration details to be used in the target cell. Including new TX resource pools and potentially configured grants to be used in the target cell. gNB2 can store the obtained UE context (e.g., measurements, scheduling). The handover response can include:

[0248] • A list of SL RBs to be transferred to the new cell;

[0249] • A list of SL RBs to be dropped by the UE;

[0250] • SL resource configuration for each SL RB, including any new / modified SRS for that SL RB;

[0251] • For each transferred SL RB, the identity of the UE’s new scheduling entity, control entity or group management entity; and

[0252] • For each SL RB, the mechanism for resource reselection (e.g., random or scheduled) during the exceptional resource pool phase.

[0253] In step 5, UE2 can receive the handover response from gNB1. UE2 can then detach from the source cell in step 6 and can start synchronizing with the target cell. UE2 can also update its SL communications based on the new SL configuration details included in step 5. Next, in step 7, once synchronized to the target cell, UE2 can send a handover confirmation to gNB2.

[0254] In case the mobility event is a cell reselection event, UE1 and UE2 can be involved in SL communication and UE2 can experience cell reselection from the source cell to the target cell. The impact of V2X communication on cell reselection is illustrated by the call flow shown in Figure 5 Fig. 1. Figure 5 In step 1 of Fig. 1, UE2 can perform intra- and inter- frequency measurements based on a set of standardized rules. Then, in step 2, UE2 can rank the cells. If one cell is better than the current cell for Treselection RAT , UE2 can reselect this cell. To delay the impact of cell reselection on any ongoing sidelink communication, UE2 is preferably allowed to stay longer in the source cell. If UE2 has SL RBs (requiring low latency), it can scale Treselection RAT based on the following:

[0255] • the number of SL RBs for the UE;

[0256] • the priority of the SL RBs;

[0257] • the latency requirement of the SL RBs, e.g., scale Treselection RAT only when the SL RBs require low latency; and

[0258] • the activity on any SL RB, e.g., UE2 can be waiting for feedback from a peer UE or waiting for HARQ feedback from a peer UE or have a configured SL grant.

[0259] Alternatively, the threshold can be modified. For example, the threshold related to Qoffset can be scaled.

[0260] Next in step 3, UE2 can synchronize to the selected cell. In step 4, UE2 can read the system information of the selected cell (it can get SL resource configuration). This system information can include exceptional and normal resource pool information. In step 5, UE2 can start using SL transmission on the exceptional resource pool. Then, in step 6, UE2 can perform SL sensing to help resource selection. When the sensing result is ready, in step 7, UE2 can start using SL transmission on the normal TX resource pool.

[0261] Note that during the interval between step 3 and step 5, UE2 can not be able to transmit on SL because UE2 does not have SL resource configuration for the target cell. The following alternatives can be performed.

[0262] • The SL resource configuration for the target cell is carried in the neighbor cell information of the source cell. This can be through broadcast system information or through dedicated signaling. This can also include an indication that the exceptional resource pool is common between the source cell and the neighboring cell.

[0263] • UE2 can move to RRC CONNECTED mode in the source cell to retrieve this information before performing cell reselection. UE2 can retrieve this information for selected neighbor cells, e.g., those whose cell ranking indicates that cell reselection is likely. This can be a new trigger for the UE to move to connected mode - e.g., to retrieve neighbor cell SL configuration information for SL connection.

[0264] • The exceptional resource pool is common across validity areas. UE2 can be informed that the exceptional resource pool is common across validity areas. If the target cell is in this validity area, UE2 can not need to wait to read SI before using the exceptional resource pool.

[0265] Note that UE2 can need to use the exceptional resource pool during the interval between step 5 and step 7. This can be when UE2 performs SL sensing to aid resource selection. This sensing time can be reduced by having UE2 obtain sensing information from peer UEs. Using the exceptional resource pool, UE2 can request that peer UEs share their sensing information. UE2 can request peer UEs that it already has a connection with, or it can send a broadcast sidelink message to request the help of other UEs. This message can include the cell IDs that it wants sensing results for.

[0266] Note that during step 2, if the target cell is ranked better than the current cell within Treselection RAT period, then reselect the target cell. The reselection decision can not be based on any activity on the sidelink. In an alternative, the reselection can be delayed to a period of low SL activity. For example, there can be intervals or time periods that UE2 knows that it will not be involved in any sidelink communication. This can be based on configured grants, sensing, or SL configuration details. After triggering cell reselection, UE2 can decide to delay cell reselection to these time periods, e.g., as depicted in Figure 6 .

[0267] Note that UE2 can also evaluate how much time is left until the next possible or expected UE2 SL transmission. If this time is long enough, UE2 can decide to perform cell reselection immediately after the trigger. In addition, UE2 can be configured with a maximum reselection delay timer. If this timer expires, UE2 can decide to perform cell reselection regardless of SL activity.

[0268] Note that in Figure 5During steps 1 and 2, UE2 can also perform measurements and can rank inter- frequency cells as part of the cell reselection procedure. It is expected that if a UE requires SL services and SL communication is only available on certain frequencies, then this UE will prioritize those frequencies for cell reselection. In case of multiple frequencies supporting SL communication, a problem arises if a UE with ongoing SL communication on one frequency (fl) reselects to a new frequency (f2). In this case, the ongoing communication with the peer UE on frequency fl will be interrupted. Therefore, it is proposed to change the cell reselection rules for inter-frequency cells. Namely, if a UE has any ongoing sidelink transmission on a certain frequency, then this frequency is the highest priority. This can also be based on the type of SL RB. For example, some SL RBs can require continuity at cell reselection, while others can use exceptional resource pools or declaration of SL radio link failure (RLF).

[0269] The mobility event can be an event of transition to RRC_IDLE or RRC_INACTIVE state. The network can release the UE RRC connection and transition the device to RRC_IDLE or RRC_INACTIVE. The UE can receive an RRCRelease message with a redirectedCarrierlnfo information element (IE). This IE can provide the UE with information related to the cell to camp on. If the UE has ongoing SL RBs in RRC_CONNECTED, the network can provide additional information in the redirectedCarrierlnfo information element (IE) to assist SL communication during the transition from RRC_CONNECTED to RRC_IDLE / RRC_INACTIVE. For example, the IE can include one or more of the following:

[0270] • a list of SL RBs that can be redirected to a new carrier;

[0271] • a list of SL RBs that can be dropped and cannot be redirected to a new carrier, e.g., some SL RBs can operate only on mode 1 and can be dropped after moving to RRC_IDLE or RRC_INACTIVE;

[0272] • the identity of the new scheduling entity, control entity or group management entity of the UE for each transferred SL RB; and

[0273] • for each SL RB, the mechanism for resource reselection during the exceptional resource pool phase (e.g., random or scheduled).

[0274] A mobility event can be an event of PLMN selection. In some cases, a PLMN can not support SL communication. UEs of these operators can still want to use SL communication. One option is to allow UEs to roam on a visited network in order to use SL communication. In this case, the first operator can not want to support SL communication, and it can have an agreement with a second co-located operator that supports SL communication. The second operator can allow UEs of the first operator to roam onto its network in order to use SL communication. Current PLMN selection does not allow UEs to select the network of the second operator.

[0275] In other cases, when a UE is in a VPLMN, it can try to find its home PLMN or an equivalent home PLMN. If one or more of the equivalent home PLMNs do support SL communication, and the UE intends to use SL communication, then the UE should avoid these as much as possible during its periodic PLMN search.

[0276] It is proposed herein that if a UE has an active SL RB or intends to use SL communication, then it should try to select a PLMN that supports SL communication. For example, during a periodic PLMN search, such a UE would not consider a PLMN in the list of equivalent PLMNs that does not support SL communication. Alternatively, these PLMNs can be de-prioritized with respect to PLMNs that do support SL communication.

[0277] To support the above, it is proposed herein that a cell broadcasts SL communication support in system information. For example, in SIB1, as part of the PLMN-IdentitylnfoList IE ( SL Communication Support ) :

[0278]

[0279] Solution to problem 2: impact of mobility events on V2X communication

[0280] In the case where the mobility event is a cell handover, UE1 and UE2 can be involved in SL communication, and UE2 can experience a cell handover from a source cell to a target cell. The impact of the cell handover on V2X communication is illustrated by the call flow shown in Figure 7 Figure 7 ​In step 1 of Figure 1, UE2 can send a measurement report to gNBl. This report can indicate that the target cell is better than the current source cell. In step 2, gNBl can decide to handover UE2 to gNB2. Then, in step 3, gNBl can send a handover command to gNB2. This command can include an indication of requirements for SL communication between UE1 and UE2 or any other assistance information such as location and information for periodic traffic such as traffic periodicity, timing offset and message size. In step 4, if gNB2 accepts the handover request, it can send a handover response. This response message can include SL configuration details to be used in the target cell including new TX resource pool and configured grants that can be used in the target cell.

[0281] In step 5, UE2 receives the handover command from gNBl. Then, in step 6, UE2 can detach from the source cell and can start trying to synchronize with the target cell. During this time, the UE can use the exceptional resource pool of the target cell. UE2 can obtain this information from the handover command of step 5. Once synchronized to the target cell, in step 7, UE2 can send a handover confirmation to gNB2.

[0282] Reference Figure 7 With option A in Figure 2, UE2 can use a new scheduling entity, for example this can be gNB2 or another UE that can also be served by gNB2. In this case, the old scheduling entity can have a scheduling context for UE2 sidelink transmissions. For example, this context can include active or ongoing SPS assigned to UE2, any pending BSR received from UE2, any pending SR received from UE2, or any SL related measurements received from UE2 and maintained at the scheduling entity. This context can be provided to the new scheduling entity. The following alternatives are disclosed herein.

[0283] • In step Al, gNBl can retrieve UE2 scheduling context from the old scheduling entity if necessary.

[0284] • In step A2, the old scheduling entity can stop scheduling resource allocation for UE2. This can include releasing any configured grant resources allocated to UE2. After scheduling stops, the context information can be maintained in the old scheduling entity for a certain period of time in case the handover to the target cell fails. This can be timer based. Once the timer expires, the old scheduling entity can remove the UE2 scheduling context.

[0285] • In step A3, gNBl can send the UE2 scheduling context to gNB2. The transmission mechanism can be the same as the one used for the transmission of the message in step 3.

[0286] • In step A4, gNB2 can forward the UE2 scheduling context to the new scheduling entity.

[0287] • In step A5, the scheduling entity can wait for an indication that the handover of UE2 has been completed before starting to schedule resources for UE2. This message can come from UE2 (e.g. upon reception of an SR or BSR from UE2). Alternatively, this indication can come from gNB2. Upon reception of the handover confirmation from UE2, gNB2 can send a message (start indication) to the new scheduling entity to start.

[0288] Note that the exchanges described in steps Al, A4, A5 can be internal to gNB2, e.g. if gNB2 hosts the scheduling entity for SL communication between UE1 and UE2. Alternatively, if the scheduling entity is another UE, then these exchanges can be implemented as PC5 RRC, MAC CE, SCI or a combination of these.

[0289] In case the mobility event is a cell reselection event, UE1 and UE2 can be involved in the SL communication. UE2 can be in RRC IDLE state and UE2 can experience a cell reselection from an old cell to a new cell. In such cases, a problem arises when UE2 uses a mode 2(d) type of resource allocation (where the scheduling entity is another UE). The impact of cell reselection on V2X communication of mode 2(d) is illustrated by the call flow shown in Figure 8

[0290] In step 1 of Figure 8 , UE2 can perform measurements on neighbor cells. Then, in step 2, UE2 can determine whether to reselect to a new cell. In step 3, UE2 can read the system information of the new cell. As part of this step, UE2 can be provided with TX resource pools to use in this cell. In step 4, UE2 can sense the channel and can use exceptional resource pools until it can get sensing results. UE2 can select a scheduling entity in the new cell in step 5. UE2 can be provided with the identity of the scheduling entity as part of the system information broadcast in the new cell (in step 3). Alternatively, UE2 can perform discovery to determine which UE in the vicinity is acting or willing to act as a scheduling entity.

[0291] ​In step 6, UE2 can request the selected scheduling entity (new scheduling entity) to start scheduling it. UE2 can also provide some scheduling context, as well as the identity of the UE (old scheduling entity) performing scheduling in the old cell. In step 7, the new scheduling entity can retrieve the remaining UE2 scheduling context from the old scheduling entity, if necessary. This transfer can be over the sidelink. Then, in step 8, the old scheduling entity can stop scheduling resource allocation for UE2. This can include releasing any configured grant resources allocated to UE2. After scheduling is stopped, the context information can be maintained in the old scheduling entity for a period of time in case UE2 returns to the old cell. This can be based on a timer. Once the timer expires, the old scheduling entity can remove the UE2 scheduling context. In step 9, the old scheduling entity can return the UE scheduling context to the new scheduling entity, and in step 10, UE2 can be scheduled from the new scheduling entity.

[0292] The use of exceptional resource pools is next disclosed. In Figure 7 and Figure 8 After a mobility event, for a period of time, SL communication can rely on exceptional resource pools. These are resource pools that can be shared by all SL UEs, and are intended to provide some continuity for SL communication during a period of time where the UE does not know which TX resource pool to use. In particular, Figure 7 A case is shown where UE2 has received a handover command to move to a target cell, but has not yet synchronized to this target cell. Similarly, Figure 8 A case is shown where UE2 has reselected a new cell, but has not yet received sufficient sensing results from this cell to make proper resource allocation. In addition to these two cases, there can be other cases where exceptional resource pools are used, for example, the UE assesses that its radio quality to the serving cell is poor.

[0293] Since the use of exceptional resource pools can be expected to be based on random access, this can cause problems for SL services that require a certain level of guaranteed performance or QoS. As with any random access based scheme, the expected performance is expected to further degrade as the density of SL UEs increases. In this application, three alternative schemes are proposed to help maintain QoS requirements during periods of time where a UE can use exceptional resource pools. Aspects are disclosed herein of using modified or alternative resource allocation mechanisms with exceptional resource pools.

[0294] The first alternative can include partitioning the exceptional resource pool into priority-based sub-pools. In this approach, the exceptional resource pool can be partitioned into sub-pools, and traffic can be isolated into each of these sub-pools. The UE can be (pre)configured with a set of one or more sub-pools. Each sub-pool can have an associated priority. For example, the priority can be based on the logical channel priority of the sidelink radio bearer. A sub-pool with a certain priority can only serve traffic from logical channels of the same or higher priority. Alternatively, the exceptional resource pool can be partitioned into a high-priority sub-pool and a low-priority sub-pool. The UE can be (pre)configured with a mapping of logical channel priority to sub-pool. The UE can select the appropriate sub-pool based on the priority of the SL service. The UE can then randomly select a resource for transmission from the selected sub-pool.

[0295] The second alternative can include using a prioritized resource selection strategy. In this approach, a single exceptional resource pool can be (pre)configured, and the random selection of resources within this pool can be prioritized in an effort to support higher priority sidelink traffic. The UE can be (pre)configured with a set of one or more resource selection probabilities (P_res). Each of these probabilities can be associated with one or more priorities. These priorities can be based on the logical channel priority of the sidelink radio bearer. For example, when the UE has sidelink traffic to send and can need to use the exceptional resource pool, the UE can select the next available resource with probability P_res.

[0296] The third alternative can include designating a scheduling entity for the exceptional resource pool. In this approach, the resource allocation on the exceptional resource pool can be scheduled by a dedicated scheduling entity. It is generally expected that the scheduling entity in question is a gNB, but it can also be another UE. The details of this approach are shown in Figure 9 and further described below. Assume that UE1 and UE2 are communicating over the sidelink, and the traffic can require low latency.

[0297] In step 1 of Figure 9 , UE1 can receive a trigger to move to the exceptional resource pool. For example:

[0298] • UE1 can have just received a handover command to move to a new serving cell. It uses the exceptional resource pool until UE1 synchronizes to the new cell and confirms the handover;

[0299] • UE1 can have just performed a cell reselection to a new target cell and is waiting for the sensing results before performing autonomous resource selection;

[0300] • UE1 can have encountered radio link problems on its serving cell (UE1 lost synchronization); and

[0301] • UE1 can just move from RRC IDLE to RRC CONNECTED.

[0302] In step 2, a higher layer (e.g. an application) at UE1 can generate a packet to be transmitted to UE2. Then, in step 3, UE1 can transmit a Sidelink Scheduling Request (SSR) to the exceptional pool scheduling entity over the sidelink using the exceptional resource pool. The identity of the exceptional pool scheduling entity can be provided by:

[0303] • through configuration or pre-configuration;

[0304] • in the system information of the serving cell;

[0305] • in the system information of the target cell (e.g. in case of cell reselection);

[0306] • in dedicated signaling from the serving cell (in RRC messages such as RRCConnectionSetup or RRCConnectionReconfiguration, or in MAC CE); or

[0307] • in dedicated signaling from the target cell (e.g. in HANDOVER COMMAND included in RRCConnectionReconfiguration).

[0308] The Sidelink Scheduling Request can be transmitted using a PSCCH with a new dedicated SCI format. The SSR can include an indication that UE1 can want to be scheduled so that it can transmit a Sidelink Buffer Status Report (SBSR) to the exceptional pool scheduling entity. The SSR can also include an indication of the identity of UE1 (e.g. the source Layer 1 ID of UE1).

[0309] In step 4, the exceptional pool scheduling entity can allocate resources to UE1 for the transmission of SBSR. These resources can be outside the exceptional resource pool. The exceptional pool scheduling entity can allocate enough resources for SBSR transmission. This can be signaled to UE1 by a new SCI format. In step 5, UE1 can send SBSR to the exceptional pool scheduling entity using the allocated resources. SBSR can be a new MAC CE. SBSR can include, for example, an indication of buffer status, an indication of destination Layer 1 ID, an indication of source Layer 1 ID, and an indication of priority of traffic to be transmitted on SL. In step 6, the exceptional pool scheduling entity can schedule the transmission on the exceptional resource pool. It can schedule based on the amount of data to be transmitted, the priority of data to be transmitted, the source Layer 1 ID, the destination Layer 1 ID. The exceptional pool scheduling entity can assign resources for SL transmission from UE1 to UE2. This can be signaled to UE1 by a new SCI format. Next, in step 7, UE1 can use the assigned resources on the exceptional resource pool for transmission of packets to UE2. In step 8, UE1 can be allowed to use the normal resource pool. For example, when it sends RRCConnectionReconfigurationComplete after the handover command. Then, in step 9, UE1 can use the normal resource pool for sidelink communication with UE2.

[0310] Solution to problem 3: Impact of V2X mobility on group management

[0311] Group context in group management entity. Due to mobility, group dynamics can change frequently. The group management entity can be responsible for maintaining the group. Depending on the underlying conditions, the group management entity can:

[0312] • change the status of member UEs;

[0313] • split an existing group into one or more subgroups;

[0314] • elect one of the members of a subgroup as a relay UE;

[0315] • remove a member UE from the group;

[0316] • change the resource allocation pattern of member UEs;

[0317] • change the scheduler entity for the group;

[0318] • assign a scheduler entity for a subgroup; or

[0319] • allocate resources to be used by the scheduling entity, possibly including finding a common resource pool if the group members do not use the same TX resource pool.

[0320] A group management entity can maintain a context for each group it can be managing (referred to as group context hereinafter). This context can include the following elements.

[0321] • Group ID, an identifier of the group.

[0322] • Scheduling entity, if the group requires a scheduling entity. Some use cases can require strict performance requirements (e.g., latency and delay). These groups can require scheduled sidelink transmissions. The group management entity can also know the identity of the scheduling entity (e.g., gNB cell ID or UE ID).

[0323] • List of subgroups within the group.

[0324] • Minimum required resource allocation mode, which can specify the required resource allocation mode in the group. This can be “mode 2(d)”, “mode 1”, or “mode 2(a)”.

[0325] • List of member IDs, an ID for each member ID.

[0326] For each member ID, the group management entity can include:

[0327] • In-coverage vs. out-of-coverage status, indicating whether each member UE is in-coverage or out-of-coverage;

[0328] • RRC state (e.g., IDLE, CONNECTED, INACTIVE), indicating the RRC state of the in-coverage UEs;

[0329] • Current serving cell of the in-coverage UEs, e.g., cell ID;

[0330] • Current TX resource pool for each member UE;

[0331] • Current RX resource pool for each member UE;

[0332] • Current SPS for the member UEs, each member UE can receive an assigned SPS;

[0333] • Subgroup information, indicating the subgroup(s) the member UE is part of (a member UE can be part of zero, one, or multiple subgroups);

[0334] • Assigned resource allocation mode: mode 1, mode 2(a), or mode 2(d);

[0335] • Scheduling entity ID, if the assigned resource allocation mode is mode 2(d); and

[0336] • A backup group management entity, indicating whether this member UE can act as a backup group management entity when the original group management entity loses connectivity to the sidelink group.

[0337] Group context in a member UE. In addition, each member UE maintains information related to the group. This context can include the following list.

[0338] • A list of group IDs: an identifier of each group the UE can belong to. The UE can belong to more than one group.

[0339] • A list of other group management entities that can serve this member UE. These can be used in case the group management entity for the member UE has to be changed.

[0340] For each group ID, the group context can include the following information:

[0341] • Group management entity ID, identity of the group management entity;

[0342] • Scheduling entity ID, identity of the scheduling entity - the UE can have a gNB or RSU as scheduling entity (scheduled resource allocation - type mode 1), another UE as scheduling entity (scheduled resource allocation - type mode 2(d)), or it can have no scheduling entity (non-scheduled resource allocation - type mode 2(a))

[0343] • A list of subgroups (within that group) this member UE is part of; and

[0344] • A list of member UEs this UE can act as a relay for.

[0345] Changes in the status of a member UE. In some cases, the status of a member UE can change. The status can include, for example, serving cell, RRC state, in-coverage versus out-of-coverage, change of TX resource pool, or change of RX resource pool. Changes in any or all of these can be reflected in the group context maintained by the group management entity. A member UE can indicate a change in any of these by sending a PC5StatusUpdate message to the group management entity.

[0346] Changing the resource allocation mode of a member UE. The resource allocation mode selected for a sidelink group can be controlled by the group management entity and can be a characteristic of the group. The group management entity can make this decision based on the ongoing services within the group. Some services can have strict delay and latency requirements, which can require the use of a scheduled resource allocation (mode 1 or mode 2(d)). Conversely, some services are best effort, and thus can use either a scheduled or a non-scheduled resource allocation mode (mode 1, mode 2(a), or mode 2(d)).

[0347] The group management entity can be (pre)configured with a mapping of service to resource allocation mode. If the group has multiple ongoing services, the group management entity can determine the resource allocation mode based on priority. For example, mode 2(d) can be the highest priority, followed by mode 1, then mode 2(a). The resource allocation decision can be provided to the member UEs using the PC5GroupConfiguration command.

[0348] When a member UE is configured to use mode 2(d) resource allocation mode, the UE can rely on a PC5-based scheduling entity. As described in the Problem Statement section, the member UE can lose SL connectivity with this scheduling entity. In response, the group management entity can attempt to reestablish SL connectivity. For example, the group management entity can attempt to wrest service from a relay UE. Alternatively, the group management entity can attempt to change the broadcast mode used over the sidelink. Alternatively, the group management entity can split the group into subgroups and assign new scheduling entities to serve the member UEs.

[0349] In this section, we propose another alternative in which the group management entity can change the resource allocation mode of a member UE. The group management entity can check if the minimum resource allocation mode allows the member UE to use a lower resource allocation mode. If so, the group management entity can use the PC5GroupConfiguration command to change the resource allocation mode of the member UE (e.g., mode 2(a)). In response, the member UE can stop using the scheduling entity and can start using the unscheduled approach (sensing, random access, etc.). The group management entity can also change the group context state for this member UE to reflect the new resource allocation mode.

[0350] The group management entity removes a member UE. Due to mobility, some member UEs can lose their permission to transmit over the sidelink. In other cases, a member UE can lose connectivity with other member UEs. In both cases, these member UEs should be removed from the group. The overall procedure can include the following steps.

[0351] • Step 1: The group management entity can determine that a member UE is isolated from the group. It can determine this based on inactivity (no communication to and from the member UE), an indication from other member UEs that the member UE is not responding, an indication from the scheduler entity that the member UE is not active

[0352] • Step 2: The group management entity can check if the member UE is a relay for any other member UEs. If so, the group management entity can select new relay UEs for these member UEs. These UEs are updated with PC5GroupConfiguration

[0353] • Step 3: The group management entity can remove the member UEs from the group context.

[0354] The group management entity decides to split the group. In some cases, the group management entity can split the group into one or more subgroups. This can be to address coverage issues in the group, or it can be to optimize scheduling of sidelink transmissions for the group member UEs.

[0355] Figure 10 Splitting of a group for coverage reasons is illustrated. In step 0, the member UEs (UE1, UE2,... UEk) communicate over sidelink. In step 1, UE1 can lose SL connectivity with one or more of the other group members or with the scheduling entity. UE1 can use sidelink radio link monitoring to determine that it has lost this connectivity. It can be assumed hereafter that UE1 has lost connectivity with UE2. In step 2, UE1 can inform the group management entity about this loss of sidelink connectivity. This can be, for example, by using the message PC5StatusUpdate. The potential content of PC5StatusUpdate is shown in Table 7.

[0356] In step 3 of Figure 7, Figure 10 The group management entity can use its context information as well as the information from the PC5StatusUpdate to determine that UE3 can be used as a relay UE to assist in the connectivity between UE1 and UE2. The group management entity can select UE3 as the relay UE and can create two subgroups: subgroup 1 can include all member UEs except UE1, and subgroup 2 can include UE3 and UE1. Next, in step 4, the group management entity can send a configuration command (PC5GroupConfiguration) to UE3, including an indication that UE3 will act as a relay UE and become part of the new subgroup 1 and the new subgroup 2. It can also send a configuration command to UE1, including an indication that UE1 will become part of the new subgroup 2. It can also send a configuration command to all other member UEs that are included in subgroup 1. Then, in step 5, UE3 can configure itself as a relay UE, while having membership in subgroup 1 and subgroup 2. UE1 can configure itself to have membership in subgroup 2.

[0357] As a special case, if a member UE loses connectivity with the group management entity, it can be assumed that the latter will be able to detect the loss of connectivity. For example, if the group management entity is using a PC5 interface with the member UE, it can be performing its own sidelink radio link monitoring and determining that the member UE has lost connectivity.

[0358] For better scheduling of the long-haul, the group can be split. Due to mobility, one set of member UEs can be using one TX resource pool while a second set of member UEs can be using a different TX resource pool. This can not be a problem in case of unscheduled sidelink transmission. Both sets of UEs autonomously select resources from their respective TX resource pool and each member UE receives sidelink transmission from both TX resource pools. In case of scheduled sidelink transmission, this is not expected to be a problem in case of Uu-based scheduling entity. The member UEs can be scheduled by their respective gNB and can be able to receive sidelink transmission from both TX resource pools. However, in case of sidelink transmission scheduled using SL-based scheduling entity, there can be some inefficiency in scheduling the group by one scheduling entity. In this case, the group management entity can determine that splitting the group along the TX resource pool can be more efficient and let the scheduling entity perform resource allocation for each subgroup.

[0359] Figure 11 It is shown that the group is split for scheduling efficiency reasons. Note that in Figure 11 , the group management entity is shown as outside of the group but it can also be a member of the group. In Figure 11 , step 1, the group management entity can be monitoring the number of member UEs using each TX resource pool. If this number exceeds a configured threshold, then the group management entity can determine that it should split the group into two subgroups, each with its own scheduling entity. Alternatively, the decision to split the group for scheduling can come from the upper layer. The upper layer of the member UEs can signal to the group management entity to split the group, e.g., when some QoS measures are not satisfied. In step 2, the group management entity can determine UEs to act as scheduling entities in each subgroup. This can be based on the capabilities of the UEs as can be maintained in the group context stored in the group management entity. Next, in step 3, the group management entity can create two subgroups. It can send a PC5GroupConfiguration message to each UE. Alternatively, this can be a broadcast or groupcast message with details of all UEs. In step 4, the group management entity can send scheduling context to the scheduling entity of each subgroup. Then, in step 5, each UE can configure itself for the new subgroup and information about the scheduling entity of each subgroup. Thereafter, in step 6, all scheduling can be done at the subgroup scheduling entities.

[0360] Subgroup entity reorganization. In this use case, it can be assumed that the group is divided into two subgroups. Each subgroup can have its own group management entity, scheduling entity, and / or control entity. Note that in the following, it can be assumed that only the group management entity is per subgroup, but it should be understood that this can apply to the scheduling entity and / or control entity being per subgroup. This can occur, for example, when the group management entity is co-located with a roadside unit, as shown in Figure 12

[0361] Figure 12 A multiple subgroup use case is shown. As vehicles move along the road, they lose connectivity to RSU2 and can re-connect to RSU1. In this case, the group management entity in RSU1 can better serve these vehicles. The subgroup reorganization call flow is shown in Figure 13

[0362] Figure 13 Subgroup reorganization is demonstrated. In step 0, each GME can broadcast the capability to support group management functions. Each GME can also broadcast the current group they serve. This can be a group ID or a service ID. In step 1, UE1 can be triggered to change group management entities. This can be due to, for example, SL connectivity issues with its current group management entity, a change in UE1 scheduling entity, a change in UE1 control entity, a change in the RSU serving UE1, an indication to its current group management entity (GME2), an indication to its current scheduling entity, or an indication to its current control entity. In step 2, UE1 can determine acceptable group management entities from the broadcast information. Alternatively, GME2 can know the nearby group management entities and can provide this information to UE1. UE1 can then store this information as part of the group context it maintains. Next, in step 3, if a suitable group management entity is found, then UE1 can select it. Then, in step 4, UE1 can signal to GME2 that it wants to be part of the group managed by GME1.

[0363] Next, in step 5, GME2 can send a GMEHandover request to GME1. This request can include one or more of the following:

[0364] • Resource allocation mode used by UE1, including mode 1, mode 2, or both mode 1 and mode 2;

[0365] ​​• Any configured SPS for UE sidelink transmission;

[0366] • Any received measurement results for sidelink transmission;

[0367] • Any available scheduling information for the UE (e.g., pending SR, BSR report);

[0368] • The cast type (unicast, groupcast, broadcast) for each SL RB, where for groupcast it can provide the size of the group;

[0369] • If the UE has a special SL role (if the UE acts as a scheduling entity, control entity, or group management entity for other sidelink transmissions), it can provide an indication of the number of UEs it can be controlling, scheduling, or managing; and

[0370] • For each SL RB, the UE’s scheduling entity, control entity, or group management entity.

[0371] In step 6, GME1 can determine if it is willing to manage UE1. If so, in the following steps Al-A3 it can update its group context to include UE1. In step Al, GME1 can send a GMEHandover response to GME2. This response can include one or more of the following:

[0372] • A list of IDs of other members in the group managed by GME1;

[0373] • SL resource configuration for each SL RB, including any new / modified SPS for the SL RB (GME1 can use different SL resource configuration than GME2);

[0374] • For each transferred SL RB, the identity of the UE’s new scheduling entity, control entity, or group management entity; and

[0375] • For each SL RB, the mechanism for resource reselection during the exceptional resource pool phase (e.g., random or scheduled).

[0376] In step A2, GME2 can forward the GMEHandover to UE1. And, in step A3, UE1 can now be in the group managed by GME1 and can start using the new SL resource configuration (if any).

[0377] If GME1 determines in step 6 that it can not be willing to manage UE1, it can proceed with steps B1-B4. In step B1, GME1 can send a GMEHandover response to GME2 indicating that it is not willing to include UE1 in the group it manages. In step B2, GME2 can forward the GMEHandover response to UE1. In step B3, UE1 can continue to use GME2 as its group management entity. And in step B4, GME2 can rely on some group related coverage enhancements (such as those described with reference to Figure 10

[0378] (e) re-elect a new group management entity. In this use case, a SL-based group management entity can be replaced. As described, this can happen because the group management entity can no longer be allowed to transmit on the sidelink, or connectivity from the group management entity can be lost, or the group management entity can fail to establish / re-establish connectivity with one or more of the member UEs.

[0379] Figure 14 The election of a new group management entity is illustrated. In step 1, the group management entity can select a UE to act as a backup to manage the group in case of failure. As part of the group context, the selected UE can set the BackupGME flag to TRUE. In step 2, the group management entity can periodically update the backup GME (backupGME). It can periodically or upon a change in the group context, transfer the group context to the backup. The group management entity can send the complete group context or only the changed part since the last update. Alternatively, the backup GME can be configured to periodically pull the group context information from the group management entity. The group management entity can use the PC5 GME Status Update message. In step 3, the backup GME can determine that the group management entity can no longer be connected to the group. It can determine this based on missing the periodic indication from the group management entity (e.g., the periodic update of step 2), based on an indication from the scheduling entity that the group management entity has not been active for a period of time, or based on an indication from multiple member UEs that the group management entity has not been active for a long time. Then, in step 4, the backup GME can assume the role of the group management entity, and in step 5, the backup GME can inform all group member UEs of the change in group management entity. This can be through the PC5 Group Configuration.

[0380] ​Election of a new scheduling entity. In this use case, it can be required to replace the SL-based scheduling entity. As mentioned above, this can occur because the scheduling entity is no longer allowed to transmit on the sidelink, the scheduling entity can no longer be willing to act as a scheduler (e.g., based on a request from its upper layer), or the connection from the scheduling entity can be lost. Furthermore, for some group scenarios where scheduling of sidelink services can be required, scheduling entity re-election can also occur when the scheduling entity is unable to establish / re-establish connectivity with one or more of the member UEs.

[0381] Figure 15 The election of a new scheduling entity is shown. In step 0, the member UEs (UE1, UE2,... UEk) can be communicating over the sidelink. The group management entity can be aware of the member UEs that act as scheduling entity for the group. The group management entity can also be aware of all member UEs that are willing / able to act as a scheduler UE. In step 1, the UEs can monitor their SL connectivity. Then, in step 2, upon detecting SL connectivity problems, the UEs can inform the group management entity. This can be done using the message PC5StatusUpdate, for example. The potential content of PC5StatusUpdate is shown in Table 7.

[0382] Step 3: The group management entity can determine that the scheduling entity can no longer provide services to the group. For example, it can determine this based on sidelink radio link monitoring between itself and the scheduling entity, a status message (e.g., PC5StatusUpdate) from the sidelink entity, or a status message (e.g., PC5StatusUpdate) from one or more member UEs. The group management entity can use the sidelink status information contained in the messages to determine whether a new scheduling entity must be elected. For example, if the PC5StatusUpdate from the scheduling entity shows connectivity problems with a large portion or all of the sidelinks from the scheduling entity, the group management entity can decide to elect a new scheduling entity. Similarly, even after the group management entity has tried to recover from this problem, if the PC5StatusUpdate from the member UEs consistently show connectivity problems with the scheduling entity, the group management entity can decide to elect a new scheduling entity.

[0383] In step 4, the group management entity can use the group context to elect a new scheduling entity. In step 5, the group management entity can inform the member UEs that it is the new scheduling entity. It can provide the scheduling context it has available, e.g., whether the member UEs are configured with SPS (e.g., PC5GroupConfiguration). Next, in step 6, the group management entity can inform the other group member UEs of the identity of the new scheduling entity (e.g., PC5GroupConfiguration). And, in step 7, the group can start using the new scheduling entity.

[0384] The group management entity determines the optimal TX resource pool. Due to mobility, a member UE can change its TX resource pool, e.g., when it changes serving cell, changes from in-coverage to out-of-coverage (or vice versa) or changes its RRC state. In such cases, the TX resource pool for the member UE can be different from the TX resource pool of the other group members, the scheduling entity and / or the group management entity. As described, using different TX resource pools among the members of a group can lead to inefficiencies, especially if the group members can need to use the mode 2(d) scheduled resource allocation mode. To cope with these inefficiencies, the group management entity can determine a “common TX resource pool”. This common TX resource pool can only contain resources that are common to all members of the group (possibly including the SL-based scheduling entity and the SL-based group management entity). The overall procedure can be defined in the following steps.

[0385] • Step 1: A member UE can change its TX resource pool. The member UE can update the group management entity with its latest TX resource pool.

[0386] • Step 2: The group management entity can evaluate the requirement for an optimized TX resource pool and can thus determine a common TX resource pool.

[0387] • Step 3: The group management entity can update all group members (possibly also the scheduling entity) with the new TX resource pool.

[0388] Signaling message content

[0389] Message exchange. Table 7 shows PC5StatusUpdate. Direction: UE to group management entity and link: PC5 or Uu.

[0390] Table 7: PC5StatusUpdate

[0391]

[0392] Table 8 shows PC5GroupConfiguration. Direction: group management entity to UE and link: PC5 or Uu.

[0393] Table 8: PC5GroupConfiguration

[0394]

[0395]

Claims

1. An apparatus comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the apparatus to perform operations associated with a source cell of a communication network, comprising: receiving a measurement report from a first user equipment (UE), the measurement report comprising an indication that a target cell of the communication network is better than the source cell; determining, based on the measurement report, to perform a handover of the first UE to the target cell; sending a handover request to the target cell, the handover request comprising sidelink communication requirements between the first UE and a second UE in communication with the first UE; receiving a handover response to the handover request from the target cell, wherein the handover response comprises sidelink configuration information associated with the target cell, wherein the sidelink configuration information comprises a configuration of an exceptional resource pool of the target cell for sidelink communication during the handover, wherein the configuration of the exceptional resource pool is partitioned into priority-based sub-pools; sending the handover response to the first UE to facilitate a handover of the first UE from the source cell to the target cell; and initiating sidelink communication of a given priority using only sub-pools having an equal or lower priority to maintain quality of service (QoS) requirements of the sidelink communication during the handover.

2. The apparatus of claim 1, wherein the sidelink communication requirements between the first UE and the second UE comprise one or more of: a resource allocation mode of the first UE, a cast type of each sidelink radio bearer, an indication of whether sidelink radio bearers should be transferred to the target cell, a scheduling entity of the first UE, a control entity of the first UE, a group management entity of the first UE, an indication of whether the first UE has a special role as a scheduling entity, a control entity, or a group management entity.

3. The apparatus of claim 1, wherein the sidelink configuration information associated with the target cell comprises one or more of: a list of sidelink radio bearers to be transferred to the target cell, a list of sidelink radio bearers to be discarded, a new scheduling entity for the first UE, a new control entity for the first UE, or a new group management entity for the first UE.

4. The apparatus of claim 1, wherein sending the handover response to the first UE triggers the first UE to detach from the source cell, begin synchronizing with the target cell, and reconfigure according to the sidelink configuration information.

5. The apparatus of claim 1, wherein the instructions, when executed by the processor, further cause the apparatus to perform operations comprising: retrieving a scheduling context associated with the first UE from a scheduling entity associated with the first UE; and sending the scheduling context associated with the first UE to the target cell, wherein the scheduling context facilitates scheduling of resources associated with the first UE by a new scheduling entity.

6. The apparatus of claim 5, wherein the scheduling context comprises one or more of: configured grants assigned to the first UE that are active, pending buffer status reports received from the first UE, pending scheduling requests received from the first UE, or sidelink-related measurements received from the first UE. ​ 7. The apparatus of claim 5, wherein the new scheduling entity is hosted by the target cell or by another UE served by the target cell.

8. The apparatus of claim 5, wherein retrieving the scheduling context associated with the first UE triggers the scheduling entity to stop resource scheduling for the first UE and release configured grant resources allocated to the first UE.

9. The apparatus of claim 5, wherein retrieving the scheduling context associated with the first UE triggers the scheduling entity to maintain the retrieved scheduling context for a period of time and remove the scheduling context after the period of time expires.

10. A method performed by an apparatus, comprising: receiving a measurement report from a first user equipment (UE), the measurement report including an indication that a target cell of a communication network is better than a source cell; determining to perform a handover of the first UE to the target cell based on the measurement report; sending a handover request to the target cell, the handover request including sidelink communication requirements between the first UE and a second UE in communication with the first UE; receiving a handover response to the handover request from the target cell, wherein the handover response includes sidelink configuration information associated with the target cell, wherein the sidelink configuration information includes a configuration of an exceptional resource pool of the target cell for sidelink communication during the handover, wherein the configuration of the exceptional resource pool is partitioned into priority-based sub-pools; sending the handover response to the first UE to facilitate the handover of the first UE from the source cell to the target cell; and initiating sidelink communication of a given priority using only sub-pools having an equal or lower priority to maintain quality of service (QoS) requirements of the sidelink communication during the handover.

11. The method of claim 10, wherein the sidelink communication requirements between the first UE and the second UE include one or more of: a resource allocation mode of the first UE, a cast type of each sidelink radio bearer, an indication of whether sidelink radio bearers should be transferred to the target cell, a scheduling entity of the first UE, a control entity of the first UE, a group management entity of the first UE, an indication of whether the first UE has a special role as a scheduling entity, a control entity, or a group management entity.

12. The method of claim 10, wherein the sidelink configuration information associated with the target cell includes one or more of: a list of sidelink radio bearers to be transferred to the target cell, a list of sidelink radio bearers to be discarded, a new scheduling entity for the first UE, a new control entity for the first UE, or a new group management entity for the first UE.

13. The method of claim 10, wherein sending the handover response to the first UE triggers the first UE to detach from the source cell, start synchronization with the target cell, and reconfigure according to the sidelink configuration information.

14. The method of claim 10, further comprising: retrieving a scheduling context associated with the first UE from a scheduling entity associated with the first UE; and sending the scheduling context associated with the first UE to the target cell, wherein the scheduling context facilitates scheduling of resources associated with the first UE by a new scheduling entity. ​ ​ 15. The method of claim 14, wherein the scheduling context comprises one or more of: an active configured grant assigned to the first UE, a pending buffer status report received from the first UE, a pending scheduling request received from the first UE, or a sidelink related measurement received from the first UE.

16. The method of claim 14, wherein the new scheduling entity is hosted by the target cell or by another UE served by the target cell.

17. The method of claim 14, wherein retrieving the scheduling context associated with the first UE triggers the scheduling entity to stop resource scheduling for the first UE and release configured grant resources allocated to the first UE.

Images