CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62/451,314, filed January 27, 2017, the disclosure of which is incorporated by reference in its entirety.

BACKGROUND

[0001] In mobile networks, implicit authorization is typically assumed for a user equipment (UE) once it is successfully authenticated by the network. That is, immediately after a UE is authenticated through an eNB, mobile management entity (MME) and home subscriber server (HSS), service-related traffic (e.g., user or control plane) may be automatically allowed to flow through the S/P-GW into the network. In cases, Proximity Services (ProSe) may use a form of explicit authorization for a UE, but it is specifically designed for Device to Device (D2D) discovery and communication services. It is recognized herein that current approaches to authorizing a given UE lack capabilities. For example, in typical existing mobile networks, there is typically no explicit authorization of a UE or network entity before granting access to a particular resource or service.

SUMMARY

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

[0003] In an example, a Subscription Profile (SP) is extended to support dynamic service authorizations in addition to implicit service authorizations. Authorization information may be defined, provisioned, or updated on UE/Network/3 ^rd Party Application Server centered on a subscription profile that captures authorization information for basic services, gated services (also referred to as restricted services), and negotiated services. The authorizations may enable a UE to gain access to a service or slice. [0004] In an example, application layer services are separated from the underlying network provisioned services, and aligned with the delivery of the services via service flows through network slices(s). Authorization may be performed at the various OSI layers.

[0005] In an example, a node in a serving network receives a service request from a device to use a service. The device may have a home network that is different than the serving network. For example, the device may be a subscriber to a home network. The node may read information from a subscription profile associated with the device to determine whether the service is in a set of pre-authorized services. The node may determine, based on the information from the subscription profile, that the service is not a pre-authorized service. The node may send a message to the home network to determine whether the home network authorizes the device to access the service corresponding to the service request. When the device is authorized, the node may provide the device access to the service. Further, in an example, the subscription profile may be updated such that the service is in the set of pre-authorized services. Thus, after the device uses the service, the node may receive a second service request from the device to use the service, and the node may read information from the updated subscription profile associated with the device to determine that the service is in the set of the pre-authorized services. The updated subscription profile may indicate that the home network has authorized the device to access the service in response to the service request. In some cases, the access to the service may be limited to certain criteria. For example, access may be limited to a specific time duration or geographic location.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Fig. 1 is a block diagram that depicts a dynamic subscriber service authorization aspect in accordance with an example embodiment.

[0007] Fig. 2 illustrates an example of dynamic authorization for a gated or restricted service.

[0008] Fig. 3 illustrates another example of dynamic authorization, wherein the dynamic authorization includes dynamic service alignment/negotiation.

[0009] Fig. 4 depicts an example of a subscription profile (SP) for service authorization that is based on the subscription profile.

[0010] Fig. 5 shows another example of a subscription profile that can be implemented and updated during a dynamic service authorization. [0011] Fig. 6 is a call flow for dynamic authorization by an operator in accordance with an example embodiment.

[0012] Fig. 7 is a call flow for dynamic authorization by a trusted third party in accordance with an example embodiment.

[0013] Fig. 8 shows a home routed (HR) scenario for a UE service dynamic authorization in a NextGen Network Roaming Reference Architecture.

[0014] Fig. 9 shows a local break out (LBO) scenario for a UE service dynamic authorization in a NextGen Network Roaming Reference Architecture.

[0015] Fig. 10 is a call flow for an example basic service authorization in an HR scenario.

[0016] Fig. 11 is a call flow for an example basic service authorization in an LBO scenario.

[0017] Fig. 12 is a call flow for an example gated service authorization in an HR scenario in accordance with an example embodiment.

[0018] Fig. 13 is a call flow for third party issued authorization for a gated service using LBO in accordance with an example embodiment.

[0019] Fig. 14 is a call flow for an example negotiated service authorization in an HR scenario in accordance with an example embodiment.

[0020] Fig. 15 is a call flow for an example negotiated service authorization in an LBO scenario.

[0021] Fig. 16A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0022] Fig. 16B is a system diagram of an example WTRU that may be used within the communications system illustrated in Fig. 16A.

[0023] Fig. 16C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in Fig. 16A.

[0024] Fig. 16D is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in Fig. 16 A.

[0025] Fig. 16E is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in Fig. 16 A. DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0026] In some examples, a given user equipment (UE) is authorized to access a service based on a subscription profile associated with the UE. This subscription profile (SP) based authorization model, in some cases, has been successful from an interoperability standpoint, for example, when applied to a limited market of services that are mostly driven by operators. It is recognized herein, however, that this approach may pose issues from a 5G system standpoint. For example, the current SP based authorization model might not, in some cases, scale to adequately support the diversity of services offered in 5G networks. The current SP based authorization model might not adequately cater to network deployments comprising a Network Slice (NS) architecture, wherein multiple stakeholders may be involved in providing the 5G network services. The current SP based authorization model may, in some cases, hinder an operator's ability to differentiate its service offerings when seeking to create a competitive advantage other than cost. By way of another example, the current SP based authorization model may make it difficult for an operator to address the requirements for more agile new service deployments, a particular requirement enabling operators to compete with over-the-top OTT providers. By way of yet another example, is recognized herein that a mismatch between services available in a Serving Network (SN) and those described in the Subscriber Profile (SP) may lead to inappropriate authorization to a service.

[0027] Issues from the end user point of view are also recognized herein. For example, and without limitation, it is recognized herein that the probability for a user to obtain the exact same service or enjoy a comparable QoS from a Serving Network (SN) while roaming may be further reduced given the expected increased diversity of services between the Home Network (UN) and SN in a 5G context. Also, there may an inability for a user to access additional or modified services available in a SN, beyond the services that are provisioned in their

subscription profile.

[0028] Referring now to Fig. 1, an example conceptual system 201 is shown in accordance with an embodiment, in which a Subscription Profile (SP) 203 is extended to support dynamic service authorizations. In accordance with the illustrated example, the SP 203 is associated with a user or subscriber 205. Services that may be dynamically authorized in the system 201 include negotiated services 202 and gated services 204 (also referred to as restricted services). In addition, basic services 206 may be implicitly authorized in the system 201. [0029] In an example, the Basic Services 206 are enabled in the SP 203 as per an existing service contract between the user 205 and the operator of its Home Network (HN) 207. The basic services 206 may consist of standard defined service flows (e.g., VoIP call, text messaging), which may be readily available in any network and enabled by default in the SP 203 of the user 205. When the user 205 is authenticated and requests one of the Basic Services 206 from a Serving Network (SN) 209, it may be automatically authorized by inspecting the configuration in the SP 203.

[0030] In an example, the Gated Services 204 may refer to services that have some of their respective service flows enabled, and others disabled in the SP 203. As used herein, a gated service may also be referred to as a restricted service, without limitation. A disabled service flow may be an optional service flow provisioned in the SP 203 and turned off by default. For example, when the user 205 has been authenticated and requests a given gated service 204 such that an optional service flow is included in the request from the Serving Network 209, a dynamic authorization with the HN 207 may be initiated, and the given gated service may be enabled in the SP 209.

[0031] The gated services 204 may include services with varying or limited coverage. For example, in some cases, an ultra-high speed video service flow might be not possible in resource limited networks. In some examples, the HN 207 may authorize such a service on a case-by-case basis after considering aspects such as, for example, the subscriber's (e.g., user 205) service plan, the capabilities of the SN 209 and agreed upon roaming charges or the like, physical location of the user 205, public land mobile network (PLMN) identity (ID), time of day associated with the service request, capabilities of a device 211 of the user 205, etc. Unless otherwise specified, subscriber/user 205 and device 211 may be used interchangeably herein, without limitation. By way of another example, a particular service flow may be offered on demand (or on a pay-per-use basis) by the HN 207 after a dynamic authorization. For example, the HN 207 may check a service rating or a user account standing. Alternatively, or additionally, a dynamic authorization may include a user confirmation or permission from the user.

[0032] Referring now to Fig. 2, an example use case implementing gated services 204 is shown. In accordance with the illustrated example, the user 205 may utilize a Voice Call (VC) service (e.g., from a rich chat application), which may be one of the basic services 206. In addition, for instance while getting to a vehicle of the user 205, the user 205 may turn-on an infotainment system that requires access to other services, such as High Mobility Data and Video Streaming for example. As shown, authorization policies for both static services (e.g., Voice Call) and dynamic services (e.g., Video Streaming) authorization may be captured in the user's subscription profile 203. At 1, in accordance with the illustrated example, the infotainment system sends the request for the Video Streaming and High Mobility Data services to the SN 209. Thus, the SN 209, in particular a node of the SN 209, may receive a service request from a device to use a service. The device can have a home network that is different than the serving network. In an example, at 2, the SN 209 checks a cached or pre-authorization SP 203a to determine whether the requested services are gated services 204. The SN 209, and in particular a node of the SN, may read information from the SP associated with the device to determine whether the requested service is in a set of pre-authorized services. The SP 203a may be obtained from the HN 207 or from the device 211. In an example, the SN 209 may determine, based on the information from the subscription profile 203a, that the service is not in the set of pre-authorized services.

[0033] Still referring to Fig. 2, if at least one of the requested services are ones of the gated services 204 or the requested service is not in the set of pre-authorized services, then the SN 209 may forward the service request to the HN 207 (at 3) for an extra level of authorization. For example, the SN 209 may send a message to the HN 207 to determine whether the HN 207 authorizes the device to access the service corresponding to the service request. Thus, the HN 207 may receive, from a serving network of a subscriber, a service request for a service that is restricted by the home network, and the service may include a plurality of features. At 4, in accordance with the illustrated example, the HN 207 performs a verification based on the content of the SP 203a and based on the context of the request. At 4, the HN 207, based on the SP 203a and the request, may determine whether to grant access to the requested gated service. In another example, the HN 207 may read information from the SP 203a associated with the subscriber 205 to determine that at least one of a plurality of features must be authorized by the HN 207.

