Connecting to a virtualized mobile core network

Abstract

To provide user equipment (UE) that interacts with an underlay network (ULN) and establishes connection to a virtual network slice.SOLUTION: As a procedure of establishing connection to a virtual network slice, a procedure of allocating a new slice instance to UE (UE-initiated and ULN-initiated), a procedure of changing an UE profile (UE initiated type and ULN initiated type), and a procedure of changing the assigned slice instance of UE (ULN initiated type) are defined.SELECTED DRAWING: Figure 22

Description

[Technical field]

[0001] (Citation of Related Application) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 335,511, filed May 12, 2016, the disclosure of which is incorporated herein by reference as if set forth in its entirety. [Background technology]

[0002] The term (S)Gi-LAN refers to a packet data network located between the GGSN or P-GW of a mobile core network and the Internet. The (S)Gi-LAN is under the control of a Mobile Network Operator (MNO). When uplink data packets exit the (S)Gi-LAN, they are no longer under the control of the MNO and can generally be considered to have gone to the public Internet. This is shown in Figure 1.

[0003] The (S)Gi-LAN may include Value Added Services (VAS) 2052. Examples of VAS 2052 are NAT, firewall, video compression, data compression, load balancer, HTTP header enhancement, TCP optimizer, etc. Generally, deep packet inspection (DPI) techniques determine whether each VAS 2052 should act on a data flow.

[0004] Traffic can be routed to / from the (S)Gi-LAN and servers in the public Internet such as M2M servers, which can also be deployed inside the (S)Gi-LAN by operators or service providers to provision a set of value-added services for M2M / IoT use cases.

[0005] The IETF has developed an architectural framework for efficient deployment of VAS or "service functions". The architectural framework is described in the IETF, Service Function Chaining Working Group, Internet Draft, Service Function Chaining (SFC) Architecture. The framework allows traffic to be "steered" through only the services that apply to each individual flow, rather than requiring that all traffic be routed sequentially through all service functions. The terms "service function" and "value-added service" can be used interchangeably.

[0006] Figure 2 shows a schematic diagram of the major components of the IETF's SFC architectural framework.

[0007] The Service Classification Function (SCF) receives an incoming packet. In a traditional (S)Gi-LAN, the incoming packet may be an IP packet from the P-GW / GGSN or the Internet. The SCF encapsulates the incoming packet with another header and may determine the service function through which the packet should be routed, the order in which the packet should be routed through the service functions, and may attach metadata to the packet to assist the service function.

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

[0009] The Network Service Header (NSH) was developed by the IETF's Service Function Chaining (SFC) Working Group and is defined in the IETF, Network Working Group, Internet-Draft, Network Service Header. The NSH contains metadata and service path information that is used by the service plane to steer traffic through network services.

[0010] Figure 3 shows where the NSH sits relative to the IP datagram.

[0011] The format of the NSH is shown in Figure 4. The base header contains the following: -Version field - The "C" bit indicates that important metadata is present in the network service header. - A length field indicating the total length of the NSH -Metadata type field indicating the format of the metadata - the following protocol fields indicating the format of the original payload:

[0012] The Service Path Header contains the following: - Service Path ID, a 24-bit field indicating the service path to be selected for the packet - A service index used to indicate the packet's location within the service path

[0013] All context headers can be in one of two formats, depending on how the metadata type field is set in the base header. All context header values ​​can be fixed length, or they can contain variable length values. For the case of variable length headers, the IETF, Network Working Group, Internet-Draft, Network Service Header describes how to format the metadata and indicate the length of each value in the context header.

[0014] When the metadata type field indicates that the metadata is variable length, it is formatted as shown in FIG.

[0015] The TLV class field describes the scope of the type field, in other words, it identifies the vendor or standards body that allocated the type field.

[0016] The type field indicates the type of information contained in the metadata. The MSB of the type field is used to indicate whether an entity is required to process the NSH to understand the metadata value.

[0017] The R bit is reserved for future use.

[0018] The Len field indicates the length of the metadata in 4-byte words.

[0019] Service-aware nodes are enabled 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, firewall, HTTP header enrichment, etc. can also inspect and modify IP, UDP / TCP / application data.

[0020] The 3GPP SA2 Working Group has a work item called Flexible Mobile Service Steering (FMSS). The objective of this work item is to define service requirements that will allow 3GPP Core Networks to define and modify traffic steering policies that will be used to select the required service enablers for operator-deployed (S)Gi-LANs. The goal is to achieve efficient and flexible service steering in (S)Gi-LANs.

[0021] The immediate output of this work item is captured in 3GPP TR 23.718, Architecture Enhancements for Flexible Mobile Service Steering.

[0022] Figure 6 is a representation of how the 3GPP architecture proposed in TR 23.718 would be applied to the architecture proposed by the IETF in the IETF,Service Function Chaining Working Group,Internet Draft,Service Function Chaining (SFC) Architecture. The green shaded boxes are standardized by 3GPP and owned by the MNO. The orange boxes are not standardized by 3GPP, but are typically deployed in (S)Gi-LANs and owned by the MNO.

[0023] IETF, Service Function Chaining Working Group, Internet Draft, Service Function Chaining (SFC) Architecture proposes an St reference point that allows the PCRF to provide traffic steering policy to the SCF in the (S)Gi-LAN. TR 23.718 also proposes that an Sd interface with the TDF can be used to provide traffic steering policy to the TDF. The TDF can then be used to apply packet marking (i.e., NSH) to the traffic based on detected applications, users, etc. TR 23.718 also proposes that the P-GW applies packet marking (i.e., NSH) based on the policy from the PCRF.

[0024] IT services can be deployed on varying operating environments (hardware platforms, operating systems, etc.). Message-based middleware provides a "messaging layer" between communicating services, thus abstracting the underlying operating environment in which each service runs. In other words, the "messaging layer" acts as an intermediary in exchanging messages between services.

[0025] Figure 7 shows a high-level representation of message-based middleware. In this example, four services communicate through a common middleware platform. Each service may run on a variety of different platforms (i.e., hardware platforms, operating systems, etc.). The middleware abstracts the underlying operating environment of each service so that they can communicate through some defined messaging protocol.

[0026] There are many well-known message-based middleware architectures. The following section will provide an overview of some of the main message-based middleware concepts and terminology.

[0027] The middleware layer can be based on the concept of message queues as shown in the example of Figure 8. In this example, there is a dedicated queue that can be used to send messages to Service 1. Services 2, 3, and 4 can submit messages to the Service 1 queue and the messages will be delivered to Service 1 in a first-in, first-out (FIFO) fashion.

[0028] Note that each service may communicate over a different transport layer protocol, the details of which are abstracted by the middleware.

[0029] A queue-based middleware architecture can take many different forms: there may be a single shared queue that is used to send messages to all services, there may be dedicated queues for each service to receive messages (as shown in Figure 8), there may be dedicated queues for each service to send messages, etc.

[0030] In the publish / subscribe model, messages are sent (published) to a destination in the middleware. The destination depends on the message "topic" (sometimes called a channel). A service that wants to receive messages related to a particular topic "subscribes" to the topic.

[0031] FIG. 9 shows an example of a publish / subscribe system. ● Services 1, 2, and 3 publish to Topic 1. ● Services 2 and 3 publish to topic 2. ● Service 1 subscribes to topics 1 and 2. ● Service 2 subscribes to Topic 2.

[0032] Topics can be based on any number of factors: Topics can be related to message types (debug, alarm, warning, task request, etc.).

[0033] The term message broker generally refers to an entity that receives all messages and distributes all messages, as shown in Figure 10. The broker may be implemented as a publish / subscribe architecture with several topics, etc., with several queues.

[0034] Messages sent to and from middleware brokers can be characterized in a number of different ways. There are four general types of messages: ● Non-acknowledgeable and non-blocking request messages - messages that are simply sent by a service to a broker. When a service sends a message to the broker, the service does not expect a reply and the service continues to run. Acknowledgeable and Blocking Request Messages - A blocking message is a message that will cause a service to pause (block) until it receives the message. For example, if a service tries to read a message from a broker or queue and the message is not ready, the execution of the service will block. ● Confirmable and Non-Blocking Messages - A non-blocking message is a message that will not cause a service to pause (block) until it is ready. For example, if a service attempts to read a message from a broker or queue and the message is not ready, the service's execution will continue until the message is ready. When a service attempts a non-blocking read, it can provide a callback function to the broker that can be called when the message is ready. ● Notification - A notification message is a message that the broker sends to a service as a result of some previous request, for example the previous request might have been a non-blocking read attempt or a subscribe request.

[0035] The Advanced Message Queuing Protocol (AMQP) [OASIS Advanced Message Queuing Protocol (AMQP)] is a message bus protocol. A message bus is a type of middleware.

[0036] Figure 11 shows the relationship between AMQP exchanges and queues. An AMQP exchange receives messages from a service and routes messages to one or more queues. Exchanges can be designed to route messages based on static rules (i.e., send all messages to these five services), based on any queues that bind themselves to the exchange, based on message topics, or based on values ​​in message headers.

[0037] Message Queuing Telemetry Transport (MQTT) [OASIS MQTT V3.1.1 Committee Specification 01, 18 May 2014] is another message bus protocol. A message bus is a type of middleware.

[0038] MQTT is a message-based middleware protocol originally developed by IBM and Eurotech in the late 1990s. It was submitted to OASIS standards in 2013 for formal adoption (a process ongoing) and further development. MQTT is a low-overhead message queuing and transport protocol tailored for constrained devices and low bandwidth networks, most notably deployed in the Facebook Messenger mobile app. It uses a publish / subscribe model as shown in Figure 12.

[0039] The core elements of MQTT are clients (which can be both publishers and subscribers), servers (also called brokers), sessions, subscriptions, and topics. These are shown in Figure 13.

[0040] Like HTTP, the MQTT protocol is asymmetric in that it distinguishes between two different roles: client and server.

[0041] In MQTT terminology, a client is a program or device that uses MQTT. It always establishes a network connection to a server. A client can: - Publish application messages that may be of interest to other clients. ● Subscribe to request application messages that it is interested in receiving. ● Unsubscribe and remove requests for application messages. ● Disconnect from the server.

[0042] An MQTT server is an entity that receives connections from clients. Unlike its HTTP counterpart, it does not generally run any application logic; instead, an MQTT server acts as an intermediary between clients that publish application messages and clients that have subscribed to receive them.

[0043] Topics are the "Qs" in MQTT; they are named message queues maintained by a server to link publishers with subscribers. An MQTT client plays the role of a publisher when it issues a PUBLISH message to an MQTT server (i.e., an instruction to deliver an opaque message payload to any clients subscribed to a supplied topic name), and a subscriber when it issues a SUBSCRIBE message to an MQTT server (i.e., an instruction to receive any PUBLISH message that matches a supplied topic filter). A topic filter is an expression included in a subscription that indicates interest in one or more topics. Topic filters may contain wildcard characters. PUBLISH messages are delivered with one of three QoS level guarantees: at most once, at least once, or exactly once.

[0044] Sessions and subscriptions represent two levels of attachment between a client and a server. A session is a stateful interaction (i.e., an active TCP / IP network connection) between a client and a server and is identified by a unique client identifier. A session can be established only by a client sending a CONNECT message to a server. Flags in the CONNECT, PUBLISH, and SUBSCRIBE messages determine how session state is maintained if the session is disconnected.

[0045] Network Functions Virtualization (NFV) aims to transform the way network operators design networks by evolving standard IT virtualization techniques to consolidate many network equipment types onto industry-standard high-volume servers, switches, and storage devices that may be located in data centers, network nodes, and end-user premises. This involves the implementation of network functions (e.g., mobility management, session management, QoS) in software that can run on a range of industry-standard server hardware and can be moved or instantiated at various locations in the network on demand without requiring the installation of new equipment. An illustrative example reproduced from ETSI GS NFV 002, Network Functions Virtualization (NFV); Architectural Framework, is shown in Figure 14.

[0046] NFV is applicable to any data plane packet processing and control plane functions in mobile and fixed networks. Potential examples may include: ● Switching elements: BNG, CG-NAT, router ● Mobile network nodes: HLR / HSS, MME, SGSN, GGSN / PDN-GW, RNC, eNodeB ● Features included in home routers and set-top boxes to create a virtualized home environment ● Centralized and network-wide functionality: AAA server, policy control and billing platform ● Application level optimization: CDN, cache server, load balancer, application accelerator ● Security features: firewall, virus scanner, intrusion detection system, spam protection

[0047] The application of NFV brings many benefits to network operators and contributes to a dramatic change in the landscape of the telecommunications industry. NFV can bring the following benefits: Reduce equipment costs and power consumption by consolidating equipment and leveraging economies of scale in the IT industry. Increased speed to market by minimizing typical network operator cycles of innovation The possibility to run production, test and reference facilities on the same infrastructure provides much more efficient testing and integration, reducing development costs and time to market. Targeted service deployment based on geography or customer sets is possible. Services can be rapidly scaled up / down depending on demand. ● Enabling a diverse ecosystem and encouraging openness ● Optimize network configuration and / or topology in near real-time based on actual traffic / mobility patterns and service demands. Supports multi-tenancy, thereby enabling network operators to provide tailored services and connectivity for multiple users, applications, or internal systems, or for other network operators, all coexisting on the same hardware with appropriate and secure separation of administrative domains. Reducing energy consumption by leveraging power management features within standard servers and storage devices, as well as workload consolidation and location optimization.

[0048] The European Telecommunications Standards Institute (ETSI) has formed a specification group, "Network Functions Virtualization," to publish several white papers and to produce some further elaboration material, including standard terminology definitions and use cases for NFV, that will serve as a reference for vendors and operators considering implementing NFV.

[0049] ETSI GS NFV 002, Network Functions Virtualization (NFV); Architectural Framework, is an ETSI publication that establishes an architectural framework for applying NFV concepts to mobile core networks.

[0050] Figure 15 is an example end-to-end network service with VNFs and nested forwarding graphs, reproduced from ETSI GS NFV 002. This figure illustrates the concept of a Virtualized Network Function Forwarding Graph (VNF-FG). A VNF-GW describes how a set of VNFs are connected to provide a service.

[0051] Network slicing, as described in Next Generation Mobile Network (NGMN) Alliance, “Description of Network Slicing Concept”, is a mechanism that can be used by mobile network operators to support multiple “virtual” networks behind the air interface across the fixed parts of the mobile operator's network, both the backhaul and the core network. It involves “slicing” the network into multiple virtual networks to support different service types launching across different RANs or a single RAN. Network slicing allows operators to create networks that are customized to provide optimized solutions for different market scenarios that demand diverse requirements, for example in the areas of functionality, performance, and isolation. Figure 16 shows a conceptual architecture of network slicing. Different colors are used to indicate different network slice instances or sub-network slice instances.

[0052] 3GPP is designing 5G networks and is considering incorporating network slicing technology to accommodate them. This is because 5G use cases (e.g., mass IoT, critical communications, and enhanced mobile broadband) are very diverse and at times demand extreme requirements. Current architectures utilize relatively monolithic network and transport frameworks to accommodate various services such as smartphones, OTT content, mobile traffic from feature phones, data cards, and embedded M2M devices. It is expected that the current architectures are not flexible and scalable enough to efficiently support a wider range of business needs, each with its own specific set of performance, scalability, and availability requirements. Furthermore, the introduction of new network services should be made more efficient. Nevertheless, several use cases are expected to be active simultaneously within the same operator network, thus demanding a high degree of versatility and scalability of the 5G network.

[0053] Network slicing allows operators to create networks that are customized to provide optimized solutions for different market scenarios that demand diverse requirements, for example in the areas of functionality, performance, and isolation. However, there are several challenges and problems to support network slicing in future 5G networks. ● How to achieve separation / isolation between network slice instances, and the level and type of separation / isolation that may be required; How resource and network function sharing can be used between network slice instances, and the types of resource and network function sharing A method for enabling a UE to simultaneously obtain services from one or more specific network slice instances of one operator. Network slicing (e.g., network slice creation / configuration, modification, deletion) is within the scope of 3GPP Network functions that may be included in a particular network slice instance, and network functions that are independent of the network slice Procedure for selection of a specific network slice for a UE ● How to support network slicing roaming scenarios? ● How to enable operators to use network slicing concepts to efficiently support multiple third parties (e.g. enterprises, service providers, content providers, etc.) that require similar network characteristics.

[0054] Further details (i.e., issues, challenges, and possible solutions) can be found in 3GPP TR 23.799, Study on Architecture for Next Generation Systems, on how 3GPP is applying network slicing within 5G network architectures.

[0055] To enable a UE to simultaneously obtain services from multiple network slices of one network operator, a single set of control plane functions is shared across multiple core network instances as shown in Figure 17. This figure is reproduced from 3GPP S2-162259, the latest update on the solution for supporting multiple connections to multiple network slices.

[0056] A core network instance consists of a single set of control plane functions and a single set of user plane functions. Also, a core network instance is dedicated to UEs belonging to the same UE type. Identifying the UE type is done by using specific parameters, e.g., UE usage type and / or information from the UE's subscription. A set of user plane functions in a core network instance is responsible for providing a specific service to the UE and transporting data of the specific service to the user plane. For example, one set of user plane functions in core network instance #1 provides enhanced mobile broadband services to the UE, while another set of user plane functions in core network instance #2 provides critical communication services to the UE. When a UE first connects to the operator's network, a default core network instance that matches the UE usage type is assigned to the UE. Each UE can have multiple user plane connections to different sets of user plane functions available in different core network instances at the same time. Control plane functions can be shared across network slices.

[0057] The Core Network Selection Function (CNSF) is responsible for: Selecting a core network instance adapted to the UE by considering the UE's subscription and specific parameters, e.g., UE usage type. ● Select a control plane function in the selected core network instance with which the base station should communicate. This selection of the control plane function is done by using specific parameters, e.g. the UE usage type. Selecting a set of user plane capabilities with which the base station should establish a connection to transport user plane data of different services. This selection of user plane capabilities is done by using specific parameters, e.g. UE usage type and service type.

[0058] To enable the interconnection of network functions, an Interconnection and Routing Function (IRF) 2058 is proposed in 3GPP TR 23.799, Study on Architecture for Next Generation System. Figure 18 and Figure 19 show the reference models of IRF 2058 for non-roaming and roaming scenarios, respectively. The functions of IRF 2058 include: ● Store the binding between the identity of the UE and the interface layer identity (e.g. instance number) of each serving NF that has an active session for the UE. For NFs that do not interface directly with the IRF2058, e.g. in a roaming scenario, the IRF2058 stores the identities of IRFs2058 of distant PLMNs through which these NFs are reachable. ● Updating the binding repository when the identity of the serving NF changes for a given UE, for example due to UE mobility, load rebalancing (i.e. virtual machine shrink or grow), or restoration reasons. ● Inspect the message header to determine the identity of the UE (to which the message is being sent) and the destination NF. For the UE identity, consult the internal binding repository to determine the interface layer identity (e.g. instance number) of the destination NF or the identity of the remote IRF 2058. Route the message accordingly. Optionally, implement message authorization based on operator configuration, e.g. if the operator configuration prohibits NF1 from sending a certain message ("Change APN-AMBR of UE") towards NF4, IRF2058 rejects the corresponding message. Optionally, protect NFs during extensive signaling by implementing overload control, e.g. pacing of messages sent to a given NF based on its load / overload status.

[0059] Each NF interfaces with the IRF 2058 via a given reference point within its own PLMN. NFs do not interface directly with each other, but may communicate with each other (i.e., send request or response messages) via the IRF 2058. Thus, when required, the present model allows any NF to communicate directly with any other NF without involving any other unrelated network function in the path; for example, NF1 can send a message to NF3 via the IRF 2058 without involving NF2 if the involvement of NF2 is not required. Summary of the Invention [Means for solving the problem]

[0060] The 5G network architecture uses virtualization and network slicing. A user equipment (UE) interacts with an underlay network, which interacts with a virtual network slice. The UE interacts with an underlay network (ULN) to establish a connection to the virtual network slice.

[0061] The following procedures can be defined: ● Procedures for allocating new slice instances to UEs (UE-initiated and ULN-initiated) ● Procedures to change the UE profile (UE-initiated and ULN-initiated) ● Procedure to change the assigned slice instance of a UE (ULN initiated)

[0062] An embodiment is described in which a network slice instance is deployed by connecting virtualized network functions via a message broker.

[0063] This Summary is provided to introduce a set of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted in any part of this disclosure. [Brief description of the drawings]

