Patent Description:
A DNA fabric is part of an enterprise network that enables a distributed data place with a centralized control plane. The enterprise network typically provides wireless access to associated devices, allows mobility across its entire wireless network and implements network connectivity measures such as integrated security policies, client traffic dependent security policies and/or network segmentation for client traffic through the enterprise network.

Currently deployed DNA fabric structures service wired and/or Wi-Fi traffic. However, if devices associated with an enterprise establishes a cellular connection using its associated cellular wireless service provider, there is currently no mechanism for the enterprise to apply its network connectivity measures to such devices. For example, if a mobile device establishes a Wi-Fi connection to the network enterprise, the DNA fabric of the enterprise can provide network access to the mobile device, implement network security measures and policies, etc. However, once the mobile device switches to using its cellular connection (LTE/<NUM> interface, for example), the DNA fabric would be unable to track the mobile device, apply network security measures to the mobile device, etc. Furthermore, some enterprise network providers may build their own private LTE/<NUM> network and integration of associated LTE/<NUM> traffic with wired and/or Wi-Fi traffic through the DNA fabric is currently not possible.

<CIT> describes, according to a machine translation of its abstract, a mobile relay device with enhanced authentication and security functions and a packet data transceiving method using the same and a system thereof to enhance authentication and security without complexity based on intrinsic identification information of a terminal user connected to a mobile router.

<CIT> describes, according to its abstract, a hybrid access gateway (HAG) apparatus for native bridged communication in a communication network, comprising: an upstream interface configured for receiving downlink Open Systems Interconnection (OSI) layer <NUM> traffic in said communication network; at least one downstream cellular coupling interface configured to be communicatively coupled to a user equipment (UE) represented by an OSI layer <NUM> address via a cellular access network (e.g. a Radio Access Network or RAN) of said communication network; an inspection module configured for inspecting an OSI layer <NUM> header of said received traffic; and a direction module configured for, based on said inspected OSI layer <NUM> header, directing said received traffic to said user equipment via said at least one downstream cellular coupling interface.

<CIT> describes, according to its abstract, systems, devices, and configurations to implement trusted connections within wireless networks and associated devices and systems. In some examples, a wireless local area network (WLAN) may be attached to a 3GPP evolved packet core (EPC) as a trusted access network, without use of an evolved packet data gateway (ePDG) and overhead from related tunneling and encryption. Information to create the trusted attachment between a mobile device and a WLAN may be exchanged using Access Network Query Protocol (ANQP) extensions defined by IEEE standard <NUM>. 11u-<NUM>, or using other protocols or standards such as DHCP or EAP. A trusted WLAN container with defined data structure fields may be transferred in the ANQP elements to exchange information used in the establishment and operation of the trusted attachment.

The invention of the present European patent is set out in the appended claims.

Various example embodiments of the disclosure are discussed in detail below. Thus, the following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure can be references to the same embodiment or any embodiment; and, such references mean at least one of the embodiments.

Disclosed are systems, methods, and computer-readable media for integrating LTE/<NUM> capable access points into a DNA fabric of a network or any enterprise overlay management solution for servicing associated devices and more specifically for implementing procedures for managing LTF/<NUM> traffic to and from LTE/<NUM> devices via a DNA fabric of a network.

In one aspect of the present disclosure, an access point (AP) of a network, including memory having computer-readable instructions stored therein and one or more processors. The one or more processors are configured to execute the computer-readable instructions to generate a pseudo Media Access Control (MAC) address for a device attempting to establish a cellular connection via the access point based on a unique identifier of the device; obtain an Internet Protocol (IP) address for the device based on the pseudo MAC address, the IP address being used for tracking mobility of the device across the network; obtain a tag for the device from a network component associated with the network; and connect the device to the network using the IP address, the tag and the cellular connection of the device.

In one aspect of the present disclosure, a method includes generating, by an access point (AP) associated with a network, a pseudo MAC address for a device attempting to establish a cellular connection via the access point based on a unique identifier of the device: obtaining an IP address for the device based on the pseudo MAC address, the IP address being used for mobility of the device across the network; obtaining a tag for the device from a network component associated with the network; and connecting the device to the network using the IP address, the tag and the cellular connection of the device.

