WO2020000145A1

WO2020000145A1 - World-switch as a way to schedule multiple isolated tasks within a VM

Info

Publication number: WO2020000145A1
Application number: PCT/CN2018/092690
Authority: WO
Inventors: Bing Zhu; Yang Huang; Kai Z. WANG; Yao Zu Dong; Wei A. DENG; Yadong QI; Ned Smith
Original assignee: Intel Corporation
Priority date: 2018-06-25
Filing date: 2018-06-25
Publication date: 2020-01-02
Also published as: WO2020005984A1

Abstract

Systems, apparatuses, methods, and computer-readable media associated with trusty OS virtualization and RPMB virtualization are disclosed herein. Other embodiments may be described and/or claimed.

Description

World-switch as a way to schedule multiple isolated tasks within a VM

BACKGROUND

Automotive automation and embedded control systems today use hundreds of discrete ECU (Embedded Control Unit) modules, each programmed to perform a specific function, to function as a coherent embedded control system. They communicate over a field bus (e.g. Controller Area Network (CAN) ) to coordinate distributed application goals. Unfortunately, this architecture doesn’t scale well across many vectors, safety, complexity, performance and security.

Some existing solutions use ECUs using hardware isolation of security and safety relevant operation from less critical functions within the ECU. Other architectures use dedicated ECUs to perform safety and security critical functions.

Still other solutions involve combining secure and non-secure ECU functionality in a single ECU based on ARM TrustZone that provide hardware separation of both application and operating system while still allowing a single application paradigm. The hypervisor may assign a physical TrustZone core to the virtual machine (VM) core and allow the operating system (OS) on the untrusted side to call into the TrustZone core –being careful to ensure the TrustZone core isn’t simultaneously assigned to a different untrusted core.

Consolidation and virtualization of ECUs using any one of a number general purpose application processor (such as

Core,

Atom or

Xeon) would be desirable. Security and safety are potentially important requirements that are at risk as a result of consolidation. However, not all general purpose application processors implement a similar technique like ARM TrustZone for some of the CPU skus aimed at this market segment.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 illustrates an example of Trusted OS Virtualization, in accordance with some embodiments.

Figure 2 illustrates an example of RPMB virtualization, in accordance with some embodiments.

Figure 3 illustrates an alternate embodiment where the number of guest VMs is less than the number of RPMB partition units, in accordance with some embodiments.

Figure XP1 illustrates an example multi-access edge framework in accordance with some embodiments.

Figure XP2 illustrates an example multi-access edge system architecture in accordance with some embodiments.

Figure XQ depicts an architecture of a system of a network in accordance with some embodiments.

Figure XR1 depicts an architecture of a system including a first core network in accordance with some embodiments.

Figure XR2 depicts an architecture of a system including a second core network in accordance with some embodiments.

Figure XS1 depicts an example of infrastructure equipment in accordance with various embodiments.

Figure XS2 depicts example components of a computer platform in accordance with various embodiments

Figure XT depicts example components of baseband circuitry and radio frequency circuitry in accordance with various embodiments.

Figure XU depicts example interfaces of baseband circuitry in accordance with some embodiments.

Figure XV is an illustration of a various protocol functions that may be used for various protocol stacks in accordance with various embodiments.

Figure XX illustrates components of a core network in accordance with various embodiments.

Figure XY is a block diagram illustrating components, according to some example embodiments, of a system to support NFV.

Figure XZ depicts a block diagram illustrating components, according to some exampleembodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologiesdiscussed herein.

Figure F1 illustrates an arrangement showing interconnections that may be present between the Internet and IoT networks, in accordance with various embodiments.

Figure F2 illustrates an example domain topology that may be used for a number of IoT networks coupled through backbone links to gateways, in accordance with various embodiments.

Figure F3 illustrates an arrangement F300 of example cloud computing network, or cloud, in communication with a number of Internet of Things (IoT) devices, in accordance with various embodiments.

Figure F4 illustrates an arrangement of a cloud computing network in communication with a mesh network of IoT devices, which may be termed a fog device, operating at the edge of the cloud, in accordance with various embodiments.

DETAILED DESCRIPTION

To address this challenge for these general purpose application processors, virtualization of the “trusted zone” is needed. One challenge requires co-resident operation of the “secure” world with the “unsecure” world while maintaining VM isolation from other virtual ECUs.

The present disclosure virtualizes the trusted and untrusted environments by bundling two operating systems and applications in a single VM. The hypervisor maintains separate memory page tables and assigns a different virtual CPU to each “world” . The hypervisor divides the VM execution quanta between the vCPUs giving each an opportunity to execute.

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail.

Figure 1–Shows an example world switch architecture in a general purpose processor (such as Intel X86) virtualization environment 100 where “User OS” 102 is a VM implementing a virtual ECU and where other VMs may contain other ECUs that require ECU-ECU separation. Within the VM a normal (untrusted or unsecured) world 104 is isolated from a trusted (secure) world 106 using hypervisor separation of memory pages where the normal (unsecure) world 104 may host a virtual kernel 108 and user environment 110 as well as hosting a “trusted” (secure) user/

kernel environment

112 and 114 using a different set of memory pages.

The hypervisor 116 includes a scheduler which does two-layer scheduling where the first layer schedules VM execution quanta and the second-level scheduler performs task switching between trusted (secure) and untrusted (unsecure) “worlds” by assigning a portion of the VM execution quanta to the first world. Any unused VM quanta is given to the second world. If the first world is blocked on the second world task, the first world immediately yields its execution time back to the hypervisor which assigns it to the second world. This repeats until the second world task completes.

As illustrated, for the embodiments, the hypervisor 116 provides different vCPU 118 with different contexts for normal (unsecure) world and trusted (secur) e world. Normal (unsecure or untrusted) world OS 104 and Trusty (secure) world OS 106 can trigger the world switch through hypercalls. Further, the hypervisor 116 maintain two extended page tables (EPT) for the different worlds. The trusted (secure) world memory is invisible for the normal (unsecure) world, but not vice versa.

In embodiments, for the “second-level scheduler, ” the normal (secure) world is event-driven. Whenever there is a request from the normal (unsecure) world, which sends a request to the hypervisor 116, the hypervisor 116 will schedule the context (and memory page tables) to the trusted (secure) world. Then the trusted (secure) world starts to execute its security task, and eventually, exits back to hypervisor 116 whenever either the secure task in the trusted (secure) world is completed, or there is a block event/like interrupt that doesn’t belong to the trusted (secure) world. After exiting to hypervisor, the hypervisor will schedule the context back to the normal (unsecure) world to continue to execution in the normal (unsecure) world. Since the trusted (secure) world is event-driven (or request-driven) , thus when there is no request from the normal (unsecure) world, the trusted (secure) world will not be scheduled.

In embodiments, the trusty OS may be the trusty OS released by Google for Android secure world. In embodiments, the hypervisor 116 may be the ACRN hypervisor, an open source project.

It is noted that the hypervisor 116 need not be restricted to supporting only VMs that implement trusted/untrusted worlds. It may support tradition “singleton” VM environments or it may support various container environments where a container may be one or more namespace and resource restricted application execution environments.

Figure 2 illustrates an example of Replay Protected Memory Block (RPMB) virtualization, according to some embodiments. Replay Protected Memory Block (RPMB) is a technology defined by NVMExpress ^TM organization and published in the NVM Express Base Specification Revision 1.3c, May 24, 2018. This specification is implemented in the embedded multi-media controller for non-volatile memory (eMMC NV) . RPMB partitions NV memory into blocks where RPMB blocks have additional security semantics beyond non-RPMB blocks. These semantics include NV locations that are replay protected meaning values written cannot be overwritten under normal conditions. They may be used to implement monotonic counters (MC) where a first value can be incremented but not decremented. Current RPMB specification doesn’t allow overflow of MC. If overflow occurs, then any write access request will be rejected. There is no software interface to allow software reset to this MC.

A challenge facing many architectures is the lack of an eMMC means application that run in a secure world (see figure 1) do not have access to RPMB functionality. The present disclosure virtualizes an eMMC such that a traditional NVMe storage device can be used in place of a physical eMMC. This is achieved by providing a hypervisor 210 to a virtualization environment 200, to host a Service VM or Service OS (SOS) 202 and a number of user VM or user OS 208. Service OS (SOS) 202 may beotherwise known as “VM#0, ” because it is the first VM instance created and may be co-resident with the hypervisor/virtual machine manager (VMM) image that is securely bootstrapped.

The hypervisor 210 is configured to partition an NVMe storage device 204 into a series of RPMB blocks (Blk#0, …Blk#n) 206 where each block 206 is assigned to an appropriate guest VM (also known as a “User OS” –UOS) 208. The SOS 202 maintains an array of Device Module structures 212 containing information associated with the NVMe block assignment (s) corresponding to a guest VM 208, including information to protect and maintain the security of the content of the RPBM blocks.

One of the challenges associated with virtualizing an RPMB is integrity and confidentiality protection of RPMB contents. The hypervisor 210 uses strong cryptography to encrypt RPMB blocks. Each block may be encrypted and bound to a particular guest VM 208. In embodiments, a different encryption key (eKey) is employed to encrypt the RPMB blocks assigned to a particular guest VM 208 (i.e. eKey#0 → RPMB of VM#0, eKey#1→RPMB of VM#1 etc…) . With this approach, even the SOS 202 cannot decrypt the data of the VMs 208.

Additionally, one VrKey (virtual RPMB key) is provided for each VM 208 and stored in the corresponding DM context 212 for use to authenticate communication between SOS 202 and Secure world of UOS 208, so that the Secure world of UOS thought it was talking to a physical RPMB device.

Further, a common rkey is used for authentication between the SOS 202 and the hypervisor 116 , which then in turn talks to physical RPMB controller in NVMe storage device 204 with a physical/real RPMB key. In alternate embodiments, the hypervisor 116 can be pass-through’ed, which means that the rKey can behave as the physical/real RPMB key, which then is directly used for authentication between the SOS 202 and the physical RPMB controller in NVMe storage device 204, thus the hypervisor 202 is bypassed in this embodiments.

In alternate embodiments, the same eKey may be used for each RPMB block that is under the supervision of the SOS VM 202. Each approach has different security, availability and performance trade-offs. Use of the eKey by the SOS 202 is authorized by the associated VM guest 208.

In some embodiments, the VrKey established for each VM, and store in the corresponding DM 212 context structure may also be used to authenticate and protect the communication channel between the SOS 202 the VM guest 208.

The hypervisor 210 may play a role in provisioning the VrKey by generating and provisioning the VrKey into memory pages corresponding to the VM guest 208 and the corresponding DM context 212. The SOS 202 is trusted to maintain the integrity of the DM context structures 212. If the VM Guest 208 implements “world” separation, the “trusted” world memory page is used to provision the VrKey and the world switch isolation mechanism helps ensure the untrusted world cannot obtain a copy of the VrKey. Consequently, the VrKey is inaccessible by the untrusted world except through an application programming interface (API) designed to control and restrict VrKey usage.

In some embodiments, an alternative approach may allow the RPMB block data to remain encrypted until it reaches the SOS 202 where the SOS driver applies the encryption/decryption operation.

In embodiments, the RPMB driver 214 in the kernel of the SOS 202 can implement read or write, monotonic counter and other RPMB defined NV functions in compliance with an eMMC expected behavior.

In embodiments, SOS 202 may operate a Linux kernel. UOS 208 may be user OS 102 of Figure 1. The hypervisor 210 may be hypervisor 116 of Figure 1.

In alternate embodiments, instead of having each DM context 212 having a copy of the rkey, an optional RPBM raw access module (216) may be provided to the kernel (as a companion to RPBM driver 212) to handle the rkey for all DM contexts 212, and interface between the DM contexts 212 and the hypervisor 116. Under these embodiments, the rkey is kept out of the user space of the service machine 202, which is likely to further increase security.

Figure 3 illustrates an alternate embodiment where the number of guest VMs is less than the number of RPMB partition units, in accordance with some embodiments. As shown, for the example virtualization environment 300, hypervisor 310 is hosting service machine 302 and two

example guest VMs

308a and 308b. NVMe storage device 204 include 4 RPBM partitions, more than the number of

guest VMs

308a and 308b being hosted. (Note than the number of 2 VMs and 4 RPBM partitions shown here are illustrative, and not to be read as limiting. In alternate embodiments, virtualization environment 300 may include any number of M VMs and N partitions, where M &N are integers with M < N. )

In these embodiments, In an alternate embodiment, when the number of guest VM (User OS) 308a-308b is less than or equal to the number of physical RPMB partitions or units 304a-304n, then each guest VM (User OS) 308a or 308b can have its own dedicated physical RPMB partitions/units 304a, 304b, …or 304n. Thus, for these embodiments, the dedicated physical rKeys (or RPMB key #1/#2 …) will be used for authentication between guest VM (User OS) 308a or 308b and physical storage devices 304. In this special embodiment, the SOS (Services OS) 302 doesn’t have to implement RPMB virtualization (described earlier with reference to Figure 2) . For data encryption, just like RPMB virtualization embodiment aforementioned, the per-guest eKey can be dedicated for each guest VM to ensure the data confidentiality protection. (Note that , unlike the RPMB virtualization of Figure 2, there is no need to split each

RPBM partition unit

303a, 303n …303n into “RPBM BLOCKS” ) .

Additionally, in some embodiments, a “Multiplex and filter services” module 320 may be provided to forward/filter RPMB data framse from User OS (UOS) 308a or 308b to the physical RPMB driver/device 320 (and back forth) . This may increase operational efficiency, since each virtual guest VM/

UserOS

308a and 308b doesn’t have directly physical RPMB device access.

In embodiments, the general purpose processor (such as Intel X86)

virtualization environment

100, 200, 300 of Figures 1-3 may be a virtualization environment in a client computing device, an edge computing device (near the edge of a network) , a fog networking device (to provide near end fog computing to client devices) , a hybrid edge/fog device, or a cloud server. In particular, an example client computing device may be an on-board computing device in a computer-assisted or autonomous driving vehicle. Further, the client, edge, fog networking or cloud computing device may be any one of such devices in the various computing systems and frameworks described with references to the remaining figures.

Edge Computing Systems and Frameworks

Edge computing comprises a collection of loosely coupled, voluntary, and/or human-operated resources such as desktops, laptops, nano data centers, tablets, etc. that are configured to operate in conjunction with one another to provide cloud computing functionality or otherwise share and/or distribute resources. The resources reside at the edge of a network and are within one to two-hop distance from the IoT devices and clients. Edge resources have varying ranges of computational capabilities from highly capable devices such as workstations, nano data centers etc. to less capable such as tablets, smartphones, IoT devices, or the like. Edge layer resources are sometimes assumed to have device-to-device (D2D) connectivity and may have somewhate more reliable connectivity to a Fog system (see e.g., Figures F1-F4 discussed infra) . As the resources in the edge cloud usually lie in one to two-hop proximity to the various devices and resources, processing data at the edge can significantly reduce network delay and increase computational efficiency.

Figure XP1 illustrates an example multi-access edge framework XP100 in accordance with some embodiments. The multi-access edge framework XP100 is an example structure of a multi-access edge computing (MEC) environment. MEC enables implementation of multi-access edge applications XP136 as software-only entities that run on top of a virtualization infrastructure XP138, which is located in or close to the network edge. The MEC framework XP100 shows the general entities involved, and these entities can be grouped into system level XP102, host level XP101, and network level XP103 entities.

The multi-access edge system level XP102 includes multi-access edge system level management XP202, UE XP01 (which may be the same or similar to the other UEs or terminals discussed herein) , and 3 ^rd Party entities XP10. The multi-access edge host level XP101 includes multi-access edge host level management XP201 and multi-access edge host XP135. The multi-access edge host XP135 includes the multi-access edge platform XP137, multi-access edge applications XP136, and virtualization infrastructure XP138. The network level XP103 includes various external network level entities, such as a 3GPP network XP140 (see e.g., Figures XQ, XR1, and XR2 infra) , a local network XP141, and an external network XP142. These entities are discussed in more detail with regard to Figure XP2.

Figure XP2 illustrates an example multi-access edge system architecture in accordance with some embodiments. The multi-access edge system XP200 of Figure XP2 includes a multi-access edge host level XP101 and a multi-access edge system level XP102. The multi-access edge host level XP101 may include multi-access edge hosts XP135 and multi-access edge management XP130, which provide functionality to run multi-access edge applications (ME apps) XP136 within an operator network or a subset of an operator network.

The multi-access edge system XP200 includes three groups of reference points, including “Mp” reference points regarding the multi-access edge platform functionality; “Mm” reference points, which are management reference points; and “Mx” reference points, which connect MEC entities to external entities. The interfaces/reference points in the multi-access edge system XP200 may include internet protocol (IP) based connections, and may be used to provide Representational State Transfer (REST or RESTful) services, and the messages conveyed using the reference points/interfaces may be in XML, HTML, JSON, or some other desired format. A suitable Authentication, Authorization, and Accounting (AAA) protocol, such as the radius or diameter protocols, may also be used for communicating over the reference points/interfaces in other embodiments.

The multi-access edge hostXP135 may be an entity that contains a multi-access edge platform XP137 and a virtualization infrastructure XP138 which provides compute, storage, and network resources, for the purpose of running ME apps XP136. The virtualization infrastructure XP138 includes a data plane XP138A that executes the traffic rules received by the multi-access edge platform, and routes the traffic among applications (e.g., ME apps XP136) , ME services XP137A, DNS server/proxy (see e.g., via DNS handling entity XP137C) , 3GPP network XP140 (e.g., as shown and described with regard to Figures XS and XR, infra) , local networks XP141, and external networks XP142.

The multi-access edge platform XP137 within the multi-access edge host XP135 may be a collection of essential functionality required to run ME apps XP136 on a particular virtualization infrastructure XP138 and enable them to provide and consume multi-access edge services XP137A. The multi-access edge platform XP137 can also provide various services and/or functions, such as offering an environment where the ME apps XP136 can discover, advertise, consume and offer multi-access edge services XP137A (discussed infra) , including multi-access edge services available via other platforms when supported. The multi-access edge platform XP137 may receive traffic rules from the multi-access edge platform manager XP131, applications, or services, and instruct the data plane accordingly (see e.g., Traffic Rules Control XP137B) . The multi-access edge platform XP137 may send instructions to the data plane XP138A within the virtualization infrastructure XP138 via the Mp2 reference point. The Mp2 reference point between the multi-access edge platform XP137 and the data plane XP138A of the virtualization infrastructure XP138 may be used to instruct the data plane XP138A on how to route traffic among applications, networks, services, etc. In some implementations, the multi-access edge platform XP137 may translate tokens representing UEs XP01 in the traffic rules into specific internet protocol (IP) addresses. The multi-access edge platform XP137 may also receive DNS records from the multi-access edge platform manager XP131 and configure a DNS proxy/server accordingly. The multi-access edge platform XP137 may host multi-access edge services XP137A including the multi-access edge services discussed infra, and provide access to persistent storage and time of day information. Furthermore, the multi-access edge platform may communicate with other multi-access edge platforms via the Mp3 reference point.

Multi-access edge applications (ME apps) XP136 are instantiated on the virtualization infrastructure XP138 of the multi-access edge host XP135 based on configuration or requests validated by the multi-access edge management XP130. ME apps XP136 may run as virtual machines (VM) on top of the virtualization infrastructure XP138 provided by the multi-access edge host XP135, and can interact with the multi-access edge platform XP137 to consume and provide multi-access edge services XP137A. In some embodiments, the ME apps XP136 can also interact with the multi-access edge platform XP137 to perform certain support procedures related to the lifecycle of the ME apps XP136, such as indicating availability, preparing relocation of user state, etc. The ME apps XP136 may have a certain number of rules and requirements associated to them, such as required resources, maximum latency, required or useful services, etc. These requirements may be validated by the multi-access edge system level management XP130, and can be assigned to default values if missing.

A multi-access edge service (ME service) XP137A is a service provided and consumed either by the multi-access edge platform XP137 or a multi-access edge application XP136. When provided by an application, it can be registered in the list of services XP137D to the multi-access edge platform XP137 over the Mp1 reference point. Additionally, the ME apps XP136 can subscribe to one or more services XP137A for which it is authorized over the Mp1 reference point.

As shown by Figure XP2, the Mp1 reference point is between the multi-access edge platform XP137 and the ME apps XP136. The Mp1 reference point may provide service registration XP137D, service discovery, and communication support for various services, such as the multi-access edge services XP137A. In addition, the Mp1 interface may provide application availability, session state relocation support procedures, traffic rules and DNS rules activation, access to persistent storage and time of day information, and/or the like. The Mp1 reference point may be used for consuming and providing service specific functionality.

Examples of ME services XP137A may include radio network information services, location services, and bandwidth management services. Radio network information services, when available, may provide authorized ME apps XP136 with radio network related information, and expose appropriate up-to-date radio network information to the ME apps XP136. The radio network information may include, inter alia, radio network conditions, measurement and statistics information related to the user plane, information (e.g., UE XP01 context and radio access bearers) related to UEs served by the radio node (s) associated with the multi-access edge host, changes on information related to UEs served by the radio node (s) associated with the multi-access edge host, and/or the like. The radio network information may be provided at the relevant granularity (e.g., per UE, per cell, per period of time) .

The location services, when available, may provide authorized ME apps XP136 with location-related information, and expose such information to the ME apps XP136. The location information may include, inter alia, the location of specific UEs currently served by the radio node (s) associated with the multi-access edge host, information about the location of all UEs currently served by the radio node (s) associated with the multi-access edge host, information about the location of a certain category of UEs currently served by the radio node (s) associated with the multi-access edge host, a list of UEs in a particular location, information about the location of all radio nodes currently associated with the multi-access edge host, and/or the like. The location information may be in the form of a geolocation, a Global Navigation Satellite Service (GNSS) coordinate, a Cell identity (ID) , and/or the like.

The bandwidth management services (BWMS) may allow allocation of bandwidth to certain traffic routed to and from ME apps XP136, and specify static/dynamic up/down bandwidth resources, including bandwidth size and bandwidth priority. ME apps XP136 may use the BWMS to update/receive bandwidth informationto/from the MEP XP137. In some embodiments, different ME apps XP136 running in parallel on the same multi-access edge host XP135 may be allocated specific static, dynamic up/down bandwidth resources, including bandwidth size and bandwidth priority. The BWMS may include a bandwidth management (BWM) API to allowed registered applications to statically and/or dynamically register for specific bandwidth allocations per session/application. The BWM API may include HTTP protocol bindings for BWM functionality using RESTful services or some other suitable API mechanism.

Example Implementations

Figure XQ illustrates an example architecture of a system XQ00 of a network is shown, in accordance with various embodiments. The following description is provided for an example system XQ00 that operates in conjunction with the as Long Term Evolution (LTE) system standards and the Fifth Generation (5G) or New Radio (NR) system standards as provided by 3rd Generation Partnership Project (3GPP) technical specifications (TS) . However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., Sixth Generation (6G) ) systems, Institute of Electrical and Electronics Engineers (IEEE) XS202.16 protocols (e.g., Wireless metropolitan area networks (MAN) , Worldwide Interoperability for Microwave Access (WiMAX) , etc. ) , or the like.

As shown by Figure XQ, the system XQ00 may include user equipment (UE) XQ01a and UE XQ01b (collectively referred to as “UEs XQ01” or “UE XQ01” ) . According to various embodiments, the UEs XQ01 may be any of the vUEs discussed previously. As used herein, the term “user equipment” or “UE” may refer to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface. In this example, UEs XQ01 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) , but may also comprise any mobile or non-mobile computing device, such as consumer electronics devices, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs) , pagers, wireless handsets, desktop computers, laptop computers, in-vehicle infotainment (IVI) , in-car entertainment (ICE) devices, an Instrument Cluster (IC) , head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME) , mobile data terminals (MDTs) , Electronic Engine Management System (EEMS) , electronic/engine control units (ECUs) , electronic/engine control modules (ECMs) , embedded systems, microcontrollers, control modules, engine management systems (EMS) , networked or “smart” appliances, machine-type communications (MTC) devices, machine-to-machine (M2M) , Internet of Things (IoT) devices, and/or the like.