[0064] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1] FIG. 1 is a diagram illustrating a (S)Gi-LAN. [Diagram 2] Figure 2 is a diagram illustrating the major components of the IETF's SFC architectural framework. [Diagram 3] FIG. 3 is a diagram illustrating NSH encapsulation. [Figure 4] FIG. 4 is a diagram illustrating the NSH format. [Diagram 5] FIG. 5 is a diagram illustrating a variable context header. [Figure 6] FIG. 6 is a diagram illustrating the 3GPP architecture applied to the architecture proposed by the IETF. [Figure 7] FIG. 7 is a diagram illustrating a high-level representation of a message-based middleware. [Figure 8] FIG. 8 is a diagram illustrating a queue-based middleware. [Figure 9] FIG. 9 is a diagram illustrating an example of a publish / subscribe system. [Figure 10] FIG. 10 is a diagram illustrating a message-based middleware broker. [Figure 11] FIG. 11 is a diagram illustrating the relationship between the AMPQ exchange and queues. [Figure 12]FIG. 12 is a diagram illustrating the MQTT publish / subscribe model. [Figure 13] FIG. 13 is a diagram illustrating the MQTT functional model. [Figure 14] FIG. 14 is a diagram illustrating the vision for NFV. [Figure 15] FIG. 15 is a diagram illustrating the concept of a Virtualized Network Function Forwarding Graph (VNF-FG). [Figure 16] FIG. 16 is a diagram illustrating a conceptual architecture of network slicing. [Figure 17] FIG. 17 is a diagram illustrating the CNSF in selecting multiple network slice instances. [Figure 18] FIG. 18 is a diagram illustrating a non-roaming reference model for interconnection of network functions. [Figure 19] FIG. 19 is a diagram illustrating a roaming reference model for interconnection of network functions. [Figure 20A] FIG. 20A is a diagram illustrating a 5G network architecture. [Figure 20B] FIG. 20B is a diagram illustrating an underlay network for the 5G network architecture of FIG. 20A. [Figure 20C] FIG. 20C is a diagram illustrating a virtual network slice for the 5G network architecture of FIG. 20A. [Figure 21] FIG. 21 is a diagram illustrating RAT interface functions for a mobile core network and networks associated with each RAT. [Figure 22] FIG. 22 is a diagram illustrating the initial connection procedure. [Diagram 23] FIG. 23 is a diagram illustrating a GUI prompt for a new temporary identifier. [Figure 24] FIG. 24 is a diagram illustrating a UE-initiated ULN-based new slice instance allocation call flow. [Diagram 25] FIG. 25 is a diagram illustrating a ULN-initiated ULN-based new slice instance allocation call flow. [Figure 26] FIG. 26 is a diagram illustrating a UE-initiated ULN-based profile change. [Figure 27] FIG. 27 is a diagram illustrating ULN-initiated ULN-based profile changes. [Figure 28] FIG. 28 is a diagram illustrating ULN-initiated ULN-based profile changes. [Figure 29] FIG. 29 is a diagram illustrating a new UE-initiated slice allocation (alternative approach). [Diagram 30] FIG. 30 is a diagram illustrating network-initiated new slice allocation (alternative approach). [Diagram 31] FIG. 31 is a diagram illustrating a UE-initiated profile change (alternative approach). [Diagram 32] FIG. 32 is a diagram illustrating network-initiated profile change (alternative approach). [Diagram 33] FIG. 33 is a diagram illustrating network-initiated slice change (alternative approach). [Diagram 34] FIG. 34 is a diagram illustrating an example of implementing an IRF / IWK-IRF as a message broker. [Diagram 35] FIG. 35 is a diagram of a graphical user interface of one embodiment. [Figure 36A] FIG. 36A is a schematic diagram of an M2M / IoT / WoT communication system including a communication network. [Figure 36B] FIG. 36B is a schematic diagram of an illustrated M2M service layer in a field domain that provides services for M2M applications, M2M gateway devices, and M2M terminal devices, as well as a communication network. [Figure 36C]FIG. 36C is a schematic diagram of an example device that may be used to implement any of the network nodes, devices, or apparatus described herein. [Figure 36D] FIG. 36D is a block diagram of a computer system or server that may be used to implement any of the network nodes, devices, or apparatus described herein. [Figure 37A] FIG. 37A illustrates one embodiment of an exemplary communication system of which the methods and apparatus described and claimed herein may be embodiments. [Figure 37B] FIG. 37B is a block diagram of an example apparatus or device configured for wireless communication according to embodiments illustrated herein. [Figure 37C] FIG. 37C is a system diagram of a RAN and a core network according to an embodiment. [Figure 37D] FIG. 37D is a system diagram of a RAN and a core network according to another embodiment. [Figure 37E] FIG. 37E is a system diagram of a RAN and a core network according to yet another embodiment. [Figure 37F] Figure 37F is a block diagram of a 5G core network. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0065] [Table 1-1] [Table 1-2] [Table 2]

[0066] The 3GPP SA2 working group is defining a new 5G network architecture. The work is being carried out under the study item called "Study on Architecture and Security for Next Generation System" (FS_NextGEN). The results of the study are summarized in 3GPP TR 23.799,Study on Architecture for Next Generation System.

[0067] 5G network architecture will rely on network function virtualization (NFV) techniques. NFV will enable mobile network operators to dynamically deploy, scale, and scale services as needed or required by their customers. Services will be provided through virtual network functions that are stitched together to form slices and provide one or more services to users.

[0068] Not all functions can be virtualized. For example, before the UE 2006 can connect to the network slice 2002, an initial connection with the network must be formed. Thus, some basic non-virtualized connection with the network must be formed before the network can determine the network slice to which the UE 2006 should connect. Another example is that the UE 2006 must form a Layer 1 connection with some base station hardware before it can form an initial connection with the network.

[0069] In the proposals considered thus far, there has been only limited discussion of how the UE 2006 forms an initial connection with the 5G network, and what functions the UE 2006 is required to have outside of any network slice 2002 so that it can form an initial connection with the network. 3GPP S2-162259 and 3GPP S2-162260 are two of several references that discuss this issue. It should be understood that the initial connection procedure may also be referred to as a registration procedure, since the initial connection procedure involves authorizing the UE to receive services from the network.

[0070] (5G Network Architecture) Figure 20A shows a 5G network architecture 2000 with an underlay network 2004 and a virtual network slice 2002. Figure 20B is a diagram illustrating an underlay network 2004 for the 5G network architecture of Figure 20A. Figure 20C is a diagram illustrating a virtual network slice 2002 for the 5G network architecture of Figure 20A.

[0071] As shown in the figure, various UEs 2006a-d may connect to the 5G network via multiple different radio access technologies (RATs). The RAT used to connect the 5G network may or may not be defined by 3GPP. If the RAT is not defined by 3GPP, 3GPP may or may not define procedures for the RAT to interface with the 5G network. If 3GPP does not define procedures for the RAT to interface with the 5G network, a customized interface may be built based on a dedicated solution that allows the RAT to interface with the 5G network via a 3GPP defined interface to the core network.

[0072] A reference point named NG1 is used to interface the RAT with the 5G core network. The NG1 interface is split into a user plane reference point and a control plane reference point, i.e., NG1-U and NG1-C, respectively. The NG reference point is designed such that the signaling on this interface and the protocols on this interface are largely RAT independent. However, the interface is expected to be RAT aware in the sense that it should provide the ability to inform the 5G network of the RAT type and RAT capabilities. Some examples of RAT capabilities could be minimum or maximum latency, maximum data rate, security capabilities, etc.

[0073] 20A and 20B show functions that may be considered part of the underlay network 2004. The underlay network 2004 consists of core network functions that a UE 2006 requires to establish a connection and obtain a minimum level of service. These functions are required before the UE 2006 can be authenticated, authorized, and permitted to receive services. The underlay network 2004 may also consist of functions that should not be virtualized. For example, a user's subscription data should not be virtualized.

[0074] The 5G architecture may rely heavily on network function virtualization techniques. Virtualized network functions will be grouped together into network slices via the IRF 2058 to provide one or more services to a UE 2006 and / or a group of UEs. A UE 2006 may be enabled to connect to more than one network slice simultaneously.

[0075] The network functions 2056 do not communicate directly with each other. Rather, they communicate via the IRF 2058 described above. Some network functions may be common to multiple network slices. This type of network function may connect to more than one IRF. An example of a network function that may be shared across network slices is the mobility management network function 2022, which tracks the UE's point of attachment to the network (i.e., RAT).

[0076] Network slices can be largely isolated from one another in the sense that they will not directly interact, however, they are not isolated in the sense that they may run on the same physical platform and interface with the same network functions in the underlay network 2004.

[0077] Network slices may also communicate in roaming scenarios. For example, some services may require that the UE's IP anchor resides in the HPLMN while the mobility management functionality may reside in the VPLMN. In such scenarios, it is necessary for slices to interwork or for slices to exist across operators. In such scenarios, the IRFs of each slice (or part of a slice) would communicate via an IRF interworking (IRF-IWK) function 2030 in the underlay network 2004.

[0078] Operator-defined, enterprise, vertical, and third-party services may be deployed as network functions. Such services may connect directly to the operator's RF 2058 and provide services to the UE 2006 or the operator. For example, an M2M server may be deployed as a network function that connects directly to the IRF 2058 and provides services to the UE 2006. Also, a parental control service may be deployed as an NF and apply policies to traffic to and from the UE 2006. For example, a PCF may provide parental control policies to a UPF, which can enforce the policies. As described elsewhere herein, an NF such as a UPF may include a PEF.

[0079] Operator-defined, enterprise, vertical, and third-party services may also be deployed in an over-the-top (OTT) fashion. When deployed in this manner, traffic is routed from the egress node of the slice to the OTT service 2010. The output of the egress node may typically be IP data. However, it may also be SMS data, and the OTT service may be an SMS-SC. The traffic may also be non-IP data packets tunneled (over IP) to the OTT service.

[0080] OTT services such as M2M servers (IN-CSE, SCS, AS) may simultaneously connect and interact with the UE 2006 in an OTT manner and interact with the UE's network slice 2002 via the SCEF 2054, which enables the OTT services to connect to the IRF 2058 and obtain services from the slice 2002.

[0081] The network functions included in Figures 20A-C are described below. It is understood that the functionality illustrated in Figures 20A-C may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a wireless device or other apparatus (e.g., a server, gateway, device, or other computer system), such as one of those illustrated in Figures 36-37 described below. It is also understood that the functionality illustrated in Figures 20A-C may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via a forwarding or routing function.

[0082] Figures 22-33 illustrate 5G network procedures required for the UE 2006 to establish basic connectivity with the 5G network. The procedures of Figures 22-28 are based on an approach that requires interaction between the UE 2006 and functions in the underlay network 2004. The procedures of Figures 29-33 show alternative approaches such as connecting to a new network slice, changing network slices, changing profiles, etc. These procedures assume that the UE 2006 has a default slice that it will connect to at the initial attachment / connection event, which may also provide IP connectivity.

[0083] 5G networks will support network functions that may be either virtualized or not virtualized. It may not be desirable to virtualize network functions that are required to be centralized and coordinated across all network functions, such as a subscriber database. Different network functions may be performed on the same or different physical platforms or network nodes. Table 3 lists the network functions discussed in this document. [Table 3-1] [Table 3-2]

[0084] 5G networks will support network nodes that can perform one or more network functions, either naturally in some situations or through network function virtualization. In some cases, the functions described in Table 3 may be distributed across multiple network nodes. For example, a session management function may reside in the ingress and egress nodes, in the RAT base station, and in the UE. When the RIF, CNEP, and MM functions are co-located / combined in one NF, the combined function handles the access and mobility management of the UE to the network, and thus the co-located / combined NF may be referred to as an access and mobility management function (AMF). There may be a single NF for handling MO data. In this case, the MOI and MOE may be co-located. Because this NF handles user plane data, this combined function may be referred to as a user plane function (UPF) or MO-UPF. There may be a single NF for handling MT data. In this case, the MTI and MTE may be co-located. Because this NF handles user plane data, this combined function may be referred to as a user plane function (UPF) or MT-UPF. There may be a single NF for handling MT and MO data. In this case, the MOI, MOE, MTI, and MTE may be co-located. Because this NF handles user plane data, this combined function may be called the User Plane Function (UPF).

[0085] The following sections describe in more detail some of the network functions described in Table 3.

[0086] A Subscription Service Function (SSF) 2060 is a type of NF that handles queries for subscriber data. Subscriber information is stored in a subscriber database, which holds subscriber information for each UE 2006, a group of UEs, or an application server. HSS, HLR, SPR, and UDR 2032 are types of subscriber databases. The subscriber database itself would typically not be virtualized, but would instead be considered a function that is part of the underlay network 2004 and shared across network slices. Because the SSF 2060 is an NF that may be part of a slice, it may interface with the UDR 2032 via the IRF 2058.

[0087] In the example of Figures 20A and 20B, the subscriber database (UDR 2032) is part of the underlay network 2004 and is not virtualized. The SSF 2060 is a NF that may be virtualized and instantiated in each network slice instance.

[0088] When a new network slice is instantiated, the associated SSF2060 may be configured based on the services provided by the slice instance and the users that are or will be associated with the slice instance. For example, if a user, group of users, or class of users is not permitted to use the slice instance, the SSF2060 may not allow queries of the UDR2032 when the query references these users, groups of users, or classes of users.

[0089] If UDR2032 is a centralized entity and shared across many network slices, SSF2060 may cache and / or pre-fetch and store subscriber information stored in UDR2032. When a user or group is associated with a network slice, SSF2060 may then fetch the user or group's subscription information from UDR2032 and store it locally in the SSF instance 2060 so that future UDR2032 queries may be avoided. SSF2060 may inform UDR2032 that it has cached information associated with a user or group so that UDR2032 may notify SSF2060 when and if the associated information is updated.

[0090] The subscriber database may need to be accessed prior to the UE 2006 connecting to a slice, for example, to perform authentication and authorization procedures with the UE 2006. Thus, the UDR 2032 may have an interface to the AAA server 2028.

[0091] The User Data Repository (UDR 2032) is a repository of subscriber data. Table 4 captures the information that may be included in a UDR subscription profile of a UE. Alternatively, the same information may be associated with a group of UEs, an application server, or a group of application servers.

[0092] Because the UDR 2032 is deployed as a central function shared across all network functions and is required to determine the slice to which the UE 2006 should first connect, the UDR 2032 may not be virtualized and may be considered part of the underlay network 2004. [Table 4]

[0093] (UDR Temporary ID Generation Procedure) The UDR 2032 may receive a request to generate a temporary ID for the UE. The request may indicate the type of service the UE 2006 will want to use when providing the temporary ID, where the UE 2006 is expected to be when the temporary ID is used, the party to be charged when the temporary ID is used, etc.

[0094] (UE-DEVICE-TYPE) UE-DEVICE-TYPE identifies the type of device or device capabilities. For example, this may indicate that it is a PS-only device, a control plane-only device, a low-volume data device, an emergency / first responder device, etc.

[0095] A control plane only device is a device that maintains only a control plane connection to a network or network slice.

[0096] A PS-only device is a device that only accesses PS services and does not access CS services.

[0097] A small data device is a device that only accesses the network or a network slice to transmit small data packets. There can be different types of small data devices (i.e., non-IP small data, SMS, etc.).

[0098] The emergency / first responder device type indicates that the device is used for important communications and should be prioritized during times of network congestion or partial network outage.

[0099] A low mobility device type may indicate that the UE 2006 is unlikely to be mobile or will only move infrequently. In addition, information such as a stationary indication or maximum speed may be provided.

[0100] The UE-DEVICE-TYPE may be permanent subscription data in the subscriber database.

[0101] The UE-DEVICE-TYPE may be temporary subscription data in the subscriber database. When the UE-DEVICE-TYPE is temporary subscriber data, it may be provided by the UE 2006 when a new service is accessed or when establishing an initial connection.

[0102] The UE-DEVICE-TYPE may consist of several identifiers so that a device can be considered as multiple types at the same time, for example a radiation detector may be both a low mobility and an emergency device.

[0103] The device type may indicate the times when the UE 2006 is or is not allowed to access the network.

[0104] The device type may indicate where the UE 2006 is or is not enabled to access the network. Because the device type describes the UE's ability to use core network features, this may be referred to as UE 5G Core Network (5GCN) capabilities.

[0105] (UE-SLICE-DESCRIPTOR) The UE-SLICE-DESCRIPTOR fully describes one or more types of slices. It may be considered as a slice template or an identifier associated with a slice template. The subscription information of the UE may include a UE-SLICE-DESCRIPTOR, which indicates the types of slices to which the UE 2006 may connect.

[0106] The UE-SLICE-DESCRIPTOR may include an indication that this is the UE default, in which case the UE 2006 will connect to this type of slice by default.

[0107] The UE-SLICE-DESCRIPTOR may include an indication that it is required, in which case the UE 2006 is always required to connect to this type of slice when connected to the network.

[0108] The UE-SLICE-DESCRIPTOR may include an indication that it is optional, in which case the UE 2006 may optionally request to connect to a slice of this type.

[0109] The UE-SLICE-DESCRIPTORs may be permanent subscription data or they may be temporary subscriber data, in which case they may be provided by the UE 2006 during the initial attachment procedure or when the desired service or set of services is requested.

[0110] (UE-SERVICE-DESCRIPTOR) The UE-SERVICE-DESCRIPTOR describes one or more services desired by the UE. The UE's subscription information may include a UE-SERVICE-DESCRIPTOR, which indicates the types of services the UE 2006 may have access to.

[0111] The UE-SERVICE-DESCRIPTOR may include an indication that this is the UE default, in which case the UE 2006 will connect to this type of service by default.

[0112] The UE-SERVICE-DESCRIPTOR may include an indication that it is requested, in which case the UE 2006 is always requested to connect to this type of service when connected to the network.

[0113] The UE-SERVICE-DESCRIPTOR may include an indication that it is optional (or enabled), in which case the UE 2006 may optionally request to connect to this type of service.

[0114] The UE-SERVICE-DESCRIPTORs may be durable subscription data or they may be temporary subscriber data, in which case they may be provided by the UE 2006 during the initial attachment procedure or when the desired service or set of services is requested.

[0115] The UE-SERVICE-DESCRIPTOR may include a UE capability profile and / or a UE session profile. Some examples of UE capability profiles are: ● A "Web Browsing" service descriptor, indicating that the UE 2006 expects to use a web browsing application and have access to certain upload and download speeds. ● An "SMS messaging" service descriptor, indicating that the UE 2006 expects to use an application to send SMS messages. The service descriptor may indicate that the UE 2006 is enabled to send or receive X messages per unit time. - A "video streaming" service descriptor, which may for example be used by video streaming applications, which require a relatively high data rate on a more or less continuous basis. - A "Non-IP Data" service descriptor, which may be used, for example, by home automation appliances that do not require a full IP stack. ● An "ultra-low latency" service descriptor, for example for use by industrial automation applications. - A "Short Data Burst" service descriptor, for example for use by smart meters generating low frequency short data bursts. • A "critical communications" service descriptor for use by essential applications, e.g., public safety or government use. - Third-party services (e.g. notification servers, M2M servers, etc.) Sponsors (e.g., third-party services that may sponsor the service)

[0116] The service descriptor may indicate the times when the UE 2006 is or is not enabled to access the service.

[0117] The service descriptor may indicate where the UE 2006 is or is not enabled to access the service.

[0118] (Policy maintenance function) The Policy Maintenance Function (PMF) 2050 is responsible for storing and enabling retrieval of policies applicable to the 5G network as well as services offered by third parties. The PMF 2050 will be queried by various network functions before taking enforcement action. The PMF 2050 will be updated by the service provider, for example, in response to changes in network or third party policies.

[0119] The PMF 2050 may be a centralized entity that resides in the underlay network 2004. Each network slice may have an NF that serves as a front-end to the PMF 2050. The PMF front-end (PMF-FE) may be used by other NFs in the slice to read policies. The PMF-FE may filter policies that are sent to other NFs in the slice. Filtering may be based on the configuration of the slice, the capabilities of the slice, or the capabilities or permission level of the NF that is reading the policy.

[0120] Alternatively, the PMF 2050 may not be centralized, but instead deployed as a NF in each slice, or shared across several slices. Each network slice may have an NF that serves as a PMF 2050. The PMF 2050 may be used by other NFs in the slice to read policies. The PMF 2050 may filter policies that are sent to other NFs in the slice. Filtering may be based on the configuration of the slice, the capabilities of the slice, or the capabilities or permission level of the NF that is reading the policy.

[0121] The PMF 2050 may provide an interface that allows external entities to provision new services at the PMF 2050. This interface may be accessible via the IRF 2058 or via O&M methods.

[0122] (Policy enforcement function) The Policy Enforcement Function (PEF) may be deployed as a standalone function or distributed across several NFs. In other words, it may be considered as an action taken by many different NFs. For example, in a distributed deployment, the PEF will be part of the ingress and / or egress functions and will be responsible for enforcing QoS constraints on flows ingressing / egressing the core network. The PEF may also be part of a third party service, such as parental control, that requires certain content to be filtered as specified by the PMF 2050. The PEF may be part of the IRF 2058 and enforce policies related to the NFs or services that are allowed to be accessed. Thus, the distributed PEF function will periodically (or when triggered by some event) query the PMF 2050 to obtain the current policy regarding the services being provided.

