Patent Description:
The claimed invention is related to a method and a non-transitory computer readable medium for providing network services at a location. In particular, responsive to a mobile services engine or a virtual baseband engine receiving a call to a predefined emergency number from a user device, an emergency state of the user device is forced by the mobile services engine or the virtual baseband engine. First information that includes location information corresponding to the location of the user device is obtained and the mobile services engine pushes the first information to a public safety answering point.

Demands for end-user cellular mobile performance, also known as Mobile Broadband ("MBB"), are expected to increase by factors of <NUM> over the next <NUM> years with MBB connections expected to reach nearly <NUM> billion by <NUM>. The forecast for these demands are concentrated on areas where there are high-densities of people, especially of an affluent enough nature that they are utilizing the latest in mobile devices (smartphones and similar user equipment). In addition to humans, an influx of embedded wireless radios within a wide array of machines and personal devices (cars, appliances, etc.) will further increase demands, this outgrowth is known as Internet of Things (IoT) or Machine to Machine (M2M) and is anticipated to <NUM> billion connected devices on the global networks by <NUM>. Bandwidth-consuming applications, including video communications and streaming of broadcast quality video, may push the demand for bits-per-second on a per user basis. As a result, the utilization of available, shared spectrum is critical - requiring a higher quantity of smaller-sized cells that can support larger quantities of users while delivering increases in each user's performance.

Small cell technology set out to address this growth. However, the nature of most small cells is such that they tend to have limitations in signal delivery, require many to cover an area, are limited in their ability to support an influx of active users, and create interference with each other, which reduces performance at many areas of cell edges resulting in users' devices being in a soft handover state often as user moves from one small cell coverage area to another - and often all of these transitions (handovers) require orchestration back to the core network, further complicating the solution. Add to this the fact that at each small cell requires backhaul considerations to each devices, typically demanding a dedicated network installed to assure capacity and security - a costly method to deliver. The results from all these factors is it has relegated small cells to be most suitable in very small office facilities.

Distributed antenna systems (DAS), in contrast, are exceptional at delivering balanced signal across medium and larger facilities. Unlike Small Cell technology, a DAS acts can either look like a single cell or smaller number of cells that do not require as many cellular-protocol handoffs when a user moves from one DAS antenna coverage area to another. Even when multiple cells are applied the ability to fine tune signal edges allows the RF design for a building to provide much better overall performance for users. They may combine radios with different power classes to optimize coverage, can be used to provide multiple-bearer paths to increase performance, and may carry multiple bands across multiple carriers to deliver multi-operator service within facilities. Conventionally, they are completely transparent to end users on the system and are dependent on traditional baseband processors (called BBUs or BaseBand Units) and their surrounding control infrastructure to "Roam" users from one cell to another. BBUs are the components that carry voice and/or data between a user's cellphone and the core cellular wireless network (e.g., ATT's network or Verizon's network). In some systems, the BBU is a component of an eNodeB, which may also include a radio head. Conventional BBUs have no knowledge that they are on a DAS system, and thus they depend on the DAS to remain transparent, minimizing any extracurricular delays, and in many aspects maintaining its transparency. The conventional DAS and BBU function to provide capabilities, but they suffer drawbacks and deficiencies because they essentially ignore that each other exists.

<CIT> discloses a method for providing network services at a location, the method comprising: enabling an interface for providing information associated with a user device; registering an application with the interface, wherein the application provides one or more services to the user device based at least partially on the information; receiving first information associated with the user device, wherein the first information comprises one or more of identification information of the user device and state information of the user device; and pushing, via the interface, the first information to the application.

<CIT> is directed to a two-factor authentication system that grants or prevents network access to a facility based on an identification associated with the device and a physical presence of the user in a facility (e.g., determined using a key card reader).

Various features of the implementations can be more fully appreciated, as the same become better understood with reference to the following detailed description of the implementations when considered in connection with the accompanying figures, in which:.

For simplicity and illustrative purposes, the principles of the present teachings are described by referring mainly to examples of various implementations thereof. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented in, all types of information and systems, and that any such variations do not depart from the true spirit and scope of the present teachings. Moreover, in the following detailed description, references are made to the accompanying figures, which illustrate specific examples of various implementations. Electrical, mechanical, logical and structural changes can be made to the examples of the various implementations without departing from the spirit and scope of the present teachings. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present teachings is defined by the appended claims and their equivalents.

<FIG> is a generic diagram that illustrates an example of a location <NUM>, which can be provided with integrated network services, according to various implementations. While <FIG> illustrates various components contained in the location <NUM> and coupled to the location <NUM>, <FIG> illustrates one example and additional components can be added and existing components can be removed.

The location <NUM> can be any type of geographic location, building, house, etc. in which integrated network services can be provided, as described herein. For example, the location <NUM> can be an office building of a corporation, an apartment building, a multi-dwelling residence, a government building, a city block, a park etc. The location <NUM> can include a mobile services engine (MSE) <NUM>. The MSE <NUM> can be configured to coordinate, track, and facilitate network communications internal and external for the location <NUM>. The MSE <NUM> can be configured to coordinate, track, and facilitate communications between networks, computer system, user devices, etc. located internally within the location <NUM>. Likewise, the MSE <NUM> can be configured to coordinate, track, and facilitate communications between networks, computer system, user devices, etc. located internally within the location <NUM> and networks, computer system, user devices, etc. located externally from the location <NUM>. Additionally, the MSE <NUM> can provide a set of applications programming interfaces (API) for services provided to the location <NUM>, for example, from internal application services or external application services.

In implementations, the MSE <NUM> can be implemented as software, hardware, or combination thereof. When implemented as software, the MSE <NUM> can be executed on one or more computer systems, whether virtual, physical, or combinations thereof. For example, physical computer systems can include conventional computer systems, such as those data centers, servers, etc. The physical computer systems can include hardware resources, such as processors, memory, network hardware, storage devices, and the like, and software resources, such as OS, application programs, and the like. Likewise, for example, the virtual computer systems can include virtual machines, cloud computing environments, etc. When implemented as software, the MSE <NUM> can be written utilizing a variety of programming languages, such as JAVA, C, C++, Python code, hypertext markup language (HTML), extensible markup language (XML), and the like to accommodate a variety of operating systems, computing system architectures, APIs, etc..

