Summary based on the input provided by Huawei, Hisilicon in SP-220577. This Feature enhances 5G core network to support Edge Computing as specified in TS 23.548. The main functionalities include the discovery and re-discover of Edge Application Server (EAS), edge relocation, network exposure to EAS, support of 3GPP application layer architecture for enabling Edge Computing, and AF guidance to determination of URSP rules. The outputs of corresponding study phase are documented in TR 23.748. Discovery and re-discovery of Edge Application Server: Edge relocation: Network exposure to EAS: Support of 3GPP application layer architecture for enabling Edge Computing: AF guidance to PCF determination of URSP rules:

Summary based on the input provided by Samsung in SP-220622. Edge computing is a well-known industry concept, and is supported within 3GPP networks with the introduction of Edge computing capabilities in 5G System Architecture (TS 23.501). While there have been efforts at the system level, the overall application layer architecture needs supporting environment (such as provisioning, discovery, registration, enabler layer capability exposure, network capability exposure, support for service continuity) to enable edge applications over 3GPP networks. TS 23.558 specifies the architecture, procedures and information flows to enable edge applications over 3GPP networks. Architecture for enabling edge applications based on the architectures principles such as UE application portability, Edge Application portability, service differentiation and flexible deployment. The Edge Data Network (EDN) is a local Data Network. Edge Application Server(s) and the Edge Enabler Server (EES) are contained within the EDN. EES is primarily responsible for enabling discovery of the EASs; Edge Enabler Client supports EAS discovery to the ACs in the UE; and, Edge Configuration Server, providing configurations to the EEC. The Edge Configuration Server provides configurations related to the EES, including details of the Edge Data Network hosting the EES. The UE contains Application Client(s) and the Edge Enabler Client (EEC). The Edge Application Server(s), the Edge Enabler Server and the Edge Configuration Server may interact with the 3GPP Core Network. With the support of the enabling layer, TS 23.558 provides many rich features at the application layer for support of the Edge Application, such as:

• Service Provisioning: Enabling a UE with an Edge Enabler Client to find and connect to available Edge Data Networks.
• Rich discovery: On-demand configuration provisioning by the Edge Configuration Server and the query support of Edge Enabler Server allows discovery of the Edges and the Edge Application Servers by a UE equipped with the Edge Enabler Client.
• Dynamic availability: Due to the flexible nature, the availability of Edge and the EAS can change dynamically due to multiple reasons, such as change in deployments, mobility of the UE etc. UE can subscribe to such changes to fine tune the services provided accordingly.
• Capability exposure: EES capability is exposed as APIs to EAS (e.g. via CAPIF as specified in TS 23.222) as value added services to the EASs. The EASs and EESs can also utilize 3GPP network capability exposure as SCEF/NEF northbound APIs.
• Support for service continuity: With the UE being mobile, eventually, a different server on Edge or Cloud can become more suitable for serving the AC. To enable continuity of service in such scenarios, the architecture supports transfer of the UE's application context to the new server whenever needed; allowing the new server to restore the service without losing the application context.

Management aspects of application layer support of the Edge Applications is specified in TS 28.538. Security aspects of application layer support of the Edge Applications is specified in TS 33.558. Stage 3 normative work for application layer support of the Edge Applications are specified as open APIs in TS 24.558 and 29.558 [6].

Summary based on the input provided by Samsung in SP-220020. The ECM Work Item and the resulting specification in TS 28.538 provides management provisions and solutions for edge computing considering related requirements from SA6 EDGEAPP WI including lifecycle management, provisioning, performance assurance and fault supervision for EDGEAPP defined entities. Edge computing is a well-known industry concept, with 3GPP 5G System Architecture supporting Edge computing deployments by enabling certain features as listed in sub clause 5.13 of TS 23.501. SA6, as part of TS 23.558, have defined the functionality and concepts required for enabling Edge Applications in 3GPP networks. The functionalities defined to be deployed in 3GPP networks include Edge Application, Edge Enabler Server and Edge Data Network Configuration Server. The management provisions for these functionalities are addressed as part of this WI. The management solutions in preview of this WI includes.