[0034] At 5, in accordance with the illustrated example, the HN 207 updates the SP 203a to generate a post-authorization check or updated SP 203b. The HN 207 may update the subscription profile to reflect its authorization decision. In an example, the SP 203 a is updated to define the updated SP 203b that now includes the requested service in the set of pre-authorized services. The authorization decision, and thus the updated subscription profile, may indicate whether a particular gated service was granted or denied. The subscription profile may also be updated to indicate a scope (e.g., time, location, number of sessions) associated with the authorization decision. For example, updating the subscription profile may include authorizing the subscriber access to the service for a specific time duration. By way of another example, the HN 207 may update the subscription profile so as authorize the subscriber access to the service while the subscriber is within a specific location area. In another example the service may be granted for a specified number of pre-granted sessions. In an example, a service may be authorized without updating the SP. For example, in some cases, the service may be authorized for a single session only, thus the SP is not updated. In an example, when the specific number is one, the subscription profile is not updated based on the authorization message, and when the specific number is greater than one, the subscription profile is updated based on the authorization message. In some cases, the HN may authorize the subscriber to access the service for a specific number of sessions, such that, when the subscriber has accessed the service for the specific number of sessions, the subscriber must receive another authorization from the HN to access the service again. A token or variation thereof can be be used for the authorization. For example, after the specific number of sessions has been reached, the SN may request that the HN provide a new authorization. In the illustrated example, still referring to Fig. 2, video streaming is granted for 4K but denied for 8K. The subscription profile 203 is updated to reflect the authorization decisions with respect to video streaming in 4K and 8K. In particular, the cached SP 203a can be updated in the SN 209 so that, in some cases, there is faster re-authorization should there be subsequent requests for the same services in a similar context.

[0035] Still referring to Fig. 2, in accordance with the illustrated example, at 6, the HN 207 responds to the SN 209 with its authorization decision. The HN 207 may send an authorization message to the SN 209 to enable at least one feature of the requested service, so as to authorize the subscriber 205 to access the service. In particular, at 6, the HN 207 informs the SN 209 that the user 205 is authorized to stream 4K video. At 7, the SN 209 indicates to the device 211, and thus the user 205, that the user 205 is authorized to access the gated service, in particular 4K video streaming. When the device 211 is authorized, the SN 209 may provide access to the service. Thus, the user 205 can access the gated service, which is a service that was not authorized as part of the pre-authorization SP 203 a. As mentioned above, the authorization may be limited to a scope defined by the HN 207. For example, based on the authorization, the SN 209 may provide the device 211 access to the service for a specific time duration authorized by the home network, and may deny the device access to the service when the specific time duration expires. Alternatively, or additionally, the SN 209 may provide the device access to the service for a specific location area authorized by the home network, and deny the device access to the service when the device is not in, for instance exits, the specific location area. The SN 209 may enforce these restrictions on behalf of the HN 207. Alternatively, or additionally, software/firmware within the device 211 may enforce the service restrictions such that the UE 211 is not able to receive the service once it has moved out of the authorized location.

[0036] In an example, after the subscriber 205 has terminated the use of the service, the SN 209, in particular a node within the SN 209 may receive a subsequent service request from the device to use the same service that was previously authorized. In response to the subsequent service request, the SN 209 may read information from the updated subscription profile associated with the device to determine that the service is in the set of the pre-authorized services. The updated subscription profile may indicate that the home network has authorized the device to access the service in response to the previous service request. Thus, the SN 209 may be providing the device access to the service again without seeking authorization from the HN 207. As mentioned above, the SN 209 may provide the device access to the service for a specific time duration indicated in the updated subscription profile 203b, and deny the device access to the service when the specific time duration expires. In addition, or alternatively, the SN 209 may provide the device access to the service for a specific location area indicated in the updated subscription profile, and deny the device access to the service when the device is not in, for instance exits, the specific location area.

[0037] In an example, the Negotiated Services 202 refer to services that are not provisioned by the operator of the HN 207 in the SP 203. When an authenticated user 205 discovers and requests such a service (a service that is not provisioned in the SP 203) from the SN 209, a two-step process may be initiated in accordance with an example embodiment. A dynamic service negotiation to align the SN service with an equivalent HN service may occur. Then a dynamic authorization from the HN 207 may be initiated. By way of an example use case, with respect to dynamic service negotiations between a given SN and the HN, roaming users may be authorized to consume services beyond those provisioned in their SP (e.g., Wi-Fi roaming). By way of another example use case, network operators may be able to adapt service offerings and deliver a more tailored service experience beyond what is delivered with the basic services 206 or the gated services 204. It will be understood that the use cases for dynamic service negotiations are not limited to the examples described herein, and all such use cases are contemplated as being within the scope of this disclosure.

[0038] Referring now to Fig. 3, an example of dynamic/negotiated services is illustrated by way of an example use case. Referring to Fig. 3, the subscriber 205 wants to use an enhanced mobile broadband (eMBB) type of service, which is referred to in the example as service "A." In the example, the subscriber 205 typically accesses service A when connected to his or her HN 207. The subscription of the subscriber 205, and thus the SP 203, allows the subscriber 205 to continue using service A while roaming. But, in some cases, not all roaming partners (serving networks) can provide the fullness of service A. For example, some features of service A might not be accessible from an application that the subscriber 205 wants to run when service A is accessed from certain serving networks. In the illustrated example, the SN 209 does not support quality of service (QoS) "C" or feature "Y." By way of example, QoS C might represent 4K video streaming, and feature Y might represent the ability to enable dynamic subtitles in a video, though it will be understood that QoS parameters and service features are not limited to those examples.

[0039] With continuing reference to Fig. 3, at 1, in accordance with the illustrated example, the subscriber 205 requests service A from the SN 209. The subscriber 205 (or device 211) can have a home network that is different than the SN 209. Thus, the SN 209 may receive a service request from the device 211 to use a service that defines a plurality of characteristics. When the SN 209 receives the service request, the SN 209 may determine that it cannot offer the subscriber all of features and quality associated with service A. Thus, based on the service request, a node of the SN 209 may determine that the SN 209 cannot offer one or more of the plurality of characteristics of the requested service. For example, the SN 209 may determine that it can offer the subscriber 205 a subset of the features typically included as part of service A. At 2, the SN 209 may determine whether the subscriber 205 is authorized by the FIN 207 to receive access to dynamically tailored services (i.e. negotiated services). For example, the SN 209 may retrieve information from the SP 203 of the subscriber 205 to determine whether the subscriber 205 can access dynamically tailored services. In an example, the SN 209 may read information from the SP 203 associated with the device 211 to determine whether the device 211 is authorized to receive dynamically tailored services. If the subscriber 205 is authorized to receive access to dynamically tailored services from the SN 209, the SN 209 may send a service request to the FIN 207, at 3. Thus, when the device 211 is authorized to receive dynamically tailored services, the SN 209 may send a message to the HN 207 indicating which of the plurality of characteristics of the first service the SN 209 can offer. The service request at 3 may be for a dynamically tailored service, which is illustrated as service "Α'." In an example, service A' provides a subset of the features provided by service A. In the accordance with the illustrated example, service A provides QoS characteristics A, B, and C, and provides features X and Y. Service A', which is the service in the example that the SN 209 can offer, provides a subset of service A, in particular QoS characteristics A and B, and feature X. By way of example, it may be that the SN 209 does not have the capability to provide QoS with characteristic C. Similarly, in some cases, the SN 209 may not be able to interpret feature Y, and thus cannot provide feature Y.

[0040] At 4, in accordance with the illustrated example, the subscriber's HN 207 determines whether the subscriber 205 is authorized to receive access to dynamically tailored services in this case. For example, the HN 207 may evaluate context associated with the request, for example time and location associated with request, to determine whether the subscriber 205 is authorized. When the subscriber is authorized, the HN 207 may merge the subscribers requested service (Service A) with an offer from the SN 209 to define the service (e.g., Service A') that is authorized for the subscriber 205 to access (at 5). To perform the merging, and thereby define Service A', the HN 207 may rely on the service level agreement (SLA) between the subscriber 205 and the HN 207. Thus, a second service may be defined that is adapted from the requested service. The HN 207 may respond to the SN 209 with service information of the second service (e.g., Service A') that the subscriber 205 is authorized to access. Also, as described above, the HN 207 may update the subscription profile 203 of the subscriber 205. Thus, the request for a service (e.g., Service A) can be adapted to align with the capabilities of the SN 209, rather than being denied entirely. At 5, in response to the message at 3, the SN 209 may receive an authorization response from the HN 207 to offer the subscriber 205 the second (adapted or merged) service. At 6, the SN 209 sends a notification to the subscriber 205 that the subscriber 205 can access Service A'. By way of an example, the subscriber 205 may be notified, for example via an application on the device 211, what services are available and what terms (e.g., cost) are associated with the available services. In some cases, the subscriber 205 may choose to accept or reject the terms. By way of example, in some cases, when the subscriber 205 decides to use the tailored service (e.g., Service A'), the HN 207 may be able to charge the subscriber 205 a discounted price because the subscriber is unable to attain the full experience associated with the requested service (e.g., Service A).

[0041] Turning now to what entails authorization of services for a subscriber, the types of authorizations described herein may be requested and granted in a dynamic manner, which may or may not involve negotiations between a Subscriber (UE/User), Serving Network, Home Network and/or a Trusted Third Party. As used herein, unless otherwise specified, service authorization for a subscriber may refer to one or more of authorization at the application layer, authorization at the service layer, authorization at the network layer, authorization at the MAC layer, authorization at the physical layer.

[0042] In an example, an authorization at the application layer refers to an authorization in which a subscriber has been authorized to use a particular application that is provided by an Application Service Provider (ASP). An example of such an authorization is where a subscriber has been authorized to use a "Whatsapp" messaging service. Generally, an authorization at the application layer is beyond the scope of a mobile network operator (MNO) and is provided by an applications service provider (ASP), such as an Over-The-Top (OTT) service provider. In most cases, the MNO is agnostic to the application/ASP and the MNO only provides a connectivity service (e.g., network communications service) between the subscriber and the OTT. In other cases, the MNO may work very closely with an OTT. In certain other cases, it is possible for an ASP to be controlled and hosted by an MNO, such as a video content providing service (e.g., Video-on-Demand).

