Summary based on the input provided by Samsung in SP-220623. In Rel-16, Service Enabler Architecture Layer (SEAL) was specified, in TS [1] to [8]. SEAL offers a set of common services to the verticals industry applications and to V2X applications. These services include the management of Groups, Configurations, Keys, Identities, Locations and Network Resource. SEAL is further described in clause 9.4 of TR 21.916. In Rel-17, enhancements are made to several SEAL services, namely:

1. The SEAL architecture is enhanced to support Light Weight Protocol (LWP) for constrained devices.
2. The "Configuration Management" capability is enhanced to support generic container to carry Vertical Application Layer (VAL) service-specific information.
3. The "Group Management" capability is enhanced to support temporary groups in a VAL system, to remove the limitation where VAL service specific data cannot be sent to group members, to add location criteria in the group creation, to support management of 5G VN groups, to control notification rate, to control group communication messages, support for external group Id and group fetch procedure.
4. The "Location Management" capability is enhanced to support the tracking of UE and obtaining dynamic UE information at a location, to distinguish the VAL services, to obtain list of UEs based on location area, monitoring location deviation, to include supplementary location information to verticals, to add timestamp for location report and off-network location management.
5. The "Network resource management" is enhanced to add local MBMS support, to allow NRM server to use TSN and 5G native TSC for resource management, to subscribe to unicast QoS monitoring, to Subscribe to Unicast QoS Monitoring and real-time monitoring status information.

Beside these enhancements, an entirely new service, called Network Slice Capability Enablement (NSCE), is defined. It includes: the functional model; Procedure for VAL server-triggered and network-based network slice adaptation for VAL application; Procedure for VAL UE-triggered and network-based network slice adaptation for VAL application. The SEAL enhancements are specified in TS 24.544, TS 24.545, TS 24.546, TS 24.547, TS 24.548 and TS 29.549, while the SEAL new service is specified in TS 24.549.

Summary based on the input provided by Siemens in SP-220458. Cyber-physical control applications in vertical domains (CAV) was introduced in Rel-16 [2]. As a reminder, "cyber-physical control applications" refers to applications that control physical processes over a network, using algorithms. Communication for cyber-physical control applications supports operation in various vertical domains, for instance industrial automation, Smart Grid. CAV requires very high levels of communication service availability and some of them also require a very low end-to-end latency as well as real-time capabilities. Rel-17's enhancements for CAV (eCAV) refines the service requirements for CAV and specifies new service requirements for specific aspects (Stage 1): additional service performance requirements (KPIs, influencing parameters) have been provided for enhanced and new use cases of cyber-physical control applications: control-to-control communication, wired-to-wireless link replacement (100 Mbit/s, 1 Gbit/s), cooperative carrying, mobile operation panels, and industrial wireless sensors. eCAV addresses further and enhanced service requirements for industrial Ethernet integration, which includes time synchronization, clock synchronization performance requirements, different time domains, integration scenarios, and support for time-sensitive networking (TSN). An essential requirement specifies: "The 5G system shall support clock synchronization (e.g. IEEE 802.1AS) through the 5G network if the sync master and the sync devices are served by different UEs". See Figure 6.2.1.2-1. The flow of clock synchronization messages is in either direction, UL and DL, and can contain two wireless links on its path.

Service requirements on direct device communication (ProSe communication) for cyber-physical control applications are provided (general, network performance, clock synchronization, service continuity, aspects of indirect communication), many of them supporting the use case of cooperative carrying. Furthermore, high-level requirements for enhancements in network operation and maintenance in 5G non-public networks for cyber-physical control applications in vertical domains and enhancements and clarifications for positioning have been provided.

Summary based on the input provided by Huawei in CP-220394. The 3GPP Northbound Interfaces and APIs are specified as to enable external entities and third party Application Servers/Functions to access a set of exposed 3GPP network services and capabilities in a secure and controlled manner. The 3GPP application layer APIs are defined by 3GPP as to allow the support of various applications/services (e.g. V2X, UAS, EDGE, etc.) over 3GPP networks and to ensure the efficient use and deployment of these applications/services over 3GPP systems via an optimized application layer framework. 3GPP northbound interfaces/APIs as well as application layer APIs are used and supported by various external entities including third party Application Servers/Functions. This work relates to the introduction of pure stage 3 (i.e. there are no related stage 1 nor stage 2 requirements) technical improvements and enhancements, i.e. improvement of the overall efficiency, reliability and flexibility, enhancement of the signalling efficiency, consolidation of the common protocol aspects, alignment with the 5GC service based principles and guidelines when relevant, corrections/changes missed in the previous 3GPP Releases, etc., especially that such enhancements may not be covered by the other more dedicated and functionality-driven work items.