The MSE <NUM> can be configured to provide an interface for and to negotiate network communications for a local mobile network <NUM>. The local mobile network <NUM> can include one or more virtual baseband engines (VBEs) <NUM> and one or more radio frequency (RF) distribution platforms <NUM>. The local mobile network <NUM> can provide service to one or more user devices (UEs) <NUM> within the location <NUM>. The VBE can provide one or more baseband units (BBUs) to support and control mobile communications with the RF distribution platforms <NUM>. The VBEs <NUM> can be implemented a software, hardware, or combination thereof, as discussed below. For example, when implemented as software, the VBEs <NUM> can be executed on one or more computer systems, whether virtual, physical, or combinations thereof. For example, physical computer systems can include conventional computer systems, such as servers used within data centers, etc. The physical computer systems can include hardware resources, such as processors, memory, network hardware, storage devices, and the like, and software resources, such as OS, application programs, and the like. Likewise, for example, the virtual computer systems can include virtual machines, cloud computing environments, etc. When implemented as software, the MSE <NUM> can be written in a variety of programming languages, such JAVA, C, C++, Python code, hypertext markup language (HTML), extensible markup language (XML), and the like to accommodate a variety of operating systems, computing system architectures, etc. The RF distribution platforms <NUM> can be any type of radio/antenna platform such as a distributed antenna system (DAS), a remote radio head (RRH), and the like. The RF distribution platforms <NUM> can be implemented using software, hardware, or combination thereof, as discussed below.

The UEs <NUM> can be any type of computer systems and devices that are capable of communicating with the local mobile network <NUM> and/or any other network, internal or external, to the location <NUM>. For example, the UEs <NUM> can include telephones, mobile phones, laptop computer, server computers, tablet computers, smart appliances, IoT devices, and the like.

In implementations, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can store, keep track of, and/or otherwise monitor the distribution (e.g., location) of remote radios and antennas in the RF distributions platforms <NUM>, and can identify, monitor, and/or otherwise determine the UEs <NUM> locations in relation to each radio/antenna of the RF distributions platforms <NUM>. Using this intelligence information, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can dynamically optimize the allocation of available BBU resources to best serve the location <NUM>. Because the local mobile network <NUM> can operate as a finely tuned and single system, utilizing one or more wireless technologies and thus maximizing the end user throughput at any point or points across the system.

For example, if location <NUM> is a venue, such as a football stadium, which is covered by a DAS, the local mobile network <NUM> can be a single cell covered by multiple antennas of the DAS. In this example, during the second quarter, one of the end-zone sections of the stadium seating can be covered by one specific antenna of the multiple DAS antennas throughout the stadium, and there can be <NUM> users (e.g., cellphones) being served by that antenna. At the same time, another antenna in a concourse area of the stadium can be serving <NUM> users because most people are in their seats and the concourse is lightly occupied. When halftime arrives, most of the users in the end-zone section, as well as from other sections, can crowd into the formerly lightly occupied concourse section, such that the antenna serving the concourse area now has <NUM> users, while the antenna serving the end-zone section now has only <NUM> users because all the others have moved elsewhere. In this example, VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can sense a change in user numbers in the end-zone section antenna and in the concourse-area antenna, and react by reallocating cellular resources (e.g., BBU resources) from serving the end-zone section antenna to serving the concourse-area antenna, thus improving the network performance for the users in the concourse-area. In various implementations, this dynamic, situation-responsive functionality can be achieved by the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>), which determines where BBU resources are needed within a venue or other area covered by a local mobile network <NUM> and moves, reassigns, or otherwise reallocates BBU resources to meet the current needs.

In implementations, the MSE <NUM> can be configured to provide an interface for and to negotiate communication between the location <NUM> and one or more external networks <NUM>. The one or more external networks <NUM> can be any type of network that utilizes any type of communication protocols or processes. For example, the one or more external networks <NUM> can be mobile carrier networks (also referred to as mobile operator network), Internet Protocol (IP) based network, and the like. The MSE <NUM> can be configured to transparently control and negotiate communications between systems and devices and the one or more external networks <NUM>, as discussed further below. The MSE <NUM> can also be configured to provide one or more interfaces, e.g. application programming interfaces (APIs), to services provided by the one or more external networks <NUM>, as discussed further below.

In implementations, the MSE <NUM> can be configured to provide an interface for and to negotiate communications with one or more internal networks <NUM>. The one or more internal networks <NUM> can be any type of network that utilizes any type of communication protocols or processes. For example, the one or more internal networks <NUM> can be or include wireless access point (WAPs), trusted local area networks (LANs), untrusted LANs, and the like. The MSE <NUM> can be configured to transparently control and negotiate communications between systems and devices and the one or more internal networks <NUM>, as discussed further below. The MSE <NUM> can also be configured to provide one or more interfaces, e.g. APIs, to services provided by the one or more internal networks <NUM>, as discussed further below.

In implementations, the MSE <NUM> can be configured to provide an interface for and to negotiate communication with one or more application services <NUM>. For example, the MSE <NUM> can provide an APIs for the application services. The application services <NUM> can be any type of application, functionality, and the like, which can be utilized in the location <NUM>, as described below.

For example, as noted above, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can store or otherwise keep track of the location of each remote radio and antenna in the RF distributions platforms <NUM>. In some implementations, the MSE <NUM> can use the radio/antenna-location intelligence information to identify the location of UEs <NUM> within the area covered by the local mobile network <NUM>, and employ intelligence through other means, such as Wireless Access Point beacons, Bluetooth Beacons, to effectively and in combination utilize proximity and triangulation techniques to achieve user-device location to enable various applications, such as user-device map applications that show a user's current location within a venue and provide directions for the user to follow to arrive at a different location, such as a specific seat, room, meeting, shop, restaurant or the like. Similarly, the determined user-device location can be employed by <NUM> applications to report the location of the use making a <NUM> call, or otherwise employed by similar emergency applications. Where and when further enabled by emerging UE standards a <NUM> call by a user or other emergency state within a location can allow for the MSE and/or VBEs to force an emergency state of the UE, enabling all radios in the UE device, including cellular, Wi-Fi, and Bluetooth technologies, to optimize location intelligence to the benefit of users in an emergency state.