[0043] In an example, an authorization at the Application Layer indicates that authorization for lower layers, for instance all the lower layers, may have been granted or is required to be granted. The authorization may be agreed upon between the ASP and MNO, for instance as part of a service level agreement (SLA) or dynamically. A Proof-of- Authorization (PoA) (e.g., access token(s), signed message(s)) at the application layer may be used to grant authorization(s) for the other lower layers (e.g., Service, Network, MAC or Phy layers). The granting of authorization for lower layer(s) may entail the issuance or exchange of a newer PoA that are applicable to the lower layers.

[0044] With respect to authorization at the service layer, in an example, this type of authorization indicates that a subscriber has been authorized to access a particular type of service or service class. The type of service/service class may be, for example, eMBB, URLLC, mMTC, voice, text, or basic Internet access. In an example 5G scenario, an authorization at the service layer implies that a subscriber has been authorized to access a particular service, which may be delivered over an instantiation of a particular slice. In some cases, however, if the service characteristics require several different types of Service Flows (SF) or if load balancing is necessary, then a subscriber may be provided with access to multiple slice instances that meet the subscriber's needs.

[0045] In an example, in order for a subscriber to be able to use a particular application (provided it has been authorized), the subscriber may be authorized to access one or more slices. In most cases, an authorization for a service at the service layer provides access to particular slice instances that fulfill the requested service. Even in such cases, in an example, the subscriber may only be granted access to those exact slice instance(s). In some cases, an authorization at the service layer implies that the control functions (e.g., VNF for mobility management) within a particular slice have been authorized to process control plane (CP) messages from/to that authorized subscriber in order that the subscriber can be provided with a service. The authorization may be agreed upon between the ASP and MNO as part of a SLA and information configured in a SP, or the authorization may be determined dynamically. Alternatively, a PoA from an application layer that may be in the form of a signed message or token may be used to provide authorization for the service layer (e.g., slice instance(s)). The PoA from the application layer may carry information on service layer characteristics (e.g., class of service such as: eMBB or even more granular characteristics such as SF requirements or VNF for mobility management etc.).

[0046] In an example, an authorization at the network layer refers to an authorization in which a subscriber has been authorized, so that the packets from or to the subscriber can be routed within the service provider's network (e.g., MNO). This may imply that the subscriber has been authorized to route control and data packets within the routing/s witching fabric, for both Control Plane (CP) and User Plane (UP) VNFs. The authorization may be agreed upon between the ASP and MNO as part of a SLA and information configured in a SP, or the authorization may be determined dynamically, for example. Alternatively, a proof-of-authorization (PoA) in the form of signed messages or token(s) may be used to convey authorization from the service layer to the network layer. An example mechanism to provide for such an authorization and enforcement of authorization is by making use of techniques such as software-defined- networking (e.g., open flow). The PoA may carry information on the required network layer QCI characteristics (e.g., QoS: bandwidth, delay, jitter etc., security: message

integrity/confidentiality, etc.) for the UP/CP. The VNFs may use the PoAs addressed to it as a means to provide the requested service and the assoicated service characteristics (e.g., QCI, security level).

[0047] In an example, an authorization at the MAC layer indicates that the subscriber may be authorized to use a particular type of Radio Access Network (RAN), such as 5G RAN, Wi-Fi, or some other radio network. As an example, if high bandwidth is required, at the Radio, for a particular type of application, then a particular type of RAN may be authorized to the particular subscriber. A more granular authorization may indicate, for example, not just the type of RAN, but also the exact RAN. By way of example, a subscriber may be authorized to use only Wi-Fi hotspots at Starbucks or even a Starbucks on a particular street in a particular city. The authorization may be agreed upon between the ASP and MNO as part of a SLA and information configured in a SP or the authorization may be determined dynamically.

Alternatively, a PoA may indicate appropriately the granularity of MAC layer authorization and indications on the type of security required at the MAC layer (e.g. 802.11, 3GPP AKA protection mechanisms).

[0048] With respect to authorization at the physical (PHY) layer, similar to the above- described authorizations, a subscriber may be authorized to use a RAN in certain frequencies, time-slots or other PHY layer characteristics within a certain location, time-of-day and duration, etc. The PoA may indicate those granular radio-layer indications, which may include various security characteristics such as, for example, the requirement for physical layer security mechanisms (e.g., PHY layer message authentications).

[0049] Referring now to Fig. 4, a visual depiction of an example subscription profile (SP) structure 400 is shown. As shown, the SP structure 400 is partitioned into Basic Services 206, Gated Services 204, and negotiated or dynamic services 202 that can be defined by dynamic service negotiation. A subscription profile service definition or service profile 402 may also be included in the SP structure 400. In various embodiments, various elements of the SP 203 and the Service Profile data structure and organization may be considered by an Operator, with flexibility and evolution design goals in mind. For example, in some cases, the service profile data 402 may be decoupled from the data in the SP 203. In an example, the SP 203 may include, and thus may refer to, multiple service profiles. For example, a subset of service profiles may be attributed to a contract between the User and HN (e.g., permanent field in the subscription profile) that is and referenced in a catalog (e.g., catalog A described below). Another subset may be attributed to a dynamic negotiation with User/SN (e.g., temporary field in the subscription profile) and referenced in a catalog (e.g., catalog B described below). In some cases, the Subscription Profile 203 may specify if service negotiation is authorized. In an example, the Service Profile 402 may specify for which attributes negotiation is authorized. In some cases, an operator may maintain a catalog (Catalog A) of pre-defined Service Profiles created or generated during normal service creation or provisioning processes (OSS/BSS operations). For example, when a subscriber buys a new service from the HN 207, the operator may add a Service Profile reference from Catalog A to the SP 203. In another example, an operator may maintain another catalog (Catalog B) of Service Profiles that are populated or updated automatically during service negotiations for gated services 204 and dynamic services 202. In an example, when a subscriber negotiates a new variant configuration "V" of an existing service from Catalog A, the HN 207 creates an entry for "V" in Catalog B and adds a reference to "V" into the subscription data.

[0050] A given Service Profile may be uniquely identified and referred to by multiple Subscription Profiles. A Service Profile may be scoped geographically (e.g., country, PLMN ID) or in time. A Service Profile may refer to a parent Profile (template). For example, each Profile in Catalog B may be derived from one in Catalog A following a successful negotiation. In some cases, subscription profile data structures and service profile data structures may evolve independently from each other. For example, a given Service Profile may be specified in a rich language to express high service diversity and to accommodate future rapid evolution of those services. A given service profile may refer to multiple service flows. In an example, service profiles may be combined to allow for easy service composition.

[0051] In order to provide a capability to cater to the wide range of application layer services associated with 5G Systems, it is recognized herein that it may be necessary to break down an application layer service into a constituent set of basic characteristic network layer services. These basic network services may be further aligned with the network architecture and the underlying services offered by a network operator in terms of the QCI and security. With the move toward a network slice (NS) based 5G network architecture, the NS is intended to provide support for a subset of the full set of services anticipated for 5G systems. At a basic level, the NS services may be eMBB, mMTC, or URLL. However, in accordance with an example

embodiment, even these services may be dissected into a more granular service flow

architecture, whereby the service flows supported by an NS may be aligned to a class of service flows that are described by a QCI and security attributes. A Service Flow (SF) may be a MAC- layer protocol service that provides unidirectional transport of packets on the uplink or on the downlink. A single or combination of such service flows may be defined for a particular service to be offered by a network operator. By way of example, a texting application may map to an SMS service flow. A VoIP service may map to a VoIP service flow. A chat application may map to an SMS and VoIP service flow. Alternatively, in a format more aligned with different QoS classifications, the service flows (SFs) may be categorized into various classes, such as, for example and without limitation, a conversational class, a streaming class, an interactive class, and a background class in the case of alignment with legacy 4G and earlier service flows.

[0052] An example of the class of services and their representation from an

authorization perspective in an SP 500 is illustrated in Fig. 5. As shown, a line of separation or an association between a rich set of network services and resources required of the network, and the higher layer application layer services, may be provided. In the various illustrated rows, examples of application layer services are represented and classified as either Basic, Gated, or Negotiated, according to the authorization information associated with the corresponding constituent service flows that are represented in the various columns. For example, a texting application service may be classified as a Basic service that is pre-authorized in the SP. By way of further example, a Video Conference application layer service may be classified as a Gated service in the SP, if at least one of its constituent service flows (e.g., message texting, voice call, video feed) is disabled in the SP and requires supplementary authorization from the UN to enable. In some cases, the flexibility from authorizing a set of network layer service flows aligned with a particular set of QCI enables a flexible means of controlling network resources while enabling authorization for a rich set of application layer services. For example, authorized SMS, voice, and low rate video service flows in a SP may enable a SN to provide a rich set of application layer services using these constituent service flows without needing to seek authorization from a UN. It will be understood that examples of the richness of the SP based service authorization are provided for illustration, though application layer services and network layer service flows may be alternatively authorized, and those alternatives are contemplated as being within the scope of this disclosure.

[0053] Furthermore, the granular service flow definitions and characteristics may be directly mapped to a NS architecture, in particular to the specific services offered by a NS. Thus, in some cases, there can be a one-to-one correspondence between service flows and the delivery of such service(s) by a NS and the authorization thereof. The service flow characteristics may also be captured by way of unique Service Flow Identifiers (SFID), and these identifiers may be standardized and then used to describe a user's SP and the service authorizations. The SFID may define the QCI and Security parameters for the packets (PDUs) that are exchanged on the connection.

[0054] Referring generally to Fig. 4, in an example of basic service authorization, a UE 211 may request a service from the SN 209. Upon receipt of the service request by the SN 209, the UE's Subscription Profile (SP) 203 is inspected for the requested service, and if the service is enabled and part of the Basic Services 206, then the subscriber 205 may be automatically granted access to the service. In an example embodiment, if the UE SP 203 is inspected for the service and if the service is defined as a Gated Service 204, and if an SFID flag is not enabled for this service, then explicit authorization may be sought from the Home Network (FIN) 207 to request authorization and to enable the related flows. If the SFID is enabled, then as in the basic service case, the service may be granted directly by the SN 209.