In some embodiments, any of the UEs XQ01 can comprise an IoT UE, which may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as M2M or MTC for exchanging data with an MTC server or device via a public land mobile network (PLMN) , Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) , with short-lived connections. The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network.

The UEs XQ01 may be configured to connect, for example, communicatively couple, with a access network (AN) or radio access network (RAN) XQ10. In embodiments, the RAN XQ10 may be a next generation (NG) RAN or a 5G RAN, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) , or a legacy RAN, such as a UTRAN (UMTS Terrestrial Radio Access Network) or GERAN (GSM (Global System for Mobile Communications or Groupe Spécial Mobile) EDGE (GSM Evolution) Radio Access Network) . As used herein, the term “NG RAN” or the like may refer to a RAN XQ10 that operates in an NR or 5G system XQ00, and the term “E-UTRAN” or the like may refer to a RAN XQ10 that operates in an LTE or 4G system XQ00. The UEs XQ01 utilize connections (or channels) XQ03 and XQ04, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below) . As used herein, the term “channel” may refer to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radiofrequency carrier, ” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” may refer to a connection between two devices through a Radio Access Technology (RAT) for the purpose of transmitting and receiving information.

In this example, the connections XQ03 and XQ04 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and/or any of the other communications protocols discussed herein. In embodiments, the UEs XQ01 may directly exchange communication data via a ProSe interface XQ05. The ProSe interface XQ05 may alternatively be referred to as a sidelink (SL) interface XQ05 and may comprise one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Shared Channel (PSSCH) , a Physical Sidelink Discovery Channel (PSDCH) , and a Physical Sidelink Broadcast Channel (PSBCH) .

The UE XQ01b is shown to be configured to access an access point (AP) XQ06 (also referred to as also referred to as “WLAN node XQ06” , “WLAN XQ06” , “WLAN Termination XQ06” or “WT XQ06” or the like) via connection XQ07. The connection XQ07 can comprise a local wireless connection, such as a connection consistent with any IEEE XS202.11 protocol, wherein the AP XQ06 would comprise a wireless fidelity

router. In this example, the AP XQ06 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below) . In various embodiments, the UE XQ01b, RAN XQ10, and AP XQ06 may be configured to utilize LTE-WLAN aggregation (LWA) operation and/or WLAN LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP) operation. The LWA operation may involve the UE XQ01b in RRC_CONNECTED being configured by a RAN node XQ11 to utilize radio resources of LTE and WLAN. LWIP operation may involve the UE XQ01b using WLAN radio resources (e.g., connection XQ07) via Internet Protocol Security (IPsec) protocol tunneling to authenticate and encrypt packets (e.g., internet protocol (IP) packets) sent over the connection XQ07. IPsec tunneling may include encapsulating entirety of original IP packets and adding a new packet header thereby protecting the original header of the IP packets.

The RAN XQ10 can include one or more AN nodes or RAN nodes XQ11a and XQ11b (collectively referred to as “RAN nodes XQ11” or “RAN node XQ11” ) that enable the connections XQ03 and XQ04. As used herein, the terms “access node, ” “access point, ” or the like may describe equipment that provides the radio baseband functions for data and/or voice connectivity between a network and one or more users. These access nodes can be referred to as base stations (BS) , next Generation NodeBs (gNBs) , RAN nodes, evolved NodeBs (eNBs) , NodeBs, Road Side Units (RSUs) , Transmission Reception Points (TRxPs or TRPs) , and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . The term “Road Side Unit” or “RSU” may refer to any transportation infrastructure entity implemented in or by an gNB/eNB/RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU” , an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU. ” As used herein, the term “NG RAN node” or the like may refer to a RAN node XQ11 that operates in an NR or 5G system XQ00 (for example a gNB) , and the term “E-UTRAN node” or the like may refer to a RAN node XQ11 that operates in an LTE or 4G system XQ00 (e.g., an eNB) . According to various embodiments, the RAN nodes XQ11 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and/or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. In other embodiments, the RAN nodes XQ11 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a cloud radio access network (CRAN) . In other embodiments, the RAN nodes XQ11 may represent individual gNB-distributed units (DUs) that are connected to a gNB-centralized unit (CU) via an F1 interface (not shown by Figure XQ) .

Any of the RAN nodes XQ11 can terminate the air interface protocol and can be the first point of contact for the UEs XQ01. In some embodiments, any of the RAN nodes XQ11 can fulfill various logical functions for the RAN XQ10 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In embodiments, the UEs XQ01 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes XQ11 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency-Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications) , although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes XQ11 to the UEs XQ01, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs XQ01. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs XQ01 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE XQ01b within a cell) may be performed at any of the RAN nodes XQ11 based on channel quality information fed back from any of the UEs XQ01. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs XQ01.

The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs) . Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1, 2, 4, or 8) .

Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs) . Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs) . An ECCE may have other numbers of EREGs in some situations.

The RAN nodes XQ11 may be configured to communicate with one another via interface XQ12. In embodiments where the system XQ00 is an LTE system, the interface XQ12 may be an X2 interface XQ12. The X2 interface may be defined between two or more RAN nodes XQ11 (e.g., two or more eNBs and the like) that connect to EPC 120, and/or between two eNBs connecting to EPC 120. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C) . The X2-U may provide flow control mechanisms for user data packets transferred over the X2 interface, and may be used to communicate information about the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information for user data transferred from a master eNB (MeNB) to a secondary eNB (SeNB) ; information about successful in sequence delivery of PDCP PDUs to a UE XQ01 from an SeNB for user data; information of PDCP PDUs that were not delivered to a UE XQ01; information about a current minimum desired buffer size at the SeNB for transmitting to the UE user data; and the like. The X2-C may provide intra-LTE access mobility functionality, including context transfers from source to target eNBs, user plane transport control, etc.; load management functionality; as well as inter-cell interference coordinationfunctionality.

In embodiments where the system XQ00 is a 5G or NR system, the interface XQ12 may be an Xn interface XQ12. The Xn interface is defined between two or more RAN nodes XQ11 (e.g., two or more gNBs and the like) that connect to 5GC XQ20, between a RAN node XQ11 (e.g., a gNB) connecting to 5GC XQ20 and an eNB, and/or between two eNBs connecting to 5GC XQ20. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functionality. The Xn-C may provide management and error handling functionality, functionality to manage the Xn-C interface; mobility support for UE XQ01 in a connected mode (e.g., CM-CONNECTED) including functionality to manage the UE mobility for connected mode between one or more RAN nodes XQ11. The mobility support may include context transfer from an old (source) serving RAN node XQ11 to new (target) serving RAN node XQ11; and control of user plane tunnels between old (source) serving RAN node XQ11 to new (target) serving RAN node XQ11. A protocol stack of the Xn-U may include a transport network layer built on Internet Protocol (IP) transport layer, and a GTP-U layer on top of a UDP and/or IP layer (s) to carry user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as Xn Application Protocol (Xn-AP) ) and a transport network layer that is built on SCTP. The SCTP may be on top of an IP layer, and may provide the guaranteed delivery of application layer messages. In the transport IP layer point-to-point transmission is used to deliver the signaling PDUs. In other implementations, the Xn-U protocol stack and/or the Xn-C protocol stack may be same or similar to the user plane and/or control plane protocol stack (s) shown and described herein.

The RAN XQ10 is shown to be communicatively coupled to a core network -in this embodiment, Core Network (CN) XQ20. The CN XQ20 may comprise a plurality of network elements XQ22, which are configured to offer various data and telecommunications services to customers/subscribers (e.g., users of UEs XQ01) who are connected to the CN XQ20 via the RAN XQ10. The term “network element” may describe a physical or virtualized equipment used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, virtualized network function (VNF) , network functions virtualization infrastructure (NFVI) , and/or the like. The components of the CN XQ20 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) . In some embodiments, Network Functions Virtualization (NFV) may be utilized to virtualize any or all of the above described network node functions via executable instructions stored in one or more computer readable storage mediums (described in further detail below) . A logical instantiation of the CN XQ20 may be referred to as a network slice, and a logical instantiation of a portion of the CN XQ20 may be referred to as a network sub-slice. NFV architectures and infrastructures may be used to virtualize one or more network functions, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to execute virtual or reconfigurable implementations of one or more EPC components/functions.

Generally, the application server XQ30 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc. ) . The application server XQ30 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc. ) for the UEs XQ01 via the EPC XQ20.

In embodiments, the CN XQ20 may be a 5GC (referred to as “5GC XQ20” or the like) , and the RAN XQ10 may be connected with the CN XQ20 via an NG interface XQ13. In embodiments, the NG interface XQ13 may be split into two parts, an NG user plane (NG-U) interface XQ14, which carries traffic data between the RAN nodes XQ11 and a user plane function (UPF) , and the S1 control plane (NG-C) interface XQ15, which is a signaling interface between the RAN nodes XQ11 and Access and Mobility Functions (AMFs) . Embodiments where the CN XQ20 is a 5GC XQ20 are discussed in more detail with regard to Figure XR2.

In embodiments, the CN XQ20 may be a 5G CN (referred to as “5GC XQ20” or the like) , while in other embodiments, the CN XQ20 may be an Evolved Packet Core (EPC) ) . Where CN XQ20 is an EPC (referred to as “EPC XQ20” or the like) , the RAN XQ10 may be connected with the CN XQ20 via an S1 interface XQ13. In embodiments, the S1 interface XQ3 may be split into two parts, an S1 user plane (S1-U) interface XQ14, which carries traffic data between the RAN nodes XQ11 and the serving gateway (S-GW) , and the S1-mobility management entity (MME) interface XQ15, which is a signaling interface between the RAN nodes XQ11 and MMEs. An example architecture wherein the CN XQ20 is an EPC XQ20 is shown by Figure XR1.

Figure XR1 illustrates an example architecture of a system XR100 including a first CN XR120 is shown, in accordance with various embodiments. In this example, system XR100 may implement the LTE standard wherein the CN XR120 is an EPC XR120 that corresponds with CN XQ20 of Figure XQ. Additionally, the UE XR101 may be the same or similar as the UEs XQ01 of Figure XQ, and the EUTRAN XR110 may be a RAN that is the same or similar to the RAN XQ10 of Figure XQ, and which may include RAN nodes XQ11 discussed previously. The CN XR120 may comprise MMEs XR121, an S-GW XR122, a Packet Data Network (PDN) Gateway (P-GW) XR123, a home subscriber server (HSS) XR124, and a Serving General Packet Radio Service (GPRS) Support Nodes (SGSN) XR125.

The MMEs XR121 may be similar in function to the control plane of legacy SGSN, and may implement mobility management (MM) functions to keep track of the current location of a UE XR101. The MMEs XR121 may perform various MM procedures to manage mobility aspects in access such as gateway selection and tracking area list management. MM (also referred to as “EPS MM” or “EMM” in E-UTRAN systems) may refer to all applicable procedures, methods, data storage, etc. that are used to maintain knowledge about a present location of the UE XR101, provide user identity confidentiality, and/or other like services to users/subscribers. Each UE XR101 and the MME XR121 may include an MM or EMM sublayer, and an MM context may be established in the UE XR101 and the MME XR121 when an attach procedure is successfully completed. The MM context may be a data structure or database object that stores MM-related information of the UE XR101. The MMEs XR121 may be coupled with the HSS XR124 via an S6a reference point, coupled with the SGSN XR125 via an S3 reference point, and coupled with the S-GW XR122 via an S11 reference point.

The SGSN XR125 may be a node that serves the UE XR101 by tracking the location of an individual UE XR101 and performing security functions. In addition, the SGSN XR125 may perform Inter-EPC node signaling for mobility between 2G/3G and E-UTRAN 3GPP access networks; PDN and S-GW selection as specified by the MMEs XR121; handling of UE XR101 time zone functions as specified by the MMEs XR121; and MME selection for handovers to E-UTRAN 3GPP access network. The S3 reference point between the MMEs XR121 and the SGSN XR125 may enable user and bearer information exchange for inter-3GPP access network mobility in idle and/or active states.

The HSS XR124 may comprise a database for network users, including subscription-related information to support the network entities’handling of communication sessions. The EPC XR120 may comprise one or several HSSs XR124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS XR124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HHS XR124 and the MMEs XR121 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the EPC XR120 between HHS XR124 and the MMEs XR121.

The S-GW XR122 may terminate the S1 interface 513 ( “S1-U” in Figure XR1) towards the RAN XR110, and routes data packets between the RAN XR110 and the EPC XR120. In addition, the S-GWXR122 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement. The S11 reference point between the S-GW XR122 and the MMEs XR121 may provide a control plane between the MMEs XR121 and the S-GW XR122. The S-GW XR122 may be coupled with the P-GW XR123 via an S5 reference point.

The P-GW XR123 may terminate an SGi interface toward a Packet Data Network (PDN) XR130. The P-GW XR123 may route data packets between the EPC XR120 and external networks such as a network including the application server XQ30 (alternatively referred to as application function (AF) ) via an Internet Protocol (IP) interface XQ25 (see e.g., Figure XQ) . In embodiments, the P-GW XR123 may be communicatively coupled to an application server (application server XQ30 of Figure XQ or PDN XR130 in Figure XR1) via an IP communications interface 525 (see e.g., Figure XQ) . The S5 reference point between the P-GW XR123 and the S-GW XR122 may provide user plane tunneling and tunnel management between the P-GW XR123 and the S-GW XR122. The S5 reference point may also be used for S-GW XR122 relocation due to UE XR101 mobility and if the S-GW XR122 needs to connect to a non-collocated P-GW XR123 for the required PDN connectivity. The P-GW XR123 may further include a node for policy enforcement and charging data collection (e.g., Policy and Charging Enforcement Function (PCEF) (not shown) . Additionally, the SGi reference point between the P-GW XR123 and the packet data network (PDN) XR130 may be an operator external public, a private PDN, or an intra operator packet data network, for example, for provision of IMS services. The P-GW XR123 may be coupled with a PCRF XR126 via a Gx reference point.

Policy and Charging Enforcement Function (PCRF) XR126 is the policy and charging control element of the EPC XR120. In a non-roaming scenario, there may be a single PCRF XR126 in the Home Public Land Mobile Network (HPLMN) associated with an UE’s XR101 Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with an UE’s XR101 IP-CAN session, a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN) . The PCRF may be communicatively coupled to the application server XR130 via the P-GW XR123. The application server XR130 may signal the PCRF to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF XR126 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI) , which commences the QoS and charging as specified by the application server XR130. The Gx reference point between the PCRF XR126 and the P-GW XR123 may allow for the transfer of (QoS) policy and charging rules from the PCRF XR126 to Policy and Charging Enforcement Function (PCEF) in the P-GW XR123. An Rx reference point may reside between the PDN XR130 (or “AF XR130” ) and the PCRF XR126.

Although not shown, the EPS XR120 may also include a Service Capability Exposure Function (SCEF) that securely exposes the services and capabilities provided by 3GPP network interfaces to external entities. The SCEF is connected with a Services Capability Server (SCS) via a T8 reference point, wherein the SCS is connected to entities outside of the 3GPP network (e.g., application server XQ30) . The external entities and/or the SCS may access the SCEF via a suitable Application Programming Interface (API) and/or using the RADIUS/Diameter protocol (s) . The SCEF may support Common API Framework (CAPIF) and the CAPIF API provider domain functions. The SCEF is also connected to the MME XR121 via a T6a reference point and connected with the SGSN XR125 via a T6b reference point. Additionally, the SCEF is connected to the HSS XR124 via an S6t reference point, and connected with the PCRF XR126 via the Rx reference point and/or an Nt interface.

The SCEF provides a means for the discovery of the exposed services and capabilities. The SCEF abstracts the services from the underlying 3GPP network interfaces and protocols, and provides access to network capabilities through homogenous network APIs (e.g., Network APIs) defined over the T8 interface. Individual instances of SCEF may vary depending on the particular service capabilities that are exposed and the particular API features that are supported. The abstraction of services may involve hiding the underlying 3GPP network interfaces and protocols to allow full network integration. The supported may include, for example, underlying protocol connectivity, routing and traffic control; mapping specific APIs onto appropriate network interfaces; and protocol translation. In some implementations, abstraction is applied only in cases where required functionality is not natively provided by 3GPP network. When needed, the SCEF may support mapping between information exchanged with the SCS/AS (e.g., geographical identifiers) and information exchanged with internal PLMN functions.

