Core Network

Abstract

The present application is at least directed to a core network including a non-volatile memory having instructions stored thereon for registering a network function or a network function template in the core network. The network includes a processor operably coupled to the non-volatile memory. The processor is configured to execute instructions for determining that registration of a network function or a network function template is acceptable. The processor is also configured to execute instructions for sending a message including the network function or the network function template to a repository in the core network. The processor is also configured to execute instructions for verifying the network function or the network function template against existing policies in the core network. The processor is also configured to execute instructions for registering the network function or the network function template in the repository after verification. The present application is also directed to a core network in which a network function or a network function template is discovered. The present application is also directed to a core network for instantiating a network function.

Description

[0001] This application is a divisional application of the invention patent application with the application date of October 5, 2017, the name of which is “Core Network” and the application number is 201780070756.5.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Application No. 62 / 404,467, filed on October 5, 2016, entitled “Capability Exposure for Service Instantiation,” the contents of which are incorporated herein by reference in their entirety. Technical Field

[0004] The present application relates to network function virtualization techniques and instructions for registration, discovery, instantiation, scaling, and reconfiguration of services on a core network. Background Art

[0005] Typically, a network operator in a core network can decide to instantiate a new service or network function (NF) based on observed network behavior. For example, network behavior may indicate that more or fewer devices are attached to the network. Therefore, the network operator can decide to scale up or scale down a specific NF.

[0006] Gathering the necessary intelligence to scale up or down may require further assistance. Specifically, nodes such as user equipment (UE) and / or application servers (AS) may be preferably positioned to provide suggestions for scaling, configuring, or instantiating network functions. For example, an AS may inform a network operator that a certain type of traffic is cacheable, thereby letting the network operator know that instantiating a cache service network function is acceptable.

[0007] A network operator may provide a catalog or repository of NFs available for instantiation upon node request. Requests from nodes to configure, scale, or instantiate NFs may not always result in instantaneous network reconfiguration. Depending on the request, it may take several minutes or longer to complete a network reconfiguration. What is needed is an improved way to notify nodes when a network reconfiguration occurs.

[0008] Network confirmation may also involve the location where the service or NF is instantiated. That is, there are cases where the NF may need to be geographically located at the edge of the network in close proximity to the devices that use it. However, instantiating services at the edge of the network poses challenges for collecting billing records for services provided locally to the UE. Summary of the invention

[0009] The present disclosure is provided to introduce some concepts in a simplified form, which will be further described in the following detailed description. The present disclosure is not intended to limit the scope of the claimed subject matter. To a large extent, the above needs are met by the present application involving network function virtualization including dynamic registration, discovery, instantiation, scaling and reconfiguration of services.

[0010] In one aspect of the present application, a core network is described that includes a non-volatile memory having instructions stored thereon for registering a network function or a network function template in the core network. The core network also includes a processor operably coupled to the non-volatile memory. The processor is configured to execute instructions to determine that registration of the network function or the network function template is acceptable. The processor is also configured to execute instructions to send a message including the network function or the network function template to a repository in the core network. The processor is also configured to execute instructions to verify the network function or the network function template against an existing policy in the core network. The processor is also configured to execute instructions to register the network function or the network function template in the repository after verification.

[0011] In another aspect of the present application, a core network including a non-volatile memory having instructions stored thereon for discovering network functions or network function templates in the core network is described. The core network also includes a processor operably coupled to the non-volatile memory. The processor is configured to execute instructions to determine that the discovery of a network function or a network function template is acceptable at the core network. The processor is also configured to execute instructions to send a message including a network function or a network function template to a repository in the core network. The processor is also configured to execute instructions to search for network functions or network function templates in the repository in the core network. The processor is also configured to execute instructions to discover network functions or network function templates in the repository in the core network. The processor is even configured to execute instructions to send a discovery response to a networking function in the core network based on the discovery instruction.

[0012] Another aspect of the present application relates to a core network including a non-volatile memory having instructions stored thereon for instantiating a network function in the core network. The core network also includes a processor operably coupled to the non-volatile memory. The processor is configured to execute instructions to determine that the instantiation of the network function is acceptable at the core network. The processor is also configured to execute instructions to determine that the instantiation of the network function is acceptable. The processor is also configured to execute instructions to send a message including an instantiation request for the network function to a slice instance management function in the core network. The processor is also configured to execute instructions to verify that the network function can be instantiated. The processor is also configured to execute instructions to instantiate the network function. The instantiation instruction may include registration of a first instance of the network function. Alternatively, if the network function exists, the instantiation instruction may include a change in state.

[0013] There has thus been outlined, rather broadly, certain embodiments of the invention in order that the detailed description thereof may be better understood, and in order that the present contribution to the art may be better appreciated. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to promote a more robust understanding of the present application, reference is now made to the accompanying drawings, in which like elements are denoted by like reference numerals. These drawings should not be construed as limiting the present application, but are intended to be illustrative only.

[0015] Figure 1 The diagram shows the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) architecture framework.

[0016] Figure 2 The diagram shows the (S)Gi-LAN architecture.

[0017] Figure 3 The diagram illustrates the Internet Engineering Task Force (IETF) service function linking architecture framework.

[0018] Figure 4 Illustrated is Network Services Header (NSH) encapsulation relative to an Internet Protocol (IP) datagram.

[0019] Figure 5 The diagram illustrates the 3GPP Flexible Mobile Service Steering (FMSS) architecture and Network Service Descriptor (NSD).

[0020] Figure 6 The diagram shows the overview and composition of NSD.

[0021] Figure 7 The diagram illustrates the 3GPP architecture for service capability exposure.

[0022] Fig. 8AAn embodiment of a machine-to-machine (M2M) or IOT communication system is illustrated.

[0023] Figure 8B An embodiment of an application of an M2M service platform is illustrated.

[0024] Figure 8C An embodiment of an application of a system diagram of example M2M devices is illustrated.

[0025] Fig.8D An embodiment of an application of a block diagram of an exemplary computing system is illustrated.

[0026] Fig. 8E An exemplary communication system according to an embodiment is illustrated.

[0027] Fig.8F An exemplary apparatus configured for wireless communications in accordance with an embodiment is illustrated.

[0028] Figure 8G A system diagram of a radio access network and a core network according to an embodiment is illustrated.

[0029] Figure 8H A system diagram of a radio access network and a core network according to another embodiment is illustrated.

[0030] Figure 8I A system diagram of a radio access network and a core network according to yet another embodiment is illustrated.

[0031] Figure 8J Diagram showing the 5G core network.

[0032] Fig. 9 An exemplary use case according to an embodiment of the present application is illustrated.

[0033] Fig.10 The diagram illustrates a 5G network architecture for network exposure according to an embodiment of the present application.

[0034] Fig.11 The figure illustrates the registration process according to an embodiment of the present application.

[0035] Fig.12 The diagram illustrates the NF or Network Function Template (NFT) discovery or subscription / notification process according to an embodiment of the present application.

[0036] Fig.13 The diagram illustrates the NF instantiation process according to an embodiment of the present application.

[0037] Fig.14 The diagram illustrates a common process for NF instance management according to an embodiment of the present application.

[0038] Fig.15The exposed API at the UE according to an embodiment of the present application is illustrated.

[0039] Fig.16 Exemplary graphical user interfaces of a UE, a server, and a core network according to an embodiment of the present application are illustrated. DETAILED DESCRIPTION

[0040] A detailed description of illustrative embodiments will be discussed with reference to the various figures, embodiments and aspects of this document.While this description provides detailed examples of possible implementations, it should be understood that the details are intended to be examples and therefore do not limit the scope of the present application.

[0041] References in this specification to "one embodiment," "an embodiment," "one or more embodiments," "aspects," etc., mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Moreover, the term "embodiment" in various places in the specification does not necessarily refer to the same embodiment. That is, various features are described that may be present in some embodiments but not in another embodiment.

[0042] Generally, the present application relates to a core network that utilizes network function virtualization (NFV) technology to enable dynamic instantiation, scaling, and reconfiguration of services. Network operators will require information or actions from UEs and ASs to trigger and / or provide information used by decisions and processes for service instantiation. In an embodiment, the present application describes an NF repository, a directory or repository, and an NF template in a core network. Since the network function template provides a common profile for the associated NF instantiation, the NF template (NFT) may also be referred to as an NF profile. It should also be recognized that if a separate repository for NFT is not deployed, the functions described as part of the NFT may be performed by the NF repository (NFR), integrated with the NFR, or co-located with the NFR. NFR may also be referred to as an NF repository function (NRF).

[0043] A third-party SCS or AS can be enabled to access a repository of NFs available in the mobile core network. This allows them to discover existing functions and obtain relevant information about their services.

[0044] In one aspect of the present application, a method and system are drawn to enable SCS / AS to register NF and NFT in their respective repositories. This provides new functionality for further use in the core network.

[0045] In another aspect of the present application, a method and system are drawn that enables SCS / AS to discover NFs, NFTs and their capabilities in their respective repositories.

[0046] In yet another aspect of the present application, a method and system are drawn that enables an SCS / AS to subscribe to NF and NFT repositories to obtain notifications of updates and events.

[0047] In even another embodiment, a method and system are drawn that enables an AS to request instantiation of NFs available in the system, i.e., spawning. Instantiation allows a node to request a specific geographic location for function instantiation. It also provides the ability to configure how billing information should be generated. Several methods are contemplated in the present application, including but not limited to: (i) enabling SCS / AS to request instantiation of NFs in the core network, (ii) enabling SCS / AS to reconfigure instantiated NFs, (iii) enabling SCS / AS to terminate NF instances, (iv) enabling SCS / AS to expand / reduce NFs, and (v) enabling SCS / AS to change the state of NF instantiation. These instantiation and instance management and reconfiguration techniques provide the ability to request a specific location (e.g., geography) for function instantiation. They also provide the ability to configure how billing information should be generated. As will be discussed in more detail below, the technology of the present application is applicable to AS, SCS, services, network functions, value-added services, core functions, or value-added functions owned by an operator. Similar but separate methods for enabling UEs to discover the function are also contemplated in the present application.

[0048] Definitions and abbreviations

[0049] Definitions of terms and phrases commonly used in this application are provided below in Table 1.

