Method, device and system for network slice management at UE initiated service enabled layer

Abstract

Methods, devices, and systems for UE initiated network slice management at a service enabled layer are described herein. In one aspect, a method may include receiving, by an NSCE client of a user equipment (UE), context information corresponding to application or user information of the UE from a VAL client of the UE; determining, by the NSCE client, one or more network slices required by the VAL client based on the received context information; generating, by the NSCE client, one or more network slice management requests corresponding to the determined one or more network slices; and sending, by the NSCE client, the generated one or more network slice management requests to one or more NSCE servers.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 324,327, filed on March 28, 2022, entitled “Methods, Devices, and Systems for UE-Initiated Network Slice Management at Service Enablement Layer,” and is incorporated herein by reference. Background Art

[0003] Figure 1 The Service Enabler Architecture Layer (SEAL) for vertical industries in the 3GPP SA6 working group is shown. SEAL is a service enabler architecture layer common to all vertical applications deployed on the 3GPP system. Therefore, SEAL provides a horizontal layer where the vertical application layer can get public services. Some of the public services are: location management; group management; configuration management; identity management; key management; and network resource management.

[0004] The Vertical Application Layer (VAL) client accesses services provided by the SEAL client on the UE, which then transmits traffic to the SEAL server using the SEAL-UU interface. The SEAL server routes the traffic to the destination VAL server and can communicate with Figure 1 The SEAL layer can communicate with other SEAL servers not shown in the figure. In addition, the SEAL server can access network exposure information via the network interface with the 3GPP network. The VAL client and the VAL server access the SEAL service through the API exposure of the public functions provided by the SEAL layer to all vertical applications. For example, SEAL supports network slicing capability management.

[0005] The SEAL server can be deployed as part of a PLMN operator domain or a VAL service provider domain. When deployed in a VAL service provider domain, the SEAL server can be connected to multiple PLMN operator domains. The SEAL server is connected to a 3GPP network system, and one SEAL server can support multiple VAL servers. The functional model of the SEAL layer can be described as an on-network functional model in which communication involves a 3GPP network, or an off-network functional model in which communication occurs between two UEs. Summary of the invention

[0006] The disclosure provided herein describes a method in which a service hosted on a UE initiates network slice management operations, so that network slices are allocated, modified, and de-allocated based on the dynamically changing requirements and context of the UE (such as context from applications and their users). The disclosed method enables the allocation, modification, and de-allocation of network slices for UEs with improved intelligence, efficiency, privacy, and performance by introducing network slice management functionality to the UE itself. This functionality enables local network slice management decisions rather than relying entirely on remote network slice management decisions in the network. This proposed functionality also enables network slices to be defined in a more application-specific manner, with higher granularity and without incurring excessive overhead to the system. Using techniques that involve the UE more to manage network slices can allow network slices to be customized and adapted to the needs of the UE and its applications and users with greater precision, dynamism, and less waste of resources. Without this functionality, over-provisioning or under-provisioning of network slice resources is more likely to occur, especially when UE requirements change dynamically (e.g., users start and stop different applications on the UE). By enabling the UE to play a more active role in the management of network slices, it can be ensured that sufficient network slices are allocated to the UE. This also helps save and optimize the overall network slice resources of the entire system. This functionality also allows sensitive user context information to remain local to the UE, without requiring sensitive information to be shared with network slice management services in the network.

[0007] This summary is provided to introduce some concepts in a simplified form, which will be further explained in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to features that solve any or all deficiencies mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 Describe the vertical industry-oriented service enabler architecture layer (SEAL) in the 3GPP SA6 working group;

[0009] Figure 2 Describe the Network Slice Capability Exposure (NSCE) architecture defined by Network Slice Capability Exposure for Application Layer Enablement (NSCALE) Release 18 (3GPP TR 23.700-99, Study on Network Slice Capability Exposure for Application Layer Enablement (NSCALE); V1.0.0);

[0010] Figure 3 An example of a process depicting a network slice management operation initiated by a user equipment (UE);

[0011] Figure 4 Depicting a graphical user interface (GUI) of a UE that can be used to manage network slice resources for the UE;

[0012] Figure 5A An example communication system is depicted of which the methods and apparatus described and claimed herein may be an aspect.

[0013] Figure 5B A block diagram depicts an example apparatus or device configured for wireless communications.

[0014] Figure 5C System diagram depicting an example radio access network (RAN) and core network.

[0015] Figure 5D System diagram depicting another example RAN and core network.

[0016] Figure 5E System diagram depicting another example RAN and core network.

[0017] Fig. 5F depicts a block diagram of an example computing system; and

[0018] Figure 5G A block diagram depicts another example communication system. DETAILED DESCRIPTION