[0123] (AAA feature 2028) The AAA function 2028 may be required during an initial attach procedure of a UE, and therefore may not be virtualized and may be considered part of the underlay network 2004, as shown in Figures 20A and 20B.

[0124] The AAA server 2028 may be used to obtain authentication and authorization information for the UE 2006. It may also be used as a secure interface for other entities (e.g., the RIF 2102) to obtain UE subscription information, obtain a new temporary identifier for the UE 2006, and update the UE's subscription information with new location and status information.

[0125] The UE 2006 may attempt to establish an initial connection via a RAT (eg, small cell, access point, eNodeB, base station, etc.) and utilize the AAA service 2028.

[0126] The AAA server function 2028 may also be virtualized and included as part of the network slice to provide similar functionality. In the 5G network architecture 2000, these types of functions are provided within the slice by the SSF 2060.

[0127] When the UE 2006 successfully authenticates with the AAA server 2028, the AAA server 2028 may include the UE subscription information, such as the information from Table 4, in a successful authentication response to the RIF 2102.

[0128] The AAA function 2028 may be integrated with the UDR function 2032 .

[0129] (RAT Interface Function (RIF) 2102) The core network exposes an interface that is independent of the RAT being used to access the core network. A RAT Interface Function (RIF) 2102 is used to interface between the core network and the RAT used to access the core network. Figure 21 shows the placement of the RAT Interface Function 2102 to the mobile core network and the network associated with each RAT. In this architecture, the RIF 2102 is not considered a core network function, however, it can be seen how it is placed relatively close to the core network and can be considered a core network function or can be integrated or co-located with a core network function such as the CNEP.

[0130] It is understood that the functionality illustrated in Figure 21 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a wireless device or other apparatus (e.g., a server, gateway, device, or other computer system), such as one of those illustrated in Figures 36-37 described below. It is also understood that the functionality illustrated in Figure 21 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via a forwarding or routing function.

[0131] RATs can be broadly classified into three categories. ● 3GPP-defined RAT ● 3GPP compliant RATs - 3GPP compliant RATs are RATs that are not defined by 3GPP, but 3GPP has defined procedures to make these RATs interwork with the 3GPP core network. In 4G, these RATs are called non-3GPP RATs, examples of non-3GPP RATs are Wi-Fi and CDMA2000. Foreign RAT - Foreign RATs are RATs for which 3GPP has not defined interworking procedures. However, customized or implementation specific air interface modules can be designed to interwork these RATs with the core network.

[0132] Note that the RIF 2102 can connect one or more networks to the core network, where each network may be associated with a different or the same RAT. The RIF 2102 interfaces with the access points (i.e., base stations or eNodeBs) of each network.

[0133] The RIF 2102 will access the core network functions through a Core Network Entry Point (CNEP) 2010. The RIF 2102 will provide the RAN with any core network information that may be broadcast / advertised by the RAN, for example to assist the UE 2006 in selecting a RAT and connecting to an underlay network.

[0134] RIF2102 supports the procedures listed in Table 5. [Table 5]

[0135] (RAT Broadcast / Advertisement) Prior to the initial attachment procedure, the UE 2006 receives the broadcasted information. The information in the broadcast is used by the UE 2006 to determine which RATs can be used by the UE 2006 to establish a connection with a core network or network slice and to obtain a desired service. The RIF 2102 will provide the broadcasted information to the lower RAT.

[0136] The following information may be included in the broadcast: For each RIF2102 that can be reached via the RAT: RAT Interface Identifier: RIF ID (a unique identifier that can be referenced by the UE for connectivity) ○ Identification of the network operator associated with the RIF2102: PLMN ID or MNO ID ○ Address of the serving SISF: ID, IP address, or FQDN of the SISF ○ Serving CNEP address: CNEP ID, IP address, or FQDN o Service ID - Identifiers or names of services that can be reached via this RAT or RIF 2102. These Service IDs can map to specific types of Service Profiles. ○ RAT type (e.g. low mobility only, low data rate only, etc.) ○ Co-located RAT information (if applicable)

[0137] A single AP / base station may broadcast information about multiple RIFs / RATs that may be requested by a UE. For example, an AP / base station may broadcast multiple RIF identifiers, and a separate set of the information listed above may be associated with each identifier.

[0138] The UE 2006 may provide a GUI or API that allows the user to input any of the above information. The information will then be used as a criterion by the UE 2006 to determine if the UE 2006 should connect to the RAN. In addition, the operating system may maintain profiles of installed applications and provide profile information that either directly maps to a required RAT type or provides constraints on the RAT type required to meet application requirements. The operating system may provide the profile to the modem for transmission to the underlay network. The modem may expose an API to allow the operating system to provide the profile to the modem.

[0139] (Initial-Connection) The initial attachment procedure is performed between the RIF 2102 and the UE 2006 when the UE 2006 is attempting to make an initial attachment to the core network.

[0140] The Initial-Connection-Req message is sent by the UE 2006 to the RIF 2102. The request includes the following information: ● UE-T-ID: A temporary identifier to which the RIF 2102 may resolve an HPLM-ID or an MNO-ID. The format of this identifier may be a binary value such as a temporary IMSI, or the format of this identifier may be a URI. An example URI may be alpha-numeric-string@network-operator-identifer.net. The portion of the identifier that identifies the network operator may include a Mobile Network Code (MNC) and a Mobile Country Code (MCC). ● UE-AAA-SERVER-POC: A point of contact, identity, or address of an AAA server 2028 that can be used to authorize and authenticate the UE. If this value is not provided by the UE, the RAN may derive it from the UE-T-ID. For example, the RIF 2102 may perform a DNS lookup on the UE-T-ID and obtain the point of contact, or the RIF 2102 may recognize that the UE-T-ID is associated with a particular operator and have a pre-provisioned point of contact for that operator. UE-DEVICE-TYPE (This may be part of the UE's subscription information as permanent subscription data or may be provided by the UE. If provided by the UE 2006, this may be added to the UE's subscription data as temporary subscription data.) UE-SISF-ID (this may be part of the UE's subscription information as permanent subscription data or may be provided by the UE 2006. If provided by the UE 2006, this may be added to the UE's subscription data as temporary subscription data.) UE-SLICE-DESCRIPTORS (this may be part of the UE's subscription information as permanent subscription data or may be provided by the UE. If provided by the UE 2006, this may be added to the UE's subscription data as temporary subscription data.) UE-SERVICE-DESCRIPTORS (this may be part of the UE's subscription information as permanent subscription data or may be provided by the UE. If provided by the UE 2006, this may be added to the UE's subscription data as temporary subscription data.) ● HANDOVER-FLAG - This is an indication from the UE 2006 that the UE 2006 is already connected to the core network via another access point or another RIF 2102. When this indication is set by the UE or provided by the UE, it is an indication that the RIF 2102 should authenticate and authorize the UE, get the relevant subscription information from the UE 2006 from the SSIF, and maintain the UE's connection to the core network and network slice to which it is currently connected. ● RIF-ID - This identifier allows the UE 2006 to uniquely reference a specific RIF 2102 based on the broadcast information. This allows the UE 2006 to request an initial attachment to a specific RAT even if the broadcast information is provided over a different RAT.

[0141] The Initial-Connection-Resp message is sent to UE2 by RIF2102. The request includes the following information: ● An indication of whether the connection is allowed. - An indication of whether any requested services or connections to slices can be provided. ● UE-T-ID-NEW - a new temporary identifier. If this identifier is provided, the previous UE-T-ID should be considered invalid. UE-SERVICE-DESCRIPTORS (this may be part of the UE's subscription information as permanent subscription data or may be provided by the UE. If provided by the UE 2006, this may be added to the UE's subscription data as temporary subscription data.)

[0142] (obtains authentication and authorization vectors from the core network) This procedure is used between the RIF 2102 and the AAA server 2028 to obtain authentication and authorization information for the UE 2006 attempting to establish a connection to the core network. The AAA server 2028 resides in the core network to which the UE 2006 is attempting to establish a connection. The RIF 2102 uses the UE's UE-T-ID to determine how to contact the AAA server 2028 in the UE's HPLMN. For example, a DNS lookup on the UE-T-ID may resolve the AAA server 2028 address, the HPLMN, or the CNEP 2020 address. Alternatively, the UE 2006 may have explicitly provided the network operator, HPLMN, CNEP, or AAA server ID in the Initial-Connection-Req message. Instead of contacting the AAA server 2028, the point of contact may be a subscriber database such as the HSS, HLR, or UDR 2032.

[0143] The RIF 2102 sends an AA-Vector-Req message to the AAA server 2028. The message includes the UE-T-ID.

[0144] The AAA server 2028 responds to the RIF 2102 with an AA-Vector-Resp message. A successful response is an indication to the RIF 2102 that the AAA server 2028 recognizes that the UE 2006 associated with the UE-T-ID should be enabled to establish a connection to the RAT. This response may include the following information: ● One or more challenge vectors that can be used to authenticate the UE. The AKA procedure may be similar to that defined in EPS, but with potentially different key derivations on demand for different entities and relationships. The AKA mechanism performs authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge-response based mechanism that uses symmetric encryption. AKA is typically initiated in a subscriber module (e.g., USIM) that resides on a smart card-like device that also provides tamper-proof storage of the shared secret. One or more tokens may be used by the UE 2006 to perform network authentication.

[0145] (UE certified) When the UE 2006 establishes a connection to the RIF 2102, the RIF 2102 authenticates the UE. When the UE 2006 moves from one RAT to another or from one AP / base station to another, the UE 2006 does not necessarily need to re-authenticate if the RIF 2102 does not change.

[0146] During this authentication process, the RIF 2102 will send a challenge message to the UE 2006 and check that the UE 2006 provides the expected response. If the expected response is provided, the UE 2006 is assumed to be authenticated. This section describes the challenge and response messages exchanged between the RIF 2102 and the UE.

[0147] The RIF 2102 sends an Auth-Challenge-Req message to the UE. The authentication challenge message includes one or more of the challenge vectors provided by the AAA server 2028. The message may also include the following information: ● An indication that the temporary identifier is not recognized or that the temporary identifier is associated with a stolen device. This may cause the UE platform to display a message such as "This device's identity is not recognized by the network. Please contact your service provider to obtain an identity." The UE 2006 may further provide a GUI that allows the user to enter a new temporary identity and select a "Connect" option. Selecting the "Connect" option will cause the UE 2006 to attempt to reconnect to the network and initiate a new Initial-Connection request.

[0148] The UE 2006 sends an Auth-Challenge-Resp message to the RAN. The challenge response is based on the challenge vector and the UE's private identity provided in the Auth-Challenge-Req message.

[0149] (Check authentication and authorization vectors with the core network) This procedure is used between the RIF 2102 and the AAA server 2028 to check the UE's authentication response. The RIF 2102 forwards the UE's response to the AAA server 2028, which responds with an indication of whether the response is correct and whether the UE 2006 can be considered authenticated.

[0150] The RIF 2102 sends an AA-Challenge-Check-Req message to the AAA server 2028. This message is used to forward the challenge response from the UE 2006 to the AAA server 2028. This message may also include the following information: The challenge vector sent to the UE 2006 in the Auth-Challenge-Req ● UE-T-ID associated with the UE

[0151] The AAA server uses the challenge vector, the UE-T-ID, and the UE's challenge response to verify that the response is appropriate and was provided by the UE 2006 associated with the UE-T-ID. The AAA server 2028 responds with an AA-Challenge-Check-Resp message that includes an indication of whether the authentication was successful. Because the UE 2006 is now authenticated, the AAA server 2028 may choose to send subscription information associated with the UE 2006 to the RIF 2102. For example, the response may include the following information: UE-T-ID and UE-T-ID-NEW. In case of successful authentication, the AAA server 2028 may provide a new UE-T-ID, i.e. UE-T-ID-NEW, that should be assigned to the UE. The original UE-T-ID may now be considered invalid. ● UE-DEVICE-TYPE ● UE-SISF-ID ● UE-SLICE-DESCRIPTORS ● UE-SERVICE-DESCRIPTORS ● CONNECTION-REFERENCE-ID CHARGING-REFERENCE-ID

[0152] (Slice Instance Selection Function (SISF)) SISF2024 has the following functionality: 1) Allocating slice instances to the UE or performing additions / deletions / modifications within the set of network slice instances assigned to the UE, for example, when the UE 2006 first connects to the core network or when there is a UE service profile change or UE location. 2) Connect the UE 2006 to the selected network slice instance and notify the session management function to configure / set up the required NF for the UE. This may be the result of a new slice request from the UE 2006. 3) Modify network slice instance allocation based on input from SIMF2026. 4) Report network slice instance needs / usage to the slice instance management function (SIMF) 2026. 5) Monitor and respond to context changes (e.g., UE location changes). 6) Manages network initiated connection requests. 7) Configure CNEP2020 to route traffic to the appropriate network slice instance.

[0153] Some actions will trigger one or more of the above functionalities, which are described in the following sections.

[0154] The SISF 2024 provides a slice ID that is assigned to the UE 2006 for a particular service or set of services. Because the SISF selects a network slice, it may also be referred to as a network slice selection function (NSSF). Because the SISF selects a network slice from a list or repository of network slices, it may also be referred to as a network slice repository function (NSRF). The SISF 2024 may additionally provide configuration for the slices. For example, two UEs may access the same slice to obtain services. However, the slices may be configured differently for each UE. The configuration may refer to specific NFs with slices that handle traffic from each UE 2006 and the order in which the NFs handle traffic from each UE. Currently, there is no distinction between network slices and network slice instances. However, in this type of implementation, the distinction between network slices and network slice instances may be that a network slice refers to a specific set of deployed NFs, while a network slice instance refers to a specific chaining or ordering of NFs within the slice that provides services.

[0155] (Allocate network slice instances based on new UE 2006 connecting to underlay network 2004) After authenticating and authorizing the UE, the RIF 2102 will query the SISF 2024 to determine the network slice instances to which the UE 2006 may connect. The message used to query the SISF 2024 may be referred to as SISF-Req. The query may be based on the following information: ● UE-SLICE-DESCRIPTORS - One or more slice descriptors may be associated with a UE. A slice descriptor may simply describe the requirements for a slice. A slice descriptor may also be referred to as a slice template. ● UE-SERVICE-DESCRIPTORS - One or more service descriptors may be associated with a UE. The service descriptors describe the types of services that the UE 2006 expects to have access to. ● UE-DEVICE-TYPE - The device type may describe the general manner in which the UE 2006 will be used. For example, an MTC device type may imply that the UE 2006 only requires low data rates. The device type may indicate that the UE 2006 is limited to accessing a certain number or type of network slice instances. The device type may indicate that it is used for emergency services and should be assigned to a slice that has a low probability of being disabled during an emergency situation. ● LOCATION-INFORMATION - The assigned slice may depend on the location of the UE. For example, UEs in a certain area (i.e., a school) may be constrained from viewing certain content, or certain content may be limited to UEs in a certain area (i.e., a stadium or live event). The location of the UE may also influence slice selection in the sense that the SISF 2024 may want to assign slices with computational resources that are geographically close to the UE 2006, for example, to facilitate low latency augmented reality applications. The location of the UE may be provided by the UE 2006 itself (i.e., in GPS format), or the location may be inferred by the identity of the radio station to which the UE 2006 is connected. Thus, the LOCATION-INFORMATION may be the identity of the RAT / RAN or radio station to which the UE 2006 is connected. ● UE-HPLMN-ID - The UE's home network identifier may be used to determine the slice to which the UE 2006 should be told to connect. For example, the SISF 2024 may assign different slices depending on the roaming agreements it has with each operator. ● UE-ID - The UE-ID identifies the particular UE 2006 that is associated with the query. ● RAT-TYPE-INDICATOR - indicates the type of RAT with which the RIF 2102 is interfaced. This may indicate the type of service provided by the RAT. For example, the RAT-TYPE-INDICATOR may indicate that the RIF 2102 is interfaced with a low throughput, low mobility RAT that may be suitable for IoT applications rather than enhanced mobile broadband. This will provide the SISF 2024 with additional information about the slice instance to be selected for a UE accessing the network via this RAT. If the RAT does not provide this indicator, the SISF 2024 can select from all available slice instances rather than a subset optimized for the specific RAT type. The RAT-TYPE-INDICATOR should match the Rat type. ● Third Party Service Agreement - For example, the UE's subscription information may already be configured with information indicating that a third party will sponsor the connection.

[0156] When the above information is provided by the RAT to the SISF 2024 through the RIF 2102, the RAT may have obtained certain fields from the UE 2006 itself, for example, when the UE 2006 made its initial connection or authentication / authorization request. The RAT (or RIF 2102) may also have obtained certain fields from a subscriber database, for example, the UE's home network operator may have provided the information to the RAT (or RIF 2102) once the UE 2006 is authenticated and authorized, or the RAT (or RIF 2102) may have queried the UE's home network operator for the information after the UE 2006 is authenticated and authorized.

[0157] The SISF 2024 may be located in the RAT, or may be located remote from the RAT but in the VPLMN (i.e., owned by the same owner of the RAT). The SISF 2024 may respond to the RAT's query with the information listed below, or the SISF 2024 may respond to the RAT (or RIF 2102) with the identity of another remotely located SISF 2024 that should be queried on its behalf. For example, the SISF 2024 may determine, based on the UE's identity, that the SISF 2024 in the UE's home network should be queried. In this type of scenario, the function in the RAT (or RIF 2102) may be a "SISF resolution function" and the SISF 2024 may be in the UE's home network. Alternatively, the SISF in the RAT (or RIF 2102) may resolve the appropriate SISF function and act as a proxy between the RAT and the appropriate SISF function. The SISF 2024 may also reside in the RAT interface function.

[0158] The SISF 2024 may be located in the UE's home network. The UE's identifier may be used by the RAN to locate the appropriate SISF. For example, the UE's identity may identify the UE's home network operator, and the RAN (or RIF 2102) may use the home network identifier to look up the SISF address, or a DNS query for the UE's identifier may resolve the SISF identity. For non-3GPP RATs, the SISF 2024 will either be co-located with a RAT interface function or will reside within the ULN 2004. For non-3GPP RATs, one way the SISF 2024 may present itself to the UE 2006 is as a DHCP server.

[0159] The response message from the SISF 2024 may be referred to as SISF-Resp. The response may include the following information: A list of allocated network slice instance identifications and associated slice descriptions. Each identification may include the following information: NSI-ID: Network Slice Instance Identifier ○ The communication types supported by the slice (e.g. SMS, IP, non-IP) o IPOC - Initial Point of Contact. This can be a DHCP server. o UE-SLICE-DESCRIPTOR-INDEX - the associated UE-SLICE-DESCRIPTOR or UE-SERVICE-DESCRIPTORS provided in the query message. Alternatively, this can be an index associated to a slice or service description from the query. For example, a value of 3 may indicate that this slice will fulfill the service or functionality required by the slice or third party service described in the query. o A list of network slice descriptions or templates (called SLICE_DESCRIPTOR). Each description or template may contain the following information that may be used to dynamically instantiate a desired instance: Services Offered: An indication of the type of service offered by the slice, e.g., Critical Communications, Massive IoT, Enhanced Mobile Broadband, etc. Latency: This includes an indication of the latency associated with the slice. For example, typical control plane latency for initial attach, handover, etc., and typical user plane latency. Value-added services provided: A list of value-added services provided by the slice, e.g., parental control, caching of user plane content, etc. Mobility Support: An indication of the type of mobility that the slice supports. Some slices do not support any mobility. For example, a UE 2006 associated with a slice that does not support mobility will not be tracked by the core network. o UE-SLICE-AVAILIBILITY - A time (or a list of times) when the slice is available to this UE. This can be used to indicate the initial connection time to the UE. This can also be used when multiple slices are assigned to the same UE 2006 to create automatic switching by the UE 2006 between slices.

[0160] The SISF 2024 may be considered a "core network function" and therefore may not be virtualized. Some functions may need to be accessed prior to the UE 2006 connecting to a slice because the UE 2006 must select a slice to connect to before the connection procedure begins. When the UE 2006 connects to a slice, all slices associated with the UE 2006 may interface with the SISF. Network slices may interface with the SISF 2024 via a SISF front-end (SISF-FE) NF.