[0050] The service layer can be a functional layer within a network service architecture. The service layer is usually located above the application protocol layer (such as HTTP, CoAP or MQTT) and provides value-added services to client applications. The service layer also provides an interface to the core network at the lower resource layer (such as, for example, the control layer and the transport / access layer). The service layer supports multiple categories of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control and service clustering. Recently, several industry standard organizations (e.g., oneM2M) have been developing the M2M service layer to address the challenges associated with the integration of M2M-type devices and applications into deployments such as the Internet / web, cellular, enterprise and home networks. The M2M service layer can provide access to the above-mentioned capabilities or function sets supported by the service layer for applications and / or various devices, and the service layer can be referred to as a public service entity (CSE) or a service capability layer (SCL). Some examples include, but are not limited to, security, charging, data management, device management, discovery, supply and connectivity management, which can be used by various applications in common. These capabilities or functions make these various applications available via APIs that use the message formats, resource structures, and resource representations defined by the M2M service layer. CSE or SCL is a functional entity that can be implemented by hardware or software, and provides (service) capabilities or functions (i.e., functional interfaces between these functional entities) exposed to various applications or devices so that they use such capabilities or functions.

[0051]

[0052]

[0053]

[0054] Table 1

[0055] A consumer NF is a function that needs to access the functionality of other NFs, and therefore consumes their services.

[0056] NF is a processing function in a network with defined functional behaviors and interfaces. NF can be implemented as a network element on dedicated hardware, or as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (e.g., on a cloud infrastructure). NF can be the smallest unit instantiated in a network.

[0057] A network service (NS) is a service that is functionally provided to end users by instantiating one or more functions. NS is defined as a composition of NFs.

[0058] A network slice or network slice instance is an instantiation of a network slice template. A network slice consists of all NFs and NSs required to provide the required telecommunication services and network capabilities, as well as the resources to run these NFs and NSs.

[0059] Core-NF describes the OAM NF defined in the CN domain.

[0060] VA-NF (Value Added NF) is used for NFs provided by OAM or other tenants in the tenant domain.

[0061] OTT-NF (over-the-top-NF) is used for network functions / services from external domains.

[0062] A provider is a NF whose functionality is provided to other NFs.

[0063] (S)Gi-LAN is a reference point that describes the point of logical interconnection between the EPC network and different packet data networks (PDN), while the Gi reference point describes the point of logical interconnection between the GPRS network and another PDN. The term (S)Gi-LAN refers to the packet data network located between the GGSN or P-GW of the mobile core network and the Internet. (S)Gi-LAN is controlled by the MNO.

[0064] The Underlay Network (ULN) is a set of NFs or nodes that reside in the core network but do not belong to any specific network slice (instance). Even though the ULN functions do not belong to a specific network slice, they can be virtualized and can be grouped together as a common (used by multiple network slice instances) set of functions. The functions in the latency network can be aligned with the functions described as common CP functions in the reference.

[0065] Network Function Virtualization (NFV)

[0066] NFV is a network architecture concept that uses virtualization to create network node functions as virtual building blocks that are connected to provide communication services. This aims to transform the way network operators architect networks by integrating many types of network equipment onto industry-standard high-capacity servers, switches, and storage devices. NFs (e.g., mobility management, session management, QoS) are implemented in software that can run on standard server hardware. NFs can be instantiated at various locations such as data centers, network nodes, and even end-user premises.

[0067] The ETSI working group on NFV has produced white papers, standard term definitions and use cases that serve as a reference for vendors and operators considering implementing NFV. An architectural framework for applying NFV concepts to mobile core networks is contemplated in this application.

[0068] Figure 1 The NFV architecture framework shown in identifies the functional blocks and the main reference points between these blocks. The functional blocks are:

[0069] Virtualized Network Functions (VNFs)

[0070] Component Management (EM)

[0071] NFV infrastructure: hardware and virtualized resources and virtualization layer

[0072] Operations and Business Support Systems (OSS / BSS)

[0073] NFV Management and Orchestration (MANO), including: Virtualization Infrastructure Manager(s), NFV Coordinator, VNF Manager(s), Services, VNFs and Infrastructure Description.

[0074] As specified by the ETSI architecture, a VNF may adopt multiple internal states with transitions, thereby providing an architectural model for the intended VNF functionality. This is exemplarily shown in Table 2 below.

[0075]

[0076] Table 2

[0077] Value-added Services

[0078] MNOs have a great interest in optimizing the complex services provided over the packet data network between the MCN and external networks via the (S)Gi interface defined by 3GPP.

[0079] These functions can include value-added services (VAS) such as web proxies, video optimization, firewalls, load balancers, HTTP header enhancements, TCP optimizers, content and billing gateways, and NAT. Typically, deep packet inspection (DPI) techniques determine whether each VAS should operate on a data flow. (S)Gi-LAN functions are under the control of the MNO and can be virtualized and mapped to software-configured service chains to create more efficient and programmable value-added service domains.

[0080] like Figure 2 As shown, traffic to / from (S)Gi-LAN and servers (such as M2M servers) in the public Internet can be routed. In addition, M2M servers can be deployed inside (S)Gi-LAN by operators or service providers to provide a set of value-added services for M2M / IoT use cases.

[0081] IETF Service Function Link

[0082] The IETF has developed an architectural framework for efficiently deploying VAS, otherwise referred to in this application as "service functions." The framework allows traffic to be "steered" through services that apply only to each individual flow, rather than requiring all traffic to be routed serially through all service functions.

[0083] Figure 3 Figure illustrating the main components of the IETF's SFC architecture framework. The Service Classification Function (SCF) accepts input packets. In a traditional (S)Gi-LAN, the input packets can be IP packets from the P-GW / GGSN or the Internet. For example, the SCF can encapsulate the input packets with another header; determine which service functions the packets should be routed through; determine the order in which the packets should be routed through the service functions; and attach metadata to the packets to assist the service functions.

[0084] The Service Function Forwarder (SFF) will accept packets from the SCF and route them through the service functions. Once the packet has been routed through its service path, the SFF will forward the packet to the egress node. The egress node will remove any additional header information inserted by the SCF, SFF or service function and send the packet out of the (S)Gi-LAN and into the P-GW / GGSN or public Internet.

[0085] The SFC working group of the IETF defined the Network Service Header (NSH) to contain metadata and service path information used in the data plane to direct traffic through network services. Figure 4 The figure shows NSH encapsulation relative to IP datagram. The format of NSH includes the following three headers:

[0086] In the first header, the basic header includes: (i) a version field; (ii) a 'C bit indicating the presence of key metadata in the network service header; (iii) a length field indicating the total length of the NSH; (iv) a metadata type field indicating the format of the metadata; and (v) a next protocol field indicating the format of the original payload.

[0087] In the second header, the service path header includes: (i) a service path ID, which is a 24-bit field indicating a service path that should be selected for the packet; and (ii) a service index for indicating a location of the packet in the service path.

[0088] The third header depends on how the metadata type field is set in the base header. The context header can be in one of two formats – fixed length or containing variable length values. For the variable length option, specify the format of the metadata and how to indicate the length of each value in the context header.

[0089] Allows service-aware nodes to perform header-related actions such as inserting headers, removing headers, selecting service paths, updating context headers, and policy selection based on header content. Of course, service-aware nodes can also inspect and modify more than just NSH headers. Service nodes such as NAT, firewalls, HTTP header enrichment can also inspect and modify IP, UDP / TCP / application data.

[0090] 3GPP Flexible Mobile Service Steering

[0091] The 3GPP SA2 working group has a work item called Flexible Mobile Service Steering (FMSS). The goal of this work item is to define service requirements to enable the 3GPP core network to define and modify traffic steering policies that will be used to select the required service enablers of the (S)Gi-LAN deployed by the operator. The goal is to achieve efficient and flexible mobile service steering in (S)Gi-LAN.

[0092] Figure 5 Shows how to apply the 3GPP architecture to the IETF proposed architecture. The green shaded boxes are standardized by 3GPP and owned by the MNO. The orange boxes are not standardized by 3GPP, but they are typically deployed in (S)Gi-LANs and owned by the MNO.

[0093] The St reference point allows the PCRF to provide traffic steering policies to the SCF in the (S)Gi-LAN. The St reference point also suggests that the Sd interface communicates with the TDF to provide traffic steering policies to the TDF. The TDF can then be used to apply packet markings (i.e., NSH) to traffic based on detected applications, users, etc., and the P-GW applies packet markings (i.e., NSH) based on the policies from the PCRF.

[0094] Network Features template and network services Descriptors

[0095] A Network Service (NS) is a composition of NFs that is arranged as a collection of functions with unspecified connectivity between them or according to one or more forwarding graphs. The description of a NS used by the NFV management and coordination function to deploy network service instances includes references to the descriptors of its constituent objects. ETSI GS NFV-IFA 011 specifies network service templates for creating object instances and the format of VNF descriptors to be exchanged between OSS / BSS and NFVO. A Network Service Descriptor (NSD) is a deployment template consisting of information used by the NFV Coordinator (NFVO) for lifecycle management of a NS. As Figure 6 As shown, NSD includes the following:

[0096] One or more Virtualized Network Function Descriptors (VNFDs).

[0097] Zero, one or more Physical Network Function Descriptors (PNFDs) used by the NFVO to determine how to connect the PNF to the VL. The information contained within the PNFD is limited to the description of the connectivity requirements for integrating the PNF into the NS.

[0098] Zero, one or more Virtual Link Descriptors (VLDs) used by the NFVO to deploy Virtual Links (VLs), and

[0099] Zero, one or more VNF Forwarding Graph Descriptors (VNFFGD).

[0100] The VNFFGD describes the topology of a network service or a portion of a network service by referencing a pool of connection points and service access points, descriptors of its constituent VNFs, PNFs, and the VLs that connect them. It may also contain one or more Network Forwarding Path (NFP) descriptors.

[0101] The VNFD may also indicate a specific VNF "flavor" that provides further instantiation details (such as the number of instances of each constituent VNF), or specify "affinity rules" that dictate how VMs and hosts are kept together.

[0102] In Release 13, 3GPP defined the Service Capability Exposure Framework (SCEF), which provides a means to expose services and capabilities provided by 3GPP network interfaces. Several future work items are defined as part of this work, including, for example:

[0103] Supports establishment of Application Server (AS) sessions with required QoS;

[0104] Supports changing the chargeable party at session establishment or during a session;

[0105] Support third-party interaction of information on predictable communication patterns;

[0106] Support notification of third parties regarding potential network issues; and

[0107] Supports 3GPP resource management for background data transmission.

