(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0061315 A1
`(43) Pub. Date:
`Mar. 27, 2003
`Jin
`
`US 20030061315A1
`
`(54) SYSTEM AND METHOD FOR "PLUG AND
`PLAY" ABILITY TO BROADBAND
`NETWORK BASED CUSTOMER DEVICES
`(76) Inventor: Frank Kui Jin, Sammamish, WA (US)
`Correspondence Address:
`FRANK K. JIN
`20041 SE 24th St.
`Sammamish, WA 98.075 (US)
`(21) Appl. No.:
`10/244,116
`(22) Filed:
`Sep. 16, 2002
`Related U.S. Application Data
`(60) Provisional application No. 60/324,503, filed on Sep.
`25, 2001.
`
`Publication Classification
`
`(51) Int. Cl." ......................... G06F 15/177; G06F 15/16
`(52) U.S. Cl. ............................................ 709/220; 709/203
`(57)
`ABSTRACT
`A distributed broadband network comprises of unconfigured
`broadband-based customer devices or network computers
`
`ACS
`
`and at least one auto configuration and monitoring Server. A
`network protocol called Plug and Play Host Protocol (PPHP)
`is defined to facilitate the automatic connections between an
`auto configuration Server and a number of unconfigured
`broadband customer devices or network computers. The
`customer device determines on power on time if it has been
`identified and configured through the auto configuration
`Server. If the identification and configuration information are
`lacking, the customer device Sends an identification and
`configuration request to the auto configuration Server using
`a multicast message with a predefined multicast group.
`Upon receiving the identification request from a new cus
`tomer device, the auto configuration Server chooses a unique
`computer name for the customer device and Sends the
`computer name along with Some other initialization infor
`mation to the customer device using another multicast
`message with another predefined multicast group. The cus
`tomer device uses the unique computer name and other
`configuration information received to configure itself and
`establish connections to the Service providers in the net
`work. After the initial discovery and configuration phase, the
`connection channels established between an auto configu
`ration Server and a plurality of managed customer devices
`are used continuously for automatic monitoring and remote
`management of the customer devices.
`
`Unicast
`
`
`
`1 SiGNON Message (ACC to ACS)
`Multicast
`2. INIT Message (ACS to ACC)
`Multicast
`3 NATOONE Message (ACC to ACS)
`
`:
`
`Router
`
`Acronym
`ACS auto configuration server
`SRA subnet relay agent
`ACC:auto configuration client
`
`
`
`1. SIGNON Message ACC to SRA)
`Muticast
`4.INIT Message SRA to ACC)
`Multicast
`
`Exhibit 1008
`IPR2023-00581
`U.S. Patent 8,886,772
`
`Page 1 of 9
`
`

`

`Patent Application Publication Mar. 27, 2003 Sheet 1 of 3
`
`US 2003/0061315 A1
`
`Figure 1
`
`ACS
`
`Segment/Subnet 1
`P address 192.168.0.X
`Mask 255.255.255.128
`
`
`
`
`
`
`
`Segment 2
`P address: 17216.0.X
`Mask 255.255.O.O
`
`Subnet 2
`P address: 192.168.0.X
`Mask 255.255.255.192
`
`Acronym
`ACS: auto configuration server
`SRA. subnet relay agent
`ACC: auto Configuration client
`
`Page 2 of 9
`
`

`

`Patent Application Publication Mar. 27, 2003. Sheet 2 of 3
`ACS
`
`
`
`US 2003/0061315 A1
`
`
`
`Ethernet
`
`i
`
`1 SIGNON Message (ACC to ACS)
`Multicast
`2. INIT Message (ACS to ACC)
`Multicast
`3 NIT DONE Message (ACC to ACS)
`Unicast
`
`
`
`
`
`
`
`Acronym
`ACS. auto configuration server
`SRA subnet relay agent
`ACC: auto configuration client
`
`4. INIT Message (SRA to ACC)
`Multicast
`
`5. INIT DONE Message (ACC to SRA)
`
`Unicast
`
`Page 3 of 9
`
`

`

`Patent Application Publication Mar. 27, 2003 Sheet 3 of 3
`
`US 2003/0061315 A1
`
`Figure 3
`
`
`
`
`
`Subnet Relay
`Agnet
`
`
`
`Multicast
`
`Acronym
`ACS. auto configuration server
`SRA. Subnet relay agent
`ACC. auto configuration client
`
`Page 4 of 9
`
`

`

`US 2003/0061315 A1
`
`Mar. 27, 2003
`
`SYSTEMAND METHOD FOR "PLUG AND PLAY"
`ABILITY TO BROADBAND NETWORK BASED
`CUSTOMER DEVICES
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`0001. This application is related to U.S. provisional
`patent application No. 60/324,503 still pending, entitled
`“System and method for “Plug and Play ability to broadband
`network based customer devices”, filed on Sept. 25, 2001,
`which is hereby incorporated by reference.
`
`BACKGROUND OF THE INVENTION
`0002 ATCP/IP based broadband customer device, such
`as a high end Settop box, is actually a high performance
`network computer. These broadband customer devices typi
`cally roll off a production line with the same operation
`image. That means that all of the customer devices have the
`exact Same network identity and a default configuration
`when they leave the production line. They have to undergo
`Some Sort of configuration procedure before they can be
`used in a Specific intranet environment by end users. The
`most important Step in this configuration procedure is to Set
`a proper network identity for each of the customer devices
`in an intranet based on a predefined Scheme. There are
`usually Some other configuration Steps in the configuration
`procedure, Such as Setting up IP addresses for different
`network Servers in the customer devices. Because these
`customer devices are usually deployed with a large quantity
`in a customer environment, it is desirable that the configu
`ration procedure can be performed automatically without
`any user intervention.
`0003. The configuration methods currently used can be
`classified as either (a) sending a trained technician to cus
`tomer Sites to do the manual configuration for each customer
`device or each network computer; (b) Shipping a detailed
`configuration manual with each broadband-based customer
`device and asking the end user to perform the configuration
`by reading the User's Manual. Neither of the methods is
`Suitable for a large-scale deployment of the broadband
`based customer devices because of the need of the manual
`configuration on the client Side.
`0004. After the initial network configuration to all of the
`managed customer devices, how to monitor and manage
`them remotely on the daily basis is another major concern to
`the service providers. Therefore, a platform that provides the
`mechanism for remote and automatic management of broad
`band customer devices in a point-to-points mode without
`using any significant bandwidth is much needed for IT
`perSonnel to manage a large number of the broadband based
`customer devices efficiently.
`0005 The system and method presented in this invention
`provide a complete Solution to both of the automatic initial
`configuration and daily remote management to the broad
`band-based customer devices.
`
`BRIEF SUMMARY OF THE INVENTION
`0006 The present invention overcomes the shortcoming
`of the above-mentioned methods by providing a completely
`automated System and method for configuring and monitor
`ing broadband-based customer devices. With this invention,
`
`the configuration process on the client Side is as simple as
`plugging in the broadband connection and turning on the
`power for each customer device. Thus, the configuration of
`the broadband-based customer device is completely trans
`parent to the end user. Furthermore, the invention provides
`the ability to automatically monitor and remotely manage
`broadband-based customer devices from a centralized auto
`configuration Server.
`0007. In summary, the present invention is a system and
`method for the automatic configuration and remote manage
`ment of broadband-based customer devices from a central
`ized auto configuration Server. The auto configuration Server
`has a client information database (CIDB) that contains all of
`the configuration information for each managed customer
`device. The core of the invention is a client-Server commu
`nication protocol between the auto configuration Server and
`the managed customer devices, which is called as Plug and
`Play Host Protocol (PPHP), as summarized below. The
`communication mechanism established by using PPHP
`between the auto configuration Server and managed cus
`tomer devices can be used to perform automatic monitoring
`and remote management of the managed customer devices
`from the centralized auto configuration Server.
`0008. The PPHP specifies shared multicast groups and
`communication sequences between a PPHP server (part of
`the auto configuration server) and multiple PPHP clients
`(broadband-based customer devices). APPHP server should
`be configured and up running before any PPHP clients can
`be connected to the network. The PPHP server must join
`SIGNON SVR, a predefined multi-cast group, to wait for
`the connection requests from any PPHP clients. In addition,
`the server needs to setup a unicast port called SVR ACK
`PORT to listen acknowledgements and Some potential
`errors from clients.
`0009. When a new PPHP client first appears on the
`network, it joins INIT GROUP, another predefined multi
`cast group, and Sends out a configuration request, SIGNON,
`with its identification information to the PPHP server using
`a multicast message to SINGON SVR. Upon receiving the
`SIGNON message from a new client, the server builds up an
`initialization message using the information from CIDB and
`the client's request. Then it sends out the initialization
`message, INIT, to INIT GROUP as a multicast message
`because at this point the client who Supposes to get the
`message may have not been configured with a proper IP
`address. Because of the hardware identification contained in
`the initialization message, the targeted client will be the only
`one to process the INIT message. The client must send the
`configuration request repeatedly until it receives its initial
`ization message. After processing the initialization message,
`the client must send an INIT DONE message to
`SVR ACK PROT. Then the client needs to join GEN
`CONFIG GROUP, a predefined multicast group for a com
`mon configuration update, and listen on SPE CFG PROT,
`a predefined unicast port for any Specific configuration
`update.
`0010. The invention completely eliminates the need to do
`any manual configuration on the client Side for broadband
`based customer devices or any network computers that
`support TCP/IP multicasting. The administrator uses the
`auto configuration Server to configure all of the managed
`PPHP clients. After the initial configuration, the PPHP
`
`Page 5 of 9
`
`

`

`US 2003/0061315 A1
`
`Mar. 27, 2003
`
`clients-server infrastructure is used for daily System updates
`and performance monitoring of the broadband-based cus
`tomer devices.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0.011
`FIG. 1 is a typical network topological structure
`wherein there are an auto configuration server (ACS), a
`number of auto configuration clients (ACC) located in
`different Subnets or Segments and two Subnet relay agents
`(SRA).
`0012 FIG. 2 illustrates the PPHP messages among an
`ACS, a SRA and a number of ACCs. As described in the
`diagram, a SRA is responsible to relay all of the PPHP
`multicast messages from the ACCS within the same Subnet
`or segment to a connected ACS. All of the PPHP unicast
`messages are communicated directly between an ACS and
`ACC(s).
`0013 FIG. 3 is a system block diagram for the invention.
`It gives more details about the components in an ACS.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`0.014. This invention creates a network system structure,
`as illustrated in FIG. 1, which comprises five major sub
`systems: a Configurator, a PPHP Server, a Client Informa
`tion Database (CIDB), and a plurality of PPHP Clients and
`a plurality of PPHP Relay Agents. As displayed in FIG. 3,
`an Auto Configuration Server (ACS) is comprised of a
`Configurator, a PPHP Server and a CIDB. A PPHP Client
`can also be called as an Auto Configuration Client (ACC).
`A PPHP Relay Agent is also called as a Subnet Relay Agent
`(SRA). The five subsystems are related together by Plug and
`Play Host Protocol (PPHP) as described below.
`0015 The core idea for PPHP is to provide a reliable
`mechanism using multicast communications to let network
`computerS automatically get their network configuration
`information from a centralized server even before the net
`work computers are properly configured. The only assump
`tion PPHP made is that the network supports TCP/IP mul
`ticasting.
`0016 PPHP specifies a series of messages used to estab
`lish the connections and facilitate the communications
`between a PPHP Server and a number of PPHP Clients, as
`described in FIG. 2.
`0017) 1. SIGNON Message: This is a multi-cast
`message that is used by a new client to connect to a
`PPHP Server through a predefined multi-cast group.
`The message contains: message ID that is SIGNON,
`MAC address of the computer, and etc.
`0018 2. INIT Message: This is also a multicast
`message that is used by the PPHP Server to send the
`initialization data to a specific new client. The mes
`sage contains: message ID that is INIT, MAC
`address of the targeted client machine, computer
`name that is assigned to the client machine, the
`PPHP Server's IP address/host name and the server's
`unicast listening port, and etc.
`0019. 3. INIT DONE Message: This is a unicast
`message from a client to the Server's listening port to
`notify the server that the client has successfully
`
`processed the INIT message. The message contains:
`message ID that is INIT DONE, the client's com
`puter name, and etc.
`0020 4. GEN CONFIG Message: This is a multi
`cast message that is used for the Server to Send
`general configuration updates to a number of clients.
`The message contains: message ID that is GEN
`CONFIG, a serial number to identify this GEN
`CONFIG message, hostname mask that define the
`group to receive the message, a list of configuration
`data and etc.
`0021 5. GEN CFG ACK Message: This is a uni
`cast message from a client to the Server to acknowl
`edge the receiving of a specific GEN CONFIG
`message. The message contains: message ID that is
`GEN CFG ACK, the serial number and the host
`name and etc.
`0022 6. SPE CONFIG Message: This is a unicast
`message from the Server to a specific client to update
`the client's configuration. The message contains:
`message ID that is SPE CONFIG, a serial number,
`a list of configuration data and etc.
`0023 7. CLIENT ERR Message: This is a unicast
`message for a client to report Some error conditions
`to the Server. The message contains: message ID that
`is CLIENT ERR, hostname, the message ID that the
`error is related to, error message and etc.
`0024 8. STILL ALIVE Message: This is a unicast
`message sent from a client to server's SVR ACK
`PORT periodically. The message contains: message
`ID that is STILL ALIVE, hostname and etc.
`0025 PPHP defines following multicast groups and
`Socket ports:
`0026 1. SIGNON SVR: This multicast group is
`used to facilitate the initial connections between a
`server and a number of clients before the network
`configurations of the clients are properly done. The
`PPHP Server is the only one to join the group and
`listen to SIGNON requests from a number of clients.
`A new PPHP client needs to send a multicast mes
`sage, SIGNON, to this group.
`0027 2. INIT GROUP: this is a multicast group
`that all of the clients will join in initially to receive
`the initial INIT packages from the server. A PPHP
`Server uses this group to Send out the multicast
`message, INIT, to new PPHP clients.
`0028) 3. GEN CONFIG GROUP: this multicast
`group is used to implement the configuration updates
`for the whole group or part of the group. All of PPHP
`clients join in this group and a PPHP server sends out
`multicast message, GEN CONFIG, to this group.
`0029 4. SVR ACK PORT: this is the server port to
`listen the acknowledgements or Some potential
`errors from clients.
`0030) 5. SPECFG PORT: this is the client port to
`receive customized configuration messages from the
`SCWC.
`
`Page 6 of 9
`
`

`

`US 2003/0061315 A1
`
`Mar. 27, 2003
`
`0031) To establish an initial connection between a PPHP
`server and PPHP clients, and configure the clients as speci
`fied, the following Sequence of messages will be sent
`between the Server and clients.
`0032) 1. PPHP clients join INIT GROUP multicast
`group to listen to INIT messages. Then, in order to
`look for a PPHP server, every PPHP client will send
`out SIGNON request
`to
`multicast group,
`SIGNON SVR, repeatedly until it receives the INIT
`message specific for itself.
`0033 2. After the server receives a SIGNON mes
`Sage, it builds up an INIT message using the infor
`mation from CIDB and the SIGNON message. Then
`it sends out the INIT message to INIT GROUP.
`0034) 3. All of the clients in INIT GROUP will
`receive every INIT message the server send out. But
`only the client found a matching MAC address
`processes the message.
`0035 4. After processing INIT message, the client
`must send out an INIT DONE message to
`SVR ACK PORT. At this time, the client needs to
`create two listening Sockets: one is to join GEN
`CONFIG GROUP; the second is on SPECFG
`PORT.
`0036 PPHP requires that the computer name for each
`client computer must be unique. When DHCP is used to
`assign an IP address to a client computer, the computer name
`is the only unique ID for the client. When a static P is used
`for a client computer, PPHP still uses the unique computer
`name to identify the client. This gives the system the ability
`to Switch the IP address type back and forth between DHCP
`and static IP for a client computer. PPHP provides three
`Schemes to assign a unique computer name to a new client
`computer (or a new customer device) as described below.
`0037 Scheme One: A pool of unique computer names is
`predefined and stored in a CIDB on the server side. For each
`new connected client, the Server will pick up a unique name
`Sequentially from the pool and assign the name to the new
`client automatically. This is the Simplest way to assign a
`unique computer name to a client computer. The only way
`to associate a client computer to a specific name in this
`Scheme is to control the Sequence of the connection to the
`Server for each client. For example, if you want a client
`computer to get the third name in the pool, you need to make
`Sure that the client is the third computer to connect to the
`Server, and So on.
`0.038 Scheme Two: A root name is predefined on the
`Server Side. For each new connected client, a popup window
`comes out on the client computer to let an end user to enter
`a client feature ID, Such as a room number in a hotel. Then
`the System will automatically build up a full computer name
`using the root name from the Server and the client feature ID,
`and assign the name to the client computer.
`0.039 Scheme Three: A pool of unique computer names
`is predefined on the Server Side. For each new connected
`client, the Server requires the client to provide a computer
`name that matches one of the names in the pool. If the
`existing name in the client computer does not match any
`name in the pool, a popup window comes out on the client
`
`computer to let an end user to enter a matching name, and
`then assign the matched name to the client computer.
`0040. The Configurator, as described in FIG. 3, is a
`utility Subsystem to allow network administrators to Specify
`the configurations to each managed client computers. In
`order to Save user's time to Survey current client informa
`tion, the Configurator Searches all connected clients using
`multicast communications even before they are properly
`configured. Therefore a user does not have to type in all of
`the computer names for each managed client computers if
`they don’t want to change them. The client network con
`figurations that can be specified with the Configurator
`include computer name, IP address, static IP or DHCP, DNS,
`WINS, Gateway IP and etc. After specifying the network
`configurations for each managed client, the information will
`be saved in CIDB to share between the Configurator and a
`PPHP Server.
`0041) The PPHP Server, as described in FIG. 3, is the
`Subsystem that monitors and manages all of PPHP clients at
`real time. It acquires the information about all of the
`managed clients from CIDB and also writes all of updated
`information about the managed clients back to CIDB. For
`each new client, the Server is responsible to listen to the
`SIGNON request, and build up and send out the INIT
`message. Then it also updates the connection Status on the
`server UI and in CIDB. After the connection phase, the
`server will manage the STILL ALIVE messages periodi
`cally Sent from each connected client to update the client
`connection Status. At runtime, the connection channels
`between the server and managed clients are used to remotely
`update the configurations, manage the client Systems and
`distribute files, and etc.
`0042. The Client Information Database (CIDB), as
`described in FIG. 3, is a central depositary for all of client
`related information. A Synchronization mechanism has been
`implemented in CIDB because it is a shared database
`between Configurator and PPHP Server. CIDB is a real time
`database. The information and Status for each online client
`can change at any time and the record for each client in
`CIDB must be updated accordingly.
`0043. The PPHP Client or ACC as described in FIG. 3
`runs in each managed customer device or client computer. It
`is responsible to send out SIGNON request repeatedly until
`it receives the INIT message expected. After processing the
`INIT message, it will send out INIT DONE message to the
`server. Then it sends out STILL ALIVE messages periodi
`cally to maintain the connection with the server. While
`connected, it listens to messages from the Server on GEN
`CONFIG GROUP and SPE CFG PORT, and processes
`the messages to update the client System or perform Some
`required taskS.
`0044) The PPHP Relay Agent or SRA as described in
`FIG. 3 is a subsystem to expand the applied scope of PPHP
`into the network where more than one Subnets or Segments
`exist. As described above, the core idea for PPHP is to
`automatically configure network computers from a central
`ized Server using multicasting. However, multicasting mes
`Sages usually cannot travel acroSS different Subnets or Seg
`ments. To make PPHP work for multiple subnets or
`segments, the PPHP Relay Agents are used to relay the
`PPHP multicasting messages between a PPHP Server and
`PPHP Clients located in different subnets or segments. The
`
`Page 7 of 9
`
`

`

`US 2003/0061315 A1
`
`Mar. 27, 2003
`
`communications between a PPHP Server and a PPHP Relay
`Agent are point-to-point TCP communication. The commu
`nications between a PPHP Relay Agent and the PPHP clients
`within the same Subnet or Segment are multicasting com
`munication.
`0045. As described in FIG.2, for a network with multiple
`subnets or segments, PPHP will work as following:
`0046) 1. All of the PPHP clients join a predefined
`multicasting group, INIT GROUP, to receive INIT
`messages from a PPHP server.
`0047 2. A PPHP client sends out SIGNON mes
`Sages repeatedly to the predefined multicasting
`group, SIGNON SVR, until it receives an INIT
`message specifically for itself.
`0048) 3. A PPHP relay agent joins SIGNON SVR
`group and receives all of the SIGNON messages
`from the Same Subnet or Segment.
`0049 4. After receiving a SIGNON message from
`the SIGNON SVR multicasting group, the PPHP
`relay agent relays the message to a PPHP server
`using point-to-point TCP message.
`0050) 5. A PPHP server joins SIGNON SVR mul
`ticasting group and also listens to all of the ports
`connected to PPHP relay agents.
`0051) 6. After receiving a SIGNON message from
`the SINGON SVR multicasting group, the PPHP
`server builds up an INIT message using the infor
`mation from CIDB and the SIGNON message for the
`client. Then it sends out the INIT message to the
`multicasting group, INIT GROUP.
`0.052 7. After receiving a SIGNON message from a
`port of a connected PPHP relay agent, the PPHP
`Server builds up an INIT message using the infor
`mation from CIDB and the SIGNON message for the
`client. Then it sends out the INIT message to the
`PPHP relay agent by using a point-to-point TCP
`communication.
`0053 8. After receiving an INIT message from the
`PPHP server, the PPHP relay agent sends out the
`INIT message to multicasting group, INIT GROUP,
`using multicasting communication.
`0054) 9. After receiving the matching INIT message
`on INIT GROUP, a PPHP client processes the mes
`Sage by configuring the local System using the infor
`mation from the INIT message.
`0055 10. After the configuration, the PPHP client
`sends out an INIT DONE message to the PPHP
`Server with a point-to-point TCP message.
`0056 Because a centralized ACS may need to manage
`Several hundreds or even thousands of ACCs, thread man
`agement is a critical issue in the implementation of the
`System. The present invention creates an efficient thread
`management method as described below. A thread manager
`is implemented to create and manage all of other work
`threads directly or indirectly. There are two categories of
`working threads in the System: constant threads and tempo
`rary threads. A constant thread is the one that always exists
`whenever the System is up running. A temporary thread may
`
`only exist for a short period of time to conduct a short-term
`task. All of constant threads are managed directly by the
`thread manager. Every constant thread needs to Send Still
`alive message periodically to the thread manager. There are
`two types of constant threads in the System: recoverable and
`non-recoverable. A recoverable thread is a thread that does
`not depend on other working threads. Therefore the thread
`manager can restart a recoverable thread individually at
`runtime if necessary. A non-recoverable thread is the one
`that cannot be restarted individually. Therefore the thread
`manager has to restart the whole System to recover from a
`failed non-recoverable thread. If one of the managed thread
`runs into a problem and stops Sending the Still-alive mes
`Sages, the thread manager will check the thread type first. If
`it is a recoverable thread, the thread manager will restart the
`thread to fix the problem. If it is a non-recoverable thread,
`the thread manager will restart the PPHP Server as a whole.
`0057 To handle short-term tasks for a large number of
`client computers in a random mode, Such as processing
`SIGNON messages, a growable thread pool is created in the
`system. While the number of pending tasks is low, the pool
`maintains a minimum number of threads. While the number
`of Simultaneous tasks increases, the number of threads in the
`pool grows too up to a limit to handle the Spontaneous tasks.
`For example, whenever a PPHP Server receives a SIGNON
`message, it dispatches a thread from the pool to process the
`SIGNON message. After finishing the task, the thread will
`return to the pool for next pending task. If the number of
`pending tasks excesses the number of available threads in
`the pool, the pool will automatically increase the number of
`threads up to a predefined limit to handle the Spontaneous
`tasks. While the number of pending tasks becomes low, the
`pool will automatically decrease the number of the threads
`in the pool to effectively conserve the System resources.
`0058 Other embodiments, combinations and modifica
`tions of this invention will occur readily to those of ordinary
`skill in the art in view of these teachings. Therefore, this
`invention is to be limited only to the following claims, which
`include all Such embodiments and modifications when
`Viewed in conjunction with the above description and
`accompanying drawings.
`
`I claim:
`1. A System for automatic configuration of broadband
`customer devices, comprising of an auto configuration
`server (ACS); a plurality of Subnet Relay Agents (SRA);
`and a plurality of auto configuration clients (ACC).
`2. A method for automatic configuration of broadband
`customer devices, comprising the Steps of:
`Receiving requests from the broadband customer devices
`for auto configuration;
`Receiving client identification information with each of
`the requests, wherein the client identification informa
`tion includes the MAC address and the alias, Such as a
`room number or phone number, associated with the
`broadband customer device;
`Using the received client identification information and a
`predefined client information database (CIDB) to deter
`mine a computer name for the customer device;
`
`Page 8 of 9
`
`

`

`US 2003/0061315 A1
`
`Mar. 27, 2003
`
`Using the received client identification information and
`CIDB to build a configuration package for each man
`aged client and Send the configuration package to the
`corresponding ACC,
`Receiving and processing the configuration package from
`acS to configure the broadband device for network
`communication.
`3. The method of claim 2, wherein the computer name
`determined based on a client identification information and
`a predefined CIDB is a human-friendly name and is used as
`the unique ID for the customer device in the System.
`4. The method of claim 3, wherein the unique computer
`name for each managed customer device is obtained through
`one of the three Schemes:
`Automatically assigning a unique name to a new client
`from a pool of predefined unique computer names,
`Combining a predefined root name and a client's feature
`ID, Such as a room number, to form a unique computer
`name for a client;
`Providing a name by a client that matches one of the
`unique names predefined in the CIDB.
`5. The method of claim 2, wherein Sending and receiving
`auto configuration requests using a predefined multi-cast
`grOup.
`
`6. The method of claim 2, wherein Sending and receiving
`auto configuration packages using a predefined multi-cast
`grOup.
`7. The method of claim 2, wherein the autoconfiguration
`attempt is conducted repeatedly until all of the managed
`clients are Successfully configured.
`8. The client information database (CIDB) of claim 2 is a
`central depository of all of client related information, which
`can be processed in real time.
`9. The system of claim 1, wherein each PPHP Relay Agent
`(SRA) establishes a direct TCP connection with an ACS and
`relays all of multi-cast communications between the ACS
`and ACCs in its own Subnet.
`10. The system of claim 1, wherein the connections
`among ACS, SRAS and ACCs are used for the further
`configuration and management of the broadband customer
`devices.
`11. The system claim 1, wherein the combination of a
`thread manager and a thread pool is used to provide reliable
`thread management and the ability to handle Spontaneous
`tasks in an ACS.
`
`Page 9 of 9
`
`