Abstract: Systems and methods for supporting multiple uncrewed aerial vehicle (UAV) Service Suppliers (multi-USS) are described. The methods may be performed by a wireless transmit/receive unit (WTRU) including a UAV application enabling (UAE) client located in the UAV with the method performed with the UAV in-flight. Steps may include: sending a registration request to a UAE server, the registration request including an indication of multi-USS capability; receiving a registration response message that includes an indication that the UAE server supports multi-USS capability; receiving a multi-USS configuration request that includes multi-USS configuration parameters related to conditions under which the UAE client may initiate a USS change and a list of allowed USSs; sending a multi-USS configuration response; and performing a multi-USS change and sending a multi-USS change notification based on the multi-USS configuration parameters.

Abstract: A wireless transmit/receive unit (WTRU) may send a discovery request to a first edge enabler server (EES) instance to obtain edge application server (EAS) information. The WTRU may receive a discovery response from the first EES instance. The discovery response may indicate a list of EAS information and/or registrar EES information for one or more EAS instances in the list of EAS information. The WTRU may select an EAS instance based on one or more of the list of EAS information or the registrar EES information for the one or more EAS instances. A second EES instance of the plurality of EES instances may be the registrar EES of the selected EAS instance.

Abstract: Methods and apparatuses for power saving are described herein. A method performed by a remote wireless transmit/receive unit (WTRU) may include receiving a broadcast message indicating a power saving capability, sending, to a relay WTRU, a request for direct communication, receiving an acknowledgement from the relay WTRU in response to the request for direct communication, and establishing a link to the relay WTRU based on the received acknowledgement. The method may further include sending, to the relay WTRU, a message for registration with a network, receiving, via the relay WTRU, a message from the network in response to the message for registration, sending, to the relay WTRU, a message indicating that a power saving feature is enabled, and adjusting parameters for power saving. The request for direct communication may include information indicating one or more power saving capabilities or power saving requirements of the remote WTRU.

Abstract: A method for UE-to-UE (U2U) relay discovery security is disclosed. The method may comprise provisioning an end-UE with security material for a direct discovery set and a U2U discovery message and provisioning a U2U relay with security material for the U2U discovery message. The security material for the direct discovery set may comprise at least one of: A ProSe restricted code, associated key material, or an indicator associated with a relay service code (RSC) that indicates whether the RSC supports per ProSe direct discovery set protection. The method may comprise sending, by the end-UE to the U2U relay, a direct connection request (DCR) message. The DCR message may comprise at least one of: an RSC, and end-UE User info identification (ID), or a ProSe restricted code. The method may comprise sending, by the end-UE, an indication for direct discovery set protection.