• Provisioning and LCM: Provisioning includes configuration and lifecycle management. It deals with defining NRMs (Network Resource Model) for the edge entities to be managed and also defining usage of those NRMs by the management services to achieve provisioning and lifecycle management.
• Performance Assurance: It deals with defining edge specific performance measurements and KPIs. The collection mechanism for the same is also defined.
• Fault Supervision: It deals with defining edge specific alarm. The collection mechanism for the same is also defined.
• Connection to 5GC: Connecting edge nodes to 5GC is crucial part of edge computing management. The defined NRM fragments to enable the same.

Summary based on the input provided by ZTE in SP-210890 for SA and CT aspects, and by CMCC, ZTE in RP-221376 for RAN aspects [note from the editor: one single summary was expected to cover ALL aspects]. This work item specifies the system enhancements to support some parameters of GST (Generic Slice Template) as documented in NG.116. The following enhancements are specified in this work item.

• A new NSACF(Network Slicing Admission Control Function) is defined to monitor and control the number of registered UEs per network slice and the number of PDU Sessions per network slice for the network slices that are subject to Network Slice Admission Control (NSAC)
• A new QoS parameter "Slice-Maximum Bit Rate" (S-MBR) is defined to limit the aggregate data rate in UL and DL per UE across all GBR and Non-GBR QoS Flows for all PDU sessions associated with an S-NSSAI for the UE. The S-MBR is enforced in RAN and is available in PCF for optional input to apply current QoS functionality. In addition the PCF for the PDU Session may also be configured to monitor the data rate per Network Slice for a UE and to strengthen or relax the traffic restrictions for individual PDU Sessions or PCC rules accordingly
• The PCF is enhanced to monitor the data rate per Network Slice and based on operator policies, apply a policy decision to strengthen the traffic restrictions for individual PDU Sessions or PCC rules to ensure that the data rate for the network slice does not exceed the NW Slice maximum data rate parameter which is configured and stored in the UDR. The PCF may use NWDAF service to monitor the data rate per Network Slice.
• An optional Network Slice Simultaneous Registration Group (NSSRG) information for each S-NSSAI in UE subscription is defined to indicate which S-NSSAIs can be simultaneously provided to the UE in the Allowed NSSAI. The serving PLMN AMF may also provide the supporting UE with the NSSRG information related to the S-NSSAIs of the HPLMN which are in the mapping information of the Configured NSSAI. A UE which receives the NSSRG values in the network slicing configuration information shall only include in the Requested NSSAI S-NSSAIs that share a common NSSRG as per the received information.
• A mechanism is defined to allow the AMF to provide Target NSSAI and RFSP to RAN to steer the UE to another cell supporting network slices not available in a current cell and RA. The Target NSSAI includes at least one S-NSSAI from the Requested NSSAI not available in the current TA, but available in another TA in different frequency band possibly overlapping with the current TA, and optionally additional S-NSSAIs from the Requested NSSAI that are configured to be available within the same TAs as the S-NSSAIs not available in the current TA.