The SCEF may also provide authorization and authentication functionality including identification of the API consumer, profile management, and access control list (ACL) management. The SCEF also allows the external entities to discover the exposed service capabilities, and manages and resolves issues related to external interconnection and point of contact.

The SCEF also provides policy enforcement functionality including enforcement of infrastructure policies (e.g., policies to protect platforms and network, such as ensuring that a service node such as SMS-SC is not overloaded) , business policies (e.g., policies related to the specific functionalities exposed. An example may be number portability, service routing, subscriber consent etc. ) , and application layer policies (e.g., policies that are primarily focused on message payload or throughput provided by an application. An example may be throttling) The SCEF also provides integration with O&M systems, assurance processes related to usage of APIs, and accounting for inter-operator settlements.

The services and capabilities offered by SCEF to SCS/AS include: Group Message Delivery; monitoring events; high latency communication; informing about potential network issues; resource management of background data transfer; E-UTRAN network resource optimizations based on communication patterns provided to the MME; support of setting up an AS session with required QoS; change the chargeable party at session set-up or during the session; non-IP Data Delivery; Packet Flow Description management; Enhanced Coverage restriction control; Network Parameter Configuration; and accessing MTC-IWF Functionality via the T8 reference point.

According to various embodiments, the SCEF exposes or otherwise provides event monitoring capabilities to subscribing entities or consumers (e.g., any of the devices or systems discussed herein) . The Monitoring Events feature makes monitoring events information available via the SCEF and comprises means that allow the identification of the 3GPP network element suitable for configuring the specific events, the event detection, and the event reporting to the authorized users (e.g., for use by applications or logging, etc. ) If such an event is detected, the network may be configured to perform special actions (e.g., limit the UE access) . Configuration and reporting of the following monitoring events may be supported: Monitoring the association of the UE and UICC and/or new IMSI-IMEI-SV association; UE reachability; UE location and UE location changes; loss of connectivity; communication failure; roaming status; number of UEs present in a geographical area; and availability after DDN failure.

Support for Monitoring Events can be offered either via the HSS XR124, MME XR121, SGSN XR125, or the PCRF XR126, which may be based on operator policies. For group based Monitoring Events, the SCS/AS (either the same SCS/AS or different SCSs/ASs) may configure a Monitor Event with different External Group Identifiers. In embodiments, when a Monitoring Event is detected by the MME XR121, SGSN XR125, and/or HSS XR124 at which the Monitoring Event is configured, the entity that detected the Monitoring Event sends a Monitoring Indication message to the SCEF. The Monitoring Indication message includes SCEF Reference ID (s) , Monitoring Event Report, and a User Identity (e.g., an External ID or MSISDN) . The External ID or MSISDN may be included if the indication is associated with an individual Group Member UE. Using the SCEF Reference ID, the SCEF retrieves the associated T8 Long Term Transaction Reference ID (TLTRI) along with the T8 Destination Address or, if not available, the address of the SCS/AS which sent the Monitoring Request as destination for the Monitoring Indication message. For each Monitoring Indication message sent to the SCS/AS (or received by the SCS/AS) , the SCS/AS sends a Monitoring Indication Response message to the SCEF. The Monitoring Response message includes a T8 Transaction Reference ID (TTRI) and a cause indicator or value. The cause value reflects successful or unsuccessful acknowledgement of the Monitoring Indication message.

The T8 Transaction Reference ID (TTRI) is a parameter which refers to transactions (e.g. Set Chargeable Party Request followed by Set Chargeable Party Response, NIDD Submit, etc. ) between the SCEF and the SCS/AS when using T8 interface. The transactions consist of one request message followed by one or more response messages. It is created by the originator of the transaction, and is unique through the duration of the transaction. It is stored on both the SCEF and the SCS/AS for the duration of the transaction.

The T8 Long Term Transaction Reference ID (TLTRI) is a parameter which refers to long term transaction (e.g. NIDD Configuration, Group Message Request, Monitoring Event configuration) between the SCEF and the SCS/AS when using T8 interface. Long term transactions consist of one or more request messages which may have one or more response messages i.e. one or more transactions represented by TTRI. It is created by the originator of the transaction, and is unique through the duration of the transaction. It is stored on both the SCEF and the SCS/AS for the duration of the transaction.

The T8 Destination Address is an optional parameter included by the SCS/AS to indicate that T8 messages from the SCEF (e.g. Monitoring Indication, or NIDD Submit Response) in response to an SCS/AS originated request (e.g. Monitoring Request, or NIDD Submit Request) are to be delivered to an address different from the address of the requesting SCS/AS. Absence of this parameter implies that the T8 messages from the SCEF are to be sent to the SCS/AS that originated the request.

Figure XR2 illustrates an architecture of a system XR200 including a second CN XR220 is shown in accordance with various embodiments. The system XR200 is shown to include a UE XR201, which may be the same or similar to the UEs XQ01 and UE XR101 discussed previously; a (R) AN XR210, which may be the same or similar to the RAN XQ10 and RAN XR110 discussed previously, and which may include RAN nodes XQ11 discussed previously; and a Data network (DN) XR203, which may be, for example, operator services, Internet access or 3rd party services; and a 5G Core Network (5GC or CN) XR220.

The 5GC XR220 may include an Authentication Server Function (AUSF) 222; an Access and Mobility Management Function (AMF) XR221; a Session Management Function (SMF) XR224; a Network Exposure Function (NEF) XR223; a Policy Control function (PCF) XR226; a Network Function (NF) Repository Function (NRF) XR225; a Unified Data Management (UDM) XR227; an Application Function (AF) XR228; a User Plane Function (UPF) XR202; and a Network Slice Selection Function (NSSF) XR229.

The UPF XR202 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to DN XR203, and a branching point to support multi-homed PDU session. The UPF XR202 may also perform packet routing and forwarding, packet inspection, enforce user plane part of policy rules, lawfully intercept packets (UP collection) ; traffic usage reporting, perform QoS handling for user plane (e.g. packet filtering, gating, UL/DL rate enforcement) , perform Uplink Traffic verification (e.g., SDF to QoS flow mapping) , transport level packet marking in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF XR202 may include an uplink classifier to support routing traffic flows to a data network. The DN XR203 may represent various network operator services, Internet access, or third party services. DN XR203 may include, or be similar to application server XQ30 discussed previously. The UPF XR202 may interact with the SMF XR224 via an N4 reference point between the SMF XR224 and the UPF XR202.

According to various embodiments, the 5GC XR220 also supports edge computing. Edge computing enables operator and 3rd party services to be hosted close to the UE's access point of attachment, so as to achieve an efficient service delivery through the reduced end-to-end latency and load on the transport network. In various embodiments, the 5GC XR220 selects a UPF XR202 close to the UE XR201 and executes traffic steering mechanisms to steer traffic from the UPF XR202 to the local DN XR203 via the N6 interface. This may be based on the UE XR201 subscription data, UE location, information from the AF XR228, policy, or other related traffic rules. Due to user or AF XR228 mobility, the service or session continuity may be required based on the requirements of the service or the 5G network. The 5GC XR220 may also expose network information and capabilities to an Edge Computing Application Function and/or other devices/systems discussed herein. Depending on operator deployment, certain AFs XR228 may interact directly with Control Plane NFs with which they need to interact, while the other AFs XR228 need to use the external exposure framework via the NEF XR223.

Edge computing can be supported by one or a combination of the following enablers: user plane (re) selection, wherein the 5GC XR220 (re) selects UPF XR202 to route the user traffic to the local DN XR203; Local Routing and Traffic Steering, wherein the 5GC XR220 selects the traffic to be routed to the applications in the local DN XR203 including the use of a single PDU Session with one or more PDU Session Anchors; session and service continuity to enable UE XR201 and application mobility; AF XR228 influence of UPF XR202 (re) selection and traffic routing via PCF XR226 or NEF XR223; network capability exposure, wherein the 5GC XR220 and AF XR228 provide information to each other directly or via the NEF XR223; QoS and Charging, wherein the PCF XR226 provides rules for QoS Control and Charging for the traffic routed to the local Data Network; and support of Local Area Data Network (LADN) , wherein the 5GC XR220 provides support to connect to the LADN in a certain area where the applications are deployed.

The AUSF XR222 may store data for authentication of UE XR201 and handle authentication related functionality. The AUSF XR222 may facilitate a common authentication framework for various access types. The AUSF XR222 may communicate with the AMF XR221 via an N12 reference point between the AMF XR221 and the AUSF XR222; and may communicate with the UDM XR227 via an N13 reference point between the UDM XR227 and the AUSF XR222. Additionally, the AUSF XR222 may exhibit an Nausf service-based interface.

The AMF XR221 may be responsible for registration management (e.g., for registering UE XR201, etc. ) , connection management, reachability management, mobility management, and lawful interception of AMF-related events, and access authentication and authorization. The AMF XR221 may be a termination point for the an N11 reference point between the AMF XR221 and the SMF XR224. The AMF XR221 may provide transport for Session Management (SM) messages between the UE XR201 and the SMF XR224, and act as a transparent proxy for routing SM messages. AMF XR221 may also provide transport for short message service (SMS) messages between UE XR201 and an SMS function (SMSF) (not shown by Figure XR2) . AMF XR221 may act as Security Anchor Function (SEA) , which may include interaction with the AUSF XR222 and the UE XR201, receipt of an intermediate key that was established as a result of the UE XR201 authentication process. Where USIM based authentication is used, the AMF XR221 may retrieve the security material from the AUSF XR222. AMF XR221 may also include a Security Context Management (SCM) function, which receives a key from the SEA that it uses to derive access-network specific keys. Furthermore, AMF XR221 may be a termination point of RAN CP interface, which may include or be an N2 reference point between the (R) AN XR211 and the AMF XR221; and the AMF XR221 may be a termination point of NAS (N1) signalling, and perform NAS ciphering and integrity protection.

AMF XR221 may also support NAS signalling with a UE XR201 over an N3 interworking-function (IWF) interface. The N3IWF may be used to provide access to untrusted entities. N3IWF may be a termination point for the N2 interface between the (R) AN XR210 and the AMF XR221 for the control plane, and may be a termination point for the N3 reference point between the (R) AN XR210 and the UPF XR202 for the user plane. As such, the AMF XR221 may handle N2 signalling from the SMF XR224 and the AMF XR221 for PDU sessions and QoS, encapsulate/de-encapsulate packets for IPSec and N3 tunnelling, mark N3 user-plane packets in the uplink, and enforce QoS corresponding to N3 packet marking taking into account QoS requirements associated to such marking received over N2. N3IWF may also relay uplink and downlink control-plane NAS signalling between the UE XR201 and AMF XR221 via an N1 reference point between the UE XR201 and the AMF XR221, and relay uplink and downlink user-plane packets between the UE XR201 and UPF XR202. The N3IWF also provides mechanisms for IPsec tunnel establishment with the UE XR201. The AMF XR221 may exhibit an Namf service-based interface, and may be a termination point for an N14 reference point between two AMFs XR221 and an N17 reference point between the AMF XR221 and a 5G-Equipment Identity Register (5G-EIR) (not shown by Figure XR2) .

The UE XR201 may need to register with the AMF XR221 in order to receive network services. Registration Management (RM) is used to register or deregister the UE XR201 with the network (e.g., AMF XR221) , and establish a UE context in the network (e.g., AMF XR221) . The UE XR201 may operate in an RM-REGISTERED state or an RM-DEREGISTERED state. In the RM-DEREGISTERED state, the UE XR201 is not registered with the network, and the UE context in AMF XR221 holds no valid location or routing information for the UE XR201 so the UE XR201 is not reachable by the AMF XR221. In the RM-REGISTERED state, the UE XR201 is registered with the network, and the UE context in AMF XR221 may hold a valid location or routing information for the UE XR201 so the UE XR201 is reachable by the AMF XR221. In the RM-REGISTERED state, the UE XR201 may perform mobility Registration Update procedures, perform periodic Registration Update procedure triggered by expiration of the periodic update timer (e.g., to notify the network that the UE XR201 is still active) , and perform a Registration Update procedure to update UE capability information or to re-negotiate protocol parameters with the network, among others.

The AMF XR221 may store one or more RM contexts for the UE XR201, where each RM context is associated with a specific access to the network. The RM context may be a data structure, database object, etc. that indicates or stores, inter alia, a registration state per access type and the periodic update timer. The AMF XR221 may also store a 5GC MM context that may be the same or similar to the (E) MM context discussed previously. In various embodiments, the AMF XR221 may store a CE mode B Restriction parameter of the UE XR201 in an associated MM context or RM context. The AMF XR221 may also derive the value, when needed, from the UE's usage setting parameter already stored in the UE context (and/or MM/RM Context) .

Connection Management (CM) may be used to establish and release a signaling connection between the UE XR201 and the AMF XR221 over the N1 interface. The signaling connection is used to enable NAS signaling exchange between the UE XR201 and the CN 120, and comprises both the AN signaling connection between the UE and the Access Network (AN) (e.g., RRC connection or UE-N3IWF connection for Non-3GPP access) and the N2 connection for the UE XR201 between the AN (e.g., RAN XR210) and the AMF XR221. The UE XR201 may operate in one of two CM states, CM-IDLE mode or CM-CONNECTED mode. When the UE XR201 is operating in the CM-IDLE state/mode, the UE XR201 may have no NAS signaling connection established with the AMF XR221 over the N1 interface, and there may be (R) AN XR210 signaling connection (e.g., N2 and/or N3 connections) for the UE XR201. When the UE XR201 is operating in the CM-CONNECTED state/mode, the UE XR201 may have an established NAS signaling connection with the AMF XR221 over the N1 interface, and there may be a (R) AN XR210 signaling connection (e.g., N2 and/or N3 connections) for the UE XR201. Establishment of an N2 connection between the (R) AN XR210 and the AMF XR221 may cause the UE XR201 to transition from CM-IDLE mode to CM-CONNECTED mode, and the UE XR201 may transition from the CM-CONNECTED mode to the CM-IDLE mode when N2 signaling between the (R) AN XR210 and the AMF XR221 is released.

The SMF XR224 may be responsible for Session Management (SM) (e.g., session establishment, modify and release, including tunnel maintain between UPF and AN node) ; UE IP address allocation &management (including optional Authorization) ; selection and control of UP function; Configures traffic steering at UPF to route traffic to proper destination; termination of interfaces towards Policy control functions; control part of policy enforcement and QoS; lawful intercept (for SM events and interface to LI System) ; termination of SM parts of NAS messages; downlink Data Notification; initiator of AN specific SM information, sent via AMF over N2 to AN; determine SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU Connectivity Service that provides or enables the exchange of PDUs between a UE XR201 and a data network (DN) XR203 identified by a Data Network Name (DNN) . PDU Sessions may be established upon UE XR201 request, modified upon UE XR201 and 5GC XR220 request, and released upon UE XR201 and 5GC XR220 request using NAS SM signaling exchanged over the N1 reference point between the UE XR201 and the SMF XR224. Upon request from an Application Server, the 5GC XR220 may trigger a specific application in the UE XR201. In response to receipt of the trigger message, the UE XR201 may pass the trigger message (or relevant parts/information of the trigger message) to one or more identified applications in the UE XR201. The identified application (s) in the UE XR201 may establish a PDU Session to a specific DNN. The SMF XR224 may check whether the UE XR201 requests are compliant with user subscription information associated with the UE XR201. In this regard, the SMF XR224 may retrieve and/or request to receive update notifications on SMF XR224 level subscription data from the UDM XR227.

The SMF XR224 may include the following roaming functionality: handle local enforcement to apply QoS SLAs (VPLMN) ; charging data collection and charging interface (VPLMN) ; lawful intercept (in VPLMN for SM events and interface to LI System) ; support for interaction with external DN for transport of signalling for PDU session authorization/authentication by external DN. An N16 reference point between two SMFs XR224 may be included in the system XR200, which may be between another SMF XR224 in a visited network and the SMF XR224 in the home network in roaming scenarios. Additionally, the SMF XR224 may exhibit the Nsmf service-based interface.

The NEF XR223 may provide means for securely exposing the services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, Application Functions (e.g., AF XR228) , edge computing or fog computing systems, etc. This is referred to as “Network Exposure. ” In such embodiments, the NEF XR223 may authenticate, authorize, and/or throttle the AFs. NEF XR223 may also translate information exchanged with the AF XR228 and information exchanged with internal network functions. For example, the NEF XR223 may translate between an AF-Service-Identifier and an internal 5GC information. NEF XR223 may also receive information from other network functions (NFs) based on exposed capabilities of other network functions. This information may be stored at the NEF XR223 as structured data, or at a data storage NF using a standardized interfaces. The stored information can then be re-exposed by the NEF XR223 to other NFs and AFs, and/or used for other purposes such as analytics. Additionally, the NEF XR223 may exhibit an Nnef service-based interface.

Network capability exposure comprises exposure of network events externally as well as internally towards network functions (NFs) of the 5GC XR220; exposure of provisioning capability towards external functions; exposure of policy and charging capabilities towards external functions; and exposure of core network internal capabilities for analytics.

When subscribing to event reporting the consumer NF (s) provide: one or more event ID(s) ; event filter information; event reporting information; a target of event reporting; and a notification target address. An event ID identifies the type of event being subscribed to (e.g. PDU Session release, UE mobility out of an Area of Interest, etc. ) . The event filter information provides Event Parameter Types and Event Parameter Value (s) to be matched against, in order to meet the condition for notifying the subscribed Event ID e.g. the Event Parameter Type could be "Area of interest"and Event Parameter Value list could be list of TAs. The Event Filter depends on the Event ID. The Event Filter Information is provided per Event ID (s) being subscribed to: within a subscription different Event ID (s) may be associated with different Event Filter Information.

Event Reporting Information is described in Table 4.15.1-1 below. Within a subscription, all Event ID (s) are associated with an unique Event Reporting Information. The target of event reporting: this may indicate a specific UE or PDU Session, a group of UE (s) or any UE (i.e. all UEs) , Within a subscription all Event ID (s) are associated with the same target of event reporting (possibly corresponding to multiple UE or multiple PDU Sessions) . The Notification Target Address (+ Notification Correlation ID) allowing it to correlate notifications received from the Event provider with this subscription. A subscription is associated with an unique Notification Target Address (+ Notification Correlation ID) .

When the subscription is accepted by the Event provider NF, the consumer NF receives from the event provider NF an identifier (Subscription Correlation ID) allowing to further manage (modify, delete) this subscription. The Notification Correlation ID is allocated by the consumer NF that subscribes to event reporting and the Subscription Correlation ID is allocated by the NF that notifies when the event is met. Both correlation identifiers can be assigned the same value, although in principle they are supposed to be different, as they are optimized for finding the subscription related context within each NF.

The consumer NF may use an operation dedicated to subscription modification to add or remove Event ID (s) to this subscription or to modify Event Filter Information. Events are subscribed by the consumer NF (s) by providing Event Filters. The content of the Event Reporting Information is described in Table 4.15.1-1.

Table 4.15.1-1: Event Reporting Information

While the Event Reporting Information is generally mandatory in a subscription request, not all information above is mandatory. Corresponding notifications contain at least the Notification Correlation ID together with the Event ID and the individual target (e.g. UE or PDU Session ID) associated with the notification.

The NEF XR 223 supports external exposure of capabilities of network functions. External exposure can be categorized as Monitoring capability, Provisioning capability, and Policy/Charging capability. The Monitoring capability is for monitoring of specific event for UE in 5GS and making such monitoring events information available for external exposure via the NEF. The Provisioning capability is for allowing external party to provision of information which can be used for the UE in 5GS. The Policy/Charging capability is for handling QoS and charging policy for the UE based on the request from external party. The Monitoring Events feature comprises means that allow NFs in the 5GS for configuring the specific events, the event detection, and the event reporting to the requested party. The set of capabilities required for monitoring are accessible via NEF XR223 to NFs in the 5GS. Monitoring Events may be configured via the UDM XR227 and the AMF XR221 enables the NEF XR223 to configure a given Monitor Event at the UDM XR227 or AMF XR221, and reporting of the event via the UDM XR227 and/or AMF XR221. Depending on the specific monitoring event or information, either the AMF XR221or the UDM XR227 that is aware of the monitoring event or information and makes it reported via the NEF. The table 4.15.3.1-1 shows the supported monitoring events.