[0055] In some cases, the UE SP may be inspected and, if it does not contain the appropriate authorization information for the requested service, a dynamic negotiation is performed to seek authorization for the requested service. Since the requested service might not be an exact match to the pre-authorized services as indicated within the UE's SP for basic and gated services, then an alignment of the services and appropriate authorization check(s) may be performed and negotiated between the SN and the HN.

[0056] An illustrative example of a service alignment between the SN and HN is now described. The HN may provide an application layer video conference service (e.g., named "MyVideoConferencePro") with the following constituent network layer services: Voice, Text Messaging, Video with qualities (480p, 720p), and confidentiality protection for all

communications by default. In the contrast, the SN may provide a slightly different application layer service. For example, the service the SN provides may have the video quality limited to 480p, and the confidentiality protection of communications may be limited to text and voice (e.g., application layer service named "MyVideoConference"). As an eample, the difference between the SN and HN here may be driven by a business requirement whereby, for example, the HN may cater more to business oriented users while the SN may be targeting consumers. Continuing with the example, when a user starts the video conferencing application, the UE sends a request to the SN for a "MyVideoConferencePro" application service (e.g., voice, text and video (720p) with confidentiality protection for all). Because the SN does not provide 720p video service flow or video confidentiality protection, the SN seeks to negotiate and obtain an authorization from the HN to offer an equivalent "MyVideoConference". Note that if

"MyVideoConference" was classified either as a Basic or Gated Service, in some cases, the SN may deny the service to the UE because what the SN can deliver is not an exact match of what is in the SP. Continuing with the example, upon the request from the SN, the HN may create in the UE SP a temporary entry "MyVideoConference" that is associated with the SN, and the HN may perform any dynamic authorization checks against the constituent service flows. By way of example, if the SFID for the video component is Gated (Restricted) while roaming, the HN may perform an additional check (e.g., against a cap for data roaming charges, location information) and enable the SFID (if authorized), and may send a response back to the SN, which may update the UE SP accordingly. The SN may further inform the user of the cost and the characteristics of the negotiated service and/or seek the user's consent. Thus, for example, in some cases, the user may accept or reject a lower quality video feed or lack of confidentiality protection. In an alternative embodiment, the SN may be capable of instantiating dynamically (and on the fly) a Network Slice that satisfies the MyVideoConferencePro application requirements. In that case, continuing with the example, the SN may only need to seek authorization from the HN for any restricted service flow (e.g., if 720p video flow is disabled and requires HN permission) without having to negotiate the service with the HN.

[0057] Dynamic authorizations, using Gated or Negotiated services in the SP, are now further described. Various new procedures or capabilities in 5G Systems are related to the dynamic authorizations described herein. For example, a subscriber may be allowed to access services dynamically, which are not enabled as part of the SP, in a SN, which are not initially enabled as part of the SP. For example, some optional service characteristics may be enabled based on user session context (Gated Service)) or to align SP to better match SN

offering/capabilities (e.g., instantiate a new service in SP based on existing subscribed services, user session context, SN capabilities (Negotiated Service)). In an example, a temporary subscription data field can be leveraged as a way to capture the dynamically authorized services (Gated or Negotiated). Furthermore, the various services dynamic authorization states for a given subscriber being centralized in the SP may leverage SP distribution procedures throughout the system (e.g., IDR/IDA etc.) and offer, for example, a consistent view of cached service authorization or local/fast service re-authorization optimization.

[0058] In an example embodiment, subscriber service negotiation (such as described above), which offers a full spectrum of flexibility for the Operator to cater to the wide range of application layer services expected for 5G Systems, may be enabled by the aforementioned dynamic authorization approach. In some cases, with respect to the client side, the

subscriber/UE may discover SN standard or tailored services. The Subscriber/UE may request HN tailored service from the SN. The Subscriber/UE may request enabling optional characteristics/features while requesting or using an HN service (while roaming or not). In an example, the Subscriber/UE may accept or reject a service offer. For example, Service

Negotiation functionality may be provided with an Operator Provisioned Policy on the UE.

[0059] With respect to the server side, the SN may publish available services through broadcasted or directed messaging (e.g., NAS Attach Accept). The HN/SN may authorize or reject a UE tailored service request (e.g., Negotiated Service). The HN may authorize or reject a UE request to enable characteristics/features (e.g., Gated Service). The HN may update SP service information for authorization as part of handling a UE service request (e.g., Gated or Negotiated service) or following any network event (e.g., Mobility event causing a previously authorized feature to be unauthorized). The HN/SN may cache locally (outside SP) authorization information related to Gated or Negotiated services. In some cases, authorization may be handled by the HN for maximum control, or by the SN on behalf of the HN (e.g., performed with agreement/trust in place), or by SN independently (e.g., ad hoc relationship UE-SN).

[0060] With respect to Dynamic Authorizations and Subscriber Service Negotiation Protocols, in an example, the protocol may be defined between the UE and SN, or between the SN and HN. The protocol may be transported on top of UE service requesting procedures (aka session management procedure) and/or SP distribution procedures (e.g., IDR/IDA, etc.) in a synchronous or asynchronous fashion.

[0061] Example differences between Subscription Profile based service authorization as it is performed in the current EPS, and embodiments described herein are now discussed, using IMS services as an illustrative example. In Table 1, some fields are reproduced from 3GPP TS 23.008, V14.0.0, which are specifically relevant for this Service Authorization comparison.

Table 1 : Core Network Service Authorization for IMS services (excerpt from TS 23.008 Table 5.3)

M = mandatory means that this parameter is stored for all subscribers with subscription C = conditional means that the parameter is subject to some condition (e.g. subscribed to service).

T = temporary set and changed automatically by network functions

P = permanent can be set and modified only by the home operator