[0019] In Release 18, 3GPP recognized the need to expose enhancements to SEAL's network slicing capabilities that have not yet been implemented and that enable trusted third parties to access the network slicing APIs defined and opened by the 5G CN. Various aspects of this study (3GPP SP-211509, Study on Network Slice Capability Exposure for Application Layer Enablement (NSCALE)) include allowing network slice lifecycle management operations to be further exposed to trusted third-party application layers to support network slice management and control. This permission supports network slicing related operations, such as mapping or migrating one or more vertical applications to one or more network slices. Network slice monitoring and triggering of dynamic network slice lifecycle management operations due to changes in application requirements (e.g., QoS) or changes in network slice status are also within the scope of the study.

[0020] To date, Release 18 studies have defined the following embodied in TR 23.700-99 (3GPP TR 23.700-99, Study on Network Slice Capability Exposure for Application Layer Enablement (NSCALE); V1.0.0) Figure 2 The NSCE architecture shown in . The network slicing capability exposure client communicates with the network slicing capability exposure server through the NSCE-UU reference point. The network slicing capability exposure client provides support for the network slicing capability exposure function to the VAL client through the NSCE-C reference point. The VAL server communicates with the network slicing capability exposure server through the NSCE-S reference point. The network slicing capability exposure server can communicate with the 5G core network function via the NEF (N33) reference point (for interaction with PCF, NSACF, etc.) or directly via N5 to interact with the PCF if allowed. The network slicing capability exposure server can interact with the OAM system through the NSCE-OAM reference point (for example, for network slicing lifecycle management operations, fault supervision, etc.).

[0021] Note that although not in Figure 2 , but the NSCE client can be implemented as an integrated Figure 1 Similarly, the NSCE server can be implemented as a function integrated within the SEAL server.

[0022] To date, Release 18 NSCALE research and architecture has primarily focused on defining processes that enable VAL servers in the network to play a more active role in the management of network slices. These network slices are used to support communications between VAL servers (e.g., application servers or edge application servers) and VAL clients (e.g., application clients) on one or more UEs. However, the research has not yet defined processes that enable the UE to play a more proactive and involved role in the management of network slices. This is a shortcoming of current NSCALE research and architecture because the UE has a unique position in the system that contributes to more optimized management of network slices. The VAL client on the UE is privately aware of application-centric context and information that other functions in the network may not be privately aware of. For example, constraints requiring user data to remain local to the UE to ensure user privacy, and / or performance constraints that limit the sharing of latency-critical information with functions and services in the network.

[0023] Due to these types of constraints and requirements, the UE is in a good position in the system to assist in the management of network slices. The UE can collect and analyze information local to the UE, such as the current state or usage patterns of applications on the UE, and how users interact with applications and services hosted on the UE. For example, the location or route where the application on the UE is expected to be available, and the required network KPIs (e.g., bandwidth, latency, reliability, etc.) that the application needs to meet the user's expectations for Quality of Experience (QoE). The UE's own functions are in the best position in the system to collect, analyze, and process these types of information in a more secure and timely manner, rather than the UE sharing this information with other functions and services in the network to process and make less efficient remote decisions about network slice management.

[0024] Figure 3 Proposed enhancements to the NSCALE procedure for Release 18 are shown for enabling UE initiated network slice management operations. The NSCE client and NSCE server may perform one or more of these steps in the order shown, or the steps may be performed in an order different from that shown.

[0025] In step 1, the VAL client on the UE may share application and / or user context information applicable to the management of network slices with the NSCE client on the UE. The types of application and / or user context information may include, but are not limited to, the information defined in Table 1. The sharing of this information may be initiated by the VAL client based on the detection of various types of trigger events such as, but not limited to, those defined in Table 2. When a trigger event is detected, the VAL client may initiate the sharing and updating of this information so that the NSCE client may determine whether network slice management operations are required based on the information. For example, when the VAL client determines that a change in the expected location or route of the UE has occurred, the NSCE client may be notified. The NSCE client may then perform any necessary network slice management operations. This may include coordinating with functions in the network to allocate new network slices that the VAL client may use to communicate with the new VAL server. Similarly, the NSCE client may coordinate with functions in the network to deallocate network slices that the VAL client no longer requires to communicate with the old VAL server.

[0026] Table 1: Application / user context applicable to management of network slices

[0027]

[0028]

[0029]

[0030]

[0031] Table 2: Events that trigger sharing of application / user context

[0032]

[0033]

[0034]

[0035]

[0036] In step 2, in addition to any context information received by the NSCE client from the VAL client, the NSCE client may also collect additional context information applicable to the management of the network slice, such as but not limited to the context shown in Table 3. The collection of this information may be initiated by the NSCE client. Alternatively, other entities in the system may share the context information with the NSCE client. These other entities may include, but are not limited to, other service enablers or functions hosted on the UE itself or that may reside in the network. For example, functions in the UE's operating system, functions in the UE's protocol stack, functions in the UE's modem chipset, and / or functions or services in the network (e.g., NSCE servers, OAM services, etc.).