Table 4.15.3.1-1: List of event for monitoring capability

In embodiments, the AMF service operations information procedure may operate as follows: First, the NEF XR223 sends a request to subscribe to one or a set of Event ID (s) to the AMF XR221 in an Namf_EventExposure_Subscribe request. The NEF XR223 could be the same NF subscribing to receive the event notification reports (e.g., Event Receiving NF) or the NEF XR223 could be a different NF. The NF expecting to receive events subscribes to one or several Event (s) (identified by Event ID. Event Reporting information defines the type of reporting requested. If the reporting event subscription is authorized by the AMF XR221, the AMF XR221 records the association of the event trigger and the requester identity. Second, the AMF XR221 acknowledges the execution of Namf_EventExposure_Subscribe. Third, the AMF XR221 detects the monitored event occurs and sends the event report by means of Namf_EventExposure_Notify message, to the Event Receiving NF which was subscribed to the event before.

In embodiments, the UDM service operations may operate as follows: First, the NEF XR223 subscribes to one or more monitoring events by sending an Nudm_EventExposure_Subscribe request to the UDM XR227. The Event Reporting Information defines the type of reporting requested. If the reporting event subscription is authorized by the UDM XR227, the UDM XR227 records the association of the event trigger and the requester identity. Second, the UDM XR227 sends an Namf_EventExposure subs request to a corresponding AMF XR221 for some events where it is required (e.g., loss of connectivity) , if any. In this case, the AMF XR221 acknowledges the execution of Namf_EventExposure_Subscribe by sending an Namf_EventExposure_Subscribe Response message to the UDM XR227. Third, UDM XR227 acknowledges the execution of Nudm_EventExposure_Subscribe by sending an Nudm_EventExposure_Subs Response message to the NEF XR223. Fourth, when the UDM XR227 detects occurrence of the monitored event, the UDM XR227 sends an event report, by means of Nudm_EventExposure_Notify message, to the requester NF which has subscribed to the event (e.g., the NEF XR223) . Depending on the event, the AMF XR221 may occurrence of the monitored event, and sends an event report by means of Namf_EventExposure_Notify message to the requester NF which has subscribed to the event (e.g., the NEF XR223) .

In embodiments, the NEF service operations information procedure may be as follows:

First, the requester (e.g., application server XQ30 or other like device/system) subscribes to one or several monitoring events by sending an Nnef_EventExposure_Subscribe reques to the NEF XR223. Event Reporting Information defines the type of reporting requested (e.g. one-time reporting, periodic reporting or event based reporting, for Monitoring Events) . If the reporting event subscription is authorized by the NEF XR223, the NEF XR223 records the association of the event trigger and the requester identity.

Second, the NEF XR223 subscribes to the received event (s) by sending an Nudm_EventExposure_Subscribe request to the UDM XR227. If the reporting event subscription is authorized by the UDM XR227, the UDM XR227/AMF XR221 records the association of the event trigger and the requester identity. Otherwise, the UDM XR227 indicates failure to the NEF XR223.

Third, if the requested event (e.g., monitoring of Loss of Connectivity) requires AMF XR221 assistance, then the UDM XR227 sends an Namf_EventExposure_Subscribe Request message to the AMF XR221 serving the requested user. The AMF XR221 acknowledges the execution of Namf_EventExposure_Subscribe by sending an Namf_EventExposure_Subscribe Response message to the UDM XR227.

Fourth, the UDM XR227 acknowledges the execution of Nudm_EventExposure_Subscribe by sending an Nudm_EventExposure_Subscribe Response message to the NEF XR223.

Fifth, the NEF XR223 acknowledges the execution of Nnef_EventExposure_Subscribe to the requester that initiated the request by sending an Nnef_EventExposure_Subscribe Response message to the requester.

Sixth, the UDM XR227 (depending on the Event) detects occurrence of the event and sends the event report, by means of Nudm_EventExposure_Notify message to the NEF XR223, which has subscribed to the event beforehand. Depending on the event, the AMF XR221 may detects occurrence of the event and sends an event report, by means of Namf_EventExposure_Notify message to the NEF XR223, which has subscribed to the event beforehand.

Seventh, the NEF XR223 forwards the reporting event received by either Nudm_EventExposure_Notify and/or the Namf_EventExposure_Notify to the requester.

The NRF XR225 may support service discovery functions, receive NF Discovery Requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF XR225 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate” , “instantiation” , and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF XR225 may exhibit the Nnrf service-based interface.

The PCF XR226 may provide policy rules to control plane function (s) to enforce them, and may also support unified policy framework to govern network behaviour. The PCF XR226 may also implement a front end (FE) to access subscription information relevant for policy decisions in a UDR of the UDM XR227. The PCF XR226 may communicate with the AMF XR221 via an N15 reference point between the PCF XR226 and the AMF XR221, which may include a PCF XR226 in a visited network and the AMF XR221 in case of roaming scenarios. The PCF XR226 may communicate with the AF XR228 via an N5 reference point between the PCF XR226 and the AF XR228; and with the SMF XR224 via an N7 reference point between the PCF XR226 and the SMF XR224. The system 200 and/or CN 120 may also include an N24 reference point between the PCF XR226 (in the home network) and a PCF XR226 in a visited network. Additionally, the PCF XR226 may exhibit an Npcf service-based interface.

The UDM XR227 may handle subscription-related information to support the network entities’handling of communication sessions, and may store subscription data of UE XR201. For example, subscription data may be communicated between the UDM XR227 and the AMF XR221 via an N8 reference point between the UDM XR227 and the AMF XR221 (not shown by Figure XR2) . The UDM XR227 may include two parts, an application FE and a User Data Repository (UDR) (the FE and UDR are not shown by Figure XR2) . The UDR may store subscription data and policy data for the UDM XR227 and the PCF XR226, and/or structured data for exposure and application data (including Packet Flow Descriptions (PFDs) for application detection, application request information for multiple UEs 201) for the NEF XR223. The Nudr service-based interfacemay be exhibited by the UDR 221 to allow the UDM XR227, PCF XR226, and NEF XR223 to access a particular set of the stored data, as well as to read, update (e.g., add, modify) , delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM FE, which is in charge of processing of credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing; user identification handling; access authorization; registration/mobility management; and subscription management. The UDR may interact with the SMF XR224 via an N10 reference point between the UDM XR227 and the SMF XR224. UDM XR227 may also support SMS management, wherein an SMS-FE implements the similar application logic as discussed previously. Additionally, the UDM XR227 may exhibit the Nudm service-based interface.

The AF XR228 may provide application influence on traffic routing, access to the Network Capability Exposure (NCE) , and interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC XR220 and AF XR228 to provide information to each other via NEF XR223, which may be used for edge computing implementations. In such implementations, the network operator and third party services may be hosted close to the UE XR201 access point of attachment to achieve an efficient service delivery through the reduced end-to-end latency and load on the transport network. For edge computing implementations, the 5GC may select a UPF XR202 close to the UE XR201 and execute traffic steering from the UPF XR202 to DN XR203 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF XR228. In this way, the AF XR228 may influence UPF (re) selection and traffic routing. Based on operator deployment, when AF XR228 is considered to be a trusted entity, the network operator may permit AF XR228 to interact directly with relevant NFs. Additionally, the AF XR228 may exhibit an Naf service-based interface.

The NSSF XR229 may select a set of network slice instances serving the UE XR201. The NSSF XR229 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and the mapping to the Subscribed Single-NSSAIs (S-NSSAIs) , if needed. The NSSF XR229 may also determine the AMF set to be used to serve the UE XR201, or a list of candidate AMF(s) 221 based on a suitable configuration and possibly by querying the NRF XR225. The selection of a set of network slice instances for the UE XR201 may be triggered by the AMF XR221 with which the UE XR201 is registered by interacting with the NSSF XR229, which may lead to a change of AMF XR221. The NSSF XR229 may interact with the AMF XR221 via an N22 reference point between AMF XR221 and NSSF XR229; and may communicate with another NSSF XR229 in a visited network via an N31 reference point (not shown by Figure XR2) . Additionally, the NSSF XR229 may exhibit an Nnssf service-based interface.

As discussed previously, the CN XR220 may include an SMSF, which may be responsible for SMS subscription checking and verification, and relaying SM messages to/from the UE XR201 to/from other entities, such as an SMS-GMSC/IWMSC/SMS-router. The SMS may also interact with AMF XR221 and UDM XR227 for notification procedure that the UE XR201 is available for SMS transfer (e.g., set a UE not reachable flag, and notifying UDM XR227 when UE XR201 is available for SMS) .

The CN XR220 may also include other elements that are not shown by Figure XR2, such as a Data Storage system/architecture, a 5G-Equipment Identity Register (5G-EIR) , a Security Edge Protection Proxy (SEPP) , and the like. The Data Storage system may include a Structured Data Storage network function (SDSF) , an Unstructured Data Storage network function (UDSF) , and/or the like. Any NF may store and retrieve unstructured data into/from the UDSF (e.g., UE contexts) , via N18 reference point between any NF and the UDSF (not shown by Figure XR2) . Individual NFs may share a UDSF for storing their respective unstructured data or individual NFs may each have their own UDSF located at or near the individual NFs. Additionally, the UDSF may exhibit an Nudsf service-based interface (not shown by Figure XR2) . The 5G-EIR may be an NF that checks the status of Permanent Equipment Identifiers (PEI) for determining whether particular equipment/entities are blacklisted from the network; and the SEPP may be a non-transparent proxy that performs topology hiding, message filtering, and policing on inter-PLMN control plane interfaces.

Additionally, there may be many more reference points and/or service-based interfaces between the NF services in the NFs; however, these interfaces and reference points have been omitted from Figure XR2 for clarity. In one example, the CN XR220 may include an Nx interface, which is an inter-CN interface between the MME (e.g., MME XR121) and the AMF XR221 in order to enable interworking between CN XR220 and CN XR120. Other example interfaces/reference points may include anN5g-eir service-based interface exhibited by a 5G-EIR, an N27 reference point between NRF in the visited network and the NRF in the home network; and an N31 reference point between the NSSF in the visited network and the NSSF in the home network.

Figure XS1 illustrates an example of infrastructure equipment XS100 in accordance with various embodiments. The infrastructure equipment XS100 (or “system XS100” ) may be implemented as a base station, radio head, RAN node, etc., such as the RAN nodes XQ11 and/or AP XQ06 shown and described previously. In other examples, the system XS100 could be implemented in or by a UE, application server (s) XQ30, and/or any other element/device discussed herein. The system XS100 may include one or more of application circuitry XS105, baseband circuitry XS110, one or more radio front end modules XS115, memory XS120, power management integrated circuitry (PMIC) XS125, power tee circuitry XS130, network controller XS135, network interface connector XS140, satellite positioning circuitry XS145, and user interface XS150. In some embodiments, the device XS100 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

As used herein, the term “circuitry” may refer to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) , an Application Specific Integrated Circuit (ASIC) , a field-programmable device (FPD) , (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structuredASIC, or a programmable System on Chip (SoC) ) , digital signal processors (DSPs) , etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. In addition, the term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

The terms “application circuitry” and/or “baseband circuitry” may be considered synonymous to, and may be referred to as “processor circuitry. ” As used herein, the term “processor circuitry” may refer to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations; recording, storing, and/or transferring digital data. The term “processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU) , a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes.

Furthermore, the various components of the core network XQ20 (or CN XR20 discussed infra) may be referred to as “network elements. ” The term “network element” may describe a physical or virtualized equipment used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, virtualized network function (VNF) , network functions virtualization infrastructure (NFVI) , and/or the like.

Application circuitry XS105 may include one or more central processing unit (CPU) cores and one or more of cache memory, low drop-out voltage regulators (LDOs) , interrupt controllers, serial interfaces such as SPI, I ²C or universal programmable serial interface module, real time clock (RTC) , timer-counters including interval and watchdog timers, general purpose input/output (I/O or IO) , memory card controllers such as Secure Digital (SD/) MultiMediaCard (MMC) or similar, Universal Serial Bus (USB) interfaces, Mobile Industry Processor Interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. As examples, the application circuitry XS105 may include one or more Intel

or

processor (s) ; Advanced Micro Devices (AMD)

processor (s) , Accelerated Processing Units (APUs) , or

processors; and/or the like. In some embodiments, the system XS100 may not utilize application circuitry XS105, and instead may include a special-purpose processor/controller to process IP data received from an EPC or 5GC, for example.

Additionally or alternatively, application circuitry XS105 may include circuitry such as, but not limited to, oneor more a field-programmable devices (FPDs) such as field-programmable gate arrays (FPGAs) and the like; programmable logic devices (PLDs) such as complex PLDs (CPLDs) , high-capacity PLDs (HCPLDs) , and the like; ASICs such as structured ASICs and the like; programmable SoCs (PSoCs) ; and the like. In such embodiments, the circuitry of application circuitry XS105 may comprise logic blocks or logic fabric including and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry of application circuitry XS105 may include memory cells (e.g., erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , flash memory, static memory (e.g., static random access memory (SRAM) , anti-fuses, etc. ) used to store logic blocks, logic fabric, data, etc. in lookup-tables (LUTs) and the like.

The baseband circuitry XS110 may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board or a multi-chip module containing two or more integrated circuits. Although not shown, baseband circuitry XS110 may comprise one or more digital baseband systems, which may be coupled via an interconnect subsystem to a CPU subsystem, an audio subsystem, and an interface subsystem. The digital baseband subsystems may also be coupled to a digital baseband interface and a mixed-signal baseband sub-system via another interconnect subsystem. Each of the interconnect subsystems may include a bus system, point-to-point connections, network-on-chip (NOC) structures, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio sub-system may include digital signal processing circuitry, buffer memory, program memory, speech processing accelerator circuitry, data converter circuitry such as analog-to-digital and digital-to-analog converter circuitry, analog circuitry including one or more of amplifiers and filters, and/or other like components. In an aspect of the present disclosure, baseband circuitry XS110 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for the digital baseband circuitry and/or radio frequency circuitry (e.g., the radio front end modules XS115) .

User interface circuitry XS150 may include one or more user interfaces designed to enable user interaction with the system XS100 or peripheral component interfaces designed to enable peripheral component interaction with the system XS100. User interfaces may include, but are not limited to one or more physical or virtual buttons (e.g., a reset button) , one or more indicators (e.g., light emitting diodes (LEDs) ) , a physical keyboard or keypad, a mouse, a touchpad, a touchscreen,speakers or other audio emitting devices, microphones, a printer, a scanner, a headset, a display screen or display device, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, etc.

The radio front end modules (RFEMs) XS115 may comprise a millimeter wave RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs) . In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFICs may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module XS115. The RFEMs XS115 may incorporate both millimeter wave antennas and sub-millimeter wave antennas.

The memory circuitry XS120 may include one or more of volatile memory including dynamic random access memory (DRAM) and/or synchronous dynamic random access memory (SDRAM) , and nonvolatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as Flash memory) , phase change random access memory (PRAM) , magnetoresistive random access memory (MRAM) , etc., and may incorporate the three-dimensional (3D) cross-point (XPOINT) memories from

and

Memory circuitry XS120 may be implemented as one or more of solder down packaged integrated circuits, socketed memory modules and plug-in memory cards.

The PMIC XS125 may include voltage regulators, surge protectors, power alarm detection circuitry, and one or more backup power sources such as a battery or capacitor. The power alarm detection circuitry may detect one or more of brown out (under-voltage) and surge (over-voltage) conditions. The power tee circuitry XS130 may provide for electrical power drawn from a network cable to provide both power supply and data connectivity to the infrastructure equipment XS100 using a single cable.

The network controller circuitry XS135 may provide connectivity to a network using a standard network interface protocol such as Ethernet, Ethernet over GRE Tunnels, Ethernet over Multiprotocol Label Switching (MPLS) , or some other suitable protocol. Network connectivity may be provided to/from the infrastructure equipment XS100 via network interface connector XS140 using a physical connection, which may be electrical (commonly referred to as a “copper interconnect” ) , optical, or wireless. The network controller circuitry XS135 may include one or more dedicated processors and/or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the network controller circuitry XS135 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

The positioning circuitry XS145, which may include circuitry to receive and decode signals transmitted by one or more navigation satellite constellations of a global navigation satellite system (GNSS) . Examples of navigation satellite constellations (or GNSS) may include United States’Global Positioning System (GPS) , Russia’s Global Navigation System (GLONASS) , the European Union’s Galileo system, China’s BeiDou Navigation Satellite System, a regional navigation system or GNSS augmentation system (e.g., Navigation with Indian Constellation (NAVIC) , Japan’s Quasi-Zenith Satellite System (QZSS) , France’s Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS) , etc. ) , or the like. The positioning circuitry XS145 may comprise various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate the communications over-the-air (OTA) communications)to communicate with components of a positioning network, such as navigation satellite constellation nodes.

Nodes or satellites of the navigation satellite constellation (s) ( “GNSS nodes” ) may provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight, which may be used by GNSS receivers (e.g., positioning circuitry XS145 and/or positioning circuitry implemented by UEs XQ01, XQ02, or the like) to determine their GNSS position. The GNSS signals may include a pseudorandom code (e.g., a sequence of ones and zeros) that is known to the GNSS receiver and a message that includes a time of transmission (ToT) of a code epoch (e.g., a defined point in the pseudorandom code sequence) and the GNSS node position at the ToT. The GNSS receivers may monitor/measure the GNSS signals transmitted/broadcasted by a plurality of GNSS nodes (e.g., four or more satellites) and solve various equations to determine a corresponding GNSS position (e.g., a spatial coordinate) . The GNSS receivers also implement clocks that are typically less stable and less precise than the atomic clocks of the GNSS nodes, and the GNSS receivers may use the measured GNSS signals to determine the GNSS receivers’deviation from true time (e.g., an offset of the GNSS receiver clock relative to the GNSS node time) . In some embodiments, the positioning circuitry XS145 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master timing clock to perform position tracking/estimation without GNSS assistance.

The GNSS receivers may measure the time of arrivals (ToAs) of the GNSS signals from the plurality of GNSS nodes according to its own clock. The GNSS receivers may determine ToF values for each received GNSS signal from the ToAs and the ToTs, and then may determine, from the ToFs, a three-dimensional (3D) position and clock deviation. The 3D position may then be converted into a latitude, longitude and altitude. The positioning circuitry XS145 may provide data to application circuitry XS105 which may include one or more of position data or time data. Application circuitry XS105 may use the time data to synchronize operations with other radio base stations (e.g., RAN nodes XQ11 or the like) .

The components shown by Figure XS1 may communicate with one another using interface circuitry. As used herein, the term “interface circuitry” may refer to, is part of, or includes circuitry providing for the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, input/output (I/O) interfaces, peripheral component interfaces, network interface cards, and/or the like. Any suitable bus technology may be used in various implementations, which may include any number of technologies, including industry standard architecture (ISA) , extended ISA (EISA) , peripheral component interconnect (PCI) , peripheral component interconnect extended (PCIx) , PCI express (PCIe) , or any number of other technologies. The bus may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I ²C interface, an SPI interface, point to point interfaces, and a power bus, among others.

Figure XS2 illustrates an example of a platform XS200 (or “device XS200” ) in accordance with various embodiments. In embodiments, the computer platform XS200 may be suitable for use as UEs XQ01, XQ02, XR01, application servers XQ30, and/or any other element/device discussed herein. The platform XS200 may include any combinations of the components shown in the example. The components of platform XS200 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the computer platform XS200, or as components otherwise incorporated within a chassis of a larger system. The block diagram of Figure XS2 is intended to show a high level view of components of the computer platform XS200. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

The platform XS200 includes processor circuitry XS202. The processor circuitry includes circuitry such as, but not limited to single-core or multi-core processors and one or more of cache memory, low drop-out voltage regulators (LDOs) , interrupt controllers, serial interfaces such as serial peripheral interface (SPI) , inter-integrated circuit (I2C) or universal programmable serial interface circuit, real time clock (RTC) , timer-counters including interval and watchdog timers, general purpose input-output (IO) , memory card controllers such as secure digital/multi-media card (SD/MMC) or similar, universal serial bus (USB) interfaces, mobile industry processor interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. The processor (s) of processor circuitry XS202 may include any combination of general-purpose processors and/or dedicated processors (e.g., graphics processors (GPUs) , application processors, etc. ) , which may be microprocessor (s) , multi-core processor (s) , multithreaded processor (s) , an ultra-low voltage processor (s) , embedded processor (s) , or other known processing element. The processors (or cores) of the processor circuitry XS202 may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the platform XS200.