In one aspect of the present disclosure, one or more non-transitory computer-readable medium have computer-readable instruction stored thereon, which when executed by one or more processors, cause the one or more processors to generate a pseudo MAC address for a device attempting to establish a cellular connection via the access point based on a unique identifier of the device: obtain an IP address for the device based on the pseudo MAC address, the IP address being used for tracking mobility of the device across the network; obtain a tag for the device from a network component associated with the network; connect the device to the network using the IP address, the tag and the cellular connection of the device; and after connecting the device to the network, managing the mobility of the device across the network using one of a first method or a second method based on whether the device is in an active state or an idle state.

The disclosed technology addresses the need in the art for integrating Long Term Evolution (LTE)/ Fifth Generation (<NUM>) traffic into a Digital Network Architecture (DNA) fabric of a network (e.g., a wireless network). Such integration may be made possible by introducing access points into the DNA fabric that support both cellular (LTE and/or <NUM>) as well as Wi-Fi network connectivity. Throughout this disclosure, such access points may be referred to as dual mode APs and/or dual wireless connection APs.

The disclosure begins with a description of an example network for integrating LTE/<NUM> traffic into an enterprise network fabric and description of several components thereof with reference to <FIG> and <FIG>.

<FIG> illustrates an example network, according to an aspect of the present disclosure. As shown in <FIG>, network <NUM> may be private enterprise network that includes a DNA fabric <NUM> or simply fabric <NUM>. While fabric <NUM> will be described in detail with reference to <FIG>, it can be formed of one or more edge nodes <NUM> (which may be also referred to as Locator/ID Separator Protocol (LISP) tunnel routers or xTRs <NUM>), a mapping server <NUM> (MAP server <NUM>), a Dynamic Host Configuration Protocol (DHCP) server <NUM> and an Identity Service Engine (ISE) <NUM>. Edge nodes <NUM> will be further described below with reference to <FIG>. MAP server <NUM> can record locator information (e.g., IP addresses) of connected devices and provide them to a requesting entity. MAP server <NUM> can be used to track mobility and movement of connected devices across enterprise network <NUM>. DHCP server <NUM> may be a network server that provides and assigns IP addresses, default gateways and other network parameters to connected devices such as loTs <NUM>. ISE <NUM> can be used for implementing network security policies across enterprise network <NUM>. ISE <NUM> can communicate network policies to ToTs <NUM> in the form of a Virtual Network ID (VNID) or a Security Group Tag (SGT).

While fabric <NUM> is shown as having edge nodes <NUM>, MAP server <NUM>. DHCP server <NUM> and ISE <NUM>, components of fabric <NUM> are not limited thereto and may include any other component necessary and/or ordinary to fabric <NUM>'s intended use and operation.

Network <NUM> can include one or more access points (APs) <NUM>. For purposes of the present disclosure, it is assumed that each of APs <NUM> can be a LTE and/or a <NUM> small cell. In one example, such APs <NUM> can have integrated Wi-Fi capabilities (and thus can be referred to as dual mode APs) that supports both cellular wireless connectivity and Wi-Fi connectivity to devices connected thereto. However, network <NUM> can also have Wi-Fi only APs. APs <NUM> can be any known or to be developed AP having LTE/<NUM> and Wi-Fi integrated capabilities such as those designed and manufactured by Cisco Technology, Inc. of San Jose, CA.

Network <NUM> can also include multiple mobile devices associated therewith. Such mobile devices can include any known or to be developed mobile phones, tablets, laptop computers, various wireless capable sensors, etc., and thus are collectively referred to as Internet of Things (IoT) devices <NUM> in <FIG>.

Within network <NUM>, fabric <NUM> (or in other words components thereof) can communicate with a <NUM>/LTE and/or a <NUM> packet core <NUM>. For example, if some of APs <NUM> are LTE and Wi-Fi integrated APs and other ones are <NUM> and Wi-Fi integrated APs, then fabric <NUM> communicates with both a <NUM>/LTE packet core and a <NUM> packet core, each of which will be further described below with reference to <FIG> and <FIG>, respectively. Communication between fabric <NUM> components and packet core <NUM> can be through internet <NUM>.