[0161] The combination of SLICE_DESCRIPTOR and RAT-TYPE-INDICATOR will provide the SISF 2024 with the characteristics of the service that can be provided from the RAT through network egress. The SISF 2024 may therefore determine that the services required for the user's service profile cannot be satisfied by any slice instance, and therefore may recommend that the user seek an alternative RAT. This recommendation may be signaled to the UE 2006 via the OMA device management API and may trigger the UE 2006 to display a user interface message to the user indicating that they may wish to add support for a different RAT to their subscription. The device management signaling may be carried via an alternative slice instance, a default slice instance, or via the underlay network 2004, assigned to the UE.

[0162] (Modify allocated network slice instance allocation based on UE profile changes) If the UE 2006 changes its capabilities or session profile, the SISF 2024 is notified so that it can allocate a new network slice instance to the UE. The RIF 2102 may send a SS_Profile_Change_Req to the SISF 2024. The query may include the following information: ● UE-ID - The UE-ID identifies the particular UE 2006 that is associated with the query. ● UE-SLICE-DESCRIPTORS - One or more slice descriptors may be associated with a UE. A slice descriptor may simply describe the requirements for a slice. A slice descriptor may also be referred to as a slice template. ● UE-SERVICE-DESCRIPTORS - One or more service descriptors may be associated with a UE. The service descriptors describe the types of services that the UE 2006 expects to have access to. ● RAT-TYPE-INDICATOR-RIF2102 indicates the type of RAT being interfaced.

[0163] In response to the profile change, the SISF2024 may change the network slice instance allocated to the UE2006 via an SS_Profile_Change_Resp, which may include the parameters enumerated in the SISF-Resp message and the parameters listed below. ● A list of allocated network slice instance identifications and associated slice descriptions. SLICE_DESCRIPTOR for each of these network slice instance identifications, which contains a network slice description or template. Each description or template may contain the following information, which may be used to dynamically instantiate the desired instance: ● RAT-TYPE-INDICATOR-RIF2102 indicates the type of RAT being interfaced.

[0164] Again, SISF2024 may determine that the services required for the user's service profile cannot be satisfied by any Rice instance via the currently used RAT, and may therefore recommend that the user seek an alternative RAT.

[0165] (Connecting UE2006 to a Network Slice instance) The RIF 2102 may request that the SISF 2024 connect the UE 2006 to a network slice instance. This is accomplished through an SS_Slice_Req, which may include the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that is associated with the query. ● NSI_ID - One of the slices provided by SISF2024 (e.g., after initial connection or after a profile change). ● UE-SERVICE-DESCRIPTORS - One or more service descriptors may be associated with the UE. The service descriptor describes the type of service that the UE 2006 expects to access. This may be a subset of the UE-SERVICE-DESCRIPTORS and is used by the SISF 2024 as an indication of the connection that is triggering this request to connect to the slice. The UE 2006 may optionally not provide a UE-SERVICE-DESCRIPTORS, in which case the SISF 2024 may take this as an indication that the UE 2006 wants a basic default connection. The UE-SERVICE-DESCRIPTORS may be referred to as network slice selection assistance information (NSSAI) because this information assists the network in selecting a particular network slice instance. ● CONNECTION_ID: The identifier of the connection associated with the query. ● RAT-TYPE-INDICATOR-RIF2102 indicates the type of RAT being interfaced. The SISF 2024 may query the SSF 2060 to verify that the UE 2006 has access to the slice and may connect the UE 2006 to the requested slice, or alternatively, may connect the UE 2006 to an alternative slice. One reason the SISF 2024 may connect the UE 2006 to an alternative slice is a non-match between the RAT-TYPE-INDICATOR and the requested slice. The SISF 2024 issues a response (SS_Slice_Resp) to the UE, which may include the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that is associated with the query. NSI_ID - the ID of the network slice instance assigned to the UE ● CONNECTION_ID: The identifier of the connection associated with the query. ● Slice_Connect_Cause-The reason for assigning the UE 2006 to this slice. This could be due to a subscription, lack of resources on the requested slice, etc. ● Slice_Operating_Parameters - Any restrictions associated with the slice, for example this may include a schedule of when a connection should use the slice. ● Connection_Parameters:--Core network parameters related to the connection, such as the IP address assigned to the UE 2006 (if applicable), sleep parameters, SM parameters, or other slice-related parameters such as the time the slice is available to the UE, where the UE 2006 may access the slice, bandwidth and data rate limitations that should be enforced when accessing the slice, etc.

[0166] (UE autonomously changes network slice instance) The SISF2024 may autonomously decide to change the network slice instance to which the UE2006 is connected, for example, an existing slice may be deleted, a newly created slice by the SIMF2026 may be more suitable for the UE2006 connection, etc. The SISF2024 may send an SS_New_Slice message to the UE2006 (via the RIF2102), which may include the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that is associated with the query. ● List of slices NSI_ID - ID of the network slice instance to which UE2006 is connected ○ SLICE_DESCRIPTOR - slice description o CONNECTION_ID: Identifier of the connection associated with the query. If included, this tells the UE 2006 to start a new PDU connection with the offered slice. ○ Slice_Operating_Parameters ○ Connection_Parameters Receipt of the SS_New_Slice_Ack acknowledges that the UE 2006 has received the request.

[0167] (Change the network slice instance configuration) The SISF2024 may change the configuration of the network slice instance assigned to the UE. The SISF2024 provides the NSI_ID of the network slice instance being changed as well as information related to the new network slice instance. If the UE2006 is already connected to the network slice instance being changed, the SISF2024 may provide the Slice_Operating_Parameters and Connection_Parameters to the UE. If the UE2006 is not yet connected to the slice being changed, the UE2006 only updates its list of allocated slices (replaces the old slice information with the new slice information). The SISF2024 may change the slice using a SS_Change_Slice request message. The message may include the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that is associated with the query. ● List of changes to slices: ○ OLD_NSI_ID - ID of the network slice instance that is being changed o NEW_NSI_ID - ID of the network slice instance being added (if NEW_NSI_ID is either NULL or associated with a slice instance already assigned to the UE, the network slice instance change is effectively a network slice instance deletion.) ○ SLICE_DESCRIPTOR - slice description ○ Slice_Operating_Parameters (if UE2006 is already connected to OLD_NSI_ID) ○ Connection_Parameters (if UE2006 is already connected to OLD_NSI_ID) HARD / SOFT_TRANSITION_IND - indicates whether the transition between slices should be performed with a "make before break" connection. o Services_per_slice - If more than one slice is allocated after the transition, this indicates which services should be transferred to which slices.

[0168] (updates SIMF2026 for allocated slices) The SISF2024 may periodically provide status information to the SIMF2026 and assist the SIMF2026 in managing the network slice instances. The SISF2024 updates the SIMF2026 through a Slice_Usage_Update message. This message may include the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that triggered the update. ● UE-SERVICE-DESCRIPTORS - One or more service descriptors may be associated with a UE. The service descriptors describe the types of services that the UE 2006 expects to have access to. NSI_ID - the ID of the network slice instance currently assigned to the UE

[0169] (Manage UE location changes) When the UE 2006 changes its location, this may trigger the SISF 2024 to modify the slice instances allocated to the UE or to change the slice instance to which the UE 2006 is connected. The SISF 2024 is notified from the mobility management function, or any similar function that maintains UE location information. The SISF 2024 may be notified through a SS_Location_Change_Req message, which provides the SISF 2024 with the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that triggered the update. ● LOCATION-INFORMATION-UE location (eg, in GPS format). ● MOBILITY_STATUS - The UE 2006 may provide an indication of its associated mobility (low mobility, stationary, fast moving, etc.). For example, some slice instances may be targeted to low mobility UEs. The UE 2006 may have this information pre-configured or may dynamically determine this based on GPS, base station changes, etc.

[0170] (Manage new connection requests from PMF2050) When a network-initiated connection is requested for a UE, the PMF 2050 may trigger the SISF 2024 to allocate a slice instance to the connection. The SISF 2024 may be notified through an SS_Connection_Req message, which provides the SISF 2024 with the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that is being targeted. ● UE-SERVICE-DESCRIPTORS - one or more service descriptors that provide details of the connection request. ● REQUESTOR-ID - the application server or network function that initiated the request.

[0171] (Configuring CNEP2020 for routing) After connecting the UE 2006 to the slice, the SISF 2024 may provide routing information for the UE connection to the CNEP 2020. This allows the CNEP 2020 to route the connection to the appropriate network slice instance. The SISF 2024 may use a Connection_Config_Req message, which may include the following: ● UE-ID - The UE-ID identifies the particular UE 2006 that triggered the request. ● CONNECTION_ID: Identifier of the connection associated with the UE. ● NSI_ID - the ID of the network slice instance currently assigned to the UE. This may alternatively be an identifier to the CN ingress function on the network slice instance.

[0172] (Slice Instance Management Function (SIMF)) The SIMF 2026 is where the ULN 2004 interacts, which might traditionally be considered a virtualization layer or hypervisor. The SIMF 2026 is the ULN's interface for requesting that network slices be added, modified, or removed.

[0173] (Add / remove / modify slice instances) The SIMF 2026 is responsible for managing network slice instances. The SIMF 2026 may make its decisions based on management and network organization (MANO) functionality, which: ● Periodically retrieve status information (e.g. usage, load, latency, etc.) from the slice instances themselves. • Retrieve status information from SISF2024 about new UEs that are requesting a connection or whose profile has changed.

[0174] In addition, the SIMF 2026 can be directed to configure network slice instances through a graphical user interface (GUI) that allows the operator to create new slices or modify / delete existing slice instances. If there are any changes in slice instances (if an existing slice instance is deleted or modified, or a new slice instance is created), the SIMF 2026 should notify the SISF so that these updates can be taken into account during slice instance selection. The SIMF 2026 notifies the SISF 2024 through the New_Slice_Req, Modify_Slice_Req, and Delete_Slice_Req messages. Some of the contents of these messages are described below. New_Slice_Req NSI_ID - ID of the network slice instance being added ○ SLICE_DESCRIPTOR - slice description Modify_Slice_Req: NSI_ID - ID of the network slice instance being added ○ SLICE_DESCRIPTOR - slice description Delete_Slice_Req NSI_ID - ID of the network slice instance being added

[0175] New slice, slice modification, and slice deletion requests may be initiated by administrative or O&M means. For example, assume an operator signs a commercial agreement with a large smart grid operator that will take effect one month from signing. The operator may want to pre-reserve a certain amount of network capacity (i.e., a number of slice instances) before SISF2024 is triggered for its smart grid customers.

[0176] (Core Network Entry Point (CNEP) 2020) CNEP2020 may provide: Marking packets so that they can flow to the correct network function in the assigned slice instance. For example, the CNEP may mark traffic from a particular UE 2006 so that it is sent to the correct slice. Marking may also be based on information inserted by the UE 2006 to indicate the traffic or service type. ● Routing packets to the correct network slice instance (i.e., the correct IRF) based on configuration from the SISF. This may be based on UE_ID, CONNECTION_ID, or some other identifier. Routing control plane packets to the appropriate control plane network function within the ULN2004 ● Interworking between RIFs, enabling cooperation between RATs and potentially multi-RAT operation (where the UE connection is split across two or more RATs simultaneously).

[0177] (Interconnection and Routing Function (IRF)) IRF2058 features include: ● Store the binding between the identity of the UE and the interface layer identity (e.g., instance number) of each serving NF that has an active session for the UE 2006. For NFs that do not interface directly with the IRF 2058, e.g., in a roaming scenario, the IRF 2058 stores the identities of IRFs 2058 of distant PLMNs through which these NFs are reachable. ● Updating the binding repository when the identity of the serving NF changes for a given UE, for example due to UE mobility, load rebalancing (i.e. virtual machine shrink or grow), or restoration reasons. ● Inspect the message header to determine the identity of the UE 2006 (to which the message is being sent) and the destination NF. For the UE identity, consult an internal binding repository to determine the interface layer identity (e.g. instance number) of the destination NF or the identity of the remote IRF 2058. Route the message accordingly. Optionally, implementing message authorization based on operator configuration, e.g. if the operator configuration prohibits NF1 from invoking a certain message ("Change APN-AMBR of UE") towards NF2, IRF2058 rejects the corresponding message. Optionally, implementing overload control, e.g. pacing of messages sent to a given NF based on its load / overload status, thus protecting NFs during extensive signaling.

[0178] (Mobile call ingress function) The Mobile Originated Ingress (MOI) function is the point at which the underlay network 2004 connects to a network slice for MO user plane communications. The CNEP 2020 receives the PDU from the UE 2006 and determines the network slice to transmit the PDU. The PDU is then transmitted to the MOI 2040 of the appropriate selected network slice. In response to receiving the PDU, the MOI 2040 may verify that the PDU originates from a UE / underlay network combination that is authorized to transmit the PDU to the network slice. The MOI 2040 may transmit a reject response to the CNEP 2020 if the PDU does not originate from an authorized UE / underlay network combination. To minimize latency, the CNEP may reside in a RIF closer to the base station or access point.

[0179] Assuming the PDU is authorized and properly formatted, the MOI 2040 may wrap the PDU in a new header, which may contain information about the PDU for the NF to forward.

[0180] For example, based on the header information that the UE 2006 attached to the PDU, the MOI 2040 may determine that the PDU is an SMS message and attach information indicating that the PDU should be routed to a particular NF that serves as an interface to an SMS-SC, an IW-MSC, or a legacy IW-MSC or SMS-SC. If the MOI 2040 determines that the PDU is an SMS PDU destined for another operator's network, the MOI 2040 may attach information indicating that the PDU should be routed to the other operator's network, specifically, the packet may be sent to the IRF-IWK 2030 in the underlay network 2004 such that the packet can then be forwarded to the IRF-IWK 2030 of the target network.

[0181] In another example, based on the header information that the UE 2006 attached to the PDU, the MOI 2040 may determine that the PDU is an IP packet and attach information indicating that the PDU should be sent to a particular NF serving as an IP anchor point. The MOI 2040 may detect, based on the header information, that the IP anchor resides in another network slice or in another operator's network and then attach information indicating that the PDU should be sent to the IRF-IWK 2030 so that it can be forwarded to the appropriate destination network.

[0182] In another example, based on the header information that the UE 2006 attached to the PDU, the MOI 2040 may determine that the PDU is an unstructured, non-IP packet and attach information indicating that the PDU should be sent to a particular NF that can be used to forward the packet to a destination. The MOI 2040 may detect, based on the header information, that the packet needs to be sent to an NF residing in another network slice or in another operator's network and then attach information indicating that the PDU should be sent to the IRF-IWK 2030 so that it can be forwarded to the appropriate destination network.

[0183] The MOI 2040 may attach header information to the PDU, indicating other network functions that should process the PDU and the order in which the NFs should process the data. For example, the header may be formatted similarly to the NSH. The MOI 2040 may also add metadata to the header. The metadata may be used by other NFs to help process the PDU. For example, the metadata may indicate that the packet has a certain priority, originated from a particular location, etc.

[0184] (Mobile call exit function) The Mobile Originated Egress (MOE) function 2046 is the last NF that processes a user plane packet before it egresses from the network slice. The MOE 2046 removes header information, such as the NSH, that was used to route the packet through the slice and between NFs within the slice.

[0185] There may be multiple types of MOEs based on the PDU type. For example, an MOE 2046 may be defined for SMS PDUs and the MOE 2046 may send the PDU to the SMS-SC. In this example, the MOE 2046 may act as an IW-MSC on its interface to the SMS-SC. In another example, the MOE 2046 may process IP packets. The MOE 2046 may remove header information specific to processing within a slice and send the IP packet to an IP network. In another example, the MOE 2046 may detect that the packet is an unstructured non-IP packet and send the packet directly to a server, such as an M2M server, an application server, etc. The MOE 2046 may know the destination of the non-IP packet based on an identifier in the header of the PDU attached by the UE 2006, the SM NF 2048, the MOI, or another NF. The SM NF 2048, the MOI 2040, or other NFs may know the destination of the non-IP data based on information provided by the UE 2006 during session establishment or based on provisioned subscription information. The non-IP packets may be tunneled from the MOE 2046 to a destination server.

[0186] (Mobile Termination Ingress Function) The Mobile Termination Ingress (MTI) function 2044 is the point where the network slice connects to the PDN or directly to a server for user plane communications. The PDN (or server) sends IP packets, SMS messages, or unstructured non-IP data to the MTI 2044.

[0187] When the PDU type is IP, the MTI 2044 may be the IP anchor point of the UE 2006. If the MTI 2044 is not considered part of a network slice, the MTI 2044 will determine the appropriate network slice to transmit the data to based on the destination and source IP addresses and port numbers. The determination of the network slice to transmit the data to may also be based on information from a DPI engine that has examined the traffic and determined the type of application associated with the PDU.

[0188] When the PDU type is SMS, the MTI 2044 may act as an SMS-GMSC that receives the SMS data from the SMS-SC. The MTI 2044 may then forward the PDU to the appropriate destination slice or NF based on the destination MSISDN, application port ID, data coding scheme, and protocol identifier SMS header fields.

[0189] When the PDU type is unstructured non-IP, the MTI 2044 may use information in the header to determine which NF or network slice to forward the data to. The determination may also be based on the source address or identifier of the non-IP data. When the non-IP data is tunneled to the MTI 2044 (e.g., in an IP tunnel), the MTI 2044 will remove the header from the IP tunnel before forwarding the packet further into the network slice.

[0190] Based on the information provisioned during session setup, the MTI 2044 may attach a packet marking to the PDU before forwarding it into the network slice. The packet marking may indicate the requested QoS treatment (i.e., priority, latency requirements, etc.).

[0191] (Mobile Termination Exit Function 2042) The mobile termination egress (MTE) function 2042 is the last NF that processes user plane packets before they exit the network slice and are sent to the underlay network 2004 for transmission to the UE 2006. The MTE 2042 removes header information, such as the NSH, used to route packets through and between NFs within the slice.

[0192] There may be multiple types of MTEs based on the PDU type, for example, MTE 2042 may be defined for SMS PDUs, MTE 2042 may be defined for IP data, and MTE 2042 may be defined for unstructured non-IP data.

[0193] The MTE 2042 may attach new headers to the PDU so that the UE 2006 may determine how to process the PDU. For example, the MTE 2042 may add headers including a bearer identifier, a tunnel identifier, a traffic type identifier, a destination application identifier, or an SMS header so that the UE 2006 can route the PDU to the appropriate application in the UE 2006. The MTE 2042 may have obtained this information during session setup from the SM NF 2048, from the UE 2006 itself, or from subscription information.

[0194] (Session Management (SM) function) The session management function is responsible for managing the PDU sessions of the UE within the network slice instance. These sessions can be IP-based, non-IP-based, as well as connectionless. The session management function is responsible for: ● Control / management of user plane traffic of PDU sessions. This may involve preparing PDU session "flow information" that provides an indication of the path that packets of a particular PDU session should take. For example, the SM function 2048 may set up PDU forwarding and screening rules associated with the PDU session in various user plane network functions. Alternatively, the SM function 2048 may provide the flow information to the NF (e.g., the CNEP 2020, the MO ingress function, or the MT ingress function) that is responsible for marking user plane packets. ● Assign an IP address to the UE2006 (for IP-based PDU sessions) ● Manage the separation or aggregation of PDU sessions across multiple access network paths. For example, the UE 2006 may be connected to a 3GPP RAT and a Wi-Fi RAT simultaneously. The PDU sessions may be split across both access network connections. The SM function 2048 configures the separator / aggregator network functions with the information needed to properly split / aggregate the PDU sessions. This may be through policies or rules. For example, ○ Alternating transmission of PDU packets between access networks Fair division of PDU session packet transmissions across different access networks o Transmitting packets across the access network and providing the highest instantaneous transmission rate based on, for example, some channel quality indicator

[0195] (Mobility Management (MM) function) The mobility management function maintains the mobility context for all UEs in the network. It is responsible for: Tracking the location of the UE 2006, for example as the UE 2006 moves from one access network base station to another, or from one RAT to another. ● Evaluate the UE mobility profile. For example, the MM function 2022 may determine whether the UE 2006 is stationary, fast moving, portable, etc. It may also determine whether the determined mobility profile corresponds to a profile stored in the UE subscription. If not, it may take proactive measures. For example, the MM function 2022 may notify the SISF 2024 to remove the UE 2006 from the assigned network slice instance. It should be understood that the MM function may be co-located or integrated with another network function, such as a RIF or CNEP. ● Provide mobility information to other network functions. This may be based on a request, for example, an NF may specifically query the MM 2022 to determine the location of one UE or a group of UEs. Alternatively, this may be based on a subscription model, whereby a network function subscribes to be notified when the UE 2006 changes its mobility context. Alternatively, the MM function 2022 may push location information to one NF, either when a mobility event occurs or periodically. For example, the MM function 2022 may notify the SSF 2060 about a change in UE location so that this can be updated in the subscription database. Provides UE paging and supports mobile terminated communications