As an example, the processor circuitry XS202 may include an

Architecture Core ^TM based processor, such as a Quark ^TM, an Atom ^TM, an i3, an i5, an i7, or an MCU-class processor, or another such processor available from

Corporation, Santa Clara, California. However, any number other processors may be used, such as one or more of Advanced Micro Devices (AMD)

processor (s) , Accelerated Processing Units (APUs) , MxGPUs, or the like; A5-A9 processor (s) from

Inc., Snapdragon ^TM processor (s) from

Technologies, Inc., Texas Instruments, Inc.

Open Multimedia Applications Platform (OMAP) ^TM processor (s) ; a MIPS-based design from MIPS Technologies, Inc; an ARM-based design licensed from ARM Holdings, Ltd.; or the like. In some implementations, the processor circuitry XS202 may be a part of a system on a chip (SoC) in which the processor circuitry XS202 and other components are formed into a single integrated circuit, or a single package, such as the Edison ^TM or Galileo ^TM SoC boards from

Corporation.

Additionally or alternatively, processor circuitry XS202 may include circuitry such as, but not limited to, one or more FPDs such as FPGAs and the like; PLDs such as CPLDs, HCPLDs, and the like; ASICs such as structured ASICs and the like; PSoCs; and the like. In such embodiments, the circuitry of processor circuitry XS202 may comprise logic blocks or logic fabric including and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry of processor circuitry XS202 may include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, anti-fuses, etc. ) used to store logic blocks, logic fabric, data, etc. in LUTs and the like.

The processor circuitry XS202 may communicate with a system memory circuitry XS204 over an interconnect XS206 (e.g., a bus) . Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory may be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) design such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4) . In various implementations, the individual memory devices may be of any number of different package types such as single die package (SDP) , dual die package (DDP) or quad die package (Q17P) . These devices, in some examples, may be directly soldered onto a motherboard to provide a lower profile solution, while in other examples the devices are configured as one or more memory modules that in turn couple to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different varieties including but not limited to microDIMMs or MiniDIMMs.

To provide for persistent storage of information such as data, applications, operating systems and so forth, a storage circuitry XS208 may also couple to the processor circuitry XS202 via the interconnect XS206. In an example, the storage circuitry XS208 may be implemented via a solid-state disk drive (SSDD) . Other devices that may be used for the storage circuitry XS208 include flash memory cards, such as SD cards, microSD cards, xD picture cards, and the like, and USB flash drives. In low power implementations, the storage circuitry XS208 may be on-die memory or registers associated with the processor circuitry XS202. However, in some examples, the storage circuitry XS208 may be implemented using a micro hard disk drive (HDD) . Further, any number of new technologies may be used for the storage circuitry XS208 in addition to, or instead of, the technologies described, such resistance change memories, phase change memories, holographic memories, or chemical memories, among others.

The memory circuitry XS204 and/or storage circuitry XS208 may store program code of an operating system (OS) , which may be a general purpose OS or an OS specifically written for and tailored to the computing platform XS200. The OSs may include one or more drivers that operate to control particular devices that are embedded in the platform XS200, attached to the platform XS200, or otherwise communicatively coupled with the platform XS200. The drivers may include individual drivers allowing other components of the platform XS200 to interact or control various input/output (I/O) devices that may be present within, or connected to, the platform XS200. For example, the drivers may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface of the platform XS200, sensor drivers to obtain sensor readings of sensor circuitry XS222 and control and allow access to sensor circuitry XS222, EMC drivers to obtain actuator positions of the EMCs XS222 and/or control and allow access to the EMCs XS222, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices. The OSs may also include one or more libraries, drivers, or APIs, which provide program code and/or software components for one or more applications to obtain and use the data from the secure execution environment (SEE) XS215 and/or the ME circuitry XS250. The SEE XS215, the ME circuitry XS250, or both the SEE XS215 and ME circuitry XS250 may be referred to as a trusted execution environment (TEE) and the like.

In this example, the storage circuitry XS208 is divided into one or more trusted memory regions XS217 for storing applications or software modules of the SEE XS215. In other embodiments, the trusted memory regions may be included in the memory circuitry XS204, or any combination of the memory circuitry XS204 and the storage circuitry XS208. The trusted memory regions are hardware enforceable containers called “enclaves, ” “secure enclaves, ” and the like. The enclaves XS217 are one or more isolated regions of the storage circuitry XS208 that are encrypted within the storage circuitry XS208, and only decrypted inside a secure region of the processor circuitry XS202. The secure enclaves XS217 may be used to store security critical code and/or data, such as secure applications (not shown) and/or an enclave OS (not shown) . The storage circuitry XS208 may be divided into multiple enclaves XS217, wherein each enclave may include its own applications and/or data. From a physical point of view, enclave data is resident within registers, caches, and/or other logic blocks inside the application circuitry or host architecture (e.g., processor circuitry XS202, memory circuitry XS204, storage circuitry XS208, etc. ) . Unauthorized access via untrusted software is prevented by processor logic. Whenever enclave data leaves the on-package caches to be written to memory circuitry XS204 and/or storage circuitry XS208, the data is automatically encrypted and integrity protected, which reduces the likelihood enclave data will be viewed, modified, or replayed. In some embodiments, the enclaves may be defined and managed by a virtual machine monitor (VMM) of a virtual machine running as a guest OS. Any suitable VMM may be used to define the secure enclaves. In various embodiments, the SEE XS215 may be one or more secure enclaves defined using the

SGX instructions. A detailed discussion of enclave establishment and operation (including communication between two or more enclaves, and between an enclave and remote devices) is discussed in the commonly assigned Int’l App. No. PCT/US2016/037634 and U.S. App. No. 15/473,370, both of which are incorporated by reference in their entireties. Other examples of the SEE XS215 may include, inter alia,

Secure Execution Environment,

virtual processor (s) ,

secure virtual machine,

Secure Execution Environment (QSEE) , TSEE provided by

Kinibi provided by

and/or the like. According to various embodiments, one or more enclaves XS217 may be used as the management controller 231 as shown and described with regard to Figure 2.

The storage circuitry XS208 may include instructions XS282 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions XS282 are shown as code blocks included in the memory circuitry XS204 and the storage circuitry XS208, it may be understood that any of the code blocks may be replaced with hardwired circuits, for example, built into an application specific integrated circuit (ASIC) .

In an example, the instructions XS282/870 provided via the memory circuitry XS204, the storage circuitry XS208, or the processor circuitry XS202 may be embodied as a non-transitory, machine-readable medium XS260 including code to direct the processor circuitry XS202 to perform electronic operations in the platform XS200. The processor circuitry XS202 may access the non-transitory machine-readable medium XS260 over the interconnect XS206. For instance, the non-transitory, machine-readable medium XS260 may be embodied by devices described for the storage circuitry XS208 of Figure XS2 or may include specific storage units such as optical disks, flash drives, or any number of other hardware devices. The non-transitory, machine-readable medium XS260 may include instructions XS282 to direct the processor circuitry XS202 to perform a specific sequence or flow of actions, for example, as described with respect to the flowchart (s) and block diagram (s) of operations and functionality depicted previously. In further examples, a machine-readable medium also includes any tangible medium that is capable of storing, encoding or carrying instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. A “machine-readable medium” thus may include, but is not limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., EPROM, EEPROM) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions embodied by a machine-readable medium may further be transmitted or received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP) .

The components may communicate over the interconnect XS206. The interconnect XS206 may include any number of technologies, including industry standard architecture (ISA) , extended ISA (EISA) , peripheral component interconnect (PCI) , peripheral component interconnect extended (PCIx) , PCI express (PCIe) , or any number of other technologies. The interconnect XS206 may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I ²C interface, an SPI interface, point-to-point interfaces, and a power bus, among others.

The interconnect XS206 couples the processor circuitry XS202 to a modem circuitry XS210 (also referred to as “baseband circuitry XS210” , “modem XS210” , and the like) for communications with other devices. The modem XS210 comprises one or more memory devices and one or more processors (e.g., baseband processors) used to perform various operations to communicate in accordance with one or more wireless communications protocols (e.g., where each processor is dedicated implement a particular protocol stack of a corresponding wireless protocol) , one or more audio digital signal processor (s) (DSP) including elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. The processors of the modem XS210 may be the same or similar to the processor circuitry XS202 discussed previously. In various embodiments, modem XS210 may interface with the application circuitry of the computing platform XS200 (e.g., processor circuitry XS202, memory circuitry XS204, and storage circuitry XS208) for generation and processing of the signals and for controlling operations of the transceivers XS211, XS212.

The modem XS210 may process signals received from receive signal paths of the transceivers XS211, XS212 and generate signals for transmit signal paths of the transceivers XS211, XS212. The modem XS210 may be used to handle various radio control functions that enable communication with one or more radio networks via the transceivers XS211, XS212 according to one or more particular wireless communications protocols. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequencyshifting, implementing protocol stacks, and the like. In some embodiments, modulation/demodulation by the modem XS210 may include Fast-Fourier Transform (FFT) , precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the modem XS210 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. The modem XS210 may pass demodulated signals obtained from the transceivers XS211, XS212 to other components of the computing platform XS200, and may pass modulated signals to the transceivers XS211, XS212 for transmission to other devices.

The transceiver XS211 (also referred to as a “mesh transceiver” and the like) is used for communications with other mesh devices XS264. The mesh transceiver XS211 may use any number of frequencies and protocols, such as 2.4 Gigahertz (GHz) transmissions under the IEEE XS202.15.4 standard, using the

low energy (BLE) standard, as defined by the

Special Interest Group, or the

standard, among others. Any number of radios, configured for a particular wireless communication protocol, may be used for the connections to the mesh devices XS264. For example, a WLAN unit may be used to implement Wi-Fi ^TM communications in accordance with the Institute of Electrical and Electronics Engineers (IEEE) XS202.11 standard. In addition, wireless wide area communications, for example, according to a cellular or other wireless wide area protocol, may occur via a WWAN unit.

The mesh transceiver XS211 may communicate using multiple standards or radios (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate the communications over the air) for communications at different range. For example, the platform XS200 may communicate with close devices, e.g., within about 10 meters, using a local transceiver based on BLE, or another low power radio, to save power. More distant mesh devices XS264, e.g., within about 50 meters, may be reached over ZigBee or other intermediate power radios. Both communications techniques may take place over a single radio at different power levels, or may take place over separate transceivers, for example, a local transceiver using BLE and a separate mesh transceiver using ZigBee.

A wireless network transceiver XS212 (also referred to as a “cloud transceiver” and the like) may be included to communicate with devices or services in the cloud XS201 via local or wide area network protocols. The wireless network transceiver XS212 includes one or more radios (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate the communications over the air) to communicate with devices in the cloud XS201. The cloud XS201 may be the same or similar to cloud F302 of Figures F3-F4. The wireless network transceiver XS212 may be a LPWA transceiver that follows the IEEE XS202.15.4, or IEEE XS202.15.4g standards, among others. The platform XS200 may communicate over a wide area using LoRaWAN ^TM (Long Range Wide Area Network) developed by Semtech and the LoRa Alliance. The techniques described herein are not limited to these technologies, but may be used with any number of other cloud transceivers that implement long range, low bandwidth communications, such as Sigfox, and other technologies. Further, other communications techniques, such as time-slotted channel hopping, described in the IEEE XS202.15.4e specification may be used.

Any number of other radio communications and protocols may be used in addition to the systems mentioned for the mesh transceiver XS211 and wireless network transceiver XS212, as described herein. For example, the radio transceivers XS211 and XS212 may include an LTE or other cellular transceiver that uses spread spectrum (SPA/SAS) communications for implementing high-speed communications. Further, any number of other protocols may be used, such as

networks for medium speed communications and provision of network communications.

The radio transceivers XS211 and XS212 may include radios that are compatible with, and/or may operate according to any one or more of the following radio communication technologies and/or standards including but not limited to: a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and/or a Third Generation Partnership Project (3GPP) radio communication technology, for example Universal Mobile Telecommunications System (UMTS) , Freedom of Multimedia Access (FOMA) , 3GPP Long Term Evolution (LTE) , 3GPP Long Term Evolution Advanced (LTE Advanced) , Code division multiple access 2000 (CDM2000) , Cellular Digital Packet Data (CDPD) , Mobitex, Third Generation (3G) , Circuit Switched Data (CSD) , High-Speed Circuit-Switched Data (HSCSD) , Universal Mobile Telecommunications System (Third Generation) (UMTS (3G) ) , Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS) ) , High Speed Packet Access (HSPA) , High-Speed Downlink Packet Access (HSDPA) , High-Speed Uplink Packet Access (HSUPA) , High Speed Packet Access Plus (HSPA+) , Universal Mobile Telecommunications System-Time-Division Duplex (UMTS-TDD) , Time Division-Code Division Multiple Access (TD-CDMA) , Time Division-Synchronous Code Division Multiple Access (TD-CDMA) , 3rd Generation Partnership Project Release 8 (Pre-4th Generation) (3GPP Rel. 8 (Pre-4G) ) , 3GPP Rel. 9 (3rd Generation Partnership Project Release 9) , 3GPP Rel. 10 (3rd Generation Partnership Project Release 10) , 3GPP Rel. 11 (3rd Generation Partnership Project Release 11) , 3GPP Rel. 12 (3rd Generation Partnership Project Release 12) , 3GPP Rel. 13 (3rd Generation Partnership Project Release 13) , 3GPP Rel. 14 (3rd Generation Partnership Project Release 14) , 3GPP Rel. 15 (3rd Generation Partnership Project Release 15) , 3GPP Rel. 16 (3rd Generation Partnership Project Release 16) , 3GPP Rel. 17 (3rd Generation Partnership Project Release 17) and subsequent Releases (such as Rel. 18, Rel. 19, etc. ) , 3GPP 5G, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed-Assisted Access (LAA) , MuLTEfire, UMTS Terrestrial Radio Access (UTRA) , Evolved UMTS Terrestrial Radio Access (E-UTRA) , Long Term Evolution Advanced (4th Generation) (LTE Advanced (4G) ) , cdmaOne (2G) , Code division multiple access 2000 (Third generation) (CDM2000 (3G) ) , Evolution-Data Optimized or Evolution-Data Only (EV-DO) , Advanced Mobile Phone System (1st Generation) (AMPS (1G) ) , Total Access Communication System/Extended Total Access Communication System (TACS/ETACS) , Digital AMPS (2nd Generation) (D-AMPS (2G) ) , Push-to-talk (PTT) , Mobile Telephone System (MTS) , Improved Mobile Telephone System (IMTS) , Advanced Mobile Telephone System (AMTS) , OLT (Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony) , MTD (Swedish abbreviation for Mobiltelefonisystem D, or Mobile telephony system D) , Public Automated Land Mobile (Autotel/PALM) , ARP (Finnish for Autoradiopuhelin, "car radio phone" ) , NMT (Nordic Mobile Telephony) , High capacity version of NTT (Nippon Telegraph and Telephone) (Hicap) , Cellular Digital Packet Data (CDPD) , Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN) , Personal Digital Cellular (PDC) , Circuit Switched Data (CSD) , Personal Handy-phone System (PHS) , Wideband Integrated Digital Enhanced Network (WiDEN) , iBurst, Unlicensed Mobile Access (UMA) , also referred to as also referred to as 3GPP Generic Access Network, or GAN standard) , Bluetooth (r) , Bluetooth Low Energy (BLE) , IEEE XS202.15.4 based protocols (e.g., IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) , WirelessHART, MiWi, Thread, IS100.11a, etc. ) WiFi-direct, ANT/ANT+, Z-Wave, 3GPP device-to-device (D2D) or Proximity Services (ProSe) , Universal Plug and Play (UPnP) , Low-Power Wide-Area-Network (LPWAN) , Long Range Wide Area Network (LoRA) or LoRaWAN ^TM developed by Semtech and the LoRa Alliance, Sigfox, Wireless Gigabit Alliance (WiGig) standard, mmWave standards in general (wireless systems operating at 10-300 GHz and above such as WiGig, IEEE XS202.11ad, IEEE XS202.11ay, etc. ) , technologies operating above 300 GHz and THz bands, (3GPP/LTE based or IEEE XS202.11p and other) Vehicle-to-Vehicle (V2V) and Vehicle-to-X (V2X) and Vehicle-to-Infrastructure (V2I) and Infrastructure-to-Vehicle (I2V) communication technologies, 3GPP cellular V2X, DSRC (Dedicated Short Range Communications) communication systems such as Intelligent-Transport-Systems and others, the European ITS-G5 system (i.e. the European flavor of IEEE XS202.11p based DSRC, including ITS-G5A (i.e., Operation of ITS-G5 in European ITS frequency bands dedicated to ITS for safety re-lated applications in the frequency range 5,875 GHz to 5,905 GHz) , ITS-G5B (i.e., Operation in European ITS frequency bands dedicated to ITS non-safety applications in the frequency range 5,855 GHz to 5,875 GHz) , ITS-G5C (i.e., Operation of ITS applications in the frequency range 5,470 GHz to 5,725 GHz) ) , etc.. In addition to the standards listed above, any number of satellite uplink technologies may be used for the transceivers XS211, XS212 including, for example, radios compliant with standards issued by the ITU (International Telecommunication Union) , or the ETSI (European Telecommunications Standards Institute) , among others. The examples provided herein are thus understood as being applicable to various other communication technologies, both existing and not yet formulated.

A network interface circuitry/controller (NIC) XS216 may be included to provide a wired communication to the cloud XS201 or to other devices, such as the mesh devices XS264. The wired communication may provide an Ethernet connection, or may be based on other types of networks, such as Controller Area Network (CAN) , Local Interconnect Network (LIN) , DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among many others. An additional NIC XS216 may be included to allow connect to a second network, for example, a NIC XS216 providing communications to the cloud over Ethernet, and a second NIC XS216 providing communications to other devices over another type of network. The NIC XS216 comprises one or more dedicated processors and/or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the NIC XS216 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

The interconnect XS206 may couple the processor circuitry XS202 to an external interface XS218 (also referred to as “I/O interface circuitry” or the like) that is used to connect external devices or subsystems. As used herein, the term “interface circuitry” may refer to, is part of, or includes circuitry providing for the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, input/output (I/O) interfaces, peripheral component interfaces, network interface cards, and/or the like. In some implementations, the interface circuitry XS218 may connect the platform XS200 with positioning circuitry XS245, which may be the same or similar as the positioning circuitry XS145 discussed with regard to Figure XS1. The external devices may include sensor circuitry XS222, such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, pressure sensors, barometric pressure sensors, and the like. The external interface XS218 connects the platform XS200 to electro-mechanical devices (EMCs) XS224, allow platform XS200 to change its state, position, and/or orientation, or move or control a mechanism or system. The EMCs XS222 may include one or more power switches, relays including electromechanical relays (EMRs) and/or solid state relays (SSRs) , actuators (e.g., valve actuators, etc. ) , an audible sound generator, a visual warning device, motors (e.g., DC motors, stepper motors, etc. ) , wheels, thrusters, propellers, claws, clamps, hooks, and/or other like electro-mechanical components. In embodiments, platform XS200 may be configured to operate one or more EMCs XS222 based on one or more captured events and/or instructions or control signals received from a service provider and/or various client systems. In some embodiments, the aforementioned sensor circuitry XS222 and EMCs XS224 may correspond to the sensors 428 discussed with regard to Figure 4. In other embodiments, the platform XS200 that utilizes the sensor circuitry XS222 and EMCs XS224 may correspond to the sensors F428 discussed with regard to Figure F4.

