WO2018232253A1 - Network exposure function - Google Patents

Abstract

A server determines the identity of a network exposure function (NEF) associated with a user equipment (UE), and provides the UE with information such as an NEF identifier, a UE external identifier, and a slice identifier which may be used to register the devices, applications, or functions. The NEF identity may be provisioned or provided automatically. The NEF identity may be determined dynamically, e.g., based on a network slice used by the user equipment. A data storage function (DSF) may be used to receive UE context information, such as reachability, location, data usage, and available radio access technologies (RATs), and a data storage function front end (DSF-FE) may receive and process a request from an NEF to read the context of a UE, e.g., determining whether to authorize the request, and may further provide the UE context. The DSF-FE may reside with the DSF or the NEF, for example.

Description

NETWORK EXPOSURE FUNCTION

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No.

62/520,247, filed June 15, 2017, the disclosure of which is hereby incorporated by reference in its entirety.

BACKGROUND

[0002] Machine-to-machine (M2M) systems, also called Internet-of-Things (IoT) or web of things (WoT) systems, often incorporate multiple interconnected heterogeneous networks in which various networking protocols are used to support diverse devices, applications, and services. These protocols have different functions and features, each optimized for one situation or another. There is no one-size-fits-all solution due to the diversity of devices, applications, services, and circumstances.

[0003] Various standards and proposed protocols, such as 3GPP and oneM2M, describe methods for various entities to establish connections and communicate at various layers of operation. Such an entity may be, for example, a local, serving, or packet data network gateway (L-GW, S-GW, or P-GW), user equipment (UE), application server (AS), a service capability server (SCS), a mobility management entity (MME), an evolved UTRAN node B (eNB), a service capability exposure function (SCEF), or a home subscriber server (HSS). Layers of operation may include, for example, evolved packet core (EPC)/AS(SCS) interfaces, 3GPP Core Network and Service Layer. Network service exposure functions and application layers on nodes such as UE, NEF, IoT Server, Core Network Data Storage Function, SMF, PCF, AMF, UPF, and analogous nodes on 3GPP, M2M, IoT, WoT, and similar systems.

SUMMARY

[0004] A server may determine the identity of a network exposure function (NEF) associated with a user equipment (UE). Standard registration methods may be enhanced to enable the network to provide the UE with information such as an NEF identifier, a UE external identifier, and a slice identifier. The information may be provided automatically by the server, for example, or upon request from the UE. UE applications and service layers may then use such information, e.g., by providing the NEF identifier or UE identifier, when registering with a server so that the server may identify and communicate with the associated NEF.

[0005] A data storage function (DSF) may be used to receive UE context information, such as reachability, location, data usage, and available radio access technologies (RATs). A data storage function front end (DSF-FE) may receive and process a request from an NEF to read the context of a UE, e.g., determining whether to authorize the request, and may further provide the UE context. The DSF-FE may reside with the DSF or the NEF, for example. Optionally, request processing may involve communications with a unified data management (UDM) entity or home subscriber service (HSS) for example.

BRIEF DESCRIPTION OF THE FIGURES

[0006] Figure 1 is a block diagram of an example 3GPP Architecture for SCEF.

[0007] Figure 2 is a block diagram of an example 5G System Service-based

architecture.

[0008] Figure 3 is a block diagram of an example Data Layer Interconnection Model.

[0009] Figures 4-6 show a call flow diagram of an example Registration Procedure.

[0010] Figure 7 is a call flow diagram of an example UE Obtaining an NEF Identifier and Providing it to the IoT Server.

[0011] Figure 8 is a block diagram of an example Hierarchical NEF Architecture.

[0012] Figure 9 is a block diagram of an example Data Storage Architecture for Unstructured Data from any NF.

[0013] Figure 10 is a block diagram of an example Exposure via a Common DSF.

[0014] Figure 11 is a call flow diagram of an example Context Retrieval via the NEF.

[0015] Figure 12 is a call flow diagram of an example Context Write via the NEF.

[0016] Figure 13 is a call flow diagram of an example AF Subscribing to UE Context via the NEF.

[0017] Figure 14 is an illustration of an example Third Party Service Exposure

Authorization GUI.

[0018] Figure 15 is a system diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented. [0019] Figure 16 is a system diagram of an example architecture that may be used within the M2M/IoT/WoT communications system illustrated in Figure 31.

[0020] Figure 17 is a system diagram of an example communication network node, such as an M2M/IoT/WoT device, gateway, or server that may be used within the

communications system illustrated in Figures 15 and 16.

[0021] Figure 18 is a block diagram of an example computing system in which a node of the communication system of Figures 15 and 16 may be embodied.

[0022] Figure 19 illustrates an example communications system.

[0023] Figure 20 is a block diagram of an example apparatus or device configured for wireless communications such as, for example, a wireless transmit/receive unit (WTRU).

[0024] Figure 21 is a system diagram of a first example radio access network (RAN) and core network.

[0025] Figure 22 is a system diagram of a second example RAN.

[0026] Figure 23 is a system diagram of a third example radio access network RAN.

[0027] Figure 24 is a system diagram of a fourth example radio access network RAN.

DETAILED DESCRIPTION

[0028] 3GPP is defining a 5G mobile core network (MCN). The architecture of the 5G network will rely on network function virtualization (NFV) techniques. When the MCN is virtualized, the NEF that an Application Function (AF) uses to interface with the MCN may change over time, e.g., depending on what network slice the UE is connected to. The MCN may be designed such that the compute logic and data storage parts of each Network Functions are separate logical entities. This type of design is well suited for allowing NFs to share data storage resources.