[0037] Table 3: Additional network slice context collected by NSCE client

[0038]

[0039]

[0040] In step 3, the NSCE client may process the context it receives and / or collects to determine the network slices required by one or more VAL clients on the UE and / or the network slice management operations that may be required for these network slices. This processing may include, but is not limited to, one or more types of processing defined in Table 4. Based on the processing of the context, the NSCE client may trigger one or more events, such as, but not limited to, the events defined in Table 5.

[0041] Table 4: Operations on contexts applicable to management of network slices

[0042]

[0043] Table 5: Events triggered by context processing

[0044]

[0045]

[0046]

[0047] In step 4, based on the trigger event detected in step 3, the NSCE client may initiate one or more network slice management requests to one or more NSCE servers and / or OAM services in the network to perform network slice management operations. For example, the NSCE client may initiate a request to allocate one or more new network slices for use by the UE and its VAL client, modify one or more network slices already allocated to the UE and its VAL client, and / or de-allocate one or more network slices no longer required by the UE and its VAL client. In addition, the NSCE client may subscribe to receive notifications from the NSCE server about one or more types of network slice management events of interest to the NSCE client, the UE, and / or the VAL client on the UE. The request may include, but is not limited to, one or more of the information elements defined in Table 6.

[0048] Table 6: Network Slice Management Request Information Elements

[0049]

[0050]

[0051] In step 5, when receiving a network slice management request from the NSCE client, the NSCE server may first authenticate the NSCE client. Once the NSCE client has been authenticated, and before making any network slice management request on behalf of the NSCE client, the NSCE server may check whether the VAL client specified in the request is authorized to access the VAL server specified in the request. To perform this check, the NSCE server may interact with other entities in the system, such as but not limited to an authorization service or a VAL server. If it is found that one or more of the specified VAL clients do not have authorization to access the VAL server, the NSCE server may attempt to obtain authorization for the VAL client by sending an authorization request to other entities in the system (such as but not limited to an authorization service or a VAL server). The authorization request may include one or more information elements from the request received by the NSCE server from the NSCE client, such as the information elements defined in Table 6. If the NSCE server determines that the VAL client is authorized to access the specified VAL server, the NSCE server may continue to process the network slice management request, otherwise the NSCE server may return an error condition to the NSCE client, indicating that the VAL client lacks sufficient authority to access the specified VAL server, and therefore no network slice management operation is performed.

[0052] In step 6, the NSCE server may send one or more requests to functions in the core network (e.g., NEF, PCF, NWDAF, etc.) and receive one or more responses or notifications returned from these core network functions. These requests may obtain additional context information about the UE that initiated the network slice management request, other UEs specified in the network slice management request, and / or the VAL server specified in the network slice management request. The types of context information obtained from the core network functions may include, but are not limited to, the contexts defined in Table 7.

[0053] Table 7: Context information obtained from core network functions

[0054]

[0055]

[0056] In step 7, the NSCE server may send one or more network slice query requests to one or more network slice management functions in the system and receive one or more query responses in response. These functions may reside in the core network (e.g., NSACF) and / or elsewhere in the system (e.g., OAM services). The query request may include one or more information elements from a request received by the NSCE server from the NSCE client, such as the information elements defined in Table 6, or context information obtained by the NSCE server from a core network function, as defined in Table 7. The NSCE server may use the query request to determine the types of network slices supported by the core network (e.g., SST values), and the locations in the network that support these types of network slices (e.g., within a specific region, domain, and / or within a specific edge data network in the network). The NSCE server may also use the query request to determine whether there are any existing network slice instances (NSIs) that have been allocated that meet the minimum required service or QoE KPIs for the VAL client on the specified UE and that can provide service to the UE during the UE's required communication schedule and / or for the UE's expected location and / or route. The NSCE server may also receive information from the VAL server about network slice types and / or instances that the VAL server supports and / or is currently using.

[0057] In step 8, after determining the types of network slices supported by the core network and / or the available instances of network slices allocated within the network (which meet the requirements of the specified VAL client and / or are being used by the VAL server), the NSCE server may check whether these UEs and their VAL clients are authorized to access and use these network slice types and instances. To perform this check, the NSCE server may use a list of allowed network slices provided in the request from the NSCE client. Alternatively, the NSCE server may initiate one or more requests to one or more functions in the system. For example, the NSCE server may initiate a request to a function (e.g., NEF, UDR, UDM) or an OAM service in the core network to check whether the UE's subscription permits access to certain network slice types or existing network slice instances that have been allocated in the network. If it is found that the UE and / or VAL client does not have authorization to access a network slice type or instance, the NSCE server may initiate one or more requests to other network slice management functions (e.g., OAM services) in the system to try to obtain authorization authority (on their behalf). If ultimately the UE and / or its VAL client cannot be granted access to the network slice type or instance they requested, the NSCE server may return an error condition to the NSCE client, indicating that the VAL client lacks sufficient permissions to access the network slice type and instance and therefore cannot perform the requested network slice management operation.

