U.S. patent application number 11/089238 was filed with the patent office on 2006-02-23 for service level assurance system and method for wired and wireless broadband networks.
This patent application is currently assigned to Pctel, Inc.. Invention is credited to Robert Boxall, Biju Nair, Vojislav Samsalovic.
Application Number | 20060041931 11/089238 |
Document ID | / |
Family ID | 35064377 |
Filed Date | 2006-02-23 |
United States Patent
Application |
20060041931 |
Kind Code |
A1 |
Boxall; Robert ; et
al. |
February 23, 2006 |
Service level assurance system and method for wired and wireless
broadband networks
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.
Inventors: |
Boxall; Robert; (Elmhurst,
IL) ; Samsalovic; Vojislav; (Chicago, IL) ;
Nair; Biju; (Long Grove, IL) |
Correspondence
Address: |
PILLSBURY WINTHROP SHAW PITTMAN LLP
P.O. BOX 10500
MCLEAN
VA
22102
US
|
Assignee: |
Pctel, Inc.
Chicago
IL
60631
|
Family ID: |
35064377 |
Appl. No.: |
11/089238 |
Filed: |
March 23, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60555988 |
Mar 23, 2004 |
|
|
|
60555812 |
Mar 23, 2004 |
|
|
|
Current U.S.
Class: |
726/4 ;
726/1 |
Current CPC
Class: |
H04L 43/08 20130101;
H04W 28/14 20130101; H04W 4/18 20130101; H04L 41/5003 20130101;
H04W 12/062 20210101; H04L 63/162 20130101; H04L 67/125 20130101;
H04L 41/5067 20130101; H04L 43/12 20130101; H04W 74/00 20130101;
H04L 41/507 20130101; H04L 63/08 20130101; H04L 41/5009 20130101;
H04L 67/04 20130101; H04L 67/32 20130101; H04L 67/34 20130101; H04L
41/082 20130101; H04W 24/00 20130101; H04L 41/5035 20130101; H04W
76/10 20180201; H04L 67/18 20130101 |
Class at
Publication: |
726/004 ;
726/001 |
International
Class: |
H04L 9/00 20060101
H04L009/00; H04L 9/32 20060101 H04L009/32; G06F 17/00 20060101
G06F017/00; G06K 9/00 20060101 G06K009/00; H04K 1/00 20060101
H04K001/00; G06F 17/30 20060101 G06F017/30; G06F 15/16 20060101
G06F015/16; G06F 7/04 20060101 G06F007/04; G06F 7/58 20060101
G06F007/58; G06K 19/00 20060101 G06K019/00 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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.
[0002] 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
[0003] 1. Field of the Invention
[0004] 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.
[0005] 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.
[0006] 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
[0007] 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.
THE FIGURES
[0008] 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:
[0009] FIG. 1 illustrates in block diagram form the interoperation
of the present invention with a service provider's network
operations center;.
[0010] FIG. 2 illustrates in block diagram form an exemplary CCS
architecture in accordance with the present invention;
[0011] FIG. 3 illustrates in time line form an exemplary SPI
client-server transaction where the SPI server is in the network
provider's "Whitespace";
[0012] 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";
[0013] FIG. 5 illustrates a simple message exchange sequence
between the SPI client and the SPI server;
[0014] FIG. 6 illustrates a message exchange between the SPI client
and the SPI server involving authentication;
[0015] FIG. 7A-7D illustrate an authentication sequence in an
exemplary implementation of the present invention; and
[0016] FIG. 8 is a flow chart for the process of authenticating a
client.
DETAILED DESCRIPTION OF THE INVENTION
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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,
TABLE-US-00001 <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)
</>
[0040] Similarly, the ACTION message may take the form
TABLE-US-00002 <actions> <action name ="ACTION NAME">
<parameter name="PARAMETER NAME" type="single"> <value>
VALUE </value> </parameter> </action>
</actions> </>
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
TABLE-US-00003 <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>
[0048] It should be noted that some parameters are populated with
information, which may be provided, for example, by the NAS in the
prior step.
[0049] 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.
[0050] 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>.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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: TABLE-US-00004 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.
[0056] 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-US-00005 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.
[0057] 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-US-00006
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>
[0058] 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.
[0059] 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:
TABLE-US-00007 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> ...
[0060] 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.
[0061] 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.
* * * * *
References