[0196] (5G Network Procedure (Underlay Network Based)) The 5G network procedures described in this section relate to how the UE 2006 makes an initial connection to the RAT, the core network, and the network slices. They are all based on the assumption that the UE 2006 requires some control plane connection to functions in the RAN and / or the core network that are not virtualized. These "always present" / "non-virtualized" functions are referred to as the underlay network 2004. The underlay network 2004 is the functionality that the UE 2006 uses to make an initial connection to the RAN, the core network, and the network slices. Table 6 summarizes the procedures described in this section. [Table 6]

[0197] (Initial connection procedure) During the initial connection procedure: The UE 2006 establishes a connection to the RAT. ● Provide the RIF2102 with a temporary identifier (UE-T-ID) from which the RIF2102 resolves the HPLMN identifier. - The RIF 2102 uses the temporary identifier to contact the HPLM to initiate the process by which the UE 2006 is authorized and authenticated. ● The RIF2102 communicates with the SISF2024 and determines the network slice to which the UE2006 should connect. - The UE 2006 is told which slice to connect to.

[0198] After the initial attachment procedure, the UE 2006 begins to connect to the network slice. This process is described with respect to Figures 24 and 25. It should be understood that the initial attachment procedure may also be referred to as a registration procedure because the initial attachment procedure involves a step of authorizing the UE to receive services from the network.

[0199] As a general principle, the UE 2006 should never provide its private subscription identifier to the RIF 2102. The UE 2006 should only provide a temporary identifier to the RIF 2102. A new temporary identifier will be provided to the UE 2006 periodically, or a temporary identifier may be pre-provisioned for when the UE 2006 is connecting to the network for the first time. The UE 2006 may provide a GUI that allows the user to enter a temporary identifier that may be used by the UE 2006 the next time it connects to the system. An example of a GUI that allows the user to configure its temporary identifier is shown in FIG. 23. Users may be provided with a temporary identifier as part of activating their account. In addition, device management procedures may be used to push a new TID to the UE 2006.

[0200] FIG. 22 is a diagram illustrating the initial connection procedure.

[0201] In step 0 of FIG. 22, the UE 2006 will be provisioned to check for available networks. The UE 2006 will be provisioned to check if an access point of a certain RAT type and a certain frequency is available. In response to detecting that an acceptable RAT and frequency combination exists, the UE will listen to information broadcast by each of the associated access points and make a decision regarding the RAT to connect to. Some access points may broadcast information associated with access points of another RAT type. For example, a 5G cellular base station may broadcast information about nearby non-3GPP (e.g., Wi-Fi) access points, their operating frequencies, their SSIDs, etc. As shown in FIG. 20A, the RIF 2102 may connect to one or more access points and provide it with information to be broadcast. The information broadcast by the RIF 2102 and how the UE 2006 uses the information to decide to send a connection request to the RIF 2102 are described above. Alternatively, the access points may be provisioned with broadcast information via O&M procedures.

[0202] In step 1 of FIG. 22, after determining, based on observed broadcast information, that it desires to connect to a particular access point, the UE 2006 sends an Initial-Connection-Req message to the RIF 2102.

[0203] In step 2 of Figure 22, the RIF 2102 sends an AA-Vector-Req message to the AAA server 2028 in the UE's HPLMN. This message is used to obtain an Authentication and Authorization (AA) AA vector for the UE 2006.

[0204] In step 3 of Figure 22, the AAA server 2028 sends an AA-Vecto-Resp message to the RIF 2102. As shown in parts 3a) and 3b) of this step, the AAA server 2028 may obtain the AA vector from the SSF 2060.

[0205] In step 4 of FIG. 22, the RIF 2102 sends an authentication challenge to the UE 2006.

[0206] In step 5 of FIG. 22, the UE 2006 sends an authentication challenge response to the RIF 2102.

[0207] In step 6 of FIG. 22, the RIF 2102 sends a request to the AAA server 2028 and verifies that the response provided by the UE 2006 is correct.

[0208] 22, step 7 may optionally choose to obtain the UE subscription information from a subscriber database (i.e., HLR, HSS, or UDR 2032) if the AAA server 2028 does not have the subscription information or slice identifier so that it can be provided to the RIF 2102 since the AAA server 2028 knows that the UE 2006 is now authenticated and authorized. As part of this query, the subscriber database may obtain a slice identifier from the SISF 2024 that can be used by the UE 2006. If a slice identifier is obtained in this step, steps 10-12 may not be required as the RIF 2102 may simply forward the slice identifier to the UE 2006 as shown in step 12.

[0209] In step 8 of Figure 22, the AAA server 2028 responds to the IF 2102 with an indication of whether the UE's response was correct and whether the UE 2006 can be considered authenticated. This response may also include the subscribe data provided to the RIF 2102 in step 7.

[0210] In step 9 of FIG. 22, the RIF 2102 queries the SISF 2024 to determine a network slice to assign to the UE 2006. In step 10 of FIG. 22, optionally, the SISF 2024 may trigger the creation of a slice instance by the SIMF 2026 that would meet the needs of the UE 2006. The SISF 2024 may provide a slice ID to the RIF 2102 and indicate the time the slice will be available. The SISF 2024 may also query another NF, application server, or server to see if it will voluntarily sponsor the UE's connection. The SISF's query may be based on an indication in the UE's request or subscription information that the flow will be sponsored.

[0211] In step 11 of Figure 22, SISF2024 responds to RIF2102 with a list of network slice identifiers.

[0212] In step 12 of FIG. 22, the RIF 2102 responds to the UE's connection request with an Initial-Connection-Resp message. If the UE 2006 indicated in the Initial-Connection-Resp that this is a handover operation, this message may indicate that the UE's existing slice connection is maintained, or this message may provide the UE 2006 with a slice identifier with which the UE 2006 is already associated. If this message includes a slice identifier to which the UE 2006 should connect, the UE 2006 (or the RIF / SISF) may then initiate a slice connection procedure toward the identified slice.

[0213] It is understood that the entities performing the steps illustrated in FIG. 22 may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 22 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in FIGS. 36-37, which computer-executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 22. It is also understood that the functionality illustrated in FIG. 22 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 22 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer-executable instructions (e.g., software) it executes.

[0214] (Assign new slice instance to UE2006 (ULN based)) The procedure of allocating a new slice instance to a UE may be initiated when the UE's service profile or location changes.

[0215] A service profile change of the UE may be initiated by the UE 2006. This may occur when a new app is installed or launched for the first time.

[0216] A service profile change for the UE may be network initiated. This can occur when there is a change in subscription data, a request to activate a service from an OTT service via the SCEF 2054, or an indication from the NF that some type of downlink or uplink traffic has been detected for the UE 2006.

[0217] The following sections provide details of the new slice allocation for ULN-based scenarios.

[0218] (Allocating a new slice instance to the UE - UE initiated) In a UE-initiated, ULN-based procedure for allocating a new slice instance to a UE, it is assumed that the UE 2006 already has information that can be resolved to a network slice instance ID by the SISF 2024. This information may be a service profile, a slice FQDN, or some other slice identifier.

[0219] The UE 2006 will provide this information to the SISF 2024 via the RIF 2102, which will resolve the information into a set of network slice instance IDs that will be provided to the UE 2006 and subsequently used by the UE 2006 to connect to the network slice. The slice instance IDs provided to the UE 2006 may be temporary identifiers that may only be used by the UE 2006 or a group of UEs to connect to a particular slice, thus hiding the internal slice identifiers from the UE 2006.

[0220] After this procedure, the UE 2006 will have at least one new network slice assigned to it, but the UE 2006 may not yet be connected to the slice. The UE 2006 may connect to the slice as part of a subsequent procedure. Alternatively, this procedure may also be used to initiate the slice attachment process.

[0221] FIG. 24 is a diagram illustrating a UE-initiated ULN-based new slice instance allocation call flow.

[0222] In step 0 of Figure 24, it is assumed that the UE 2006 already has information about the services it wants to access. For example, it may have received a service profile in the initial RAT attach procedure (see Figure 22), a user may have manually entered a new service profile into the UE 2006, or an application level event on the UE 2006 may have caused the UE's OS to modify the UE's service profile or create a new service profile. It may also have been provisioned with a service profile or received a service profile from the network in the procedures of Figures 26 and 27.

[0223] In step 1 of Figure 24, the UE 2006 sends a New-Slice-Req message to the RIF 2102. This message includes a list of services that the UE 2006 wants to be assigned, and may be the same as the SS-Slice-Req.

[0224] In step 2 of Figure 24, the RIF 2102 sends an SS-Slice-Req message to the SISF 2024 to request allocation of one or more slice instances to the UE 2006. The SISF 2024 may optionally forward the request to a Subscription Service Function, which will respond with an indication of whether the requested slice instances are part of the user's subscription.

[0225] In step 3 of Figure 24, the SISF 2024 responds to the RIF 2102 with an SS-Slice-Resp message indicating that a new slice instance has been successfully assigned to the UE 2006 or that a different slice instance is assigned to the UE 2006 (the network overrides the UE request). If the UE request was made using a reference ID, the network may override the UE request without the UE 2006 being aware of it.

[0226] In step 4 of FIG. 24, SISF2024 will notify the session instance management function of the network slice instance to which UE2006 has been assigned and will inform it that it now has an additional assignment by sending a Slice-Notify message, which will include at a minimum a UE identifier.

[0227] In step 5 of Figure 24, the RIF 2102 confirms that the UE 2006 is assigned to a network slice instance by sending a New-Slice-Resp message. In the event that the assigned network slice instance provides IP connectivity, this step may be used to assign an IP address to the UE 2006 or direct the UE 2006 to a DHCP server through which the IP address assignment procedure may be completed (avoiding the usual broadcast query).

[0228] It is understood that the entities performing the steps illustrated in FIG. 24 may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 24 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in FIGS. 36-37, which computer-executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 24. It is also understood that the functionality illustrated in FIG. 24 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 24 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer-executable instructions (e.g., software) it executes.

[0229] (Allocating a new slice instance to the UE - ULN initiated) In a ULN-based, ULN-initiated procedure of allocating a new slice instance to a UE, the UE 2006 is provided with a new slice instance as a result of an action in the ULN 2004. Exemplary causes of this initiation may be a change in the user's profile, subscription, or online charging. In cases where the network slice instance provides IP connectivity, the UE 2006 will either be assigned an IP address or be directed to a DHCP server through which the IP address allocation procedure can be completed (avoiding the usual broadcast queries).

[0230] FIG. 25 is a diagram illustrating a ULN-initiated ULN-based new slice instance allocation call flow.

[0231] At step 0 of Figure 25, the UE profile and / or subscriptions may optionally be modified prior to a ULN2004 initiated new slice instance procedure, which is described with respect to Figures 26 and 27.

[0232] In step 1 of FIG. 25, for example as a result of a profile or subscription change, the SISF 2024 will send an SS-New-Slice message to the RIF 2102, which will include the slice instance ID to be assigned to the UE 2006.

[0233] In step 2 of FIG. 25, the RIF 2102 will send a New-Slice-Assign message to the UE 2006, which will include one or more slice instance IDs.

[0234] In step 3 of FIG. 25, the UE 2006 will respond to the RIF 2102 with a New-Slice-Resp message indicating that it is now confirming the assignment to the new slice instance provided to it in the New-Slice-Assign message.

[0235] In step 4 of FIG. 25, the RIF2102 will send an SS-New-Slice-Resp message to the SISF2024, confirming that the UE2006 has been assigned to a new network slice instance.

[0236] In step 5 of FIG. 25, SISF2024 will notify the session instance management function of the network slice instance to which UE2006 has been assigned and will inform it that it now has an additional assignment by sending a Slice-Notify message, which will include at a minimum a UE identifier.

[0237] It is understood that the entities performing the steps illustrated in FIG. 25 may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 25 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in FIGS. 36-37, which computer-executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 25. It is also understood that the functionality illustrated in FIG. 25 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 25 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer-executable instructions (e.g., software) it executes.

[0238] (Profile Change) The service profile stored in the network (e.g., in the Subscription Service Function and / or in the SISF) may be updated for various reasons. Profile changes may be initiated by the UE 2006, the ULN 2004, or the network. The profile may have changed due to administrative action or due to a UE location change. Profile changes may be implemented over an existing IP connection (if present) or using the ULN 2004. The following sections describe the details of the profile change procedure for ULN-based scenarios.

[0239] (Profile Change - ULN-Based - UE Initiated) In a UE-initiated ULN-based profile change procedure, the UE 2006 will request a profile change, for example, in response to a new application being installed or launched for the first time. Upon completion of the profile change, the UE 2006 may be provided with one or more network slice instance IDs (or other identifiers that may be uniquely resolvable by the network to network slice instance IDs).

[0240] FIG. 26 is a diagram illustrating a UE-initiated ULN-based profile change.

[0241] At step 0 of FIG. 26, prior to the UE 2006 initiated profile change, the initial RIF connection procedure that provided it with connectivity with the ULN 2004 should have been completed (see FIG. 22).

[0242] In step 1 of Figure 26, the UE 2006 sends a Profile-Change-Req message to the RIF 2102, for example as a result of installing a new application or launching an application for the first time. The Profile-Change-Req message will include, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the types of services the UE 2006 expects to access.

[0243] In step 2 of Figure 26, the RIF 2102 will send an SS-Profile-Change-Req message to the SISF 2024, which may optionally forward the message to a Subscription Service Function. The SS-Profile-Change-Req message will contain, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the type of services the UE 2006 expects to access.

[0244] In step 3 of FIG. 26, if the Subscription Service Function was sent an SS-Profile-Change-Req in step 2, it may respond to the SISF 2024 confirming that the profile change is acceptable given the UE subscription. Alternatively, the SISF 2024 may independently respond to the SS-Profile-Change-Resp message to indicate confirmation that the UE profile has been updated. The SISF 2024 may optionally include one or more network slice IDs (or other identifiers that can be uniquely resolved by the network to network slice instance IDs) along with the SS-Profile-Change-Resp message.

[0245] In step 4 of Figure 26, the RIF 2102 will send a Profile-Change-Resp message to the UE 2006 indicating that the UE profile change procedure has been completed by the ULN 2004. This message may be identical to the SS-Profile-Change-Resp message sent in the previous step.

[0246] It is understood that the entities performing the steps illustrated in FIG. 26 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 26 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 26. It is also understood that the functionality illustrated in FIG. 26 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 26 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0247] (Profile Change - ULN-Based - ULN-Initiated) In a ULN-initiated ULN-based profile change, the ULN 2004 will request a profile change, for example, in response to a subscription change or an OMA device management command. Upon completion of the profile change, the UE 2006 may update its SIM card OS configuration based on the new profile assigned by the network. In addition, the UE 2006 may be provided with one or more network slice instance IDs (or other identifiers that may be uniquely resolvable by the network to network slice instance IDs).

[0248] FIG. 27 is a diagram illustrating ULN-initiated ULN-based profile changes.

[0249] At step 0 of FIG. 27, prior to the UE 2006 initiated profile change, the initial RIF connection procedure that provided it with connectivity with the ULN 2004 should have been completed (see FIG. 22).

[0250] In step 1 of FIG. 27, optionally, the subscription service function sends an SS-Profile-Change-Req message to SISF2024 as a result of a change in user subscription or as a result of an OMA device management command. The subscription service function sends the SS-Profile-Change-Req message to SISF2024, which forwards the SS-Profile-Change-Req message, and may optionally include one or more network slice instance IDs (or other identifiers that may be uniquely resolvable to network slice instance IDs) to the RIF2102.

[0251] In step 2 of Figure 27, the RIF 2102 will send a Profile-Change-Req message to the UE 2006. The Profile-Change-Req message will include, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the types of services that the UE 2006 expects to access.

[0252] In step 3 of FIG. 27, the UE 2006 responds with a Profile-Change-Resp message indicating that it has updated its profile based on the Profile-Change-Req message in one or more of the SIM, OS configuration, or other device configuration memories.

[0253] In step 4 of Figure 27, the UE 2006 responds with a Profile-Change-Resp message indicating that it has confirmed the update of its profile based on the Profile-Change-Req message. Optionally, the SISF 2024 may forward the Profile-Change-Resp to a subscription service function.

[0254] It is understood that the entities performing the steps illustrated in FIG. 27 may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 27 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in FIGS. 36-37, which computer-executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 27. It is also understood that the functionality illustrated in FIG. 27 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 27 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer-executable instructions (e.g., software) it executes.

[0255] (Modify slice instance) The network may change the slice instance to which the UE 2006 is assigned for various reasons such as changes in user subscriptions, load balancing, etc. The slice instance change may be performed via an existing IP connection (if one exists) or via the ULN 2004. The following sections provide details of the slice instance change procedure for the ULN-based update case.

[0256] (Modify Slice Instance - ULN-Based - ULN-Initiated) When initiated by and performed via the ULN 2004, the procedure to change the slice instance will provide one or more network slice IDs (or other identifiers that are uniquely resolvable to network slice IDs) to the UE 2006. After this procedure, one or more of the UEs that were previously assigned a network slice instance will no longer be assigned, but will be replaced by a different network slice instance.

[0257] FIG. 28 is a diagram illustrating ULN-initiated ULN-based profile changes.

[0258] In step 0 of FIG. 28, optionally, the subscription service function may notify SISF 2024 of changes to the user subscription that may affect one or more of the slices currently assigned to the user.

[0259] In step 1 of Figure 28, the SISF 2024 will send an SS-Change-Slice message to the RIF 2102 based on updated subscription information, or due to an OMA device management command, etc. The SS-Change-Slice message will include one or more network slice IDs currently allocated to the user, as well as one or more network slice IDs that the UE 2006 should replace with the current allocation.

[0260] In step 2 of FIG. 28, the RIF 2102 will send a Change-Slice-Assign message to the UE 2006, which will contain at least the same information as was contained in the SS-Change-Slice message it received.

[0261] In step 3 of FIG. 28, UE 2006 will respond with a Change-Slice-Resp message indicating that it confirms the change of network slice instance based on the Change-Slice-Assign message it received.

[0262] In step 4 of Figure 28, the RIF 2102 will forward the response from the UE 2006 in an SS-Change-Slice-Resp message. This message will contain at least the same information that was included in the Change-Slice-Resp message from the UE 2006.

[0263] It is understood that the entities performing the steps illustrated in FIG. 28 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 28 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 28. It is also understood that the functionality illustrated in FIG. 28 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 28 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0264] (5G Network Procedures (Alternative Approaches)) The procedures in this section show alternative approaches such as connecting to a new network slice, changing network slices, changing profiles, etc.

[0265] The 5G network procedure described in this section assumes that the UE 2006 has a default slice to which it will connect at the initial attachment / attachment event, which may also provide IP connectivity. The procedure includes UE service profile update and network slice instance allocation and update, as summarized in Table 7. This section assumes that the initial attachment procedure (including broadcast) is performed as described with respect to FIG. 22. [Table 7]

[0266] (Allocate a new slice instance to UE2006 (alternative approach)) The procedure of allocating a new slice instance to a UE may be initiated by the UE 2006 (e.g., a new app is installed or launched for the first time) or the network may initiate it for various reasons, such as a change in user subscription, etc. The following sections explain the details of new slice allocation for various possible scenarios.

[0267] Allocating a new slice instance to the UE - UE initiated (alternative approach) A new slice instance (alternative approach) allocation procedure may be initiated by the UE 2006 to request one or more new network slices. It is assumed that the UE 2006 has already been provided with a network slice instance ID (or other identifier that can be uniquely resolved to a network slice instance ID by the SISF 2024) so ​​that after this procedure, the UE 2006 has these new network slices assigned to it.

[0268] FIG. 29 is a diagram illustrating UE-initiated new slice allocation (alternative approach).

[0269] At step 0 of Figure 29, the initial RIF attachment procedure that provided the UE 2006 with connectivity prior to the network-initiated profile change should have been completed (see Figure 22). IP connectivity may also have been established.

[0270] In step 1 of Figure 29, the UE 2006 sends a New-Slice-Req message to the RIF 2102. This message includes one or more slice instance IDs (or IDs that can be uniquely resolved to slice instance IDs by the SISF 2024) to which the UE 2006 wishes to connect.

[0271] In step 2 of FIG. 29, the RIF 2102 sends an SS-Slice-Req message to the SISF 2024 to request allocation of one or more slice instances to the UE 2006.

[0272] In steps 2a and 2b, the SISF2024 may check that the profile change is acceptable given the UE subscription, and therefore a subscription request / response pair of messages may be exchanged with the subscription service function.

[0273] In step 3 of Figure 29, the SISF 2024 will send an SS-New-Slice message with the network slice ID that the UE 2006 is to use in addition to the current allocation. The list provided by the SISF 2024 may be the same as the list requested by the UE 2006, a subset of it, or a different slice assigned.