In implementations, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) are configured to provide solutions targeted at a location <NUM>, such as corporate centers or university campuses, that have the ability to roam UEs <NUM> onto and within the location <NUM>. In some embodiments, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can handover the UEs <NUM> using standard inter-RAT and intra-RAT handoff methodologies to enable transparent transitions into and out of serving areas, including to legacy networks outside of the pseudo-private system. As a result, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) allows secure access to local private IP networks that can be affiliated with the location <NUM>.

In some implementations, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can intelligently identify qualified UEs to utilize the networks and systems of the location <NUM>, whereby the VBE <NUM> (and/or MSE <NUM>) can implement a Closed Subscriber Group, which shall limit which LTEs are allowed to handover to the location <NUM> based on policies set forth by a configuration of the system, and can also apply special data routing policies to individual UEs <NUM> to enable users to access various networks and data resources of the location <NUM>, such as: the internet, the operator's IP-core network for things such as high definition voice and video calls or IP Multimedia Subsystem (IMS) services, or local IP network to the location <NUM>, such as internal file stores, databases, and other tools accessible via a secure connection to UEs <NUM>. For example, consider a venue such a corporate campus that is served by an implementation of location <NUM>. In such a venue, it is desirable to enable employees of the corporation to connect to and access data in the corporation's computers or intranet, while denying such connectivity and access to visitors on the campus who are not corporate employees. In this example, the system identifies the UEs <NUM> of corporate employees that connect via cellular means to the local mobile network <NUM>, and allow those UEs <NUM> to access the corporation's computers according to the routing policies for corporate employees. Similarly, the system identifies the UEs <NUM> of visitors (i.e., non-corporate employees) that connect via local mobile network <NUM>, and prevent those UEs <NUM> from accessing the corporation's computers. In addition to access rights, the policy can also specify other features or resources to supply or deny to UEs <NUM>, such as an amount of bandwidth, fees for access, and the like.

In some implementations, the special data routing policies can allow access to industrial, Internet of Things (IoT), and Machine to Machine (M2M) environments. For example, the VBEs <NUM> and the RF distributions platforms <NUM> implementing the local mobile network <NUM> (and/or the MSE <NUM>) can provide various communication functions and utility, such as allowing LTE-modem-embedded shipping pallets with localized radio frequency identification (RFID) tagging, which identifies the items on the pallet, to connect and communicate to internal systems as the pallets move through a factory and into shipping trucks.

While <FIG>. illustrates one MSE <NUM>, the location <NUM> can include multiple instances of the MSE <NUM>. For example, multiple instances of the MSE <NUM> to communicate with different local mobile networks <NUM>, different external networks <NUM>, different internal networks <NUM>, different application services <NUM>, and the like.

<FIG> is a diagram that illustrates a more detailed example of the location <NUM>, which can be provided with integrated network services, according to various implementations. While <FIG> illustrates various components contained in the location <NUM> and coupled to the location <NUM>, <FIG> illustrates one example and additional components can be added and existing components can be removed.

As illustrated in <FIG>, the local mobile network <NUM> can include a DAS <NUM> coupled to the VBEs <NUM>. For example, the VBEs <NUM> can be coupled to the DAS <NUM> via a digital interface, such as a common public radio interface (CPRI) interface <NUM>.

The local mobile network <NUM> can include one or more additional small cell systems <NUM> coupled the VBEs <NUM>. For example, small cell systems <NUM> can include existing hardware such as donor antennas, EnodeB's, small cells, and the like as additional RF sources as well as incorporating the BBU (VBEs <NUM>) technology, for example. Inputs from these devices can be <NUM>, <NUM>, <NUM>, public safety, etc. radio frequency and are agnostic to the carrier frequency, manufacturer and/or type of equipment. Accordingly, the local mobile network <NUM> can utilize existing network infrastructure to IP-based, managed systems, e.g., while continuing to capitalize on at least some previously-implemented hardware, software, etc..

The VBEs <NUM> can be configured to coordinate and control mobile communication with the local mobile network <NUM>. The VBEs <NUM> can gather intelligence information about the DAS <NUM> usage by users and the current system resources (e.g., BBU resources), and use that intelligence information to reallocate system resources to better serve the current users, for example, UEs. The intelligence information can include information regarding the identity, service capabilities for (e.g., type of device, its LTE capabilities, ability to offer Voice over LTE, multi-path radio capabilities, etc.), and location of user equipment (e.g., smartphones or IoT devices) and user-equipment sessions that are wirelessly connected to (e.g., roamed onto) the DAS <NUM> and each specific sub-element of the DAS <NUM> (e.g., each antenna, remote radio unit, coverage area, and the like). The VBEs <NUM> can collect and store information about the amount, capacity, and current allocation of BBU resources, across pools of BBU processors, which can be rack units, and have knowledge of available baseband frequencies, frequency bands, power output, bandwidth, sessions, channels, processing cycles or time, digital signal processing capacity, registered and active users or devices, device types, and the like.

The location <NUM> includes a switch <NUM>, whereby such switch can be an externally programmable device or an integral element of the MSE. For example, the switch <NUM> can be an independent software defined networking (SDN) switch. The switch <NUM> can be dynamically configured by the MSE to setup certain packet level routing paths for network communication between systems and devices within the location <NUM>, for example, the local mobile network <NUM>, a local area network <NUM>, and wireless access points (WAPs) <NUM>, and networks external to the location <NUM>, for example, internet service provider (ISP) networks <NUM> and mobile carrier networks <NUM>.

In implementations, the MSE l02 can be configured to communicate with the VBEs <NUM> and a switch or switches <NUM>. The MSE <NUM> can be configured to transparently negotiate and control the network communication handled by the VBEs <NUM> and the switch <NUM> as discussed further below. Additionally, the MSE <NUM> can be configured to collect, store, and utilize data and intelligence information from the VBEs <NUM>.

In implementations, the MSE <NUM> can be configured to include a network functions virtualization (NFV) interface <NUM>. For example, the NFV interface <NUM> can be one or more APIs that enable functionality of one or more NFV proxies and/or middleware <NUM>. In some implementations, the NFV interface <NUM> can be utilized by the MSE <NUM> and the NFV proxies and middleware <NUM> to implement evolved packet core (EPC) functions <NUM>, for communication over network standards, such as 3GPP LTE wireless communication standard. For example, the EPC functions <NUM> can include certain information for the registration and policies of UEs, mobile handoff coordination of UEs, authentication of UEs, certain services enabled or allowed by a UE and related policies to be applied, packet redirection internally, externally, or both for location <NUM>, and the like. The MSE <NUM> can be configured to implement and communicate via the NFV interface <NUM> using any type of protocol, for example, JAVA script object notation (JSON), XML, and the like.