[0108] In TS 23.682, 3GPP introduced a functional block, namely, SCEF, to provide a means to securely expose the services and capabilities provided by the 3GPP network interface. Figure 7The exposure of services by the network creates capabilities that can be used, with appropriate authorization, to accomplish one or more of the following: (i) retrieve information, (ii) request a specific service, (iii) receive notifications, and (iv) request the setting of specific parameters. The SCEF also provides a means for discovering exposed service capabilities.

[0109] General architecture

[0110] Fig. 8A is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Internet of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides building blocks for IoT / WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of IoT / WoT and IoT / WoT service layer, etc. Any node shown in any of the diagrams may include a communication system (such as Figures 8A-8D Node of the system shown).

[0111] like Fig. 8A As shown, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may include multiple access networks that provide content such as voice, data, video, message, broadcast, etc. to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc. In addition, for example, the communication network 12 may include other networks, such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0112] like Fig. 8AAs shown, the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain refers to the regional network usually behind the M2M gateway. The field domain and the infrastructure domain may both include various different nodes of the network (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and an M2M terminal device 18. It should be appreciated that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway device 14 and the M2M terminal device 18 is configured to send and receive signals via the communication network 12 or a direct radio link using a communication circuit system. The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate through an operator network (such as the communication network 12) or a direct radio link. For example, the M2M terminal device 18 can collect data and send the data to the M2M application 20 or other M2M terminal devices 18 via the communication network 12 or a direct radio link. The M2M terminal device 18 can also receive data from the M2M application 20 or the M2M terminal device 18. In addition, data and signals can be sent to and received from the M2M application 20 via the M2M service layer 22, as described below. The M2M terminal device 18 and the gateway 14 can communicate via various networks, including, for example, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio links, and wired lines. For example, exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart sockets.

[0113] refer to Figure 8B , the M2M service layer 22 shown in the field domain provides services for the M2M application 20, the M2M gateway 14 and the M2M terminal device 18, and the communication network 12. It should be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateways 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 can be implemented by one or more nodes of a network, which may include servers, computers, devices, etc. The M2M service layer 22 provides service capabilities applied to the M2M terminal devices 18, the M2M gateway 14, and the M2M application 20. The functions of the M2M service layer 22 can be implemented in a variety of ways, such as as a web server, in a cellular core network, in the cloud, etc.

[0114] Similar to the M2M service layer 22 shown, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the underlying communication network 12' in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateways 14 and M2M terminal devices 18 in the field domain. It will be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can be interacted with by different service providers. The M2M service layer 22' can be implemented by one or more nodes of a network, which can include servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.), etc.

[0115] Also refer to Figure 8B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that different applications and verticals can fully utilize. These service functions enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. Basically, these service functions relieve the application of the burden of implementing these functions, thereby simplifying application development and reducing costs and time to market. The service layers 22 and 22' also enable the M2M applications 20 and 20' to communicate in association with the services provided by the service layers 22 and 22' over various networks 12 and 12'.

[0116] The M2M applications 20 and 20' may include applications in various industries, such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and monitoring. As mentioned above, the M2M service layer running across devices, gateways, servers, and other nodes of the system supports functions such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery, and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0117] Typically, a service layer (such as Fig. 8A and 8BThe service layer 22 and 22' shown in the figure can be a functional layer within the network service architecture. The service layer is usually located above the application protocol layer such as HTTP, CoAP or MQTT, and provides value-added services to client applications. The service layer also provides an interface to the core network at lower resource layers such as the control layer and the transport / access layer. The service layer supports multiple categories of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control and service clustering. Recently, several industry standard organizations, such as oneM2M, have been developing M2M service layers to address the challenges associated with integrating M2M-type devices and applications into deployments such as the Internet / Web, cellular, enterprise and home networks. The M2M service layer can provide applications and / or various devices with access to a set of the above-mentioned capabilities or functions or a set of the above-mentioned capabilities or functions supported by the service layer, which can be referred to as a public service entity (CSE) or a service capability layer (SCL). Some examples include, but are not limited to, security, billing, data management, device management, discovery, provisioning and connection management that can be used in common by various applications. These capabilities or functions are available to these various applications via APIs that utilize message formats, resource structures, and resource representations defined by the M2M service layer. A CSE or SCL is a functional entity that can be implemented by hardware and / or software and provides (service) capabilities or functions (i.e., functional interfaces between these functional entities) exposed to various applications and / or devices in order to enable them to use these capabilities or functions. The Third Generation Partnership Project (3GPP) also defines an architecture for machine type communication (MTC). In this architecture, the service layer and the service capabilities it provides are implemented as part of a service capability server (SCS). Whether implemented in a device SCL ("DSCL"), gateway SCL ("GSCL"), or network SCL ("NSCL") of the ETSI M2M architecture, in a service capability server (SCS) of the 3GPP MTC architecture, in a public service function ("CSF") or CSE of the oneM2M architecture, or in some other node of the network, an instance of the service layer may be implemented as a logical entity (e.g., software, computer executable instructions, etc.) executed either on one or more independent nodes (including servers, computers, and other computing devices or nodes) in the network, or as part of one or more existing nodes. As an example, an instance of the service layer or its components may be implemented in the form of software running on a network node (e.g., a server, computer, gateway, device, etc.) having the following described. Figure 8C or Fig.8D The general architecture shown in .

[0118] Additionally, the methods and functions described herein may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services.

[0119] Figure 8C is a block diagram of an example hardware / software architecture of a node of a network, such as Figure 10-16 The example shown in Fig. 8A and 8B One of the nodes in the M2M network shown in FIG. 1 that operates as an M2M server, gateway, device, or other node. Figure 8C As shown, the node 30 may include a processor 32, a non-removable memory 44, a removable memory 46, a speaker / microphone 38, a keyboard 40, a display, a touch pad and / or an indicator 42, a power supply 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include a communication circuit system, such as a transceiver 34 and a send / receive element 36. It should be appreciated that the node 30 may include any sub-combination of the aforementioned elements while remaining consistent with the embodiment. The node may be a node that implements the time flexibility function described herein.

[0120] The processor 32 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. In general, the processor 32 may execute computer executable instructions stored in a memory of the node (e.g., memory 44 and / or memory 46) to perform various desired functions of the node. For example, the processor 32 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the node 30 to operate in a wireless or wired environment. The computer executable instructions stored in the memory of the node and executed by the processor may also enable the node to perform the above-mentioned Figure 11-15 The processor 32 may run application layer programs (e.g., browsers) and / or radio access layer (RAN) programs and / or other communication programs. The processor 32 may also perform security operations such as authentication, security key negotiation, and / or encryption operations, such as at the access layer and / or application layer, for example.

[0121] like Figure 8CAs shown, processor 32 is coupled to its communication circuit system (e.g., transceiver 34 and transmit / receive element 36). Processor 32 can control the communication circuit system by executing computer executable instructions so that node 30 communicates with other nodes via the network connected thereto. In particular, processor 32 can control the communication circuit system so as to execute the present invention (e.g., in Figure 11-15 The sending and receiving steps described and shown in the claims. Figure 8C The processor 32 and transceiver 34 are depicted as separate components, but it should be appreciated that the processor 32 and transceiver 34 may be integrated together in an electronic package or chip.

[0122] The send / receive element 36 can be configured to send signals to other nodes or receive signals from other nodes, and other nodes include M2M servers, gateways, equipment, etc. For example, in an embodiment, the send / receive element 36 can be an antenna configured to send or receive RF signals. The send / receive element 36 can support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, the send / receive element 36 can be a transmitter / detector configured to, for example, send or receive IR, UV or visible light signals. In another embodiment, the send / receive element 36 can be configured to send and receive both RF and optical signals. It will be appreciated that the send / receive element 36 can be configured to send and / or receive any combination of wireless or wired signals.

[0123] Furthermore, although the transmit / receive element 36 is Figure 8C Although depicted as a single element in FIG. 3 , the node 30 may include any number of transmit / receive elements 36. More specifically, the node 30 may employ MTMO technology. Therefore, in an embodiment, the node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for sending and receiving wireless signals.

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

[0125] The processor 32 can access information from any type of suitable memory (such as non-removable memory 44 and / or removable memory 46) and store data therein. For example, the processor 32 can store the session context in its memory, as described above. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 32 can access information from a memory physically located on the node 30 (such as on a server or a home computer) and store data in the memory. The processor 32 can be configured to control the lighting pattern, image, or color on the display or indicator 42 to reflect the status of the communication and provide a graphical user interface, such as Fig.16 The GUI shown in and described above.

[0126] Processor 32 may receive power from power source 48 and may be configured to distribute and / or control power to other components in node 30. Power source 48 may be any suitable device for powering node 30. For example, power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0127] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (eg, longitude and latitude) regarding the current location of node 30. It should be appreciated that node 30 may acquire location information via any suitable location determination method while remaining consistent with an embodiment.

[0128] The processor 32 may also be coupled to other peripherals 52, 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 52 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.

[0129] Node 30 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or eHealth equipment, robots, industrial equipment, unmanned aerial vehicles, vehicles such as cars, trucks, trains or airplanes. Node 30 may be connected to other components, modules or systems of these devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of peripheral devices 52).

[0130] Fig.8D is a block diagram of an exemplary computing system 90, which may also be used to implement one or more nodes of a network, such as Figure 11-15 , which can be used as a node in Fig. 8A and 8B 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, stored or accessed anywhere or by any means. Such computer-readable instructions may be executed within a processor such as a central processing unit (CPU) 91 to cause the computing system 90 to perform operations, such as, for example, executing Figure 10-15 The operations shown and described in the and description of the drawings. In many known workstations, servers and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor, different from the main CPU 91, which performs additional functions or assists the CPU 91.

[0131] In operation, the CPU 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computer's main data transfer path, the system bus 80. Such a system bus connects the components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically 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.

[0132] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally includes stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates 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 has been set up, it cannot access memory within the virtual address space of another process.

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

[0134] The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented as a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components necessary to generate the video signals sent to the display 86. For example, the display 86 may be used to display a graphical user interface (GUI) for user equipment, servers, and / or core networks, such as Fig.16 shown and described above.

[0135] Additionally, computing system 90 may include communications circuitry such as, for example, network adapter 97, which may be used to connect computing system 90 to an external communications network, such as Fig. 8A and Figure 8B The network 12 enables the computing system 90 to communicate with other nodes of the network. The communication circuit system alone or in combination with the CPU 91 can be used to perform the operations described herein (e.g., in Figure 11-15 ) and the sending and receiving steps described in the claims.