Summary based on the input provided by Intel in RP-220919. This Work Item specifies solutions for NR Positioning enhancements, including improvement of positioning accuracy and latency of Rel-16 NR positioning methods, improvements of network efficiency (On-Demand PRS transmission), improvement of device efficiency (positioning in RRC_INACTIVE), providing high integrity and reliability requirements (GNSS integrity) and enhancements of A-GNSS positioning (BDS B2a,/B3I and NavIC to NR). All these aspects are detailed below. To improve positioning accuracy, several solutions were considered: Mitigation of gNB/UE Tx/Rx timing delay errors: For mitigation of gNB/UE Tx/Rx timing delay errors, multiple enhancements are introduced in Rel-17:

• For DL-TDOA, a UE can be requested to provide the Rx TEG IDs together with RSTD measurements and a TRP can be requested to provide TRP Tx TEG association information of DL PRS resources to mitigate UE Rx timing errors and TRP Tx timing errors. A UE can also be requested to measure the same DL PRS resource of a TRP with different UE Rx TEGs and report the corresponding multiple RSTD measurements to mitigate UE Rx timing errors.
• For UL-TDOA, Rel-17 supports a TRP to provide the Rx TEG IDs together with RTOA measurements and a UE to provide UE Tx TEG association information of UL positioning SRS resources to mitigate TRP Rx timing errors and UE Tx timing errors. A TRP can also be requested to measure the same UL SRS resource of a UE with different TRP Rx TEGs and report the corresponding multiple RTOA measurements to mitigate TRP Rx timing errors.
• Multi-RTT, Rel-17 supports a UE/TRP to provide the RxTx TEG IDs, or combination of {Rx TEG ID, Tx TEG ID} together with UE/gNB Rx-Tx time difference measurements and a UE/gNB to provide its Tx TEG association information for mitigating UE/TRP Rx/Tx timing errors;