[0058] In step 9, if after querying the current network slice instance, the NSCE server determines that there is no currently available and / or accessible slice instance that meets the minimum requirements of the UE and its VAL client specified in the request, the NSCE server may initiate one or more requests to trigger the allocation and / or modification of one or more network slice instances for use by the UE, its VAL client and / or the VAL server of interest to the VAL client. In order to trigger the allocation and / or modification of one or more network slice instances, the NSCE server may issue one or more requests to other functions in the system (such as core network functions (e.g., NEF, NSACF, etc.), OAM functions responsible for managing network slices, and / or VAL servers). Within the request, the NSCE server may include information and context, such as but not limited to the elements set forth in Table 1, Table 3, Table 6, and / or Table 7. When attempting to allocate or modify a network slice instance, the NSCE server may first analyze or obtain information about existing network slice instances that have been allocated and used within the network. Through this analysis, the NSCE server can identify the number, type, and identity of UEs, VAL clients, and VAL servers that have been allocated to and / or using these allocated network slice instances. The NSCE may also identify the location, routes, and schedules of UEs, VAL clients, and / or VAL servers that use these allocated network slice instances.

[0059] Based on this information, the NSCE server can determine whether there are sufficient available resources within one or more allocated network slices requested in the received request. The NSCE server can also determine whether existing network slices are already in use by the UE, VAL client and / or VAL server, and if so, give priority to the use of these existing network slice instances in an attempt to reduce the number of different network slice instances required for use by a given UE, VAL client or VAL server, which can optimize the equipment and network resources in the system. In addition to allocating and / or modifying network slice instances, the NSCE server can also issue one or more requests to deallocate network slice instances, if necessary. For example, if the NSCE server detects that there is no longer any UE requiring a particular network slice instance, it can issue a request to deallocate the network slice instance. The NSCE server can also subscribe to receive notifications about network slice instance events of interest from the OAM function, such as one or more notification events defined in the request from the NSCE client defined in Table 6.

[0060] In step 10, if the NSCE server can determine the network slice instances that the UE can access and use, the NSCE can configure the UE routing selection policy (URSP) on the UE. The URSP can be configured with rules that define the network slices that the VAL client on the UE is authorized to use when establishing a PDU session for accessing certain VAL servers. Configuring the URSP policy on the UE may involve the NSCE server making a request to a function in the core network (e.g., NEF, PCF, etc.) to configure the URSP on the UE.

[0061] Alternatively or in addition, the NSCE server may send an NSCE client configuration rule (NCCR) for slice access to the NSCE client on the UE using an NSCE message, which may include a reference to the URSP configured on the UE and / or information about the NSSAI and / or DNN of the network slice instance allocated or modified by the NSCE server for use by the VAL client on the UE. The NSCE client may use these NCCRs to reference the URSP configured on the UE. Alternatively, the NSCE client may use these NCCRs and pre-configured policies to create URSP rules or enhanced URSP rules. The NCCR may also provide information about triggers for creating or using alternative URSP rules. For example, the NSCE client may derive or use alternative URSP rules with the same traffic descriptor and different routing descriptors associated with various trigger conditions present at the UE. The routing descriptors derived by the NSCE client allow the UE to utilize new or newly configured network slices based on the trigger conditions. The trigger conditions contained in the NCCR may be the same as those described in Table 5, or may be based on time, location, etc. The usage may be different compared to step 3, because in step 3 they are used to trigger the UE network slice management request, while when provided through the NCCR, they are used to change the URSP rules derived from the NCCR. These two mechanisms can be used separately or in conjunction.

[0062] The URSP may also include identifiers of VAL clients on the UE and / or identifiers of VAL servers that these VAL clients are authorized to access using specified network slice instances. The URSP may also include rules specifying allowed timetables for VAL clients to access network slice instances. These timetables may be configured so that they are consistent with the expected usage timetables of one or more VAL clients on the UE. The URSP may also include rules specifying allowed locations or routes from which VAL clients are permitted to access and use network slice instances. These locations and routes may be configured so that they are consistent with the expected locations and routes specified by one or more VAL clients on the UE. When the UE is not at the specified location or is not traveling along the specified route, based on the URSP, the VAL client will not be permitted to access and use the network slice instance to communicate with the VAL server. In the case where the NSCE server requests a new network slice authorization for the UE, the NSCE server may need to request the 5G network to perform a UE configuration update process in order to provide the UE with new network slice authorization information, for example, in the allowed NSSAI. The UE configuration update process may need to be performed before the URSP is updated to the UE to ensure that the appropriate network slice authorization is available in the UE before the URSP rules are used.

