US20060041931A1

US20060041931A1 - Service level assurance system and method for wired and wireless broadband networks

Info

Publication number: US20060041931A1
Application number: US11/089,238
Authority: US
Inventors: Robert Boxall; Vojislav Samsalovic; Biju Nair
Original assignee: PCTel Inc
Current assignee: Smith Micro Software Inc
Priority date: 2004-03-23
Filing date: 2005-03-23
Publication date: 2006-02-23
Also published as: KR20070007155A; WO2005094464A2; WO2005094463A2; EP1741036A2; EP1761866A4; US8325625B2; KR20060135910A; EP1761866A2; WO2005094464A3; WO2005094463A3; US20060047830A1

Abstract

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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.

BACKGROUND

1. 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.

SUMMARY

THE FIGURES

These 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:
FIG. 1 illustrates in block diagram form the interoperation of the present invention with a service provider's network operations center;.
FIG. 2 illustrates in block diagram form an exemplary CCS architecture in accordance with the present invention;
FIG. 3 illustrates in time line form an exemplary SPI client-server transaction where the SPI server is in the network provider's “Whitespace”;
FIG. 4 illustrates in block diagram form an exemplary SPI client-server transaction where the SPI server is not in the network provider's “Whitespace”;
FIG. 5 illustrates a simple message exchange sequence between the SPI client and the SPI server;
FIG. 6 illustrates a message exchange between the SPI client and the SPI server involving authentication;
FIG. 7A-7D illustrate an authentication sequence in an exemplary implementation of the present invention; and
FIG. 8 is a flow chart for the process of authenticating a client.

DETAILED DESCRIPTION OF THE INVENTION

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 FIG. 1, the general context and operation of the present invention can be appreciated. The network management system (NMS)100 of the present invention interacts with one or more devices 110A-n (sometimes collectively referred to hereinafter as “devices 110”), which have been suitably configured to provide quality of service information to the NMS 100. The NMS 100 in turn communicates with the network operation center (NOC) 120, which is not part of the invention and is typically resident at the premises of a network service provider.
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 FIG. 1 as a Central Configuration Server (CCS) 130, a SPI 140, and a Service Level Assurance (SLA) module 150. The exchange between an SPI-enabled device 110 and the SLA module 150 begins when an SPI-enabled device 110 provides information such as, for example, ID, location, IP address, and/or other relevant information. When an SPI-enabled device 110 contacts the SLA module 150, the SLA module 150 queries, via the SPI 140 and CCS 150, the appropriate SPI enabled devices 110A-n, which in turn responds to the queries and provide appropriate information concerning location, connect attempts, failures, signal strength, available and effective data rates, and any other status or location information which the carrier deems appropriate.
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 FIG. 2, one exemplary configuration of the CCS 130 can be better appreciated. The CCS 130 allows carriers, PC-OEMs, and Enterprises to manage the storage and flow of updates and upgrades to clients from a single location, and can further provide reporting and tools to manage the ability to push new data to clients. The CCS 130 operates to provide version control, code management, and flow control for all updateable features within the Roaming Client software. 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. The CCS 130 also allows the carrier, PCOEM, or Enterprise to manage versioned software files, such as executable files of the Roaming Client application and user interface skins. In addition the CCS 130 can be used in conjunction with the Roaming Client to update other files on a user's PC that are not directly related to the roaming client application, such as device drivers.
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 FIG. 2, it can be appreciated that the CCS architecture 200 includes an operating system layer 210 that communicates with the selected operating system (not shown), which in the illustrated example is Windows 2000 Advanced Server. A web application server 220, which may for example be based on the J2EE standard and certified on Jakarta Tomcat, layers atop the OS layer 210, as does a database module 230, which may, for example, be compliant with SQL 2000 and certified on MS SQL Server. Layered atop the application server module 220 and database module 230 are various modules for managing connections via different protocols. Thus, for example, Wi-Fi connection data is managed at 240, GPRS connection data is managed at 250, Location Finder data is managed at 260, and Custom Application data is managed at 270.
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 FIGS. 3 and 4, the operation of the SPI 140 can be better appreciated from the procedure for login and authentication. In this example, a provider deploys a hotspot and deploys a server that supports the SPI protocol. A user associates with the hotspot and physically establishes a connection between the client machine and the hotspot.
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 FIG. 3, the Roaming Client will only initiate SPI transactions to servers that are considered “trusted”, or in the providers “White List”. This will allow the provider to send back to the Client pre-authentication actions to be executed. After authentication, the client will again post its INFO status to the SPI server, allowing post-authentication actions to be executed by the client. Finally, when the client disconnects, final messages can be executed related to disconnection from the network.
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 FIG. 4, no actions can be executed by the SPI server until the client has authenticated to the network, but all appropriate actions can be taken once the client has authenticated.