[0029] Herein methods and apparatuses are described whereby a NEF may obtain UE context information from the network, and the NEF may provide UE context information to the network such that the network functions in the slice do not need to be "NEF-aware". NEF interactions with the Data Storage Function (DSF) are also described. The example procedures are provided which allow the UE context, or state, information to be stored in the DSF and read from the DSF without interacting with the compute functions of the other network functions within the slice (e.g., UPF, SMF, PCF, AMF, etc.). [0030] Herein the term "procedure" may be used interchangeably with the term "method" to indicate a range of solutions using a common technique or methodology. The steps provided are meant as examples, and should not be taken to be rigid requirements.

[0031] For example, an IoT Server may determine the identity of an EF that is associated with the UE. The 5G UE General Registration Procedure may be enhanced to enable the network to provide the UE with information such as NEF Identifier, UE External Identifier, and Slice Identifier. UE Applications and Service Layers may then use this information when registering with an IoT Server so that the IoT Server may identify and communicate with the NEF.

TABLE 1

Acronyms

OFCS Offline Charging System

OS Operating System

PCF Policy Control Function

PEI Permanent Equipment Identifier

PFD Packet Filter Descriptions

QoS Quality of Service

RAN Radio Access Network

SCEF Service Capability Exposure Function

SCS/AS Service Capability Server/ Application Server

SDSF Structured Data Storage Function

SMF Session Management Function

SMS Short Message Service

SUPI 5G Subscriber Permanent Identity

UDM Unified Data Management

UDSF Unstructured Data Storage Function

UE User Equipment

UPF User plane Function

[0032] Herein the terms SCS/AS, application function (AF), application server (AS), Service Layer, Common Services Entity (CSE), M2M Server, and IoT Server are used interchangeably to refer to entities that may perform similar functions.

[0033] Herein the term UE context may refer to any information about a UE' s registration status/parameters, or about the UE's connection(s) to the network. For example, it may refer to the UE's periodic update timer value, IP address, location, etc.

[0034] A Service Capability Exposure Function (SCEF) is introduced in TS 23.682, Architecture enhancements to facilitate communications with packet data networks and applications. V15.0.0. The SCEF architecture is shown in Figure 1. The SCEF exposes an API (T8 Reference Point) to third party Application Functions. The API is used by the third party AF to access network capabilities and services such as monitoring, non-IP data delivery, group messaging, monitoring for potential network issues, change of chargeable party, background data transfer, setting up QoS, provisioning communication patterns, PFD management, device triggering, and SMS delivery.

[0035] The NEF is introduced in section 5.20, of TS 23.501, System Architecture for the 5G System; Stage 2. V0.3.1, where sections 4.2.5, 5.13, 6.2.5, 6.2.10, 6.2.11, 7.2.2, 7.3, 7.4, and A. l, for example, discuss NEF functionality.

[0036] Figure 2 shows the 5G system architecture from TS 23.501 and shows that the NEF is a service within the 5G system. The service based interface of the NEF is called Nnef Note that in 5G, the SCEF is called the NEF.

[0037] The NEF also has reference points towards the NF's that it interacts with. Thus far, TS 23.501 has only named one of the NEF reference points; N19 is the name of the reference point between the NEF and SDSF.

[0038] The NEF exposes network capabilities and services to an external party

Application Function (AF). Several capabilities and services that are mentioned in TS 23.501. These include: monitoring, such as UE location, reachability, roaming status, and loss of connectivity; provisioning, such as mobility patterns, communication patterns; policy/charging, such as session and charging policy, QoS, providing packet filter descriptions (PFDs); edge computing (AF mobility, traffic steering); information/data exposure; device triggering; and negotiation of background data transfer policies.

[0039] The NEF may receive data from other network functions, such as UE location information, and store it as structured data in the SDSF. The data may then be exposed to the external Application Function.

[0040] In the 5G system, NEF exposes an API to the external AF that allows the AF to access exposed capabilities.

[0041] The API's that are exposed by the SCEF will be a subset of the API's that are exposed by the NEF. Thus, from the perspective of the Application Function, any feature that is available in 4G should be available in 5G. However, the underlying logic that enables the functionality that is requested, or initiated, by an API call will be different in 5G compared to 4G.

[0042] The NEF will also expose capabilities that are not available in 4G. For example, the NEF will exposure capabilities such, as edge computing and Information/Data Exposure which are not available in 4G. [0043] S2-165772, Updates on Control plane interconnection model with a data layer, October 17-21, 2016, proposes that network functions in the 5G core network share a common data layer. The main principle of the proposal in S2- 165772 is to store (or expose) UE related context data to a data layer. This can include both near real-time storage of structured data and opaque data. Figure 3 shows how network functions under S2-165772 may share a common data layer. The solutions propose that while the subscriber data can be placed in a centralized location (e.g., UDM/HSS), context data (context data for a certain network function) should be placed close to the network function to reduce latency for data access and to meet the necessary performance criteria.

[0044] In 4G, the SCS/AS determines what SCEF to contact for a given MTC-IWF by performing a DNS lookup on the UE's external identifier. The DNS lookup resolves to an IP address of an SCEF that can be used to access services related to the UE. In a 5G mobile core network this DNS lookup approach is not sufficient. It is not sufficient because the NEF is part of a core virtualized network slice. If the UE was always connected to the same virtual slice, this would not be a problem. However, the UE may connect to more than one core network slice and the virtualized slice instances that the UE connects to may change over time. Since there may be an NEF associated with each slice that the UE connects to and the slice instances that the UE connects to may change, the NEF identity must be determined dynamically based on the slice that the UE is connected to.

[0045] In 4G, the SCS/AS may provide the SCEF with configuration information for a UE or a group of UE's. For example, the SCS/AS may provide communication patterns, sleep cycles preferences, etc. The SCS/AS may also request to be notified when a UE becomes reachable, loses connectivity, has a change of IMSI/IMEI association, etc. When the SCS/AS makes these types of request, the configuration information and subscription requests are passed to the HSS and the HSS sends them to the MME. This approach creates a situation where a significant amount of configuration data and subscription requests must be routed through a central point (the HSS) and then to the serving node (MME). In the 5G core network, it would be better if information or requests from the SCS/AS were not all routed through a central repository such as the UDM.