In implementations, the MSE <NUM> can be configured to include an enterprise function virtualization (EFV) interface <NUM>. For example, the EFV interface <NUM> can be one or more APIs that enable functionality of one or more EFV middleware <NUM> and one or more enterprise application <NUM>. In some implementations, the EFV interface <NUM> can be utilized by the MSE <NUM>, EFV middleware <NUM>, and enterprise application <NUM> to implement application services within the location <NUM>, as discussed further below. For example, the application services can include packet redirection internally, externally, or both for location <NUM>, policy control for the location <NUM>, emergency services for the location <NUM>, enhance user experience at location <NUM>, and the like. The MSE <NUM> can be configured to implement and communicate via the EFV interface <NUM> using any type of protocol, for example, JAVA script object notation (JSON), XML, and the like.

<FIG> are diagrams that illustrates an example of the local mobile network, for example local mobile network <NUM>, according to various implementations. While <FIG> illustrate various components contained in the local mobile network and coupled to the local mobile network, <FIG> illustrate one example and additional components can be added and existing components can be removed.

As illustrated in <FIG>, globally indicated with reference number <NUM> is a system for the distribution of wireless signals in telecommunication networks, for example, the local mobile network <NUM> in the location <NUM>, particularly for providing a baseband unit (BBU) functionally integrated with a distributed antenna system (DAS). In some implementations, the system <NUM> can provide greater flexibility, modularity and future-proof architectures, by implementing the following features:.

In this way, the system <NUM> can provide a solution for the realization of the base stations that are innovative from the economic point of view (cost reduction and economies of scale), from an engineering point of view (computational and dynamic utilization efficiency) and from the environmental point of view (efficiency and energy saving).

As shown schematically in <FIG>, the system <NUM> includes two blocks <NUM> and <NUM> closed in the dotted rectangle and related to the base station BTS (or BBU or eNodeB depending on the technology used, i.e., <NUM>, <NUM>, <NUM>) and the Point Of Interface (POI) of a DAS system. In some examples, the system <NUM> can be easily integrated into the conventional structures of a DAS. In some implementations, the system <NUM> can be partially integrated with the DAS and operatively connected with the conventional master unit <NUM> of the DAS itself. The master unit <NUM> can be connected through an optical fiber connection to a remote unit <NUM>. The master unit <NUM> can perform an RF-to-optical conversion and vice versa, while the remote unit <NUM> can perform signal amplification and optical-to-RF conversion and vice versa. The remote unit <NUM> can be further connected to a distributed antenna system <NUM> for the distribution of signals.

<FIG> and <FIG> are block diagrams that illustrate an example of the architecture of the system <NUM>. As illustrated, the system <NUM> provides an architecture composed of the following components:.

For example, the system <NUM> includes a point of interface network <NUM> provided with a plurality of the point of interface units <NUM> that interface with the central server <NUM> via the interface links <NUM> and which is connected with the DAS to distribute the signal received from the BBU <NUM> in areas, for example, areas with high density of users.

The interface link <NUM> includes a plurality of optical connecting links. The communication through the connecting links <NUM> can be implemented by means of protocol of the CPRI and/or Ethernet type. The system <NUM> comprises a plurality of BBU <NUM> realized via a BBU pooling software <NUM> configured on the central server <NUM>.

The system <NUM> provides the possibility to realize on the central server <NUM> a set of BBU <NUM>, called BBU-pool. The BBU pooling software <NUM> for the implementation of the BBU-pool can be, for example, a type of a software radio. The central server <NUM> can be, for example, one or more physical computer systems or virtual computer systems, as discussed above. In some implementations, the number of BBUs <NUM> implemented on the central server <NUM> can depend on the number of processors of the computer on the central server <NUM>, itself. The central server <NUM> of the system <NUM> can include one or more electronic connection cards <NUM> and one or more digital CPRI links (or an Ethernet links) between the BBU-pool <NUM> and the electronic connection cards. In some implementations, the electronic connection card <NUM> can be a PCI card.

The electronic connection card <NUM> can be equipped with an Field Programmable Gate Array (FPGA) chip <NUM> capable of ensuring high performance (in terms of clock rates used, power consumption, etc.) The electronic connection card <NUM> can include one or more CPRI links <NUM> (or an Ethernet links). The CPRI links <NUM> perform the transmission/reception on fiber of the base band signal and implements the merging of CPRI and Ethernet data.

For example, the electronic connection card <NUM> can be provided with four CPRI links <NUM> (or Ethernet links) connected to corresponding optical connecting links <NUM>. While illustrated with four links, the electronic connection card <NUM> can include more than four CPRI links <NUM>. In some implementations, the CPRI links <NUM> on the electronic connection card <NUM> can be a type of CPRI Master links.

The BBU-pooling software <NUM> interfaces with the electronic connection card <NUM> through an interface unit <NUM>, for example, a PCI Express interface, and with supervision software <NUM> that acts as supervision of central server <NUM> and POI-Network <NUM>.

The connecting links <NUM> connect the electronic connection card <NUM> of the central server <NUM> with the point of interface unit <NUM> of the DAS. In some implementations, the point of interface units <NUM> can be implemented by means of dedicated POI-CPRI boards. In some implementations, the connecting links <NUM> are constituted by high-speed optical links with CPRI/Ethernet protocol.

The POI-CPRI boards <NUM> are implemented using FPGA boards <NUM>, which allow both the management of the connecting links <NUM>, both the implementation of reprogrammable and re-configurable circuitry, such as digital filtering and adaptive modulation/demodulation of the signal. In some implementations, the POI-Network <NUM> can consist of several POI-CPRI boards <NUM> equipped with a plurality of ports <NUM> connected to respective connecting links <NUM>. The POI-CPRI boards <NUM> can be equipped also with a plurality of ports <NUM> connected to respective connecting links <NUM>.