<FIG> illustrates an example of a fabric of network of <FIG>, according to an aspect of the present disclosure. In some examples, Network Environment <NUM> can include a Fabric <NUM> which can represent the physical layer or infrastructure (e.g., underlay) of the Network Environment <NUM>. Fabric <NUM> is an example of Fabric <NUM> of <FIG>. Fabric <NUM> can include Spines <NUM> (e.g., spine routers or switches) and Leafs <NUM> (e.g., leaf routers or switches, which can be the same as xTRs <NUM> of <FIG>) which can be interconnected for routing or switching traffic in the Fabric <NUM>. Spines <NUM> can interconnect Leafs <NUM> in the Fabric <NUM>. and Leafs <NUM> can connect the Fabric <NUM> to an overlay or logical portion of the Network Environment <NUM>, which can include application services, servers, virtual machines, containers, endpoints, etc. Thus, network connectivity in the Fabric <NUM> can flow from Spines <NUM> to Leafs <NUM>, and vice versa. The interconnections between Leafs <NUM> and Spines <NUM> can be redundant (e.g., multiple interconnections) to avoid a failure in routing. In some examples, Leafs <NUM> and Spines <NUM> can be fully connected, such that any given Leaf is connected to each of the Spines <NUM>. and any given Spine is connected to each of the Leafs <NUM>. Leafs <NUM> can be, for example, top-of-rack ("ToR") switches, aggregation switches, gateways, ingress and/or egress switches, provider edge devices, and/or any other type of routing or switching device.

Leafs <NUM> can be responsible for routing and/or bridging tenant or customer packets and applying network policies or rules. Network policies and rules can be driven by one or more Controllers <NUM> (which can be the same as ISE <NUM> of <FIG>), and/or implemented or enforced by one or more devices, such as Leafs <NUM>. Leafs <NUM> can connect other elements to the Fabric <NUM>. For example, Leafs <NUM> can connect Servers <NUM>. Hypervisors <NUM>. Virtual Machines (VMs) <NUM>, Applications <NUM>, Network Device <NUM>, etc., with Fabric <NUM>. Network device <NUM> can be the same as one of APs <NUM> having integrated Wi-Fi and LTE/<NUM> capabilities, which can connect IoT devices <NUM> to fabric <NUM>, packet core <NUM>, etc. Such elements can reside in one or more logical or virtual layers or networks, such as an overlay network. In some cases, Leafs <NUM> can encapsulate and decapsulate packets to and from such elements (e.g., Servers <NUM>) in order to enable communications throughout Network Environment <NUM> and Fabric <NUM>. Leafs <NUM> can also provide any other devices, services, tenants, or workloads with access to Fabric <NUM>.

Applications <NUM> can include software applications, services, containers, appliances, functions, service chains, etc. For example, Applications <NUM> can include a firewall, a database, a CDN server, an IDS/IPS, a deep packet inspection service, a message router, a virtual switch, etc. An application from Applications <NUM> can be distributed, chained, or hosted by multiple endpoints (e.g., Servers <NUM>. VMs <NUM>, etc.), or may run or execute entirely from a single endpoint.

VMs <NUM> can be virtual machines hosted by Hypervisors <NUM> or virtual machine managers running on Servers <NUM>. VMs <NUM> can include workloads running on a guest operating system on a respective server. Hypervisors <NUM> can provide a layer of software, firmware, and/or hardware that creates, manages, and/or runs the VMs <NUM>. Hypervisors <NUM> can allow VMs <NUM> to share hardware resources on Servers <NUM>. and the hardware resources on Servers <NUM> to appear as multiple, separate hardware platforms. Moreover, Hypervisors <NUM> on Servers <NUM> can host one or more VMs <NUM>.

Configurations in Network Environment <NUM> can be implemented at a logical level, a hardware level (e.g.. physical), and/or both. Such configurations can define rules, policies, priorities, protocols, attributes, objects, etc., for routing and/or classifying traffic in Network Environment <NUM>. For example, such configurations can define attributes and objects for classifying and processing traffic based on Endpoint Groups (EPGs), Security Groups (SGs), VM types, bridge domains (BDs), virtual routing and forwarding instances (VRFs), tenants, priorities, firewall rules, etc. Other example network objects and configurations are further described below. Traffic policies and rules can be enforced based on tags, attributes, or other characteristics of the traffic, such as protocols associated with the traffic, EPGs associated with the traffic, SGs associated with the traffic, network address information associated with the traffic, etc. Such policies and rules can be enforced by one or more elements in Network Environment <NUM>. such as Leafs <NUM>, Servers <NUM>, Hypervisors <NUM>. Controllers <NUM>, etc. As previously explained, Network Environment <NUM> can be configured according to one or more particular softwaredefined network (SDN) solutions, such as, but not limited to, CISCO ACI or VMWARE NSX.

