SEAL is the service enabler architecture layer common to all vertical applications over 3GPP systems. It provides the functions like location management, group management, configuration management, identity management, key management, network resource management and network slice capability management as defined in TS 23.434. Network slicing is a general network capability which can be applied for many vertical industries. The network slice capability management service in TS 23.434 only provides capability of network slice adaptation between NSCE server and the NSCE client. However, for such capability both control plane and management plane interactions need to be considered since there is close coupling between the per UE session and the per slice related actions. For example, the SEAL/NSCE layer may need to be aware of the slice provisioning parameters (NSI/NSSI configuration) which can be provided by the slice management system. Furthermore, NSI/NSSI performance monitoring from management system (e.g. NSI/ NSSI status) may be useful to be known at the enabler layer, since this may affect the application to slice re-mapping triggering (e.g. to re-map to the least congested slice); and may also impact other SEAL provided functionalities (e.g. QoS/resource control, group management etc). Open issues:

• Whether and which enhancement to SEAL network slice capability management service is required having in mind SA2 and SA5 slice related exposure?
• Whether a potential enhancement to SEAL network slice capability management functional model is required?
• Whether new or enhanced APIs are needed to support the potential SEAL enhancements?
• How the network slice capability (such as management service (MnS)) consumption may trigger and impact the value-add services provided by the SEAL layer?

It is specified in clause 6.10 of TS 22.261 that 5G network is required to provide suitable APIs to allow a trusted third-party to create, modify, scale and delete network slices used for the third-party. As specified in 28.531 [5], SA5 has defined the network slice lifecycle management service. SA6 can provide a more concise application layer exposed network slice lifecycle management with additional functionality for verticals. It can help vertical do the lifecycle management without knowledge of SA5 O&M defined interfaces and APIs. In addition, with the network slice related information (such as network slice status reported from NSACF), the SA6 could trigger some slice lifecycle management operations automatically to provide a value-added lifecycle management service. It is not clear how to expose the network slice lifecycle management service from application perspective with providing additional value on top of existing SA5 solution. NOTE: The interface which may be used in this KI is specified in TS 28.532, and the enabler layer could use the interface exposed by EGMF defined in TS 28.533. Hence, it is required to study the following issues:

• How to integrate and expose the SA5 and SA2 network slice related capability to provide some value-added lifecycle management service from application layer?
• Whether and how additional service APIs are required to be supported for application layer enablement of network slice lifecycle management?
• Whether and how CAPIF can be leveraged for additional service APIs.