[0136] The Third 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), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation of cellular technology, which is called New Radio (NR), also known as "5G". The development of the 3GPP NR standard is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to include new, non-backward compatible radio access in new spectrum below 6 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-6 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0137] 3GPP has identified a variety of use cases that NR is expected to support, resulting in various user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, ubiquitous 50+Mbps, ultra-low-cost broadband access, in-vehicle mobile broadband), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive eCall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality, among others. All of these use cases and others are contemplated herein.

[0138] Fig. 8EAn embodiment of an example communication system 100 is illustrated in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, but it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e Fig. 8E -I is depicted as a handheld wireless communication device, but it should be understood that for the various use cases expected 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, and by way of example only, the device or apparatus includes a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics 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, etc.).

[0139] 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 wire and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b and / or TRPs (transmission and reception points) 119a, 119b 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 RRHs 118a, 118b may be any type of device configured to 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 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. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, and the like. While the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0140] 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 and / 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, in an embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may therefore use multiple transceivers for each sector of the cell.

[0141] 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).

[0142] The base station 114b may communicate with one or more of the RRHs 118a, 118b and / or TRPs 119a, 119b 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).

[0143] The RRHs 118a, 118b and / or the TRPs 119a, 119b may communicate with one or more WTRUs 102c, 102c 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).

[0144] 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 and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d 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).

[0145] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 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-Advance (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.

[0146] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, 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.

[0147] The base station 114c in Figure 8 can be a wireless router, a Home Node B, a Home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area (such as a business location, a home, a vehicle, a campus, etc.). In an embodiment, 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 an embodiment, 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 another embodiment, 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 picocell or a femtocell. Fig. 8E 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.

[0148] 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).

[0149] Although not in Fig. 8E105b 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.

[0150] 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 computer networks and devices that are interconnected using 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 as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0151] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig. 8E 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.

[0152] Fig.8F 1 is a block diagram of an example apparatus or device (eg, WTRU 102) configured for wireless communication according to the embodiments described herein. Fig.8FAs shown in the example WTRU 102, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, 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 will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiment. Moreover, the embodiment contemplates that the base stations 114a and 114b, and / or nodes of 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 server node, etc. may include Fig.8F Some or all of the elements depicted in and described herein.

[0153] 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 Fig.8F The processor 118 and transceiver 120 are depicted as separate, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0154] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. Fig. 8E103 / 104 / 105 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 or a different RAT as the RAN 103 / 104 / 105. For example, in addition to being connected to the RAN 103 / 104 / 105, which may employ an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0155] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d 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 computer networks and devices that are interconnected using 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 employ the same RAT as the RAN 103 / 104 / 105 or a different RAT.

[0156] 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. Fig. 8E 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.

[0157] Fig.8F 1 is a block diagram of an example apparatus or device (such as, for example, WTRU 102) configured for wireless communication according to the embodiments described herein. Fig.8FAs 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 126, 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 should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments. Moreover, the embodiments contemplate that 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 include Fig.8F Some or all of the elements described in and described herein.

[0158] 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 Fig.8F The processor 118 and the transceiver 120 are depicted as separate components, but it should be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0160] In addition, although the transmit / receive element 122 is Fig.8F 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 an embodiment, 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.

[0161] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and 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 to enable the WTRU 102 to communicate via multiple RATs (e.g., such as UTRA and IEEE 802.11).

[0162] 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 memory 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 an embodiment, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0164] 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. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received 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 remaining consistent with an embodiment.

[0165] 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.

[0166] 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 equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes), etc. 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 an interconnect interface that may include one of the peripheral devices 138).

[0167] Figure 8G 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. 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 be in communication with the core network 106. Figure 8GAs 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 should be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0168] like Figure 8G As 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. RNC142a, 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 connected thereto. 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.

[0169] Figure 8G 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 foregoing elements is depicted as part of the core network 106, it should be appreciated that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0170] 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.

[0171] 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.

[0172] 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.

[0173] Figure 8H 1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. 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.

[0174] 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 remaining consistent with an embodiment. 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 an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0175] 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 8H As shown in FIG. , the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0176] Figure 8HThe 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. While each of the foregoing elements is depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0177] 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, etc. 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.

[0178] 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 / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during an inter-eNode B handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0179] 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.

[0180] 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 serves 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.

[0181] Fig. 8E 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. 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 will be discussed further 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.

[0182] like Figure 8I As shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. 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 an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to send wireless signals to the WTRU 102a 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 serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0183] 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.

[0184] The communication link between each base station 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transfer between the 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 for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0185] like Figure 8I As 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 protocols for facilitating, for example, 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. While each of the foregoing elements is depicted as part of the core network 109, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0186] 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.

[0187] Although not in Figure 8I 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 105 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, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0188] This article describes and Fig. 8E , 8G The core network entities shown in 8D and 8I are identified by the names given to those entities in certain existing 3GPP specifications, but it should be recognized that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig. 8E The specific network entities and functionality described and illustrated in -I are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0189] Figure 8JThe 5G core network 170 shown in the figure may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, a user plane function (UPF) 176, a user data management function (UDM) 178, an authentication server function (AUSF) 180, a network exposure function (NEF), a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 192, and an application function (AF) 188. Although each of the foregoing elements is depicted as part of the 5G core network 170, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be appreciated that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 8J The network functions are shown connected directly to each other, however, it should be appreciated that they may communicate via a routing agent such as a Diameter routing agent or a message bus.

[0190] The AMF 172 may be connected to each of the RAN 103 / 104 / 105 / 103b / 104b / 105b via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, 102c.

[0191] The SMF 174 may be connected to the AMF 172 via an N11 interface, to the PCF 184 via an N7 interface, and to the UPF 176 via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, WTRU 102a, 102b, 102c IP address allocation and management, and configuration of traffic steering rules in the UPF 176, and generation of downlink data notifications.

[0192] The SMF 174 may also be connected to the UPF 176, which may provide the WTRUs 102a, 102b, 102c with access to a data network (DN) 190, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The SMF 174 may manage and configure traffic steering rules in the UPF 176 via the N4 interface. The UPF 176 may be responsible for interconnecting packet data unit (PDU) sessions with the data network, packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, and downlink packet buffering.

[0193] The AMF 172 may also be connected to the N3IWF 192 via an N2 interface. The N3IWF facilitates connectivity between the WTRUs 102a, 102b, 102c and the 5G core network 170 via radio interface technologies that are not defined by 3GPP.

[0194] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to Application Function (AF) 188 via an N5 interface. PCF 184 may provide policy rules to control plane nodes such as AMF 172 and SMF 174, allowing the control plane nodes to implement these rules.

[0195] UDM 178 acts as a repository for authentication credentials and subscription information. UDM can be connected to other functions such as AMF 172, SMF 174 and AUSF 180.

[0196] AUSF 180 performs operations related to authentication and is connected to UDM 178 via an N13 interface and to AMF 172 via an N12 interface.

[0197] NEF exposes capabilities and services in the 5G core network 170. NEF can be connected to AF 188 via an interface, and it can be connected to other control plane and user plane functions (180, 178, 172, 172, 184, 176 and N3IWF) to expose capabilities and services of the 5G core network 170.

[0198] The 5G core network 170 may facilitate communications with other networks. For example, the core network 170 may include an IP gateway (e.g., an IP Multimedia Subsystem (FMS) server) or may communicate with an IP gateway that serves as an interface between the 5G core network 170 and the PSTN 108. For example, the core network 170 may include a short message service (SMS) service center or communicate with a short message service (SMS) service center that facilitates communications via short message service. For example, the 5G core network 170 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, 102c and a server. In addition, the core network 170 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.

[0199] In one embodiment, an exemplary use case of the present application is provided. Fig. 9exemplarily shown in . Specifically, the sensors 910 are deployed in a warehouse 900 that transports hazardous materials. Due to the critical nature of the sensors 910, an urgent transmission from one of the sensors 910 must be sent through the local IP network 920 with minimal delay. In order to save energy, the sensors 910 are periodically available to receive read requests through the local IP network. It is contemplated that these constrained sensors 910 can use a third-party cache service 921 in the local IP network (e.g., the core network 920) to store readings in order to efficiently return to a power-efficient mode. Therefore, the sensors 910 do not need to wait for communications from the M2M server 930. Separately, it is contemplated that the M2M server 930 can instantiate and configure services for its devices and control their locations.

[0200] Core network architecture for service exposure

[0201] This section describes the SCEF API that can be exposed to the AS and used to configure network functions or slices used by the AS to provide services to (one or more) UEs. The API can also be exposed by the UE's OS and / or modem platform and used by the UE OS or UE applications to make network configuration requests. In this application, we refer to this API as the SCEF API. However, the same functionality can be exposed and provided by other network functions. The call flow is described to show how each API call will be performed when called from the AS.

[0202] According to Fig.10 In one embodiment exemplarily shown in FIG, the network architecture highlights the entities involved in providing exposure of network capabilities to entities outside the core network. In the exemplary embodiment, the network architecture is based on 5G. The 5G network is designed to provide connectivity via multiple and different RATs and relies on NFV technology. In the core network, virtualized network functions will be grouped together into network slices to provide one or more services to a UE and / or a group of UEs. A UE may be allowed to connect to more than one network slice at the same time. The network slices will not interact directly with each other to provide services, but they may run on the same physical platform and they may interface with some common functions such as in the underlying network.

[0203] The underlying network includes the core network functions that the UE needs to establish a connection and obtain the minimum service level required before the UE can be authenticated, authorized and allowed to connect to the network slice. For example, the underlying network contains the SISF for MCN slice instance management, which can interact with the MCN MANO to instantiate new NFs in the slice.

[0204] Policy management is provided via the PMF function depicted in the CN slice instance and can also be instantiated in the underlying network. The PMF abstracts the PCRF management function as described by 3GPP.

[0205] The network functions within a slice communicate via the interconnect and routing function (IRF). In a roaming scenario, the IRF of each slice (or part of a slice) will communicate via the IRF interworking (IRF-IWK) function in the underlying network.

[0206] Operator-defined enterprise, industry, and third-party services can be deployed as network functions in tenant domains or in an over-the-top (OTT) manner. When deployed within the CN, they can be connected and integrated into the operator's NFV framework via the operator's IRF. From a control perspective, services interact with network slices via the SCEF, which allows them to be configured to receive and provide services within the network slice.