In addition, Rel-17 supports a UE to report more than one measurement instance of RSTD, DL RSRP, and/or UE Rx-Tx time difference measurements in a single measurement report, and support a TRP to report more than one measurement instance of RTOA, UL RSRP, and/or gNB Rx-Tx time difference measurements in a single measurement report. Each measurement instance is reported with its own timestamp; UL-AOA enhancements: The new assistance information (expected UL-AOA value and uncertainty range) can be provided by the LMF to facilitate gNB measurements for NR UL-AOA, UL-TDOA and Multi-RTT positioning methods. Support of the first arrival path UL-AOA/ZOA measurement pair per SRS resource were introduced, including reporting of multiple per path AOA value pairs (including additional paths) to cope with possible ambiguity of angle measurements in antenna arrays with larger spacing than a half wavelength, and reporting ZoA only to cope with angle measurements in linear antenna arrays. The per path UL SRS receive reference signal power (UL SRS-RSRPP) measurement definition was introduced. The antenna reference point (ARP) location can be associated with UL measurements for NR Positioning (UL AOA, UL-RTOA, UL SRS-RSRP, UL SRS-RSRPP and gNB Rx-Tx time difference measurements). Finally, to facilitate hybrid RAT dependent positioning, gNB can report to LMF the following set of measurements {one SRS-RSRP, multiple UL-AOAs (AOA/ZoA pairs), one UL-RTOA or one-gNB Rx-Tx time difference}. DL-AOD enhancements: The enhancements of assistance data (a subset of PRS resources for each PRS resource for the purpose of prioritization of DL-AOD reporting or the boresight direction information for each PRS resource) were defined to improve DL-AOD estimation. In addition, the assistance information on DL-AOD/DL-AOA expected value and uncertainty range can be provided by LMF to UE. In Rel-17, for more accurate DL-AOD measurements, the gNB can provide the beam/antenna information to LMF (and LMF can further share it to UE for UE-based positioning). The per path DL PRS reference signal received power (DL PRS RSRPP) for the first path measurements were defined for DL-AOD estimation, and the maximum number of DL PRS RSRPP for the first path measurements was 24. Finally, the maximum number of DL PRS RSRP measurements per TRP was increased up to 24 compared to 8 in Rel.16. Multi-path and NLOS mitigation: In Rel-17, multi-path (additional path) report enhancements and LOS/NLOS indication were introduced for NR positioning solutions. The maximum number of additional paths that can be reported is increased (up to 8) with per path RSRP measurements and associated relative timing supported. Multiple UL-AOAs (up to 8) per additional path reporting is supported for the UL-TDOA and Multi-RTT positioning methods. The LOS/NLOS indicator was introduced that can be associated with specific measurements, DL/UL reference signals / resources for positioning. To improve the positioning latency, following solutions were considered: Preconfigured measurement gap: To reduce latency of procedures for DL PRS processing with measurement gaps, the set of measurement gap patterns can be pre-configured to UE and activated/deactivated by gNB using new DL MAC CE signalling designed to control DL PRS measurement by UE. The UE can request activation and deactivation of the pre-configured MG using new UL MAC CE signalling introduced in Rel-17. The LMF can request activation of pre-configured MG using new NRPPa signalling introduced in Rel-17. Preconfigured PRS processing window: To further reduce latency of DL PRS processing, UEs can perform DL PRS measurement outside measurement gaps and inside the active DL BWP with PRS having the same numerology as the active DL BWP. The gNB can use RRC signalling to pre-configure PRS processing window and DL MAC CE signalling for activation of PRS processing window, respectively. gNB can indicate the DL PRS processing priority relative to other DL signals/channels within the PRS processing window for PRS measurement outside MG. M-sample measurement (M = 1): In Rel-17, LMF can request UE and/or TRP to perform measurement over either a single RS transmission period (M=1) or four RS transmission periods (M=4). Configuring M=1 for a UE reduces UE measurement period comparing to Rel.16 (In Rel-16, UE is expected to measure DL PRS over four periods (M = 4)). An AGC sample, in addition to the M=1 sample may be required at the UE subject to measurement conditions. Lower Rx beam sweeping factor: In Rel-17, a new UE capability on lower Rx beam sweeping factor (<8) is introduced to reduce the PRS measurement latency for FR2 positioning frequency layers. Storing LPP capability in AMF: The LMF may interact with the AMF to provide (updated) UE Positioning Capability to AMF and to receive stored UE Positioning Capability from AMF as described in TS 23.273. The LPP procedures to transfer UE LPP positioning capabilities may be skipped if the LMF already obtained the UE positioning capabilities from the AMF. Preconfigured assistance data: Preconfigured assistance data is the DL-PRS assistance data (with associated validity criteria, i.e. area ID) that can be provided to the UE (before or during an ongoing LPP positioning session), to be then utilized for potential positioning measurements at a future time (e.g. for deferred MT-LR). Pre-configured DL-PRS assistance data may consist of multiple instances, where each instance is applicable to a different area within the network. Scheduled location time: During positioning procedure, the LMF may obtain the scheduled location time from the AMF. Based on the obtained scheduled location time, the LMF may schedule location measurements by the UE and/or location measurement by the NG-RAN to occur at or near to the scheduled location time. On-Demand PRS transmission procedure allows the LMF to control and decide whether PRS should be transmitted or not and whether the characteristics of an ongoing PRS transmission should be changed or not. In case of UE-initiated On-Demand PRS, the LMF may configure the UE with pre-defined PRS configurations via LPP Provide Assistance Data message or via posSI. The UE sends an On-Demand PRS request to the LMF via LPP Request Assistance Data message. The On-Demand PRS request can be the request for a defined PRS configuration with PRS configuration ID or explicit parameter for PRS configuration and may be a request for PRS transmission or change to the PRS transmission characteristics for positioning measurements. In case of LMF-initiated On-Demand PRS, the LMF and the UE may exchange LPP messages e.g., to obtain UE measurements or the DL-PRS positioning capabilities of the UE, etc). The actual PRS changes are requested by the LMF irrespective of whether the procedure is UE- or LMF-initiated. Positioning may be performed when a UE is in RRC_INACTIVE. Any uplink LCS or LPP message can be transported in RRC_INACTIVE. If the UE initiated data transmission using UL SDT, the network can send DL LCS, LPP and RRC message (e.g. to configure SRS for UL positioning, if it is supported) to the UE. UE may also receive PRS or transmit SRS in RRC_INACTIVE. Support of all NR positioning measurements and support of NR positioning methods such as NR E-CID, DL-TDOA, DL-AOD, UL-AOA, UL-TDOA, Multi-RTT and RAT-independent positioning methods are extended for UEs in RRC_INACTIVE state. Positioning integrity is a measure of the trust in the accuracy of the position-related data and the ability to provide associated alerts. UE based GNSS integrity is supported in Rel-17. It allows the UE to determine and report the integrity results of the calculated location, where only protection level (PL) reporting mode is supported; the UE can use the integrity requirements and assistance data obtained via NG-RAN, together with its own measurements, to determine the integrity results of the calculated location. For integrity operation, the network will ensure that: for all values of IRallocation in the range irMinimum ≤ IRallocation ≤ irMaximum for all the errors in Table 8.1.2.1b-1 as specified in clause 8.1.2.1b of TS 38.305, which have corresponding integrity assistance data available and where the corresponding DNU flag(s) are set to false. Enhancements of A-GNSS positioning specified: BDS B2a signal; BDS B3I signal; NavIC to NR.