<FIG> illustrates an example of an LTE packet core, according to an aspect of the present disclosure.

Packet core <NUM> of <FIG> can include one or more components for registering devices (e.g., a mobile device that can be one of IoTs <NUM>) with a corresponding cellular network, when the mobile and the associated AP <NUM> is a LTE small cell with integrated Wi-Fi capabilities. These components include, but are not limited to. Mobility Management Entity (MME) <NUM>, Home Subscriber Server (HSS) <NUM>, Serving Gateway, Packet Data Network Gateway <NUM> (SGW/PGW, which may collectively be referred to as GW <NUM>), Authentication, Authorization and Accounting (AAA) component <NUM>, a Dynamic Network Access Control (DNAC) component <NUM> for managing LTE/<NUM> APs, and/or any other known, or to be developed, component that is part of core network <NUM> for routine functioning of a <NUM>/LTE packet core. Functionalities of MME <NUM>, HSS <NUM>, GW <NUM> and AAA <NUM> are known to those skilled in the art and for the sake of brevity, will be omitted.

<FIG> illustrates an example of a <NUM> packet core, according to an aspect of the present disclosure. In example of <FIG>, core network <NUM> is a <NUM> core network having logical components. Example components include various network functions implemented via one or more dedicated and/or distributed servers (can be cloud based). <NUM> core network <NUM> can be highly flexible, modular and scalable. It can include many functions including network slicing. It offers distributed cloud-based functionalities. Network functions virtualization (NFV) and Software Defined Networking (SDN).

For example and as shown in <FIG>, core network <NUM> has Application and Mobility Management Function (AMF) <NUM> and bus <NUM> connecting various servers providing different example functionalities. For example, bus <NUM> can connect AMF <NUM> to Network Slice Selection Function (NSSF) <NUM>, Network Exposure Function (NEF) <NUM>, Network Repository Function (NRF) <NUM>, Unified Data Control (UDC) <NUM>, which itself can include example functions including Unified Data Management (UDM) <NUM>, Authentication Server Function (AUSF) <NUM>, Policy Control Function (PCF) <NUM>, Application Function (AF) <NUM> and Session Management Function (SMF) <NUM>. Various components of core network <NUM>, examples of which are described above, provide known or to be developed functionalities for operation of <NUM> networks including, but not limited to, device registration, attachment and authentication, implementing network policies, billing policies, etc..

Furthermore, as shown in <FIG>, SMF <NUM> is connected to User Plane Function (UPF) <NUM>. which in turns connects core network <NUM> and one or more of IoTs <NUM> via network <NUM>.

While <FIG> illustrates an example structure and components of core network <NUM>, the present disclosure is not limited thereto. Core network <NUM> can include any other number of known or to be developed logical functions and components and/or can have other known or to be developed architecture.

Furthermore, core network <NUM> can have a centralized Self Organizing Network (CSON) function/server <NUM> connected to AMF <NUM>. CSON server <NUM> can have a dedicated server for performing functionalities thereof (e.g., management of device registrations, load balancing, integrated access backhaul, etc.).

Having described various examples of network <NUM> and one or more elements thereof with reference to <FIG>, the disclosure now turns to describing example embodiments directed to managing client/device (e.g., one or more of IoTs <NUM>) onboarding, mobility while active and mobility while idle scenarios.

<FIG> illustrate methods of traffic management in a LTE/<NUM> integrated enterprise network; according to an aspect of the present disclosure. <FIG> will be described from the perspective of any one of LTE/<NUM> APs <NUM>. While <FIG> is described from the perspective of an LTE/<NUM> AP, it will be understood that such AP has one or more processors that are configured to execute computer-readable instructions stored on one or more associated memories to perform functionalities described with reference to <FIG>. Furthermore, with reference to <FIG>, a mobile device as an example of IoTs <NUM> will be used for reference that may join network <NUM>, move across network <NUM> while active or move across network <NUM> while idle. Such mobile device is assumed to be capable of establishing both a cellular connection (LTE and/or <NUM> connection) with core network <NUM> and a Wi-Fi (or any other wireless based connection) to network <NUM> via fabric <NUM>.