[0207] These services can also be deployed in an OTT manner via the exit nodes of the slice. OTT services can be deployed to interact with the network slice also via a dedicated exposure function (e.g., SCEF).

[0208] In the 5G architecture, it is recommended that the SCEF can access the NFTR and NFR. Both the NFTR and NFR can be connected to (one or more) slice NFs via IRF, such as Fig.10 As shown. It is envisioned that the depicted functionality is contained entirely within the slice. Depending on the implementation, they may instead be located within the underlying network, or there may be components within the underlying network that can communicate with multiple slices.

[0209] Network Function Template Repository

[0210] According to an embodiment, the NFTR is a database of NF templates. The NFTR may reside in the underlying network and may be shared across network slices, or a network slice may have its own NFTR. Alternatively, each slice may have its own interface to the common NFTR. The interface may filter requests from the slices so that each slice can only see templates that are authorized for the slice. The NFTR may include templates that can be used for instantiation by the slice. The template may describe how to configure each NF instantiation. It is envisioned that the NFTR supports the following technologies:

[0211] (i) NF Template Registration: Receive and maintain NF templates as requested by other authorized core NFs or SCS / AS.

[0212] (ii) NF Template Discovery: Methods for discovering and retrieving NF template instances.

[0213] (iii) Subscription / Notification: Consumer functions can subscribe to the repository and be notified of NF template creation, deletion, modification.

[0214] It can be envisaged that if the initiator (of registration / discovery / subscription) is the SCS / AS, the initiator will send the request to the SCEF which will act as the consumer NF.

[0215] Network Function Repository

[0216] NFR is a database or list of NFs in a given slice. Typically, there may be an NFR associated with each slice. Alternatively, NFRs may reside in the underlying network and may be shared across network slices. When NFRs are shared across network slices, the NFRs contain a list of NFs instantiated in each network slice. NFRs can be queried or indexed based on the network slice ID. When queried, the NFR may provide a list of NFs instantiated in the slice and information about how each NF is configured, including information about the template associated with the instance. In addition, the NFR will provide an identifier that can be used to contact each NF. The identifier may be an NF identifier. NFR supports the following processes:

[0217] (i) Core NF Registration: When a new NF is deployed in the control plane, the profile information of the NF is received and maintained.

[0218] (ii) Core NF Discovery: A generic method for discovering and accessing NF instances.

[0219] (iii) Registration and discovery of non-core NFs.

[0220] (iv) Consumer NF subscription / notification: Consumer NFs can subscribe to the repository and be notified of NF creation, deletion, modification and state changes affecting instantiations, e.g., start / stop of a provider NF.

[0221] (v) Status monitoring: NF status (eg, started / stopped) is reflected in the NFR.

[0222] NFR and NFTR exposure

[0223] In an embodiment, it is envisioned that the MCN exposes the ability to instantiate NFs. NFs can be categorized as "value-added" or "core", "functionality" or "service", and "template" or "instantiation". These terms are described in more detail below:

[0224] Value Added and Core Functions: Core functions are those defined by 3GPP. Value Added Functions are those provided by the MNO and are not strictly required to provide connectivity. It is envisaged in this application that Value Added and Core Functions are interchangeable. It is assumed that methods such as access control, storage isolation, etc. can be used to achieve the necessary privacy / security. Exposure methods are considered in a unified manner.

[0225] Function and Service: A function can be the smallest unit instantiated in a network. A service is a function provided to an end user by instantiating one or more functions. As mentioned above, existing work provides descriptors for function instantiation at the network function (VNFD) level and the network service (NSD) level. NS is defined as the composition of NF. In this application, NS and NF are used interchangeably. For example, the term NFR refers to a repository of both functions and services. Similarly, the term NFT refers to a template that describes a function, service, or network slice. The difference lies in the order of magnitude of the complexity of the function composition. That is, it can span from simple functions and composite services to complex slices, and use the same approach.

[0226] Templates and instantiation: Templates describe how to create an NF, slice or service. Templates can be provided to the hypervisor so that NFs, slices or services can be created. The created NFs, slices or services are instantiations. Templates can in turn be in "abstract" or "deployable" formats. The deployable format can be a standardized form that allows instantiation in an NFV system, for example, a template defined by an ETSI NFVD descriptor. An abstract format can be a format that is used only for a specific domain, and in which abstract information should be encapsulated within the domain. There may be other standardized templates with higher levels of abstraction, or they may be MNO defined. The abstract format will be converted within the CN using domain policies and settings before being consumed by the CN MANO. According to the template description in this article, new parameters are provided at the abstract level, while combining existing formats (e.g., ETSI) provided at a more detailed deployable level.

[0227] According to an embodiment, NFTR provides management of NF templates. SCEF exposes CN APIs that allow third-party services to access and determine which NFs can be instantiated and how the NFs can be configured. SCEF also exposes CN APIs that allow third-party services to determine which NFs are available in a slice. These APIs can also be used to obtain identifiers of available NFs. The identifiers can then be used to query the NFs and access their functions. Third-party services can access NFs via core network APIs exposed by NFR / NFTR or by SCEF. For example, a third-party service can query the NFR to obtain an identifier of the mobility management NF. The query can also inquire which mobility management function is serving a specific UE. The third-party service can receive a mobility management NF identifier in response to the query, and then use the identifier to address the mobility management NF and query the location of the UE. The query of the mobility management NF can be performed via the SCEF or by directly addressing the NFR.

[0228] It is envisaged that this functionality allows exposure of NFR and NFTR repositories to the Value Added and OTT domains. The exposure is provided via a core network API that enables the AS and UE to provide the network with the information required to configure CN functions including VA-NF and OTT-NF.

[0229] Table 3 shown below introduces the NF template. In addition to the parameters required by MANO for function instantiation (e.g., ETSI NS template), additional parameters are proposed. These parameters are necessary within the MCN to enable the provision of specialized services, such as location-specific instantiation, charging, F-pooling, service constraints and policy application, etc.

[0230]

[0231]

[0232]

[0233] Table 3 NFR and NFTR Exposure API

[0234] According to another embodiment, the SCEF may expose APIs that allow third parties to access the functionality of the NFR and NFTR. Alternatively, these APIs may be exposed directly to third-party servers and other NFs. It is contemplated that these methods may be exposed to external entities and used to instantiate NFs to provide services to (one or more) UEs. The corresponding APIs may be available to the SCS / AS or may be used by the UE's OS and / or modem platform to make network configuration requests.

[0235] Table 4 shown below lists the APIs that may be exposed by the SCEF to allow access to the functionality of the NFR and NFTR.

[0236]

[0237] Table 4

[0238] Registration API

[0239] In one aspect of the present application, a registration API is used to add an NFT to a NFTR or to add a NF to an NFR. An NFT can be added to an NFTR when an API caller wants to announce specific available functionality or services. An NF can be added to an NFR when an API caller wants to indicate that an NF has been instantiated or the configuration of an existing NF has changed. For example, when an SCS / AS initiates a request, the request is sent to the SCEF. The SCEF verifies the authority that submitted the request. If verified, the request continues as a consumer Core-NF. Alternatively, the request can come directly from another Core-NF.

[0240] In such Fig.11 In the exemplary embodiment shown in FIG. 1 , a process for registering a NF (at an NFR) or a NFT (at an NFTR) is disclosed. Each step is referenced by an alphanumeric label, such as a0, a1, etc. In one embodiment, i.e., process "a", the SCS / AS decides to submit a NF or NFT for registration (step a0). Next, the NF / NFT registration request is sent to the SCEF (step a1). The SCEF verifies that the SCS / AS is authorized to make such a request (accessing other MCN nodes as needed) (step a3). In the example shown in FIG. 1 , the SCS / AS determines whether the NF or NFT is registered with the SCEF. The SCS / AS determines whether the NF or NFT is registered with the SCEF. Fig.11 In an alternative embodiment shown as process 'b' in FIG. 1 , the template or function registration may be initiated by the Core-NF. For example, Core-NF internal processing leads to the decision to request the registration (step b0).

[0241] exist Fig.11 Following the above embodiments in, the following steps are considered common. Here, the role of the SCEF may be similar to that of any other Core-NF (such as, for example, SIMF) that may initiate the process. In step c1, the SCEF / Core-NF forwards the Registration Request. The Registration Request message may include the following parameters that have been received by the SCEF from the SCS / AS or have been generated by the Core-NF. These parameters (e.g., inputs) include:

[0242] 1. Requester credentials: Enable authorization and authentication, as well as signing for NSD / VNFD.

[0243] 2. Template Description: Provided in Table 3 above.

[0244] In NF registration, a template provides a description of functionality that can be instantiated. Depending on local policies, NF registration that provides a template that is not part of the NFTR may result in parallel NFT registration. According to step c2, the NF or NFT to be registered uses the services of other NFs (such as, for example, SIMF and PMF) for verification. PMF can verify the request against other existing policies. PMF also registers new NF / NFT policies. SIMF can provide current slice instance status information that helps in verification.

[0245] Next, in step c3, the NFR / NFTR proceeds with the registration. In other words, the function / template is added to the repository. An identifier (NF-Regld or NFT-Regld) is generated to identify the entity within the registry. Thereafter, the NFR / NFTR sends a registration response to the SCEF / Core-NF, including the outputs of the registration process (step c4). These outputs may include, but are not limited to: (i) a newly generated entity identifier, e.g., NF-Regld or NFT-Regld; and (ii) a success or failure indicator.

[0246] In another embodiment of this aspect, another step of process 'a' is envisaged. Specifically, in step a3, if the request originates from the SCS / AS, the SCEF forwards the registration response and outputs it to the initiator.

[0247] Discovery and Subscription / Notification APIs

[0248] According to another aspect of the present application, a discovery API may be used to allow an initiator to search for available NFs in a slice and available NFTs that can be instantiated in a slice. This may be due to matching search criteria. In this regard, the terms subscription and notification may be used interchangeably.

[0249] The API is used to allow the initiator to be notified of available NFs or NFTs in a slice based on matching criteria. In addition to providing the matching criteria, the subscriber can also provide a description of the events to be notified, for example, when the state of the NF changes. This is done in Fig.12 The steps are referenced by alphanumeric labels, such as a0, a1, etc. Fig.12 Depicts the commonalities and differences in the steps to be performed. The process is applicable to both NFR and NFTR. When the SCS / AS initiates a request, the request is sent to the SCEF, which verifies the authority submitting the request. If verified, the request proceeds as a consumer Core-NF. Alternatively, the request can come directly from another consumer Core-NF or from the UE.