[0274] If SISF2024 requests that certain functionality be transferred to the new slice, a list of transferred and / or enabled features is provided, as well as information about connection establishment for the new slice. A HARD / SOFT-TRANSITION indicator is sent to indicate a "make before break" transition for features that may support it.

[0275] In step 4 of FIG. 29, the RIF 2102 will send a New-Slice-Assign message to the UE 2006, which will contain at least the same information that was contained in the SS-New-Slice message it received.

[0276] In step 5 of Figure 29, the SISF 2024 may send a Slice-Notify message to the Subscription Service Function 2060 (SSF, 5a) and the Slice Instance Management Function 2026 (SIMF, 5b) to indicate the updated network slice ID to be assigned to the UE 2006. Other Slice-Notify indication messages may be sent to other network functions, including the Session Management (SM) functions 2048 in each of the involved network slices (5c).

[0277] In step 6 (optional) of FIG. 29, the IP session may be modified based on the new slice allocation.

[0278] It is understood that the entities performing the steps illustrated in FIG. 29 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 29 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 29. It is also understood that the functionality illustrated in FIG. 29 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 29 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0279] Allocating a new slice instance to the UE - network initiated (alternative approach) The new slice instance allocation (alternative approach) procedure is initiated by the network and provides the UE 2006 with one or more new network slice IDs (or other identifiers that are uniquely resolvable to network slice IDs). After this procedure, the UE 2006 will have at least one new network slice assigned to it. Either the SISF 2024 or other network functions may initiate the new slice allocation.

[0280] FIG. 30 is a diagram illustrating network-initiated new slice allocation (alternative approach).

[0281] At step 0 of Figure 30, the initial RIF attachment procedure that provided the UE 2006 with connectivity prior to the network-initiated profile change should have been completed (see Figure 22). IP connectivity may also have been established.

[0282] In step 1 of Figure 30, the SISF 2024 determines, based on internal processing or based on a specific request from another network function, that new slices are required for one or more UEs, which may include a change in subscription.

[0283] If the new slice allocation is triggered by a subscription change, this step may include the profile change procedure of FIGS. 24 and 25, or the entire procedure below may be merged with the profile change procedure of FIGS.

[0284] In step 2 of FIG. 30, if the new slice allocation did not come from the subscription service, the SISF 2024 uses the subscription service function to check that the UE 2006 subscription is compatible with the new slice.

[0285] In steps 2a and 2b of FIG. 30, a subscription request / response pair of messages may be exchanged with the subscription service function for this reason.

[0286] In step 3 of FIG. 30, the SISF 2024 will send an SS-New-Slice message including one or more network slice IDs that the UE 2006 should use in addition to the current allocation.

[0287] If SISF2024 requests that certain functionality be transferred to the new slice, a list of transferred and / or enabled features is provided, as well as information about connection establishment for the new slice. A HARD / SOFT-TRANSITION indicator is sent to indicate a "make before break" transition for features that may support it.

[0288] In step 4 of FIG. 30, the RIF 2102 will send a New-Slice-Assign message to the UE 2006, which will contain at least the same information as was contained in the SS-New-Slice message it received.

[0289] In step 5 of FIG. 30, the UE 2006 will respond with a New-Slice-Resp message indicating that it confirms the allocation of the new network slice instance.

[0290] In step 6 of Figure 30, the RIF 2102 will forward the response from the UE 2006 in an SS-New-Slice-Resp message. This message will contain at least the same information that was included in the New-Slice-Resp message from the UE 2006.

[0291] In step 7 of FIG. 30, the SISF 2024 will send a New-Slice-Notify message to indicate completion of the slice allocation procedure.

[0292] In step 7a of Figure 30, if the initiator was a network function other than the SISF, the caller is notified of procedure completion.

[0293] In step 7b of Figure 30, the Slice Instance Management Function (SIMF) is notified of the new slice allocation.

[0294] In step 7c (optional) of FIG. 30, the subscription service function may also be notified of the new slice allocation to indicate the updated network slice ID assigned to the UE 2006.

[0295] In step 7d (optional) of FIG. 30, another Slice-Notify indication message may be sent to other network functions, including session management (SM) functions in each of the involved network slices.

[0296] In step 8 (optional) of FIG. 30, the IP session may be modified based on the new slice allocation.

[0297] It is understood that the entities performing the steps illustrated in FIG. 30 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 30 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 30. It is also understood that the functionality illustrated in FIG. 30 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 30 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0298] (Profile Change) A service profile stored in the network (e.g., in a subscription service function and / or in a SISF) may be updated for a variety of reasons. Profile changes may be initiated by the UE 2006 or by the network.

[0299] (Profile Change - UE Initiated (Alternative Approach)) In a UE-initiated (alternative approach) profile change, the UE 2006 would request a profile change in response to changing application requirements, e.g., the browser begins to be used for video streaming. The UE 2006 is assumed to have IP connectivity through an egress function.

[0300] Upon completion of the profile change, existing sessions may be modified or the UE 2006 may be provided with one or more new network slice instance IDs.

[0301] FIG. 31 is a diagram illustrating a UE-initiated profile change (alternative approach).

[0302] At step 0 of Figure 31, prior to the UE 2006 initiated profile change, the initial RIF connection procedure that provided it with connectivity with the ULN 2004 should have been completed (see Figure 22). IP connectivity may also have been established.

[0303] In step 1 of Figure 31, when service functionality changes (e.g., from browsing to video streaming), the UE 2006 will send a Profile-Change-Req message to the RIF 2102. The Profile-Change-Req message will contain, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the type of service the UE 2006 expects to access.

[0304] In step 2 of Figure 31, the RIF 2102 will send an SS-Profile-Change-Req message to the SISF. The SS-Profile-Change-Req message will contain, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the types of services that the UE 2006 expects to access.

[0305] In steps 2a and 2b of FIG. 31, the SISF2024 may check that the profile change is acceptable given the UE subscription, and therefore a subscription request / response pair of messages may be exchanged with the subscription service function.

[0306] In step 3 of FIG. 31, SISF2024 responds to RIF2102 with a Profile-Change-Resp message, optionally including one or more network slice IDs (or other identifiers that can be uniquely resolved to network slice IDs by the network).

[0307] In step 4 of FIG. 31, the RIF 2102 will send a Profile-Change-Resp message to the UE 2006, including the information received from the SISF.

[0308] In step 5 (optional) of Figure 31, the SISF 2024 will send a Profile-Change-Notify message to the Subscription Service Function (SSF) 2060 indicating that the UE profile change procedure is complete. Other network functions may be similarly notified.

[0309] In step 6 (optional) of FIG. 31, the IP session may be modified based on the UE profile changes.

[0310] It is understood that the entities performing the steps illustrated in FIG. 31 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 31 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 31. It is also understood that the functionality illustrated in FIG. 31 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 31 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0311] (Profile Change - Network Initiated (Alternative Approach)) In a network-initiated (alternative approach) profile change, a request for a profile change is issued by a network function in response to a subscription change or an OMA device management command. The UE 2006 may have IP connectivity.

[0312] Upon completion of the profile change, existing sessions may be modified or the UE 2006 may be provided with one or more new network slice instance IDs.

[0313] FIG. 32 is a diagram illustrating network-initiated profile change (alternative approach).

[0314] At step 0 of Figure 32, the initial RIF attachment procedure that provided the UE 2006 with connectivity prior to the network-initiated profile change should have been completed (see Figure 22). IP connectivity may also have been established.

[0315] In step 1 of Figure 32, a subscription service or another network function will request a profile change by using a Profile-Change-Req message to the SISF. The Profile-Change-Req message will contain, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the type of services the UE 2006 expects to access.

[0316] In steps 1a and 1b of FIG. 32, SISF2024 may check that the profile change is acceptable given the UE subscription, and thus a subscription request / response pair of messages may be exchanged with the subscription service function (unless this function is the profile change requester).

[0317] In step 2 of Figure 32, the SISF 2024 initiates the profile change by sending an SS-Profile-Change-Req to the RIF 2102 with the new profile information. The SS-Profile-Change-Req message will contain, at a minimum, one or more UE-SERVICE-DESCRIPTORS that describe the types of services the UE 2006 expects to access.

[0318] The message may include additional parameters such as "active time" that allow for synchronized changes of the profile between the UE 2006 and the network. The message may also provide alternative profiles to be used in different conditions and / or at different times that may be automatically applied / switched by the UE 2006 as well as the network.

[0319] In step 3 of FIG. 32, the RIF 2102 will send a Profile-Change-Req message to the UE 2006 with the new profile information.

[0320] In step 4 of FIG. 32, after changing the locally stored profile, the UE 2006 will send a Profile-Change-Resp message to the RIF 2102 confirming the new profile.

[0321] In step 5 of FIG. 32, the RIF 2102 will send an SS-Profile-change-Resp message to the ISF.

[0322] In step 6 of FIG. 32, the SISF 2024 responds to the initiator (SSF 2060 or other network function) with a Profile-Change-Resp message.

[0323] In step 7 (optional) of FIG. 32, if the initiator is a network function other than a Subscription Service Function (SSF) 2060, the SISF 2024 may send a Profile-Change-Notify to the SSF 2060 indicating that the UE profile change procedure is complete.

[0324] In step 8 (optional) of FIG. 32, the IP session may be modified based on the UE profile changes.

[0325] It is understood that the entities performing the steps illustrated in FIG. 32 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 32 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 32. It is also understood that the functionality illustrated in FIG. 32 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 32 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0326] (Modify slice instance) The network may change the slice instance to which the UE 2006 is assigned for various reasons, such as load balancing or changes in the user's subscription, among others.

[0327] (Modified Slice Instances - Network Initiated (Alternative Approach)) A procedure to change the slice instance (alternative approach) is initiated by the network to change the network slice assigned to the UE 2006. After this procedure, the UE 2006 will be assigned to a different network slice instance.

[0328] FIG. 33 is a diagram illustrating network-initiated slice change (alternative approach).

[0329] At step 0 of Figure 33, the initial RIF attachment procedure that provided the UE 2006 with connectivity prior to the network-initiated profile change should have been completed (see Figure 22). IP connectivity may also have been established.

[0330] In step 1 of Figure 33, the SISF 2024 determines, based on internal processing or based on a specific request from another network function, that the slices assigned to one or more UEs need to be changed, which may include a change in subscription.

[0331] If the new slice allocation is triggered by a subscription change, this step may include the profile change procedure of FIGS. 24 and 25, or the entire procedure below may be merged with the profile change procedure of FIGS.

[0332] In step 2 of FIG. 33, if the new slice allocation did not come from the subscription service, SISF2024 uses the subscription service function to check that the UE2006 subscription is compatible with the new slice.

[0333] In steps 2a and 2b of FIG. 33, a subscription request / response pair of messages may be exchanged with the subscription service function for this reason.

[0334] In step 3 of Figure 33, the SISF 2024 will send an SS-Change-Slice message that includes the network slice ID(s) currently assigned to the UE 2006, as well as the network slice ID(s) that will replace the current assignment. The message will include information about the new slice (e.g., NEW_NSI_ID-ID, SLICE_DESCRIPTOR, Slice_Operating_Parameters, Connection_Parameters).

[0335] SISF2024 may provide a list of transferred and / or enabled features per slice, as well as information about connection establishment for new slices. A HARD / SOFT-TRANSITION indicator is sent to indicate a "make-before-break" transition for features that may support it.

[0336] In step 4 of FIG. 33, the RIF 2102 will send a Change-Slice-Assign message to the UE 2006, which will contain at least the same information as was contained in the SS-Change-Slice message it received.

[0337] In step 5 of FIG. 33, UE 2006 will respond with a Change-Slice-Resp message indicating that it confirms the change of the network slice instance based on the Change-Slice-Assign message it received.

[0338] In step 6 of Figure 33, the RIF 2102 will forward the response from the UE 2006 in an SS-Change-Slice-Resp message. This message will contain at least the same information that was included in the Change-Slice-Resp message from the UE 2006.

[0339] In step 7 of FIG. 33, if the initiator was another network, the SISF 2024 sends a Slice-Change-Resp to the individual function to indicate completion of the slice change procedure.

[0340] In step 8 of Figure 33, the SISF 2024 sends a Slice-Change-Notify indication to the session management (SM) function to indicate the updated network slice ID assigned to the UE 2006 and to trigger the necessary session transfer procedure. 8a and 8b show indicators sent to the SM function in the assigned slice before and after the procedure.

[0341] In step 9 of Figure 33, the UE 2006 connection to the slices is modified based on the assigned slice. Context may be exchanged between the slices involved in the procedure.

[0342] A slice change notification may be sent to other network functions affected by the slice change and may include timing information about when the change should occur. Other context transfer procedures may occur between equivalent functions in the two slices.

[0343] It is understood that the entities performing the steps illustrated in FIG. 33 may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of and executing on a processor of an apparatus configured for wireless and / or network communication or computer system such as those illustrated in FIGS. 36-37. That is, the method illustrated in FIG. 33 may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of an apparatus such as the apparatus or computer system illustrated in FIGS. 36-37, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in FIG. 33. It is also understood that the functionality illustrated in FIG. 33 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via forwarding or routing functions. It is also understood that any transmitting and receiving steps illustrated in FIG. 33 may be performed by the communication circuitry of the apparatus under the control of the processor of the apparatus and the computer executable instructions (e.g., software) it executes.

[0344] (Embodiment (mounting aspect)) Figure 34 shows an example of implementing IRF / IWK-IRF as a message broker. The following points are noted: The IRF 2058 and / or IWK-IRF are implemented as a message broker so that all other NFs and VASs that register with the IRF 2058 can participate in the network slice instance. A network slice instance can consist of NFs and VASs provisioned by either a core network operator or a third party operator. ● Core network operators provide: o NFs and VASs that implement functionality such as SISF, SIMF, and mobility management in the CN. ○ NF and VAS directory that allows convenient discovery of available NFs and VASs to be registered in IRF2058 ● Since the IRF / IWK-IRF is implemented as a message broker, which is essentially a messaging-based middleware, the NFs may subscribe to certain information / events they are interested in in the IRF 2058. For example, the mobility management function and the session management function may subscribe to location reports / updates for a UE 2006 or a group of UEs in the IRF 2058 to be notified with the corresponding location updates. ● Different third party operators may register their own NFs and VAS with IRF2058 and offer these functions / services to users. ● Figure 34 may represent a single network slice, or may represent several network slices, where IRF2058 is shared by multiple network slices and NFs connected to IRF2058 belong to different network slices.

[0345] It is understood that the functionality illustrated in Figure 34 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a wireless device or other apparatus (e.g., a server, gateway, device, or other computer system), such as one of those illustrated in Figures 36-37 described below. It is also understood that the functionality illustrated in Figure 34 may be implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, but rather may communicate via a forwarding or routing function.

[0346] An interface, such as a graphical user interface (GUI), can be used to assist a user in controlling and / or configuring functionality related to connecting to a virtualized mobile core network. Figure 35 is a diagram illustrating an interface 3502 that allows a user to create a new slice or modify / delete an existing slice instance. It should be appreciated that the interface 3502 can be generated using a display such as that shown in Figure 35.

[0347] (Example M2M / IoT / WoT Communication System) The various techniques described herein may be implemented in connection with hardware, firmware, software, or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatus located at various nodes of a communications network. The apparatuses may operate alone or in combination with each other to achieve the methods described herein. As used herein, the terms "apparatus," "network apparatus," "node," "device," and "network node" may be used interchangeably.

[0348] A service layer may be a functional layer within a network service architecture. The service layer typically sits above an 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 functionality, including service definition, service run-time enablement, policy management, access control, and service clustering. Recently, several industry standards organizations, such as oneM2M, have developed M2M service layers to address challenges associated with the integration of M2M type devices and applications into deployments such as Internet / Web, cellular, enterprise, and home networks. The M2M service layer may provide applications and / or various devices with access to a collection or set of the above capabilities or functionalities supported by the service layer, which may be referred to as CSEs or SCLs. Some examples include, but are not limited to, security, charging, data management, device management, discovery, provisioning, and connectivity management, which may be commonly used by various applications. These capabilities or functionalities are made available to such 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 may be implemented by hardware and / or software and provides (service) capabilities or functionality that are exposed to various applications and / or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionality.

[0349] 36A is a schematic diagram of an example Machine-to-Machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides the 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, as well as an IoT / WoT service layer, etc. The communication system 10 can be used to implement the functionality of the disclosed embodiments and can include functional and logical entities such as a subscription service function (SSF) 2060, a user data repository 2032, a policy maintenance function (PMF) 2050, a policy enforcement function (PEF), an authorization authentication accounting (AAA) function 2028, a RAT interface function (RIF) 2102, a slice instance selection function (SISF) 2024, a slice instance management function (SIMF) 2026, a core network entry point (CNEP) 2020, an interconnection and routing function (IRF) 2058, a mobile originating ingress function (MOI) 2040, a mobile originating egress function (MOE) 2046, a mobile terminated ingress function (MTI) 2044, a mobile terminated egress function (MTE) 2042, a session management (SM) function 2048, and a mobility management (MM) function 2022.

[0350] As shown in FIG. 36A, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 can be a fixed network (e.g., Ethernet, 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 can be a multiple access network that provides content such as voice, data, video, messaging, broadcast, etc. to multiple users. For example, the communication network 12 can employ 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. Furthermore, the communication network 12 may comprise other networks such as, for example, 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.

[0351] As shown in FIG. 36A, 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 an end-to-end M2M deployment, and the field domain refers to the area network, typically behind an M2M gateway. Both the field domain and the infrastructure domain may comprise a variety of different network nodes (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and a terminal device 18. It will be understood 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 devices 14 and M2M terminal devices 18 is configured to transmit and receive signals via the communication network 12 or a direct wireless link using communication circuitry. The M2M gateway 14 enables wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate either through an operator network, such as the communications network 12, or through a direct wireless link. For example, the M2M terminal devices 18 may collect data and transmit the data to an M2M application 20 or another M2M terminal device 18 via the communications network 12 or a direct wireless link. The M2M terminal devices 18 may also receive data from the M2M application 20 or the M2M terminal devices 18. Additionally, data and signals may be transmitted to and received from the M2M application 20 via the M2M service layer 22, as described below. The M2M terminal devices 18 and the gateway 14 may communicate over a variety of networks, including, for example, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct wireless links, and wired.

[0352] Exemplary M2M terminal devices 18 include, but are not limited to, tablets, smartphones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and wellness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0353] Referring to FIG. 36B, the illustrated M2M service layer 22 in the field domain provides services for M2M applications 20, M2M gateway devices 14, and M2M terminal devices 18, as well as the communication network 12. The communication system network 12 can be used to implement the functionality of the disclosed embodiments and can include functional and logical entities such as a subscription service function (SSF) 2060, a user data repository 2032, a policy maintenance function (PMF) 2050, a policy enforcement function (PEF), an authorization authentication accounting (AAA) function 2028, a RAT interface function (RIF) 2102, a slice instance selection function (SISF) 2024, a slice instance management function (SIMF) 2026, a core network entry point (CNEP) 2020, an interconnection and routing function (IRF) 2058, a mobile originating ingress function (MOI) 2040, a mobile originating egress function (MOE) 2046, a mobile terminating ingress function (MTI) 2044, a mobile terminating egress function (MTE) 2042, a session management (SM) function 2048, and a mobility management (MM) function 2022. The M2M service layer 22 may be implemented by one or more servers, computers, devices, virtual machines (e.g., cloud / storage farms, etc.), or the like, including, for example, the devices illustrated in Figures 36C and 36D described below. It will be appreciated that the M2M service layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M terminal devices 18, and communications network 12, as desired. The M2M service layer 22 may be implemented by one or more nodes of a network, which may comprise servers, computers, devices, etc. The M2M service layer 22 provides service capabilities that apply to the M2M terminal devices 18, M2M gateways 14, and M2M applications 20. The functions of the M2M service layer 22 may be implemented in various ways, for example, as a web server, in a cellular core network, in a cloud, etc.

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

[0355] Also referring to FIG. 36B, the M2M service layers 22 and 22' provide a core set of service delivery capabilities that can be leveraged by a variety of applications and verticals. These service capabilities enable the 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. In essence, these service capabilities remove the burden of implementing these functionalities from the applications, thus simplifying application development and reducing cost and time to market. The service layers 22 and 22' also enable the M2M applications 20 and 20' to communicate over the network 12 in conjunction with the services that the service layers 22 and 22' provide.

[0356] The present method may be implemented as part of the service layer 22 and 22'. The service layer 22 and 22' is a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. Both ETSI M2M and oneM2M use a service layer that may include the present connection method. The ETSI M2M service layer is referred to as the service capability layer (SCL). The SCL may be implemented in M2M devices (referred to as device SCL (DSCL)), gateways (referred to as gateway SCL (GSCL)), and / or network nodes (referred to as network SCL (NSCL)). The oneM2M service layer supports a set of common service functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more specific types of CSFs is referred to as a common service entity (CSE), which may be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). Furthermore, the connectivity methods of the present application 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 such as the connectivity methods of the present application.