Referring next to FIG. 5, the SPI protocol is shown in an exemplary arrangement, wherein the SPI protocol is primarily based on two message packages: INFO and ACTION. The INFO or information message communicates from the client to the SPI server the client's current status. The, ACTION message communicates from the server to the client an action that the SPI server wants the client to execute. Thus, an INFO message may comprise, for example,



	<status> the current state of the client</status>
	<username>username</username>
	<password>password of user </password>
	<error> reported error code</error>
	<provider> the name of the service provider</provider>
	<location>Geographic location of basestation </location>
	<sessionid> session id generated</sessionid>
	<ip> ip address of users device </ip>
	<mac> MAC address of users adapter</mac>
	<bssid>access point mac address</bssid>
	<linkspeed>reported link speed from basestation</linkspeed>
	<rssi>reported signal strength from basestation</rssi>
	<hwvendor>hardware vendor of basestation</hwvendor>
	<driverversion>software driver version</driverversion>
	<hostname>basestation host name</hostname>
	<wisprattribs>WISPr attributes supported</wisprattribs>
	<popid>POP Identification name</popid>
	...
	...
	...(Other Parameter/Value pairs)
	</>

Similarly, the ACTION message may take the form



	<actions>
	<action name =”ACTION NAME”>
	<parameter name=”PARAMETER NAME”
	type=”single”>
	<value> VALUE </value>
	</parameter>
	</action>
	</actions>
	</>

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 FIG. 6, a representation of an SPI message exchange sequence 600 between a client and a server according to the present invention is shown. The SPI message 600 describes an idealized login scenario for a user who has an already-existing subscription and has successfully logged in at a particular carrier's hotspot and completed the upload successfully. As noted above, the transactions described in this section happen in an automated fashion when the client or MMD arrives at a hotspot hosted by a wireless service provider, the following sequence happens with no or limited user interaction.
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 (FIG. 5), the SPI client component embedded in the MMD makes a request to the SPI server with its current INFO. In this example, State =Connected, but not logged in. At SPI Server Response 608, the SPI server responds with an Action message as required by the protocol definition. Because the client device state is not “Logged In,” the SPI server sends an Action message to the client, in this case “login” action, which also contains a URL to the authentication server in the form of a parameter name/value pair in the login message. At Client Request 610, the client parses the action message and then responds with a POST request to the authentication server URL providing the user name and password or a single unique device code embedded in the device. At Authentication Server Response 612, the authentication server responds with a successful login message. At 614, the client sends a start upload request. At 616, the server responds with a start upload command sending the upload location URL as a parameter. At 618, the client MMD parses the location URL and begins upload to that location. At 620, the server responds with an affirmative on upload complete.
A further example of authentication is shown in FIGS. 7A-7D, with an attempt to connect to an Acme Company server. Referring first to FIG. 7A, the user connects to Acme's wireless network through Acme's AP. The user makes a request to a URL outside of Acme's “white list” of “free” servers. The request passes through to the Acme's Network Access Server (NAS), which verifies whether the user has been authenticated. The next step could occur through alternative processes. In one exemplary arrangement, CCS attributes initially pushed to the SPI-enabled device are used by the SPI device as the parameters for connecting to the network. For example, the Roaming Client 110will use parameters pushed to it from CCS during client updates for authentication purposes.
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 FIG. 7B.