[0250] Fig.12Two embodiments of the initial trigger and setup phases are illustrated. Embodiment "a" describes that the SCS / AS initiates discovery or subscription / notification at the NFR or NFTR according to the following steps.

[0251] Step a0: The SCS / AS decides to submit a request for discovery or subscription / notification at the NF or NFT. This enables the SCS / AS to obtain information about the functions that are instantiated or available for instantiation in the slice.

[0252] Step a1: Send NF / NFT Discovery / Subscription request to SCEF. It includes matching parameters to be used as search criteria or trigger notification events.

[0253] Step a2: The SCEF verifies that the SCS / AS is authorized to make such a request (accessing other MCN nodes as needed).

[0254] On the other hand, embodiment "b" describes a Core-NF entity that initiates discovery or subscription / notification at an NFR or NFTR according to the following steps.

[0255] Step b0: Core-NF internally processes the decision leading to the submission of a request for discovery or subscription / notification at the NF or NFT. This enables the Core-NF to obtain information about the functions that are instantiated or available for instantiation in the slice.

[0256] exist Fig.12 Following the above embodiments in , the following steps are considered common to both and are denoted as "c". During this time, the role of the SCEF is similar to that of any other Core-NF that may initiate the process. According to step c1, the SCEF / Core-NF forwards the request to the NFR / NFTR. It is conceivable that the request may be forwarded by another entity (such as, for example, a SIMF). The request message may include the following parameters that have been received by the SCEF from the SCS / AS or have been generated by the Core-NF and represent the input of the process:

[0257] Requester Credentials: Enables authorization and authentication, as well as signing for NSD / VNFD.

[0258] Template description or reference to a template description in NFTR, which is shown in Table 3.

[0259] NFT Pool: represents a specific NFT pool to perform discovery in or to subscribe to. NFT pools are logical groupings of templates and can be specified as part of match parameters or used alone to restrict search targets, for access control, etc.

[0260] Criteria: Includes a series of parameters to be matched for discovery or for generating notifications, e.g., NF or NFT characteristics. Criteria may also indicate: physical location (where the NF or NFT is constrained to be instantiated), state or slice information, etc.

[0261] Return Format: Indicates what information should be included in the discovery response (e.g., no software images returned) and in what format (e.g., ID only, full description, etc.). This enables the discovery request to format the response and can be used to query only specific information.

[0262] Notification Event: describes the event for which a notification is generated (only applicable to Subscribe / Notify), for example, NFT update, NF start / stop, etc.

[0263] The callback reference ID. This value is provided to the subscriber when a subscription event occurs, allowing the subscriber to associate the event with the request.

[0264] After step c1, the discovery of matching criteria provided in the request is used to search within the NFR / NFTR (step c2). For subscription / notification, the request information is used to create a subscription based on a given event matching the given criteria or being triggered. Next, the NFR / NFTR sends a registration response to the SCEF / Core-NF and includes the output of the discovery / subscription process, including but not limited to: (i) a success or failure indicator; (ii) (one or more) NF instance identifiers: NF instance identifiers that match the discovery criteria (e.g., NF-Regld); and (iii) (one or more) NFT instance identifiers: NFT identifiers that match the discovery criteria (e.g., NFT-Regld) (step c3).