There are use cases (being discussed also in SA1, TR 22.835), where the applications (e.g. gaming or online video applications) may access the 5GS over multiple slices for different services (e.g. based on the user membership); or have different priorities on different slices based on Application Service Provider (ASP) request. As an example, a mobile network operator has provisioned a set of network slices (Slice#1, Slice#2, Slice#3) which may be used by different ASPs (e.g. Slice#1 for online video services, Slice#2 for gaming. Slice#3 for eMBB or IOT service). Different ASPs may use these slices (or a subset of them) for different services that they offer. Furthermore, when an application changes the network slices to be accessed, it should be agnostic to the UEs accessing the service and should be performed automatically. The vertical enablement layer (SEAL, vertical-specific enablers) supports the exposure of telco provided services to the vertical / application service provider (ASP). Such telco-provided services traditionally covered the 3GPP control plane services (provided by SA2); however, these can be extended to 3GPP management domain services (provided by SA5) which may be useful for allowing the ASP to monitor and manage the slices used by the UEs. The enabler layer can be seen as a trusted application entity that interacts with the management system on behalf of ASP to allow the exposure of management services related to the offered slices. It can be used to trigger dynamic slice-related actions and also reduce complexity at the ASP side. In this extended notion of vertical enablement (to cover the 3GPP management service exposure), the vertical/ slice customer needs to be able to 1) discover the relevant Network Slice Instances and the respective capabilities such as coverage offered, RAT/ frequencies, to 2) discover the management services (based on TS 28.533) which can be exposed as part of the offered slices, and 3) register to the 3GPP management domain via the vertical enabler layer for consuming the management services. This study needs to investigate:

• Whether and how SEAL needs to be enhanced to support the discovery of the offered slices and the offered management services related to these slices, to the vertical/ASP;
• Whether and how SEAL needs to be enhanced to support the registration of the vertical applications to the 3GPP management domain.

As the requirement captured in TS 22.261, based on operator policy, the 5GS shall provide suitable APIs to allow a trusted third-party to monitor the network slice used for the third-party according to operator policy. In addition, the descriptions of network diagnostics are captured in clause F.2 of TS 22.261 as following: Network diagnostics helps with scanning, diagnosing and identifying problems within a network. Diagnostics includes gathering data and continuously providing sufficient performance parameters that characterize the quality of the network connection. This includes data of the physical connection as well as of logical links and sub-networks. Exposure of relevant (and possibly aggregated) performance parameters ensures a quick reaction in case of failure as well as identifying network connectivity, performance and other related problems. Network diagnostic information needs to be generated automatically and, in case of a hosted or virtual network deployment, be made available to the tenant of the network via a suitable API. The alarm data can be used to help the third-party to diagnose the fault problem of the services, locate the fault causes, and to be aware of the potential fault. In TS 28.545, the fault supervision management services are standardized by which the alarm of the network slice instance from network resource aspects can be subscribed and reported. This alarm information together with the application function's fault report and communication service related knowledge can be utilized by the SEAL/NSCE to diagnose and locate the cause of the service performance deterioration and the fault of the communication services, and then exposed the fault report to the third-party. For example, if the status of the required communication is not correct, the SEAL/NSCE derives this alarm information from application functions. In this case, it is the SEAL/NSCE's responsibility to detect whether this fault is caused by the 5GS network or not and exposed the fault report to the third-party. If it is, then the SEAL/NSCE may inform the management functions the location of the fault and ask for the maintenance of the managed functions to clear the fault. In addition, the two business relationships of network slice as a service and network slice as NOP internals may considered separately for the capabilities exposed in each scenarios. The coordination with SA5 is needed to fill the gap between the communication services (from the verticals' point of view) and the 5G network. Open issues:

• Whether and how additional APIs dedicated to network slice fault management capability are required?
• How to define the APIs to expose the fault report to verticals client/server
• How to coordinate with fault supervision management services provided by O&M systems defined in SA5 to fill the gap in fault management.

In clause 6.10 of TS 22.261, following requirements are defined: Based on operator policy, the 5G network shall expose a suitable API to allow an authorized third-party to define and reconfigure the properties of the communication services offered to the third-party. The 5G system shall support the means for disengagement (tear down) of communication services by an authorized third-party In addition, in clause 6.23.1 of TS 22.261, it defines that QoS monitoring can be used for assessing and assuring the dependability of the communication services. In SA5 TS 28.535, management services to assure the communication service as per agreement (for example a SLS) with a communication service (only network slice as a service scenario) consumer (e.g. enterprise) have been defined. For other scenarios, the communication services from the verticals aspects required by SA1 (e.g., vertical automation communication services, URLLC services) are not discussed in SA5 From the vertical industry perspective, they may be more concerned about how to operate the communication services provided by 5GS to meet the business requirements on application level. Take V2X service as an example, there is a specific service of cooperative driving for vehicle platooning information exchange, and the vertical has some requirements on this service, including end-to-end latency between two UEs. Therefore, the service enable layer needs to provide such capabilities for vertical industries, including lifecycle management and quality assurance of communication services from the verticals' perspective. For example, with the QoE/QoS data of communication services collected from vertical application layer, SA6 may need to provide some value-added communication services management and/or assurance services. It is not clear how to expose the communication service management service from application perspective with providing additional value on top of existing SA5 solution. Hence, it is required to study the following issues:

• What kinds of service APIs are required to be supported for application layer exposure of communication services life cycle management?
• What kinds of additional service APIs are required to be supported for application layer exposure of communication services SLA assurance?
• How to support above capabilities in the enable layer?
• How to coordinate with SA5 functionalities to fill the gap between the communication services (from the verticals' point of view) and the 5G network.

In clause 6.23 of TS 22.261, it is defined the requirements about QoS monitoring that 5G system shall be able to assessing and assuring the dependability of the communication services. In clause F.1 of TS 22.261, it is discussed how QoS monitoring information can be used for assurance purposes. In step "Customer rating of QoS", it mentions that the customer can compare the QoS achieved by the provider with the QoS requirements and its own experience of the QoS. In clause SA5 TS 28.552, it defined QoS measurements reports with different Filters from perspective of OAM, e.g. 5QI, QIC, S-NSSAI, PLMN. In some cases, the verticals and the service provider reach an agreement on the SLA, however with this SLA requirement, the VAL client may also suffer unsatisfied experience. Hence, it could be possible to provide Vertical application layer the capability of comparing the QoS achievement status together with the OAM QoS data versus real customer QoS data (e.g., MOS) collected from VAL client to check whether the existing QoS data is able to satisfy the VAL client's. It is not clear how to expose the QoS verification capabilities on top of existing SA5 solution. Hence, it is required to study the following issues:

• What kinds of additional service APIs are required to be supported for application layer enablement of QoS verification?
• What kinds of additional service APIs are required to obtain the real vertical QoS to support the QoS verification?
• How to support above capabilities in the enable layer?

As specified in clause 6.10 of TS 22.261, 5G network is requested to support a 3rd party to get the network status information of a private slice dedicated for the 3rd party. The 5G network collects various kinds of data, such as performance measurements in TS 28.552 and analytics data as specified in TS 28.104 and the analytics data from NWDAF and NSACF exposed by NEF. However, to get the information efficiently, the verticals are supposed to know, which entity to interact with to get the desired information, how to extract useful information from data which is collected using different statistical methods from different entities, which is challenging for some verticals. The network slice capability exposure enabler layer can aggregate and process the data from different source, making the network information exposure more orderly and easier to read. For example, for the slice related performance and analytics come from multiple sources, the enabler layer could help to organize and aggregate the information. For some applications utilizing multiple S-NSSAI, the enabler layer could help to organize and aggregate the information so that it is exposed and displayed based on the application level rather than slices level. Hence, it is required to study the following:

• Whether and how information about available (SA2 and SA5) slice performance and analytics should be exposed to a third party with added value?
• Whether and how available slice performance and analytics related information could be aggregated or processed to support an efficient information exposure?
• Whether and how additional service APIs are required to be supported at SEAL for the network slice measurements and analytics exposure?
• Whether and how CAPIF can be leveraged for additional service APIs?

Requirements for network slice from different verticals may vary from one to another, in terms of performance and capability requirements. For example, for the performance related requirements, the live video streaming cares more on bandwidth while V2X cares more on latency and jitters. For the capabilities related requirements, V2X may requests the positioning while future factory may request the self-control and management. To satisfy the requirements, vertical has to interact with several 5GS entities and understand the specific network parameters, such as the attributes in the service profile as defined in TS 28.541. Slice enabler layer could act as a mediator between the vertical customer and the 5GS to decompose and translate the requirements. Besides, the verticals are more focused on the KQI or QoE of the applications and services. For example, in a scenario of future factory, the robots are used to enable the intelligent delivering, the third-parties have a requirement on the application latency between the robots and the robots control system, the slice enabler may decompose this application latency requirement to 5GS network latency requirement (e.g., the network latency requirements specified in TS 28.541 as packet transmission latency (millisecond) through the RAN, CN, and TN part of 5G network or the UL/DL packet delay measurement between UE and PSA UPF for a QoS Flow defined in TS 23.501) and forward it to the 5GS systems. Another example is that to support the service of the imaging for professional applications as defined in TS 22.261, the imaging system latency of the application as defined in TS 22.263 is required which may not only depends on the 5GS network transmission latency but also will be influenced by the network throughput and network bandwidth. The NSCE are responsible for the translation from the vertical's KQI/QoE requirements to 5GS network requirements based on the knowledge of the industry profiles and 5G network (the definition of the KQI/OoE is service and application specific and is out the scope of this study). However, to cope with the various requirements, it is needed to specify the operations and procedure on how to translate them more efficiently, such as in the unified manner with unified format/model/template. In such way, the slice enabler layer is capable of translating requirements from the vertical, to service consumption or service API invocation and configurations to the respective 5GS domains. The service could be provided from control plane, management plane and SA6 slice enabler layer itself, or the combinations of services above. There are two main aspects in requirements translation: 1) one is how the vertical requirements could be collected, whether and how the template is needed? 2) The other is how to transfer the requirements into actions, whether and how API translation is needed? This key issue aims to discuss how to configure and translate the requirements to service consumption and configuration in a way that the slice capability exposure is 1) agnostic to the underlying telecom infrastructure, 2) hides the complexity of telecom infrastructure, 3) doesn't impact/restrict the level of exposure to the vertical and 4) that is resilient to dynamic changes that may happen due to application portability or telco-provided API status changes. Therefore, the open issues include:

• Whether and how the vertical requirements could be collected at the slice enabler to allow the translation to network service consumption and configuration,
• Whether and how API translation is needed to support the requirements translation.

A vertical application may use the slice enabler services (which can be seen as a trusted 3rd party to the MNO) to request management services as well as control plane services for a new slice on demand, based on an agreement between the vertical and the network slice provider. However, the creation of a new slice will require a form of trust between the vertical/end application and the 5GS (management and control plane) for authorizing/authenticating the application request and enabling the vertical app to consume management / control services related to the requested slice. The vertical application may not be trusted by the OAM or the 5GC, and is therefore not able to access management and control services. Also, there can be two way of accessing these services after authorization, via direct exposure or indirectly via the enabler server. So, the key issue will study:

• How to enable the authorization/authentication of the vertical application to consume telco-provided services (management and control plane), based on the vertical applications request.
• How to enable the authorization/authentication of the vertical application to consume telco-provided services (management and control plane) indirectly via the slice enabler layer, based on the vertical applications request.

As per TS 22.261, it is possible for trusted third-party to use a dedicated network slice for diverse use cases. Further, it provides following requirement to manage applications: "Based on operator policy, a 5G network shall provide suitable APIs to allow a trusted third-party to manage this trusted third-party owned application(s) in the operator's Service Hosting Environment." It is also possible for the third-party to offer its consumers different contract qualities level (e.g. gold, silver and bronze). In clause 5.7.1 of TR 22.835, following use case has been specified: "For gaming or online video applications, the end users, who have subscription with MNOs who may provide multiple network slices to different users or services, may still have different priority or membership e.g. VIP maintained by 3rd party Service Provider (SP). And depending on the priority or membership information from 3rd party SP perspective, based on the agreement between SP and MNO, the UE have different priority for the available network slices." In clause 4.2.11.2 of TS 23.502 specifies following: "When for all the Requested S-NSSAI(s) provided in step 2 the NSACF returned the maximum number of UEs per network slice has been reached and if one or more subscribed S-NSSAIs are marked as default in the subscription data and not subject to Network Slice Admission Control, the AMF can decide to include these Default Subscribed S-NSSAIs in the Allowed NSSAI. Otherwise, the AMF rejects the UE request for registration. In the Registration Reject message the AMF includes the rejected S-NSSAI(s) in the rejected NSSAI parameter, and for each rejected S-NSSAI the AMF includes a reject cause to indicate that the maximum number of UEs per network slice has been reached and optionally a back-off timer." Upon reaching maximum UEs slice quota, the 5GC may reject the registration request on the S-NSSAI from the gold quality level customer which may not be desirable by the trusted third party. This happens since 5GC is not aware of the relevant application information e.g. contract qualities level of the UE making the registration request. The third party application needs to provide high priority to the higher level of contract qualities and so it needs to manage such connections. It is also specified in TS 22.261 that the 5G system shall support a mechanism to optimize resources of network slices (e.g., due to operator deploying different frequency to offer different network slices) based on network slice usage patterns and policy (e.g., application preference) of a UE or group of UEs. In particular, this KI will address:

• Whether and how the AF can provide application policy information to the operator's Service Hosting Environment to enable automatic management of application resources?
• What application policy information needs to be specified by the trusted third-party AF that can be automatically evaluated by the operator's Service Hosting Environment?
• Whether and how the AF can manage use of the application resources in the operator's Service Hosting Environment on a per user characteristic?

As described in clause 6.1.2.2 of TS 22.261, the 5G system shall allow the operator to create, modify, and delete a network slice, verticals have strong desires for the slice/service self-management. Initially, they may translate the communication service parameters to slice parameters (serviceProfile provided to OAM as defined SA5) and order a slice with certain slice requirements parameters and their values. The verticals will put their best effort into slice requirements translation. However, they are not able to guarantee that all the potential factors will be considered to generate the optimal slice requirements parameters on the first try. After the service is executed on the required slice, the slice may not fully match the service real-time running conditions, for example, maybe only 60% of the slice resource is used to support the service, and rest of the slice resource is always idle, or the slice resource is insufficient due to under-provisioning. Or in some cases, there may be some unforeseen exceptions (e.g., unexpected traffic changes) and the current configured slice requirements parameters are not able to fulfil the requirements, for example, more resources are required to address the exceptions. In order to achieve the maximum return of investment and ensure the slice/service self-management, the verticals expect a more optimal service profile which contains the exact value of those slice requirements parameters to support to the executing services' demands, i.e., by monitoring the network performance statistics to align the slice requirements between verticals and network providers. Furthermore, the action of alignment is not triggered by a single event but considers the statistics of the network performance during a certain time period. From the management perspective, third-party is able to modify the slice requirements (serviceProfile defined in TS 28.541) by perform the operation of modifyMOIAttributes listed in Table 6.1-1 in TS 28.531 to support the slice requirements alignment. This key issue is to study how to enable better alignment between the vertical needs and the slice requirements parameters. Open issues:

• Whether and How the SEAL network slice capability management service supports better alignment between vertical needs and slice requirements parameters for initial service requirements and ongoing service conditions?
• How does the SEAL network slice capability management service determine and indicate that VAL server policy (e.g., requirements provided when adding or changing slices) requests or actions result in suggested changes to the NSCE service provider policy (e.g., allowed NS profile operations or parameter ranges) or to VAL policies?

The network slice deployed in the core network has a certain distance from the customer, so the delay will be affected to a certain extent and cannot meet the operation requirements of low latency equipment. Moreover, a variety of service data need to be processed in the core network, the scale of data traffic is large, the backhaul network needs to bear a large load and consume more bandwidth. For example, the differential protection service has strict requirements for latency in power industry. In order to meet the personalized services requirements of vertical industries, network slices are deployed by using the computing, storage and communication capabilities of the edge date network, so as to realize the localized processing of the service, reduce the service transmission latency and enhance the service performance. How to expose the network slice capability deployed in the edge data network to the vertical industry or the third parties is worthy of our study. Open issues:

• How could the NSCE server deployed inside the EDN interact with the NSCE server outside the EDN? Whether and how could the NSCE server interact with other NSCE serve?
• Whether and how could the NSCE server inside the EDN manage the network slice that has resource outside the EDN?
• Whether and how does SEAL need to be enhanced to support NSCE client to interact with NSCE server in the EDN and NSCE server outside the EDN?

There are many requirements on Network Slice Exposure specified in clause 6.10 of TS 22.261. Based on operator policy, a 5G network shall provide suitable APIs to allow a trusted third-party to create, modify, and delete network slices used for the third-party. Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to monitor the network slice used for the third-party. Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to define and update the set of services and capabilities supported in a network slice used for the third-party. Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to configure the information which associates a UE to a network slice used for the third-party. Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to configure the information which associates a service to a network slice used for the third-party. Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to assign a UE to a network slice used for the third-party, to move a UE from one network slice used for the third-party to another network slice used for the third-party, and to remove a UE from a network slice used for the third-party based on subscription, UE capabilities, and services provided by the network slice. In order to satisfy the above requirements, the third party should know the Network Slice existence in prior to the proper operation related to the Network Slice. The 3rd party service providers may know the existence of Network Slice through a way of delivery from the NSCE as an entity of NSP, which manages information of Network Slice for the 3rd party service providers. The concept of Network slice delivery is described in clause 4.1.8 of TS 28.530. Which information should be contained and delivered is another important point for delivery of the existing Network Slice. When 3rd party service providers activate the existing Network slice, 3rd party service providers should analyze the specific information of Network Slice such as set of service, capability, QoE, bandwidth and so on in order to figure out to meet their service requirements. What kind of information is necessary to 3rd party service providers may vary according to the services of the 3rd party service providers. With the regards, NSCE servers collect and manage information on Network Slice which 5GS may provide. It may be enough to indicate the standardized NEST (e.g, MBB, URLLC, massive IOT, etc.). Security aspects have to be considered. If there is a need for resource reservation per customer, then a dedicated slice is needed. Open issues:

• When does the Network Slice delivery occur?
• Which information of Network Slice does need to be contained when delivered? Or is it enough the delivery indicates the standardized NEST such MBB, URLLC, massive IOT?
• Whether and how management domain capabilities (e.g. MnS) corresponding to the network slice need to be delivered via the NSCE server?
• How the deployment of NSCE server (e.g. at NSP or NSC side) affects the level of slice information to be delivered?

The requirements specified in clause 6.10 of TS 22.261 says, Based on operator policy, a 5G network shall provide suitable APIs to allow a trusted third-party to create, modify, and delete network slices used for the third-party. This requirement interprets that the third-party can allocate the Network Slice for its service with suitable APIs provided by 5G Network. It can be implemented based on whether an appropriate Network Slice for the third-party service does exist or not. In case the appropriate Network Slice exists, the third-party request to use the Network Slice for the service, and the corresponding entities modifies the info of the Network Slice properly. In case the appropriate Network Slice does not exist, then the third-party request to create the new Network slice. This procedure should be handled with interaction between VAL server, NSCE and 5G network. Security aspects have to be considered. If there is a need for resource reservation per customer, then dedicated slice is needed. After the Network Slice allocation is requested, UE should be notified that the Network Slice for the third-party service is used. It is obvious that the UE utilizes the info of Network Slice in URSP or local configuration to transport the data of the third-party service. With the regard, without notification to the UE, the Network Slice will not be used for the service. When notified, SA6 needs to take it consideration whether the notification is transported over NSCE layer. If transported over NSCE layer, then it should be considered whether UE applies the new allocated Network Slice into URSP. Open Issues:

• What kind of information should be required for creating a new Network Slice for the third-party service (between NSP and NSC)? Any minimum set of information should be considered such as Service/Slice Type, Device Type or QoS Index?
• Whether and how is the notification transported over NSCE layer?
• Whether does UE apply the new allocated Network Slice into URSP when transported over NSCE layer?