In some implementations, the POI-CPRI boards <NUM> can be provided with CPRI slave interfaces and CPRI master interfaces. As shown in <FIG>, the POI-CPRI boards <NUM> can be connected to the PCI card <NUM> through CPRI Slave interfaces and are also interconnected each other through CPRI Master/Slave interfaces. The type of the POI CPRI/Ethernet links of the POI-CPRI boards <NUM> can be dynamically reconfigurable as a function of the fact that they must be of Master or Slave type. This makes it possible to create a fully interconnected network between the various POI-CPRI boards <NUM> which has advantages in terms of routing, sustainability and redundancy of the connecting links <NUM> in case of malfunctions/loss of one or more links.

The BBU pooling software <NUM> can realizes the virtualization of the BBU-pool <NUM> or eNodeB (eNB) system. In this way the BBU-pool <NUM> (or eNB) can be hardware independent (it does not require a dedicated hardware) but it can be installed on server machine scalable in terms of CPU power. For example, depending on CPU power, the BBU pooling is able to manage from one to tens of LTE <NUM> MIMO 2x2 carriers. The BBU pooling software <NUM> can be configured, managed and monitored via a supervision software <NUM> that realizes the OMT (Operational and Maintenance Terminal) via a web based GUI and via a BBU maintenance network <NUM>. With the same web based GUI it can be possible to configure, manage and monitor the POI-CPRI boards <NUM> up to the DAS platform interface. In some implementations, the DAS platform itself can be managed by a similar but separated web GUI to keep BBU-pool <NUM> and DAS platform independently manageable.

In some implementations, through OMT web pages, it is possible to manage the LTE datastream coming from operator backhaul network <NUM> to the I/Q drivers and from I/Q drivers to distribute the LTE data to the destination POI-CPRI boards <NUM> through connecting links <NUM>. In this way, on each POI-CPRI board <NUM>, it is possible to generate the RF signal related to the desired band and sector, then this signal will drive the DAS. This platform is flexible, fully configurable and perfectly fits the multiband/multioperator DAS platform.

Concerning the electronic connection card <NUM>, it can be constituted by a FPGA card <NUM>. For example, the electronic connection card <NUM> can be constituted by a software reprogrammable circuitry inserted within the central server <NUM> through a PCI Express interface <NUM> of the latest generation. The electronic connection card <NUM> packs the stream of base-band data generated by the BBU pooling software <NUM> and received via the PCI Express interface <NUM>, according to the CPRI/Ethernet standards, in order to interface to the POI-CPRI boards <NUM> of the POI-Network <NUM>.

A more detailed diagram of the circuitry implemented on the electronic connection card <NUM>, for example, a PCI Card, is shown in <FIG>. The FPGA board <NUM> implement a PCI-Express communication interface <NUM>. Furthermore, the FPGA board <NUM> comprises a memory management unit <NUM> of the Direct Memory Access (DMA) type for managing memory accesses to/from the central server <NUM> memory and from/to the memory on the FPGA board <NUM>.

The FPGA board <NUM> further includes custom interfaces to align the format of the three different data interfaces and PCIe, DMA and CPRI, and other custom algorithms of signal processing to organize, optimize and tailored stream of data with respect to the POI-Network <NUM>. The FPGA board <NUM> also comprises organization units <NUM> for organizing data according to the CPRI standard. In some implementations, the organization units <NUM> performs AxC IQ data mapping, interleaving frame and synchronization management.

An example of a hardware architecture of a POI-CPRI Board <NUM> is shown in detail in <FIG>. The POI-CPRI board <NUM> can include the following components:.

The FPGA board <NUM> can perform the following functions:.

The realization of the BBUs in software on the central server allows: cost savings for production operators; savings production materials and physical dimensions apparatus; energy saving; intercommunication between multiple BBU; and use of a FPGA board for the management of the CPRI link high speed. Furthermore, the realization of the specific digital and interconnected CPRI-POI boards allows: the communication between the various boards with optical CPRI links; the ability to reroute traffic dynamically; and high flexibility and re-configurability of the POI network; and re-programmability of the individual CPRI-POI board through the use of FPGA boards.

Because the integrated BBU/DAS system operates as a finely tuned and single system, it can minimize the disadvantageous of consistent soft-handover states that typically occur in when users are traversing across numerous small cells, while maximizing the end user throughput at any point or points across the system. The integrated BBU/DAS system allows to store, keep track of, and/or otherwise monitor the distribution of remote radios and antennas in the DAS, and can identify, monitor, and/or otherwise determine the end users' (e.g., cellphones) localizations in relation to each DAS radio/antenna. Using this intelligence information, the system can dynamically optimize the allocation of available BBU resources to best serve the locations of these different user communities.

<FIG> and <FIG> illustrate an example of a method <NUM> for baseband aggregation routing, according to various implementations. The illustrated stages of the method are examples and that any of the illustrated stages can be removed, additional stages can be added, and the order of the illustrated stages can be changed.

In <NUM>, a UE roams into a first area of a location. For example, as illustrated in <FIG>, a UE <NUM> can be receiving mobile services from a mobile operator network <NUM> via an external "macro" cell <NUM>. The UE <NUM> can enter a first area <NUM> of the location <NUM>. For example, the location <NUM> can be an office building and the first area <NUM> can be the lobby of the office building.

In <NUM>, the UE locates a baseband unit. For example, as illustrated in <FIG>, once the UE <NUM> enters the first area <NUM>, the UE <NUM> can detect a radio signal from a RF unit <NUM> coupled to the one or more of the VBEs <NUM>. For instance, the UE <NUM> can activate a search for a radio signal. Once the UE <NUM> enters the area <NUM>, the UE <NUM> can detect the radio signal from the RF unit <NUM> and attempt to establish a connection with a baseband unit of the VBEs106.

In <NUM>, the baseband unit establishes a communication path with the UE. For example, the baseband unit of the VBEs <NUM> can authenticate the UE <NUM> and register the UE <NUM> with the VBEs <NUM>. The VBEs <NUM> can authenticate the UE <NUM> with the mobile operator network <NUM> via the MSE <NUM>. As illustrated in <FIG>, once the UE <NUM> has been authenticated, the VBEs <NUM> can establish a communication path <NUM> with the UE <NUM>. The communication path <NUM> can be any type of mobile communication path or session. For example, the communication path <NUM> can be a 3GPP LTE wireless communication which includes three tunnels, e.g., voice, data, and control.