<FIG> illustrates an example method of onboarding a LTE/<NUM> device in the network of <FIG>, according to an aspect of the present disclosure. Per <FIG>, at S400, AP <NUM> facilitates authentication and attachment of a mobile device to core network <NUM> (establishes a connection between the mobile device and core network <NUM>). This authentication and attachment procedure may be performed with appropriate components of core network <NUM> such as with MME <NUM> and/or HSS <NUM> of core network <NUM> (for LTE cases) and/or AMF <NUM> (for <NUM> cases). As part of this facilitation at S400, AP <NUM> also provides its own IP address to core network <NUM> such that MME <NUM>, for example, may select AP <NUM> as mobile device's local gateway for the mobile device's Packet Data Network (PDN) connection.

Furthermore, At S400, AP <NUM> generates a pseudo MAC address for the mobile device in order to obtain an IP address for the mobile device. An LTE/<NUM> device does not have an IP address and thus the pseudo MAC address will be used to obtain an IP address the mobile device from DHCP server <NUM>. The DHCP server may be part of fabric <NUM> or core network <NUM>. In one example, the pseudo MAC address will be generated using any known or to be developed method including, but not limited to using identity unique to the mobile device, which maybe the International Mobile Subscriber Identity (IMSI) or Globally Unique Temporary Identity (GUTI), or based on pseudo-MAC ranges that are made available to the AP <NUM> (e.g., based on configuration from the DNAC). Once the mobile device is authenticated, the MME <NUM>/AMF <NUM> may provide the mobile device's permanent identity (which may be the IMSI or the IMEI of the mobile device) to the AP <NUM>, which enables the AP <NUM> to generate the pseudo-MAC address for the mobile device.

At S402, AP <NUM> determines if the authentication and attachment process of S400 for the mobile device has been successful. If not, the process ends at S403 and optionally a corresponding notification may be generated and sent to the mobile device by AP <NUM>.

If successful, then at S404, AP <NUM> obtains a tag for the mobile device from ISE <NUM>. The tag may include information indicative of the fact that the mobile device is a LTE and/or a <NUM> device for security classifications and designation. Therefore, it may be referred to as a security tag as well.

Thereafter, at S406, AP <NUM> updates MAP server <NUM> of fabric <NUM> with the IP address and/or the tag for the mobile device. In one example, updating MAP server <NUM> may be performed using L2/L3 tunneling. In one example, there may be other instances where AP <NUM> updates MAP server <NUM>. For example, when AP <NUM> times out or when the mobile device leaves network <NUM>. AP <NUM> updates MAP server <NUM> to remove mobile device's entry from its record.

Thereafter, at S408, AP <NUM> connects the mobile device to fabric <NUM>/network <NUM>, on which the mobile device can roam using its cellular connection, the assigned IP address and the tag. Accordingly, cellular traffic of the mobile device can be integrated into fabric <NUM> of network <NUM>, turning network <NUM> into a LTE/<NUM> integrated enterprise network.

At this point, the mobile device can roam on network <NUM> using it's LTE/<NUM> connection while fabric <NUM> can implement its security measures to the mobile device since it is aware of the presence of the LTE/<NUM> mobile device through MAP server <NUM>.

Having described examples for onboarding a mobile device onto a LTE/<NUM> integrated network, hereinafter examples will be described for handling mobility of the mobile device across network <NUM> while the mobile device is active. For example, an active mobile device may switch roaming from one AP <NUM> (source AP) to another AP <NUM> (destination AP). In this scenario, it is assumed that the source AP <NUM> has the IP address and the tag obtained for the mobile per the process of <FIG>.

<FIG> illustrates an example method of managing active mobility of a LTE/<NUM> device in the network of <FIG>. according to an aspect of the present disclosure. Per <FIG>, at S410, source AP <NUM> performs a handover process for handing the mobile device to a new AP <NUM> (destination AP). This handover process can be an X2 handover process. As part of this X2 handover, source AP <NUM> sends the tag for the mobile device to the destination AP <NUM> as well as mobile device's IP address and any other additional context.

At S412, destination AP <NUM> updates MAP server <NUM> with the handover process to indicate that the mobile device now roams on destination AP <NUM>.