[0046] In 4G, each core network node that serves the UE stores some amount of context about the UE. Although the information might be useful to the SCS/AS, it is not typically exposed to the SCS/AS. Besides the security implications of sharing context, one of the primary reasons it is not exposed is the cost associated with the extra messaging that would be required to send the data to the SCEF. In 5G, compute logic may be separate from data storage functionality. Thus, in 5G, a method is needed to allow the NEF to obtain context information from a Network Function without requiring the compute logic associated with the Network Function to send additional messages.

[0047] A Network Exposure Function (NEF) may be implemented for a Virtualized Mobile Core Network. An IoT Server may determine the identity of the NEF that is associated with the UE. It describes updates to the 5G UE General Registration Procedure where the network can provide the UE with information such as NEF Identifier, UE External Identifier, and Slice Identifier. UP Applications and Service Layers may then use this information when registering with an IoT Server so that the IoT Server may identify and communicate with the NEF.

[0048] The NEF can obtain UE context information from the network and how the NEF can provide UE context information to the network such that the network functions in the slice do not need to be "NEF-aware". NEF interactions with the Data Storage Function (DSF) are described. The procedures are defined so that UE context, or state, information can be stored in the DSF and read from the DSF without interacting with the compute functions of the other network functions within the slice (e.g., UPF, SMF, PCF, AMF, etc.).

[0049] The problem of how the Application Function can determine the identity of the NEF that is associated with a UE Application may be addressed in a number of ways in various scenarios. For, example, in a first scenario, the NEF is a slice specific network function. In a second scenario, the NEF is a network function that is shared/common network function across multiple network slices. In a third scenario, an NEF-FE (NEF Front End) is defined. The Application Function can access this NEF-FE by default and use the NEF-FE to obtain the contact information for the NEF or to forward requests to the NEF.

[0050] The problem of how UE context is obtained from the network by the NEF and how the NEF subscribes to UE context/state information may also be addressed in a number of ways, including methods wherein requests do not need to be routed through a central repository such as the UDM. UE context/state information can be provided to the Application Function via the NEF, without requiring the compute logic associated with the Network Function to send additional messages.

[0051] In a first example, the NEF is part of a network slice, such that the AF does not need to be slice aware. The NEF that is contacted is only part of one slice.

[0052] When an SCS/AS wishes to provision a UE's communication pattern, send non- IP data to a UE, request notifications about a UE, etc., it needs to issue a request or send a message to the NEF. However, since the UE may connect to different network slices, the proper slice for the SCS/AS to contact may change dynamically.

[0053] When a UE registers or connects to a network slice, the network may provide the UE with an NEF identifier or a value that could be resolved to an NEF identifier. For example, the NEF identifier can be sent to the UE by the AMF. The UE could then provide this identifier to the SCS/AS when it performs service layer registration. The SCS/AS may then use the identifier to contact the NEF.

[0054] The procedure that is used by the UE to connect to a network slice is called the "UE General Registration" procedure as defined in section 4.2.2.2.2 of TS 23.502, Procedures for the 5G System; Stage 2. VO.2.0 and is shown in Figures 4-6. By modifying certain steps, this method may be updated to help the UE and SCS/AS identify the NEF.

[0055] For example, in step 1 of Figure 4, the UE sends an Access Network (AN) message to the (R)AN (AN parameters, Registration Request (Registration type, Subscriber Permanent Identifier or Temporary User ID, Security parameters, NSSAI, UE 5GCN Capability, PDU session status, Using NEF flag, SCS/AS identifier)). The message may be updated to include an indication that the UE will be communicating with an SCS/AS. The indication may be used by the network to determine that an NEF identifier should be provided to the UE. The message may also include the identity of the SCS/AS that the UE will be communicating with. This identifier may be used to help determine the best NEF to associate with the UE. Note that this new information could be contained in another field. For example, it could be captured in the UE 5GCN Capability field. There may be multiple Using NEF flags, and SCS/AS identifiers. For example, a Using NEF flag and an SCS/AS identifier may be associated with each NSSAI so that the network knows whether an NEF is needed in each slice. The

registration, or service activation, request may also include an indication of whether or not the UE wants the NEF to expose information related to the UE. The UE platform may support a GUI that allows the user to indicate if service/information exposure is allowed as shown in Figure 14. When it is not allowed, the UE may indicate that NEF exposure is not desired in the registration, or service activation, request. The GUI may also allow the UE to indicate which third parties are allowed to access services related to the UE. The UE may also indicate the allowed third parties in the registration, or service activation, request. The network may use this indication as a trigger to stop exposing information related to the UE and to stop allowed Application Functions to control the UE or send data to the UE via the NEF.

[0056] Step 2 of Figure 4, and all others not discussed herein, may proceed as described in TS 23.502.

[0057] In step 3 of Figure 4, the (R)AN sends an N2 message to the AMF: (N2 parameters, Registration Request (Registration type, Subscriber Permanent Identifier or

Temporary User ID, Security parameters, NSSAI, Using NEF flag, SCS/AS identifier)).

[0058] At some point after receiving the Registration Request message (Registration type, Subscriber Permanent Identifier or Temporary User ID, Security parameters, NSSAI, Using NEF flag, SCS/AS identifier) in step 3, the new AMF may query the NSSF or old AMF to determine what service(s), or slice(s), the UE will be allowed to access. The NSSF or old AMF will respond to the new AMF with the accepted S-NSSAI' s. The response from the NSSF or old AMF may include an NEF Identifier that is associated with each accepted S-NSSAI. The NEF identifiers may be an FQDN or URI that is associated with the NEF or UE. The identifier may be part of an NSSAI. The new AMF or NSSF may update a DNS Server prior to sending the identifier so that a DNS lookup on the identifier will resolve to an IP Address and Port Number of the NEF. This message may also include an indication of whether an NEF is associated with each slice, or S-NSSAI. Alternatively, the indication and identifier could be part of the S- NSSAI.