[0265] In another embodiment of embodiment "a", if the request originates from SCA / AS, the SCEF forwards the response and outputs it to the initiator (step a'3)

[0266] NF instantiation request API

[0267] According to another aspect of the present application, a NF instantiation process and architecture are described. NF instantiation provides the ability to instantiate (i.e., generate) a NF and expose the functionality to entities such as SCS / AS. In one embodiment "a", as Fig.13 As shown, the request for NF instantiation is initiated by the SCS / AS and sent to the SCEF (step a0-2). In alternative embodiment "b", NF instantiation is performed by the Core-NF (step b0). Each step is represented by an alphanumeric label, such as a0, a1, etc. Fig.13 After the above steps in , the following steps are considered to be common to both embodiments "a" and "b".

[0268] According to step c1, the SCEF / Core-NF forwards the registration request to the NFR / NFTR. It is conceivable that in different implementations, the request may be forwarded via other entities (e.g., SIMF). The registration request message may include one or more of the following parameters, which have been received by the SCEF from the SCS / AS or have been generated by the Core-NF. These parameters represent the inputs to the process and include the following:

[0269] Requester Credentials: Enables authorization and authentication, as well as signing for NSD / VNFD.

[0270] Requester access control information: If the requester is allowed to instantiate NF with multiple roles (e.g., Administrator, UserX, etc.), it indicates the role with which this particular instantiation was created.

[0271] Template description (or reference to template description): A reference can be provided using the NF-Regld or NFT-Regld of a registered NF / NFT.

[0272] Instance location: Identifies a preferred location for instantiation. An instance location can be generic (e.g., CN0, specific slice ID(s)), or specific (e.g., physical location).

[0273] NF Pool: An indicator of the NF pool that this instance is a part of. A NF pool is a logical grouping of instances, e.g., NFs in the same NF pool can be used interchangeably for load balancing purposes.

[0274] Function descriptor: Indicates the type of functionality to be provided by the requested NF (e.g., caching, parental control, etc.). Can be used, for example, to determine whether several NFs can be instantiated for this purpose, leaving further selection decisions to the MCN.

[0275] Network service style descriptor: Indicates the NFV style, e.g., the number of instances of each constituent VNF, “affinity” rules about keeping VMs and hosts together, etc.

[0276] Instance policy constraint: If multiple policies are allowed in the template, indicates which policy should be used for this instance. For example, if the template allows a large maximum number of instances, this request can constrain the current instantiation to scale up to a lower maximum number of instances.

[0277] Instance Charging Information: If the "Instantiated Charging Information" in the template allows different types of charging, this attribute indicates which type of charging should be applied in this instance, for example, charging per UE only, charging per resource used, charging per NF instance, etc. The NF instance then generates (or provides configuration for) the relevant charging events; the charging records are forwarded to the CN for accounting and billing.

[0278] Example SFC Information: Provides linking information, such as recommended or mandatory links via a list of applicable service function chains (including their structure).

[0279] Instance Service Entity: Indicates constraints related to entities that are allowed to use the service. For example, it may contain a list of UEs for which the NF should be instantiated, or a list of other SCS / AS that may be allowed to use the instantiation.

[0280] Instance service constraints: Indicates the constraints to use when determining the instantiation level. For example, it may contain acceptable latency information that the MCN can use to determine unspecified resource levels.

[0281] Instantiation workflow: Indicates the rules for instantiating this NF, e.g. based on future slice conditions, based on relocation of the served UE, etc. For example, it may provide parameters for moving a cache service to a specific area close to the UE as the UE moves without action from the SCS / AS. In other examples, automatic periodic scaling of resources may be indicated without involving the SCS / AS.

[0282] According to step c2, the NF to be instantiated uses the services of other NFs such as SIMF and PMF for verification. For example, if NF-Regld is provided, SIMF verifies that the function is allowed to be instantiated based on the current slice state. If SIMF verifies the existence of a given template and its consistency with the policy and requests PMF can check the request against other existing policies. SIMF can provide current slice instance status information that helps with verification.

[0283] According to step c3, the relevant CN entity (e.g., SIMF) performs instantiation by calling the MANO function of the MCN slice. If the instantiation is performed based on a template, the registration of the first instance of the template can be performed by the SIMF on behalf of the initiator, and if the function is already part of the NFR, the change of state can be performed instead.

[0284] According to step c4, SFMF sends an instantiation response to SCEF / Core-NF. The response includes the output of the instantiation process, such as: (i) success or failure indicator; (ii) the actual instantiation parameters of the instantiated NF, and when the allowed range is requested; and (iii) the actual / exact location of the NF instantiation.

[0285] According to another embodiment, after step a2, if the request originates from the SCS / AS, the SCEF forwards the instantiation response and outputs it to the initiator (step a'3).

[0286] NF instance management

[0287] In yet another aspect of the present application, NF instance management exposes the ability to change / manage NF instances instantiated in the MCN. Fig.14 The diagram illustrates a general flow that can be applied to individual processes such as instance reconfiguration, termination, scaling, etc. Individual information related to each process is provided below. As shown in the diagram, the steps are represented by alphanumeric labels, such as a0, a1, etc.

[0288] exist Fig.14 In one embodiment of "embodiment a", the request for NF instantiation can be initiated by the SCS / AS and sent to the SCEF. In step a0, the SCS / AS decides to perform the NF process for management or maintenance. Next, the SCS / AS sends the NF process request to the Core-NF (step a1). Next, the Core-NF verifies the authorization of the SCS / AS (step a2). In an alternative embodiment, the request for NF instantiation can be initiated by the Core-NF (embodiment "b").

[0289] Steps beginning with the letter "c" are for Fig.14 The above embodiments shown in are common. Specifically, in step c1, the SCEF / Core-NF forwards the request to the SIMF. It is conceivable that the request can be forwarded via other entities (e.g., NFR / NFTR). The request parameters as input to the process are detailed below based on the process type. In step c2, the NF to be managed is verified using the services of other NFs such as SIMF and PMF. This step is optional. Next in step c3, the relevant CN entity, for example, SIMF, performs management by calling other MCN slice functions (such as MANO). In step c4, SFMF sends a response to the SCEF / Core-NF, including the output of the process.

[0290] According to another embodiment, if the request originates from the SCS / AS, the SCEF forwards the response and outputs it to the initiator (step a'3).

[0291] NF instance reconfiguration API

[0292] According to another aspect of the present application, the NF instance reconfiguration process can be used to change the instance, for example, location, instantiation style, etc., and use Fig.14 The general process shown in . It can also be used to change the state as described above in this application. As shown in the figure, these steps are represented by alphanumeric labels, such as a0, a1, etc.

[0293] In an embodiment, the reconfiguration request message (steps a1, c1) may include the following input parameters, which have been received by the SCEF from the SCS / AS or alternatively generated by the Core-NF:

[0294] Requester Credentials: Enables authorization and authentication, as well as signing for NSD / VNFD.

[0295] Example: A reference can be provided using NF-Regld. A Reconfiguration Ref-Id can also be provided, in which case this is a rollback of a previous process.

[0296] Reconfigured Location: Specifies the new location for instantiation.

[0297] Reconfigured NF Pool: Specifies the new NF pool that the NF will be a part of.

[0298] Reconfigured service style descriptor: indicates the new / modified NFV style.

[0299] Reconfigured Policy Constraint: Indicates the new / reconfigured policy to be used for this instance.

[0300] Reconfigured Billing Information: Indicates the new / reconfigured billing information to be used for the instance.

[0301] Reconfigured SFC information: Indicates new / reconfigured link information.

[0302] Reconfigured Service Constraints: Indicates new / reconfigured constraints associated with the entities that are allowed to use this service.

[0303] Backup configuration: Indicates whether and which feature information should be preserved for possible future rollback.

[0304] Reconfigured Instantiation Workflow: Indicates new / reconfigured rules for automatically instantiating this NF.

[0305] Reconfiguration Ref-Id: Provides a process instance reference for possible rollback.

[0306] New Configuration Reference(s): Provides new Reference ID(s) for the new configuration, e.g., a new NF-Regld.

[0307] In an embodiment, step c3 reflects the actual reconfiguration of the instance by SIMF using other slicing functions (eg, MANO).

[0308] The reconfiguration response message (steps c4, a'4) may include the following output parameters: (i) a success or failure indicator; (ii) the actual parameters of the NF instance after the process when an allowed scope is requested; (iii) the actual / exact location of the NF instantiation; and (iv) the returned new configuration reference, particularly for rollback.

[0309] NF instance termination request API

[0310] According to another aspect of the present application, an NF instance termination process can be used to remove instances from a slice. Fig.14 An exemplary illustration of a general process is provided in . As shown in the figure, the steps are represented by alphanumeric labels, for example, a0, a1, etc.

[0311] In an embodiment, the Termination Request message (steps a1, c1) may include the following input parameters, which have been received by the SCEF from the SCS / AS (or have been generated by the Core-NF):

[0312] Requester Credentials: Enables authorization and authentication, as well as signing for NSD / VNFD.

[0313] Example: References can be provided using NF-Regld.

[0314] Location: Identifies the location of the function to be terminated, for use with other identifiers (e.g., NF type). The location can be specified in a generic way (e.g., CN, slice ID), or as a physical location, etc.

[0315] NF Type: Specifies the type of function to be terminated.

[0316] NF Pool: Instead of providing a specific function identifier or descriptor, the request may indicate any instance in the pool that may be terminated.

[0317] Termination Workflow: Indicates the rule to be used to automatically terminate the NF.

[0318] In an embodiment, step c3 reflects the actual termination of the instance by the SIMF using other slicing functions (e.g., MANO). Depending on the implementation, it may involve a state change in the NFR or a NF deregistration from the NFR.

[0319] In another embodiment, the termination response message (step c4, a'4) may include the following output parameters: (i) a success or failure indicator.

[0320] NF instance scaling request API

[0321] According to another aspect of the present application, the NF instance scaling process can be used to scale instances in a slice. Fig.14 As shown in the figure, these steps are represented by alphanumeric labels, for example, a0, a1, etc.

[0322] A scaling operation may be similar to a reconfiguration in the sense that different instantiation parameters will be used. However, a scaling request may result in a change in resource allocation in the system or more / fewer components NF being instantiated.

[0323] The instance scaling request message (steps a1, c1) may include the following input parameters, which have been received by the SCEF from the SCS / AS (or have been generated by the Core-NF):

[0324] Requester Credentials: Enables authorization and authentication, as well as signing of NSD / V FD.

[0325] Scaling example: A reference can be provided, for example, using NF-Regld.

[0326] Location: Identifies the location of the function to be scaled, for use with other identifiers (e.g., NF type). The location can be specified in a generic way (e.g., CN, slice ID), or as a physical location, etc.

[0327] NF Type: Specifies the type of function to scale, for example, core.

[0328] NF Pool: This request may indicate that any instance in the pool may be scaled up / down, rather than providing a specific function.

[0329] New scaling parameters: Parameters indicating the new scaling level, for example, NsScalingAspect, NsInstantiationLevel, VnfToLevelMapping, NsToLevelMapping.

[0330] Scaling Workflow: Indicates the rules used to automatically scale NFs.

[0331] In another embodiment, step c3 uses other slicing functions (eg, MANO) to reflect the actual scaling of the instances by the SIMF. Depending on the implementation, it may involve changes in the NFR.

[0332] In another embodiment of this aspect, the instance scaling response message (steps c4, a'4) may include the following output parameters: (i) a success or failure indicator; (ii) actual scaling parameters: information about the achieved zoom level; (iii) additional scaling information: if the scaling results in the creation of an additional component NF, the id and related information may be provided to the requester.

[0333] NF instance status change API

[0334] According to another aspect of the present application, the NF instance state change API can be used to change the NF state. An exemplary diagram of this aspect is shown together with the general process in Fig.14 Shown in.

[0335] In an embodiment, the NF instance state change request message (steps a1, c1) may include the following input parameters, which have been received by the SCEF from the SCS / AS (or have been generated by the Core-NF):

[0336] Requester Credentials: Enables authorization and authentication, as well as signing for NSD / VNFD.

[0337] Example: A reference may be provided, for example, using NF-Regld.

[0338] Location: Identifies the location of the function to be started / stopped / reset, for use with other identifiers, e.g., NF type. The location can be specified in a generic way (e.g., CN, slice ID), or as a physical location, etc.

[0339] NF Type: Specifies the type of function to start / stop / reset, for example, core.

[0340] NF Pool: This request may indicate that any instance in the pool may be started / stopped / reset, rather than providing a specific function.

[0341] State Change Workflow: Indicates the rules used to automatically change states

[0342] In another embodiment, step c3 uses other slice functions (eg, MANO) to reflect the actual state change of the SIMF to the instance. Depending on the implementation, it may involve changes to the NFR.

[0343] The instance state change response message (steps c4, a'4) may include the following output parameters: (i) a success or failure indicator.

[0344] Exposing APIs on UE

[0345] According to another aspect of the present application, it is described that the information required to determine how to best scale, configure or instantiate a network function can be obtained at the UE. This information enables instantiation of network functions based on service requirements at the UE, for example, when downloading a virus scanning NF is required. In addition to UE service requirements, UE states and actions may be most relevant to triggering processes such as those described above.

[0346] In an embodiment, the service instantiation method may be exposed to the UE using the same SCEF entity or through a separate dedicated service exposure entity for the UE. It is conceivable to use the same SCEF exposure entity. Fig.15 An exemplary embodiment is illustrated in which the above-described embodiment is shown in more detail. As shown, the steps are represented by alphanumeric labels, such as a0, a1, etc.

[0347] In one embodiment, the UE initiates and the SCS / AS is managed. Fig.15 ” is shown as “Alt x” in the figure. In this embodiment, the UE initiates the process by sending a request to the SCEF, which is forwarded to the SCS / AS. The SCS / AS acts on behalf of the UE by calling the instantiated API introduced previously. The SCS / AS can also act on behalf of the UE based on a direct request from the UE on the data or user plane.

[0348] According to step x1, the UE sends a NF procedure request to the SCEF. It can be assumed that the "NF procedure" message is abstract and can be instantiated as any message introduced in this application. The request may be:

[0349] NF / NFT Registration

[0350] NF / NFT Discovery

[0351] NF / NFT Subscription / Notification

[0352] NF Instantiation

[0353] NF instance reconfiguration

[0354] NF instance termination

[0355] NF instance scaling

[0356] NF instance status changes

[0357] In addition to the corresponding request parameters introduced above in this application, the request from the UE may include:

[0358] UE credentials: enable authorization and authentication, and signature of the requested NF.

[0359] Delegation Flag: The UE may indicate itself that it wishes to delegate the procedure to the SCS / AS (alternative x) or to manage it itself (alternative y), or the decision may be subject to implementation and local SCEF policy.

[0360] Related SCS / AS: If several choices of SCS / AS are possible, the UE can indicate which SCS / AS should be used. The choice can be indicated with the SCS identifier or by providing characteristics (e.g., "SCS / AS for multimedia applications").

[0361] NF procedure requests may also allow requests based on abstract NF / NFT descriptions as described above. The UE makes an abstract request for a cache which is then converted into an instantiated request for a specific NF based on other criteria such as UE location.

[0362] According to step x2, the SCEF determines the relevant SCS / AS to which to forward the request. The decision to forward can be based on local policy or on the content of the request message, i.e., the UE can specifically request the SCS / AS management process. The selection of the SCS / AS can also be made by the UE or the SCEF based on the received information and local policy.

[0363] According to step x3, the SCEF forwards the request to the SCS / AS. It is envisaged in the present application that steps x1, x2 and x3 can also be implemented by the UE sending a direct request to the SCS / AS. This can be done using either the control plane or the user plane. It is also envisaged in the present application that the UE to SCS / AS request can be abstract (e.g., "request for cache") or detailed (e.g., "request to instantiate NF-Regld 123").

[0364] According to step x4, the SCS / AS decides to request the execution of the NF process on behalf of the UE.

[0365] According to step x5, the SCS / AS uses the information provided in the initial request as well as locally available information to provide the required information in the NF Procedure Request message and sends it to the SCEF. For example, if the UE request only includes acceptable latency, the SCS / AS may be able to calculate the specific location for requesting NF instantiation.

[0366] According to step x6, the SCEF verifies that the SCS / AS is authorized to make such a request (accessing other MCN nodes as required). It is envisaged that the authorization may be performed using the SCS / AS credentials, the UE credentials, or both.

[0367] In an alternative embodiment, the UE initiates and the UE is managed. Fig.15In this embodiment, the UE initiates the process by sending a request to the SCEF. After authorization, the service instantiation process is performed within the MCN and the UE receives a response to its request. The SCS / AS may be notified of the process instantiation and / or completion.

[0368] According to step y1, the UE sends a NF Procedure Request to the SCEF. As in step x1, the "NF Procedure" message shown is abstract and can be instantiated as any of the messages introduced above and can contain any additional parameters indicated above.

[0369] According to step y2, the SCEF verifies that the UE is authorized to make such a request (accessing other MCN nodes as needed). In step y3 (optional), the SCEF notifies the relevant (one or more) SCS / AS about the triggering of the procedure (e.g., those SCS / AS included in the relevant SCS / AS parameters, or those SCS / AS that are allowed to access the instantiation request in the entity constraints of the instance service).

[0370] like Fig.15 As shown, the common phrases identified by the tags starting with 'c' are common to the embodiments discussed above. The overall functionality is included in the propagation of requests within the MCN slice, performing the service instantiation process and receiving the corresponding response by the SCEF.

[0371] In another embodiment, it is proposed that after the SCEF receives the procedure response (alt x), the SCEF forwards the procedure response to it (step x'7). Local processing may ensue, for example, the SCS / AS may make changes to the services provided to the UE based on the NF procedures performed. Next, the SCS / AS forwards the procedure response to the originating UE, indicating all or some of the response information received (step x'8).

[0372] In yet another embodiment, regarding 'alt y', the SCEF provides an indication to the relevant SCS / AS that the procedure has been completed (y'4). Local processing may be performed, for example, (one or more) SCS / AS may change the service provided to the UE based on the NF procedure performed. In addition, the SCEF may forward the procedure response to the originating UE, indicating all or some of the response information received (y'5). Depending on the implementation, the system may allow one or both options. The decision to forward the request in step x2 may be based on the UE request, local SCEF policy, or both.

[0373] According to another aspect of the present application, a graphical user interface (GUI) supporting the above functions is described. The GUI can be implemented at the core network, a third-party application server (SCS / AS), or a UE. Figure 8C and 8D Described in Fig.16 Further shown in . Fig.16 An exemplary deployment with four GUIs - 610, 615, 620 and 630 is shown. Underlined text refers to parameters belonging to the NFT created by the MCN GUI in 'A'. (GUI 610). Italic text refers to parameters provided with the request for NF process 'B' (GUI 615). Other italic text refers to instantiation parameters provided by the SCS / AS.

[0374] Within the core network, a GUI may be implemented to provide direct access to the NFTR and introduce new templates into the system. The GUI may be used to perform one or more functions. One function may include providing a complete / deployable NFT to the system. This may be a single function or service used to instantiate one or more functions. For the core network, this is specified by the 'A' of 1610. Another function may include providing an abstract NFT to the system by allowing parameter input that is converted internally to an NFT format. Yet another function may include displaying existing / available NFTs in the system. Another function may include querying the system for a specific NFT.

[0375] According to Fig.16 Another embodiment shown may implement another core network GUI for the core network to allow instantiation and management of NFs in the system. The GUI may be used to perform one or more functions. One function may include providing the system with configuration (deployable or abstract) of a specific NF instantiation or process. This is designated as "B" associated with the GUI 1615 of the core network. Another function may include providing the system with a trigger to start the NF process. This is also shown with "B". Yet another function may include providing the system with a workflow for automatically instantiating the NF process based on changing states and parameters. Another function may include displaying existing / available NFs in the system, monitoring them and / or related events. Another function may include querying a specific NFT in the system.

[0376] According to Fig.16Another embodiment shown may provide (one or more) GUIs 1620'C to a third-party application server (SCS / AS) that may be used to perform one or more functions. As shown in the italic text, a scaling request is performed. The scaling parameters are indicated with a percentage sign, such as 150%. This will be converted in the italic NsScalingAspect parameter to provide for execution during the process. One function may include providing a complete / deployable or abstract NFT to the system. Another function may include providing the system with a configuration (deployable or abstract) for a specific NF instantiation or process. Another function may include providing the system with a trigger for requesting an NF process. Yet another function may include providing the system with a workflow for automatically triggering a NF process based on changing states and parameters. However, yet another function may include querying the system for existing / available NFs, monitoring them and / or related events. Another function may include displaying notifications of related events.

[0377] In yet another embodiment, Fig.16 A UE with (one or more) GUIs 1630 "D" is depicted in the view of , which can be used to perform one or more functions. In GUI 1630, service constraint parameters (e.g., "SMS delay") will be converted by the system for execution. One function may include providing a complete / deployable or abstract NFT to the system. Another function may include providing the system with a configuration (deployable or abstract) of a specific NF instantiation or process. Yet another function may include providing the system with a trigger for requesting a NF process. Another function may include providing the system with a workflow for automatically triggering NF processes based on changing states and parameters. Yet another function may include querying the system for existing / available NFs, monitoring them and / or related events. However, yet another function may include displaying notifications of related events.

[0378] According to the present application, it should be understood that any or all systems, methods and processes described herein can 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 machine such as a computer, a server, an M2M terminal device, an M2M gateway device, a switching device, etc., executes and / or implements the systems, methods and processes described herein. Specifically, any of the above steps, operations or functions can be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing 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, cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other physical media that can be used to store desired information and can be accessed by a computer.

[0379] According to another aspect of the present application, a non-transitory computer-readable or executable storage medium for storing computer-readable or executable instructions is disclosed. The medium may include one or more computer-executable instructions, such as the above-mentioned Figure 11-15 The computer executable instructions may be stored in a memory and executed by a processor, as described above in Figure 8C and Fig.8D and adopted in devices including UE, SCS and AS.

[0380] Although the systems and methods have been described in terms of what are presently considered to be specific aspects, the present application is not necessarily limited to the disclosed aspects. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims, the scope of which should be given the broadest interpretation to encompass all such modifications and similar structures. The present disclosure includes any and all aspects of the following claims.

Claims

1. A device for instantiating a network function, comprising: a non-volatile memory having instructions stored thereon; and A processor operably coupled to the non-transitory memory, the processor being configured to execute the following instructions: receiving a message for service instantiation, wherein one or more parameters in the message include a location of the service instantiation and a functional description of a network function providing the service; determining a requirement for instantiation of a network function based on the one or more parameters in the received message; Sending to a slice instance management function a request for instantiation of a network function including the location where the service is instantiated; as well as Receive a response from the slice instance management function indicating whether the network function can be instantiated. 2 . The apparatus of claim 1 , wherein the sent instantiation request comprises any one or more of a template description, an instance location, or an instance service constraint.

3. The device of claim 1, wherein The received message for service instantiation originates from a node located outside the core network, and The processor is further configured to execute instructions to send a response to the node indicating whether the network function can be instantiated.

4. The device according to claim 3, wherein: The node is a service capability server, an application server, or a wireless transmit / receive unit (WTRU).

5. The device according to claim 2, wherein: The instantiation request sent also includes any one or more of requester access control information, network function pool, function descriptor, network service style descriptor, instance policy constraint, instance billing information, instance service function link information, instance service entity or instantiation workflow.

6. The apparatus of claim 1, wherein the processor is further configured to execute the following instructions: Receive a reconfiguration request for an instantiation.

7. The device according to claim 6, wherein: The reconfiguration request includes any one or more of a workflow, an instance, a reconfigured location, a reconfigured network function pool, a reconfigured service style descriptor, a reconfigured policy constraint, a reconfigured billing information, a reconfigured service function link information, a reconfigured service constraint, a backup configuration, a reconfigured instantiated workflow, a reconfiguration reference identifier, or a new configuration reference.

8. The apparatus of claim 6, wherein the processor is further configured to execute the following instructions: Sending a request to the slice instance management function to perform a reconfiguration of the instantiation; and Receive a response from the slice instance management function whether reconfiguration of the instantiation can be performed.

9. The apparatus of claim 1, wherein the received response comprises any one or more of instantiation parameters of the network function, a location of the network function, or a registry identifier of the network function.

10. The apparatus of claim 1, wherein the processor is further configured to execute the following instructions: Receiving a termination request based on the instantiation; and Determines the termination of execution instantiation.

11. A method for instantiating a network function, comprising: receiving a message for service instantiation, wherein one or more parameters in the message include a location of the service instantiation and a functional description of a network function providing the service; determining a requirement for instantiation of a network function based on the one or more parameters in the received message; Sending to a slice instance management function a request for instantiation of a network function including the location where the service is instantiated; as well as Receive a response from the slice instance management function indicating whether the network function can be instantiated.

12. The method of claim 11, wherein the sent instantiation request includes any one or more of a template description, an instance location, or an instance service constraint.

13. The method of claim 11, wherein: The received message for service instantiation originates from a node located outside the core network, and Also included is sending a response to the node indicating whether the network function can be instantiated.

14. The method of claim 13, wherein: The node is a service capability server, an application server, or a wireless transmit / receive unit (WTRU).

15. The method of claim 12, wherein: The instantiation request sent also includes any one or more of requester access control information, network function pool, function descriptor, network service style descriptor, instance policy constraint, instance billing information, instance service function link information, instance service entity or instantiation workflow.

16. The method of claim 11, further comprising: Receive a reconfiguration request for an instantiation, The reconfiguration request includes any one or more of a workflow, an instance, a reconfigured location, a reconfigured network function pool, a reconfigured service style descriptor, a reconfigured policy constraint, a reconfigured billing information, a reconfigured service function link information, a reconfigured service constraint, a backup configuration, a reconfigured instantiated workflow, a reconfiguration reference identifier, or a new configuration reference.

17. The method of claim 16, further comprising: Sending a request to the slice instance management function to perform a reconfiguration of the instantiation; and Receive a response from the slice instance management function whether reconfiguration of the instantiation can be performed.

18. The method of claim 11, wherein the received response includes any one or more of instantiation parameters of the network function, a location of the network function, or a registry identifier of the network function.

19. A non-transitory computer readable medium comprising program instructions which, when executed by a processor, implement: receiving a message for service instantiation, wherein one or more parameters in the message include a location of the service instantiation and a functional description of a network function providing the service; determining a requirement for instantiation of a network function based on the one or more parameters in the received message; Sending to a slice instance management function a request for instantiation of a network function including the location where the service is instantiated; as well as Receive a response from the slice instance management function indicating whether the network function can be instantiated.

20. The non-transitory computer readable medium of claim 19, wherein the sent instantiation request includes any one or more of a template description, an instance location, or an instance service constraint.

21. A wireless transmit / receive unit WTRU, comprising: a non-volatile memory having instructions stored thereon; and A processor operably coupled to the non-transitory memory, the processor being configured to execute the following instructions: sending a request to the first server to discover services, wherein the request includes discovery criteria; receiving a response from the first server indicating one or more services matching the discovery criteria that are available for instantiation; In view of the received response, sending a message for service instantiation to the second server to instantiate one of the available services; as well as receiving, from a second server, a communication that the available service has been instantiated in view of the message, The first server and the second server include at least one of a network function repository (NFR) or a network function template repository (NFTR).

22. A method for network function discovery and instantiation, comprising: sending a request to the first server to discover services, wherein the request includes discovery criteria; receiving a response from the first server indicating one or more services matching the discovery criteria that are available for instantiation; sending a message for service instantiation to a second server to instantiate one of the available services; as well as receiving a communication from a second server that the available service has been instantiated, The first server and the second server include at least one of a network function repository (NFR) or a network function template repository (NFTR).

Images