[0063] In step 11, the NSCE client may include an indication to the NSCE server in the request it sends to the NSCE server (specified in step 4) to attempt to obtain authorization for the NSCE client to issue network slice management requests directly to the network slice management function in the system. If the indication is present, the NSCE server may initiate a request to other entities in the system (e.g., an authorization server, an OAM service) to attempt to obtain authorization for the NSCE client to issue network slice management requests directly to the network slice management function in the system (e.g., a core network function (e.g., NEF, NSACF, etc.) or an OAM service). Within the request, the NSCE server may provide the information elements it received from the NSCE client, such as the information elements defined in Table 6 and / or the UE context information it obtained, such as the type of information defined in Table 7. In response, the NSCE server may receive an authorization decision indicating whether the NSCE is permitted to issue network slice management requests directly to a network slice management function in the system, one or more types of network slice management operations that are permitted to be initiated by the NSCE client, an authorization token that the NSCE client may use to authenticate its own to the network slice management function, and / or an authorization validity period indicating a time window or expiration time after which the NSCE client may no longer issue requests directly to the network slice management function.

[0064] In step 12, after the NSCE server completes processing of the network slice management request from the UE, the NSCE server may return a response to the NSCE client. In addition, if / when the NSCE server detects that a network slice event of interest to the NSCE client has occurred, the NSCE server may also send a notification to the NSCE client. These notifications may depend on the network slice notification criteria provided by the NSCE client to the NSCE server, such as but not limited to the criteria defined in Table 6. The response and / or notification may include one or more information elements, such as but not limited to the information elements defined in Table 8.

[0065] Table 8: Information returned by the NSCE server in the network slice management response

[0066]

[0067]

[0068] In step 13, if authorized, the NSCE client may directly issue a network slice management request to a network slice management function (e.g., OAM service) in the system, rather than indirectly issuing a network slice management request to the network slice management function via the NSCE server. When issuing a request, the NSCE client may include information elements, such as but not limited to the information elements defined in Table 6.

[0069] In step 14, the NSCE client may receive a response from the network slice management function. The response may include one or more information elements as defined in Table 8.

[0070] In step 15, after receiving a response and / or notification from the NSCE server or another network slice management function in the system, the NSCE client may process the response and notification. The processing may involve the NSCE client determining whether to initiate one or more network slice management operations to the NSCE server, such as the allocation, modification, or deallocation of a network slice for use by a VAL client on the UE. The NSCE client may also send one or more notifications to the VAL client on the UE. These notifications may notify the VAL client that a PDU session can now be established because network slice resources are available to the UE, or notify changes to the network slice and / or PDU session corresponding to the network slice that affect the VAL client. Notifications can also be used to change the behavior of the VAL client. For example, notifications can be used to modify (e.g., suppress) its communication mode based on the availability of resources within the network slice, or switch to using different PDU sessions and network slices.

[0071] In step 16, PDU sessions may be established between the VAL client and the VAL server. These PDU sessions are established based on the URSP that has been configured on the UE as part of the UE initiated network slice management process. Thus, the network slice instance associated with each PDU session meets the application requirements of the VAL client using these PDU sessions. As the requirements of the VAL client change over time and / or the UE moves and requires a new network slice, the NSCE client continues to keep the URSP and network slice instances updated and assigned to the UE. This ensures that any changes in the network requirements of the UE and VAL client are managed, while also ensuring that any unused network resources are freed up for use by other UEs.

[0072] Graphical User Interface