[0059] In step 22 of Figure 6, the AMF may send the Registration Accept message to the UE: Registration Accept (Temporary User ID, Registration area. Mobility restrictions, PDU session status, NSSAI, Periodic registration update timer, NEF Identifiers).

[0060] After receiving the Registration Accept with the NEF identifier, the UE may expose the NEF identifier information to applications that use a Slice that is associated with the NEF identifier. For example, the UE OS may expose an API that provides an application with a list of services that can be obtained from a network slice. The list may include one or more NEF identifiers. The list may be provided to the application whenever the application connects to the slice, or by an API that allows an application to browse or check what slice(s) the UE is connected to. Once a UE application obtains the NEF Identifier, it may provide it to an IoT Server. For example, it may be provided in a Service Layer registration message. Figure 7 shows an example procedure of how a UE application may obtain an NEF identifier and provide it to an IoT Server.

[0061] As an alternative to providing an NEF identifier in step 22, the network may provide the UE with an external identifier. The external identifier may be provided to the UE dynamically so that it can be associated with the slice. In other words, the external identifier will be associated with the UE's connection to a particular network slice. The identifier may be provided to the IoT Server during application, or service layer, registration and the IoT Server may use the external identifier to determine the NEF identity. For example, this may be done via DNS lookup.

[0062] In step 1 of Figure 7, the UE application calls an API that is used to obtain, from the UE OS, a list of slices that the UE is connected to, or is able to connect to. The list in the response from the UE OS also includes what services are available in each slice. The list may include an indication that an NEF is associated with a slice and the list may provide an NEF identifier.

[0063] In step 2, The UE Application calls an API to indicate that it wants to connect to a particular slice. If the UE is not already connected to the slice, then the UE OS may initiate the UE General Registration or Service Request procedure of [2] in order to initiate a connection to the network slice. The UE OS may respond to the API call with an indication that an NEF is associated with a slice and the response may provide an NEF identifier. An NEF Identifier may be provided to the UE during registration. Similarly, an NEF identifier may be provided to the UE during a Service Request procedure. This NEF Identifier that is provided to the UE during a Service Request procedure may be different than the one that was provided to the UE during the UE General Registration procedure, for example, when the network wants to change what NEF the UE is associated with.

[0064] In step 3, the UE Application sends a registration request to an IoT Server, the Registration request includes the NEF identifier. Note that the NEF identifier may be provided to the IoT Server in another type of message, for example it may be provided in a message that is specifically used to convey the NEF identifier to the IoT Server. The IoT Server may respond to the registration request.

[0065] In step 4, the IoT Server uses the NEF identifier to determine how to contact the NEF. For example, the IoT Server may perform a DNS lookup on the NEF identifier and obtain an IP Address and Port Number for the NEF.

[0066] In step 5, the IoT Server may then contact the NEF to perform operations related to the UE, such as NIDD, provisioning of Communication Patterns, monitoring, etc.

[0067] Note that the network may later indicate to the UE that the NEF has changed. For example, the network may indicate to the UE that the NEF has changed during an AMF relocation procedure or when an NSSAI changes. When this occurs, the UE OS may send an indication to the UE application that the NEF has changed. The UE Application may then send an indication to the IoT Server that the NEF has changed. This message may be a registration update, a notification, a RESTful resource update, or an attribute update.

[0068] In another example, the NEF is shared across network slices. This is different from scenarios in which the NEF is in a single slice, since here the AF needs to provide additional information when requesting services from the NEF. For example, the AF will need to provide the NEF with information about what slice(s) it wants to access services from.

[0069] The NEF may be a common, or shared, core network function. The term "shared" refers to sharing the NEF across multiple network slices. In other words, the NEF exposes all services and capabilities related to all Network Slices that the UE connects to. In this type of deployment, the NEF Identifier associated with the UE may still be provided to the UE during the General Registration procedure. However, when the UE Application registers with the IoT Sever (as shown in the example procedure of Figure 7), the UE Application must provide the identity of the slice that it is using in addition to the NEF identifier. The IoT Server needs the slice identity so that it can be provided to the NEF when making requests to the NEF. The NEF will use the slice identifier to determine what DSF-FE to contact.

[0070] The NEF may be a Front End that is associated with the PLMN. This scenario is illustrated in Figure 8. In this scenario, the Application Function may know what NEF-FE to contact based on the Home PLMN of the UE. The Home PLMN may be determined from a DNS lookup of the UE's external ID or it may be identified in the external identifier, for example the external identifier may be formatted so that the Home PLMN is named (e.g., user-name @ plmn-name.com). The request that the NEF-FE receives from the Application Function may include a UE identity (e.g., an external ID) and a network slice ID. The NEF-FE may use the UE identity and network slice ID to determine what NEF the request should be forwarded to. The NEF may be determined based on provisioned policies, or based on a DNS lookup of the external ID. The NEF-FE may determine the DNS server based on the network slice ID that was provided by the Application Function. Alternatively, policies could be dynamically provided to the NEF via procedures such as O&M.

[0071] As an alternative to the architecture as shown in Figure 8, instead of forwarding messages to the NEF, the NEF-FE may act as an NEF resolution function and may provide the Application Function with contact information so that the AF can directly contact the proper NEF.

[0072] In 4G, each core network node that serves the UE stores some amount of context about the UE or a group of UEs. Although the information might be useful to the SCS/AS, it is not typically exposed to the SCS/AS. Besides the security implications of sharing context, one of the primary reasons it is not exposed is the cost associated with the extra messaging that would be required to send the data to the SCEF. However, in 5G, compute logic may be separate from data storage functionality. Currently, TS 23.501 says that any network function may connect to its own UDSF via an N18 interface. Figure 9 is copied from TS 23.501 and illustrates how any network function may connect to an UDSF.