In embodiments where the platform XS200 is implemented in or by a vehicle (such as in the various embodiments discussed herein) , the EMCs XS222 may be controlled by electronic/engine control units (ECUs) , electronic/engine control modules (ECMs) , or other like embedded computer device that controls one or more electrical systems of a vehicle. The ECUs may obtain sensor data from one or more sensors XS222 embedded in the vehicle, interpret the sensor data using multidimensional performance maps or lookup tables, and control other EMCs XS222 (e.g., valve actuators, fuel injectors, ignition coils, etc. ) to adjust or alter the performance of corresponding systems. Examples of these systems include, inter alia, a fuel injection system operated by an ECM to control the air-to-fuel ratio (AFR) to the cylinders of the vehicle’s engine and/or the engine’s revolutions per minute (RPMs) ; a transmission system operated by a transmission control unit (TCU) to control, for example, a transmission gear ratio; variable valve timing systems; and the like. The ECUs may include, inter alia, a Drivetrain Control Unit (DCU) , an Engine Control Module (ECM) , Electronic Engine Management System (EEMS) , a Powertrain Control Module (PCM) , a Transmission Control Module (TCM) , a Brake Control Module (BCM) including an anti-lock brake system (ABS) module and/or an electronic stability control (ESC) system, a Central Control Module (CCM) , a Central Timing Module (CTM) , a General Electronic Module (GEM) , a Body Control Module (BCM) , a Suspension Control Module (SCM) , a Door Control Unit (DCU) , a Speed Control Unit (SCU) , a Human-Machine Interface (HMI) unit, a Telematic Control Unit (TTU) , a Battery Management System and/or any other entity or node in a vehicle system. In some embodiments, the one or more of the ECUs 322 and/or platform XS200 may be part of or included in a Portable Emissions Measurement Systems (PEMS) . In an example, an ECM or ECU may provide engine revolutions per minute (RPM) of an engine of the vehicle, fuel injector activation timing data of one or more cylinders and/or one or more injectors of the engine, ignition spark timing data of the one or more cylinders (e.g., an indication of spark events relative to crank angle of the one or more cylinders) , transmission gear ratio data and/or transmission state data (which may be supplied to the EMC/ECU by the TCU) , real-time calculated engine load values from the ECM, etc.; a TCU may provide transmission gear ratio data, transmission state data, etc.; and the like.

In some implementations, the interface circuitry may connect the platform XS200 with positioning circuitry XS245, which may be the same or similar as the positioning circuitry XS145 discussed with regard to Figure XS1.

In some implementations, the interface circuitry may connect the platform XS200 with near-field communication (NFC) circuitry XS240, which may include an NFC controller coupled with an antenna element and a processing device. The NFC circuitry XS240 may be configured to read electronic tags and/or connect with another NFC-enabled device.

The driver circuitry XS246 may include software and hardware elements that operate to control particular devices that are embedded in the platform XS200, attached to the platform XS200, or otherwise communicatively coupled with the platform XS200. The driver circuitry XS246 may include individual drivers allowing other components of the platform XS200 to interact or control various input/output (I/O) devices that may be present within, or connected to, the platform XS200. For example, driver circuitry XS246 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface of the platform XS200, sensor drivers to obtain sensor readings of sensors XS222 and control and allow access to sensors XS222, EMC drivers to obtain actuator positions of the EMCs XS222 and/or control and allow access to the EMCs XS222, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

The management engine (ME) circuitry XS250 is one or more hardware and/or software components used to remotely manage the platform XS200, and to establish that the platform XS200 is using or includes trustworthy components to ensure the integrity of other parts of the platform XS200. The ME circuitry XS250 may be embodied as any number of hardware, firmware, and/or software modules configured to perform security, encryption, and/or authentication functions, as described herein. In some implementations, the ME circuitry XS250 may be an physically isolated and tamper-resistant chipset, which is distinct from and generally operates independently of the processor circuitry XS202. In other implementations, the isolation of the ME circuitry XS250 can be realized using secure processor modes, virtualization (e.g., using a virtual machine) , or containerization (e.g., using an application container, such as

containers) . In embodiments where the ME circuitry XS250 is implemented as a separate chipset, the ME circuitry XS250 may be included in a graphics controller or graphics processing unit (GPU) , integrated into the application circuitry (e.g., a same circuit board or package as processor circuitry XS202 and/or memory circuitry XS204, etc. ) , or integrated into the communication circuitry of the platform XS200 (e.g., a same circuit board, SoC, SiP, etc. as the modem circuitry XS210 or the NIC XS216) . In other embodiments, the ME circuitry XS250 may additionally or alternatively include separate circuitry disposed on another circuit board, SoC, package, SiP, etc. that is communicatively coupled to the application circuitry and/or the communication circuitry via a signal path, such as interconnect XS206 or a separate bus (e.g., a private LPC bus/interconnect) . In some implementations, the ME circuitry XS250 may be communicatively coupled the application circuitry, communications circuitry, and/or other components of the platform XS200 via interconnect XS206 or via one or more separate bus/interconnects, such as a private low pin count (LPC) serial bus or some other bus or interconnect that is not exposed to a host OS of the application circuitry.

In this example, the ME circuitry XS250 includes ME processor XS252 and ME memory XS254. ME memory XS254 is a mechanism that provides secure storage of certain data and disallows unauthorized access by other untrusted components of the platform XS200. The ME circuitry XS254 stores various crypto operations, which is a set of cryptographic algorithms or operations used for generating keys and encrypting/decrypting data. The keys may be used to encrypt/decrypt data being communicated through the ME circuitry XS250. In some embodiments, the keys may be generated based on one or more measurements of the application circuitry. However, any suitable algorithm or operations may be used for key generation and/or encrypting/decrypting data. The ME memory XS254 also stores program code/computational logic of an ME operating system, firmware, or the like, for authenticating and verifying trusted components to access to securely stored data, and for preventing unauthorized or untrusted components from accessing the securely stored data. ME processor XS252 comprises one or more processing devices capable of executing software modules or program code independently of the other processors of the application circuitry and may include tamper-resistant characteristics. ME processor XS252 may include one or more microprocessors, DSPs, cryptoprocessors, secure cryptoprocessors, cryptographic accelerators, secure controllers, and/or any other suitable device. The ME memory XS254 may be embodied as one or more volatile and/or non-volatile memory devices. The ME memory XS254 may store various data, including software/firmware executable by the ME processor XS252 and data used for the various cryptographic operations, program code for an ME OS (not shown) , keys, and crypto operations, and/or the like. In one example, a software or firmware component called a “management layer” , when executed by the ME processor XS252, provides a runtime environment for trusted applications or components, and enforces access control to protected resources (e.g., the aforementioned keys) . The integrity of the management layer may be verified either as part of the boot time platform integrity verification (and runtime monitoring) or on demand when trusted applications are loaded for execution.

ME processor XS252 may implement an ME OS, which may be a framework that provides OS like functionality to trusted applications, and provides an API for client applications to access trusted applications. The ME OS may also include internal ME APIs or libraries, such as a cryptographic operations API to provide cryptographic capabilities (e.g., the cryptographic algorithms/operations of crypto operations) to trusted applications, a trusted storage API to provide trusted storage for keys and other data, and a secure element API that provides mechanisms for an application to open a connection with a secure element. In some embodiments, the ME OS may also include firmware or drivers that provide override mechanisms for tamper-resistant hardware devices, and firmware or drivers for verifying digital certificates, etc. These firmware modules may ensure that various conditions are met before any new applications are provisioned within the ME circuitry XS250. In some embodiments, the ME OS may include firmware modules for signing and verifying certificates using a certificate signing key pair. The firmware modules may verify a digital signature of certificates using a public key of the certificate signing key pair, and the private key of the certificate signing key pair is used by the security assist server to sign the certificates. The private key of this key pair may be stored in a secure data store associated with a remote provisioning service, and the public key of the key pair may be maintained in ME memory 754 as a firmware image that cannot be changed or altered (e.g., as one of the keys) . In some embodiments, the ME OS may be any suitable OS or firmware, such as a real-time OS (RTOS) and the like.

According to various embodiments, the ME circuitry XS250 may enable remote management of the platform XS200 by RMS 210. In such embodiments, the RMS 210 may communicate with the platform XS200 via a secure and/or encrypted link or channel with the ME circuitry XS250 that is separate from the communications channels used by the application circuitry. The link with the ME circuitry XS250 may secured using Transport Layer Security (TLS) . This may be referred to as “out-of-band” management because the secure channel/link is outside of the normal communications link that the platform XS200 uses to communicate with other devices or systems. In embodiments, the ME circuitry XS250 may operate in accordance with the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) specification ISO/IEC 11889: 2009, which defines standards for trusted computing platforms. In embodiments, the ME circuitry XS250 may be a Desktop and mobile Architecture Hardware (DASH) compliant Network Interface Card (NIC) , a Management/Manageability Engine provided by

a Converged Security Engine (CSE) or a Converged Security Management/Manageability Engine (CSME) provided by

Trusted Execution Engine (TXE) provided by

Platform Security coProcessor (PSP) ,

PRO A-Series Accelerated Processing Unit (APU) with DASH manageability, the

Crypto

4807, 4XS208, 4809, and/or 4765 Cryptographic Coprocessors,

Baseboard Management Controller (BMC) with Intelligent Platform Management Interface (IPMI) , Dell ^TM Remote Assistant Card II (DRAC II) , integrated Dell ^TM Remote Assistant Card (iDRAC) , and the like. The ME circuitry XS250 may operate in conjunction with

Secure Technology,

Trusted Execution Technology (TXT) provided by

Active Management Technology (AMT) provided by

and/or

vPro ^TM Technology (vPro) . The

AMT and/or

vPro ^TM may allow for remote provisioning of the ME circuitry XS250, and remote management of the ME circuitry XS250 once the ME circuitry XS250 has been successfully provisioned.

In some optional examples, various input/output (I/O) devices may be present within, or connected to, the platform XS200. For example, a display or other output device 1084 may be included to show information, such as sensor readings or actuator position. An input device 1086, such as a touch screen or keypad may be included to accept input. An output device 1084 may include any number of forms of audio or visual display, including simple visual outputs such as binary status indicators (e.g., LEDs) and multi-character visual outputs, or more complex outputs such as display screens (e.g., LCD screens) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the platform XS200. In another example, near-field communication (NFC) circuitry comprising an NFC controller coupled with an antenna element and a processing device may be included to read electronic tags and/or connect with another NFC-enabled device.

A battery XS226 may power the platform XS200, although in examples in which the platform XS200 is mounted in a fixed location, it may have a power supply coupled to an electrical grid. The battery XS226 may be a lithium ion battery, or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like.

A battery monitor/charger XS228 may be included in the platform XS200 to track the state of charge (SoCh) of the battery XS226. The battery monitor/charger XS228 may be used to monitor other parameters of the battery XS226 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery XS226. The battery monitor/charger XS228 may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix Arizona, or an IC from the UCD90xxx family from Texas Instruments of Dallas, TX. The battery monitor/charger XS228 may communicate the information on the battery XS226 to the processor circuitry XS202 over the interconnect XS206. The battery monitor/charger XS228 may also include an analog-to-digital (ADC) convertor that allows the processor circuitry XS202 to directly monitor the voltage of the battery XS226 or the current flow from the battery XS226. The battery parameters may be used to determine actions that the platform XS200 may perform, such as transmission frequency, mesh network operation, sensing frequency, and the like.

A power block XS228, or other power supply coupled to a grid, may be coupled with the battery monitor/charger XS228 to charge the battery XS226. In some examples, the power block XS228 may be replaced with a wireless power receiver to obtain the power wirelessly, for example, through a loop antenna in the platform XS200. A wireless battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, California, among others, may be included in the battery monitor/charger XS228. The specific charging circuits chosen depend on the size of the battery XS226, and thus, the current required. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard, promulgated by the Alliance for Wireless Power, among others.

In some implementations, the battery XS228 may be a “smart battery, ” which includes or is coupled with a Battery Management System (BMS) or battery monitoring integrated circuitry. The BMS may be included in the platform XS200 to track the state of charge (SoCh) of the battery XS228. The BMS may be used to monitor other parameters of the battery XS228 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery XS228. The BMS may communicate the information of the battery XS228 to the application circuitry XS205 or other components of the platform XS200. The BMS may also include an analog-to-digital (ADC) convertor that allows the application circuitry XS205 to directly monitor the voltage of the battery XS228 or the current flow from the battery XS228. The battery parameters may be used to determine actions that the platform XS200 may perform, such as transmission frequency, network operation, sensing frequency, and the like

Input device circuitry XS286 and output device circuitry XS284 may include one or more user interfaces designed to enable user interaction with the platform XS200 and/or peripheral component interfaces designed to enable peripheral component interaction with the platform XS200. Input device circuitry XS286 may include, inter alia, one or more physical or virtual buttons (e.g., a reset button) , a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, microphones, a scanner, a headset, and the like. The output device circuitry XS284 may include, but are not limited to one or more indicators (e.g., light emitting diodes (LEDs) ) , speakers or other audio emitting devices, a printer, a display screen, display device (or a touchscreen) , a projector, etc. In some embodiments, the sensor circuitry XS222 may be used as the input device circuitry XS286 (e.g., an image capture device, motion capture device, or the like) and one or more EMCs XS224 may be used as the output device circuitry XS284 (e.g., an actuator to provide haptic feedback or the like) . Peripheral component interfaces may include, but arenot limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, etc.

A power block, or other power supply coupled to an electrical grid may be coupled with the BMS to charge the battery XS228. In some examples, the power block XQ28 may be replaced with a wireless power receiver to obtain the power wirelessly, for example, through a loop antenna in the computer platform XS200. In these examples, a wireless battery charging circuit may be included in the BMS. The specific charging circuits chosen may depend on the size of the battery XS228, and thus, the current required. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard, promulgated by the Alliance for Wireless Power, among others.

Although not shown, the components of platform XS200 may communicate with one another using a suitable bus technology, which may include any number of technologies, including industry standard architecture (ISA) , extended ISA (EISA) , peripheral component interconnect (PCI) , peripheral component interconnect extended (PCIx) , PCI express (PCIe) , a Time-Trigger Protocol (TTP) system, or a FlexRay system, a Local Interconnect Network (LIN) , a controller area network (CAN) , or any number of other technologies. The bus may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I ²C interface, an SPI interface, point to point interfaces, and a power bus, among others.

Figure XT illustrates example components of baseband circuitry XS110/XS210 and radio front end modules (RFEM) XS115/XS215 in accordance with various embodiments. As shown, the RFEM XS115/XS215 may include Radio Frequency (RF) circuitry XT106, front-end module (FEM) circuitry XT108, one or more antennas XT111 coupled together at least as shown.

The baseband circuitry XS110/XS210 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry XS110/XS210 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry XT106 and to generate baseband signals for a transmit signal path of the RF circuitry XT106. Baseband processing circuity XS110/XS210 may interface with the application circuitry XS105/XS205 for generation and processing of the baseband signals and for controlling operations of the RF circuitry XT106. For example, in some embodiments, the baseband circuitry XS110/XS210 may include a third generation (3G) baseband processor XT104A, a fourth generation (4G) baseband processor XT104B, a fifth generation (5G) baseband processor XT104C, or other baseband processor (s) XT104D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G) , sixth generation (6G) , etc. ) . The baseband circuitry XS110/XS210 (e.g., one or more of baseband processors XT104A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry XT106. In other embodiments, some or all of the functionality of baseband processors XT104A-D may be included in modules stored in the memory XT104G and executed via a Central Processing Unit (CPU) XT104E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequencyshifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry XS110/XS210 may include Fast-Fourier Transform (FFT) , precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry XS110/XS210 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry XS110/XS210 may include one or more audio digital signal processor (s) (DSP) XT104F. The audio DSP (s) XT104F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry XS110/XS210 and the application circuitry XS105/XS205 may be implemented together such as, for example, on a system on a chip (SOC) .

In some embodiments, the baseband circuitry XS110/XS210 may provide for communicationcompatiblewith one or more radio technologies. For example, in some embodiments, the baseband circuitry XS110/XS210 may support communication with an evolved universal terrestrial radioaccess network (EUTRAN) or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) . Embodiments in which the baseband circuitry XS110/XS210 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry XT106 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry XT106 may include switches, filters, amplifiers, etc. to facilitate the communicationwith the wireless network. RF circuitry XT106 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry XT108 and provide baseband signals to the baseband circuitry XS110/XS210. RF circuitry XT106 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry XS110/XS210 and provide RF output signals to the FEM circuitry XT108 for transmission.

In some embodiments, the receive signal path of the RF circuitry XT106 may include mixer circuitry XT106a, amplifier circuitry XT106b and filter circuitry XT106c. In some embodiments, the transmit signal path of the RF circuitry XT106 may include filter circuitry XT106c and mixer circuitry XT106a. RF circuitry XT106 may also include synthesizer circuitry XT106d for synthesizing a frequency for use by the mixer circuitry XT106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry XT106a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry XT108 based on the synthesized frequency provided by synthesizer circuitry XT106d. The amplifier circuitry XT106b may be configured to amplify the down-converted signals and the filter circuitry XT106c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry XS110/XS210 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry XT106a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry XT106a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry XT106d to generate RF output signals for the FEM circuitry XT108. The baseband signals may be provided by the baseband circuitry XS110/XS210 and may be filtered by filter circuitry XT106c.

In some embodiments, the mixer circuitry XT106a of the receive signal path and the mixer circuitry XT106a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry XT106a of the receive signal path and the mixer circuitry XT106a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection) . In some embodiments, the mixer circuitry XT106a of the receive signal path and the mixer circuitry XT106a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry XT106a of the receive signal path and the mixer circuitry XT106a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry XT106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry XS110/XS210 may include a digital baseband interface to communicate with the RF circuitry XT106.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry XT106d may be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry XT106d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry XT106d may be configured to synthesize an output frequency for use by the mixer circuitry XT106a of the RF circuitry XT106 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry XT106d may be a fractional N/N+1 synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO) , although that is not a requirement. Divider control input may be provided by either the baseband circuitry XS110/XS210 or the applications processor XS105/XS205 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor XS105/XS205.

Synthesizer circuitry XT106d of the RF circuitry XT106 may include a divider, a delay-locked loop (DLL) , a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA) . In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry XT106d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO) . In some embodiments, the RF circuitry XT106 may include an IQ/polar converter.

FEM circuitry XT108 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas XT111, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry XT106 for further processing. FEM circuitry XT108 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry XT106 for transmission by one or more of the one or more antennas XT111. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry XT106, solely in the FEM XT108, or in both the RF circuitry XT106 and the FEM XT108.

In some embodiments, the FEM circuitry XT108 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry XT106) . The transmit signal path of the FEM circuitry XT108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry XT106) , and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas XT111) .

Processors of the application circuitry XS105/XS205 and processors of the baseband circuitry XS110/XS210 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry XS110/XS210, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the baseband circuitry XS110/XS210 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers) . As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

Figure XU illustrates example interfaces of baseband circuitry in accordance with various embodiments. As discussed above, the baseband circuitry XS110/XS210 of FIGS. XS1, XS2, and XT may comprise processors XT104A-XT104E and a memory XT104G utilized by said processors. Each of the processors XT104A-XT104E may include a memory interface, XU104A-XU104E, respectively, to send/receive data to/from the memory XT104G.

The baseband circuitry XS110/XS210 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface XU112 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry XS110/XS210) , an application circuitry interface XU114 (e.g., an interface to send/receive data to/from the application circuitry XS105/XS205 of FIGS. XS1-XT) , an RF circuitry interface XU116 (e.g., an interface to send/receive data to/from RF circuitry XT106 of Figure XT) , a wireless hardware connectivity interface XU118 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components,

components (e.g.,

Low Energy) ,