In FIG. 7B, the client parses the information from the NAS response, then initiates an http request to the SPI server to report the client's status as part of the INFO package message. The SPI server URL was previously provided by the CCS in a Client update Configuration. The INFO package below represents the message that the client will send to the SPI server in this example.



	<Seque version - “1.0”>
	Status>Connected/status>
	<username></username>
	<password></password>
	<error></error>
	<provider>Acme Wireless</provider>
	<location>location1</location>
	<sessionid></sessionid>
	<1p>192.168.11.1</ip>
	<mac>AA-BB-CC-DD-EE-FF</mac>

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 FIG. 7C. In this example, the SPI server responds with an Action message to prompt the user for credentials, execute a login, then send an INFO message package back to the SPI server. In the exemplary arrangement shown in FIGS. 7A-7D, each action will be executed in the order received.
Referring next to FIG. 7D, the client then executes the actions specified by the SPI server. The client prompts the user for username and password (credentials), and then executes the “login” action directive. In the case of username and password, a specific action is sent by the Acme's SPI server to direct the client to prompt the user to input the username and password: <action>promptCredentials</action>.
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 FIG. 7B.
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 FIG. 8, the process of authentication of a client begins at step 800. At step 802, the client initiates a communication session with an access point device or an access point interface (API) and attempts to access the Internet. At step 804, the API determines, based on communication with the service provider's authentication server and the associated database, if the client is an authenticated client. If so, then at step 806 the client is allowed to access the desired URL. If not, then at step 808 the client is directed to an SPI resident on a NMS. It will be apparent to one of skill in the art that the SPI may be operating on its own server and not as part of the NMS and hence be a stand alone server. At step 810, the SPI of the NMS queries the client for information and the client provides the relevant information for authentication. At step 812, the SPI of the NMS pushes an ACTION to the client for automatic sign-on and the URL necessary for the communication session. The process continues at step 806 until the client initiates termination of the communication session. At step 814, the SPI of the NMS receives the termination request and determines if the termination and logoff process should be initiated. If not, then the process remains at step 814 until it is time to initiate the termination process. When it is time to initiate the termination, at step 816, the SPI of the NMS pushes a termination ACTION to the client. The client terminates the session and disconnects from the AP.
The INFO message can be configured to provide to the NMS 100 (FIG. 1) a variety of information suitable for monitoring and management of a network. Alternatively, and in some embodiments a presently preferred arrangement, the client can be configured to maintain an event log containing a record of various events, which can be uploaded to the NOC 120 through the NMS 100 upon request.

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:



Parameter
Name	Description	XML Syntax Example

status	The Status attribute	<status>loggedin</status>
	provides information
	about the client to the
	server side logic and to
	allow the server to
	determine a set of actions
	that should be performed
	by the client.
	The possible states that
	are supported in the
	status element are listed
	in “Table 2: Supported
	Status Attributes” below.
username	Username information	<username>someuser</username>
	allows access to the user's
	account and displaying of
	appropriate content for
	user account status. If not
	provided, the server
	assumes this is a new
	customer. However, a link
	may be provided allowing
	existing users to enter
	existing
	username/password
	manually.
realm	The realm attribute as	<realm>@provider.com</realm>
	entered by the user or
	inserted by the client that
	represents the realm the
	user is authenticating to.
password	Password information is	<password>somepass</password>
	required for accessing
	user's account. If not
	provided, the server
	should prepopulate
	username field and
	prompt user to enter
	password before being
	able to access account
	info.
error	Error codes provide	<error>0</error>
	additional information	Error Codes Vary with
	about the client status	access mode.
	and why that condition
	occurred. Error codes are
	relative to the technology
	that is currently being
	used:
	Wi-Fi error codes are
	generated by the local AP
	based on API method i.e.
	WISPr.
	GPRS error codes are
	generated either by the
	dial in RAS server or the
	GPRS network.
	Modem error codes are
	generated by the dial in
	RAS.
provider	Provider identifier passed	<provider>CarrierXYZ</provider>
	by the local NAS.
location	Location identifier passed	<location>wp_700</location>
	by the local NAS.
sessionid	Session identifier passed	<sessionid>12345</sessionid>
	by the local NAS. In some
	instances the session id
	may be generated by
	RADIUS. Session id will
	be collected if present,
	although many providers
	may not generate a
	session id.
securitytype	The type of security used	<securitytype>EAP-
	in the authentication of	TTLS</securitytype>
	the user to the network.
	Possible values:
	Empty Field
	WEP-Open
	WEP-Closed
	EAP-TTLS
	EAP-TLS
	EAP-PEAP
	EAP-LEAP
	EAP-TKIP
	EAP-PSK
ip	Current IP address of the	<ip>192.168.11.1</ip>
	client machine.
mac	MAC address assigned to	<mac>AA-BB-CC-DD-EE-FF</mac>
	the client machine.
bssid	The base station (Access	<bssid>AA-BB-CC-DD-EE-FF</bssid>
	Point) id
linkspeed	The reported link speed in	<linkspeed>11000000</linkspeed>
	bps.
	i.e. 11 Mbps Wi-Fi
	connections is reported as
	11000000. 56 Kbps
	modem connection is
	reported as 56000.