[0073] It should be appreciated that all network functions may be constructed as shown in Figure 9. Furthermore, they may be deployed such that multiple network functions in a slice share a common storage layer, or storage function (UDSF).

[0074] It is proposed herein that the "Unstructured Data" instead be "Structured". Here, the term "Structured" means that the data is formatted in a structured, or defined way, so that it can accessed, understood, shared, and modified by other network functions. This approach has several benefits in terms of the NEF.

[0075] Consider a scenario where an IoT Server queries the NEF to find a UE's IP Address. If the NEF needs to query a network function such as the SMF or UPF, e.g., to learn the UE's IP Address, then the NEF needs to first determine the proper SMF or UPF to query. However, if all network functions in a network slice store UE state information in a structured way and in a common Data Storage Function (DSF), then the NEF could retrieve the information from the DSF without needing to learn what SMF or UPF is serving the UE.

[0076] Another benefit of this approach is that network functions such as the SMF and UPF would not need to be "NEF Aware" in the sense that they would not need to authorize NEF access to their state information and would not need to be aware that their state information is being accessed by the NEF. The DSF could be tasked with managing NEF access to data in the DSF or an authorization function, such as a DSF Front End, could be used to manage NEF data accesses. These accesses can be authorized by the UE during the UE General Registration procedure. This architecture is illustrated in Figure 10, which shows the SMF, UPF, and PCF sharing a DSF. It should be appreciated that multiple UPF's, SMF's, and PCF's within a slice may share a single logical DSF that may be further partitioned into smaller DSFs. The DSF-FE may be a logical function that authorizes the NEF's access to the DSF. The DSF-FE

functionality may be part of the DSF or the NEF.

[0077] How the data is structured in the DSF should be considered. It is proposed herein that the data from each network function be stored such that it can be indexed based on UE identity (IMSI, SUPI, or PEI, etc.). However, it may be index based on other identities such as session ID, SMF ID or slice ID, Group ID, etc. By storing the data in this manner, the data associated with a particular UE can be accessed without regard to what network functions are currently serving the UE. Storing the data in this manner also provides the advantage that when a new network function begins serving the UE, the new network function can take over serving the UE without knowing the identity of the old network function. For example, when a new SMF begins serving the UE it can access the UE's context information directly from the DSF without contacting the old SMF. The new SMF may update some value in the DSF to indicate that it is now serving the UE and the old SMF may receive a notification that it is no longer the "serving" SMF.

[0078] The security of the data stored in the DSF should be considered. The network slice may serve multiple UE's but only wish to expose information related to some UE's.

Furthermore, there may be multiple NEF's and data associated with a particular UE that may only be exposed via certain NEF's. It is proposed herein that the NEF be provided with a key for each UE whose data it is permitted to access. The key may be provided to the DSF-FE when retrieving data for a UE. Furthermore, when the network function stores data in the DSF, the data may be encrypted such that it can only be read, or decrypted, if the NEF has the UE's key. Figure 11 shows an example procedure where an Application Function retrieves UE context from the DSF via the NEF. As shown in Figure 11, the NEF may also be able to access the UDM (directly or via the DSF-FE or via a UDM-FE). This connection allows the AF/NEF to access user's subscription data and state, or context, information. However, since the UDM is shared across network slices, it may be preferable that the NEF obtain information from other NF's in order to avoid a case where the UDM needs to service requests from many NEF's.

[0079] In step 1 of Figure 11, a network function stores context data in the DSF. The context data may be context information from the AMF, SMF, PCF, or UPF. The context data may be the UE's IP Address, Reachability Status, Location, Data Usage, available RATs, etc. The context data may be stored such that it can be indexed or retrieved with the UE's Identity (e.g., SUPI). The DSF may respond to the NF with an indication of whether or not the data was stored. The network function may encrypt the context information with a UE Specific Context Key that was provided by the UDM. This may be done so that only authorized network functions may later retrieve or modify the stored context. Note that, for each piece of information that the network function stores in the DSF, it may indicate whether or not the data may be exposed to other network functions and it may indicate what other network functions it may be exposed to.

[0080] In step 2, the Application Function makes a request to obtain context data related to a UE. The request may include the UE's identifier, a slice identifier, an AF Identifier, Context type, and a UE Specific Context Key. The context type identifies the context that is requested. For example, UE IP address, UE location, etc. The UE Specific Context Key may have been pre-provisioned in the Application Function or it may have been obtained from the UE Application during Application/Service Layer Registration. This key may be used to decrypt the UE context and indicate that the AF is authorized to obtain the context. The UE identifier may be the UE's SUPI or a public/external identifier. The request may be a request to obtain the UE's IP Address, location, reachability status, associated timer values (periodic registration timer, implicit deregi strati on timer, active timer value, maximum sleep duration timer, etc.). The slice identifier may have been provided to the Application Function by the UE during registration and is needed if the NEF is associated with more than one network slice. [0081] In step 3, the NEF issues a request to the DSF-FE to obtain the context information that was requested in step 2. This request may indicate the identity of the NEF and AF that issued the request. The NEF may have used the UE Specific Context Key to authorize the AF's request in step 2, or it may provide the UE Specific Context Key to the DSF-FE so that the DSF-FE may authorize the AF's request. If external ID was provided to the NEF in step 2, the NEF will translate the external ID to a SUPI.

[0082] In step 4, the DSF-FE issues a request to the Unified Data Management (UDM) to check if the NEF/AF is authorized to retrieve the requested context information. This request may include the identity of the NEF and AF, the type of context data that was requested, and the identity (SUPI) of the UE. The DSF-FE may have been provisioned with information indicating if the NEF/AF is authorized to obtain the context data. If authorization information is pre- provisioned, then steps 4 and 5 may not be necessary.