Enhancement of RAN slicing for NR was specified through this WI to define the slice aware cell reselection and slice specific RACH configuration and prioritization, as well as to define solutions to support slice-based service continuity, and to support the enforcement of Slice MBR, the usage of Target NSSAI as introduced by SA2. Support slice aware cell reselection A new NSAG (Network Slice AS Group) mechanism is introduced for slice aware cell reselection and slice specific RACH configuration, in order to avoid exposing S-NSSAI over Uu interface for reason of security and overhead. In the system information, the NSAG information is broadcast instead of S-NSSAI. In order to assist slice aware cell reselection, the NG-RAN node can provide NSAG specific cell reselection information of current cell and neighbour cell in system information and in RRCRelease message as specified in TS 38.331. The NSAG specific cell reselection information is provided per frequency per NSAG. If NSAG specific cell reselection information is provided in dedicated signalling, the UE shall ignore NSAG specific cell reselection information provided in system information. In the UE, NAS provides the NSAG information and their priorities to be considered during cell reselection to the AS. When a UE supports slice aware cell reselection, and NSAG specific cell reselection information is provided to the UE, then the UE performs the slice aware cell reselection. The details of slice aware cell reselection are specified in TS 38.304. In general, the UE can derive reselection priorities for slice aware cell reselection, and then perform cell reselection evaluation using legacy evaluation criteria. Support slice specific RACH configuration In order to support slice specific RACH configuration, separated RACH partitioning (e.g., transmission occasions of time-frequency domain and preambles) and RACH prioritization parameters (i.e., scalingFactorBI and powerRampingStepHighPriority) can be configured per NSAG in system information as specified in TS 38.331. All slices of a NSAG use the slice specific RACH configuration of the same NSAG. In a cell, there may be multiple slice-specific RACH configurations. One or more of the NSAGs can be linked to a slice-specific RACH configuration. If a NSAG is not linked to any slice specific RACH configuration, the common RACH configuration can be used. Support service continuity In order to support service continuity for specific slice(s), the NG-RAN node may use Multi-Carrier Resource Sharing or Resource Repartitioning to allocate resources to a slice in case of slice resources shortage. In Multi-Carrier Resource Sharing the RAN node can setup the dual connectivity or carrier aggregation with different frequency and overlapping coverage where the same slice is available. The Resource Repartitioning allows a slice to use resources from the shared pool or/and prioritized pool when its own dedicated or prioritized resources are not available and the use of unused resources in the prioritized pool is as specified in TS 28.541. Slice RRM policies/restrictions associated with Resource Repartitioning are configured from O&M. Measurements of RRM policy utilization according to resource types defined in TS 28.541 are reported from RAN nodes to O&M and may lead O&M to update the configuration of the Slice RRM policies/restrictions. Support the enforcement of Slice MBR and the usage of Target NSSAI The UE-Slice MBR is introduced to limit the aggregate bit rate that can be expected to be provided across all GBR and Non-GBR QoS Flows corresponding to PDU Sessions of the UE for the same slice (S-NSSAI) as specified in TS 23.501 and is ensured by the RAN. In case of Dual Connectivity, the MN decides the DL UE Slice MBR and UL UE Slice MBR limits to be assigned to the SN, and indicates these to the SN. In addition, the PDCP entity at the SN applies the received DL UE Slice MBR limit to the set of all bearers for which the SN hosts PDCP for the concerned Slice, as defined in TS 23.501, and the MAC entity at the SN applies the received UL UE Slice MBR limit to the scheduled uplink radio traffic at the SN for the concerned Slice, as defined in TS 23.501. In order to support the enforcement of Slice MBR, RAN interfaces including NG, Xn, F1 and E1 are enhanced to transmit UE-Slice-MBR. Target NSSAI is determined by Core Network on a per UE basis, and used by NG-RAN to attempt to redirect the UE to a cell and TA in another frequency band and TA that supports the S-NSSAIs in the Target NSSAI, as defined in TS 23.501. In order to support the usage of Target NSSAI at NG-RAN, NG interface is enhanced to transmit Target NSSAI.

Summary based on the input provided by MATRIXX Software in SP-220075. In 5G system when Network Slices allocated to third party providers are deployed by Mobile Network Operators, how these third-party providers can be charged for usage of assigned Network Slice(s), is not described. This work item introduces a description focusing on one particular type of Network Slice usage, leveraging from capabilities specified from Rel-15. 5G Data Connectivity charging specified in 5GS between SMF and CHF for individual UEs PDU sessions from Rel-15, is used with Converged Charging System (CCS) hosting the CHF extended to also cover the third-party provider (addressed under the tenant concept). By receiving the S-NSSAI for each UE PDU session, the enhanced CCS is able to perform per tenant charging based on tenant's Network Slice total UEs data connectivity usage, the Network Slice being identified by the S-NSSAI. The internal behaviour of the enhanced CCS is not specified in this release.