Summary based on the input provided by Ericsson in SP-220584. The support of non-public networks (NPN) was introduced in Rel-16 by the WI Vertical_LAN with UID 830042. Deployments of NPN to provide coverage within a specific geographic area for non-public use is a key demand of emerging 5G applications and verticals. This Rel-17 work item enables the four following enhancements: Support for accessing an SNPN using credentials from a Credential Holder (CH): A UE can be configured with user or CH controlled prioritized list of information, SNPN identifiers or Group IDs for Network selection (GINs), enabling the UE to discover SNPNs supporting access using credentials from a CH. If the UE selects and accesses the SNPN, the CH is involved in the primary authentication and for authorizing the access to the SNPN. The CH can either include 5GC NFs e.g. AUSF and UDM (if the CH is an SNPN or a PLMN) or include a AAA server. Support for Onboarding of UEs: Onboarding of UEs allows the UE to access an Onboarding Network (ONN) for the purpose of provisioning the UE with SNPN credentials and other information to enable the UE to select and access a desired SNPN. It also allows provisioning the UE with credentials for Network Slice-Specific Authentication and Authorization (NSSAA) or secondary authentication/authorization. Provisioning of the UE is done via User Plane connectivity. To be able to provision SNPN credentials in a UE, as the 5GS requires security to be enabled the UE needs to use some already available credentials to access a 5GS, i.e. either:

1. The UE has Default UE credentials in which case the UE selects an SNPN as ONN and then the UE registers using Registration Type set to "SNPN Onboarding" that enables the 5GC to restrict the connectivity to Onboarding service e.g. using a dedicated S-NSSAI within the network.
2. The UE uses existing PLMN or SNPN credentials in which case the UE uses the existing credentials to get access connectivity to a PLMN or SNPN.

During the PDU Session establishment the UE can get one or more addresses to one or more Provisioning Server(s) that the UE access over the User Plane for getting provisioning with the SNPN credentials and additional information to get connectivity to the SNPN. Support of IMS voice and emergency services for SNPN: Support for IMS voice and emergency services is enabled e.g. allowing the UE to select an SNPN in limited service to access IMS emergency services. Informative description how an SNPN can deploy an IMS or how one or more independent IMS providers can be used by an SNPN. NPN support for Video, Imaging and Audio for Professional Applications (VIAPA): Informative description how a UE accessing an overlay network via an underlay network, see Figure 6.2.3.1-1, can be kept in CM-CONNECTED state in the overlay network. Informative description how session/service continuity between SNPN and PLMN can be achieved when the UE has a subscription for a PLMN and for an SNPN and accessing one network as overlay network using the other network as underlay network. Informative description how to support QoS differentiation for User Plane IPsec Child SA in an underlay network.