[0083] In step 5, the UDM responds with an indication of whether or not the NEF/AF is authorized to retrieve the context data. The response may also include a UE Specific Context Key that may be used to decrypt the requested context. The response may include the identity of the NF or DSF where the context is stored. The response may also include the identity of the NF that stored the context data.

[0084] In step 6, the DSF-FE makes a request to retrieve the requested UE context. The request may include an indication of the type of data that is requested, the identity of the UE (SUPI), the identity of the NF that stored the data, and the UE Specific Context Key that was obtained from the UDM during authorization.

[0085] In step 7, the DSF-FE uses the UE Specific Context Key to decrypt the data and replies with the request data.

[0086] In step 8, he DSF-FE forwards the requested data to the NEF.

[0087] In step 9, the NEF replies to the Application Function with the requested data.

[0088] In another example, the Online Charging System (OCS) in the network slice may also utilize the DSF. The OCS may store information in the DSF such as how much credit (monetary or bit count) remains in the UE's account. The NEF may provide the AF with access to this information as described in the procedure of Figure 11. Similarly, the Offline Changing System (OFCS) may use the DSF to store data such as Charging Data Records (CDRs). The NEF may provide the AF with access to CDRs as described in the procedure of Figure 11. [0089] Note that the UE Specific Context Key serves two purposes. It is used to authorize that the requestor (e.g., NEF, any NF, etc.) is permitted to access the context and it is used to decrypt the context.

[0090] Note that the Application Function may also provide context information to the network via the NEF. For example, the procedure of Figure 12 may be used to store information in the DSF, rather than to retrieve it. The AF may put polices or communication patterns in the DSF that may be retrieved by the PCF, AMF, SMF, or UPF. The policies may pertain to data flows between the IoT Server and Applications on the UE and they may describe the type of QoS treatment required for the flow. The communication patterns may pertain to when the UE is expected to communicate, be available to communicate, and when the UE is sleeping.

[0091] Network functions such as the PCF, AMF, SMF, or UPF may subscribe to the DSF such that they are notified when new context information is stored for a UE. For example, an NF may inform the DSF that it wants to be notified when new communication patterns or polices are stored or updated for a particular UE. When the context is updated or created, the DSF may send a notification to the network function. In this way, the NF is still not "NEF aware" in the sense that it does not know that the NEF put the policy in the DSF. In other words, the NF may not know what other NF created or updated the policy.

[0092] In another example, the NEF may store information in the DSF that pertains to the location of the IoT Server that the UE is communicating with and what flows terminate at the IoT Server. The SMF may receive a notification when this information is provided to the DSF and the SMF may use the information to re-assign the flow to a new UPF, the new UPF being closer to the IoT Server. When the SMF receives a notification that information has been updated or created in the DSF, the SMF may not necessarily use or accept the information. The SMF may have an active set of information and may have a pending set of information. When the SMF receives a notification, it may decide whether or not it wants to accept and use the data. If it decides that it wants to use the data, the SMF will update its active set with data from the pending set of data. Otherwise it will keep using the existing "active" data. If the data is not accepted by the SMF, the DSF may indicate to the NEF that its data was not accepted or acted on. The SMF may make this decision based on the source of the data or the UE Specific Context Key that was provided. Note that other mechanisms may be used to inform network functions about the UE context that may be provided via the NEF. [0093] For example, a network function may periodically poll the DSF for UE specific context information. Additionally or alternatively, The DSF may push the UE context information to the desired NF. The target NFs to contact may be provided in the original request from the AF, or may be known a priori by the DSF. For example, information about

communication patterns may be tied to the SMF NF. The DSF would then find the serving SMF on behalf of the AF (e.g., by asking the UDM), and send the context information to this SMF. Also, NF's may indicate to the DSF that an indication is desired when certain pieces of information are changed or added.

[0094] The procedure of Figure 13 can be used to allow the NEF/AF to subscribe to context data in the DSF. For example, steps 1 and 2 may be a request to subscribe to UE context data. Step 3 may be a request to authorize the subscription. Steps 5 may be used to indicate to the DSF that the NEF is subscribing to a piece of data and that a notification should be sent to the NEF when the data changes, is created, or enters a certain value range. Steps 6, 7, and 8 may be an indication of whether or not the subscription was established. Later, in step 9, when the subscribed data changes, is created, or enters a certain value range, a notification may be sent from the DSF to the DSF-FE to the NEF and to the AF as shown in step 10.

[0095] Additionally, the NEF/AF may subscribe to have notifications of change in context data, sent to one or more additional recipients. As a result, at Step 9, the DSF may send a notification to the AF/IoT Server and to additional recipients (including for example other NFs and the UE). The list of recipients may be specified in the original request from the AF/IoT Server (in Step 1).

[0096] An AF may use steps 1-8 of the procedure of Figure 12 to put QoS polices, charging polices, UE communication schedules, UE location restrictions (e.g., allowed or barred areas), etc. in the DSF. An NF, such as the PCF, AMF, or SMF that is interested in QoS polices, charging polices, UE communication schedules, UE location restrictions, that are related to a UE may use step 0 of the procedure of Figure 12 to subscribe and be notified when this information is placed in the DSF.

[0097] An AF may use the procedure of Figure 13 to subscribe and be notified when particular information in the DSF is updated. For example, the AF may subscribe to the case where a PCF updates a policy, the AMF updates the UE location, the AMF detects that the UE is in a barred or allowed area, the UE attaches, the UE's IMSI-IMEI association changes, etc., the SMF updates a UE's session information, etc. This context update from the NF is shown in step 9 of Figure 13.