Summary based on the input provided by CMCC in RP-220822. This work item introduces enhancement of SON and MDT features support in NR standalone and MR-DC, including CCO, inter-system inter-RAT energy saving, inter-system load balancing, 2-step RACH optimization, mobility enhancement optimization, PCI selection, energy efficiency (OAM requirements), Successful Handovers Reports, UE history information in EN-DC, load balancing enhancement, MRO for SN change failure, RACH Optimisation enhancements, MDT enhancement and L2 measurements. The key functionalities of this WI are described as below. NR Coverage and Capacity Optimization (CCO) NR Coverage and Capacity Optimization (CCO) function is to detect and mitigate coverage and cell edge interference issues. Each NG-RAN node may be configured with alternative coverage configurations by OAM. The alternative coverage configurations contain relevant radio parameters and may also include a range for how each parameter is allowed to be adjusted. An NG-RAN node may autonomously adjust within and switch between coverage configurations. When a change is executed, a NG-RAN node may notify its neighbour NG-RAN nodes using the NG-RAN NODE CONFIGURATION UPDATE message with the list of cells and SSBs with modified coverage included. The list contains the CGI of each modified cell with its coverage state indicator and optionally the SSB index of each modified SSB with its coverage state indicator. Inter-system inter-RAT energy saving The solution builds upon the possibility for the NG-RAN node owning a capacity booster cell to autonomously decide to switch-off such cell to dormant state. The decision is typically based on cell load information, consistently with configured information. The switch-off decision may also be taken by O&M. The NG-RAN node indicates the switch-off action to the eNB over NG interface and S1 interface. The NG-RAN node could also indicates the switch-on action to the eNB over NG interface and S1 interface. The eNB providing basic coverage may request a NG-RAN node's cell re-activation based on its own cell load information or neighbour cell load information, the switch-on decision may also be taken by O&M. The eNB requests a NG-RAN node's cell re-activation and receives the NG-RAN node's cell re-activation reply from the NG-RAN node over the S1 interface and NG interface. Upon reception of the re-activation request, the NG-RAN node's cell should remain switched on at least until expiration of the minimum activation time. The minimum activation time may be configured by O&M or be left to the NG-RAN node's implementation. Inter-system load balancing The load reporting function for inter-system load balancing is executed by exchanging load information between NG-RAN and E-UTRAN. Both event-triggered and periodic inter-system load reporting are supported. Event-triggered inter-system load reports are sent when the reporting node detects crossing of cell load thresholds. The following load related information should be supported:

• Cell Capacity Class value (UL/DL relative capacity indicator);
• Capacity value (per cell: UL/DL available capacity);
• RRC connections (number of RRC connections, and available RRC Connection Capacity);
• Number of active UEs.
• PRB usage (per cell: UL/DL)

NGAP procedures used for inter-system load balancing are Uplink RAN Configuration Transfer and Downlink RAN Configuration Transfer. S1AP procedures used for inter-system load balancing are eNB Configuration Transfer and MME Configuration Transfer. 2-step RACH optimization 2-step RACH optimization is supported by UE reported 2-step RACH related information made available at the NG RAN node and by PRACH parameters exchange between NG RAN nodes. PCI selection For aggregated architecture and centralized PCI assignment in gNB, the OAM assigns a single PCI for each NR cell in the gNB, and the gNB selects this value as the PCI of the NR cell. For Aggregated architecture and distributed PCI assignment in gNB, the OAM assigns a list of PCIs for each NR cell in the gNB, and the gNB selects a PCI value from the list of PCIs. The gNB may restrict this list by removing some PCIs that are reported by UEs, reported over the Xn interface by neighboring gNBs, and/or acquired through other methods, e.g. detected over the air using a downlink receiver. The PCI Optimization Function in split gNB case, the OAM configures a PCI for each NR cell to the gNB-DU. For centralized PCI assignment in split gNB architecture, the gNB-CU detects PCI conflict of NR cells and reports the NR cells suffering PCI confilict to OAM directly. The OAM is in charge of reassigning a new PCI for the NR cell subject to PCI conflict. For distributed PCI assignment in split gNB architecture, the OAM assigns a list of PCIs for each NR cell and sends the configured PCI list to the gNB-CU. If the gNB-CU detects PCI conflict, the gNB-CU may select a new PCI value from the preconfigured PCI list for the NR cell and send it to the gNB-DU by either F1 Setup procedure or gNB-CU configuration update procedure. Energy efficiency (OAM requirements) To calculate the energy efficiency of base stations, ETSI ES 203 228 ("Environmental Engineering (EE); Assessment of mobile network energy efficiency") defines the following high-level EE KPI: In which Mobile Network data Energy Efficiency (EEMN,DV) is the ratio between the performance indicator (i.e. Data Volume DVMN) and the energy consumption (ECMN). Successful Handovers Reports Successful Handovers Reports is reported by the UE to detect failure events happened during successful handovers. The solution for the problem may consist of the following steps:

1. UE is configured with triggering conditions to compile the Successful Handover Report;
2. Only if the conditions are met, UE generates Successful Handover Report comprising a set of measurements collected during the successful handover phase, i.e. measurement at the handover trigger, measurement at the end of handover execution or measurement after handover execution.
3. The availability of a Successful Handover Report may be indicated by Completed message (RRCReconfigurationComplete, RRCReestablishmentComplete, RRCSetupComplete, RRCResumeComplete) transmitted from UE to NG-RAN node over RRC. The NG-RAN node may fetch information of a successful handover report via UE Information Request/Response mechanism.
4. NG-RAN node could forward the Successful Handover Report to the source NR-RAN node to indicate failures experienced during a successful handover event.

Upon reception of a Successful HO Report, the receiving node is able to analyse whether its mobility configuration needs adjustment. UE history information in EN-DC UE history information is introduced in EN-DC to avoid Ping Pong effect. The MN stores and correlates the UE History Information from MN and SN(s) as long as the UE stays in MR-DC, forwards UE History Information and optional UE History Information from the UE to its connected SNs. The resulting information is then used by SN in subsequent handover preparation. The SN is in charge of collecting SCG UE history information and providing the collected information to the MN based on MN request or MN subscription on the PSCell change. The MN may retrieve the SCG UE history information via the SN Addition and SN Modification procedures. SN shall provide the SCG UE history information, if available, in the SN Addition, SN Modification, SN Release, and SN initiated SN Change procedures. Load balancing enhancement The load reporting function is executed by exchanging load information over the Xn/X2/F1/E1 interfaces. Besides the load metrics introduced in Rel-16, some more metrics are introduced for intra-system load balancing, including, PRB usage for slice(s): DL/UL GBR PRB usage, DL/UL non-GBR PRB usage, and DL/UL Total PRB allocation) and PRB utilisation for MIMO To achieve load reporting function, Resource Status Reporting Initiation & Resource Status Reporting procedures are used. MRO for SN change failure For analysis of PSCell change failure, the UE makes the SCG Failure Information available to the MN. MN performs initial analysis to identify the node that caused the failure. If the failure is caused by a SN, the MN forwards the SCG Failure Information to the SN. The SN performs the final root cause analysis. The details of the solution, including the description in this paragraph are FFS. One of the functions of self-optimization for PSCell change is to detect PSCell change failures that occur due to Too late PSCell change or Too early PSCell change, or Triggering PSCell change to wrong PSCell. These problems are defined as follows:

• Too late PSCell change: an SCG failure occurs after the UE has stayed for a long period of time in the PSCell; a suitable different PSCell is found based on the measurements reported from the UE.
• Too early PSCell change: an SCG failure occurs shortly after a successful PSCell change from a source PSCell to a target PSCell or a PSCell change failure occurs during the PSCell change procedure; source PSCell is still the suitable PSCell based on the measurements reported from the UE.
• Triggering PSCell change to wrong PSCell: an SCG failure occurs shortly after a successful PSCell change from a source PSCell to a target PSCell or a PSCell change failure occurs during the PSCell change procedure; a suitable PSCell different with source PSCell or target PSCell is found based on the measurements reported from the UE.

MDT enhancement

• Support for NR MDT IDC mechanism
• Extension to LoggedMeasurementConfiguration with a flag to indicate if an early measurement/idle mode configuration has relevance for logged measurement purposes
• UE support to assist the network in preventing management based logged MDT overwriting signalling based logged MDT
• Extension to LoggedMeasurementConfiguration with Logged MDT type indication used for signalling MDT protection
• RACH failure report extension with 2-step RACH relevant information
• Support for multiple CEF reports
• Support of M5~M7 for EN-DC SN terminated MCG bearer/split bearers and MN terminated SCG/split bearers
• Immediate MDT configuration support for MN terminated SCG bearer and SN terminated MCG/split bearer by the terminated node, e.g., MN in case of MN terminated SCG bearer
• RLF report support for CHO and DAPS HO
• Support for logging of on-demand SI