Abstract: In examples, the E2E link IDs may be isolated per-hop, so that changes of link IDs may not impact other E2E/per-hop links (e.g, a LIU procedure may only run between a WTRU and the relay), A relay may allocate R-specific security IDs/session key identifiers (e.g, MSBs/LSBs of Knrp-sess ID), The relay (e.g., relay WTRU) may replace the security IDs/session key identifiers received from peer WTRUs with R-specific security IDs/session key identifiers, for example, If forwarding a message. In examples, per-hop IDs and E2E IDs may be added to link identifier update messages, In examples, the support application layer ID and iP address/prefix may be changed using a link modification procedure (e.g.

Abstract: Cellular connectivity and quality of service (QOS) monitoring and prediction are provided for unmanned aerial vehicle (UAV) communication. A core network (CN) may select assisting UAVs for communication link monitoring according to a target UAV's flight route. The CN may receive the assisting UAV's monitoring report, which may be used to derive a communication link quality prediction for the target UAV's flight path. The target UAV may discover and select an adjacent pilot UAV, which flies ahead of the target UAV's trajectory. The target UAV may receive a monitoring report from the pilot UAV, which may be used to predict a communication link quality for the target UAV's flight path. An unmanned aerial system (CAS) network function (NF) may collect QOS monitoring information from other NFs for a predetermined/popular flight route. The UAS NF may provide a prediction to the USS (e.g., upon request).

Abstract: A wireless transmit receive unit (WTRU) may be configured to perform an edge application server (EAS) discovery procedure for a user session. The WTRU may be configured to determine, based on the EAS discovery procedure, that there are no available target EAS (T-EAS) instances for the user session. The WTRU may be configured to determine whether the user session supports application context relocation (ACR) to a cloud application server (CAS) using ACR configuration information (ACI). The WTRU may be configured to establish a connection with the CAS based on the ACI. The WTRU may be configured to send a notification to one or more ACR entities indicating that ACR to the CAS has been initiated. The WTRU may be configured to obtain CAS details using the ACI.

Abstract: Methods, apparatus and systems are disclosed. One method may be implemented by a first Wireless Transmit/Receive Unit (WTRU) having established an indirect link with a second WTRU. The method may include performing a Discovery procedure and detecting, based on a result of the performed Discovery procedure, that the second WTRU is directly reachable. The method may further include initiating establishment of a direct link, switching from the indirect link to the direct link and communicating, by the first WTRU with the second WTRU, using the established direct link after the switch.

Abstract: Systems, methods, and instrumentalities are described herein that are associated with providing access to a network (e.g., if access to a different network is lost, affected, etc.). A WTRU may act as a relay to another WTRU, For example, a first VVTRU may act as a relay WTRU (e.g., a VVTRU to network relay, such as a proximity services (ProSe) WTRU to network relay) towards a second WTRU (e.g., a remote WTRU). The first WTRU may provide discovery and/or connection establishment associated with the second WTRU accessing the network (e.g., if there is a service disruption to another network).

Abstract: A user equipment, WTRU (401), may be provisioned on a stand-alone non-public network, SNPN. The WTRU registers with an on-boarding network, ONN (402). An indication that the WTRU is requesting to register with the ONN is received by a provisioning server, PVS (403), of the SNPN. An identifier associated with the WTRU is transmitted to the PVS. The PVS requests to subscribe to notifications related to the provisioning. For example, the notifications are sent/received via a network exposure function, NEF. A notification that the WTRU has successfully registered with the SNPN is transmitted (e.g., to the devices the requested to subscription notifications). After the WTRU has been successfully registered, the WTRU is de-registered from the ONN, and an indication that the WTRU has been de-registered from the ONN is transmitted (e.g., via the NEF).

Abstract: Systems, methods, and instrumentalities may be provided to discover a personal Internet of Things (IoT) network (PIN). A discovery policy configuration information associated with a PIN may be determined. The discovery policy configuration information may comprise a PIN identification (ID) and may indicate that discovery for the PIN may be enabled. A first message may be sent to a second WTRU if discovery for the PIN is enabled. The first message may be based on the discovery policy configuration information and may indicate the PIN ID. A second message may be received from the second WTRU. The second message may indicate the PIN ID and may indicate a request for information associated with the PIN. A third message may be sent to the second WTRU. The third message may indicate the PIN ID and may indicate the requested information that may be associated with the PIN.

Abstract: Systems and methods for supporting multiple uncrewed aerial vehicle (UAV) Service Suppliers (multi-USS) are described. The methods may be performed by a wireless transmit/receive unit (WTRU) including a UAV application enabling (UAE) client located in the UAV with the method performed with the UAV in-flight. Steps may include: sending a registration request to a UAE server, the registration request including an indication of multi-USS capability: receiving a registration response message that includes an indication that the UAE server supports multi-USS capability: receiving a multi-USS configuration request that includes multi-USS configuration parameters related to conditions under which the UAE client may initiate a USS change and a list of allowed USSs: sending a multi-USS configuration response; and performing a multi-USS change and sending a multi-USS change notification based on the multi-USS configuration parameters.

Abstract: A sensing operation management function (SOMF) with a processor may be configured to receive a wireless transmit/receive unit (WTRU)-initiated sensing request from a network node. The WTRU-initiated sensing request may include one or more of a requested sensing area, a requested service area, a WTRU location, information associated with a serving SOMF, or a periodic service request. The SOMF may be configured to select one or more WTRUs to perform a sensing operation based on the WTRU-initiated sensing request. The SOMF may be configured to send one or more sensing requests to the one or more selected WTRUs. The one or more sensing requests may include one or more of a periodicity for performing the sensing operation, a periodicity for sending sensing responses, or a requested sensing mechanism. The SOMF may be configured to receive one or more sensing responses from the one or more WTRUs. The one or more sensing responses may include sensing data.

Abstract: A Sensing Operation Management Function (SOMF) may comprise a processor and memory, and may be configured to receive a request message. The request message may comprise a requested sensing mechanism and a quality of service (QoS) requirement. The processor and memory of the SOMF may be configured to determine coordination information based on the requested sensing mechanism and the QoS requirement. The coordination information may be associated with one or more base stations and/or one or more wireless transmit receive units (WTRUs) to be used for performing a sensing operation. The processor and memory of the SOMF may be configured to send a sensing request message to the one or more base stations and/or the one or more WTRU. The sensing request message may comprise a sensing area for the WTRU or base station information when the sensing request message is sent to the one or more WTRUs.

Abstract: The present disclosure provides a mechanism enabling switching between different configuration for a positioning procedure to dynamically adapt the accuracy of the positioning procedure to the current requirements of client devices and/or environmental conditions. The switch may be initiated by a network node which can instruct a client device to deactivate positioning according to a first configuration and to activate positioning according to a second configuration. The network node can determine the second configuration based on e.g. position of client device, density of client devices, current position requirements per client device, network load, and/or available resources. Thereby, allowing the configuration for the positioning procedure to be adapted based on dynamic requirements on the positioning procedure.

Abstract: The invention provides a mechanism for switching between a first and a second positioning procedure. The first positioning procedure may be an absolute positioning procedure and the second positioning may be a relative positioning procedure. The switch may be initiated by a network node (300) which can instruct a client device (100) to terminate the first positioning procedure and to activate the second positioning procedure or to instruct the client device (100) to continue with the first positioning procedure and to activate the second positioning procedure. Thereby, allowing the positioning procedure used by the client device (100) to be adapted e.g. based on dynamic requirements on positioning procedures set by applications.

Abstract: A relay WTRU may receive, from a remote WTRU, a request for connection that includes a PRUK ID. The relay WTRU may transmit, to a PKMF associated with the relay WTRU, a key request message that includes the PRUK ID. The relay WTRU may receive, from the PKMF associated with the relay WTRU, a key response message that includes a GPI. The relay WTRU may transmit, to the remote WTRU, a direct security mode command message that includes the GPI. The relay WTRU may receive, from the remote WTRU, a direct security mode complete message. The relay WTRU may transmit, to the PKMF associated with the relay WTRU, a PRUK confirmation message. The relay WTRU, may receive, from the PKMF associated with the relay WTRU, an acknowledgement that the PRUK confirmation message was received, and transmit, to the second WTRU, an acceptance of the request for connection.

Abstract: A first client device compresses a broadcast sidelink packet according to a configuration for a compression profile by removing at least one non-IP header of the broadcast sidelink packet. The first client device transmits the compressed broadcast sidelink packet together with an indication of the compression profile. When a second client device receives the compressed broadcast sidelink packet, the second client device reconstructs the at least one non-IP header of the broadcast sidelink packet based on the configuration for the compression profile and the indicated compression profile.

Abstract: The invention relates to power control in groupcast communication between a first communication device (100) and a set of second communication devices (300a, 300b, . . . , 300n). The first communication device (100) obtains received signal qualities from a reporting subset (300a?, 300b?, . . . , 300n?) in the set of second communication devices (300a, 300b, . . . , 300n) and determines at least one path loss value for the reporting subset (300a?, 300b?, . . . , 300n?) based on the one or more obtained received signal qualities. The first communication device (100) may further determine a transmission power value for the groupcast communication based on the at least one path loss value and perform a groupcast communication transmission based on the determined transmission power value. Furthermore, the invention also relates to a second communication device (300), corresponding methods, and a computer program.

Abstract: The disclosure relates to early detection and indication of a Quality-of-Service (QoS) non-fulfillment in one or more radio links serving an application. A client device monitors for a QoS non-fulfillment in the one or more radio links based on a QoS monitoring configuration associated with the application. The QoS monitoring configuration may be received from a network node and/or derived based on a predefined rule. Upon detection of a QoS non-fulfillment of one or more QoS requirements obtained from the QoS monitoring configuration, the client device provides a QoS non-fulfillment indication to the application. The QoS non-fulfillment indication gives the application an early warning about QoS non-fulfillment on the one or more radio links. Thereby, allowing the application to take precautionary actions to counteract possible negative consequences of the QoS non-fulfillment. Furthermore, the disclosure also relates to corresponding methods and a computer program.