[0073] Context information may be collected from applications on the UE, which may be useful for managing the network slice resources required by the UE. Certain types of context may be input into one or more applications from the user themselves during use of the application. Figure 4 Some examples of the types of user-provided content information that can be input by the user are shown. For example, when opening and / or closing an application (e.g., When a user enters information into an application (such as destination and scheduled departure time, etc.). The UE can use these types of information to provide more efficient, proactive and dynamic management of network slice resources.

[0074] method

[0075] The method described herein may include an NSCE client, the NSCE client being hosted on a UE, receiving an application context from one or more VAL clients hosted on the same UE, the NSCE client being able to use the application context to make network slice management decisions, and wherein the application context may include, but is not limited to, one or more of the following information elements: the type and / or instance of a VAL server with which the VAL client requires interaction, identifiers of one or more VAL clients hosted on other UEs with which the VAL client on the local UE is currently communicating or planning to communicate via one or more specified VAL servers, a schedule of when the VAL client is expected to be in an active state and / or inactive state, a location or route of the UE when the VAL client is scheduled to be in an active state, a mobility and / or speed indication, a communication criticality indication, a communication direction and / or mode, a required and / or observed service KPI of the VAL client (e.g., end-to-end latency, jitter, bandwidth, reliability), observed user QoE KPIs, such as user satisfaction / dissatisfaction when using an application or service, and wherein the NSCE client can receive application context if / when events such as, but not limited to, one or more of the following occur: VAL client switches to a different VAL server; VAL client switches to a different VAL client; VAL client schedule changes; UE / VAL client location / route changes; UE / VAL client mobility changes; VAL client criticality changes; VAL client service continuity changes; VAL client edge service changes; VAL client communication direction changes; VAL client communication mode changes; VAL client end-to-end latency, jitter, bandwidth and / or reliability changes; and VAL client location accuracy changes.

[0076] The NSCE client may also collect additional context to supplement the context received from the VAL client, where the collected additional context may include, but is not limited to, one or more of the following elements: configuration parameters and resources allocated to each network slice used by the UE; network slice status; and network slice utilization.

[0077] The NSCE client may also process the received and / or collected context, wherein the processing may include but is not limited to one or more of the following operations: storing and maintaining a history of the received and / or collected context; aggregating the received and / or collected context to identify commonalities between VAL clients and / or users of the VAL clients to determine the overall network slicing requirements of the UE; analyzing the received, collected and / or historical context to detect patterns in the network slicing requirements of the UE; detecting insufficient network slices, unused network slices, and underutilized / overutilized network slices for the UE and VAL clients; and determining a set of network slices required by the VAL client on the UE.

[0078] The NSCE client may also send one or more requests to one or more NSCE servers in the network to perform network slice management operations, wherein the request contains one or more of the following information elements: identifiers of the UE, VAL client, VAL server, and NSCE client; application and / or user context received from one or more VAL clients; context collected by the NSCE client; the NSCE client is requesting the NSCE server to perform one or more network slice operations on behalf of the NSCE client, such as but not limited to: allocating, modifying, or deallocating network slices; network slice requirements (e.g., slice type, slice usage schedule, slice usage location) determined for one or more network slices required by the UE; the NSCE client is requesting the NSCE server to obtain authorization for the NSCE client, so that the NSCE client itself is allowed to directly utilize the OAM services in the network to perform one or more network slice operations; and network slice notification standards and callback addresses.

[0079] The NSCE client may also receive responses or notifications from one or more NSCE servers in the network regarding one or more of the following types of information: network slice management operation results; network slice identifier; network slice descriptor; network slice notification event; URSP identifier; URSP; authorization decision; authorization token; authorization validity period; and authorized operations.

[0080] The method described herein may also include an NSCE server, the NSCE server being hosted on a server in the network, receiving a request from one or more NSCE clients, the request including an information element, such as but not limited to one or more of the above-mentioned information elements exchanged between the NSCE client and the NSCE server, and performing one or more network slice capability-centric operations on behalf of the UE based on the information in the request, wherein the one or more operations may include but are not limited to: authenticating the NSCE client;Obtain authorization for a VAL client on a UE to access a VAL server via a network slice instance, wherein obtaining authorization includes one or more of the following operations: sending an authorization request to a service in the network (e.g., AS, EAS, authorization service) to obtain authorization approval for the VAL client, querying an entity in the system (e.g., OAM service) to determine whether there are network slice instances that already meet the minimum required service or QoE KPI of the VAL client on the specified UE, and whether these network slices are available to the UE at the required predetermined time, location and / or route, and if there are not enough network slice instances, triggering allocation of a new network slice instance or modification of an existing network slice instance, wherein the network slice instance contains enough network resources to meet the minimum required service or QoE of the VAL client on the specified UE KPI, and at the required predetermined time, location and / or route available to the UE, obtain authorization for the VAL client on the UE to access the network slice instance, wherein obtaining authorization includes one or more of the following operations: sending an authorization request to a service (e.g., an OAM service) in the network to obtain an authorization approval indication (e.g., an authorization token) for the NSCE client to perform one or more types of network slice management operations, configuring a UE routing selection policy (URSP) on the UE using rules defining the network slices that the VAL client on the UE is authorized to use to access the VAL server, wherein the configuration may involve: the NSCE server issuing a request to a function in the network to configure the URSP on the UE, the NSCE server sending the URSP directly to the NSCE client for configuration on the UE, wherein each URSP may include one or more of the following information: the NSCE server triggers allocation or modification of the network slices for use by the VAL client on the UE ; The method comprises: providing an NSSAI and / or DNN of a network slice instance, an identifier of a VAL client on a UE that is authorized to access the network slice instance, an identifier of a VAL server that the VAL client on the UE is authorized to access via the network slice instance, a predetermined time at which the VAL client on the UE is permitted to access the network slice instance, the predetermined time being constituted by a time consistent with a schedule requirement of the VAL client, a location from which the VAL client on the UE is permitted to access the network slice instance, the location being constituted by a location consistent with an expected location / route of the VAL client, obtaining authorization for the NSCE client to directly utilize an OAM service in the network for one or more network slice operations, and sending an authorization request to a service in the network (e.g., an OAM service) to obtain an authorization approval indication (e.g., an authorization token) for the NSCE client to directly utilize a network slice management service (e.g., an OAM service) in the network for one or more types of network slice management operations. ;

[0081] The NSCE server may also send responses or notification requests to one or more NSCE clients on one or more UEs in the network regarding one or more of the following types of information: network slice management operation results; network slice identifier; network slice descriptor; network slice notification event; URSP identifier; URSP; authorization decision; authorization token; authorization validity period; and authorized operations.

[0082] Note that in the context of the present disclosure, a VAL client may be an application client or service hosted on a UE that provides functionality for a specific vertical, application, or deployment use case (e.g., automotive, healthcare, agriculture, public transportation, energy, etc.). Likewise, a VAL server may be an application service hosted in the cloud or at the edge of the network and accessed by an application client on the UE.

[0083] Example Communication System

[0084] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G". 3GPP NR standards development is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new non-backwards compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0085] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and communications between vehicles and other entities. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and others are contemplated in this article.

[0086] Figure 5A An example communication system 100 is illustrated of which the methods and apparatus described and claimed herein may be an aspect. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (generally or collectively referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it will be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 5A-5E, but it should be understood that for the various use cases envisioned for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a truck, a train or an airplane, and the like.

[0087] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0090] The base station 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

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

[0092] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f and / or 102g may communicate with each other via an air interface 115d / 116d / 117d (not shown), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

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

[0094] In some cases, the base station 114a and the WTRU 102a, 102b, 102c, or the RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b and the WTRU 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0095] In some cases, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, RPs 119a, 119b and / or RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0096] Figure 5AThe base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, and the like. In some cases, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. Figure 5A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