rssi	The reported signal	<rssi>−48</rssi>
	strength as reported by
	the adapter in dBm.
hwvendor	The adapter vendor as	<hwvendor>acme_ap</hwvendor>
	reported by the adapter.
driverversion	The driver version as	<driverversion>1.2.43.2</driverversion>
	reported by the adapter.
hostname	The reported hostname of	<hostname>acme_wireless
	the AP	</hostname>
popid	POP user identifier	<popid></popid>
	information. This field	Dial Connection only
	contains the unique user
	id the provider assigns to
	each user.
hispid	Home ISP id.	<hispid></hispid>
hispsubid	Home sub ISP id	<hissubid></hissubid>
connecttime	Timestamp when users	<accesstime>2207520000
	establish the connection	</accesstime>
	in milliseconds since
	midnight Jan. 1, 1970
	GMT
authtime	Timestamp when the user	<authtime>2207520000</authtime>
	authenticates to the
	network in milliseconds
	since midnight Jan. 1,
	1970 GMT
logofftime	Timestamp when the user	<logofftime>2207520000</logofftime>
	logs out of the network in
	milliseconds since
	midnight Jan. 1, 1970
	GMT
disconnecttime	Timestamp when the user	<disconnecttime>2207520000
	is disconnected from the	</disconnecttime>
	network in milliseconds
	since midnight Jan. 1,
	1970 GMT
sessionduration	Total connection time	<duration>Seconds</duration>
	between authentication
	and logout.
setup	Setup time. Total time in	<setup>Connection setup
	milliseconds between	time in
	connect time and	milliseconds</setup>
	authentication to the
	network. (authtime -
	connecttime).
bdial	Blind dial is set to ‘N’ for	<bdial>Y</bdial>
	No Blind dial or ‘Y’ to
	indicate a Blind dial. This
	information is supported
	in Analog, ISDN, DoPA
	and PIAFS access modes.
	BDIAL will be set to ‘N’ by
	default.
clientversion	Version of the client.	<clientversion>1.3.2.1234
		</clientversion>
		Format: w.x.y.z
		w = Major Software
		version
loccode	It indicates the Country	<loccode>44+207</loccode>
	code and Area code.
clientid	Unique client identifier	<clientid>1234567890</clientid>
	provided by the client.
devtype	The device type used for	<devtype>wifi</devtype>
	accessing the network.
	Possible modes are: wifi,
	gprs, isdn, dsl, cable, phs,
	ethernet, modem.
phonenumber	Full Phone number string	<phonenumber>011+44+
	used for the connection.	207+12345678</phonenumber>
	The Phone number used
	for the connection in case
	of Analog, ISDN, PHS
	access modes shall be
	provided.
overphone	An alternate override	<phonenumber>011+44+
	phone number that is	207+12345678</phonenumber>
	used as in for Analog,
	ISDN, PHS access modes.
os	Operating system on	<os></os>
	which the client is
	installed.

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.

TABLE 2


Supported Status attributes. (See Table 1: INFO message
<status> parameter).

Status Name	Description	XML Syntax

connected	Client is connected to a	<status>connected</status>
	wireless network.
loggedin	Client has successfully	<status>loggedin</status>
	performed Login
	operations using Login
	API.
loginfailed	Client has attempted	<status>loginfailed</status>
	Login operations, but the
	login has failed due to an
	error or some other
	known or unknown
	problems.
loggedout	Client has successfully	<status>loggedout</status>
	performed Logout
	operations using Login
	API.
logoutfailed	Client has attempted	<status>logoutfailed</status>
	Logout operations, but
	the logout has failed due
	to an error or some other
	known or unknown
	problems.
disconnecting	Client has logged off and	<status>disconnecting
	is about to physically	</status>
	disconnect from the
	network. This status will
	only be applicable in
	instances where the client
	still has network
	visibility although
	not authenticated.

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:

TABLE 3


ACTIONS

Name	Parameters	XML Syntax Example

launchMiniBrowser	Url width	<action name=”launchMiniBrowser”>
	height	<parameter name=”url”
	status	type=”single”>
	statusnote	<value>https://www.someurl.com</
		value>
		</parameter>
		<parameter name=”width”
		type=”single”>
		<value>320</value>
		</parameter>
		<parameter name=”height”
		type=”single”>
		<value>240</value>
		</parameter>
		<parameter name=”status”
		type=”single”>
		<value>Please wait for page to
		load</value>
		</parameter>
		<parameter name=”statusnote”
		type=”single”>
		<value>It may take up to 45 seconds
		to load page<value>
		</parameter>
		</action>
closeMiniBrowser	—	<action name=”closeMiniBrowser”/>
login	attempts	<action name=”login”>
		<parameter name=”attempts
		type=”single”>
		<value>3</value>
		</parameter>
		</action>
logout	—	<action name=”logout”/>
setUserInfo	username	<action name=”setUserInfo”>
	accountURL	<parameter name=”username”
		type=”single”>
		<value>johndoe</value>
		</parameter>
		<parameter name=”accountURL”
		type=”single”>
		<value>htt//accounts.mc.com?id=johndoe
		</value>
		</parameter>
		</action>
promptPassword	username	<action name=”promptPassword”>
		<parameter name=”username”
		type=”single”>
		<value>johndoe</value>
		</parameter>
		</action>
showDialog	message	<action name=”showDialog”>
	width	<parameter name=”message”
	height	type=”single”>
		<value>CarrierXYZ
		Message...</value>
		</parameter>
		<parameter name=”width”
		type=”single”>
		<value>250</value>
		</parameter>
		<parameter name=”height”
		type=”single”>
		<value>350</value>
		</parameter>
		</action>
LaunchDefaultBrowser	url	<action
		name=”launchDefaultBrowser”>
		<parameter name=”url”
		type=”single”>
		<value>http://www.carrierXYZ.com
		</value>
		</parameter>
		</action>
sendInformation	url	<action name=”sendInformation”>
	method	<parameter name=”url”
	parameter1	type=”single”>
	parameter2	<value>http://someurl.com</value>
	.	</parameter>
	.	<parameter name=”method”
	.	type=”single”>
	parameterN	<value>POST</value>
		</parameter>
		<parameter name=”username”
		type=”single”>
		<value>%username%</value>
		</parameter>
		<parameter name=”returnURL”
		type=”single”>
		<value>http://wifi.qpass.com?id=johndoe
		</value>
		</parameter>
		</action>
connect	—	<action name=”connect”/>
disconnect	—	<action name=”disconnect”/>
sendStatusInfo	—	<action name=”sendStatusInfo”/>
setTimer	sessionTime	<action name=“setTimer”>
		<parameter name=“sessionTime”
		type=“single”>
		<value>85448</value>
		</parameter>
		</action>
downloadFile	forceOverwrite	<action name=“downloadFile”>
	remote	<parameter name=“forceOverwrite”
	local	type=“single”>
		<value>yes</value>
		</parameter>
		<parameter name=“remote”
		type=“single”>
		<value>http://www.pctel.com/mySkin
		.skx</value>
		</parameter>
		<parameter name=“local”
		type=“single”>
		<value>foo.skx</value>
		</parameter>
		</action>
loadSkin	file	<action name=“loadSkin”>
		<parameter name=“file”
		type=“single”>
		<value>foo.skx</value>
		</parameter>
		</action>
licenseAdjustment	adjustmentDays	<action name=“licenseAdjustment”>
	adjustmentType	<parameter
		name=“adjustmentDays”
		type=“single”>
		<value>10</value>
		</parameter>
		<parameter
		name=“adjustmentType”
		type=“single”>
		<value>relative</value>
		</parameter>
		</action>
showMessage	message	<action name=“showMessage”>
	url (optional)	<parameter name=“message”
	browserType	type=“single”>
	id	<value>click here</value>
		</parameter>
		<parameter name=“url”
		type=“single”>
		<value>http://www.pctel.com</value
		>
		</parameter>
		<parameter name=“browserType”
		type=“single”>
		<value>default</value>
		</parameter>
		<parameter name=“id”
		type=“single”>
		<value>ApiMessage</value>
		</parameter>
		</ACTION>

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:



	HTTP/1.0 404 UNAUTHORIZED
	Server: MC SSG/0.0.0 (Linux)
	Location: http://www.acme.come/index.htm
	MacAddr:AA-BB-CC-DD-EE-FF&IpAddr:192.168.11.1
	...
	<!-Location-Name=AcmeWireless>
	<!-Location-ID=Location1>
	<!-error=0>
	<!-Login-URL=https://login1.AcmeWireless.com/Login>
	<HTML>
	...

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.