In <NUM>, the MSE establishes a communication path with the baseband unit. For example, as illustrated <FIG>, the MSE <NUM> can establish a communication path <NUM> with the VBEs <NUM>. The communication path <NUM> can be the same type of communication path as communication path <NUM>. In <NUM>, the MSE <NUM> establishes a communication path with an external network. For example, as illustrated <FIG>, the MSE <NUM> can establish a communication path <NUM> with the mobile carrier network <NUM>. The communication path <NUM> can be the same type of communication path as communication path <NUM> and <NUM>. In <NUM>, the MSE associates the communication path with the external network and the communication path with the baseband unit. In implementations, the MSE <NUM> operates in coordination with VBEs <NUM> to establish the complete communication path to the mobile carrier network <NUM> in near-real time. Additionally, the MSE <NUM> can operate transparently so that the UE <NUM> and the mobile carrier network <NUM> appear to make a normal mobile connection.

In <NUM>, the UE can roam into a second area of the location. For example, as illustrated in <FIG>, the UE <NUM> can roam into a second area <NUM> of the location <NUM>, for instance, a different room or floor of the location <NUM>.

In <NUM>, the UE locates a new baseband unit. For example, once the UE <NUM> enters the second area <NUM>, the UE <NUM> can detect a radio signal from a RF unit <NUM> coupled to the one or more of the VBEs <NUM>. For instance, the UE <NUM> can activate a search for a radio signal. Once the UE <NUM> enters the second area <NUM>, the UE <NUM> can detect the radio signal from the RF unit <NUM> and attempt to establish a connection with a new baseband unit of the VBEs106.

In <NUM>, the new baseband unit establishes a communication path with UE. For example, the baseband unit of the VBEs <NUM> can authenticate the UE <NUM> and register the UE <NUM> with the VBEs <NUM>. The VBEs <NUM> can authenticate the UE <NUM> with the mobile operator network <NUM> via the MSE <NUM>. Likewise, the original baseband unit can hand over the UE <NUM> to the new baseband unit using a protocol such as X2. As illustrated in <FIG>, once the UE <NUM> has been registered, the VBEs <NUM> can establish a communication path <NUM> with the UE <NUM>.

In <NUM>, the MSE establishes a communication path with the new baseband unit. For example, as illustrated <FIG>, the MSE <NUM> can establish a communication path <NUM> with the VBEs <NUM>. The communication path <NUM> can be the same type of communication path as communication path <NUM>.

In <NUM>, the MSE associates the existing communication path with the external network with the communication path with the new baseband unit. For example, the MSE <NUM> can associate the existing communication path <NUM> with the communication paths <NUM> and <NUM>. In implementations, the MSE <NUM> operates in coordination with VBEs <NUM> to establish the complete communication path to the mobile carrier network <NUM> in near-real time. Additionally, the MSE <NUM> can operate transparently so that the UE <NUM> and the mobile carrier network <NUM> appear to make a normal mobile connection.

<FIG> and <FIG> illustrate an example of a method <NUM> for establishing a connection through a WAP, according to various implementations. The illustrated stages of the method are examples and that any of the illustrated stages can be removed, additional stages can be added, and the order of the illustrated stages can be changed.

In <NUM>, the MSE receives a request to establish a communication path through a WAP. For example, as illustrated in <FIG>, a UE <NUM> can be in location <NUM> and can send a request to establish a communication path through a WAP <NUM> to a mobile operator network <NUM>. The UE <NUM> can communicate with the WAP <NUM> using any type of wireless communication protocol. The communication path can be any type of communication path, for example, voice over IP.

In <NUM>, the MSE determines whether the WAP is subject to an access policy. For example, the location <NUM> can allow only certain defined groups of UEs to access the WAP <NUM>. To determine policy compliance, the MSE <NUM> can include a policy engine <NUM>. The policy engine <NUM> can be configured to determine whether the WAP <NUM> is subject to a policy and to determine the appropriate policy manager to check. For example, the policy engine <NUM> can maintain a record of WAPs subject to policy management and can compare identification information for the WAP <NUM> to the record.

If the WAP is subject to policy management, in <NUM>, the MSE determines whether the policy is governed by a local or external policy manager. For example, as illustrated in <FIG>, the MSE <NUM> can provide the EFV interface <NUM> to a local policy manager <NUM> and a external policy manager <NUM>.

If the policy is governed by a local policy manager, in <NUM>, the MSE sends a policy check request to the local policy manager. For example, the MSE <NUM> can send a policy check request to the local policy manager <NUM> via the EFV interface <NUM>. The policy check request can include information that identifies the UE <NUM> and the WAP <NUM>.

If the policy is governed by an external policy manager, in <NUM>, the MSE sends a policy check request to the external policy manager. For example, the MSE <NUM> can send a policy check request to the external policy manager <NUM> via the EFV interface <NUM>. The policy check request can include information that identifies the UE <NUM> and the WAP <NUM>.

In <NUM>, the MSE determines whether the UE can access the WAP. For example, the MSE <NUM> can receive a response from the local policy manager <NUM> or the external policy manager <NUM> that indicates whether the UE <NUM> can access the WAP <NUM>.

If the UE is authorized, the MSE sends a request for authentication of the UE from the mobile carrier network. For example, as illustrated in <FIG>, the MSE <NUM> can send a request to a home subscriber server (HSS) <NUM>. The request can include an identification of the UE <NUM>, for example, an identification of a SIM card of the UE <NUM>. The MSE <NUM> can send the request via an interface, for example, the NFV interface <NUM>. The HSS <NUM> can communicate with a subscriber database <NUM> to determine whether to authenticate the UE <NUM>.

In <NUM>, the MSE determines whether the UE is authenticated to aces the mobile carrier network. For example, the MSE <NUM> can receive a response from the HSS <NUM> that indicates whether the UE <NUM> can access the mobile carrier network <NUM>. The response can also indicate that the UE <NUM> can establish a connection path through the WAP <NUM>.

If the UE is authenticated, in <NUM>, the MSE establishes a communication path to the mobile carrier network. For example, the MSE <NUM> can establish a communication path <NUM> through the WAP <NUM>.