components, and other communication components) , and a power management interface XU120 (e.g., an interface to send/receive power or control signals to/from the PMIC XS225.

Figure XV illustrates various protocol functions that may be implemented in a wireless communication device according to various embodiments. In particular, Figure XV includes an arrangement XV00 showing interconnections between various protocol layers/entities. The following description of Figure XV is provided for various protocol layers/entities that operate in conjunction with the Fifth Generation (5G) or New Radio (NR) system standards and LTE system standards, but some or all of the aspects of Figure XV may be applicable to other wireless communication network systems as well.

The protocol layers of arrangement XV00 may include one or more of a physical layer (PHY) XV10, a medium access control layer (MAC) XV20, a radio link control layer (RLC) XV30, a packet data convergence protocol layer (PDCP) XV40, a service data adaptation protocol layer (SDAP) XV47, a radio resource control layer (RRC) XV55, and a non-access stratum (NAS) layer XV57, in addition to other higher layer functions not illustrated. The protocol layers may include one or more service access points (e.g., items XV59, XV56, XV49, XV45, XV35, XV25, and XV15 in Figure XV) that may provide communication between two or more protocol layers.

The PHY XV10 may transmit and receive physical layer signals XV05 that may be received from or transmitted to one or more other communication devices. The physical layer signals XV05 may comprise one or more physical channels, such as those discussed herein. The PHY XV10 may further perform link adaptation or adaptive modulation and coding (AMC) , power control, cell search (e.g., for initial synchronization and handover purposes) , and other measurements used by higher layers, such as the RRC XV55. The PHY XV10 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing. In embodiments, an instance of PHY XV10 may process requests from and provide indications to an instance of MAC XV20 via one or more physical layer service access points (PHY-SAP) XV15. According to some embodiments, requests and indications communicated via PHY-SAP XV15 may comprise one or more transport channels.

Instance (s) of MAC XV20 may process requests from, and provide indications to an instance of RLC XV30 via one or more medium access control service access points (MAC-SAP) XV25. These requests and indications communicated via the MAC-SAP XV25 may comprise one or more logical channels. The MAC XV20 may perform mapping between the logical channels and transport channels, multiplexing of MAC SDUs from one or more logical channels onto transport blocks (TB) to be delivered to PHY XV10 via the transport channels, de-multiplexing MAC SDUs to one or more logical channels from TBs delivered from the PHY XV10 via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ) , and logical channel prioritization.

Instance (s) of RLC XV30 may process requests from and provide indications to an instance of PDCP XV40 via one or more radio link control service access points (RLC-SAP) XV35. These requests and indications communicated via RLC-SAP XV35 may comprise one or more RLC channels. The RLC XV30 may operate in a plurality of modes of operation, including: Transparent Mode (TM) , Unacknowledged Mode (UM) , and Acknowledged Mode (AM) . The RLC XV30 may execute transfer of upper layer protocol data units (PDUs) , error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. The RLC XV30 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.

Instance (s) of PDCP XV40 may process requests from and provide indications to instance (s) of RRC XV55 and/or instance (s) of SDAP XV47 via one or more packet data convergence protocol service access points (PDCP-SAP) XV45. These requests and indications communicated via PDCP-SAP XV45 may comprise one or more radio bearers. The PDCP layer XV04 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs) , perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc. ) .

Instance (s) of SDAP XV47 may process requests from and provide indications to one or more higher layer protocol entities via one or more service data adaptation protocol service access points (SDAP-SAP) XV49. These requests and indications communicated via SDAP-SAP XV49 may comprise one or more quality of service (QoS) flows. The SDAP XV47 may map QoS flows to data radio bearers (DRBs) , and vice versa, and may also mark QoS flow IDs (QFIs) in DL and UL packets. A single SDAP entity XV47 may be configured for an individual PDU session. In the UL direction, the NG-RAN XQ20 may control the mapping of QoS Flows to DRB(s) in two different ways, reflective mapping or explicit mapping. For reflective mapping, the SDAP XV47 of a UE XQ01 may monitor the QoS flow ID (s) of the DL packets for each DRB, and may apply the same mapping for packets flowing in the UL direction. For a DRB, the SDAP XV47 of the UE XQ01 may map the UL packets belonging to the QoS flows (s) corresponding to the QoS flow ID (s) and PDU Session observed in the DL packets for that DRB. To enable reflective mapping, the NG-RAN XR210 may mark DL packets over the Uu interface with a QoS flow ID. The explicit mapping may involve the RRC XV55 configuring the SDAP XV47 with an explicit QoS flow to DRB mapping rule, which may be stored and followed by the SDAP XV47. In embodiments, the SDAP XV47 may only be used in NR implementations and may not be used in LTE implementations.

The RRC XV55 may configure, via one or more management service access points (M-SAP) , aspects of one or more protocol layers, which may include one or more instances of PHY XV10, MAC XV20, RLC XV30, PDCP XV40 and SDAP XV47. In embodiments, an instance of RRC XV55 may process requests from and provide indications to one or more NAS entities XV57 via one or more RRC service access points (RRC-SAP) XV56. The main services and functions of the RRC XV55 may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the NAS) , broadcast of system information related to the access stratum (AS) , paging, establishment, maintenance and release of an RRC connection between the UE XQ01 and RAN XQ20 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release) , establishment, configuration, maintenance and release of point to point Radio Bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. The MIBs and SIBs may comprise one or more information elements (IEs) , which may each comprise individual data fields or data structures.

The NAS XV57 may form the highest stratum of the control plane between the UE XQ01 and the AMF XR221. The NAS XV57 may support the mobility of the UEs XQ01 and the session management procedures to establish and maintain IP connectivity between the UE 101 and a P-GW in LTE systems.

According to various embodiments, one or more protocol entities of arrangement XV00 may be implemented in UEs XQ01, RAN nodes XQ111, AMF XR221 in NR implementations or MME XR121 in LTE implementations, UPF XR202 in NR implementations or S-GW XR122 and P-GW XR123 in LTE implementations, or the like to be used for control plane or user plane communications protocol stack between the aforementioned devices. In such embodiments, one or more protocol entities that may be implemented in one or more of UE XQ01, gNB XQ11, AMF XR221, etc. may communicate with a respective peer protocol entity that may be implemented in or on another device using the services of respective lower layer protocol entities to perform such communication. In some embodiments, a gNB-central unit (gNB-CU) of the gNB XQ11 may host the RRC XV55, SDAP XV47, and PDCP XV40 of the gNB that controls the operation of one or more gNB-distributed units (DUs) , and the gNB-DUs of the gNB XQ11 may each host the RLC XV30, MAC XV20, and PHY XV 10 of the gNB XQ11.

In a first example, a control plane protocol stack may comprise, in order from highest layer to lowest layer, NAS XV 57, RRC XV 55, PDCP XV40, RLC XV30, MAC XV 20, and PHY XV 10. In this example, upper layers XV60 may be built on top of the NAS XV 57, which includes an internet protocol layer (IP) XV61, an Stream Control Transmission Protocol layer (SCTP) XV62, and an application layer signaling protocol (AP) XV63.

In NR implementations, the AP XV63 may be an NG application protocol layer (NGAP or NG-AP) XV63 for the NG interface XQ13 defined between the NG-RAN node XQ11 and the AMF XR221, or the AP XV63 may be an Xn application protocol layer (XnAP or Xn-AP) XV63 for the Xn interface XQ12 that is defined between two or more RAN nodes XQ11.

The NG-AP XV63 may support the functions of the NG interface XQ13 and may comprise Elementary Procedures (EPs) . An NG-AP EP may be a unit of interaction between the NG-RAN node XQ11 and the AMF XR221. The NG-AP XV63 services may comprise two groups: UE-associated services (e.g., services related to a UE 101, 102) and non-UE-associated services (e.g., services related to the whole NG interface instance between the NG-RAN node XQ11 and AMF XR221) . These services may include functions including, but not limited to: a paging function for the sending of paging requests to NG-RAN nodes XQ11 involved in a particular paging area; UE Context management function for allowing the AMF XR221 to establish, modify, and/or release a UE Context in the AMF XR221 and the NG-RAN node XQ11; mobility function for UEs XQ01 in ECM-CONNECTED mode for intra-system HOs to support mobility within NG-RAN and inter-system HOs to support mobility from/to EPS systems; NAS Signaling Transport function for transporting or rerouting NAS messages between UE XQ01 and AMF XR221; a NAS node selection function for determining an association between the AMF XR221 and the UE XQ01; NG interface management function (s) for setting up the NG interface and monitoring for errors over the NG interface; warning message transmission function provides means to transfer warning messages via NG interface or cancel ongoing broadcast of warning messages; Configuration Transfer function for requesting and transferring of RAN configuration information (e.g., Self-Organizing Network (SON) information, performance measurement (PM) data, etc. ) between two RAN nodes XQ11 via CN XQ20; and/or other like functions.

The XnAP XV63 may support the functions of the Xn interface XQ12 and may comprise XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may comprise procedures used to handle UE mobility within the NG RAN XQ20 (or E-UTRAN XQ20) , such as handover preparation and cancellation procedures, SN Status Transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and the like. The XnAP global procedures may comprise procedures that are not related to a specific UE XQ01, such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, and the like.

In LTE implementations, the AP XV63 may be an S1 Application Protocol layer (S1-AP) XV63 for the S1 interface XQ13 defined between an E-UTRAN node XQ11 and an MME, or the AP XV63 may be an X2 application protocol layer (X2AP or X2-AP) XV63 for the X2 interface XQ12 that is defined between two or more E-UTRAN nodes XQ11.

The S1 Application Protocol layer (S1-AP) XV63 may support the functions of the S1 interface, and similar to the NG-AP discussed previously, the S1-AP may comprise S1-AP EPs. An S1-AP EP may be a unit of interaction between the E-UTRAN node XQ11 and an MME XR121within an LTE CN XQ20. The S1-AP XV63 services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM) , and configuration transfer.

The X2AP XV63 may support the functions of the X2 interface XQ12 and may comprise X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may comprise procedures used to handle UE mobility within the E-UTRAN XQ20, such as handover preparation and cancellation procedures, SN Status Transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and the like. The X2AP global procedures may comprise procedures that are not related to a specific UE XQ01, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, and the like.

The SCTP layer (alternatively referred to as the SCTP/IP layer) XV62 may provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1-AP or X2AP messages in LTE implementations) . The SCTP XV63 may ensure reliable delivery of signaling messages between the RAN node XQ11 and the AMF XR221/MME XR121 based, in part, on the IP protocol, supported by the IP XV61. The Internet Protocol layer (IP) XV61 may be used to perform packet addressing and routing functionality. In some implementations the IP layer XV61 may use point-to-point transmission to deliver convey PDUs. In this regard, the RAN node XQ11 may comprise L2 and L1 layer communication links (e.g., wired or wireless) with the MME/AMF to exchange information.

In a second example, a user plane protocol stack may comprise, in order from highest layer to lowest layer, SDAP XV47, PDCP XV40, RLC XV30, MAC XV 20, and PHY XV 10. The user plane protocol stack may be used for communication between the UE XQ01, the RAN node XQ11, and UPF XR202 in NR implementations or an S-GW ZR122 and P-GW XR123 in LTE implementations. In this example, upper layers XV51 may be built on top of the SDAP XV47, and may include a user datagram protocol (UDP) and IP security layer (UDP/IP) XV52, a General Packet Radio Service (GPRS) Tunneling Protocol for the user plane layer (GTP-U) XV53, and a User Plane Protocol Data Unit layer (UP PDU) XV63.

The transport network layer XV54 (also referred to as a “transport layer” ) may be built on IP transport, and the GTP-U XV51 may be used on top of the UDP/IP layer XR203 (comprising a UDP layer and IP layer) to carry user plane PDUs (UP-PDUs) . The IP layer (also referred to as the “Internet layer” ) may be used to perform packet addressing and routing functionality. The IP layer may assign IP addresses to user data packets in any of IPv4, IPv6, or PPP formats, for example.

The GTP-U XV53 may be used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats, for example. The UDP/IP XV52 may provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication on the selected data flows. The RAN node XQ11 and the S-GW XR122 may utilize an S1-U interface to exchange user plane data via a protocol stack comprising an L1 layer XV11, an L2 layer, the UDP/IP layer XV52, and the GTP-U XV53. The S-GW XR122 and the P-GW XR123 may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising an L1 layer, an L2 layer, the UDP/IP layer XV52, and the GTP-U XV53. As discussed previously, NAS protocols may support the mobility of the UE XQ01 and the session management procedures to establish and maintain IP connectivity between the UE XQ01 and the P-GW XR123.

Moreover, although not shown by Figure XV, an application layer may be present above the AP XV63 and/or the transport network layer XV54. The application layer may be a layer in which a user of the UE XQ01, RAN node XQ11, or other network element interacts with software applications being executed, for example, by application circuitry XS105 or application circuitry XS205, respectively. The application layer may also provide one or more interfaces for software applications to interact with communications systems of the UE XQ01 or RAN node XQ11, such as the baseband circuitry XS110/XS210. In some implementations the IP layer and/or the application layer may provide the same or similar functionality as layers 5-7, or portions thereof, of the Open Systems Interconnection (OSI) model (e.g., OSI Layer 7 –the application layer, OSI Layer 6 –the presentation layer, and OSI Layer 5 –the session layer) .

Figure XX illustrates components of a core network in accordance with various embodiments. The components of the CN XR120 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) . In embodiments, the components of CN XR220 may be implemented in a same or similar manner as discussed herein with regard to the components of CN XR120. In some embodiments, Network Functions Virtualization (NFV) is utilized to virtualize any or all of the above described network node functions via executable instructions stored in one or more computer readable storage mediums (described in further detail below) . A logical instantiation of the CN XR120 may be referred to as a network slice XX01, and individual logical instantiations of the CN XR120 may provide specific network capabilities and network characteristics. A logical instantiation of a portion of the CN XR120 may be referred to as a network sub-slice XX02 (e.g., the network sub-slice XX02 is shown to include the PGW XR123 and the PCRF XR126) .

As used herein, the terms “instantiate” , “instantiation” , and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. A network instance may refer to information identifying a domain, which may be used for traffic detection and routing in case of different IP domains or overlapping IP addresses. Anetwork slice instance may refer to set of network functions (NFs) instances and the resources (e.g., compute, storage, and networking resources) required to deploy the network slice.

With respect to 5G systems (see e.g., Figure XR2) , a network slice may include the CN control plane and user plane NFs, NG RANs in a serving PLMN, and a N3IWF functions in the serving PLMN. Individual network slices may have different Single Network Slice Selection Assistance Information (S-NSSAI) and/or may have different Slice/Service Types (SSTs) . Network slices may differ for supported features and network functions optimizations, and/or multiple network slice instances may deliver the same service/features but for different groups of UEs (e.g., enterprise users) . For example, individual network slices may deliver different committed service (s) and/or may be dedicated to a particular customer or enterprise. In this example, each network slice may have different S-NSSAIs with the same SST but with different slice differentiators. Additionally, a single UE may be served with one or more network slice instances simultaneously via a 5G access node (AN) and associated with eight different S-NSSAIs. Moreover, an AMF instance serving an individual UE may belong to each of the network slice instances serving that UE.

NFV architectures and infrastructures may be used to virtualize one or more NFs, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to execute virtual or reconfigurable implementations of one or more EPC components/functions.

Figure XY is a block diagram illustrating components, according to some example embodiments, of a system XY00 to support NFV. The system XY00 is illustrated as including a virtualized infrastructure manager (VIM) XY02, a network function virtualization infrastructure (NFVI) XY04, a VNF manager (VNFM) XY06, virtualized network functions (VNFs) XY08, an element manager (EM) XY10, an NFV Orchestrator (NFVO) XY12, and a network manager (NM) XY14.

The VIM XY02 manages the resources of the NFVI XY04. The NFVI XY04 can include physical or virtual resources and applications (including hypervisors) used to execute the system XY00. The VIM XY02 may manage the life cycle of virtual resources with the NFVI XY04 (e.g., creation, maintenance, and tear down of virtual machines (VMs) associated with one or more physical resources) , track VM instances, track performance, fault and security of VM instances and associated physical resources, and expose VM instances and associated physical resources to other management systems.

The VNFM XY06 may manage the VNFs XY08. The VNFs XY08 may be used to execute EPC components/functions. The VNFM XY06 may manage the life cycle of the VNFs XY08 and track performance, fault and security of the virtual aspects of VNFs XY08. The EM XY10 may track the performance, fault and security of the functional aspects of VNFs XY08. The tracking data from the VNFM XY06 and the EM XY10 may comprise, for example, performance measurement (PM) data used by the VIM XY02 or the NFVI XY04. Both the VNFM XY06 and the EM XY10 can scale up/down the quantity of VNFs of the system XY00.

The NFVO XY12 may coordinate, authorize, release and engage resources of the NFVI XY04 in order to provide the requested service (e.g., to execute an EPC function, component, or slice) . The NM XY14 may provide a package of end-user functions with the responsibility for the management of a network, which may include network elements with VNFs, non-virtualized network functions, or both (management of the VNFs may occur via the EM XY10) .

Figure XZ is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Figure XZ shows a diagrammatic representation of hardware resources X90 including one or more processors (or processor cores) XZ10, one or more memory/storage devices XZ20, and one or more communication resources XZ30, each of which may be communicatively coupled via a bus XZ40. As used herein, the term “computing resource” , “hardware resource” , etc., may refer to a physical or virtual device, a physical or virtual component within a computing environment, and/or physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time and/or processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, and/or the like. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor X92 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources X90. A “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc.

The processors XZ10 (e.g., a central processing unit (CPU) , a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU) , a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC) , a radio-frequency integrated circuit (RFIC) , another processor, or any suitable combination thereof) may include, for example, a processor XZ12 and a processor XZ14.

The memory/storage devices XZ20 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices XZ20 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM) , static random-access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , Flash memory, solid-state storage, etc.

The communication resources XZ30 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices X94 or one or more databases X96 via a network X98. For example, the communication resources XZ30 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB) ) , cellular communication components, NFC components,

components (e.g.,

Low Energy) ,

components, and other communication components. As used herein, the term “network resource” or “communication resource” may refer to computing resources that are accessible by computer devices via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

Instructions XZ50 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors XZ10 to perform any one or more of the methodologies discussed herein. The instructions XZ50 may reside, completely or partially, within at least one of the processors XZ10 (e.g., within the processor’s cache memory) , the memory/storage devices XZ20, or any suitable combination thereof. Furthermore, any portion of the instructions XZ50 may be transferred to the hardware resources X90 from any combination of the peripheral devices X94 or the databases X96. Accordingly, the memory of processors XZ10, the memory/storage devices XZ20, the peripheral devices X94, and the databases X96 are examples of computer-readable and machine-readable media.

Internet of Things (IoT) , Edge, and Fog Systems

The internet of things (IoT) is a concept in which a large number of computing devices are interconnected to each other and to the Internet to provide functionality and data acquisition at very low levels. As used herein, an IoT device may include a semiautonomous device performing a function, such as sensing or control, among others, in communication with other IoT devices and a wider network, such as the Internet. Often, IoT devices are limited in memory, size, or functionality, allowing larger numbers to be deployed for a similar cost to smaller numbers of larger devices. However, an IoT device may be a smart phone, laptop, tablet, or PC, or other larger device. Further, an IoT device may be a virtual device, such as an application on a smart phone or other computing device. IoT devices may include IoT gateways, used to couple IoT devices to other IoT devices and to cloud applications, for data storage, process control, and the like.

Networks of IoT devices may include commercial and home automation devices, such as water distribution systems, electric power distribution systems, pipeline control systems, plant control systems, light switches, thermostats, locks, cameras, alarms, motion sensors, and the like. The IoT devices may be accessible through remote computers, servers, and other systems, for example, to control systems or access data.

The future growth of the Internet may include very large numbers of IoT devices. Accordingly, as described herein, a number of innovations for the future Internet address the need for all these layers to grow unhindered, to discover and make accessible connected resources, and to support the ability to hide and compartmentalize connected resources. Any number of network protocols and communications standards may be used, wherein each protocol and standard is designed to address specific objectives. Further, the protocols are part of the fabric supporting human accessible services that operate regardless of location, time or space. The innovations include service delivery and associated infrastructure, such as hardware and software. The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements. The use of IoT devices and networks present a number of new challenges in a heterogeneous network of connectivity comprising a combination of wired and wireless technologies as depicted in Figures F1-F4.

Figure F1 illustrates an arrangement F100 showing interconnections that may be present between the Internet F100 and IoT networks, in accordance with various embodiments. The interconnections may couple smaller networks F102, down to the individual IoT device F104, to the fiber backbone F106 of the Internet F100. To simplify the drawing, not every device F104, or other object, is labeled.

