Service level assurance system and method for wired and wireless broadband networks
A system and method are provided for tracking and reporting the performance of a network. A client or a user device can access the network through a wired connection or wireless access points. The client maintains a log or track the events that occur during the log-on attempts as well as the communication sessions as well as other data related to the network performance. During the communication session data can be transferred between the client and a network device, such as the central server or a database, in the network, regardless of whether the network device is trusted and secure or not secure.
Latest Pctel, Inc. Patents:
This application claims the benefit of U.S. Provisional Application No. 60/555,812, filed Mar. 23,2004 (Atty. Dkt.: 069509-0308954)entitled “Service Level Assurance System and Method for Wired and Wireless Broadband Networks” and U.S. Provisional Application No. 60/555,988, filed Mar. 23, 2004 (Atty. Dkt.: 069509-0308956) entitled “Method and System for Automatic Data Transfer on a Network-Connected Device”, both of which are incorporated herein by reference in their entirety and for all purposes.
The present application is related to U.S. Provisional Application No. 60/504,152, filed Sep. 19, 2003 (Atty. Dkt.: 069509-0306053) and entitled “Automated Updating System for Wireless Networks,” commonly owned by the present assignee, which is incorporated herein by reference in its entirety and for all purposes.
BACKGROUND1. Field of the Invention
The present invention relates generally to systems and methods for network management, and more particularly relates to systems and methods for monitoring and managing the quality of service of a broadband service offering.
There are many devices capable of connecting to a data network, be it wired or wireless. The networks that support connections to these devices are typically broadband networks, whether wired or wireless. Carriers providing such services are often required to commit to specified levels of service for their customers. These commitments are sometimes referred to as Service Level Assurance (SLA). Even in the absence of a SLA commitment, broadband providers typically continuous monitor and attempt to improve the quality of their service offerings. Various methods are used for determining quality of service, all of which typically involve monitoring various network parameters. Among the network parameters that are typically monitored are: number of connect attempts, connection location (hot spot, dial up node, Ethernet node), signal strength, data rates (effective as well as available), connection duration, and so on.
Therefore, what is needed is a system and method for tracking and reporting the performance of a network that includes various broadband access points throughout the network.
SUMMARYA system and method are provided for tracking and reporting the performance of a network. A client or a user device can access the network through a wired connection or wireless access points. The client maintains a log or track the events that occur during the log-on attempts as well as the communication sessions as well as other data related to the network performance. During the communication session data can be transferred between the client and a network device, such as the central server or a database, in the network, regardless of whether the network device is trusted and secure or not secure.
THE FIGURESThese and other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures, wherein:
The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention. Where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Further, the present invention encompasses present and future known equivalents to the components referred to herein by way of illustration.
Referring now to
Devices 110A-n include computers having thereon a “roaming client” functionality, which includes Service Provider Interface (SPI) functionality, or a PDA, a Cell phone, a camera, an MP3 device, or any other network connected device or appliance capable with SPI functionality, that is, capable of contacting the NMS 100 and then executing appropriate commands received back from the NMS 100 including responding to queries with appropriate status information.
The NMS 100 includes, in an exemplary arrangement, three functional components, designated in
The SPI 140 gathers the responses from the SPI-enables devices 110A-n and, if necessary, formats the information for forwarding to the NOC. In an exemplary arrangement, the NOC includes appropriate functionality to accumulate the data from the SPI-enabled devices 110A-n, and generate appropriate reports for management of the network resources. It will be appreciated that the foregoing approach has the advantage of allowing communication between the SLA module 150 and compatible, SPI-enabled devices 110 even if the SPI-enabled devices 110 are behind a firewall, because the protocol is text-based and is carried over standard HTTP(S) ports, typically ports 80 and 443.
From the foregoing it can be appreciated that the present invention enables the client or device 110to communicate with the NOC. In addition, the functionality provided by the present invention also allows the NOC to communicate, through the NMS 100, back to the SPI enabled devices 110. In particular, the NOC may desire to instruct the client or device 110 to perform various functions, for example launching a browser or other application, or directing users to a particular web page. The operation may also include a push of content to the end user, or an upload or download of files, for example software upgrades, from a desired location, which may be either pre-arranged or specified on the fly. One particular instance of redirecting a client device 110 may be to enable further communications. For example, if an account is not active, the NOC may direct the SPI-enabled device 110 to a provisional URL or other web page so that that user can obtain an account or otherwise establish credentials.
The functionality of the present invention requires a previously unachieved level of cooperation among the components of the system described herein. One aspect of the invention is the client-side functionality, represented generally at 110A-n by the roaming client module or software indicated at 110A-B, which includes SPI enablement, and by which network connectivity is achieved for a variety of SPI-enabled devices 110A-n as described above.
In an exemplary arrangement, the SPI capabilities incorporated into the roaming client and other SPI-enabled devices 110 include: aggregation of disparate wireless networks under one service umbrella; prioritization of wireless networks; support for seamless roaming between networks, including Wi-Fi and GPRS; support for automatic authentication between networks that have complex and non standard mechanisms for user authentication and administration; access Point Location database; and, automatic and remote update of network attributes, location database, and Roaming Client software updates. It will be appreciated by those skilled in the art that the SPI could easily be expanded to include other capabilities.
The SPI-enabled roaming client module 110further includes several features that are remotely updateable and/or upgradeable, including the executable software, location finder database, roaming partner data, carrier/PCOEM/enterprise preferences, user interface skins, and hardware drivers.
Referring next to
The CCS 130 also negotiates download parameters, such as bandwidth, frequency, and duration of downloads with each client, based on rules that are predetermined by the carrier, PCOEM, Enterprise, or configured by the end user. Stated slightly differently, the CCS 130 may be thought of as a secure, web-based administrative console, which provides the capability for updating the various pre-defined and provider-specific parameters for the Roaming Client. In addition, the CCS 130 allows management and manipulation of “Hotspot” location database information, roaming partner database information, and the gated upload capabilities for these databases. Together, the combination of the CCS 130 with the user connectivity tool of the Roaming Client provides a dynamic wireless access management solution.
In an exemplary implementation, the CCS 130 may be architected based on the J2EE framework. In at least such an implementation, the CCS 130 need not use a middle tier or business tier, and therefore need not include an Enterprise Java Beans server. The CCS 130 functionality may reside on a personal computer or a Sun SPARC workstation, or similar computing platform, and any suitable operating system such as Windows, Linux or Solaris. Typical software requirements for such an exemplary arrangement include compatibility with a Java Servelet specification, for example version 2.3, and a JSP application such as version 1.2, as well as with a suitable database server, for example Microsoft SQL Server 2000 or similar. It may also be desirable to include compatibility with JDK 1.4.1 or later, at least for application servers.
Referring again to
The SPI 140 operates to provide the device 110access to a network, such as through an access point (AP) located at a hotspot. To put this aspect in context, a brief discussion of WiFi hotspots is helpful. In the case of WiFi hotspot deployments, a Service Provider typically has hundreds if not thousands of different locations that a user can connect to. These locations may be maintained by the service provider or provided by a roaming agreement with another provider.
In one typical scenario, a user arrives at a location, connects to the network, and then launches their WEB browser. The user attempts to get to the Internet, but is then captured and redirected by the local network administration server (NAS) device, whereupon the user is requested to authenticate or sign up and pay for service.
In the case of the Roaming Client, the SPI protocol allows additional steps to be performed. The basic goal of the SPI protocol is to allow the Roaming Client the ability to communicate to the service provider before and after login into a local hotspot. This client/server communication allows a service provider to perform various checks on the client, and push back different actions for the client to execute depending on the Roaming Clients state.
The SPI 140 provides a client/server communications protocol, and can be implemented on any web server that supports such a protocol. The SPI protocol allows a trusted web server to execute actions on the devices 110. In an exemplary arrangement, the SPI protocol may, for example, be an XML-based messaging protocol that uses HTTPS as the primary transport for secure communications between the client and server. The SPI 140 and CCS 130 interact in that the CCS 130 is the mechanism that allows a provider to modify specific parameters on the client, while the SPI protocol is the mechanism that allows specific actions to be executed on the client, for example, login and authentication in some embodiments. Such actions may use parameters that are pushed to the client via the CCS interface.
Referring now to
In Wi-Fi there is a notion of physical “connection” to a hotspot although the user has not authenticated. In this case the Roaming Client is considered to be in the “Connected” state (although not yet authenticated). At this point, the Roaming Client can initiate communication to the provider's SPI server to inform the server about its current state and other attributes associated with the client.
As shown in
Examples of pre-authentication actions that a client may execute using SPI 140 include, but are not limited to, provisioning a new user, pushing surcharge information to a client, requesting statistics from the client, and prompting a user for a password. Post-authentication actions includes pushing the time remaining, pushing advertising, pushing a custom skin, and pushing a message. Examples of disconnect actions includes sending log-off data, such as a thank you or other message, and sending usage statistics. It will be appreciated that such actions can be provided to the NOC in accordance with the present invention to provide dynamic monitoring and data gathering.
However, if the server is not in the network provider's “White List”, as illustrated in
Referring next to
Similarly, the ACTION message may take the form
In one exemplary arrangement, the Roaming Client initiates communication with the SPI Protocol Server. As noted previously, in such arrangements, the SPI server will be a web server deployed to communicate with and manage SPI enabled devices, such as the Roaming Client or other devices 110. It will be appreciated by those skilled in the art that the SPI Server is a functionality, which may reside on a dedicated hardware server, or may coexist with other software functions on one or more hardware servers, each of which may be a PC, a workstation, or similar computer processing device.
Referring now to
At Client Request 602, the user attempts to go to a particular website, for example www.mystorage.mywireless.com/myaccount, using an SPI component embedded in the MMD. At NAS Response 604, the NAS responds with a redirect because the MMD is not authenticated. At Client Request 606, which is the INFO portion of the SPI enable client device communication with the NMS (
A further example of authentication is shown in
In an alternative arrangement, HTTP headers provided by the network (the provider's NOC, for example) may be used to provide the SPI device with operating parameters. The Roaming Client can also parse attributes from the network in real time. In some cases a provider may use an authentication API that specifies attribute values utilizing http headers.
For purposes of the present example, Acme's NAS responds back to the client's original request with an UNAUTHORIZED response with custom HTTP headers. The custom HTTP headers could have also been returned after the client connected to the URL in the redirect request. Regardless of how the headers are provided, these headers will then be utilized in the next step of the authentication process, shown in
In
It should be noted that some parameters are populated with information, which may be provided, for example, by the NAS in the prior step.
The SPI server then responds with an Action message appropriate for the client's current state, as well as other variables in the INFO message package, as shown in
Referring next to
When the client receives the <action>logon</action> directive, it posts the credential information to the URL provided by the NAS (see above) or use the value pushed down to the client by the CCS. In either case, the authentication method that is implemented must be able to utilize this value when the login method is executed. In a typical arrangement, the provider has implemented a custom authentication method on the client using the Authentication API. The authentication method utilizes the custom parameter AcmeWirelessLogin-URL, which was provided by the NAS device previously, see
The login action is executed, and the credentials are sent to the authentication server URL. The Authentication server then completes the transaction with an authentication response to the client.
Referring now to
The INFO message can be configured to provide to the NMS 100 (
Table 1, below, shows, for an exemplary arrangement only, a combined list of the types of information which can be either delivered as part of the INFO message, or maintained in an event log and uploaded upon request:
Of the foregoing, one exemplary implementation implements only the following data in the INFO message, and leaves the remaining data for an event log: status, username, password, realm, error, provider, location, session, IP, MAC, bssid, linkspeed, rssi, hwvendor, driverversion, hostname, eventhistory, clientid, and clientversion. In some implementations, it may be desirable not to populate one or more of the foregoing data fields in the INFO message.
The form of the SPI Server “ACTION” messages is described above. An example of the actions which the SPI server may instruct the client to execute is shown in Table 3, below:
Various custom parameters can be used for management or authentication actions on the Roaming Client. Typically either of two methods can be used to update or manage attributes on the client. In a first approach, a CCS can push attribute values to the client when the client contacts the server for updates. It will be appreciated that, in the alternative, the CCS may simply cause a second server to push the values, or the CCS may be comprised of multiple servers. In at least some arrangements, WISPr authentication may be used.
In a second approach, the network provider can send custom HTTP headers to SPI-enabled devices, and the devices can parse the headers to identify the appropriate parameters. Examples of such includes login URL, location ID information, provider name, and so on. An example of a custom HTTP header is shown below:
From the foregoing it can be appreciated that the present invention provides a powerful, flexible, scalable method and system for monitoring and maintaining wired and wireless networks, including providing metrics for meeting SLA requirements, QoS requirements, or other network parameters.
Although the present invention has been particularly described with reference to embodiments thereof, it should be readily apparent to those of ordinary skill in the art that various changes, modifications and substitutes are intended within the form and details thereof, without departing from the spirit and scope of the invention. Accordingly, it will be appreciated that in numerous instances some features of the invention will be employed without a corresponding use of other features. Further, those skilled in the art will understand that variations can be made in the number and arrangement of components illustrated in the above figures. It is intended that the scope of the appended claims include such changes and modifications.
Claims
1. A method of detecting and managing network performance, the method comprising the steps of:
- initiating a communication session between a user device and a management server;
- recording data at the user device related to the performance of the network; and
- querying the user device for data related to the performance of the network.
2. The method of claim 1, wherein the communication session is a wireless communication session based on an interface protocol.
3. The method of claim 1 further comprising the steps of:
- transmitting data from the user device to an access point device, which in turn delivers the data to an authentication server; and
- authenticating the user device based on the data provided.
4. The method of claim 3 wherein the step of transmitting comprises the steps of:
- transmitting an address associated with the authentication server; and
- querying the user device for identity information, which information is automatically provided by the user device in response to the query.
5. The method of claim 1 further comprising the step of formatting the data from the user device for delivery to a central location for analysis in order to determine the performance of the network.
6. A system for monitoring the performance of a wireless network having a plurality of access points, the system comprising:
- a plurality of clients, wherein each client is adapted to detect the presence of the network available at the access point and initiate a wireless communication session with one access point;
- a central server in communication with each of the plurality of access points such that when each client is authenticated by the central server and logged onto the network and each client can be queried by the central server for information related to the performance of the network.
7. The system of claim 6 wherein each client and the central server include a service provider enablement component.
8. The system of claim 6 wherein each client includes a roaming client component that can be updated from the central server when the client is logged onto the network.
9. The system of claim 8 further comprising a configuration server for management of client features and policies as well as software updates that are pushed to any client during the communication session.
10. A method for evaluation of the performance of a wireless network comprising a plurality of access points each in communication with a network server, the method comprising the steps of:
- initiating a wireless communication session between a user device and one access point of the plurality of access points;
- determining if the user device is an authenticated user device;
- redirecting the user device to an authentication server, such that the authentication server initiates an authentication process and requests information form the user device for authentication of the user device; and
- querying the user device for data related to the performance of the network.
Type: Application
Filed: Mar 23, 2005
Publication Date: Feb 23, 2006
Applicant: Pctel, Inc. (Chicago, IL)
Inventors: Robert Boxall (Elmhurst, IL), Vojislav Samsalovic (Chicago, IL), Biju Nair (Long Grove, IL)
Application Number: 11/089,238
International Classification: H04L 9/00 (20060101); H04L 9/32 (20060101); G06F 17/00 (20060101); G06K 9/00 (20060101); H04K 1/00 (20060101); G06F 17/30 (20060101); G06F 15/16 (20060101); G06F 7/04 (20060101); G06F 7/58 (20060101); G06K 19/00 (20060101);