[0097] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0098] Although not in Figure 5A 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

[0099] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may use the same RAT or a different RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b.

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

[0101] Figure 5B 1 is a block diagram of an example apparatus or device, such as WTRU 102, configured for wireless communication in accordance with aspects illustrated herein. Figure 5B As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the above elements while still being consistent with the example. In addition, in some cases, the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, such as but not limited to a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and a proxy node, etc. may be included in Figure 5BSome or all of the elements depicted in and described herein.

[0102] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 5B The processor 118 and the transceiver 120 are depicted as separate components, although it is appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0103] The send / receive element 122 may be configured to send or receive signals to and from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in some cases, the send / receive element 122 may be an antenna configured to send and / or receive RF signals. In some cases, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, IR, UV, or visible light signals. In some cases, the send / receive element 122 may be configured to send and receive both RF signals and optical signals. It is to be appreciated that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0104] In addition, although the transmit / receive element 122 is Figure 5B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some cases, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0105] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122, and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

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

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

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

[0109] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0110] The WTRU 102 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as one of the peripheral devices 138.

[0111] Figure 5C 1 is a system diagram of the RAN 103 and the core network 106. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. Figure 5C As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while still being consistent with aspects of the present disclosure.

[0112] like Figure 5CAs shown in , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node-B 140a, 140b, 140c to which it is connected. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0113] Figure 5C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is depicted as part of the core network 106, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0114] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

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

[0116] As described above, core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

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

[0118] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while still being consistent with aspects of the present disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to send and receive wireless signals to and from the WTRU 102a.

[0119] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Figure 5D As shown in FIG. , eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0120] Figure 5D The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements is depicted as part of the core network 107, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0121] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

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

[0123] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0124] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include or may be in communication with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0125] Figure 5E 1 is a system diagram of the RAN 105 and the core network 109. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As further described below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0126] like Figure 5EAs shown in , the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while still being consistent with aspects of the present disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to send wireless signals to and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0127] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0128] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols that facilitate WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols that facilitate mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0129] like Figure 5EAs shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols that facilitate data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the above elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0130] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0131] Although not in Figure 5E 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between the home core network and the visited core network.

[0132] Described in this article and Figure 5A , Figure 5C , Figure 5D and Figure 5EThe core network entities illustrated in the diagram are identified using names given to these entities in certain existing 3GPP specifications, but it should be understood that in the future, these entities and functions may be identified by other names, and in future specifications published by 3GPP, including future 3GPP NR specifications, some entities or functions may be merged. Figure 5A , Figure 5B , Figure 5C , Figure 5D and Figure 5E The specific network entities and functions described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0133] Fig. 5F is a block diagram of an exemplary computing system 90 in which Figure 5A , Figure 5C , Figure 5D and Figure 5E 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed in a processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

[0135] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such a memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes is set, it cannot access memory in the virtual address space of other processes.

[0136] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

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

[0138] In addition, the computing system 90 may include a communication network that can be used to connect the computing system 90 to an external communication network, such as Figure 5A , Figure 5B , Figure 5C , Figure 5D and Figure 5EThe RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 of the present invention may be used to enable the computing system 90 to communicate with other nodes or functional entities of these networks through communication circuits, such as a network adapter 97. Alone or in combination with the processor 91, the communication circuits may be used to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0139] Figure 5G The diagram illustrates an example communication system 111 of which the methods and apparatus described and claimed herein are an aspect. As shown, the example communication system 111 may include wireless transmit / receive (WTRU) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it is to be appreciated that the present disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary represented as a dashed line in the figure). WTRUs A, B, C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0140] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, magnetic disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