[0357] In some embodiments, the M2M applications 20 and 20' may be used in conjunction with the disclosed systems and methods. The M2M applications 20 and 20' may include applications that interact with a UE or a gateway and may be used in conjunction with other disclosed systems and methods.

[0358] In one embodiment, the Subscription Service Function (SSF) 2060, the User Data Repository 2032, the Policy Maintenance Function (PMF) 2050, the Policy Enforcement Function (PEF), the Authorization Authentication and Accounting (AAA) Function 2028, the RAT Interface Function (RIF) 2102, the Slice Instance Selection Function (SISF) 2024, the Slice Instance Management Function (SIMF) 2026, the Core Network Entry Point (CNEP) 2020, the Interconnection and Routing Function (IRF) 2026, the CNEP ... Logical entities such as 2058, mobile originated ingress function (MOI) 2040, mobile originated egress function (MOE) 2046, mobile terminated ingress function (MTI) 2044, mobile terminated egress function (MTE) 2042, session management (SM) function 2048, and mobility management (MM) function 2022 may be hosted within an M2M service layer instance hosted by an M2M node such as an M2M server, M2M gateway, or M2M device, as shown in FIG. 36B. For example, logical entities such as the subscription service function (SSF) 2060, user data repository 2032, policy maintenance function (PMF) 2050, policy enforcement function (PEF), authorization authentication and accounting (AAA) function 2028, RAT interface function (RIF) 2102, slice instance selection function (SISF) 2024, slice instance management function (SIMF) 2026, core network entry point (CNEP) 2020, interconnection and routing function (IRF) 2058, mobile originating ingress function (MOI) 2040, mobile originating egress function (MOE) 2046, mobile terminated ingress function (MTI) 2044, mobile terminated egress function (MTE) 2042, session management (SM) function 2048, and mobility management (MM) function 2022 may comprise individual service capabilities within an M2M service layer instance or as sub-functions within an existing service capability.

[0359] 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 surveillance. As noted above, the M2M service layer running across the 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'.

[0360] In general, the service layers 22 and 22' define a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. The ETSI M2M and oneM2M architectures both define a service layer. The ETSI M2M service layer is referred to as a service capability layer (SCL). The SCL may be implemented in various different nodes of the ETSI M2M architecture. For example, an instance of the service layer may be implemented in an M2M device (referred to as a device SCL (DSCL)), a gateway (referred to as a gateway SCL (GSCL)), and / or a network node (referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of common service functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more specific types of CSFs is referred to as a common service entity (CSE), which may be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). The 3rd Generation Partnership Project (3GPP) has also defined an architecture for Machine Type Communications (MTC), in which the service layer and the service capabilities it provides are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a 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.) running either on one or more standalone nodes or as part of one or more existing nodes in the network, including servers, computers, and other computing devices or 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 general architecture illustrated in Figure 36C or Figure 36D described below.

[0361] Furthermore, logical entities such as a Subscription Service Function (SSF) 2060, a User Data Repository 2032, a Policy Maintenance Function (PMF) 2050, a Policy Enforcement Function (PEF), an Authorization Authentication Accounting (AAA) Function 2028, a RAT Interface Function (RIF) 2102, a Slice Instance Selection Function (SISF) 2024, a Slice Instance Management Function (SIMF) 2026, a Core Network Entry Point (CNEP) 2020, an Interconnection and Routing Function (IRF) 2058, a Mobile Originating Ingress Function (MOI) 2040, a Mobile Originating Egress Function (MOE) 2046, a Mobile Terminated Ingress Function (MTI) 2044, a Mobile Terminated Egress Function (MTE) 2042, a Session Management (SM) Function 2048, and a Mobility Management (MM) Function 2022 can be implemented as part of an M2M network using a Service Oriented Architecture (SOA) and / or a Resource Oriented Architecture (ROA) to access the services of the present application.

[0362] FIG. 36C is a block diagram of an example hardware / software architecture of an M2M network node 30, such as an M2M device 18, an M2M gateway 14, or an M2M server. The node 30 may execute or include logical entities such as a subscription service function (SSF) 2060, a user data repository 2032, a policy maintenance function (PMF) 2050, a policy enforcement function (PEF), an authorization authentication accounting (AAA) function 2028, a RAT interface function (RIF) 2102, a slice instance selection function (SISF) 2024, a slice instance management function (SIMF) 2026, a core network entry point (CNEP) 2020, an interconnection and routing function (IRF) 2058, a mobile originating ingress function (MOI) 2040, a mobile originating egress function (MOE) 2046, a mobile terminating ingress function (MTI) 2044, a mobile terminating egress function (MTE) 2042, a session management (SM) function 2048, and a mobility management (MM) function 2022. The device 30 may be part of an M2M network or a non-M2M network as shown in Figures 36A-B. As shown in Figure 36C, the M2M node 30 may include a processor 32, non-removable memory 44, removable memory 46, speaker / microphone 38, keypad 40, display, touchpad, and / or indicators 42, power source 48, Global Positioning System (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit / receive element 36. It will be understood that the M2M node 30 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. The node may be a node that implements the SMSF functionality described herein.

[0363] The processor 32 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction 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 the memory (e.g., memory 44 and / or memory 46) of the node to perform various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the M2M node 30 to operate in a wireless or wired environment. The processor 32 may run application layer programs (e.g., a browser) 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 agreement, and / or encryption operations, for example, at the access layer and / or application layer.

[0364] As shown in Figure 36C, the processor 23 is coupled to its communication circuitry (e.g., the transceiver 34 and the transmit / receive element 36). The processor 23, through execution of computer-executable instructions, may control the communication circuitry to cause the node 30 to communicate with other nodes over the network to which it is connected. In particular, the processor 32 may control the communication circuitry to perform the transmit and receive steps described herein and in the claims. Although Figure 36C depicts the processor 32 and the transceiver 34 as separate components, it will be understood that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0365] The transmit / receive element 36 may be configured to transmit signals to or receive signals from other M2M nodes, including M2M servers, gateways, devices, etc. For example, in an embodiment, the transmit / receive element 36 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, the transmit / receive element 36 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 36 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0366] In addition, although the transmit / receive element 36 is depicted in FIG. 36C as a single element, the M2M node 30 may include any number of transmit / receive elements 36. More specifically, the M2M node 30 may employ MIMO technology. Thus, in an embodiment, the M2M node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

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

[0368] The processor 32 may access information from and store data in any type of suitable memory, such as non-removable memory 44 and / or removable memory 46. For example, the processor 32 may store session context in its memory, as described above. The non-removable memory 44 may include random access memory (RAM), 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 (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 32 may access information from and store data in memory that is not physically located on the M2M node 30, such as on a server or a home computer. The processor 32 may be configured to control visual indications on the display to determine the status of the system or to obtain input from the user or display information about capabilities or settings to the user. A graphical user interface, which may be shown on the display, may be layered on top of an API to allow the user to interact with the functionality described herein.

[0369] The processor 32 may receive power from a power source 48 and may be configured to distribute and / or control power to other components in the M2M node 30. The power source 48 may be any suitable device for powering the M2M node 30. For example, the 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.

[0370] The processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (e.g., longitude and latitude) regarding a current location of the M2M node 30. It will be understood that the M2M node 30 may acquire location information via any suitable location determination method while remaining consistent with an embodiment.

[0371] The processor 32 may further 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 an accelerometer, a biometric (e.g., fingerprint) sensor, an e-compass, a satellite transceiver, a digital camera (for photos or videos), a Universal Serial Bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0372] Node 30 may be embodied in other apparatus or devices, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, vehicles such as drones, cars, trucks, trains, or planes, etc. Node 30 may connect to other components, modules, or systems of such apparatus or devices via one or more interconnection interfaces, such as an interconnection interface that may comprise one of peripherals 52. Alternatively, node 30 may comprise an apparatus or device, such as a sensor, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, vehicles such as drones, cars, trucks, trains, or planes, etc.

[0373] 36D is a block diagram of an exemplary computing system 90 that may also be used to implement one or more nodes of an M2M network, such as an M2M server, gateway, device, or other node. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. The computing system 90 may execute or include logical entities such as a subscription service function (SSF) 2060, a user data repository 2032, a policy maintenance function (PMF) 2050, a policy enforcement function (PEF), an authorization authentication accounting (AAA) function 2028, a RAT interface function (RIF) 2102, a slice instance selection function (SISF) 2024, a slice instance management function (SIMF) 2026, a core network entry point (CNEP) 2020, an interconnection and routing function (IRF) 2058, a mobile originating ingress function (MOI) 2040, a mobile originating egress function (MOE) 2046, a mobile terminated ingress function (MTI) 2044, a mobile terminated egress function (MTE) 2042, a session management (SM) function 2048, and a mobility management (MM) function 2022. The computing system 90 can be an M2M device, user equipment, gateway, UE / GW, or any other node, including, for example, a node of a mobile core network, a service layer network application provider, a terminal device 18, or an M2M gateway device 14. Such computer-readable instructions may be executed within a processor, such as a central processing unit (CPU) 91, to run the computing system 90. 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 comprise multiple processors. A coprocessor 81 is an optional processor, distinct from the main CPU 91, that performs additional functions or assists the CPU 91.The CPU 91 and / or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for an E2E M2M service layer session, such as receiving a session certificate or authenticating based on a session certificate.

[0374] In operation, the CPU 91 fetches, decodes, and executes instructions and transfers information to and from other resources via a system bus 80, which is the computer's primary data transfer path. Such a system bus connects components within the computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0375] The memories coupled to the system bus 80 include a random access memory (RAM) 82 and a read only memory (ROM) 93. Such memories include circuits that allow information to be stored and read. The ROM 93 generally includes stored data that cannot be easily modified. Data stored in the RAM 82 can be read or changed by the CPU 91 or other hardware devices. Access to the RAM 82 and / or the ROM 93 may be controlled by a memory controller 92. The memory controller 92 may provide an address translation function that converts virtual addresses to physical addresses when instructions are executed. The memory controller 92 may also provide a memory protection function that isolates processes in the system and isolates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in another process' virtual address space unless memory sharing between processes is set up.

[0376] Additionally, computing system 90 may include a peripheral controller 83 that is responsible for communicating instructions from CPU 91 to peripheral devices such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0377] Display 86, controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. Display controller 96 includes the electronic components required to generate the video signals that are sent to display 86.

[0378] Additionally, computing system 90 may include communications circuitry, such as a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as network 12 of FIGS. 36A and 36B, to enable computing system 90 to communicate with other nodes of the network.

[0379] A user equipment (UE) can be any device used by an end user to communicate. It can be a handheld phone, a laptop computer equipped with a mobile broadband adapter, or any other device. For example, a UE can be implemented as the M2M terminal device 18 of Figures 36A-B or the device 30 of Figure 36C.

[0380] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications 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 standardization of the next generation of cellular technology, called New Radio (NR), also referred to as "5G". 3GPP NR standard development is expected to include the definition of next generation radio access technologies (new RATs), which are expected to include new flexible radio access provisions below 6 GHz and new ultra-mobile broadband radio access provisions above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in new spectrum below 6 GHz and is expected to include different operation modes that can be multiplexed together in the same spectrum and address a broad set of 3GPP NR use cases with diverse requirements. Ultra Mobile Broadband is expected to include cm-wave and mm-wave spectrum, which will provide opportunities for ultra mobile broadband access, such as indoor applications and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with sub-6 GHz Flexible Wireless Access, with cm-wave and mm-wave specific design optimizations.

[0381] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in high density areas, indoor ultra-high broadband access, broadband access in crowds, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), critical communications, high volume machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy conservation), 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 office, emergency responder connectivity, automotive e-calls, disaster alerts, real-time gaming, multi-party video calls, autonomous driving, augmented reality, tactile internet, and virtual reality, to name a few. All of these use cases and others are contemplated herein.

[0382] 37A illustrates one embodiment of an example communication system 200 in which the methods and apparatus described and claimed herein may be embodied. As shown, the example communication system 200 may include wireless transmission / reception units (WTRUs) 202a, 202b, 202c, and / or 202d (which may be generally or collectively referred to as WTRUs 202), radio access networks (RANs) 203 / 204 / 205 / 203b / 204b / 205b, a core network 206 / 207 / 209, a public switched telephone network (PSTN) 208, the Internet 210, and other networks 212, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. The WTRUs 202a, 202b, 202c, 202d, 202e may each be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 202a, 202b, 202c, 202d, 202e is depicted in FIGS. 37A-37E as a handheld wireless communication device, it will be understood that with the wide variety of use cases contemplated for 5G wireless communication, each WTRU may comprise or be embodied as any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics device, 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 a plane, or the like.

[0383] The communications system 200 may also include a base station 214a and a base station 214b. The base station 214a may be any type of device configured to wirelessly interface with at least one of the WTRUs 202a, 202b, 202c and facilitate access to one or more communications networks, such as the core network 206 / 207 / 209, the Internet 210, and / or other networks 212. The base station 214b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 218a, 218b and / or TRPs (transmission and reception points) 219a, 219b and facilitate access to one or more communications networks, such as the core network 206 / 207 / 209, the Internet 210, and / or other networks 212. The RRHs 218a, 218b may be any type of device configured to wirelessly interface with at least one of the WTRUs 202c and facilitate access to one or more communication networks, such as the core network 206 / 207 / 209, the Internet 210, and / or other networks 212. The TRPs 219a, 219b may be any type of device configured to wirelessly interface with at least one of the WTRUs 202d and facilitate access to one or more communication networks, such as the core network 206 / 207 / 209, the Internet 210, and / or other networks 212. By way of example, the base stations 214a, 214b may be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a service location controller, an Access Point (AP), a wireless router, etc. Although the base stations 214a, 214b are each depicted as a single element, it should be understood that the base stations 214a, 214b may include any number of interconnected base stations and / or network elements.

[0384] The base station 214a may be part of the RAN 203 / 204 / 205, 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), relay nodes, etc. The base station 214b may be part of the RAN 203b / 204b / 205b, 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), relay nodes, etc. The base station 214a may be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The base station 214b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cells may be further divided into cell sectors. For example, the cell associated with the base station 214a may be divided into three sectors. Thus, in an embodiment, the base station 214a may include three transceivers, for example, one for each sector of the cell. In an embodiment, the base station 214a may employ multiple-input multiple-output (MIMO) technology and therefore may utilize multiple transceivers for each sector of the cell.

[0385] The base station 214a may communicate with one or more of the WTRUs 202a, 202b, 202c via an air interface 215 / 216 / 217, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cm wave, mm wave, etc.). The air interface 215 / 216 / 217 may be established using any suitable radio access technology (RAT).

[0386] The base station 214b may communicate with one or more of the RRHs 218a, 218b and / or TRPs 219a, 219b via a wired or air interface 215b / 216b / 217b, 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, cm-wave, mm-wave, etc.). The air interface 215b / 216b / 217b may be established using any suitable radio access technology (RAT).

[0387] The RRHs 218a, 218b and / or TRPs 219a, 219b may communicate with one or more of the WTRUs 202c, 202d via an air interface 215c / 216c / 217c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cm-wave, mm-wave, etc.). The air interface 215c / 216c / 217c may be established using any suitable radio access technology (RAT).

[0388] More specifically, as mentioned above, the communication system 200 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 214a in the RAN 203 / 204 / 205 and WTRUs 202a, 202b, 202c, or the RRHs 218a, 218b and TRPs 219a, 219b in the RANs 203b / 204b / 205b and WTRUs 202c, 202d, respectively, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 215 / 216 / 217 or 215c / 216c / 217c using Wideband CDMA (WCDMA). 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).

[0389] In an embodiment, the RRHs 218a, 218b and TRPs 219a, 219b in the base station 214a and WTRUs 202a, 202b, 202c, or the RANs 203b / 204b / 205b and WTRUs 202c, 202d, respectively, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 215 / 216 / 217 or 215c / 216c / 217c using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). In the future, the air interface 215 / 216 / 217 may implement 3GPP NR technology.

[0390] In an embodiment, the base stations 214a in the RAN 203 / 204 / 205 and WTRUs 202a, 202b, 202c, or the RRHs 218a, 218b and TRPs 219a, 219b in the RAN 203b / 204b / 205b and WTRUs 202c, 202d may implement a radio technology 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), or the like.

[0391] The base station 214c in FIG. 37A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT for facilitating wireless connectivity within a local area, such as a location, such as an office, a home, a vehicle, a campus, etc. In an embodiment, the base station 214c and the WTRU 202e may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In an embodiment, the base station 214c and the WTRU 202d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 214c and the WTRU 202e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 37A, the base station 214b may have a direct connection to the Internet 210. Therefore, the base station 214c may not be required to access the Internet 210 via the core networks 206 / 207 / 209.

[0392] The RAN 203 / 204 / 205 and / or RAN 203b / 204b / 205b may communicate with a core network 206 / 207 / 209, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 202a, 202b, 202c, 202d. For example, the core network 206 / 207 / 209 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication.

[0393] 37A, it will be understood that the RAN 203 / 204 / 205 and / or RAN 203b / 204b / 205b and / or the core network 206 / 207 / 209 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 203 / 204 / 205 and / or RAN 203b / 204b / 205b or a different RAT. For example, in addition to being connected to the RAN 203 / 204 / 205 and / or RAN 203b / 204b / 205b, which may utilize E-UTRA radio technology, the core network 206 / 207 / 209 may also communicate with another RAN (not shown) employing GSM radio technology.

[0394] The core network 206 / 207 / 209 may also serve as a gateway for the WTRUs 202a, 202b, 202c, 202d, 202e to access the PSTN 208, the Internet 210, and / or other networks 212. The PSTN 208 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 210 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) within the TCP / IP Internet protocol suite. The network 212 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the network 212 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 203 / 204 / 205 and / or the RAN 203b / 204b / 205b or a different RAT.

[0395] Some or all of the WTRUs 202a, 202b, 202c, 202d in the communications system 200 may include multi-mode capabilities, e.g., the WTRUs 202a, 202b, 202c, 202d, and 202e may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 202e shown in FIG. 37A may be configured to communicate with the base station 214a, which may employ a cellular-based wireless technology, and the base station 214c, which may employ an IEEE 802 wireless technology.

[0396] 37B is a block diagram of an example apparatus or device configured for wireless communication in accordance with the embodiments illustrated herein, such as, for example, a WTRU 202. As shown in FIG. 37B, the example WTRU 202 may include a processor 218, a transceiver 220, a transmit / receive element 222, a speaker / microphone 224, a keypad 226, a display / touchpad / indicator 228, non-removable memory 230, removable memory 232, a power source 234, a Global Positioning System (GPS) chipset 236, and other peripherals 238. It will be understood that the WTRU 202 may include any subcombination of the foregoing elements while remaining consistent with the embodiments. Embodiments also contemplate that the base stations 214a and 214b, and / or nodes which they may represent, such as, but not limited to, a base transceiver station (BTS), a Node-B, a service location 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, among others, may include some or all of the elements depicted in FIG. 37B and described herein.

[0397] The processor 218 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in association 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 218 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 202 to operate in a wireless environment. The processor 218 may be coupled to the transceiver 220, which may be coupled to the transmit / receive element 222. Although FIG. 37B depicts the processor 218 and the transceiver 220 as separate components, it will be understood that the processor 218 and the transceiver 220 may be integrated together in an electronic package or chip.

[0398] The transmit / receive element 222 may be configured to transmit signals to or receive signals from a base station (e.g., base station 214a) via the air interface 215 / 216 / 217. For example, in an embodiment, the transmit / receive element 222 may be an antenna configured to transmit and / or receive RF signals. Although not shown in FIG. 37A, it will be understood that the RAN 203 / 204 / 205 and / or the core network 206 / 207 / 209 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 203 / 204 / 205 or a different RAT. For example, in addition to being connected to the RAN 203 / 204 / 205, which may utilize E-UTRA radio technology, the core network 206 / 207 / 209 may also communicate with another RAN (not shown) employing GSM radio technology.

[0399] The core network 206 / 207 / 209 may also serve as a gateway for the WTRUs 202a, 202b, 202c, 202d to access the PSTN 208, the Internet 210, and / or other networks 212. The PSTN 208 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 210 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) within the TCP / IP Internet protocol suite. The network 212 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the network 212 may include another core network connected to one or more RANs, which may employ the same RAT as the RANs 203 / 204 / 205 or a different RAT.

[0400] Some or all of the WTRUs 202a, 202b, 202c, 202d in the communications system 200 may include multi-mode capabilities, e.g., the WTRUs 202a, 202b, 202c, and 202d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 202c shown in FIG. 37A may be configured to communicate with the base station 214a, which may employ a cellular-based wireless technology, and the base station 214b, which may employ an IEEE 802 wireless technology.