L2 measurement PRB usage for MIMO was first introduced to NR in Rel-16 to reflect the PRB usage at the case of MU-MIMO and multiple MIMO layers. Configuring the same constant value Alpha for all the cells sometimes is not suitable, especially for cells in bad radio condition. And it is also difficult to manually configure Alpha for each cell, considering the large number of NR base stations. In Rel-17, PRB Usage based on statistical MIMO layer and Enhanced PRB Usage for MIMO are specified. Comparing with R16 PRB usage measurement, the new PRB usage measurement can adjust Alpha autonomously, e.g., based on statistical data of MIMO layer. The objectives of the measurements are to measure usage of time and frequency resources. A use-case is OAM performance observability. In addition, PDCP excess packet delay is also specified for delay sensitive services, e.g., URLLC. The objective of this measurement performed by UE is to measure Excess Packet Delay in Layer PDCP for QoS verification of MDT.

Summary based on the input provided by China Mobile in SP-220580. This WI specifies the concepts for autonomous networks, autonomous network level (ANL), and use cases, requirements and solutions for the levels of autonomous functions in a 3GPP network. Examples of enablers for autonomous network are: Self-Organization Network (SON), management data analytics (MDA), intent driven management (IDM), closed loop SLS assurance (COSLA). Autonomous network is a telecommunication system (including management system and network) with autonomy capabilities which is able to be governed by itself, with minimal to no human intervention. ANL is used to describe the level of autonomy capabilities in the autonomous network. A framework approach for evaluating ANL is as follows:

This WI specifies the Generic autonomous network level for network optimization, the RAN NE deployment and the fault management.

Summary based on the input provided by vivo/China Mobile in SP-220629. In addition to NWDAF related work initiated in Rel-15 and Rel-16, this WI (eNA_Ph2) further specify framework enhancements and define extensions to existing Nnwdaf service for supporting network automation. The Network Data Analytics Function (NWDAF) is to support network automation as listed in TS 23.288 and includes one or more of the following functionalities:

• Support data collection from NFs, AFs and OAM as shown;
• NWDAF service registration and metadata exposure to NFs and AFs;
• Support analytics information provisioning to NFs and AFs as shown;
• Support Machine Learning (ML) model training and provisioning to NWDAFs (containing Analytics logical function).

In addition to the framework specified in Rel-15 and Rel-16, further specify framework enhancements to support network data analytics service:

• Logical function decomposition of NWDAF (Model Training logical function, Analytics logical function) and the interactions between these logical functions as shown in Figure 9.4.3-1;
• Increasing efficiency of data collection;
• Trained data model sharing between multiple NWDAF instances, limited to single vendor environments;
• multiple NWDAF instances;
• UE data as an input for analytics generation (via AF);
• User consent for UE data collection/analysis;
• Triggering conditions for the Data Analytics;
• Enhancement for real-time communication.

In addition to Nnwdaf services defined in R15 and R16, define extensions to support the analytics that are required for Slice SLA enhancement, Dispersion Analytics, NWDAF-assisted UP optimization, NWDAF-assisted RFSP policy, UP optimization for edge computing, adding application attributes to User Data congestion Analytics.

Summary based on the input provided by Intel in SP-220574. The MUSIM work item specifies 5GS and EPS support for Multi-USIM UEs for delivery of Mobile Terminated (MT) services, enabling paging reception and performing coordinated leaving. A Multi-USIM UE is a UE with multiple USIMs, capable of maintaining a separate registration state with a PLMN for each USIM at least over 3GPP access and supporting one or more of the MUSIM features described further below. The stage-1, stage-2 and security studies are documented in TR 22.834, TR 23.761 and TR 33.873, respectively. The service requirements are specified in TS 22.101, TS 22.261 and TS 22.278. The stage-2 aspects for 5GS are specified in TS 23.501 and TS 23.502. The stage-2 aspects for EPS are specified in TS 23.401 and TS 23.272. IMS-related aspects are specified in TS 23.228. NAS protocol aspects are specified in TS 24.501 and TS 24.301 for 5GS and EPS, respectively. A new MUSIM-specific rejection cause is specified in TS 29.518 and TS 29.274 for 5GS and EPS, respectively. MUSIM-specific AT commands are specified in TS 27.007. The RAN-related aspects of MUSIM are covered by a related RAN work item (RP-213679 [17]). The following features were specified as part of the MUSIM work item:

• Connection Release, allowing the Multi-USIM UE to request the network to release the UE from RRC-CONNECTED state in 3GPP access for a USIM due to activity on another USIM in 3GPP access.
• Paging Cause Indication for Voice Service, allowing the network to indicate to the Multi-USIM UE when it is being paged for voice.
• Reject Paging Request, allowing the Multi-USIM UE to indicate to the network that the UE does not accept the paging and requests to return to CM-IDLE state after sending this response.
• Paging Restriction, allowing the Multi-USIM UE to request the network to not be paged for any MT service, or to be paged only for voice, or for traffic arriving on selected PDU Session / PDN Connection, or for a combination thereof.
• Paging Timing Collision Control, allowing the Multi-USIM UE to request an IMSI Offset (EPS) or a new 5G-GUTI (5GS) that is used for determination of paging occasions.

The Multi-USIM UE and the 5GC/EPC exchange their MUSIM capabilities as part of the Registration procedure (5GS), or the Attach and Tracking Area Update procedures (EPS). The following 3GPP system entities are impacted by MUSIM:

• UE.
• MME / AMF.
• RAN / NG-RAN.
• SGW-C / SMF (new rejection cause).

The following procedures in TS 23.502 and TS 23.401 are impacted by MUSIM:

• Service Request (for Reject Paging, Connection Release, Paging Restrictions).
• Registration / Attach / Tracking Area Update (for MUSIM capability exchange, Paging Timing Collision Control).
• Registration / Tracking Area Update (for Connection Release, Paging Restrictions).
• N2 Paging / S1 Paging (for Paging Cause Indication for Voice Service).

Summary based on the input provided by vivo in RP -220604. This work item specifies solutions to address the paging occasion collision issue for single-Rx/single-Tx Multi-USIM (MUSIM) UE, and to notify network A of its switch from network A for MUSIM purpose, and to support indicating to the MUSIM UE whether an incoming paging is for voice service. The following schemes were introduced as part of the Work Item:

• Paging collision objective: To solve paging occasion collision problem, the MUSIM UE can trigger a new 5G-GUTI reallocation in 5GS or an IMSI offset assignment in EPS to modify the timing of the paging occasions. In 5GS, the UE obtains a new 5G-GUTI by performing a MRU without any specific indication. In EPS, the UE can provide a requested IMSI offset value in Attach Request or TAU Request, which triggers the MME to provide an accepted IMSI Offset value in the Attach Accept or TAU Accept message. The MME and UE use the alternative IMSI (calculated based on the IMSI and the accepted IMSI offset) for the determination of paging occasion.
• Network notification objective: AS-based network switching for leaving RRC_CONNECTED and network switching without leaving RRC_CONNECTED (i.e., requesting/configuring MUSIM gaps) were introduced. Both schemes can be configured by the network separately.
  When determining it needs to leave RRC_CONNECTED, the UE sends the UEAssistanceInformation message, which indicates the UE's preferred RRC state when leaving RRC_CONNECTED for MUSIM purpose. gNB may release the UE to RRC IDLE/INACTIVE when receiving this UAI. The UE is allowed to enter RRC_IDLE if it does not receive response message from network within a certain configured time.
  When determining it needs the MUSIM gaps, the UE sends the UEAssistanceInformation message, which indicates the UE's preference on the MUSIM gaps. The UE can request at most a single aperiodic MUSIM gap and two periodic MUSIM gaps. The MUSIM gap is per UE level.
• Paging cause objective: a paging cause field with only one codepoint voice was introduced in the NR/LTE Uu paging message, S1AP/NGAP paging message, and XNAP/F1AP paging message. The network provides this field for the upcoming paging triggered by IMS voice, only if the UE indicates the paging cause feature is supported to the network. In order to enable NG-RAN to deliver the paging cause in RAN paging for the UE in RRC-INACTIVE, the AMF provides an indication indicating the Paging Cause Indication for Voice Service feature is supported to the NG-RAN. The NG-RAN node knows the downlink data which triggers the RAN Paging message is related to voice service based on the Paging Policy Indicator, in the header of the received downlink data.