[0098] Note that a UE may provide a GUI that allows the user to select if third parties are allowed to access services (data, notifications, and control) related to the UE. Whether or not third party networks service exposure is allowed can be indicated to the network in the General Registration procedure of Figures 4-6. The GUI may further allow the user to indicate which third parties are allowed to access services (data, notifications, and control) related to the UE. Which third parties are authorized can be indicated to the network in the General Registration procedure of Figures 4-6.

[0099] Example NEF services are listed in Table 2. Example DSF services that are listed in Table 3.

TABLE 2

Services Provided by the NEF

TABLE 2

Services Provided by the DSF

[00100] Figure 15 is a 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. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IoT/WoT as well as an IoT/WoT Service Layer, etc. Any of the client, proxy, or server devices illustrated or described herein may comprise a node of a communication system, such as the communication systems illustrated or described herein, e.g., in Figures 13, 14, 17, and 19-22.

[00101] The service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and/or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (e.g., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[00102] As shown in Figure 15, the M2M/ IoT/WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may 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), and the like. Further, the communication network 12 may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[00103] As shown in Figure 15, the M2M/ IoT/WoT communication system 10 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, device, and the like) of the network. For example, the Field Domain may include M2M gateways 14 and devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M/ IoT/WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M devices 18 are configured to transmit and receive signals, using communications circuitry, via the communication network 12 or direct radio link. A M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or other M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M Service Layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example.

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

[00104] Referring to Figure 16, the illustrated M2M Service Layer 22 in the field domain provides services for the M2M application 20, M2M gateways 14, and M2M devices 18 and the communication network 12. It will be understood that the M2M Service Layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M Service Layer 22 may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, or the like. The M2M Service Layer 22 provides service capabilities that apply to M2M devices 18, M2M gateways 14, and M2M applications 20. The functions of the M2M Service Layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc. [00105] Similar to the illustrated M2M Service Layer 22, there is the M2M Service Layer 22' in the Infrastructure Domain. M2M Service Layer 22' provides services for the M2M application 20' and the underlying communication network 12 in the infrastructure domain. M2M Service Layer 22' also provides services for the M2M gateways 14 and M2M 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 a Service Layer by a different service provider. The M2M Service Layer 22' may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like.

[00106] Referring also to Figure 16, the M2M Service Layers 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals may leverage. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The Service Layers 22 and 22' also enable M2M applications 20 and 20' to communicate through various networks such as network 12 in connection with the services that the Service Layers 22 and 22' provide.

[00107] The M2M applications 20 and 20' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned 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 systems integration, and provides these functions as services to the M2M applications 20 and 20'.

[00108] Generally, a Service Layer, such as the Service Layers 22 and 22' illustrated in Figure 16, defines a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M's Service Layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the Service Layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M Service Layer supports a set of Common Service Functions (CSFs) (e.g., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which may be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3 GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, 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 a network, an instance of the Service Layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a Service Layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in Figure 16 or Figure 18 described below.

[00109] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SO A) and/or a Resource- Oriented Architecture (ROA) to access services.

[00110] Figure 17 is a block diagram of an example hardware/software architecture of a node of a network, such as one of the clients, servers, or proxies illustrated or described herein, which may operate as an M2M server, gateway, device, or other node in an M2M network, such as the networks illustrated or described herein, e.g., in Figures 13, 14, 17, and 19-22. As shown in Figure 17, the node 30 may include a processor 32, non-removable memory 44, removable memory 46, a speaker/microphone 38, a keypad 40, a display, touchpad, and/or indicators 42, a power source 48, a 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 appreciated that the node 30 may include any sub- combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements any of the steps, operations, or functions described herein.

[00111] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. 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 in order to perform the 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 node 30 to operate in a wireless or wired environment. The processor 32 may run application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor 32 may also perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access- layer and/or application layer for example.

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

[00113] The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, device, and the like. 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, and the like. 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.

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

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

[00116] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. For example, the processor 32 may store session context in its memory, as described above. The nonremovable 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 (SFM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 to reflect the status of an M2M Service Layer session migration or sharing or to obtain input from a user or display information to a user about the node's session migration or sharing capabilities or settings. In another example, the display may show information with regard to a session state.

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

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

[00119] 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, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[00120] The node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[00121] Figure 18 is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications networks illustrated or described herein may be embodied, such as certain nodes or functional entities in the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, or Other Networks 112.

[00122] 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, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a

conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

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

Component Interconnect) bus.

[00124] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by processor 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

[00125] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[00126] Display 86, which is 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. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT -based video display, an LCD- based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[00127] Further, computing system 90 may contain communication circuitry, such as for example a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as network 12 of Figures 13 and 14, the RAN

103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, or Other Networks 112 of Figures 13, 14, 17, and 19-22, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[00128] It is understood that any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless and/or wired network communications. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non- transitory (e.g., tangible or physical) method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (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 which can be used to store the desired information and which can be accessed by a computing system.

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

[00130] 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 rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, indoor ultra-high broadband access, broadband access in a crowd, 50+ Mbps everywhere, ultra-low cost broadband access, mobile broadband in vehicles), critical communications, massive machine type communications, network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to- everything (eV2X) communications. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person 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.

[00131] Figure 19 illustrates one embodiment of an example communications system 100 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105/103b/104b/l 05b, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e is depicted in Figures 17-22 as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless

communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and/or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

[00132] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. Base stations 114b may be any type of device configured to wiredly and/or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b and/or TRPs (Transmission and Reception Points) 119a, 119b to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[00133] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103b/104b/105b, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MTMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

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

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

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

[00137] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively 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).

[00138] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A). In the future, the air interface 115/116/117 may implement 3 GPP NR technology.

[00139] In an embodiment, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b and TRPs 119a, 119b in the RAN