At S414, destination AP <NUM> also updates MME <NUM> (for LTE cases) or AMF <NUM> (for <NUM> cases) in packet core <NUM> to indicate that the mobile device has moved to the destination AP <NUM>. In one example, updating MME <NUM> (or AMF <NUM>) may be performed because any subsequent move of the mobile device from the destination AP <NUM> to another AP depends on information provided by MME <NUM> (or AMF <NUM>) to the destination AP <NUM>.

<FIG> describes handling mobility of active mobile devices across LTE/<NUM> integrated networks. <FIG> illustrates an example method of managing idle mobility of a LTF/<NUM> device in the network of <FIG>, according to an aspect of the present disclosure. In describing <FIG>, references will be made to old AP <NUM> and new AP <NUM>. Old AP <NUM> may refer to the last AP <NUM> within network <NUM> on which the mobile device transitioned from an active state to an idle state, while the new AP <NUM> may refer to a current/latest AP <NUM> on which the mobile device has transitioned from the idle state back to the active state.

at S420, old AP <NUM> determines if the mobile device is idle. In one example, old AP <NUM> (which is the one currently serving the mobile device) determines if there has been no data exchange with the mobile device for a threshold period of time. The threshold period of time is a configurable parameter that may be determined based on experiments and/or empirical studies. If such threshold period of time has passed since last data exchange with the mobile device, old AP <NUM> determines that the mobile device is idle.

Upon determining that old AP <NUM> is idle at S420, at S422, old AP <NUM> releases a Radio Resource Control (RRC) message to the mobile device.

At S424, old AP <NUM> sends a S1-release message to MME <NUM> (or AMF <NUM>). old AP <NUM> may release, as part of the S1-release message, mobile device's IP address, tag (described with reference to <FIG>) and mobile device's pseudo MAC address to MME <NUM> (or AMF <NUM>). In one example, old AP <NUM> does not update MAP server <NUM> at this stage.

Thereafter, the mobile device may transition to an active state by sending a packet. However, the mobile device sends this service request to a new AP <NUM>, which is indicative that the mobile device has moved from being served by old AP <NUM> to new AP <NUM>.

At S426, new AP <NUM> receives a service request from the mobile device to transition to an active state.

At S428, new AP <NUM> sends the service request to MME <NUM> (or AMF <NUM>) at core network <NUM>.

At S430, new AP <NUM>, receives from MME <NUM> (or AMF <NUM>) the mobile device's context including, but not limited to, the mobile device's IP address, tag and Ethernet address (received from old AP at S424).

Using the received context, at S432, new AP <NUM> setups data radio bearers to the mobile device to set up mobile device's PDN connection for connecting the mobile device to network <NUM> and also updates MAP server <NUM> to reflect that the mobile device has moved to new AP <NUM>.

In describing S426 to S432, reference was made to a mobile device initiated transition from idle mode (idle state) to active mode (active state). However, in another example, the transition may be network based. In such case downlink packet may be received to old AP <NUM>. In response, old AP <NUM> may send a "downlink data notification" to MME <NUM> (or AMF <NUM>). In response, MME <NUM> (or AMF <NUM>) may page to APs <NUM> in network <NUM> and associated with fabric <NUM> (assuming that the Tracking area ID of all APs <NUM> associated with fabric <NUM>) is the same. Thereafter, the mobile device may respond to new AP <NUM>, in response to which the new AP <NUM> sets up the radio bears and updates MAP server <NUM>, per S432.

In describing <FIG>. and for situations involving mobility of a mobile device within network <NUM>, at least two APs <NUM> are involved. However, in an alternative example, fabric <NUM> may include a "centralized controller" that carries out functionalities described above with reference to <FIG>for managing all aspects of a device mobility (onboarding, mobility while active and mobility while idle) within LTE/<NUM> integrated fabric <NUM> of network <NUM>.

The disclosure now turns to <FIG> and <FIG>, which illustrate example network devices and computing devices that may be implemented as one or more components of network <NUM> described above including, but not limited to, any one of APs <NUM>, MAP server <NUM>. MME <NUM>, etc..