[0062] The example parameters from Table 1 are now described in further detail. The list of authorized visited network identifiers may indicate which visited networks, identified by their respective network identifiers, the UE is allowed to attach to when roaming. In some cases, static provisioning of authorized roaming operator partners by the home operator as part of a SP as it is carried out for IMS in existing EPS may put severe limits on the portability of a given service. In example embodiments described herein, visited networks may refer to networks to which the UE may attach, based on dynamically obtained or non-static criteria, such as an assessed trust metric or trust score for the network, to gain access to a service, and for static or dynamic authorization to a service or portion thereof (e.g., by applying operator policy rules). A Subscribed Media Profile Identifier may identify a set of session description parameters (SDP) that the IMS subscriber is authorized to request. In some examples, it identifies a Media Profile stored in the S-CSCF, which is the service layer function actually performing the authorization handling. For example, if the subscription does not allow for a video media component, then the S-CSCF may reject any service layer request for a video streaming session. For IMS the UE is able to access a service solely based on the subscription information captured by the SDP. It is not possible to offer additional SDPs as an optional component, as denoted by the P attribute in Table 1. In an example embodiment described herein, an SDP is a richer set of services than for IMS, and some of the SDPs may be provisioned as optional (e.g., attribute marked as T using Table 1 convention), allowing for dynamic authorization of the SDPs (e.g., allowing a HN to enable some or all SDPs while interacting with the UE and/or negotiating with a SN (e.g., Gated dynamic authorization). The concept of an optional characteristic for a service in the SP is not limited to network service flows (see description in previous section) but may be extended to application or service layer components, such as SDP for IMS services, or any other layer such as described herein. As now described, the services using these SDPs may also be dynamically deleted or modified.

[0063] For example, the List of Subscribed Communication Service Identifiers may refer to the list of IMS communication services that the subscriber is authorized to use. Similar to the SDP description, the communications services a UE are statically defined. In example embodiments described herein, a communications service may be statically provisioned as well as dynamically provisioned, allowing for dynamic authorization (e.g., Gated). Also proposed herein is the ability to dynamically insert a new service, which may be customized, in the list of subscribed services as part of a service negotiation process (e.g., Negotiated). Services also may be dynamically deleted or modified.

[0064] Referring now to Fig. 6, an example embodiment of a Dynamic Authorization performed by a home network operator is shown. At 0, in accordance with the illustrated example, an NG-UE 602 is authenticated and registered with the network (SN or FIN). At 1, the NG-UE 602 sends a Service Request message to the network. The request is of dynamic nature and is performed on-demand, when an application on the NG-UE 602 has been launched and requests for a service / slice(s). The temp ID, TMSI, may have been obtained in the prior Attach Accept message from the SN and may be used to route the NG-UE to the proper functionality within the Common Core Network Function (CCNF) during subsequent access. The NG-UE may have also received an Accepted NSSAI in that same message. The Accepted Network Slice Selection Assistance Information (NSSAI) is a collection of Single NSSAI (S-NSSAI) or Session Management NSSAI (SM-NSSAI) accessible by the UE on the SN, from which the UE selects an appropriate SM-NSSAI, which may be used by the network to route the service request to the appropriate slice/ Session Management Function (SMF).

[0065] At 2, in accordance with the illustrated example, a Access and Mobility

Management Function (AMF / SCMF) 604, upon receiving the Service Access Request message, makes a determination that the NG-UE 602 has been authenticated. If the NG-UE 602 has not been authorized for the requested service / slice(s) then an authorization check is performed. In order to perform further authorization, the AMF / SCMF 604 may select an appropriate authorization function, such as a SMF (AuthF) 610, and obtain the SMF's address (IP address, URL etc.). If the AMF / SCMF 604 already has a valid and locally stored PoA associated with the NG-UE 602 for the requested service, in some cases, no further authorization is required and the message flow may proceed directly to Step 8 in accordance with the illustrated example. Security / service context information may be updated at Step 8 and Resource Allocation and Configuration may be carried out at Step 9 as required.

[0066] At 3, in accordance with the illustrated example, the AMF / SCMF 604 sends a Service Authorization Request message to the selected SMF-i (AuthF) 610. This message may contain the IMSI (e.g., SUPI) or temporary id (e.g., 5G-GUTI) of the NG-UE 602, the SM- NSSAI, and optional context information (e.g., time of day, location, security level). At 4, the SMF-i (AuthF) obtains the subscription profile associated with the NG-UE 602 from a Unified Data Management (UDM or ARPF / SIDB) 606. At 5, the SMF-i (AuthF) 610 retrieves relevant dynamic authorization policies associated with the requested service / slice(s) from a Policy Control Function (PCF or ACPF) 608.

[0067] At 6, in accordance with the illustrated example, the SMF-i 610, based on the dynamic authorization policies, subscription profile, and optional context information, determines service authorization for the NG-UE 602. At 7, in accordance with the illustrated embodiment, the SMF-i (AuthF) 610 sends a Service Authorization Response containing one or more PoAs to the AMF / SCMF 604. In case of a failed authorization, a failure code may be sent. At 8, the SMF-i (AuthF) 610 updates the appropriate Service / Security Context information associated with the NG-UE 602. Similarly, the AMF / SCMF 604 processes the PoA received from the SMF-i (AuthF) 610 and creates or updates the corresponding Service / Security Context information associated with the NG-UE. In an example case in which more than one PoA is received, and each PoA indicates the address (e.g., IP, URL, NAI) of the VNF indicated within an "audience" field (e.g., "aud" claim within the Json Web Token specification IETF RFC 7519/7797) value for a particular VNF functionality, then new PoAs may be generated by the AMF / SCMF 604. The new PoA may may explicitly indicate the identity of each of the VNFs that are required to realize that service. Also, PoAs for user plane functions (e.g., routing / switching functions) for which the authorizations for the NG-UE 602 may be granted are also generated. In certain cases, even if only a single PoA is received by the AMF / SCMF 604, then based on the received PoA, the AMF / SCMF may generate new PoAs that explicitly indicates the identity of the required VNFs and the scope of the PoAs to realize the service. For security reasons, in some cases, the PoAs that are generated are digitally signed by the issuer of the PoA using its private key. In the example case described herein, the AMF / SCMF 604 may sign the generated PoAs using its private key. In case of a failed authorization, in an example, no updates are performed to the Service / Security Context.

[0068] At 9, appropriate resource allocation and configurations are performed. The resource allocation may be based on the PoAs that were issued by the AMF 604 or by the SMF-I 610. This may involve both the control plane and the user plane resources associated with that service / slice(s). The appropriate EFs within the Access Network (AN) and User Plane Function "i" (UPF-i) may be configured to permit the NG-UE 602 to access the service / slice(s). In case of a failed authorization, in an example, no further resource allocation and configurations are performed. At 10, the AMF / SCMF 604 may send a Service Response message containing an authorization approval and the associated authorized service parameters to the NG-UE 602. Additionally, the AMF / SCMF 604 may send the PoAs to the NG-UE 602, which may be used by the NG-UE 602 for connectivity at a later point in time. At 11, the NG-UE 602 is provided with access to the service / slice(s).

[0069] Referring now to Fig. 7, an example embodiment for dynamic authorization performed by a Trusted Third Party (TTP) 714 is depicted. In accordance with the illustrated example, at 1, the NG-UE 702 sends a Service Authorization Request message to the Trusted Third Party (TTP) / AuthF 714. This message may contain the IMSI (e.g., SUPI), MSISDN, or a temp ID (e.g., 5G-GUTI) of the NG-UE 702, of the service that is being requested using SM- NSSAI parameter(s) and optional context information. The temp ID may have been obtained or generated by the NG-UE 702 during the Attach Accept message from SN, and may be used to route the NG-UE 702 to the proper CCNF 701 during subsequent access. The NG-UE 702 may have also received an Accepted NSSAI in that same message. The Accepted NSSAI is a collection of SM-NSSAI accessible by the UE on the SN, from which the UE selects an appropriate SM-NSSAI which may be used by the network to route the service request to the appropriate slice/SMF 710.

[0070] At 2, if the TTP (AuthF) 714 was not pre-provisioned with authorization policies, then the TTP 714 selects the appropriate function within the UN (e.g. PCF or NEF) and obtains the address (IP address, URL) of the PCF / NEF. At 3, in accordance with the illustrated example, the TTP (AuthF) 714 sends a message requesting authorization policies and subscription information to a SMF 710. The message contains the IMSI (e.g., SUPI), temp id (e.g., 5G-GUTI), or MSISDN of the NG-UE. The message may be forwarded to the SMF 710 from the TTP (AuthF) 714 via the NEF or the PCF. At 4, the SMF 710 may retrieve relevant dynamic authorization policies associated with the requested service / slice(s) from a PCF (ACPF) 708. At 5, the SMF 710 obtains the subscription profile associated with the NG-UE 702 from a UDM (ARPF / SIDB) 706. At 6, the SMF 710 sends the authorization policies and, in some cases only those applicable subscription information elements that are required for authorization to the TTP (AuthF) 714. At 7, if required in some examples, the TTP (AuthF) 714 performs authorization check(s) of the NG-UE 702 based upon policies and context information. This may entail one or more checks that may involve the NG-UE 702. At 8, if the authorization check(s) were passed by the NG-UE 702, for example, the TTP (AuthF) 714 generates one or more PoAs. A PoA may be in the form of an Access Token, for example. At 9, the TTP (AuthF) 714 sends a Service Authorization Response message containing the PoA to the NG-UE 702. In case of a failed authorization a failure code may be sent.

[0071] Still referring to Fig. 7, at 10, in accordance with the illustrated example, the NG-UE 702 sends a Service Request message to a network (AMF / SCMF) 704. The request may be of a dynamic nature and may be performed on-demand, when an application on the NG- UE 702 has been launched and requests for a service / slice(s), for example. The NG-UE 702 may send a Service Request message to the network (AMF / SCMF) 704 containing the previously issued PoA. At 11, the AMF / SCMF 704 may verify the authenticity (e.g., verify the digital signature of the issuer, or the TTP, using the TTP's public key), freshness and scope of the PoA. If the PoA is valid and matches the service requirements, then the AMF / SCMF 704 may extract appropriate information from the PoA and create or update an associated Service / Security Context for the NG-UE 702. Additionally, the AMF/SCMF 704 may generate PoAs that may be used to reserve resources at the VNFs (control plane functions) and routing / switching functions (user-plane functions) so that that the service can be realized. The PoAs generated by the AMF / SCMF 704 may be digitally signed by the AMF / SCMF 704 by using its private key. At 12, appropriate resource allocation and configurations may be performed at the network. This may involve both the control plane and the user plane resources associated with that service / slice(s). In some cases, the appropriate EFs within the AN and UPF-i are configured to permit the NG-UE 702 to access the service / slice(s). At 13, in accordance with the illustrated example, the AMF / SCMF 704 sends a Service Response message containing the authorization approval and associated parameters to the NG-UE 702. Optionally, the PoAs issued by the AMF 704 may also be sent to the NG-UE 702, such that the PoAs may be used by the NG-UE 702 to access the same service at any later point in time provided the PoAs have not expired. At 14, the NG-UE 702 may be provided with access to the service / slice(s).

[0072] In an example, still referring to Fig. 7, the service access phase (steps 10-14) may be subsequently performed multiple times after a successful completion of the authorization phase (steps 1-13) as long as the PoA is valid.

[0073] Referring now to Fig. 8, an example NextGen Networks reference architecture is shown with enhanced functions (shaded) to support dynamic authorization and services in a Home Routed (HR) scenario. This architecture may be deployed according to the concept of Network Slice (NS). The principle network slicing model that has been adopted by 3GPP SA2 group is called "Group B", where "Network Functions are common between the network slices, while other functions reside in its individual network slices." Typical common NFs are AMF, PCF, Authentication Server Function (AUSF), UDM, whereas other individual slice specific NFs are SMF, UPF (AN or Core Network). Another model called "Group C", where only UPFs reside in individual slices, may be considered a variation of Group B.

[0074] With respect to the example call flows described below, Group B is assumed, though it will be understood that an application to Group C can be applied as desired. A distinction between Group B and Group C is that in Group B, the AMF (being the single NAS entry point in the Core Network) first selects the slice where the SMF resides before forwarding to it a Session Management message, whereas in Group C, the AMF could route the message to SMF directly, as they belong to the same common slice. In the latter case, the individual (UP- only) slice selection might be done by either AMF or SMF. In some cases, AMF based slice selection may offer a more consistent messaging flow regardless of the deployment model chosen since it remains in the common slice either way.

[0075] In accordance with various example embodiments, a UDM may support Subscription Profiles (SP) that may specify a service with variable levels of authorization (e.g., Basic, Gated, Negotiated); support a SP that can be updated dynamically so that a service may be authorized or unauthorized dynamically (e.g., Gated Service); support a SP that can be updated dynamically so that a service may be instantiated/deleted dynamically (e.g., Negotiated Service); support procedures (over NG10 interface) to handle aforementioned dynamic authorization or service instantiation updates; and support procedures to update dynamic authorization or service instantiation states according to network events (e.g., mobility events via NG8). In an example, the UDM may process messages to store a new Negotiated Service upon a Service Request from a UE. In another example scenario, the UDM may turn on an optional service flow or feature of a Gated Service upon a Service Request from UE. In an example, the UDM may leverage the existing concept of Network Induced data to implement dynamic authorization or service instantiation updates described herein, whereby the Network Induced data may be kept separate in the UDM and "take precedence over the subscriber data of the user where they are in conflict," as described in 3GPP TS 23.008, V14.0.0. An example of Network Induced data from TS 23.008 is "Service restriction data induced by roaming" where an MME from an SN may inform the HSS than a service or feature is not supported so that HSS may restrict service to the UE while roaming in that area.

[0076] In various examples, the V-SMF may support static/implicit service

authorization procedure by straightforward SP inspection (e.g., Basic). In addition, the V-SMF may support Service Mapping to enable service alignment handling by the HN (H-SMF).

[0077] In various examples, the H-SMF may support authorization procedures for services with different level of authorization from static/implicit by straightforward SP inspection (Basic Service), to dynamic using real time contextual information about the service request besides SP information according to FIN policies i.e. Gated or Negotiated. The H-SMF may support Dynamic service alignment with Service Mapping assistance from the SN (V-SMF) according to HN policies; support procedures with UDM (via NGlO interface) for dynamic authorization or service instantiation updates; and support procedures with H-PCF (via NG7) for Dynamic Service Authorization or Negotiation policy request or policy decision delivery. In an example, the H-PCF support procedures with the H-SMF (via NG7) for Dynamic Service Authorization or Negotiation policy request or policy decision delivery. A given UE may support mapping of application transmission requirements to a service request that may be standard (e.g., such that both SN and HN can fully interpret) or PLMN specific (e.g., some portions of the service request, only the HN can interpret). In a UE, support of aforementioned mapping procedures may be enabled by an operator provisioned policy. [0078] Fig. 9 shows an example NextGen Networks reference architecture with enhanced functions (shaded) to support dynamic authorization and services in a Local Break Out (LBO) scenario. Example enhancements proposed for the shaded functions in Fig. 9, which are not already covered for the HR scenario above, include, for example and without limitation, an SMF that combines V-SMF and H-SMF functionalities while the H-PCF remains the policy decision point when it comes to Dynamic Service Authorization or Negotiation. In some cases, the SMF may support authorization procedures for services with different levels of authorization from, for example static/implicit by straightforward SP inspection (Basic Service), to dynamic using real time contextual information about the service request besides SP information according to UN policies (Gated or Negotiated). The SMF, in accordance with various embodiments, may support Service Mapping to enable service alignment handling according to HN policies; dynamic service alignment according to HN policies; procedures with UDM (via NG10 interface) for dynamic authorization or service instantiation updates; and procedures with V-PCF (via NG7) for Service Mapping or Negotiation policy request or policy delivery decision, where V-PCF receives those policies from the H-PCF. The H-PCF may support with the V-PCF (via NG7r) for Dynamic Service Authorization or Negotiation policy request or policy decision delivery. The V-PCF may support procedures with the H-PCF (via NG7r) for Dynamic Service Authorization or Negotiation HN policy request or HN policy decision delivery. Further, the V- PCF may support procedures with the SMF (via NG7) for Dynamic Service Authorization or Negotiation HN policy request or HN policy decision delivery.

[0079] Referring now to Fig. 10, an example of a Basic Service authorization by a Home Network (HN) 1000 delivered through a Visiting or Serving Network (SN) 1001 is depicted. In accordance with the illustrated example, at Subscriber (UE / User) 1002 is attached to the SN 1001. In the Attach Accept message from the SN 1002, the subscriber 1002 receives a temp ID for subsequent access and an Accepted NSSAI, which is a collection of SM-NSSAI accessible by the UE 1002 on the SN 1001. At 1, in accordance with the illustrated embodiment, the UE 1002 requests the SN 1001 for a new PDU Session to be established, providing the temp ID obtained during attach, a self-allocated Session Id to identify this new session, an SM-NSSAI which specifies the slice/service type the UE wishes to use, the PDU Session Type which may be IP or non IP (e.g. IPv4, Ethernet etc.), and the Domain Network Name (DNN) which identifies the Data Network (DN) the UE wants to communicate with. The request may be triggered by an application on the UE 1002 that needs transmitting data over the SN 1001. A local UE policy or Network Slice Selection Policy (NSSP), which may be provisioned by the HN operator, may be used by the UE to associate that application with a specific SM-NSSAI. The application may provide the DNN. In an example, the UE 1002 selects an existing PDU session using SM- NSSAI and DNN (if many available and application provides latter) to route application data, otherwise it may trigger a new PDU Session request. The request is routed to the appropriate AMF using the provided temp ID.

[0080] Upon receiving the request, at 2, an AMF 1004 accesses the SP, which may have been previously fetched from the FIN 1000 during attachment, to verify whether the UE 1002 is authorized to access the given Slice/Service type and to communicate with provided DNN (which may be extracted from SP if not provided by UE). At 3, in accordance with the illustrated example, the AMF 1004 uses an NSSF 1006 to select the proper slice/SMF for the UE 1002 in both SN 1001 and HN 1000 using SP, SM-NSSAI/DNN, and local operator policies. The AMF 1004 may also determine if LBO is allowed for this PDU Session for the given DNN based on the SP. At 4, the PDU Session request is then forwarded to a selected V-SMF 1008, adding to it a selected H-SMF 1012 address in the FIN and whether LBO is allowed or not. At 5, upon receiving the request, the V-SMF 1008 may allocate a UPF 1010. At 6, the PDU Session request may be forwarded to the H-SMF 1012 specifying the Downlink (DL) address of the UPF previously allocated. At 7, upon receiving the request, the H-SMF 1012 may fetch the SP, for example, from a UDM 1018. At 8, the H-SMF 1012 retrieves policy data for the requested service handling policies (e.g., QoS handling rules), for example, from a H-PCF 1016. At 9, in accordance with the example, the H-SMF 1012 detects that it is a request for a Basic Service (e.g., does not include any gated Service Flow or Feature such as an added security feature) and authorizes service delivery according to local operator policies (e.g., overload control). At 10, the H-SMF1012 may allocate a UPF resource and set it up with previously retrieved forwarding rules (e.g., QoS requirements, destination DN) as well as a V-SMF provided tunnel endpoint address (V-UPF DL address). At 11, the H-SMF 1012 may reply to the V-SMF 1008 with an accepted status, providing authorized QoS and Features and also the V-UPF Uplink (UL) address as the service tunnel endpoint address in the HN. At 12, in the example, the V-SMF 1008 completes the User Plane setup by allocating Radio resources via the AMF 1004 providing the H-UPF UL address as the service tunnel endpoint in the HN 1000. At 13, the V-SMF 1008 sets up the previously allocated V-UPF 1010 with both AN and HN tunnel end points addresses. At 14, the V-SMF 1008 replies to the UE via AMF with a positive response. The UE address may be allocated on the UP by DHCP signaling between UE and V-SMF via V-UPF. At 15, the UE may then transmit application data over SN/HN to a DN 1020. [0081] Referring to Fig. 11, an example Basic Service authorization and delivery by a SN 1101 is depicted. Steps 0, 1, and 2 are described above with reference to the example HR scenario. In accordance with the illustrated example, at 3, a AMF 1104 uses a NSSF 1106 to select the proper slice/SMF for the UE 1102 in the SN 1101 and HN 1100 using the SP, SM- NSSAI/DNN, and local operator policies. The AMF 1104 may determine that LBO is allowed for this PDU Session for the given DNN, based on the SP. At 4, the PDU Session request may then be forwarded to the selected V-SMF 1108, adding to it the selected H-SMF address in the HN 1100 and that LBO is allowed. In some cases, the H-SMF may be provided by the AMF 1104 even though LBO is allowed because, for example, the V-SMF 1108 may decide to create a HR PDU Session. For example, the HR PDU Session may be created if the V-SMF 1108 decides that it cannot handle the service delivery on its own, or in case some other messaging than PDU Session Request may need to be exchanged with H-SMF. At 5, upon receiving the request, the V-SMF 1008 fetches the SP from a UDM 1118. In some cases, if the V-SMF 1108 has access to the SP from a previous SN interaction with the HN 1100, then this step may be optional. At 6, in accordance with the illustrated example, the V-SMF 1108 retrieves policy data for the request service handling policies (e.g., QoS handling rules) from a V-PCF 1112. The V- PCF 1112 may request HN policies from a H-PCF 1116. HN policies may have been obtained from the H-PCF 1116 during some other prior event (e.g., UE Network attachment). At 7, in accordance with the illustrated example, the V-SMF 1108 detects that the service request is a request for a Basic Service (e.g., does not include any gated Service Flow or Feature such as added security features) and authorizes service delivery according to a combination of home (e.g., QoS handling rules) and local operator policies (e.g., overload control). At 8, the V-SMF 1108 may allocate a UPF resource. At 9, in accordance with the illustrated example, the V-SMF 1108 completes the User Plane setup by allocating Radio resources via the AMF 1104, providing the H-UPF UL address as the service tunnel endpoint in the HN 1100. At 10, the V-SMF 1110 may set up the previously allocated V-UPF 1110 with the AN tunnel end point address. At 11, the V-SMF 1108 may reply to the UE 1102 via the AMF 1104 with a positive response. The UE address may be allocated on the UP by DHCP signaling between the UE 1102 and the V-SMF 1108 via the V-UPF 1110. At 12, the UE may then transmit application data over the SN/HN to a DN 1114.

[0082] Referring to Fig. 12, an example Gated Service authorization by the Home Network (HN) 1000 delivered through a Visited or Serving Network (SN) 1001 is depicted. As shown, steps 0 through 8 are similar to the basic service HR scenario described above, except that the SM-NSSAI is for a Gated Service, and the request includes enabling optional characteristics or features (e.g., QoS level, security feature, etc.). At 9, in accordance with the illustrated example, the H-SMF 1012 detects that the service request for a Gated Service, which includes enabling optional characteristics or features. The H-SMF 1012 may authorize service delivery according to the SP and local operator policies (e.g., considering user location, time of request, UE capabilities, roaming agreements with SN, etc.). Authorization rules may be applied at 9 based on various subscription information, for example and without limitation, whether the user 1002 is allowed to access the gated QoS/features, capabilities of the UE, location of the UE, VLPMN ID, roaming agreements between the UE and the FIN 1000, time of day, or the like. At 10, the H-SMF 1012, in some cases, may enable the optional characteristics or features in the SP as Temporary data, providing a PDU Session Context for scoping the validity of those enabled characteristics. In some cases, this entry may serve as a cached entry in a subsequent PDU Session request for faster re-authorization (e.g., new service request after all the UP resources have been released due to UE going into IDLE mode). At 11, in accordance with the illustrated example, the H-SMF 1012 allocates the UPF resource 1014 and sets it up with previously retrieved forwarding rules (e.g., QoS requirements, destination DN) as well as a V- SMF provided tunnel endpoint address (V-UPF DL address). At 12, in accordance with the illustrated example, the H-SMF 1012 replies to the V-SMF 1008 with an accepted status, providing authorized QoS and Features and also the V-UPF Uplink (UL) address as the service tunnel endpoint address in the HN 1000. At 13, the V-SMF 1008 may complete the User Plane setup by allocating Radio resources via the AMF 1004, providing the H-UPF UL address as the service tunnel endpoint in the HN 1000. At 14, the V-SMF 1008 sets up the previously allocated V-UPF 1010 with both AN and HN tunnel end points addresses. At 15, in some cases, the V- SMF 1008 replies to the UE 1002 via the AMF 1004 with a positive response. The UE address may be allocated on the UP by DHCP signaling between the UE 1002 and the V-SMF 1008 via the V-UPF 1010. At 16, in accordance with the illustrated example, the UE 1002 may then transmit application data over the SN/HN to the DN 1020.

[0083] Referring now to Fig. 13, a Third-party issued authorization for a gated service in the SN 1001, which requires authorization from the HN 1000, is now described. The illustrated embodiment depicts an LBO scenario. In accordance with the illustrated example, at 0, the subscriber 1002 is attached to the SN 1001. In the Attach Accept message from the SN 1001, the subscriber 1002 may receive a temp ID for subsequent access and an Accepted NSSAI, which is a collection of SM-NSSAI accessible by the SUBSCRIBER on the SN 1001. At 1, in accordance with the illustrated example, the Subscriber 1002 requests the SN 1001 for a new PDU Session to be established, and may provide the temp ID obtained during attach, a self- allocated Session Id to identify this new session, an SM-NSSAI which specifies the slice/service type the Subscriber wishes to use, the PDU Session Type that may be IP or non IP (e.g. IPv4, Ethernet etc.), and the Domain Network Name (DNN) that identifies the Data Network (DN) 1020 the Subscriber 1002 wants to communicate with. The request may be triggered by an application on the UE that needs transmitting data over the SN 1001. A local UE policy or Network Slice Selection Policy (NSSP), which may be provisioned by the HN operator, may be used by the UE 1002 to associate that application with a specific SM-NSSAI. In some cases, the application may provide the DNN. The UE may select an existing PDU session using SM- NSSAI and DNN (e.g., if many available and application provides latter) to route application data, otherwise it may trigger a new PDU Session request. The request is routed to the appropriate AMF using the provided temp ID. The request may contain a digitally signed Access Token (AT) that was issued to the Subscriber by a Trusted Third-Party (TTP). The signed AT may be signed using the TTP's private key.

[0084] With continuing reference to Fig. 13, upon receiving the request, the AMF 1004 may inspect the AT, and also may access the SP that was previously fetched from the HN 1000 during attachment, to verify if the Subscriber 1002 is authorized to communicate with the provided DNN. In some cases, the AMF 1004 determines that the Subscriber 1002 has requested for a service that is classified as a "gated service," and also determines if there is a policy that states that for all "gated services" an authorization from the Subscriber's HN 1000 is required or not. If an authorization for gated service by the HN 1000 is not required, for example, then the SN 1001 may perform authorization on behalf of the HN 1000 on its own. At 3, the AMF 1004 may use the NSSF 1006 to select the proper slice/SMF for the Subscriber 1002 in the SN 1001 using the token information, SM-NSSAI/DNN, and local operator policies. The AMF 1004 may also determine if LBO is allowed for this PDU Session, for the given DNN, based on the SP. In the example scenario described here, LBO is permitted and therefore appropriate actions are taken. At 4, in accordance with the illustrated example, the PDU Session request is then forwarded to the selected V-SMF 1008, adding to it the selected H-SMF 1012 address in the HN 1000 and an indication that LBO is permitted. The AMF 1004 may optionally include the AT in the request message. The AMF 1004 may generate other ATs that may be used for resource reservation at the VNFs and UPFs, based on the authorization performed or based on the received AT from the UE. At 5, upon receiving the request, the V-SMF 1008 allocates a UPF 1010. At 6, the Authorization request may be forwarded to the H-SMF 1012. At 7, upon receiving the request, the H-SMF 1012 fetches the SP. At 8, the H-SMF 1012 retrieves policy data for the request service handling policies (e.g., Security / QoS handling rules).

[0085] Still referring to Fig. 13, at 9, the H-SMF 1012 may verify the AT and may determine that the requested service is a Gated Service. The H-SMF may authorize service delivery according to local operator policies (e.g., context info such as location, time, security level, etc.). By way of further example, authorization rules may consider various information in the SP, such as, for example, whether the user is allowed to access gated QCI/security features, UE capabilities, location of the UE, VPLMN ID, roaming agreements of the UE, time of day, etc. At 10, the H-SMF 1012 may update the SP and accounting / billing information upon the authorization of the gated service. The H-SMF 1012 may store the AT in a token database, which may be used for billing, forensics, etc. At 11, in accordance with the illustrated example, the H- SMF 1012 replies to the V-SMF 1008 with an accepted status. At 12, the V-SMF 1008 completes the User Plan setup by allocating Radio resources via the AMF 1004. The generated ATs may be used to allocate both control and user plane resources at various layers (e.g., Radio / PHY layer), for instance all the layers, of the network stack. At 13, the V-SMF 1008 sets up the previously allocated V-UPF 1010 with both AN and HN tunnel end point addresses. At 14, the V-SMF 1008 may reply to the Subscriber 1002 via the AMF 1004 with a positive response. The Subscriber address may be allocated on the UP by DHCP signaling between the Subscriber 1002 and the V-SMF 1008, via the V-UPF 1010. At 15, the Subscriber may then transmit application data over the SN 1001 to the DN 1020.

[0086] In an alternative embodiment, the UE may maintain a local copy of a subscription profile containing subscription profile information associated with the UE. This subscription profile information may correspond to a specific portion or the entirety of a subscription profile from the HN or an authorized TTP. The SP may be provisioned/updated by the HN through a TTP or a SN. In an example, the UE maintained subscription profile may consist of a dynamic service authorization matrix such as the one illustrated in Fig. 5 (e.g., application layer services vs. associated elementary network service flows) or a subset of service information. In some cases, a UE local policy coordination function may utilize the

authorization information from the local SP to determine whether to allow or deny an application from using a particular service flow. By way of example, the UE may bar an application (service flow level application barring) from initiating a PDU session request to the network if the associated service flow usage is not authorized. For example, a rich chat application may be authorized for service flows allowing text messaging or voice calls but not video conferencing. Thus, in some cases, an MNO can manage services efficiently and can manage network congestion conditions while still providing minimal service to the user, which provides fine grained control compared to solutions that may bar an entire application based on an arbitrary service class or identifier. The SP may be integrity and confidentiality protected. The UE may send the SP to a SN, for example, while registering with the SN or when requesting a new PDU session. In some cases, the UE may send the SP to the SN upon a request by the SN (e.g., NAS Configuration Update message). The SN may then use the UE provided SP as an input (implicit from the HN) to confirm that the UE is authorized to access a service.

[0087] A UE provided SP may enable an optimized service authorization path for the SN, which may obviate the need to request authorization from the HN for some types of services. The usage of a locally stored SP in the UE as illustrated herein is not limited to Gated services, and other combinations and solutions are contemplated as being within the scope of this disclosure. For example, Gated services may be authorized by way of the UE supplied SP, and Negotiated services or Home Routing, non-3GPP access, Local Breakout, subscription-less services, may also be pre-provisioned in the SP or may require HN authorization. The SP may be maintained and updated by the HN or SN. For example, when a service is authorized by the HN that was previously unauthorized, the UE may update the SP. And if a service flow is unauthorized, then the associated service flow may be disabled.

[0088] Referring now to Fig. 14, an example of a Negotiated Service authorization by the Home Network (HN) 1000 delivered through the Visited or Serving Network (SN) 1001 in a HR scenario is depicted. At 0, in accordance with the illustrated example, the UE 1002 is attached to the SN 1001. The UE may have a Configured NSSAI stored, which may contain one or more non-standard SM-NSSAI that are HN specific. In some cases, a configured NSSAI may be preferred over an Accepted NSSAI when selecting an SM-NSSAI because none may have been sent by the SN upon successful Attachment and/or because the UE may determine that an SM-NSSAI from the Configured NSSAI is a better fit for a particular application based on the applied NSSP. At 1, the UE 1002 requests the SN 1001 for a new PDU Session similar as for the example scenario depicted in Fig. 10, but using an SM-NSSAI from the Configured NSSAI. Based, for example, on roaming agreements between the HN 1000 and SN 1001, the NSSP on the UE 1002 may determine for the PLMN ID of that particular SN that a negotiated service may be authorized and delivered with a minimum QoS guaranteed, and therefore proceed with selecting an HN tailored SM-NSSAI from the Configured NSSAI. Step 2 may be similar to step 2 that is described with reference to Fig. 10, although there may be an additional operation to verify that the SP allows for negotiated services. Step 3 may be similar to step 3 that is described with reference to Fig. 10, although there may be an additional requirement that the non-standard SM-NSSAI in the request is be minimally understood by the AMF 1004 and the NSSF 1006. For example, the slice/service type may be known for routing the request to the proper SMF in SN/HN. The QoS specifications may be known for negotiating a possible SN SM-NSSAI match. In an example, step 4 is similar to step 4 that is described with reference to Fig. 10. At 5, in accordance with the illustrated example, upon receiving the request, the V-SMF 1008 determines that the provided SM-NSSAI is not standard or SN specific. In the process, it may look for a suitable match or closest equivalent that the SN 1001 fully supports (vSM-NSSAI). In an example, steps 6 and 8 are similar to steps 5 and 7, respectively, which are described with reference to Fig. 10. Step 7 may be similar to step 6 that is described with reference to Fig. 10, but with the additional parameter vSM-NSSAI. Step 9 may be similar to step 8 that is described with reference to Fig. 10, but with additional policy rules for Service Negotiation/SM-NSSAIs mapping.

[0089] Still referring to Fig. 14, in accordance with the illustrated example, at 10, the H-SMF 1012 verifies that a Negotiated Service is authorized for that SP (in particular for that PLMN ID, DNN). The H-SMF 1012 may use the SM-NSSAI as a hint from the UE 1002 to determine a corresponding subscribed service. The H-SMF 1012 may then perform a merging operation to produce a Negotiated Service using SM-NSSAI, vSM-NSSAI, SP, and local operator policies, such that QoS and/or security requirements can be fulfilled by the SN/HN within existing SP limits (e.g., aim for an optimal provisioning level for the requested PDU Session). In some cases, the resulting service may have some flows or features that are gated, in which case authorization rules for a gated service (e.g., see above) may be applied before delivery of the service. At 11, in accordance with the illustrated example, the H-SMF 1012 may store the resulting Service as Temporary data in the SP, providing a PDU Session Context for scoping the validity of that entry. This entry may serve as a cached entry in subsequent PDU Session request for faster re-authorization (e.g., new service request after all the UP resources have been released due to UE going into IDLE mode). Steps 12-17 may be similar to steps 10- 15, respectively, described above with reference to Fig. 10. In some cases, the cached entries may be purged at regular, predetermined time intervals.

[0090] In alternative example, still referring to Fig. 14, the flow may start with the UE 1002 discovering or being offered Services available in the SN 1001 that are tailored for that particular SN. Example differences in the request processing steps include, at 7, in some cases, the V-SMF 1008 may send only one vSM-NSSAI parameter to the H-SMF 1012. Further, at 10, in some cases, the H-SMF 1012 may proceed with a merge using all mentioned input but the "hint" SM-NSSAI to produce a resulting negotiated service.

[0091] Referring now to Fig. 15, an example of a Negotiated Service authorization by a Home Network (HN) delivered through a Serving Network (SN) in a LBO scenario is depicted. This flow is almost identical to the corresponding HR flow with some exceptions. For example, the User Plane setup is limited to the SN. Further, in accordance with the illustrated example, the V-SMF forwards session parameters for authorization via an Authorization Request, so the H-SMF performs the dynamic service alignment and authorization. An example of a service alignment and authorization procedure may be similar to the "MyVideoConference" scenario illustrated above. Alternatively, the V-SMF may perform the service alignment and authorization on behalf of the HN (instead of H-SMF) using HN policies (via V-PCF/H-PCF) and SP from UDM.

[0092] As described above, call flows for Gated/Negotiated services dynamic authorization show how the related procedures may lead to the real time update of an

authorization state in the SP (e.g., enable a feature, create a new service). It was mentioned that HN may choose services to authorize based on local policies that indicate the scope of the validity for such authorizations. The operator may have a policy in place that stipulates that the validity for a given service is based on various events, such as, for example mobility events (e.g., as long as UE is in a CONNECTED state, or under a given SN coverage area), time based events (e.g., for the next hour,) or some other operator chosen criteria (e.g., quota based, 1GB of data, etc.).

[0093] When a relevant event triggers the clearing of the authorization state in the SP, an update notification may be propagated by the UDM to inform the interested parties in the SN/HN (e.g., V/H-SMF) to terminate or update any active session and release any associated resources or update any local session context data. It is recognized herein that the level of granularity and dynamicity of authorization offered by various embodiments (e.g., Gated Services) may allow selective updates of an existing session according to what has just been unauthorized in the SP, such as tearing down only an optional flow or feature, without having to tear down the whole session. In an example use case, a video conference session that has started and is authorized for the full experience because the device is stationary as per an agreed SLA, can fall back automatically into audio-only when going mobile, which may trigger the network unauthorizing the video feed. Continuing with the example, when the video feed is

unauthorized, the user may be notified, thereby, providing a seamless and controlled service delivery experience.

[0094] It will be understood that the networks or systems illustrated in Figs. 6-15 are simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, the illustrated networks, and all such embodiments are contemplated as within the scope of the present disclosure.

[0095] Further, Figs. 1-15 and the description related thereto illustrate various embodiments of methods and apparatuses for service authorizations. In these figures, various steps or operations are shown being performed by one or more nodes, devices, functions, or networks. It is understood that the nodes, devices, functions, or networks illustrated in these figures may represent logical entities in a communication network and may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of, and executing on a processor of, a node of such network, which may comprise one of the general architectures illustrated in Figs. 16A and 16C-E described below. That is, the methods illustrated in Figs. 1-15 may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a network node or apparatus, such as for example the node or computer system illustrated in Fig. 16B, which computer executable instructions, when executed by a processor of the node, perform the steps illustrated in the figures. It is also understood that any transmitting and receiving steps illustrated in these figures may be performed by

communication circuitry of the node under control of the processor of the node and the computer-executable instructions (e.g., software) that it executes.

[0100] The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effect the methods described herein. As used herein, the terms "apparatus," "network apparatus," "node," "device," and "network node" may be used interchangeably.

[0096] FIG. 16A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications system 100 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.

[0097] As shown in FIG. 16A, the communications system 100 may include wireless transmit/receive units (WTRUs), e.g., 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, 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 may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include 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 netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0098] The communications system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the 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.

[0099] 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 114a and/or the base station 114b 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 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 some embodiments, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[00100] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d 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, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

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

[00102] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[00103] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c 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.

[00104] The base station 114b in FIG. 16A 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 some embodiments, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 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 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 16A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[00105] The RAN 103/104/105 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, subscription-less services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 16A, 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.

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

[00107] 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 may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 16A 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.

[00108] FIG. 16B is a system diagram of an example WTRU 102. As shown in FIG. 16B, the 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 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 subcombination 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 or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 16B and described herein.

[00109] 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 FIG. 16B 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.

[00110] 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 some embodiments, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another 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 another 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.

[00111] In addition, although the transmit/receive element 122 is depicted in FIG. 16B 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 some embodiments, 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.

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

[00113] 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 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 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 non-removable 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 other embodiments, 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).