<FIG> and <FIG> and <FIG> illustrate an example of a method of <NUM> for providing services to a location, according to various implementations. The illustrated stages of the method are examples and that any of the illustrated stages can be removed, additional stages can be added, and the order of the illustrated stages can be changed.

In <NUM>, the MSE enables an interface for application services. For example, the MSE can configure the interface to be accessible by applications, for example, configure the interface to enable access to the protocols associated with the application. In <NUM>, the MSE registers and authenticates an application with the interface. For example, the application utilizes an authentication exchange using an XML, JSON, or other interface to process the authentication exchange and possible utilizing certification key methods, to validate that the application is a valid application and should be allowed access to the interface for application services.

In <NUM>, the MSE receives information associated with a UE, which can be a mobile phone user or other non-user devices that can be on this network such as IoT devices. The information associated with the UE can include any information that allows the MSE to cooperate with the application to deliver the services. For example, the information can include an identification of the UE, for example, a phone number, a SIM card identifier, a Media Access Control Address (MAC), etc., and state information for the UE, for example, location of the UE, call status of a UE, etc. The information can also include a change in the sate information for the UE.

In <NUM>, the MSE pushes, via the interface, the information to the application. The application can utilize the information to perform the services provided by the application. In <NUM>, the MSE receives, via the interface, a request to perform an action from the application. For example, based on the information provided, the application can instruct the MSE to perform an action at the location associated with the services. In <NUM>, the MSE performs the requested action. After <NUM>, the method <NUM> can return to <NUM> and the MSE can await new information associated with the UE.

For example, as illustrated in <FIG>, the location <NUM> can be a hotel. The hotel can desire to provide several services to guests of the hotel. For example, the hotel can support automatic check-in and simultaneous room ringing for a UE <NUM>. In automatic check-in, the location <NUM> can include a hotel property management application <NUM> that communicates with the MSE <NUM> via the EFV interface <NUM>. When the UE <NUM> enters the hotel, the UE <NUM> can communicate with the MSE <NUM>, and the MSE <NUM> can information associated with the UE <NUM>, for example, identifying information, location etc. The MSE <NUM> can then forward the information tot the hotel property management application <NUM>, via the EFV interface <NUM>. In response, the hotel property management application <NUM> can perform actions, such as identify the user associated with the UE <NUM>, check the user into a room <NUM> in the hotel, etc. The hotel property management application <NUM> can also request that the MSE <NUM> perform actions such as notify the UE <NUM> of check-in.

In this example, the location <NUM> can also include a telephone system <NUM>. The telephone system <NUM> can support simultaneous ringing a phone <NUM> when the user is located in their room <NUM>. In this case, the MSE <NUM> can, upon observing an inbound call towards a UE associated with a known room, and when the UE <NUM> is identified as being "in the room" <NUM>, utilize the EFV interface <NUM>, via a local telephone IP interface, to ring the telephone <NUM>. The MSE <NUM> can also coordinate routing the incoming call to the telephone <NUM>, if the user answers the telephone <NUM>, systematically performing appropriate CODEC translation to match with the telephone system <NUM>.

In another example, as illustrated in <FIG>, the location of a UE <NUM> can be employed by <NUM> applications to report the location, for example, a room <NUM>, of the UE <NUM> making a <NUM> call, or otherwise employed by similar emergency applications. In this example, the MSE <NUM> can enable an interface for a public safety answering point (PSAP) system <NUM>. When the UE <NUM> dial <NUM>, the MSE <NUM> can push the location information of the UE <NUM> to the PSAP system <NUM>. Where and when further enabled by emerging UE standards a <NUM> call by a user or other emergency state within a location can allow for the MSE and/or VBEs to force an emergency state of the UE, enabling all radios in the UE device, including cellular, Wi-Fi, and Bluetooth technologies, to optimize location intelligence to the benefit of users in an emergency state.

<FIG> and <FIG> illustrate an example of a method <NUM> for routing network communications, according to various implementations. The illustrated stages of the method are examples and that any of the illustrated stages can be removed, additional stages can be added, and the order of the illustrated stages can be changed.

In <NUM>, the MSE identifies a UE present in a location. The MSE can identify the UE is present when the UE attempts to communicate with one of the networks coordinated by the MSE. For example, as illustrated in <FIG>, a UE <NUM> can enter the location <NUM> and register with the VBEs <NUM>.

Once the UE is identified, in <NUM>, the MSE can determine whether a local gateway is present. A local gateway can be a system that provides a dedicated bearer channel to certain UEs. For example, a mobile operator network can offer the dedicated bearer channel as a service to subscribing UEs. As illustrated in <FIG>, for example, a local gateway <NUM> can be offered by a mobile operator network <NUM>. The local gateway <NUM> can be implemented in the switch <NUM>. The local gateway <NUM> can be implemented in hardware, software, or combination thereof. The MSE <NUM> can push a request to the mobile operator network <NUM> via the NFV interface <NUM> to determine if the local gateway <NUM> is present. The MSE <NUM> can also examine the switch <NUM> or records to determine if the local gateway <NUM> is present.

If a local gateway is present, in <NUM>, the MSE determines whether the UE is authorized to use the local gateway. The MSE can communicate with the mobile operator network associated with local gateway to determine if the UE is authorized to use the local gateway. For example, the MSE <NUM> can push a request to the mobile operator network <NUM> via the NFV interface <NUM> to determine if the UE <NUM> is authorized.

If the UE is authorized to use the local gateway, in <NUM>, the MSE directs all packets to the local gateway. For example, as illustrated in <FIG>, the MSE <NUM> can establish a communication path <NUM> to the local gateway.

If a local gateway is not present or the UE is not authorized to use the local gateway, in <NUM>, the MSE inspects packets flowing from the UE and identifies the destination of the packets. In some implementations, the packets can be destined for an internal network to the location. For example, as illustrated in <FIG>, the UE <NUM> can make a call to a second UE <NUM> that is communicating via a WAP <NUM>, for example, one a trusted or secure network. In <NUM>, the MSE can validate the UE access to the secured/trusted network. For example, the MSE <NUM> can request validation for internal or external policy managers to determine if the UE <NUM> can access the secured/trusted network.