In Figure F1, top-level providers, which may be termed tier 1 providers F108, are coupled by the fiber backbone of the Internet to other providers, such as secondary or tier 2 providers F110. In one example, a tier 2 provider F110 may couple to a tower F112 of an LTE cellular network, for example, by further fiber links, by microwave communications F114, or by other communications technologies. The tower F112 may couple to a mesh network including IoT devices F104 through an LTE communication link F116, for example, through a central node F118. The communications between the individual IoT devices F104 may also be based on LTE or NR communication links F116. In another example, a high-speed uplink F120 may couple a tier 2 provider F110 to a gateway (GW) F120. A number of IoT devices F104 may communicate with the GW F120, and with each other through the GW F120, for example, over BLE links F122.

The fiber backbone F106 may couple lower levels of service providers to the Internet, such as tier 3 providers F124. A tier 3 provider F124 may be considered a general Internet service provider (ISP) , for example, purchasing access to the fiber backbone F110 from a tier 2 provider F110 and providing access to a corporate GW F126 and other customers. From the corporate GW F126, a wireless local area network (WLAN) can be used to communicate with IoT devices F104 through

links F128. A Wi-Fi link F128 may also be used to couple to a low power wide area (LPWA) GW F130, which can communicate with IoT devices F104 over LPWA links F132, for example, compatible with the LoRaWan specification promulgated by the LoRa alliance.

The tier 3 provider F124 may also provide access to a mesh network F134 through a coordinator device F136 that communicates with the tier 3 provider F124 using any number of communications links, such as an LTE cellular link, an LPWA link, or a link F138 based on the IEEE XS202.15.4 standard, such as

Other coordinator devices F136 may provide a chain of links that forms cluster tree of linked devices.

IoT devices F104 may be any object, device, sensor, or “thing” that is embedded with hardware and/or software components that enable the object, device, sensor, or “thing” capable of capturing and/or recording data associated with an event, and capable of communicating such data with one or more other devices over a network with little or no user intervention. For instance, in various embodiments, IoT devices F104 may be abiotic devices such as autonomous sensors, gauges, meters, image capture devices, microphones, machine-type communications (MTC) devices, machine-to-machine (M2M) devices, light emitting devices, audio emitting devices, audio and/or video playback devices, electro-mechanical devices (e.g., switch, actuator, etc. ) , and the like. In some embodiments, IoT devices F104 may be biotic devices such as monitoring implants, biosensors, biochips, and the like. In other embodiments, an IoT device F104 may be a computer device that is embedded in a computer system and coupled with communications circuitry of the computer system. In such embodiments, the IoT device F104 may be a system on chip (SoC) , a universal integrated circuitry card (UICC) , an embedded UICC (eUICC) , and the like, and the computer system may be a mobile station (e.g., a smartphone) or user equipment, laptop PC, wearable device (e.g., a smart watch, fitness tracker, etc. ) , “smart” appliance (e.g., a television, refrigerator, a security system, etc. ) , and the like.

Each of the IoT devices F104 may include one or more memory devices and one or more processors to capture and store/record data. Each of the IoT devices F104 may include appropriate communications circuitry (e.g., transceiver (s) , modem, antenna elements, etc. ) to communicate (e.g., transmit and receive) captured and stored/recorded data. Further, each IoT device F104 may include other transceivers for communications using additional protocols and frequencies. According to various embodiments, the IoT devices F104 may be equipped with information (e.g., referred to as “modem profiles” herein) to configure configurable communications circuitry to perform communications in a corresponding communications. This may allow the IoT devices F104 to communicate using multiple wireless communications protocols without requiring an IoT device F104 to include separate hardware communications modules for each wireless communications protocol. The wireless communications protocols may be any suitable set of standardized rules or instructions implemented by the IoT devices F104 to communicate with other devices, including instructions for packetizing/depacketizing data, instructions for modulating/demodulating signals, instructions for implementation of protocols stacks, and the like. For example, IoT devices F104 may include communications circuitry that is configurable to communicate in accordance with one or more person-to-person (P2P) or personal area network (PAN) protocols (e.g., IEEE XS202.15.4 based protocols including ZigBee, IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) , WirelessHART, MiWi, Thread, etc.; WiFi-direct; Bluetooth/BLE protocols; ANT protocols; Z-Wave; LTE D2D or ProSe; UPnP; and the like) ; configurable to communicate using one or more LAN and/or WLAN protocols (e.g., Wi-Fi-based protocols or IEEE XS202.11 protocols, such as IEEE XS202.16 protocols) ; one or more cellular communications protocols (e.g., LTE/LTE-A, UMTS, GSM, EDGE, Wi-MAX, etc. ) ; and the like. In embodiments, one or more of tower F112, GW F120, F126, and F130, coordinator device F136, and so forth, may also be incorporated with the embodiments described herein, in particular, with references to Figures 1-XZ.

The technologies and networks may enable the exponential growth of devices and networks. As the technologies grow, the network may be developed for self-management, functional evolution, and collaboration, without needing direct human intervention. Thus, the technologies will enable networks to function without centralized controlled systems. The technologies described herein may automate the network management and operation functions beyond current capabilities.

Figure F2 illustrates an example domain topology F200 that may be used for a number of IoT networks coupled through backbone links F202 to GWs F204, in accordance with various embodiments. Like numbered items are as described with respect to Figure F1. Further, to simplify the drawing, not every device F104, or communications link F116, F122, F128, or F132 is labeled. The backbone links F202 may include any number of wired or wireless technologies, and may be part of a local area network (LAN) , a wide area network (WAN) , or the Internet. Similar to Figure F1, in embodiments, one or more of IoT devices F104, GW F204, and so forth, may be incorporated with embodiments described herein.

The network topology 200 may include any number of types of IoT networks, such as a mesh network F206 using BLE links F122. Other IoT networks that may be present include a WLAN network F208, a cellular network F210, and an LPWA network F212. Each of these IoT networks may provide opportunities for new developments, as described herein. For example, communications between IoT devices F104, such as over the backbone links F202, may be protected by a decentralized system for authentication, authorization, and accounting (AAA) . In a decentralized AAA system, distributed payment, credit, audit, authorization, and authentication systems may be implemented across interconnected heterogeneous infrastructure. This allows systems and networks to move towards autonomous operations.

In these types of autonomous operations, machines may contract for human resources and negotiate partnerships with other machine networks. This may allow the achievement of mutual objectives and balanced service delivery against outlined, planned service level agreements as well as achieve solutions that provide metering, measurements and traceability and trackability. The creation of new supply chain structures and methods may enable a multitude of services to be created, mined for value, and collapsed without any human involvement.

The IoT networks may be further enhanced by the integration of sensing technologies, such as sound, light, electronic traffic, facial and pattern recognition, smell, vibration, into the autonomous organizations. The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources.

The mesh network F206 may be enhanced by systems that perform inline data-to-information transforms. For example, self-forming chains of processing resources comprising a multi-link network may distribute the transformation of raw data to information in an efficient manner, and the ability to differentiate between assets and resources and the associated management of each. Furthermore, the proper components of infrastructure and resource based trust and service indices may be inserted to improve the data integrity, quality, assurance and deliver a metric of data confidence.

The WLAN network F208 may use systems that perform standards conversion to provide multi-standard connectivity, enabling IoT devices F104 using different protocols to communicate. Further systems may provide seamless interconnectivity across a multi-standard infrastructure comprising visible Internet resources and hidden Internet resources.

Communications in the cellular network F210 may be enhanced by systems that offload data, extend communications to more remote devices, or both. The LPWA network F212 may include systems that perform non-Internet protocol (IP) to IP interconnections, addressing, and routing.

Figure F3 illustrates an arrangement F300 of example cloud computing network, or cloud F302, in communication with a number of Internet of Things (IoT) devices, in accordance with various embodiments. The cloud F302 may represent the Internet, one or more cellular networks, a local area network (LAN) or a wide area network (WAN) including proprietary and/or enterprise networks for a company or organization, or combinations thereof. Components used for such communications system can depend at least in part upon the type of network and/or environment selected. Protocols and components for communicating via such networks are well known and will not be discussed herein in detail. However, it should be appreciated that cloud F302 may be associated with network operator who owns or controls equipment and other elements necessary to provide network-related services, such as one or more base stations or access points, and one or more servers for routing digital data or telephone calls (for example, a core network or backbone network) .

The IoT devices in Figure F3 may be the same or similar to the IoT devices F104 discussed with regard to Figures F1-F2. The IoT devices may include any number of different types of devices, grouped in various combinations, such as IoT group F306 that may include IoT devices that provide one or more services for a particular user, customer, organizations, etc. A service provider may deploy the IoT devices in the IoT group F306 to a particular area (e.g., a geolocation, building, etc. ) in order to provide the one or more services. In one example, the IoT group F306 may be a traffic control group where the IoT devices in the IoT group F306 may include stoplights, traffic flow monitors, cameras, weather sensors, and the like, to provide traffic control and traffic analytics services for a particular municipality or other like entity. Similar to Figures F1-F2, in embodiments, one or more of IoT devices F314-F324, GW F310, and so forth, may be incorporated with the various embodiments described herein, in particular, with references to Figures XP1 to XZ. For example, in some embodiments, the IoT group F306, or any of the IoT groups discussed herein, may include the components, devices, systems discussed with regard to Figures XP1 through XZ.

The IoT group F306, or other subgroups, may be in communication with the cloud F302 through wireless links F308, such as LPWA links, and the like. Further, a wired or wireless sub-network F312 may allow the IoT devices to communicate with each other, such as through a local area network, a wireless local area network, and the like. The IoT devices may use another device, such as a GW F310 to communicate with the cloud F302. Other groups of IoT devices may include remote weather stations F314, local information terminals F316, alarm systems F318, automated teller machines F320, alarm panels F322, or moving vehicles, such as emergency vehicles F324 or other vehicles F326, among many others. Each of these IoT devices may be in communication with other IoT devices, with servers F304, or both.

As can be seen from Figure F3, a large number of IoT devices may be communicating through the cloud F302. This may allow different IoT devices to request or provide information to other devices autonomously. For example, the IoT group F306 may request a current weather forecast from a group of remote weather stations F314, which may provide the forecast without human intervention. Further, an emergency vehicle F324 may be alerted by an automated teller machine F320 that a burglary is in progress. As the emergency vehicle F324 proceeds towards the automated teller machine F320, it may access the traffic control group F306 to request clearance to the location, for example, by lights turning red to block cross traffic at an intersection in sufficient time for the emergency vehicle F324 to have unimpeded access to the intersection.

In another example, the IoT group F306 may be an industrial control group (also referred to as a “connected factory” , an “industry 4.0” group, and the like) where the IoT devices in the IoT group F306 may include machines or appliances with embedded IoT devices, radiofrequency identification (RFID) readers, cameras, client computer devices within a manufacturing plant, and the like, to provide production control, self-optimized or decentralized task management services, analytics services, etc. for a particular manufacturer or factory operator. In this example, the IoT group F306 may communicate with the servers F304 via GW F310 and cloud F302 to provide captured data, which may be used to provide performance monitoring and analytics to the manufacturer or factory operator. Additionally, the IoT devices in the IoT group F306 may communicate among each other, and/or with other IoT devices of other IoT groups, to make decisions on their own and to perform their tasks as autonomously as possible.

Clusters of IoT devices, such as the IoT groups depicted by Figure F3, may be equipped to communicate with other IoT devices as well as with the cloud F302. This may allow the IoT devices to form an ad-hoc network between the devices, allowing them to function as a single device, which may be termed a fog device. This is discussed further with respect to Figure F4.

Figure F4 illustrates an arrangement F400 of a cloud computing network, or cloud F302, in communication with a mesh network of IoT devices, which may be termed a fog device F402, operating at the edge of the cloud F302, in accordance with various embodiments. Like numbered items are as described with respect to Figures F1-F3. In this example, the fog device F402 is a group of IoT devices at an intersection. The fog device F402 may be established in accordance with specifications released by the OpenFog Consortium (OFC) , the Open Connectivity Foundation ^TM (OCF) , among others.

In embodiments, fog computing systems, such as fog device F402, may be mechanisms for bringingcloud computing functionalitycloser to data generators and consumers wherein various network devices run cloud application logic on their native architecture. Fog computing systems may be used to perform low-latency computation/aggregation on the data while routing it to a central cloud computing service for performing heavy computations or computationally burdensome tasks. On the other hand, edge cloud computing (see e.g., Figures XP1-XP2 discussed above) consolidates human-operated, voluntary resources such as desktop PCs, tablets, smartphones, nano data centers as a cloud. In various implementations, resources in the edge cloud may be in one to two-hop proximity to the IoT devices 404, which may result in reducing overhead related to processing data and may reduce network delay.

In some embodiments, the fog device F402 may be a consolidation of IoT devices F404 and/or networking devices, such as routers and switches, with high computing capabilities and the ability to run cloud application logic on their native architecture. Fog resources may be manufactured, managed, and deployed by cloud vendors, and may be interconnected with highspeed, reliable links. Moreover, Fog resources reside farther from the edge of the network when compared to edge systems but closer than a central cloud infrastructure. Fog devices are used to effectively handle computationally intensive tasks offloaded by edge resources.

Data may be captured, stored/recorded, and communicated among the IoT devices F404. Analysis of the traffic flow and control schemes may be implemented by aggregators F406 that are in communication with the IoT devices F404 and each other through a mesh network. Data may be uploaded to the cloud F302, and commands received from the cloud F302, through GWs F310 that are in communication with the IoT devices F404 and the aggregators F406 through the mesh network. Unlike the traditional cloud computing model, in some implementations, the cloud F302 may have little or no computational capabilities and only serves as a repository for archiving data recorded and processed by the fog device F402. In these implementations, the cloud F302 centralized data storage system and provides reliability and access to data by the computing resources in the fog F402 and/or edge devices (see e.g., Figures XP1-XP2 discussed above) . Being at the core of the architecture, the Data Store is accessible by both Edge and Fog layers.

Similar to Figures F1-F3, in embodiments, one or more of IoT devices F404, aggregators F406, and so forth, may be incorporated with the various embodiments described herein, in particular, with references to Figures XP1 to XZ. For example, in some embodiments, the fog device F402, or any of grouping of devices discussed herein, may include the one or more components, devices systems, etc. discussed infra with regard to Figures XP1 to XZ.

Any number of communications links may be used in the fog device F402. Shorter-range links F408, for example, compatible with IEEE XS202.15.4 may provide local communications between IoT devices that are proximate to one another or other devices. Longer-range links F410, for example, compatible with LPWA standards, may provide communications between the IoT devices and the GWs F310. To simplify the diagram, not every communications link F408 or F410 is labeled with a reference number.

The fog device F402 may be considered to be a massively interconnected network wherein a number of IoT devices are in communications with each other, for example, by the communication links F408 and F410. The network may be established using the open interconnect consortium (OIC) standard specification 1.0 released by the Open Connectivity Foundation ^TM (OCF) on December 23, 2015. This standard allows devices to discover each other and establish communications for interconnects. Other interconnection protocols may also be used, including, for example, the AllJoyn protocol from the AllSeen alliance, the optimized link state routing (OLSR) Protocol, or the better approach to mobile ad-hoc networking (B.A.T.M.A.N) , among many others.

Communications from any IoT device may be passed along the most convenient path between any of the IoT devices to reach the GWs F310. In these networks, the number of interconnections may provide substantial redundancy, allowing communications to be maintained, even with the loss of a number of IoT devices.

Not all of the IoT devices may be permanent members of the fog device F402. In the example in the drawing 400, three transient IoT devices have joined the fog device F402, a first mobile device F412, a second mobile device F414, and a third mobile device F416. The fog device F402 may be presented to clients in the cloud F302, such as the server F304, as a single device located at the edge of the cloud F302. In this example, the control communications to specific resources in the fog device F402 may occur without identifying any specific IoT device F404 within the fog device F402. Accordingly, if any IoT device F404 fails, other IoT devices F404 may be able to discover and control a resource. For example, the IoT devices F404 may be wired so as to allow any one of the IoT devices F404 to control measurements, inputs, outputs, etc., for the other IoT devices F404. The aggregators F406 may also provide redundancy in the control of the IoT devices F404 and other functions of the fog device F402.

In some examples, the IoT devices may be configured using an imperative programming style, e.g., with each IoT device having a specific function and communication partners. However, the IoT devices forming the fog device F402 may be configured in a declarative programming style, allowing the IoT devices to reconfigure their operations and communications, such as to determine needed resources in response to conditions, queries, and device failures. This may be performed as transient IoT devices, such as the devices F412, F414, F416, join the fog device F402. As transient or mobile IoT devices enter or leave the fog F402, the fog device F402 may reconfigure itself to include those devices. This may be performed by forming a temporary group of the devices F412 and F414 and the third mobile device F416 to control or otherwise communicate with the IoT devices F404. If one or both of the devices F412, F414 are autonomous, the temporary group may provide instructions to the devices F412, F414. As the transient devices F412, F414, and F416, leave the vicinity of the fog device F402, it may reconfigure itself to eliminate those IoT devices from the network. The fog device F402 may also divide itself into functional units, such as the IoT devices F404 and other IoT devices proximate to a particular area or geographic feature, or other IoT devices that perform a particular function. This type of combination may enable the formation of larger IoT constructs using resources from the fog device F402.

As illustrated by the fog device F402, the organic evolution of IoT networks is central to maximizing the utility, availability and resiliency of IoT implementations. Further, the example indicates the usefulness of strategies for improving trust and therefore security. The local identification of devices may be important in implementations, as the decentralization of identity ensures a central authority cannot be exploited to allow impersonation of objects that may exist within the IoT networks. Further, local identification lowers communication overhead and latency.

Claims

A computer system, comprising a hypervisor having a plurality of vCPU, and a plurality of EPT to facilitate hosting of a virtual machine (VM) implementing an embedded control unit (ECU) , the VM having an unsecured world and a secured world, the secured world being isolated from the unsecured world.
The computer system of claim 1, wherein the plurality of EPT comprises two EPT to manage two sets of memory pages, one set each for the unsecured world and the secured world, to isolate the secured world from the unsecured world.
A computer system, comprising a hypervisor configured to manage a service machine and a plurality of virtual machines (VMs) ; wherein the hypervisor is configured to partition an NVMe storage device into a series of RPMB blocks (Blk#0, …Blk#n) , where each partition is assigned to one of the plurality of VMs; and wherein the service mahcine maintains a device module structure containing the NVMe block assignment (s) to the VMs.
The computer system of claim 3, wherein the hypervisor is configured to encrypt the RPMB blocks with one or more encryption keys (rkey) .
The computer system of claim 4, wherein the hypervisor is configured to generate and use a different rKey is used to encrypt each RPMB block.
The computer system of claim 4, wherein usage of the rKey of a RPMB assigned to a VM by the service machinee is authorized by the VM, and the service machine uses the rkey to authenticate and protect a communication channel between the service machine and the VM.
At least one computer readable medium (CRM) having instructions stored therein to implement a hypervisor on a computer system, in response to execution of the instructions by the computer system, to facilitate hosting of a virtual machine (VM) implementing an embedded control unit (ECU) , wherein the hypervisor having a plurality of vCPU, and a plurality of EPT, and wherein the VM has an unsecured world and a secured world, the secured world being isolated from the unsecured world.
The CRM of claim 7, wherein the plurality of EPT comprises two EPT to manage two sets of memory pages, one set each for the unsecured world and the secured world, to isolate the secured world from the unsecured world.
At least one computer readable medium (CRM) having instructions stored therein to implement a hypervisor on a computer system, in response to execution of the instructions by the computer system, to manage a service machine and a plurality of virtual machines (VMs) ; wherein the hypervisor is configured to partition an NVMe storage device into a series of RPMB blocks (Blk#0, …Blk#n) , where each partition is assigned to one of the plurality of VMs; and wherein the service mahcine maintains a device module structure containing the NVMe block assignment (s) to the VMs.
The CRM of claim 9, wherein the hypervisor is to encrypt the RPMB blocks with one or more encryption keys (rkey) .
The CRM of claim 10, wherein the hypervisor is to generate and use a different rKey is used to encrypt each RPMB block.
The CRM of claim 10, wherein usage of the rKey of a RPMB assigned to a VM by the service machine is authorized by the VM, and the service machine uses the rkey to authenticate and protect a communication channel between the service machine and the VM.