103b/104b/105b and the WTRUs 102c, 102d, may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[00140] The base station 114c in Figure 19 may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In an embodiment, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRUs 102d, 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 114c and the WTRUs 102e, may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 19, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106/107/109.

[00141] The RAN 103/104/105 and/or RAN 103b/104b/105b may be in

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

[00142] Although not shown in Figure 19, it will be appreciated that the RAN

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

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

[00144] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102e shown in Figure 19 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[00145] Figure 20 is a block diagram of an example apparatus or device configured for wireless communications in accordance with the embodiments illustrated herein, such as for example, a WTRU 102. As shown in Figure 20, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad/indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to, transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in Figure 20 and described herein.

[00146] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Figure 20 depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[00147] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface

115/116/117. For example, in an embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. Although not shown in Figure 19, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[00148] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[00149] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in Figure 19 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[00150] Figure 20 is a block diagram of an example apparatus or device configured for wireless communications in accordance with the embodiments illustrated herein, such as for example, a WTRU 102. As shown in Figure 20, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad/indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in Figure 20 and described herein.

[00151] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Figure 20 depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[00152] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface

115/116/117. For example, in an embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the

transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet an embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [00153] In addition, although the transmit/receive element 122 is depicted in Figure 20 as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

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

[00155] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the

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

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

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

[00158] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[00159] The WTRU 102 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[00160] Figure 21 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in Figure 2, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[00161] As shown in Figure 21, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node- Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.

[00162] The core network 106 shown in Figure 21 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

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

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

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

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

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

[00168] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in Figure 22, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[00169] The core network 107 shown in Figure 22 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

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

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

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

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

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

[00175] As shown in Figure 23, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like. [00176] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for

authentication, authorization, IP host configuration management, and/or mobility management.

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

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

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

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

[00181] The core network entities described herein and illustrated in Figures 17 and 19- 22 are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3 GPP, including future 3 GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in Figures 19 and 21-24 are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

[00182] The 5G core network 170 shown in Figure 24 may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, a user plane function (UPF) 176, a user data management function (UDM) 178, an authentication server function (AUSF) 180, a Network Exposure Function (NEF), a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 192 and an application function (AF) 188. While each of the foregoing elements are depicted as part of the 5G core network 170, it will be appreciated 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 appreciated that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 24 shows that network functions directly connect to one another, however, it should be appreciated that they may communicate via routing agents such as diameter routing agents or message buses. [00183] The AMF 172 may be connected to each of the RAN

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

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

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

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

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

[00188] The UDM 178 acts as a repository for authentication credentials and subscription information. The UDM may connect to other functions such as the AMF 172, SMF 174, and AUSF 180.

[00189] The AUSF 180 performs authentication related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface. [00190] The NEF exposes capabilities and services in the 5G core network 170. The NEF may connect to an AF 188 via an interface and it may connect to other control plane and user plane functions (180, 178, 172, 172, 184, 176, and N3IWF) in order to expose the capabilities and services of the 5G core network 170.

[00191] The 5G core network 170 may facilitate communications with other networks. For example, the core network 170 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the 5G core network 170 and the PSTN 108. For example, the core network 170 may include, or

communicate with a short message service (SMS) service center that facilities communication via the short message service. For example, the 5G core network 170 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, 102c and servers. In addition, the core network 170 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

Claims

We claim:

1. An apparatus comprising a processor, a memory, and communication circuitry, the

apparatus being connected to a communications network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to:

receive a data storage function front end request comprising a first request for user equipment context information of a user equipment;

process the data storage function front end request; and

to respond to the data storage function front end request.

2. The apparatus of claim 1, wherein the user equipment context information comprises a user equipment internet protocol address, a user equipment timer value, a user equipment reachability status, a user equipment location, a user equipment data usage, or an available user equipment radio access technology.

3. The apparatus of claim 1, wherein the computer-executable instructions further cause the apparatus to provide a network exposure function service.

4. The apparatus of claim 3, wherein the network exposure function service comprises a data storage function front end.

5. The apparatus of claim 1, wherein processing the data storage function front end request comprises communicating with an authorization entity.

6. The apparatus of claim 5, wherein the authorization entity is a unified data management entity or home subscriber service.

7. The apparatus of claim 3, wherein the computer-executable instructions further cause the apparatus to provide, to the authorization entity, a context key. The apparatus of claim 1, wherein the computer-executable instructions further cause the apparatus to subscribe to a data storage function to receive notifications of changes in a context of a user equipment.

The apparatus of claim 2, wherein the computer-executable instructions further cause the apparatus to:

receive and store user equipment context information;

receive a second request for context information of the user equipment; and respond to the second request for context information of the user equipment.

The apparatus of claim 9, wherein processing the data storage function front end request comprises communicating with an authorization entity.

The apparatus of claim 10, wherein the authorization entity is a unified data management entity or home subscriber service.

The apparatus of claim 8, wherein the computer-executable instructions further cause the apparatus to provide a network exposure function service.

The apparatus of claim 8, wherein the user equipment context information comprises a user equipment identifier, a user equipment internet protocol address, a connectivity state, a roaming status, a slice identifier, or timer value associated with a slice.

The apparatus of claim 1, wherein the computer-executable instructions further cause the apparatus to subscribe to a data storage function to receive notifications of changes in a context of a user equipment.

15. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a communications network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to:

receive network exposure function information; and

when registering with a server, provide a portion of the network exposure

function information.

17. The apparatus of claim 16, wherein the computer-executable instructions further cause the apparatus to request the network exposure function information.

18. The apparatus of claim 16, wherein the network exposure function information comprises a network exposure function identifier, a user equipment identifier, or a slice identifier.

19. The apparatus of claim 17, wherein the computer-executable instructions further cause the apparatus to provide a server identifier to the network.

20. The apparatus of claim 16, wherein the computer-executable instructions further cause the apparatus to receive a list of available network exposure functions.