In <NUM>, the MSE identifies priority packets and sets packet flags for the priority packets. For example, the MSE <NUM> can determine that the packets are associated with a voice call. In response, the MSE <NUM> can set packet flags the packets to identify the packets as priority packets to receive, for example, special processing, higher quality of service, etc. In <NUM>, the MSE sets route tables for packets with local destination. The MSE can set the route tables in the switch <NUM>. Once the MSE sets the route tables, the switch <NUM> can direct traffic to the UE <NUM> over the WAP <NUM>.

The foregoing description is illustrative, and variations in configuration and implementation can occur to persons skilled in the art. For instance, the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but, in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

In implementations, the functions described can be implemented in hardware, software, firmware, or any combination thereof. For a software implementation, the techniques described herein can be implemented with modules (e.g., procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, and so on) that perform the functions described herein. A module can be coupled to another module or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, or the like can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, and the like. The software codes can be stored in memory units and executed by processors. The memory unit can be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

For example, <FIG> illustrates an example of a hardware configuration for a computer device <NUM> that can be used as a computer system or device, which can be used to perform one or more of the processes described above. While <FIG> illustrates various components contained in the computer device <NUM>, <FIG> illustrates one example of a computer device and additional components can be added and existing components can be removed.

The computer device <NUM> can be any type of computer devices, such as desktops, laptops, servers, etc., or mobile devices, such as smart telephones, tablet computers, cellular telephones, personal digital assistants, etc. As illustrated in <FIG>, the computer device <NUM> can include one or more processors <NUM> of varying core configurations and clock frequencies. The computer device <NUM> can also include one or more memory devices <NUM> that serve as a main memory during the operation of the computer device <NUM>. For example, during operation, a copy of the software that supports the methods and processes described above, for example, the MSE <NUM>, can be stored in the one or more memory devices <NUM>. The computer device <NUM> can also include one or more peripheral interfaces <NUM>, such as keyboards, mice, touchpads, computer screens, touchscreens, etc., for enabling human interaction with and manipulation of the computer device <NUM>.

The computer device <NUM> can also include one or more network interfaces <NUM> for communicating via one or more networks, such as Ethernet adapters, wireless transceivers, or serial network components, for communicating over wired or wireless media using protocols. The computer device <NUM> can also include one or more storage device <NUM> of varying physical dimensions and storage capacities, such as flash drives, hard drives, random access memory, etc., for storing data, such as images, files, and program instructions for execution by the one or more processors <NUM>.

Additionally, the computer device <NUM> can include one or more software programs <NUM> that enable the functionality described above. The one or more software programs <NUM> can include instructions that cause the one or more processors <NUM> to perform the processes and methods described herein. Copies of the one or more software programs <NUM> can be stored in the one or more memory devices <NUM> and/or on in the one or more storage devices <NUM>. Likewise, the data utilized by one or more software programs <NUM> can be stored in the one or more memory devices <NUM> and/or on in the one or more storage devices <NUM>.

In implementations, the computer device <NUM> can communicate with other devices via one or more networks. The other devices can be any types of devices as described above. The one or more networks can be any type of network, such as a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof. The one or more networks can support communications using any of a variety of commercially-available protocols, such as TCP/IP, UDP, OSI, FTP, UPnP, NFS, CIFS, AppleTalk, and the like. The one or more networks can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.

The computer device <NUM> can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In some implementations, information can reside in a storage-area network ("SAN") familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers, or other network devices can be stored locally and/or remotely, as appropriate.

In implementations, the components of the computer device <NUM> as described above need not be enclosed within a single enclosure or even located in close proximity to one another. Those skilled in the art will appreciate that the above-described componentry are examples only, as the computer device <NUM> can include any type of hardware componentry, including any necessary accompanying firmware or software, for performing the disclosed implementations. The computer device <NUM> can also be implemented in part or in whole by electronic circuit components or processors, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

If implemented in software, the functions can be stored on or transmitted over a computer-readable medium as one or more instructions or code. Computer-readable media includes both tangible, non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media can be any available tangible, non-transitory media that can be accessed by a computer. By way of example, and not limitation, such tangible, non-transitory computer-readable media can comprise RAM, ROM, flash memory, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, DVD, floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

While the teachings have been described with reference to examples of the implementations thereof, those skilled in the art will be able to make various modifications to the described implementations without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the processes have been described by examples, the stages of the processes can be performed in a different order than illustrated or simultaneously. Furthermore, to the extent that the terms "including", "includes", "having", "has", "with", or variants thereof are used in the detailed description, such terms are intended to be inclusive in a manner similar to the term "comprising. " As used herein, the terms "one or more of" and "at least one of" with respect to a listing of items such as, for example, A and B, means A alone, B alone, or A and B. Further, unless specified otherwise, the term "set" should be interpreted as "one or more. " Also, the term "couple" or "couples" is intended to mean either an indirect or direct connection. Thus, if a first device couples to a second device, that connection can be through a direct connection, or through an indirect connection via other devices, components, and connections.

Those skilled in the art will be able to make various modifications to the described implementations without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method can be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.

The foregoing description of the disclosure, along with its implementations, has been presented for purposes of illustration only. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Those skilled in the art will appreciate from the foregoing description that modifications and variations are possible in light of the above teachings or can be acquired from practicing the disclosure. For example, the steps described need not be performed in the same sequence discussed or with the same degree of separation. Likewise various steps can be omitted, repeated, or combined, as necessary, to achieve the same or similar objectives. Similarly, the systems described need not necessarily include all parts described in the implementations, and can also include other parts not describe in the embodiments.

Claim 1:
A method for providing network services at a location, the method comprising:
enabling, by a mobile services engine, a first interface for providing location information associated with a user device to a public safety answering point system;
receiving, from the user device by one of the mobile services engine and a virtual baseband engine, a call to a predefined emergency number;
responsive to the receiving of the call:
forcing, by at least one of the mobile services engine and the virtual baseband engine, an emergency state of the user device, the forcing of the emergency state comprising:
causing the user device to enable all radios in the user device, including any of cellular technology, Wi-Fi technology, and Bluetooth technology, to determine a location of the user device by use of remote radios and antennas at locations in an RF distributions platform known to one of the mobile services engine and a local mobile network;
obtaining, by the mobile services engine, first information associated with the user device, wherein the first information comprises the location information corresponding to the location of the user device, and
pushing, by the mobile services engine via the first interface, the first information to the public safety answering point.