[0141] definition

[0142] Definitions of abbreviations found within the text of this disclosure are provided below.

[0143]

[0144]

Claims

1. A method comprising: The network slice capability opening NSCE client of the user equipment UE receives context information including location requirements, time window requirements or network access type preferences from the vertical application layer VAL client of the UE; The NSCE client determines, based on the received context information, one or more network slices required by the VAL client; Generating, by the NSCE client, one or more network slice management requests corresponding to the determined one or more network slices, wherein the one or more network slice management requests include location requirements, time window requirements, or access type preferences; The NSCE client sends the generated one or more network slice management requests to one or more NSCE servers; as well as One or more responses are received by the NSCE client from the one or more NSCE servers, the one or more responses indicating whether one or more network slices are configured to meet the requirements specified in the one or more requests.

2. The method according to claim 1, wherein the location requirement also includes the location or route of the network slice that the UE requires to be used.

3. A method according to claim 1, wherein the time window requirement also includes a schedule for when the UE requires the use of the network slice.

4. The method according to claim 1, wherein the network access type preference also includes the type of applicable access network for network slicing.

5. The method according to claim 4, wherein the type of the access network comprises 3GPP, non-3GPP or multiple access network.

6. The method according to claim 1, further comprising: The NSCE client receives, from the one or more NSCE servers, a set of NSCE client configuration rules NCCR corresponding to slice access management for the VAL client in response to the one or more network slice management requests sent; as well as The NSCE client generates a UE routing selection policy URSP for slice access authorization for the VAL client based on the set of NCCRs.

7. The method according to claim 1, further comprising: The NSCE client sends an indication to the one or more NSCE servers to obtain authorization for the NSCE client to directly issue a network slice management request to a network slice management function; as well as An authorization grant message indicating that the authorization right is granted is received by the NSCE client from the one or more NSCE servers.

8. A method comprising: A network slice capability exposure NSCE client of a user equipment UE sends a subscription request to one or more NSCE servers, where the subscription request includes network slice event information corresponding to a first network slice used by the UE for wireless communication; Receiving, by the NSCE client, a notification indicating network slice adaptation for the UE; as well as Based on the notification, the NSCE client switches the UE from using the first network slice to using the second network slice.

9. The method according to claim 8, wherein the network slice event information includes an identifier of the first network slice.

10. A method according to claim 8, wherein the network slice event information includes one or more network slice events of interest.

11. The method of claim 10, wherein the one or more network slice events of interest further include network slice adaptation or network slice error.

12. The method of claim 8, wherein the notification further comprises an identifier of the second network slice.

13. The method according to claim 8, further comprising: The NSCE client determines the second network slice to which the UE is to switch based on the notification.

14. The method according to claim 8, further comprising: Receiving, by the NSCE client, a message indicating authorization for sending a network slice management request directly to a network slice management function; And wherein the notification is received from the network slice management function.

15. A method comprising: One or more network slice capability exposure NSCE servers receive one or more network slice management requests from an NSCE client of a user equipment UE, wherein the one or more network slice management requests include context information associated with the UE, and the context information includes at least a location requirement, a time window requirement, or an access type preference; Determining, by the one or more NSCE servers based on the received context information, a certain number of network slice instances that the UE is configured to use; as well as One or more responses are sent by the one or more NSCE servers to the NSCE client, the one or more responses indicating whether one or more network slices are configured to meet the requirements specified in the one or more requests.

16. The method according to claim 15, further comprising: sending, by the one or more NSCE servers to one or more core network functions, one or more requests for additional context information corresponding to the one or more network slice management requests; The one or more NSCE servers receive the additional context information from the one or more core network functions, wherein the additional context information includes: location information of one or more UEs that are objects of communication with the UE, a current network slice permitted for use by the UE, a UE routing policy URSP currently configured for use by the UE, or a combination thereof; and Wherein determining a certain number of network slice instances that the UE is configured to use is also based on the additional context information.

17. The method of claim 15, wherein determining a number of network slice instances that the UE is configured to use comprises: Determine whether the UE is permitted to implement the number of network slice instances.

18. The method of claim 15, wherein the one or more responses sent include a set of NSCE client configuration rules NCCR corresponding to slice access management for the UE, wherein: The NCCR indicates one or more triggers that cause the UE to modify the UE routing policy URSP currently configured for use by the UE.

19. The method of claim 15, wherein the location requirement further comprises a location or a route for which the UE requires use of a network slice.

20. The method of claim 15, wherein the time window requirement further includes a schedule for when the UE requires use of a network slice.

Images