[0401] 37B is a block diagram of an example apparatus or device configured for wireless communication in accordance with the embodiments illustrated herein, such as, for example, a WTRU 202. As shown in FIG. 37B, the example WTRU 202 may include a processor 218, a transceiver 220, a transmit / receive element 222, a speaker / microphone 224, a keypad 226, a display / touchpad / indicator 228, non-removable memory 230, removable memory 232, a power source 234, a Global Positioning System (GPS) chipset 236, and other peripherals 238. It will be understood that the WTRU 202 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Embodiments also contemplate that the base stations 214a and 214b, and / or nodes which they may represent, such as, but not limited to, a base transceiver station (BTS), a Node-B, a service location 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, among others, may include some or all of the elements depicted in FIG. 37B and described herein.

[0402] The processor 218 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in association 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 218 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 202 to operate in a wireless environment. The processor 218 may be coupled to the transceiver 220, which may be coupled to the transmit / receive element 222. Although FIG. 37B depicts the processor 218 and the transceiver 220 as separate components, it will be understood that the processor 218 and the transceiver 220 may be integrated together in an electronic package or chip.

[0403] The transmit / receive element 222 may be configured to transmit signals to or receive signals from a base station (e.g., base station 214a) via air interface 215 / 216 / 217. For example, in an embodiment, the transmit / receive element 222 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 222 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In further embodiments, the transmit / receive element 222 may be configured to transmit and receive both RF and light signals. It will be understood that the transmit / receive element 222 may be configured to transmit and / or receive any combination of wireless signals.

[0404] In addition, although the transmit / receive element 222 is depicted in FIG. 37B as a single element, the WTRU 202 may include any number of transmit / receive elements 222. More specifically, the WTRU 202 may employ MIMO technology. Thus, in an embodiment, the WTRU 202 may include two or more transmit / receive elements 222 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 215 / 216 / 217.

[0405] The transceiver 220 may be configured to modulate signals transmitted by the transmit / receive element 222 and to demodulate signals received by the transmit / receive element 222. As mentioned above, the WTRU 202 may have multi-mode capabilities. Thus, the transceiver 220 may include multiple transceivers to enable the WTRU 202 to communicate via multiple RATs, such as, for example, UTRA and IEEE 802.11.

[0406] The processor 218 of the WTRU 202 may be coupled to and may receive user input data from a speaker / microphone 224, a keypad 226, and / or a display / touchpad / indicator 228 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 218 may also output user data to the speaker / microphone 224, the keypad 226, and / or the display / touchpad / indicator 228. In addition, the processor 218 may access information from and store data in any type of suitable memory, such as a non-removable memory 230 and / or a removable memory 232. The non-removable memory 230 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 232 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In an embodiment, the processor 218 may access information from, and store data in, memory that is not physically located on the WTRU 202, such as on a server or home computer (not shown).

[0407] The processor 218 may receive power from a power source 234 and may be configured to distribute and / or control the power to other components within the WTRU 202. The power source 234 may be any suitable device for powering the WTRU 202. For example, the power source 234 may include one or more dry batteries, solar cells, fuel cells, etc.

[0408] The processor 218 may also be coupled to a GPS chipset 236, which may be configured to provide location information (e.g., longitude and latitude) regarding a current location of the WTRU 202. In addition to or instead of information from the GPS chipset 236, the WTRU 202 may receive location information from a base station (e.g., base stations 214a, 214b) via the air interface 215 / 216 / 217 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be understood that the WTRU 202 may acquire location information via any suitable location determination method while remaining consistent with an embodiment.

[0409] The processor 218 may further be coupled to other peripherals 238, 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 238 may include various sensors such as an accelerometer, a biometric (e.g., fingerprint) sensor, an e-compass, a satellite transceiver, a digital camera (for photos or videos), a Universal Serial Bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0410] The WTRU 202 may be embodied in other apparatus or devices, such as a sensor, a consumer electronics device, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or plane, etc. The WTRU 202 may connect to other components, modules, or systems of such apparatus or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 238.

[0411] FIG. 37C is a system diagram of the RAN 203 and the core network 206, according to an embodiment. As described above, the RAN 203 may employ UTRA radio technology and communicate with the WTRUs 202a, 202b, and 202c over the air interface 215. The RAN 203 may also communicate with the core network 206. As shown in FIG. 37C, the RAN 203 may include Node-Bs 240a, 240b, and 240c, each of which may include one or more transceivers for communicating with the WTRUs 202a, 202b, and 202c over the air interface 215. The Node-Bs 240a, 240b, and 240c may each be associated with a particular cell (not shown) within the RAN 203. The RAN 203 may also include RNCs 242a, 242b. It will be understood that the RAN 203 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0412] As shown in FIG. 37C, the Node-Bs 240a, 240b may communicate with the RNC 242a. Additionally, the Node-Bs 240c may communicate with the RNC 242b. The Node-Bs 240a, 240b, 240c may communicate with the respective RNCs 242a, 242b via an Iub interface. The RNCs 242a, 242b may communicate with each other via an Iur interface. Each of the RNCs 242a, 242b may be configured to control the respective Node-Bs 240a, 240b, 240c to which it is connected. Additionally, each of the RNCs 242a, 242b may be configured to perform or support other functionalities such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0413] The core network 206 shown in Figure 37C may include a media gateway (MGW) 244, a mobile switching center (MSC) 246, a serving GPRS support node (SGSN) 248, and / or a gateway GPRS support node (GGSN) 250. Although each of the foregoing elements is depicted as part of the core network 206, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0414] The RNC 242a in the RAN 203 may be connected to an MSC 246 in the core network 206 via an IuCS interface. The MSC 246 may be connected to the MGW 244. The MSC 246 and MGW 244 may provide the WTRUs 202a, 202b, 202c with access to circuit-switched networks, such as the PSTN 208, and may facilitate communications between the WTRUs 202a, 202b, 202c and traditional terrestrial communication devices.

[0415] The RNC 242a in the RAN 203 may also be connected to an SGSN 248 in the core network 206 via an IuPS interface. The SGSN 248 may be connected to a GGSN 250. The SGSN 248 and GGSN 250 may provide the WTRUs 202a, 202b, 202c with access to packet-switched networks, such as the Internet 210, and may facilitate communications between the WTRUs 202a, 202b, 202c and IP-enabled devices.

[0416] As mentioned above, the core network 206 may also be connected to networks 212, which may include other wired or wireless networks owned and / or operated by other service providers.

[0417] 37D is a system diagram of the RAN 204 and the core network 207, according to an embodiment. As mentioned above, the RAN 204 may employ E-UTRA radio technology and communicate with the WTRUs 202a, 202b, and 202c over the air interface 216. The RAN 204 may also communicate with the core network 207.

[0418] The RAN 204 may include eNode-Bs 260a, 260b, 260c, although it will be understood that the RAN 204 may include any number of Node-Bs while remaining consistent with an embodiment. The eNode-Bs 260a, 260b, 260c may each include one or more transceivers for communicating with the WTRUs 202a, 202b, 202c over the air interface 216. In an embodiment, the eNode-Bs 260a, 260b, 260c may implement MIMO technology. Thus, the eNode-B 260a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 202a.

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

[0420] The core network 207 shown in Figure 37D may include a mobility management gateway (MME) 262, a serving gateway 264, and a packet data network (PDN) gateway 266. Although each of the foregoing elements is depicted as part of the core network 207, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0421] The MME 262 may be connected to each of the eNode-Bs 260a, 260b, and 260c in the RAN 204 via an S1 interface and may act as a control node. For example, the MME 262 may be responsible for authentication of users of the WTRUs 202a, 202b, 202c, bearer activation / deactivation, selection of a particular serving gateway during initial attachment of the WTRUs 202a, 202b, 202c, etc. The MME 262 may also provide a control plane function for switching between the RAN 204 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0422] The serving gateway 264 may be connected to each of the eNode-Bs 260a, 260b, and 260c in the RAN 204 via an S1 interface. The serving gateway 264 may generally route and forward user data packets to / from the WTRUs 202a, 202b, 202c. The serving gateway 264 may also perform other functions such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 202a, 202b, 202c, managing and storing the context of the WTRUs 202a, 202b, 202c, etc.

[0423] The serving gateway 264 may also be connected to a PDN gateway 266, which may provide the WTRUs 202a, 202b, 202c with access to packet-switched networks, such as the Internet 210, and may facilitate communications between the WTRUs 202a, 202b, 202c and IP-enabled devices.

[0424] The core network 207 may facilitate communications with other networks. For example, the core network 207 may provide the WTRUs 202a, 202b, 202c with access to circuit-switched networks, such as the PSTN 208, to facilitate communications between the WTRUs 202a, 202b, 202c and traditional terrestrial communications devices. For example, the core network 207 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 207 and the PSTN 208. In addition, the core network 207 may provide the WTRUs 202a, 202b, 202c with access to networks 212, which may include other wired or wireless networks owned and / or operated by other service providers.

[0425] 37E is a system diagram of the RAN 205 and the core network 209, according to an embodiment. The RAN 205 may be an Access Service Network (ASN) that employs IEEE 802.16 wireless technology and communicates with the WTRUs 202a, 202b, and 202c over the air interface 217. As will be discussed further below, communication links between different functional entities of the WTRUs 202a, 202b, 202c, the RAN 205, and the core network 209 may be defined as reference points.

[0426] As shown in FIG. 37E, the RAN 205 may include base stations 280a, 280b, 280c and an ASN gateway 282, although it will be understood that the RAN 205 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 280a, 280b, 280c may each be associated with a particular cell in the RAN 205 and may include one or more transceivers for communicating with the WTRUs 202a, 202b, 202c over the air interface 217. In an embodiment, the base stations 280a, 280b, 280c may implement MIMO technology. Thus, the base station 280a may, for example, transmit wireless signals to and receive wireless signals from the WTRU 202a using multiple antennas. The base stations 202a, 202b, 202c may also provide mobility management functions such as handoff triggers, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, etc. The ASN gateway 282 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 209, etc.

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

[0428] The communication link between each of the base stations 280a, 280b, and 280c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 280a, 280b, and 280c and the ASN gateway 282 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 202a, 202b, and 202c.

[0429] As shown in Figure 37E, the RAN 205 may be connected to a core network 209. The communication link between the RAN 205 and the core network 209 may be defined as an R3 reference point, including protocols for facilitating data transfer and mobility management capabilities, for example. The core network 209 may include a Mobile IP Home Agent (MIP-HA) 284, an Authentication, Authorization, and Accounting (AAA) server 286, and a gateway 288. Although each of the foregoing elements are depicted as part of the core network 209, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0430] The MIP-HA may be responsible for IP address management and may enable the WTRUs 202a, 202b, and 202c to roam between different ASNs and / or different core networks. The MIP-HA 284 may provide the WTRUs 202a, 202b, and 202c with access to packet-switched networks, such as the Internet 210, and facilitate communications between the WTRUs 202a, 202b, and 202c and IP-enabled devices. The AAA server 286 may be responsible for supporting user authentication and user services. The gateway 288 may facilitate interworking with other networks. For example, the gateway 288 may provide the WTRUs 202a, 202b, and 202c with access to circuit-switched networks, such as the PSTN 208, and facilitate communications between the WTRUs 202a, 202b, and 202c and traditional terrestrial communications devices. In addition, the gateway 288 may provide the WTRUs 202a, 202b, 202c with access to the networks 212, which may include other wired or wireless networks owned and / or operated by other service providers.

[0431] Although not shown in Figure 37E, it will be understood that the RAN 205 may be connected to other ASNs and the core network 209 may be connected to other core networks. The communication link between the RAN 205 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 202a, 202b, 202c between the RAN 205 and the other ASNs. The communication link between the core network 209 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0432] It should be understood that although the core network entities described herein and illustrated in Figures 37A, 37C, 37D, and 37E are identified by names given to those entities in certain existing 3GPP specifications, in the future, those entities and functionality may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, it should be understood that the specific network entities and functionality described and illustrated in Figures 37A, 37C, 37D, and 37E are provided by way of example only, and that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or in the future.

[0433] The 5G core network 270 shown in FIG. 37F may include an Access and Mobility Management Function (AMF) 272, a Session Management Function (SMF) 274, a User Plane Function (UPF) 276, a User Data Management Function (UDM) 278, an Authentication Server Function (AUSF) 280, a Network Exposure Function (NEF), a Policy Control Function (PCF) 284, a Non-3GPP Interworking Function (N3IWF) 292, and an Application Function (AF) 288. Although each of the foregoing elements is depicted as part of the 5G core network 270, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator. It should also be understood 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. FIG. 37F shows the network functions connecting directly to each other; however, it should be understood that they may communicate via a routing agent, such as a diameter routing agent, or a message bus.

[0434] The AMF 272 may be connected to each of the RANs 203 / 204 / 205 / 203b / 204b / 205b via an N2 interface and may act as a control node. For example, the AMF 272 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF 272 may generally route and forward NAS packets to / from the WTRUs 202a, 202b, and 202c.

[0435] The SMF 274 may be connected to the AMF 272 via an N11 interface, to the PCF 284 via an N7 interface, and to the UPF 276 via an N4 interface. The SMF 274 may act as a control node. For example, the SMF 274 may be responsible for session management, management and configuration of WTRU 202a, 202b, 202c IP address allocation and traffic steering rules within the UPF 276, and generation of downlink data notifications.

[0436] The SMF 274 may also be connected to the UPF 276, which may provide the WTRUs 202a, 202b, 202c with access to a data network (DN) 290, such as the Internet 210, and may facilitate communications between the WTRUs 202a, 202b, 202c and IP-enabled devices. The SMF 274 may manage and configure traffic steering rules in the UPF 276 over an N4 interface. The UPF 276 may be responsible for interconnecting packet data unit (PDU) sessions with the data network, packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0437] The AMF 272 may also be connected to the N3IWF 292 via an N2 interface. The N3IWF facilitates connectivity between the WTRUs 202a, 202b, 202c and the 5G core network 270 over an air interface technology not defined by 3GPP.

[0438] The PCF 284 may be connected to the SMF 274 via an N7 interface, to the AMF 272 via an N15 interface, and to an application function (AF) 288 via an N5 interface. The PCF 284 may provide policy rules to control plane nodes such as the AMF 272 and the SMF 274 and enable the control plane nodes to enforce these rules.

[0439] The UDM 278 serves as a repository for authentication credentials and subscription information. The UDM may connect to other functions such as the AMF 272, the SMF 274, and the AUSF 280.

[0440] The AUSF 280 performs authentication related operations and connects to the UDM 278 via the N13 interface and to the AMF 272 via the N12 interface.

[0441] The NEF exposes capabilities and services within the 5G core network 270. The NEF may connect to the AF 288 via an interface, which may connect to other control and user plane functions (280, 278, 272, 272, 284, 276, and the N3IWF) to expose capabilities and services of the 5G core network 270.

[0442] The 5G core network 270 may facilitate communication with other networks. For example, the core network 270 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G core network 270 and the PSTN 208. For example, the core network 270 may include or communicate with a Short Message Service (SMS) service center that facilitates communication via Short Message Service. For example, the 5G core network 270 may facilitate the exchange of non-IP data packets between the WTRUs 202a, 202b, 202c and a server. In addition, the core network 270 may provide the WTRUs 202a, 202b, 202c with access to the networks 212, which may include other wired or wireless networks owned and / or operated by other service providers.

[0443] As discussed above, Figure 36D is a block diagram of an example computing system 90 in which one or more devices of the communications networks illustrated in Figures 36A-C, 36E, 37A, 37C, 37D, 37E, and 37F may be embodied, such as a node or functional entity within the RAN 203 / 204 / 205, the core network 206 / 207 / 209, the PSTN 208, the Internet 210, or other networks 212. Additionally, the computing system 90 may include communications circuitry, such as, for example, a network adapter 97, that may be used to connect the computing system 90 to external communications networks, such as the RAN 203 / 204 / 205, the core network 206 / 207 / 209, the PSTN 208, the Internet 210, or other networks 212 of Figures 37A, 37B, 37C, 37D, 37E, and 37F, and enable the computing system 90 to communicate with other nodes or functional entities of those networks.

[0444] It will be understood that any or all of the systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium which, when executed by a machine, such as a node of an M2M network, including, for example, an M2M server, a gateway, a device, etc. (or by a processor, such as processor 32, 118, 218, or 91), performs and / or implements the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described above, including the operation of a gateway, a UE, a UE / GW, or any of the nodes of a mobile core network, a service layer, or a network application provider, may be implemented in the form of such computer-executable instructions. Logical entities such as a subscription service function (SSF) 2060, a user data repository 2032, a policy maintenance function (PMF) 2050, a policy enforcement function (PEF), an authorization authentication accounting (AAA) function 2028, a RAT interface function (RIF) 2102, a slice instance selection function (SISF) 2024, a slice instance management function (SIMF) 2026, a core network entry point (CNEP) 2020, an interconnection and routing function (IRF) 2058, a mobile originating ingress function (MOI) 2040, a mobile originating egress function (MOE) 2046, a mobile terminating ingress function (MTI) 2044, a mobile terminating egress function (MTE) 2042, a session management (SM) function 2048, and a mobility management (MM) function 2022 may be embodied in the form of computer-executable instructions stored on a computer-readable storage medium. Computer-readable storage media include both volatile and non-volatile, removable and non-removable media implemented in any non-transitory (i.e., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals.A computer-readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computer.

[0445] In describing preferred embodiments of the subject matter of the present disclosure as illustrated in the Figures, specific terminology is employed for the sake of clarity, however, it is understood that claimed subject matter is not intended to be limited to the specific terminology so selected, and each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[0446] This specification uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have elements that do not differ from the literal words of the claims, or if they include equivalent elements with insignificant differences from the literal words of the claims.

Claims

1. sending an initial attach message from a user equipment (UE) to a network node, the initial attach message including a temporary identifier and one or more network slice selection assistance information (NSSAIs), the one or more NSSAIs being associated with one or more services and including an indication of a connection request to one or more network slices; receiving, by the UE, a response message from the network node including an indication of whether a connection is allowed; receiving a request message from the network node, the request message including an indication of one or more second network slices that the UE is authorized to use; sending a response to the request message to the network node; A method comprising:

2. 2. The method of claim 1, wherein the UE initially determines to connect to a default slice and includes in the initial connection message a default indication associated with one or more of the respective NSSAIs.

3. The method of claim 1 , wherein the response message includes a new temporary identifier for the UE.

4. The method of claim 3 , wherein the network node interfaces with multiple network slices.

5. The method of claim 3 , wherein an underlay network routes control plane packets to a network function within the one or more network slices that the UE is authorized to use.

6. The method of claim 1 , wherein the initial attach message includes an indication of one or more capabilities of the UE.

7. The method of claim 6 , wherein the indication of one or more capabilities of the UE is a control plane only indication or a low mobility indication.

8. 2. The method of claim 1, wherein the UE is provisioned to check whether an access point of a certain frequency is available before deciding to access the one or more network slices.

9. 2. The method of claim 1, wherein the UE receives a broadcast including an identifier associated with a service reachable via a network before determining to access the one or more network slices.

10. The method of claim 1 , wherein the one or more identifiers of the one or more second network slices available to the UE include a default indication.

11. The method of claim 1 , wherein the request message is triggered in an underlay network by a subscription change.

12. sending, by the UE, to the network node, a new slice request including at least one identifier of the one or more network slices available to the UE; receiving, by the UE, from the network node, a new slice response including a second indication as to whether a connection to a slice from an identifier of the one or more network slices is permitted; The method of claim 1 further comprising:

13. The method of claim 12, wherein the new slice request is triggered by manual entry of a new service profile by a user into the UE or by an application level event in the UE.

14. 1. An apparatus comprising a processor and a memory coupled to the processor, the memory storing executable instructions that, when executed by the processor: sending an initial attach message from a user equipment (UE) to a network node, the initial attach message including a temporary identifier and one or more network slice selection assistance information (NSSAIs), the one or more NSSAIs being associated with one or more services and including an indication of a connection request to one or more network slices; receiving, by the UE, a response message from the network node including an indication of whether a connection is allowed; receiving a request message from the network node, the request message including an indication of one or more second network slices that the UE is authorized to use; sending a response to the request message to the network node; An apparatus for causing the processor to perform operations including:

15. The apparatus of claim 14, wherein the UE initially determines to connect to a default slice and includes a default indication associated with one or more of the NSSAIs in the initial connection message.

16. The apparatus of claim 14 , wherein the response message includes a new temporary identifier for the UE.

17. The apparatus of claim 14 , wherein the initial connection message includes an indication of one or more capabilities of the UE.

18. 20. The apparatus of claim 17, wherein the indication of one or more capabilities of the UE is a control plane only indication or a low mobility indication.

Images