[00114] 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 (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[00115] 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 implementation while remaining consistent with an embodiment.

[00116] 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 an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, 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.

[00117] FIG. 16C 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, 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 16C, 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.

[00118] As shown in FIG. 16C, 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 lub interface. The RNCs 142a, 142b may be in communication with one another via an lur 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, macrodiversity, security functions, data encryption, and the like.

[00119] The core network 106 shown in FIG. 16C 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.

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

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

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

[00123] FIG. 16D 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, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[00124] 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 some embodiments, 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.

[00125] Each of the eNode-Bs 160a, 160b, 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 (UL) and/or downlink (DL), and the like. As shown in FIG. 16D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface. [00126] The core network 107 shown in FIG. 16D 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.

[00127] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S I 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.

[00128] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 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.

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

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

[00131] FIG. 16E 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, 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.

[00132] As shown in FIG. 16E, 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 (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some embodiments, 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.

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

[00134] The communication link between each of the base stations 180a, 180b, 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.

[00135] As shown in FIG. 16E, 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.

[00136] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 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.

[00137] Although not shown in FIG. 16E, 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.

[00138] Mobile phones (e.g. UEs or WTRUs) have evolved from voice centric monochrome devices with a minuscule screens and little processing power to devices with high resolution, palm sized screens and data processing power rivaling laptop computers. This transformation, coupled with an expanding cache of bandwidth hungry applications, have triggered demands for higher data rates. Mobile data traffic reportedly grew more than 24-fold between 2010 and 2015 and may grow more than 500-fold between 2010 and 2020. This has, in turn, propelled the uptake of 4G network equipment contracts and driven operators worldwide to deploy 4G networks. 4G supports high data rates (e.g. up to 1 Gbit/s) on the downlink.

[00139] Attention is turning from 4G towards next generation (e.g., 5G) technologies. Use cases that may influence 5G system architecture may include Enhanced Mobile Broadband (eMBB) connectivity, Massive Machine Type Communications (mMTC) and Ultra-Reliable Critical Communications (URCC) services.

[00140] 5G may support higher data rates for uplink (UL) and downlink (DL). For example, uplink data throughput may be as high as or may exceed downlink data throughput. 5G may improve coverage and user experience, e.g., with higher data rate, lower latency and improved energy efficiency. IEEE 802.11 High Efficiency Wireless (HEW) may increase the presence of cellular operators, which may amalgamate different access technologies developed in different Standards Development Organizations (SDOs) to support future connectivity and data rates. 5G throughput and connectivity may be provided by multiple interconnected

communication standards, which may, for example, range from wireless metropolitan area networks down to wireless personal area networks and wired networks.

[00141] Massive connectivity may be driven by the variety of things or objects (e.g. RFID tags, sensors, actuators and mobile phones) in the environment around us, which may be referred to as the Internet of Things (IoT). Objects or devices may interact with each other in a variety of ways and may generate huge amounts of data. The IoT and the Internet have converged and may continue converging with a multitude and variety of service scenarios. 5G systems may connect loosely defined smart objects (e.g. M2M or IoT devices) and may enable them to interact with other objects, e.g., to yield productivity and automation gains through predictive, actionable intelligence. For example, mobile devices may adopt silent mode when entering a meeting room per a request of a meeting moderator (e.g. indicated in a policy), may alert a user to and/or turn off the radio on the user's mobile phone before entering sensitive medical areas or may detect when a user enters a car and automatically connect to its sound system. Wireless sensors may let people check where their pet is in real-time and may control the temperature for each room of their home while they are out. Emergency services may be remotely and automatically alerted, for example, when a fire is detected in a building or when a patient's medical parameters shift beyond a critical threshold.

[00142] 5G may provide increased service reliability for mission critical

communications services such as intelligent transportation systems. 5G systems may provide resiliency and reliability.

[00143] 5G wireless systems may improve data rates, efficiency and may enable new IoT services. 5G technologies may support traffic growth of 1000 times, for example, without a corresponding increase in CAPEX and OPEX costs. 5G system architecture may reduce costs for Mobile Operators or Service Providers. Cost reduction and flexibility for wireless networks may be achieved, for example, by reducing dependency on dedicated network functions and switching to generic COTS platforms, such as cloud computing utilizing virtualization technologies.

[00144] 5G systems may provide automation and remote interaction. There may be security and privacy issues associated with 5G networks.

[00145] 5G networks may be designed to connect industries, such as manufacturing and processing, intelligent transportation, smart grids and e-health. Different environments may cause issues for speed, latency and heterogeneity. Interaction by different platforms may mean different protocols, different interfaces and different policies (e.g. QoS requirements). Diverse service contexts may introduce various security and privacy considerations. For example, an e- health information system may have more privacy than a Home Automation System (HAS) that may have more security for Control Plane (CP) signaling. Network data handling capabilities may be improved to accommodate a large volume of data transported, stored and/or processed in 5G systems. Radio Network equipment that supports higher frequencies (e.g. Millimeter wave (mmW) 30GHz+) and core networks that store, forward and process data may be deployed, which may increase CAPEX and associated OPEX expenditures by mobile network service providers.