<FIG> illustrates computing system architecture for use in network of <FIG>, according to an aspect of the present disclosure. Computing system architecture <NUM> has components that are in electrical communication with each other using a connection <NUM>, such as a bus. Exemplary system <NUM> includes a processing unit (CPU or processor) <NUM> and a system connection <NUM> that couples various system components including the system memory <NUM>, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, to the processor <NUM>. The system <NUM> can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor <NUM>. The system <NUM> can copy data from the memory <NUM> and/or the storage device <NUM> to the cache <NUM> for quick access by the processor <NUM>. In this way, the cache can provide a performance boost that avoids processor <NUM> delays while waiting for data. These and other modules can control or be configured to control the processor <NUM> to perform various actions. Other system memory <NUM> may be available for use as well. The memory <NUM> can include multiple different types of memory with different performance characteristics. The processor <NUM> can include any general purpose processor and a hardware or software service, such as service <NUM><NUM>, service <NUM><NUM>. and service <NUM><NUM> stored in storage device <NUM>. configured to control the processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor <NUM> may be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing device <NUM>, an input device <NUM> can represent any number of input mechanisms, such as a microphone for speech. a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input. speech and so forth. An output device <NUM> can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing device <NUM>. The communications interface <NUM> can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

The storage device <NUM> can include services <NUM>, <NUM>, <NUM> for controlling the processor <NUM>. Other hardware or software modules are contemplated. The storage device <NUM> can be connected to the system connection <NUM>. In one aspect. a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor <NUM>. connection <NUM>, output device <NUM>, and so forth. to carry out the function.

<FIG> illustrates an example network device suitable for performing switching, routing. load balancing, and other networking operations, according to an aspect of the present disclosure. Network device <NUM> includes a central processing unit (CPU) <NUM>, interfaces <NUM>, and a bus <NUM> (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU <NUM> is responsible for executing packet management. error detection, and/or routing functions. The CPU <NUM> preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU <NUM> may include one or more processors <NUM>, such as a processor from the INTEL X86 family of microprocessors. In some cases. processor <NUM> can be specially designed hardware for controlling the operations of network device <NUM>. In some cases, a memory <NUM> (e.g.. non-volatile RAM. ROM, etc.) also forms part of CPU <NUM>. However, there are many different ways in which memory could be coupled to the system.

The interfaces <NUM> are typically provided as modular interface cards (sometimes referred to as "line cards"). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device <NUM>. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces. Ethernet interfaces. Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, Wi-Fi interfaces, <NUM>/<NUM>/<NUM> cellular interfaces, CAN BUS, LoRA, and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control, signal processing, crypto processing, and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor <NUM> to efficiently perform routing computations, network diagnostics, security functions, etc..

Although the system shown in <FIG> is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc., is often used. Further, other types of interfaces and media could also be used with the network device <NUM>.

Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory <NUM>) contigured to store program instructions for the general-purpose network operations and mechanisms for roaming. route optimization and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications. for example.

The network device <NUM> can also include an application-specific integrated circuit (ASIC), which can be configured to perform routing and/or switching operations. The ASIC can communicate with other components in the network device <NUM> via the bus <NUM>, to exchange data and signals and coordinate various types of operations by the network device <NUM>, such as routing, switching, and/or data storage operations, for example.

For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components. steps or routines in a method embodied in software, or combinations of hardware and software.

Claim 1:
An access point (<NUM>), AP, of a network (<NUM>), the AP being configured to provide cellular connection and Wi-Fi connection capabilities for a device (<NUM>) and configured to:
generate (S400) a pseudo Media Access Control, MAC, address for the device, which has established a Wi-Fi connection to the network and is attempting to establish a cellular connection to a core network (<NUM>) via the access point, based on a unique identifier of the device;
obtain (S400), from a Dynamic Host Configuration Protocol, DHCP, server (<NUM>) of a Digital Network Architecture, DNA, fabric (<NUM>) of the network, an Internet Protocol, IP, address for the device based on the pseudo MAC address, the IP address being used for tracking mobility of the device across the network;
obtain (S404), from an Identity Service Engine (<NUM>), ISE, of the DNA fabric of the network, a security tag for the device, wherein the security tag is for applying one or more security configurations of the network to the device while the device is using the cellular connection;
update (S406) a mapping server (<NUM>) of the DNA fabric of the network with the IP address and/or the tag for the device; and
connect (S408) the device to the DNA fabric of the network using the IP address, the security tag and the cellular connection of the device and allow the device to roam on the network using the cellular connection while the DNA fabric implements its security measures to the device,wherein the DNA fabric is part of an enterprise network that enables a distributed data place with a centralized control plane.