Management aspects (from Huawei, SP-220570): The management part is covered in TS 28.557 "Management and orchestration; Management of NPN; Stage 1 and stage 2". TS 28.557 specifies concepts, use cases, requirements and solutions for management of non-public networks. To support management of non-public networks, the following are addressed: Roles related to NPN management; Different management modes of NPN; Generic solutions for management of NPN; Solutions for management of SNPN; Solutions for management of PNI-NPN. Related CRs:

Summary based on the input provided by China Telecom in RP-220562. This Work Item, specified by RAN2 and RAN3, enables:

• Support SNPN along with subscription / credentials owned by an entity separate from the SNPN including: broadcasting of information to enable SNPN selection for UEs with subscription/credentials owned by an entity separate from the SNPN; associated cell selection/reselection and connected mode mobility support; necessary modifications over network interfaces (e.g. NG, Xn, F1, E1 etc)
• Support UE onboarding and provisioning for NPN including: The UE onboarding relevant parameter broadcast from SIB; associated cell selection/reselection, cell access control and the connected mode mobility support; necessary modifications over network interfaces (e.g. NG, Xn, F1, E1 etc)
• Support of IMS voice and emergency services for SNPN: Broadcasting of relevant parameters
• Support of PWS for SNPN

Support SNPN along with subscription / credentials owned by an entity separate from the SNPN For this feature, the term "Credentials Holder (CH)" is used for the external entity providing subscription or credential for SNPNs and the term "Group IDs for Network Selection (GINs)" is used for the service provider Group IDs. In TS 38.331, the following statement is added: "An SNPN may allow access to UEs being authorized using credentials or subscription owned by a separate credential holder (CH). The support of this feature is uniform across the SNPN as specified in TS 23.501 [3]." For Uu interface, the indication of SNPN access with subscription of a Credentials Holder is broadcast in SIB1 per SNPN. Optionally, Group IDs for Network selection (GINs) could be broadcast in SIBXY. Each GIN may be assigned to one or more SNPNs. There is a common list of GINs for both onboarding and SNPN access using external CHs. For each SNPN there is a vector that describes which GINs are supported, the maximum number of GINs is 24 per cell. For cell selection/reselection, since SA2 has the conclusion the indication of SNPN access with subscription of a Credentials Holder should be set uniformly, there is no impact on cell (re)selection to support SNPN with subscription or credentials by a separate entity. No UE impact was identified on connected mode mobility for external CH. Support UE onboarding and provisioning for NPN For onboarding support, the section "Support of UE onboarding and remote provisioning" is added in TS 38.331. The procedure of AMF selection in TS 38.410 is modified for supporting onboarding as follow: "Therefore, a NAS node selection function is located in the NG-RAN node to determine the AMF association of the UE, based on the UE's temporary identifier, which was assigned to the UE by the AMF. When the UE's temporary identifier has not been yet assigned or is no longer valid the NG-RAN node may instead take into account other information (e.g. slicing information, onboarding indication) to determine the AMF." For Uu interface, the indication of UE onboarding and remote provisioning is broadcast in SIB1 per SNPN. As for "on-boarding support" indicator, cell selection and suitability criteria of a SNPN cell are not affected. NAS will anyway allow access for onboarding only if the cell/SNPN supports onboarding. Toggling the 1-bit onboarding indication in SIB1 allows to control congestion due to onboarding request. No UE impact was identified on connected mode mobility for onboarding. For NG interface, the new "Onboarding Support" IE is included within the same PLMN Support Item IE in the NG SETUP RESPONSE/AMF CONFIGURATION UPDATE message, the related statement for NG SETUP procedure, in TS 38.413, is added as follows: "If the Onboarding Support IE is also included within the same PLMN Support Item IE, the NG-RAN node shall, if supported, consider that the AMF supports UE onboarding for the identified SNPN, as specified in TS 23.501 [9]." Support of IMS voice and emergency services for SNPN Emergency services are supported for SNPN in Rel-17, which is the new feature compared with Rel-16. UE in SNPN access mode could select the SNPN with imsEmergencySupportForSNPN=true for emergency services. For Uu interface, the indication of support for emergency services is broadcast in SIB1 per SNPN. Support of PWS for SNPN PWS over SNPN is supported in Rel-17. In TS 38.300, the statement that ETWS and CMAS are not supported over SNPN is removed. Related CRs: