U.S. patent application number 11/503830 was filed with the patent office on 2007-03-15 for method and system for booting, provisioning and activating hardware and software clients.
Invention is credited to Manoj K. Chaudhari, Richard M. Woundy.
Application Number | 20070058792 11/503830 |
Document ID | / |
Family ID | 37855115 |
Filed Date | 2007-03-15 |
United States Patent
Application |
20070058792 |
Kind Code |
A1 |
Chaudhari; Manoj K. ; et
al. |
March 15, 2007 |
Method and system for booting, provisioning and activating hardware
and software clients
Abstract
Automated booting of a client for a subscriber is provided for
clients that are for use in interactive user sessions that involve
multimedia. A subscribe message is sent from the client to a proxy
server. The proxy server authenticates the subscribe message, and
sends the subscribe message to the configuration server. A notify
message is sent to the client from the configuration server. The
notify message is sent through the proxy server, and contains a
location of a profile for the client. The profile is downloaded to
the clients. This arrangement allows the persistence of profiles in
a centralized place.
Inventors: |
Chaudhari; Manoj K.;
(Dayton, NJ) ; Woundy; Richard M.; (North Reading,
MA) |
Correspondence
Address: |
BROOKS KUSHMAN P.C.
1000 TOWN CENTER
TWENTY-SECOND FLOOR
SOUTHFIELD
MI
48075
US
|
Family ID: |
37855115 |
Appl. No.: |
11/503830 |
Filed: |
August 14, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60707639 |
Aug 12, 2005 |
|
|
|
Current U.S.
Class: |
379/88.17 |
Current CPC
Class: |
H04L 65/1006 20130101;
H04L 61/2514 20130101; H04L 61/2564 20130101; H04M 3/42178
20130101; H04L 29/12367 20130101; H04L 61/1511 20130101; H04L
29/12066 20130101; H04L 29/125 20130101; H04L 41/082 20130101; H04M
7/0081 20130101; H04L 29/06027 20130101; H04M 3/42144 20130101 |
Class at
Publication: |
379/088.17 |
International
Class: |
H04M 1/64 20060101
H04M001/64 |
Claims
1. A method for automated booting of a client for a subscriber, the
client being for use in interactive user sessions that involve
multimedia and being connected to a network, the network including
a configuration server and a proxy server, the method comprising:
sending a subscribe message from the client to the proxy server;
authenticating the subscribe message at the proxy server, and
sending the subscribe message from the proxy server to the
configuration server; sending a notify message to the client from
the configuration server, the notify message being sent through the
proxy server, and the notify message containing a location of a
profile for the client; and downloading the profile to the client
from its location, thereby allowing the persistence of profiles in
a centralized place.
2. The method of claim 1 further comprising: registering the client
with the proxy server to allow interactive user sessions that
involve multimedia.
3. The method of claim 1 further comprising: determining and
resolving the proxy server prior to sending the subscribe
message.
4. The method of claim 1 wherein the notify message further
contains a location of a software update for the client, the method
further comprising: downloading the software update to the client
from its location.
5. The method of claim 1 further comprising: adding a service to
the profile for the client; sending a notify message to the client
from the configuration server, the notify message being sent
through the proxy server, and the notify message containing a
location of an updated profile for the client; and downloading at
least a portion of the updated profile to the client from its
location.
6. The method of claim 1 further comprising: deleting a service
from the profile of the client; sending a notify message to the
client from the configuration server, the notify message being sent
through the proxy server, and the notify message containing a
location of an updated profile for the client; and downloading the
updated profile to the client from its location.
7. The method of claim 1 further comprising: modifying a service in
the profile of the client; sending a notify message to the client
from the configuration server, the notify message being sent
through the proxy server, and the notify message containing a
location of an updated profile for the client; and downloading the
updated profile to the client from its location.
8. The method of claim 1 wherein the client is a hardware
client.
9. The method of claim 1 wherein the client is a software client
executing on customer premise equipment.
10. The method of claim 1 wherein the client operates using Session
Initiation Protocol (SIP).
11. The method of claim 1 wherein the profile includes an address
book.
12. The method of claim 1 further comprising: updating the profile
from a local administration interface at the client; and sending
the updated profile to the configuration server.
13. The method of claim 1 further comprising: updating the profile
at a portal to the network; sending the updated profile to the
configuration server; sending a notify message to the client from
the configuration server, the notify message being sent through the
proxy server, and the notify message containing a location of an
updated profile for the client; and downloading the updated profile
to the client from its location.
14. The method of claim 1 further comprising: discovering NAT
traversal services; and enabling NAT traversal during sending the
subscribe message, authenticating, sending the notify message, and
downloading the profile.
15. A system for automated booting of a client for a subscriber,
the client being for use in interactive user sessions that involve
multimedia and being connected to a network, the system comprising:
a configuration server connected to the network; a proxy server
connected to the network; the proxy server being configured to,
upon receiving a subscribe message from the client, authenticate
the subscribe message, and send the subscribe message to the
configuration server; and the configuration server being configured
to send a notify message to the client, the notify message being
sent through the proxy server, and the notify message containing a
location of a profile for the client to allow the client to
download the profile, thereby allowing the persistence of profiles
in a centralized place.
16. The system of claim 15 wherein the configuration server is
configured to, upon a change being made to the profile, send a
notify message to the client, the notify message being sent through
the proxy server, and the notify message containing a location of
an updated profile for the client to allow the client; to download
the updated profile.
17. The system of claim 15 wherein the client operates using
Session Initiation Protocol (SIP).
18. The system of claim 15 wherein the profile includes an address
book.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of U.S. provisional
application Ser. No. 60/707,639, filed Aug. 12, 2005.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The invention relates to hardware and software based
customer premise equipment (CPE) for use in interactive user
sessions that involve multimedia. The invention further relates to
an automated boot process, and to provisioning and activation
technologies for these hardware and software clients.
[0004] 2. Background Art
[0005] Session initiation protocol (SIP) is an existing
request/response protocol for initiating, modifying, and
terminating interactive user sessions that involve multimedia.
SIP-based clients include both hardware and software based customer
premise equipment (CPE). Generally, SIP provides signaling and
session setup for Internet protocol (IP) communications involving
multimedia.
[0006] Traditional provisioning approaches used with SIP clients
utilize a pull model for provisioning, in which the client checks
for configuration changes periodically or requires to be rebooted
to get configuration updates. As a result, updates to the SIP
clients are traditionally not real-time updates. In addition, by
design, SIP is a peer-to-peer protocol. As a result, traditional
SIP applications are not configured to maintain persistence of data
in a centralized place to enable the subscriber to have a
consistent experience across a variety of platforms and hardware
solutions. Also, the traditional back-office system does not
support clients behind in-home NAT devices or nomadic clients.
[0007] For the foregoing reasons, there is a need for a method and
system for booting, provisioning, and activating hardware and
software clients that address some of the shortcomings in existing
approaches.
SUMMARY OF THE INVENTION
[0008] It is an object of the invention to provide an improved
method and system for booting, provisioning, and activating
hardware and software clients.
[0009] Some embodiments of the invention involve SIP clients;
however, it is to be appreciated that various aspects of the
invention may be used with other hardware and software clients used
in interactive user sessions using other protocols.
[0010] In one embodiment, the invention provides an automated
method for booting up SIP-based clients, including both hardware
and software based customer premise equipment (CPE). A top-down
push mechanism is used for provisioning the user, service, and
device information for a subscriber. Boot up configuration
information is stored in the network, and supports stationary as
well as nomadic SIP-based clients. In preferred embodiments,
network address translation (NAT) traversal allows the booting up
of SIP-based clients behind NAT devices.
[0011] By using the top-down push mechanism, in some embodiments it
may be possible to propagate updates from the billing system,
provisioning system, self-care portal, etc., to SIP-based clients
in real-time if the client is online. In the event that the client
is not online, the updates could be provided at the next log in or
boot up of the client.
[0012] In some embodiments, configuration parameters (for example,
user preferences, etc.) from the soft client or hard client may be
uploaded to the provisioning system.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG. 1 illustrates the system architecture for implementing
the invention in the preferred embodiment;
[0014] FIGS. 2-7 illustrate various provisioning flows in the
preferred embodiment;
[0015] FIG. 8 illustrates the provisioning login flow for a soft
client devitte logging in for the first time in the preferred
embodiment;
[0016] FIG. 9 illustrates the provisioning login flow for a soft
client device on subsequent logins, and the hard client device
login flow;
[0017] FIG. 10 illustrates the updating of client preferences from
the soft client or hard client through a local administration
graphical user interface (GUI); and
[0018] FIG. 11 illustrates the updating of client preferences using
a portal)).
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0019] FIG. 1 provides a high-level view of the functionality that
variedts systems perform in the preferred embodiment.
1. Billing Systems (10)
[0020] Billing systems 10 perform the following functions: [0021]
Order Entry: Customer Account Executive (CAE) 12, or Customer
Service Representative (CSR), will be able to create new orders in
the billing systems 10. Self-provisioning by the customer using a
Portal is another mechanism to create new orders. [0022] Monthly
bill generation: Billing systems 10 interact with the Mediation
Server (MS) 14 to generate monthly bills for each subscriber. The
monthly bill (one per multiple service subscriptions) has monthly
recurring charges (service charges, call features, rental charges,
etc.), Call detail records (date, time, place, telephone number
(TN), type of rate, number of minutes, and amount of charge),
non-recurring charges, regulatory recovery fees (911, Universal
connectivity, LNP fee, etc.), surcharge (subscriber line), taxes
(federal, state and local). [0023] Billing inquiry support: CAE 12
has access to call detail information sent from the MS 14 to handle
disputes and to apply credit for calls. [0024] Rate Code
Management: Service package and rate code information is available
for use to the CAE 12 and the order entry Portal. Based on the rate
code, individual calls will be rated by time of day, local/long
distance/international, etc. [0025] Workforce Management
functionalities: Technician scheduling, setting up customer
appointments based on real-time technician availability information
and work assignment are some of the capabilities that billing
systems 10 provide. [0026] CPE inventory management: The Billing
systems 10 provide inventory management and equipment tracking for
hard clients (HC) 18. 2. Mediation Server (MS) (14)
[0027] The service architecture includes the SIP Infrastructure 20,
Policy Server (PS) 22 and Session Border Controller (SBC) which
generate RADIUS accounting events, and not full Call Detail Records
(CDRs). These events are generated for each SIP message transaction
(e.g., INVITE, BYE) and for each (originating and terminating) call
leg during a call. The RADIUS server 24 collects these accounting
events and sends them to MS 14 using flat files for call meteeing
and rating as per service package information.
[0028] MS 14 performs RADIUS event correlation using subscriber
account information provided by billing systems 10 to derive CDRs
and call dispositions. MS 14 then forwards the CDRs to billing
systems 10. MS 14 supports billing inquiries from Portal to display
call logs in near real-time.
3. RADIUS Server (24)
[0029] Radius server 24 collects all event messages
[startup/shutdown/connect/disconnect/failed
requests/missed/forwarded/Voicemail/QoS on-off, etc.] sent by the
SIP Infrastructure 20, PS 22 and SBC to create flat file/s to be
sent to the MS 14 for further processing.
4. Provisioning Engine (PE) (30)
[0030] PE 30 receives service requests (add/delete/modify) from
billing systems 10 to perform subscriber and service provisioning
using Work Breakdown Engine (WBE) 32 to drive the workflow. PE 30
interfaces with Messaging Platform (MP) 34, Configuration Server
(CS) 36, SIP Infrastructure 20, PS 22, Provisioning Group (PG) 38
to keep these systems in sync with the Data Store (DS) 40 (source
of truth).
[0031] PE 30 receives password update requests from Subscriber
Service Management Layer (SSML) 50 and ensures that the SIP
Infrastructure 20 is updated with this data.
[0032] PE 30 receives client preferences and address book changes
from SSML 50 (changes made from the Portal) and sends an update
trigger to Configuration Server 36.
[0033] PE 30 receives call feature detail changes from the Portal
and writes the information to SIP Infrastructure 20.
[0034] PE 30 receives call feature details queries from the Portal.
The PE will process requests using SIP Infrastructure adapters to
send back the details to the Portal.
5. Work Breakdown Engine (WBE) (32)
[0035] PE 30 will communicate with the WBE 32 to get work order
breakdown for service requests (add/delete/modify). WBE 32 will
maintain the timing and order of provisioning operations.
[0036] All work order breakdown service requests from WBE 32 are
transactional in nature, following a particular sequence. Status of
orders will be updated in the Order Status Repository (OSR) 52. On
failures, these provisioning transactions originated from WBE 32
will not be rolled back to preserve the state for further analysis
during order fall out handling. The service fulfillment agent will
handle fall out orders and correct the trouble to complete and
close the order.
[0037] WBE 32 interacts with TPP (voice third party provisioning)
systems for LIDB, LNP, CNAM, and DA/DL services.
6. Order Status Repository (OSR) (52)
[0038] OSR 52 maintains the status of various legs of the
transactions that are broken down by the WBE 32. Manual
intervention will be required to fix the errors that arise out of
automated provisioning.
7. Configuration Server (36)
[0039] The Configuration Server 36 provides the following
functions: [0040] Support Subscribe-Notify SIP based event
mechanism. [0041] Support XCAP to manage configuration data, e.g.,
user, service and device profiles. [0042] Will provide all user,
service and device profile data from the data store 40 as source of
truth. [0043] For performance reasons, configuration server 36 may
cache user, service and device profiles. The caching option will be
configurable. [0044] Push configuration updates (i.e. user, service
and device profile parameter changes) from Billing system 10,
Portal to the SIP-based clients (hard clients 18, soft clients 60)
in real-time. [0045] Upload user profile changes from the SIP-based
clients (hard clients 18, soft clients 60) to data store 40 via
SSML services 50 in real-time. 8. SIP Infrastructure (20)
[0046] The SIP Infrastructure 20 provides the following
functionality: [0047] User authentication and authorization (to
gain access to SIP-based network services). [0048] End-point
registration (maintains mapping a particular SIP address and/or
E.164 # to the IP address of a user agent (UA)). [0049] Message
routing (including simple network-based features like call
forwarding, etc.). [0050] Enhanced feature support (e.g.,
multi-point conferencing with centralized media mixing). [0051]
Inter-domain routing of SIP session requests. [0052] Providing
network-based features associated with routing between multiple
domains (e.g., least-cost routing). [0053] ENUM integration for
number management and routing. [0054] Support for subscriptions and
notifications. 9. Policy Server (PS) (22)
[0055] The Policy Server 22 enforces MSO-defined authorization and
resource-management procedures. PS 22 applies rules against
received Policy Requests. Requests that pass are proxied to the
cable modem termination system (CMTS) 62 for admission control. PS
22 can push policy decisions to a CMTS 62 and respond to queries
from the CMTS 62 for policy decisions.
10. Messaging Platform (MP) (34)
[0056] The messaging platform 34 provides the subscriber with voice
mail, and video mail services. MP 34 will also provide
notifications for messages and portal based access for message
retrieval and preference settings.
11. Provisioning Group (PG) (38)
[0057] PG systems 38 are used to provision multiple technologies
and devices including Cable Modems, digital set-top boxes and
PacketCable eMTAs. The device will be added to a database
(registration) and receive a proper configuration file
(activation).
[0058] PG systems 38 also include a DHCP server to dynamically
allocate IP addresses and a DNS server that is used to map between
domain names and IP addresses.
12. Tools Database (TDB) (64)
[0059] TDB 64 is a central database of record for network element
data. TDB 64 will be populated with subscriber and service data
(e-mail, call features, etc.) written by PE 30. TDB 64 will also
house billing data (rate codes, account number, customer ID, market
ID, region ID, domain ID, etc.) TDB 64 has also near real-time feed
from PG 38 for IP-address assignments to CM, and CPEs. TDB 64 maps
a subscriber to a CMTS 62.
[0060] TDB 64 will be accessed by various OSS tools 65 and PS
22.
13. Subscriber Service Management Layer (SSMC) (50)
[0061] SSML 50 provides component services to do subscriber
options, preferences and account management. Portal based service
applications access these services to provide subscriber self-care
account management services.
[0062] SSML 50 maintains data integrity and consistency in the DS
40 for updates from multiple sources (Portal, Configuration Server,
etc.). SSML 50 provides a layer of abstraction around the data in
the DS 40.
[0063] SSML 50 will be accessed by Configuration Server 36 to
provide user/service/device profile information to the clients.
SSML 50 will retrieve the data from the DS 40 to provide the
information.
14. Data Store (DS) (40)
[0064] The DS 40 is used for product management, subscriber and
device identity management, application/service
configuration/authorization/activation and topology/infrastructure
information. The DS 40 is the source of truth and the Configuration
Server 36 and other downstream network elements need to be in sync
with DS 40.
[0065] The DS 40 is used to hold the online service state of the
subscriber. A subscriber's service is disconnected by request or by
enabling business rules that determine the state of the subscriber
over time (e.g., abandonment of the account or services for
specified period of time will result in automated termination). The
online state of the subscriber with respect to the provisioned
devices and services will be written to the DS 40 by PE 30. Certain
applications and aspects of these services such as Parental
Controls and Presence-based service management will write/update
the DS 40 independently of the PE 30.
[0066] On a much larger scale, the provisioning of subscriber,
device, and service information through PE 30 into the DS 40 allows
for the scale, flexibility, and redundancy to provide the
subscriber a richer and cohesive environment. On an even grander
scale, allowing third-party services to authenticate against the DS
40 allows subscribers to access to their services even off the
service provider's footprint.
[0067] DS 40 supports the User--Service management paradigm as well
as providing Service Access, Business Management, and Operational
(Support System) Management.
15. STUN and TURN (80)
[0068] The STUN and TURN 80 are used by clients as follows:
[0069] The STUN (Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)) is used by a client
behind NAT to find out its public address, the type of NAT it is
behind and the Internet side port associated by the NAT with a
particular local port.
[0070] The TURN (Traversal Using Relay NAT) is used by clients
behind a symmetric NAT or firewall to receive incoming data over
TCP or UDP connections.
[0071] FIGS. 2-7 provide details of various flows
[add/delete/modify service requests] for the automated boot-process
for SIP-based clients in the preferred embodiment. In each figure,
the follows are sequentially numbered to facilitate an
understanding of the illustrated process. Further, labels for the
flows are provided immediately below each flow diagram for clarity,
and indicate the activity for the flows.
[0072] FIG. 2 provides details of the add service request for a
soft client (SC) subscriber: [0073] When the subscriber calls the
Customer Account Executive (CAE) 12 to add service, serviceability
check is performed, a telephone number is allocated, and an order
is entered and after Third Party Validation (TPV) is done the order
is sent down to the Provisioning Engine (PE) 30. (Flow 1-6.) A
serviceability database for checking the serviceability of an
account/customer is indicated at 13. [0074] The PE 30 gets the
breakdown of the order from the Work Breakdown Engine (WBE) 32.
(Flows 7-8.) [0075] Based on the WBE 32, various downstream
systems--Messaging Platform (MP) 34, Policy Server (PS) 22, SIP
Infrastructure 20, Tools Database (TDB) 64, Data Store (DS) 40, and
Configuration Server (CS) 36--are updated with subscriber and
service data. (Flows 9-19.) [0076] PE 30 sends the overall order
status of the transaction to the billing system 10. (Flow 20.)
[0077] Billing system 10 sends the subscriber data to Mediation
Service (MS) 14 in real-time. This step is necessary to trigger MS
14 to start tracking the telephone call usage (type as
local/long-distance/international, toll/non-toll, minutes etc.) for
the subscriber. Subscriber data including primary account customer
ID/Account ID, Telephone Number, Service Package
information/Service Code/Rate Code, Monthly billing cycle, and
Account scams are sent. (Flow 21.) [0078] PE 30 will then update
the provisioning tasks status in Order Status Repository (OSR) 52
and inform WBE 32 that the activation was successful. (Flow 22.)
[0079] Billing system 10 sends the status of the Order Entry to CAE
12. The CAE 12 provides download information [URL] to the customer.
(Flow 23.) [0080] WBE 32 will perform third party provisioning.
Directory Assistance (DA)/Directory Listing (DL) will be updated
with the customer listing information. Calling Name (CNAM) database
will be updated with caller ID and calling name information.
Automatic Location Identification (ALI) database will be updated
with subscriber address information for E911. (Flow 24.)
[0081] FIG. 3 provides details of the delete service request for a
soft client (SC) subscriber: [0082] When the subscriber calls the
Customer Account Executive (CAE) 12 to delete service, an order is
entered and sent down to the PE 30. (Flows 1-2.) [0083] The PE 30
gets the breakdown of the order from the WBE 32. (Flows 3-4.)
[0084] Based on the WBE 32, various downstream systems--MP 34, PS
22, SIP Infrastructure 20, TDB 64, DS 40, and CS 36--are asked to
delete subscriber and service data. (Flows 5-15.) [0085] PE 30
sends the overall status of the transaction to the billing system
10. (Flow 16.) [0086] The telephone number will be returned to the
TN database 16. (Flow 17.) [0087] The status of the operation to
add the telephone number to the TN database 16 is returned to the
Billing system 10. (Flow 18.) [0088] Billing system 10 sends
notification to MS 14 in real-time that the subscriber was deleted.
(Flow 19.) [0089] Upon reporting status of delete operation to
billing system (Flow 16), PE 30 will then update the OSR data 52
with delete order status and inform WBE 32 that the deactivation is
complete. (Flow 20.) [0090] Upon completion of Flow 19, Billing
system 10 sends the status of the delete service to CAE 12. (Flow
21.) [0091] After receiving deactivation complete message from PE
30 (Flow 20), WBE 32 will perform third party provisioning to clear
the account information. (Flow 22.)
[0092] FIG. 4 provides details of the modify service request for a
soft client (SC) subscriber: [0093] When the subscriber calls the
Customer Account Executive (CAE) 12 to modify service, an order is
entered and sent down to the PE 30. (Flows 1-2.) [0094] The PE 30
gets the breakdown of the order from the WBE 32. (Flows 3-4.)
[0095] Based on the WBE 32, various downstream systems--MP 34, PS
22, SIP Infrastructure 20, TDB 64, DS 40, and CS 36--are asked to
modify subscriber and service data. (Flows 5-19.) [0096] CS 36
notifies soft client (SC) 60 of change. (Flows 10-14.) [0097] PE 30
sends the overall status of the transaction to the billing system
10. (Flow 20.) [0098] Billing system 10 sends the status of the
Order Entry to CAE 12. (Flow 21.)
[0099] FIG. 5 provides details of the add service request for a
hard client (HC) subscriber: [0100] When the subscriber calls the
Customer Account Executive (CAE) 12 to add service, serviceability
check is performed, a telephone number is allocated, an order is
entered and after Third Party Validation (TPV) is done the order is
sent down to the Provisioning Engine (PE) 30. (Flows 1-6.) [0101]
The PE 30 gets the breakdown of the order from the Work Breakdown
Engine (WBE) 32. (Flows 7-8.) [0102] Based on the WBE 32, various
downstream systems--Messaging Platform (MP) 34, Policy Server (PS)
22, SIP Infrastructure 20, Tools Database (TDB) 64, Data Store (DS)
40, and Configuration Server (CS) 36--are updated with subscriber
and service data. (Flows 9-19.) [0103] The order is not yet
complete. The Billing System 10 is informed of the status of the
provisioning request. (Flow 20.) [0104] The Billing System 10
updates CAE with order entry status. (Flow 21.) [0105] Technician
calls IVR (from the subscriber site on the day of install) and
enters MAC address. Technician also specifies whether HC 18 is
behind NAT 70 or not. (Flow 22.) [0106] WBE 32 sends update to PE
30 via Order Status Repository (OSR) 52 that the equipment
information MAC address was checked in for specific subscriber and
order (indirectly identifying TN). (Flow 23.) [0107] PE 30 updates
PG 38 to register HC 18 MAC address and allow additional IP address
allocation if HC 18 is not behind NAT 70. (Flow 24.) [0108] 30 PE
30 updates DS 40 subscriber-device association information. (Flow
25.) [0109] PE 30 updates SIP-infrastructure 20 with TN & MAC
address for authentication purpose. (Flow 26.) [0110] PE 30 writes
back equipment information to billing system 10 for the given
subscriber. (Flow 27.) [0111] Technician does wiring and
connection, confirms service is up and running, and then calls
billing system dispatch and checks-in work order. If any of the
previous steps failed, OSR 52 will have the status. The technician
will have to call service delivery or fulfillment agent to resolve
the issue. The service delivery or fulfillment agent will look at
OSR 52 and will rectify the problem. (Flow 28.) [0112] Billing
system 10 sends order check-in to PE 30 and updates Mediation
Server 14 with subscriber data. (Flows 29-30.) [0113] PE 30 will
then update the OSR data with order status and inform WBE 32 that
the activation was successful. (Flow 31.) [0114] WBE 32 will
perform third party provisioning. Line Information Database (LIDB)
will be updated. Directory Assistance (DA)/Directory Listing (DL)
will be updated with the customer listing information. Calling Name
(CNAM) database will be updated with caller ID and calling name
information. Automatic Location Identification (ALI) database will
be updated with subscriber address information for E911. (Flow
32.)
[0115] FIG. 6 provides details of the delete service request for a
hard client (HC) 18 subscriber: [0116] When the subscriber calls
the Customer Account Executive (CAE) 12 to delete service, an order
is entered and sent down to the PE 30. (Flows 1-2.) [0117] The PE
30 gets the breakdown of the order from the WBE 32. (Flows 3-4.)
[0118] Based on the WBE 32, various downstream systems--MP 34, PS
22, SIP Infrastructure 20, TDB 64, DS 40, and CS 36--are asked to
delete subscriber and service data. (Flows 5-15.) [0119] If HC 18
is not behind NAT 70, PE 30 updates PG 38 to un-register HC MAC and
reduce the number of IP addresses that can be allocated to CPEs, by
1. PE 30 will refer to DS 40 to figure out whether HC 18 is behind
NAT 70 or not as this information is gathered thru IVR during
equipment activation. If HC 18 was behind NAT 70, no change is
required to the PG 38 for IP address allocation. (Flow 16.) [0120]
PE 30 sends the status of the transaction to the billing system 10.
(Flow 17.) [0121] The telephone number will be returned to the TN
database 16. (Flows 18) [0122] The status of the operation to add
the telephone number to the TN database 16 is returned to the
Billing System 10. (Flow 19.) [0123] The Billing system 10 returns
the status of the delete service to the CAE to 12. (Flow 20.)
[0124] PE 30 will then update the OSR data 52 to inform WBE 32 that
the deactivation is complete. (Flow 21.) [0125] 32 will perform
third party provisioning to disable account. LIDB will be updated.
DA/DL will be updated with the customer listing information. CNAM
database will be updated with caller ID and calling name
information. Automatic Location Identification (ALI) database will
be updated with subscriber address information for E911. (Flow 22.)
p0 Billing system 10 will trigger an equipment pick-up event to the
dispatch. (Flow 23.) [0126] Equipment will be returned by the
customer at a drop-off location or picked up on a truck-roll. (Flow
24.) [0127] Billing system 10 sends notification to MS 14 in
real-time that the subscriber was deleted. Only after the equipment
has been picked up, MS 14 will be notified to generate the final
bill since the equipment could be rented/leased. (Flow 25.)
[0128] FIG. 7 provides details of the modify service request for a
hard client (HC) 18 subscriber: [0129] 30 When the subscriber calls
the Customer Account Executive (CAE) 12 to modify service, an order
is entered and sent down to the PE 30. (Flows 1-2.) [0130] The PE
30 gets the breakdown of the order from the WBE 32. (Flows 3-4.)
[0131] Based on the WBE 32, various downstream systems--MP 34, PS
22, SIP Infrastructure 20, TDB 64, DS 40, and CS 36--are asked to
modify subscriber and service data. (Flows 5-19.) [0132] CS 36
notifies HC 18 of change. (Flows 10-14.) [0133] PE 30 sends the
status of the transaction to the billing system 10. (Flow 20.)
[0134] Billing system 10 sends the status of the modify order to
CAE 12. (Flow 21.) [0135] If there is no truck-roll, the order is
checked in. If there is truck-roll, the technician will perform the
modifications and check in. (Flows 22-28.) [0136] PE 30 is informed
that the order is complete. (Flow 29.) [0137] Billing system sends
notification to MS 14 to start billing. (Flow 30.) [0138] If
truck-rolled, PE 30 notifies WBE 32 of order check-in to close
order. WBE will perform third party provisioning to update the
account, if required. (Flow 31.)
[0139] FIG. 8 provides detailed flows for the automatic boot
process for SIP-based Soft Clients (SC) 60 logging in for the first
time in the preferred embodiment. The details of the automatic boot
process for SIP-based SCs 60 are given below: [0140] The PC 72
interacts with the DHCP server, (may be part of the Provisioning
Group (PG) 38 or local NAT device) to get an IP address, default
gateway address and DNS server information. [0141] The subscriber
goes to the download portal (DP) 74 to download the SC 60. (Flow
1.) [0142] The DP 74 issues a LDAP query to the DS 40 to retrieve
password information. (Flow 2.) [0143] DP 74 validates the password
and allows the download of the SC 60 to the PC 72. (Flow 3.) [0144]
Once the download is complete, the installation of the SC 60 will
take place automatically. The domain name, backup fully qualified
domain name (FQDN) of STUN server and SIP server are pushed down as
part of the installation. (Flows 4-5.) [0145] The SC 60 will send a
DNS SRV query to get the service records for discovering the local
SIP service. The DNS SRV resolution process involves a
request/response transaction in which the client provides the
specially formed FQDN derived from service name, domain name and
client's preferred transport (e.g., sip._tcp.exampledomain.com).
The DNS infrastructure responds with a SRV record corresponding
with the service addressing attributes. Should the DNS SRV fail,
the backup FQDN will be used to avoid service disruption. (Flow 6.)
[0146] The DNS server will return list of SRV records having FQDN
of available SIP Proxies (part of the SIP Infrastructure) along
with the port number of the target host where the service may be
found. (Flow 7.) [0147] SC 60 will select a SRV record for SIP
service based on priority and weight (this provides combination of
load balancing and backup service). Then the client sends a query
to the DNS to resolve the FQDN of the SIP Proxy from the selected
SRV record. (Flow 8.) [0148] The DNS server will return the IP
address for the SIP Proxy. (Flow 9.) [0149] The SC 60 will send a
DNS SRV query to get service records for discovering the local STUN
service. [0150] After getting the list of SRV records for STUN
service, the SC 60 will select a SRV record based on priority and
weight. Then, the SC 60 will send a query to the DNS server to
resolve STUN server FQDN from selected SRV record to get the IP
address of the STUN server 80. Should the DNS SRV fail, the backup
FQDN will be used to avoid service disruption. [0151] SC 60 will
interact with the STUN server 80 to determine whether it is behind
a NAT device or not. In the process, SC 60 will also identify its
public address, the type of NAT it is behind and the Internet side
port associated by the NAT with a particular local port. The SC
will be using this information to make SIP proxies aware about it.
This will allow SIP proxies to interact with NATed SC 60 [0152] SC
60 will send a Subscribe message with NAT traversal information,
i.e., public IP address and Internet side port in top most Via
header as "received" and "rport" parameters to the SIP proxy to
retrieve the user, service and device profiles. The SIP
Infrastructure 20 challenges the Subscribe request if it does not
have enough authentication information. The SC 60 will resend
Subscribe request with authentication information (username and
password) to SIP infrastructure. Upon successful authentication,
SIP infrastructure routes the Subscribe message to the
Configuration server 36. (Flow 10.) [0153] The Configuration Server
36 creates subscription based on the subscriber ID and client ID in
the "Subscribe" message and notifies the SC 60 of the location of
the user, service and device profiles. Address book location will
also be notified as part of service profile. CS 36 uses the SIP
proxy to route the information back to the SC 60 using Notify
message. (Flow 11.) [0154] SC 60 sends XCAP request to the
Configuration Server 36 requesting the user, service and device
profiles. This time, the SIP Proxy is by-passed and the SC connects
directly to the Configuration server 36. (Flow 12.) [0155]
Configuration Server 36 gets the user, service and device profile
data from the DS 40 if it does not exist in its local cache and
sends the data to the SC 60. (Flow 13.) [0156] The address book
related transaction is optional as same service could be accessed
using other mechanisms, e.g., XMPP protocol. The SC has the option
to leverage XCAP capabilities for accessing and managing address
book. This is shown here as separate queries as it is optional and
also to enable the shared address book data to reside on a location
other than the Configuration server 36. The SC 60 will send XCAP
request to CS 36 requesting for address-book. (Flow 14.) [0157]
Configuration Server 36 gets the address book data from the DS 40
and sends it to the SC 60. The address book data should not be
cached in the Configuration Server 36. (Flow 15.) [0158] The SC 60
will register with the SIP Proxy which is a front element of SIP
infrastructure 20. The SIP Proxy will validate the credentials of
the SC 60 if the domain of the SC 60 is correct. Otherwise, it will
redirect the SC 60 to the correct domain. (Flow 16.) [0159] The SIP
Proxy on successful registration will send an OK, indicating that
the registration was successful. (Flow 17.) [0160] The SC 60 is now
ready for communication and the subscriber can initiate or receive
request for conversations to/from other subscribers.
[0161] FIG. 9 provides detailed flows for the automatic boot
process for SIP-based SCs 60 logging in for the 2nd time onwards
and for hard clients (HC) 18 in the preferred embodiment. The
details of the automatic boot process for SIP-based SC/HCs 60, 18
are given below: [0162] If the HC 18 is behind a NAT 70, it will
get an IP address from the NAT device. Otherwise, it will go to the
DHCP Server (part of the PG 38) to get an IP address. [0163] SC/HC
60, 18 on a login will send DNS SVR request to DNS server (part of
the PG 38). (Flow 1.) [0164] DNS provides list of SRV records to
the SC/HC 60, 18 which will select a SRV record to get the
SIP-proxy FQDN and Port information for SIP service. If DNS SRV
fails backup FQDN should be used. (Flow 2.) [0165] The SC/HC 60, 18
will interact with the DNS to resolve the IP address of the
selected SIP Proxy FQDN. (Flows 3-4.) [0166] The SC/HC 60, 18 will
send a DNS SRV query to get service records for discovering the
STUN service. [0167] After getting the list of SRV records for STUN
service, the SC/HC 60, 18 will select a SRV record based on
priority and weight. Then, the SC/HC 60, 18 will send a query to
the DNS server to resolve STUN server FQDN from selected SRV record
to get the IP address. If the DNS SRV fails, the backup STUN FQDN
will be used to avoid service disruption. [0168] SC/HC 60, 18 will
interact with the STUN server 80 to determine whether it is behind
a NAT device 70 or not. In the process, SC/HC 60, 18 will identify
its public address, the type of NAT it is behind and the Internet
side port associated by the NAT with a particular local port. The
SC/HC 60, 18 will be using this information to make SIP proxies
aware about it. This will allow SIP proxies to interact with NATed
SC/HC 60, 18 [0169] SC/HC 60, 18 will send a Subscribe message to
the SIP Proxy for user, service, device profiles. (Flow 5.) [0170]
SIP Proxy will authenticate the request and send the request to the
Configuration server 36. [0171] Configuration server 36 will send a
Notify message to the SC/HC 60,18 through the SIP Proxy containing
the location of the user, service and device profiles. The device
profile will have software/firmware upgrade information (e.g., new
version, filename/package-name, location, upgrade-type mandatory or
optional, etc.) for SC/HC 60, 18. The configuration server is
capable of sending Notifications in real-time or on schedule as
long as SC/HC 60, 18 are subscribed with Configuration server and
whenever new version software/firmware available and related
information is added to DS 40, usually done by operations as manual
procedures. (Flow 6.) [0172] The SC/HC 60, 18 will directly send
XCAP request to the Configuration server 36 to get the user,
service, and device profile updates. If there is new version
available in DS 40, then configuration server will return device
profile that is suggesting SC/HC 60, 18 to do software/firmware
upgrade. The SC/HC 60, 18 must upgrade if device profile specifies
upgrade is mandatory. Otherwise, subscriber is at will. For
upgrade, SC/HC 60, 18 will directly download software/firmware from
the location specified in device profile. After the download, SC/HC
60, 18 must backup the old image. Then SC/HC must install and use
new software/firmware automatically and re-get user, service, and
device profiles from Config Server by sending XCAP request with
latest make-model-version information. (Flow 7.)
[0173] The URL format for XCAP request should be formed as follows:
TABLE-US-00001 <XCAP-root>
<Document-selector>[<Node-selector>] Where XCAP root =
https://<config_server_fqdn>/xcap Document selector =
<application_id>/<user_id>/<device_id>/<doc_id>
<application_id> = /vcom/2_0/configuration <user_id> =
/users/username used for authentication for Softclient, it is
Comcast.net username for Video Phone(VP), it is serial number/MAC
of VP <device_id> =
/<vendor>/<model>/<version> for Softclient,
Eyeball/SC/2_0 for Video phone, Innimedia/VP/2_0 <doc_id> =
/all.xml Node selector = will be based on XML schema of full
configuration containing user, service and device profile data.
[0174] Configuration server 36 will send the data for the user,
service and device profile [deltas over previously sent data]. If
the data is in the local cache, Configuration Server 36 will send
it to the SC/HC 60, 18 directly. Otherwise, it will retrieve the
data from SSML/DS 50, 40 and then send the data to the SC/HC 60,
18. (Flow 8.) [0175] SC/HC 60, 18 may optionally sends XCAP
requests to get address book data. Config Server 36 retrieves
address book data from the DS 40 and sends back data as XCAP
response to the SC/HC 60, 18. Note: The address book service could
be hosted on Configuration Server 36 or as separate XCAP server.
(Flows 9-10.) [0176] SC/HC 60, 18 is then ready to register with
the SIP Proxy. (Flow 11.) [0177] SIP Proxy authenticates the data
using information from the local data store and sends back a status
of the registration. (Flow 12.)
[0178] FIG. 10 provides detailed information about updates from
SC/HC 60, 18 to client preferences (part of user profile) and/or
address book changes made from the SC/HC's 60, 18 local Graphical
User Interface (GUI): [0179] When the subscriber wants to make
changes to the client preferences (part of user profile) and/or the
address book, the local administration GUI will be brought up. The
subscriber will modify the preferences and/or address book in the
GUI. The changes done to the preferences and/or address book are
sent to the Configuration Server 36. The entire transaction will be
a synchronous transaction and will be complete when the
Configuration Server 36 returns the status of the update to the
SC/HC 60, 18. (Flow 1.) [0180] The Configuration Server 36 writes
to the SSML 50. The Configuration Server 36 will wait synchronously
with the data for the status from SSML 50. (Flow 2.) [0181] SSML 50
writes to DS 40. The status of the LDAP write will be available to
SSML 50. (Flow 3.) [0182] SSML 50 will send the status of the
updates to the Configuration Server 36. (Flow 4.) [0183]
Configuration Server 36 will update its cache with the newly
modified client preferences data. The address book changes, if any,
will not be cached or modified by the Configuration Server 36.
(Flow 5.) [0184] Configuration server 36 will then send the status
of the updates back to the SC/HC 60, 18. (Flow 6.) [0185] On
successful update, SC/HC 60, 18 will update the local data
structures with the modified user, service and device profiles, and
address book data. The SC/HC 60, 18 will reflect the changes on GUI
as required. (Flow 7.)
[0186] FIG. 11 provides detailed information about updates made
from the Portal to client preferences (part of user profile) and/or
the address book in the preferred embodiment: [0187] Subscriber
makes changes in the Portal 12 and the Portal 12 forwards the
changes to SSML 50. (Flow 1.) [0188] SSML 50 writes the changes to
the DS 40. The status of the DS 40 write is available to SSML 50.
(Flow 2.) [0189] SSML 50 sends the updates to the PE 30. (Flow 3.)
[0190] PE 30 acknowledges update request to SSML 50. Downstream
updates are done asynchronously with guaranteed delivery. (Flow 4.)
[0191] SSML 50 sends the status of the update to the Portal 12. As
soon as the DS 40 is updated and the request has been acknowledged
by PE 30, the status is sent back to the Portal 12 to ensure that
system resources are not tied up for this transaction. (Flow 5.)
[0192] The PE 30 then updates the Configuration Server 36. (Flow
6.) [0193] 0Configuration Server 36 modifies its local cache, if
any. (Flow 7.) [0194] The Configuration Server 36 sends the status
back to the PE 30. (Flow 8.) [0195] Configuration Server 36 sends a
Notify (SIP Protocol) message to SIP Proxy (contains the Location
of modified user/device profile information), and/or addressbook
change notification, if SC/HC 60, 18 is online. If SC/HC 60, 18 is
not online, the changes will be applicable on next login. (Flow 9.)
[0196] SIP Proxy will forward the Notify message (contains the
Location of modified user/device profile information) to SC/HC 60,
18 if it is online. (Flow 10.) [0197] SC/HC 60, 18 will send XCAP
request to get the modified information (user, service and/or
device profile) from the Configuration Server 36. (Flow 11.) [0198]
Configuration Server 36 will send down the modified (user and/or
device profile) information from its cache to SC/HC 60, 18, if the
data is present in its cache. Otherwise, the Configuration Server
will get the data from the DS 40 and send it to SC/HC 60, 18. (Flow
12.) [0199] SC/HC 60, 18 will request address book changes from the
Configuration Server 36, which then retrieves it from the DS 40 and
sends the data back to the SC/HC 60, 18. (Flows 11-12.)
[0200] Preferred embodiments of the invention has many advantages.
For example, it is possible to automate the provisioning process to
provide for an integrated solution that provides for NAT traversal,
real-time updates to SC/HC, maintain persistence of data in a
centralized place to enable the subscriber to have a consistent
experience across a variety of platforms and hardware solutions,
support for nomadic clients, support charging functions (prepaid
services/account activation/deactivation), be network agnostic for
efficient transfer of changed data elements, provide call detail
record information on-demand, provision 3rd party systems, and
provision new network elements.
[0201] While embodiments of the invention have been illustrated and
described, it is not intended that these embodiments illustrate and
describe all possible forms of the invention. Rather, the words
used in the specification are words of description rather than
limitation, and it is understood that various changes may be made
without departing from the spirit and scope of the invention.
* * * * *