FIELD OF INVENTION
[0001] The present subject matter relates to communication systems and, particularly, but
not exclusively, to auto configuration servers.
BACKGROUND
[0002] Along with quick development of network technologies to manage an equipment
and rapid promotion of performance of a network management server, the network management
server manages increasing number of equipments. Managing such equipments quickly and
efficiently in a network management system is an increasing challenge. The ‘DSL forum’, now
known as the ‘Broadband forum’, is an international industry consortium of service providers,
equipment and component manufacturers, focusing on developing broadband digital subscriber
line (DSL). The DSL forum develops technical specifications and standards that enable delivery
of DSL products and services.
[0003] The broadband forum has defined a technical specification as a Technical Report,
(TR)–069 which has been widely adapted for use in DLS modems, set-top box and Network
Attached Storage (NAS) units. The TR-069 management protocol allows communication
between Customer Premises Equipments (CPEs) and an Automatic Configuration Server (ACS).
In other words, the TR-069 specification specifies a Wide Area Network Management Protocol
for the CPE and the TR-069 specification is also referred to as CWMP. The TR-069 therefore
defines a mechanism that encompasses secure auto-configuration of the CPEs, and also
incorporates other CPE management functions into a common framework.
SUMMARY
[0004] This summary is provided to introduce concepts related to auto configuration
servers. This summary is not intended to identify essential features of the claimed subject matter
nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, a method for optimizing an auto configuration server
(ACS) is described. The method includes analyzing asynchronous requests received by the ACS
from a plurality of Customer Premises Equipments (CPEs) for a pre-defined time period, where
the ACS and the CPEs communicate over TR-069 protocol and, the asynchronous requests are
3
stochastic in nature. The method further includes predicting patterns of activity corresponding to
the asynchronous requests received by the ACS based on a time series analysis of the
asynchronous requests during the pre-defined time period. The method also includes scheduling
synchronous requests associated with the ACS based on the predicted patterns of activity and
resource parameters associated with the synchronous requests, where the synchronous requests
are deterministic and configurable by the ACS, and where the resource parameters associated
with the synchronous requests are indicative of time and resources utilized by the ACS to
process the synchronous requests.
[0006] In another implementation, an optimized ACS is described. The ACS includes a
processor. Further, the ACS includes an analysis module coupled to the processor to analyze
asynchronous requests, received by the ACS, from a plurality of Customer Premises Equipments
(CPEs) for a pre-defined time period, where the ACS and the CPEs communicate over TR-069
protocol, and where the asynchronous requests are stochastic in nature. The ACS further includes
a prediction module coupled to the processor to predict patterns of activity corresponding to the
asynchronous requests received by the ACS based on a time series analysis of the asynchronous
requests during the pre-defined time period. Further, the ACS also includes a scheduling module
coupled to the processor to schedule synchronous requests associated with the ACS based on the
predicted patterns of activity and resource parameters associated with the synchronous requests,
where the synchronous requests are deterministic and configurable by the ACS, and where the
resource parameters associated with the synchronous requests are indicative of time and
resources utilized by the ACS to process the synchronous requests.
[0007] In one implementation, a non-transitory computer-readable medium having
embodied thereon a computer program for executing a method is described. The method includes
analyzing asynchronous requests received by the ACS from a plurality of Customer Premises
Equipments (CPEs) for a pre-defined time period, where the ACS and the CPEs communicate
over TR-069 protocol, and where the asynchronous requests are stochastic in nature. The method
further includes predicting patterns of activity corresponding to the asynchronous requests
received by the ACS based on a time series analysis of the asynchronous requests during the predefined
time period. The method also includes scheduling synchronous requests associated with
the ACS based on the predicted patterns of activity and resource parameters associated with the
synchronous requests, where the synchronous requests are deterministic and configurable by the
4
ACS, and where the resource parameters associated with the synchronous requests are indicative
of time and resources utilized by the ACS to process the synchronous requests.
BRIEF DESCRIPTION OF THE FIGURES
[0008] The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the
reference number first appears. The same numbers are used throughout the figures to reference
like features and components. Some embodiments of system and/or methods in accordance with
embodiments of the present subject matter are now described, by way of example only, and with
reference to the accompanying figures, in which:
[0009] Fig. 1 illustrates an auto configuration server, according to an embodiment of the
present subject matter;
[0010] Fig. 2 illustrates a graph generated based on time series analysis if requests
received by the auto configuration server, according to an embodiment of the present subject
matter; and
[0011] Fig. 3 illustrates a method of optimizing the auto configuration server, in
accordance with an embodiment of the present subject matter.
[0012] In the present document, the word "exemplary" is used herein to mean "serving as
an example, instance, or illustration." Any embodiment or implementation of the present subject
matter described herein as "exemplary" is not necessarily to be construed as preferred or
advantageous over other embodiments.
[0013] It should be appreciated by those skilled in the art that any block diagrams herein
represent conceptual views of illustrative systems embodying the principles of the present
subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state
transition diagrams, pseudo code, and the like represent various processes which may be
substantially represented in computer readable medium and so executed by a computer or
processor, whether or not such computer or processor is explicitly shown.
5
DESCRIPTION OF EMBODIMENTS
[0014] Systems and methods for optimization of an auto configuration server in a
communication network are described. The methods can also be implemented in various servers
and communication devices communicating through various networks. The servers and
computing systems that can implement the described method(s) include, but are not limited to,
mail server, central directory servers, database server, file server, print server, web server,
application server, and the like. Although the description herein is with reference to auto
configuration servers, the methods and systems may be implemented in other server managing
network equipments, albeit with a few variations, as will be understood by a person skilled in the
art. Further, although the description has been provided with respect of TR-069 Protocol, it
would be understood that the techniques described in context of the TR-069 Protocol can be
utilized in other protocols, albeit with a few variations, as will be understood by a person skilled
in the art.
[0015] An Auto Configuration Server (ACS) is an entity in a broadband network
responsible for auto-configuration of Customer Premises Equipments (CPEs) for advanced
services. CPE may be any type of electronic device capable of digital communication. For
example, the CPE may be a personal computer, a gateway or router, an electronic appliance,
such as a set-top box, a television set, an IP based telephone, etc., or a sensor, such as thermostat,
fire sensor, and smoke sensor. Many CPE devices can be configured and managed remotely,
such as through wide area network. The TR-069 protocol, or the CPE WAN management
protocol, provides an end-to-end architecture for CPE management. In this architecture, the CPE
device in a local network connects to the ACS that is capable of providing service level settings
for services available to the CPE.
[0016] Typically, the ACS is dedicated either to a certain level of services like premium
service, best effort service, etc.; a type of device like Home Gateway, Voice over IP telephone,
and set top box; or a specific customer group, such as business and residential. For the CPEs to
communicate with the ACS, the CPEs have to be preconfigured to specifically address to the
proper ACS. The communication between the CPEs and the ACS may either be initiated by the
CPEs, or the ACS. Generally, the communications initiated by the CPEs are to report
information or to provide status of the CPEs. Such requests are generally asynchronous in nature
6
and may be initiated by the CPEs at any instance of time. For example, a CPE may update
change of value of a parameter to the ACS from time to time. Sometimes, the change in value
may occur very frequently, such as 35 to 50 times in a day and sometimes, the change in value
may occur less frequently, such as 2 to 4 time a day. Similarly, the CPEs may send heartbeat
messages, also known as periodic INFORM messages, to the ACS from time to time. Some
CPEs may send the periodic INFORM messages very frequently while others may send the
hearbeat messages occasionally, as configured by the ACS. Therefore, it would be appreciated
that the number of communications between the CPE and the ACS may vary from time to time.
[0017] Further, since the ACS is connected to multiple CPEs, the number of requests
received by the ACS at any given time instance may also vary from low to high. While at a
certain time instance, there may be no request received by the ACS from any of the CPEs, at
another time instance, multiple CPEs may send requests to the ACS. For example, in situations
when power to the CPEs is resumed after a power cut, all the CPEs may simultaneously initiate a
boot request and communicate with the ACS.
[0018] Therefore, the ACS is generally equipped with sufficient processing capabilities
to handle requests from the CPEs at all times without any disruptions in the working of the
CPEs. Accordingly, with increase in number of the CPEs, the configuration of the ACS is also
proportionally enhanced. However, the inclusion of additional capabilities to the ACS is cost
intensive and such capabilities of the ACS may often remain underutilized for considerable time
periods when the load is low. Therefore, managing an ever-increasing number of CPEs, without
increasing the processing capabilities of the ACS is a challenge.
[0019] According to an implementation of the present subject matter, systems and
methods to optimize ACSs are described. In one implementation, the ACS may utilize the TR-
069 protocol for the purpose of communication and management of the CPEs. The described
systems and the methods, on one hand optimize the operations of an ACS to efficiently handle
the requests from the CPEs, on the other hand, allows the ACS to handle more CPEs without
increasing the processing capabilities. In other words, the ACS may manage an increasing
number of CPEs, without increasing the hardware capabilities, the ACS operates on.
[0020] In one implementation of the present subject matter, an ACS is described which
utilizes time series analysis to predict usage patterns of the CPEs, and thus improves efficiency
7
of handing the requests. It would be appreciated that the ACS, while operating on the TR-069
protocol operates in two different basic modes operation. One mode of operation is when the
CPEs initiates a connection to the ACS. Such mode of operation is referred to as mode of
receiving asynchronous requests, hereinafter. For example, while indicating a change in value of
a parameter or sending a boot request upon startup, the CPEs may make asynchronous requests
to the ACS. As described above, the asynchronous requests received from the CPEs in this mode
of communication is usually stochastic and may occur randomly.
[0021] The other mode of operation is when the ACS either initiates a connection to one
or more CPEs, or schedules the CPEs to make a connection to the ACS. Such requests are
referred to as synchronous requests hereinafter. Although the periodicity and time of requests
initiated may be different for different CPEs, since the periodic inform interval can be configured
by the ACS, such requests are have also been considered as synchronous requests for the purpose
of description of the present subject matter. The traffic of the synchronous requests is usually
deterministic and occurs at pre-defined time instances, or time instances known to the ACS.
[0022] According to an implementation of the present subject matter, the ACS analyzes
the asynchronous requests based on a time series analysis to predict patterns of activity in
asynchronous requests from the CPEs. That is, based on the time series analysis of the
asynchronous requests, the ACS may predict the asynchronous TR-069 traffic input at future
time instances. For example, based on time series analysis of the asynchronous request, it may be
identified that the asynchronous requests received from CPEs are maximum during morning and
evening periods. In the example, it may also be identified that the time period between 11:00 AM
to 3:00 PM is an idle time period for the ACS and the asynchronous requests received during this
period are almost minimal. Accordingly, the ACS may predict that the morning and evening
periods for future as heavy traffic periods and the time periods between 11:00 AM to 3:00 PM
for future as low traffic periods.
[0023] In one implementation, based on the prediction of the asynchronous requests, the
ACS may further schedule its synchronous requests at pre-defined appropriate time periods. The
pre-defined appropriate time period may be identified based on resource parameters identified by
the ACS. The resource parameters may be understood to provide the quantum of ACS resources
required to fulfill a synchronous requests. In said implementation, the resource parameters may
8
depend on some of the following parameters, but not limited to, number of CPEs associated with
the ACS, type of operation expected during the synchronous requests, payload of each request to
be scheduled, time taken for processing of each synchronous request, and priority associated
with each of such synchronous requests.
[0024] In another implementation of the subject matter, depending on the time series
analysis, the predictions of asynchronous requests for future time instances, and the resource
parameters, the ACS may also schedule the synchronous requests in a distributed manner. That
is, the ACS may schedule a part of the synchronous requests for some of the CPEs at one time
instance, and another part of the synchronous requests on remaining CPEs at another time
instance. For example, if an ACS wishes to perform a firmware update operation on 10 thousand
CPEs and based on the resource parameters associated with firmware update operation, the ACS
may schedule 2 thousand firmware update operations at one time instance and postpone the
remaining 8 thousand operations for later time instances. The remaining 8 thousand operations
may either be preformed at a later idle period in the same day, or may be scheduled for initiation
during the same period on the next day.
[0025] Therefore, the time series analysis of the asynchronous requests allows the ACS
to schedule the synchronous requests to optimize the load on the ACS. Further, scheduling of the
requests based on time based analysis may efficiently utilize the processing capabilities, without
necessitating increase in capacity of the ACS based on combined maximum load of two modes
of operation.
[0026] The described methodologies can be implemented in hardware, firmware,
software, or a combination thereof. For a hardware implementation, the processing units can be
implemented within one or more application specific integrated circuits (ASICs), digital signal
processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices
(PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers,
microprocessors, electronic devices, other electronic units designed to perform the functions
described herein, or a combination thereof. Herein, the term "server" or “system” encompasses
logic implemented by software, hardware, firmware, or a combination thereof.
[0027] It should be noted that the description merely illustrates the principles of the
present subject matter. It will thus be appreciated that those skilled in the art will be able to
9
devise various arrangements that, although not explicitly described herein, embody the principles
of the present subject matter and are included within its spirit and scope. Furthermore, all
examples recited herein are principally intended expressly to be only for explanatory purposes to
aid the reader in understanding the principles of the invention and the concepts contributed by
the inventor(s) to furthering the art, and are to be construed as being without limitation to such
specifically recited examples and conditions. Moreover, all statements herein reciting principles,
aspects, and embodiments of the invention, as well as specific examples thereof, are intended to
encompass equivalents thereof.
[0028] The manner in which the systems and methods of optimizing auto configuration
servers shall be implemented has been explained in details with respect to the Figures 1 to 3.
While aspects of described systems and methods can be implemented in any number of different
computing systems, transmission environments, and/or configurations, the embodiments are
described in the context of the following exemplary system(s).
[0029] Fig. 1 illustrates a communication network environment 100 implementation,
describing an auto configuration system (ACS) 102, in accordance with an embodiment of the
present subject matter. The ACS 102 described herein, can be implemented in any network
environment comprising a variety of network devices, including routers, bridges, servers,
computing devices, storage devices, etc. In one implementation the ACS 102 is connected to one
or more CPEs 104-1, 104-2, 104-3, …, 104-N, individually referred to as CPE 104, and
commonly referred to as CPEs 104 hereinafter. The CPEs 104 may be connected to the ACS 102
through a communication network 106.
[0030] Although the description herein is with reference to auto configuration servers,
the methods and systems may be implemented in other servers, albeit with a few variations, as
will be understood by a person skilled in the art. The ACS 102 may also be implemented as a
computing device, such as a laptop computer, a desktop computer, a notebook, a workstation, a
mainframe computer, a server and the like. The ACS 102 described herein, can also be
implemented in any network environment comprising a variety of network devices, including
routers, bridges, servers, computing devices, storage devices, etc. Although the description
herein is with reference to networks implementing TR-069 protocol, the described techniques
10
may be well implemented in other protocols of communications as well, albeit a few variations,
as will be understood by those skilled in the art.
[0031] The CPEs 104 may be implemented as, but are not limited to, sensors, telephones,
routers, switches, residential gateways, set-top boxes, fixed mobile convergence equipments,
hand-held devices, laptops or other portable computers, tablet computers, mobile phones, PDAs,
smartphones, and the like. Further, the CPEs 104 may include devices capable of exchanging
data to provide connectivity to different communicating devices and computing systems. Such
devices may include, but are not limited to, data cards, mobile adapters, wireless (WiFiTM)
adapters, wireless modems, wireless communication devices, cordless phones, wireless local
loop (WLL) stations, and the like. As CPEs 104 may be stationary or mobile and may also be
understood to be a mobile station, a terminal, an access terminal, a subscriber unit, a station, etc.
[0032] The network 106 may be a wireless or a wired network, or a combination thereof.
The network 106 can be a collection of individual networks, interconnected with each other and
functioning as a single large network (e.g., the internet or an intranet). Examples of such
individual networks include, but are not limited to, Global System for Mobile Communication
(GSM) network, Universal Mobile Telecommunications System (UMTS) network, Personal
Communications Service (PCS) network, Time Division Multiple Access (TDMA) network,
Code Division Multiple Access (CDMA) network, Next Generation Network (NGN), Public
Switched Telephone Network (PSTN), and Integrated Services Digital Network (ISDN).
Depending on the technology, the network 106 includes various network entities, such as
gateways, routers; however, such details have been omitted for ease of understanding.
[0033] In one implementation, the ACS 102 includes processor(s) 112. The processor
112 may be implemented as one or more microprocessors, microcomputers, microcontrollers,
digital signal processors, central processing units, state machines, logic circuitries, and/or any
devices that manipulate signals based on operational instructions. Among other capabilities, the
processor(s) is configured to fetch and execute computer-readable instructions stored in the
memory.
[0034] The functions of the various elements shown in the figure, including any
functional blocks labeled as “processor(s)”, may be provided through the use of dedicated
hardware as well as hardware capable of executing software in association with appropriate
11
software. When provided by a processor, the functions may be provided by a single dedicated
processor, by a single shared processor, or by a plurality of individual processors, some of which
may be shared. Moreover, explicit use of the term “processor” should not be construed to refer
exclusively to hardware capable of executing software, and may implicitly include, without
limitation, digital signal processor (DSP) hardware, network processor, application specific
integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for
storing software, random access memory (RAM), non-volatile storage. Other hardware,
conventional and/or custom, may also be included.
[0035] Also, the ACS 102 includes interface(s) 114. The interfaces 114 may include a
variety of software and hardware interfaces that allow the ACS 102 to interact with the entities of
the network 106, or with each other. The interfaces 114 may facilitate multiple communications
within a wide variety of networks and protocol types, including wire networks, for example,
LAN, cable, etc., and wireless networks, for example, WLAN, cellular, satellite-based network,
etc.
[0036] The ACS 102 may also include a memory 116. The memory 116 may be coupled
to the processor 112. The memory 116 can include any computer-readable medium known in the
art including, for example, volatile memory, such as static random access memory (SRAM) and
dynamic random access memory (DRAM), and/or non-volatile memory, such as read only
memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and
magnetic tapes.
[0037] Further, the ACS 102 may include module(s) 118 and data 120. The modules 118,
amongst other things, include routines, programs, objects, components, data structures, etc.,
which perform particular tasks or implement particular abstract data types. The modules 118 may
also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other
device or component that manipulate signals based on operational instructions.
[0038] Further, the modules 118 can be implemented in hardware, instructions executed
by a processing unit, or by a combination thereof. The processing unit can comprise a computer,
a processor, a state machine, a logic array or any other suitable devices capable of processing
instructions. The processing unit can be a general-purpose processor which executes instructions
12
to cause the general-purpose processor to perform the required tasks or, the processing unit can
be dedicated to perform the required functions.
[0039] In another aspect of the present subject matter, the modules 118 may be machinereadable
instructions (software) which, when executed by a processor/processing unit, perform
any of the described functionalities. The machine-readable instructions may be stored on an
electronic memory device, hard disk, optical disk or other machine-readable storage medium or
non-transitory medium. In one implementation, the machine-readable instructions can be also be
downloaded to the storage medium via a network connection.
[0040] In an implementation, the module(s) 118 includes an analysis module 122, a
prediction module 124, a scheduling module 126, and other module(s) 128. The other module(s)
128 may include programs or coded instructions that supplement applications or functions
performed by the ACS 102. In said implementation, the data 120 includes request data 130, CPE
data 132, scheduling data 134, and other data 136. The other data 136, amongst other things, may
serve as a repository for storing data that is processed, received, or generated as a result of the
execution of one or more modules in the module(s) 118. Although the data 120 is shown internal
to the ACS 102, it may be understood that the data 120 can reside in an external repository (not
shown in the figure), which may be coupled to the ACS 102. The ACS 102 may communicate
with the external repository through the interface(s) 114 to obtain information from the data 120.
[0041] In one implementation of the present subject matter, the ACS 102 may receive
asynchronous requests from the CPEs 104. The analysis module 122 of the ACS 102 may
receive such asynchronous requests and analyze the requests for a pre-determined time period.
The analysis module 122 may further perform a time series analysis and predict patterns of
activity for the asynchronous requests.
[0042] In operation, the analysis module 122 may perform the time series analysis on the
asynchronous requests for a period of days, weeks, or months depending upon level of
optimization and acceptable accuracy of time series analysis. In one example, the analysis
module 122 may log the asynchronous requests for one month for the purpose of analysis. In
another example, the analysis module 122 may log asynchronous requests for one year for the
purpose of the analysis. It would be appreciated that the analysis done for longer duration of
asynchronous requests may provide an increased accuracy and higher optimization. For example,
13
an analysis of asynchronous requests of one month may provide less accuracy and less
optimization as compared to an analysis of asynchronous requests for six months.
[0043] In one implementation, the analysis module 122 may also normalize and clean the
logs of the asynchronous requests for the purpose of the time series analysis. That is, prior to the
time series analysis, the analysis module 122 may remove unnecessary requests to obtain
requests of interest from the log. The analysis module 122 may also normalize the requests of
interest for the purpose of analysis. For example, in a one month log of asynchronous requests,
the analysis module 122, along with the requests from CPEs 104 to the ACS, may also identify
other requests and data received by the ACS 102 which is not necessitated for the purpose of
time series analysis. In such a situation, the analysis module 122 may remove unwanted requests
from the log to clean the logs and obtain only the requests of interest for the purpose of analysis.
Further, the information related to the asynchronous requests in the form of logs may include
data in different formats, sizes, and time zones. Therefore, the analysis module 122 may further
normalize the logs corresponding to the asynchronous requests and consistently have the logs in
one format, size, and time zone. Therefore, the analysis module 122 may perform the time series
analysis on the cleaned and normalized logs to predict future patterns of activity for the
asynchronous requests.
[0044] For example, a log of asynchronous requests may include 100000 requests
received by the ACS 102. The log of 100000 requests may include requests send by CPEs 104
which have run into fault conditions and due to which may have sent several redundant requests.
Upon analysis of the logs, the analysis module 122 may identify 15% of the requests to be such
useless requests and may identity the remaining 85% as the requests of interests. Therefore, the
analysis module 122 may remove the 15% requests and generate log of 85000 requests for the
purpose of analysis. Further, in situations where normalization is necessitated, the analysis
module 122 may also normalize the logs for the purpose of time series analysis.
[0045] The analysis module 122 may further segregate the normalized and cleaned logs
into one or more sets, such as training set of logs, validation set of logs, and test set of logs for
the purpose of optimization of the ACS 102. The training set may be utilized by the analysis
module 122 to perform the time series analysis and predict patterns of activity, while the
validation set may be utilized for the purpose of validating the predictions. For instance, in the
14
above described example where the analysis module 122 determined 85000 logs as valid logs for
analysis, these logs may further be divided into the training set, the validation set, and the test
set. In one implementation, the analysis module 122 may divide the 85000 the logs in a ratio of
8:1:1 into the training set, the validation set, and the test set, respectively. In another
implementation, the analysis module may divide the logs in a ratio of 7:2:1 into the training set,
the validation set, and the test set. . It would be appreciated that the test set may be utilized to test
the predictions made based on the time series analysis. Since the use of test sets is well known,
the detailed description for the same has been omitted for the sake of brevity.
[0046] In other words, the prediction analysis performed on the training set of logs may
be validated on the validation set of logs to verify the accuracy of the predictions. This may
allow the analysis module 122 to confirm that the predictions are of acceptable accuracy and,
would provide the desired level of optimization to the ACS 102. In situations where the
acceptable accuracy is not achieved, the analysis module 122 may perform the time series
analysis on a larger training set to further increase the accuracy of the predications. In one
example, the analysis module 122 may shift some logs from the validation set to the training set
to provide more number of logs for the purpose of time series analysis. As described earlier, it
would be appreciated that an analysis of logs for a longer duration may provide an increased
accuracy of the predictions. Therefore, the predications based on the time series analysis of the
training data set may be validated based on the validation set and the desired level of accuracy
may be confirmed.
[0047] In one implementation of the present subject matter, the analysis module 122 may
utilize either an Autoregressive Integrated Moving Average (ARIMA) or an Autoregressive
Moving Average (ARMA) technique on the training set of logs to perform the time series
analysis and predict patterns of activity in asynchronous requests received from the CPE 104, by
the ACS 102.
[0048] It would be appreciated that ARMA and ARIMA are analysis techniques of data
analysis for time series data either to better understand the data or to predict future points in the
data series. In one example, based on the ARIMA technique, the analysis module 122 may
decompose the logs of validation set into 3 components, a random or noise component, a
seasonal component and a trend component. Based on the analysis of the three components, a
15
trend in the asynchronous requests may be analyzed and future traffic to the ACS 102 may be
predicted.
[0049] Fig. 2 represents a graph generated based on ARIMA analysis of a validation set,
by the analysis module 122. In the depicted figure, four different graph panels have been
depicted. The first horizontal panel 202 represents the input traffic to the ACS 102 where the xaxis
represents time and the Y axis represents the number of requests received from the CPEs
104. The second horizontal panel 204 represents the trend component of the input traffic while
the third horizontal panel 206 represents the seasonal component of the input traffic. It would be
understood that trend refers to a rising or falling number of synchronous requests received from
the CPEs 104. The seasonal component of the input traffic may depict the daily rise and fall of
number of asynchronous requests from the CPEs, per time period, such as hourly.
[0050] Further, the last horizontal panel 208 represents the random or noise component
of the inputs traffic. It would be appreciated that the random component 208 is fairly random and
the seasonal component has a fairly steady variation. The sum of the random, seasonal, and trend
components can give a fairly accurate prediction of the TR-069 asynchronous request traffic
input at a future point in time. Therefore, the prediction module 124, based on the time series
analysis performed by the analysis module 122, may predict the future pattern of activity for the
asynchronous requests. Since the prediction of pattern of activity based on time series analysis is
well know, a detailed description of predictions would be make has been omitted for the sake of
brevity. Further, it would also be understood that different other models of prediction, such as
Hidden Markov model (HMM) and Conditional Random fields may also be utilized for the
purpose of time series analysis.
[0051] In one implementation, upon predicting future patterns of activity for
asynchronous requests, the ACS 102 may further analyze the synchronous requests of the ACS
102 to determine the resource parameters associated with the synchronous requests. The resource
parameters may be understood to provide the quantum of ACS resources required to fulfill a
synchronous requests. In other words, the ACS 102 may identify number of CPEs associated
with the ACS 102, type of operation expected during the synchronous requests, payload of each
synchronous request to be scheduled, time taken for processing of each synchronous request, and
priority associated with each of such synchronous requests. Therefore, it would be understood
16
that the resource parameters are indicative of resource and time to be utilized to fulfill the
synchronous requests.
[0052] Based on the determination of the future patterns of activity of asynchronous
requests and the resource parameters associated with the synchronous requests, the ACS may
schedule the synchronous requests from the ACS 102 to the CPEs 104 and optimize the
processing capabilities of the ACS 102. In operation, to identify resource parameters
corresponding to the synchronous requests, the analysis module 122 of the ACS 102 may first
identify the synchronous requests to be scheduled by the ACS 102. As described earlier, the
synchronous requests may include requests which either the ACS 102 initiates with one or more
CPEs 104, or schedules the CPEs 104 to make a connection to the ACS 102. Therefore, based on
the type of synchronous requests, the analysis module 122 may identify the corresponding
resource parameters.
[0053] For example, the ACS 102 may have to schedule a firmware update on 20000
CPEs 104. To initiate such firmware updates, the ACS 102 may have to initiate synchronous
requests with each of the 20000 CPEs 104. In such a situation, the analysis module 122 may
analyze the resource parameters for the firmware update requests and identify payload of each
firmware update, time taken for processing each of such firmware update, and priority associated
with each of such firmware update.
[0054] Further, it may happen that the ACS 102, apart from initiating the firmware
update requests with the 20000 CPEs 104, may also have before scheduled a routine periodic
INFORM message inflow from 100 CPEs 104 at different periodic intervals to receive
information from the CPEs 104. As described earlier, although the periodicity and time of the
periodic INFORM messaged initiated by the CPEs 104 may be different for different CPEs 104,
since the periodic inform interval can be configured by the ACS, such requests are have also
been considered as synchronous requests for the purpose of description of the present subject
matter such periodic INFORM requests are also considered as synchronous requests and
therefore, the analysis module 122 may identify resource parameters corresponding to such
periodic INFORM requests as well.
[0055] In one implementation, upon identifying the future patterns of activity for the
asynchronous requests, the synchronous requests to be performed, and the resource parameters
17
associated with such synchronous requests, the scheduling module 126 may schedule the
synchronous requests to optimize the usage of processing capability of the ACS 102. For
example, the ACS 102 may choose to change the periodicity of the INFORM messages for some,
or all, the CPEs 104. In said implementation, the scheduling module 126 may utilize a linear, or
a non-linear regression technique to schedule the synchronous requests.
[0056] For example, based on the predicted future pattern of activities, the analysis
module 122 has identified that the ACS 102 is idle during the time period ‘XX’, ‘YY’, and ‘ZZ’.
Further, the analysis module 122 may have also identified that the ACS 102 is under moderate
load during the time periods ‘MM’ and ‘PP’. Furthermore, based on the analysis of the
synchronous requests and identification of the resource parameters associated with the
synchronous requests, the analysis module 122 will predict the time and processing capability
necessitated for the completion of each type of synchronous requests. Therefore, the scheduling
module 126 may utilize linear regression technique to schedule the synchronous requests among
the time periods ‘XX’, ‘YY’, ‘ZZ’, ‘MM’, and ‘PP’.
[0057] In the above example, the scheduling module 126 may identify that the
synchronous requests corresponding to the firmware updates are processing intensive and can be
scheduled during the idle time periods. Further, the scheduling module 126 may also identify that
the synchronous requests corresponding to the periodic INFORM messages are relatively light
weight requests and therefore can be scheduled during the moderate load situations of the ACS
102. Therefore, the scheduling module 126 may schedule synchronous requests into time slots
based on the resource parameters of the synchronous requests and, the predicted patterns of
activity for the asynchronous requests.
[0058] In some situations, it may so happen that the ACS 102 may be provided with
updates that may have to be communicated to certain CPEs 104. In such situations, to schedule
the synchronous requests, the analysis module 122 and the prediction module 124 may analyze
and predict patterns of activity based on time series analysis. Further, the resource parameters
associated with the synchronous requests may also be identified based on the regression
techniques. Thereafter, the scheduling module 126 may schedule the synchronous requests to
optimize the usage of processing capabilities of the ACS 102.
18
[0059] Fig. 3 illustrates a method 300 for optimizing the auto configuration servers,
according to an embodiment of the present subject matter. The order in which the method 300 is
described is not intended to be construed as a limitation, and any number of the described
method blocks can be combined in any order to implement the method 300, or any alternative
methods. Additionally, individual blocks may be deleted from the method without departing
from the scope of the subject matter described herein. Furthermore, the method can be
implemented in any suitable hardware, software, firmware, or combination thereof.
[0060] The method may be described in the general context of computer executable
instructions. Generally, computer executable instructions can include routines, programs, objects,
components, data structures, procedures, modules, functions, etc., that perform particular
functions or implement particular abstract data types. The method may also be practiced in a
distributed computing environment where functions are performed by remote processing devices
that are linked through a communications network. In a distributed computing environment,
computer executable instructions may be located in both local and remote computer storage
media, including memory storage devices.
[0061] A person skilled in the art will readily recognize that steps of the method can be
performed by programmed computers. Herein, some embodiments are also intended to cover
program storage devices, for example, digital data storage media, which are machine or
computer readable and encode machine-executable or computer-executable programs of
instructions, where said instructions perform some or all of the steps of the described method.
The program storage devices may be, for example, digital memories, magnetic storage media
such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data
storage media. The embodiments are also intended to cover both communication network and
communication devices configured to perform said steps of the exemplary methods.
[0062] Referring to Fig. 3, at block 302, asynchronous requests received from a plurality
of customer premises equipments (CPEs) are analyzed for a pre-defined time period. The
asynchronous requests may be obtained by the ACS communicatively coupled to one or more
CPEs. In one implementation, during the analysis of the asynchronous requests, the requests
irrelevant for the purpose of analysis may be removed and may further be normalized.
19
[0063] The pre-defined time period may vary depending upon the level of accuracy
required in the analysis of the asynchronous requests. In situations where the pre-defined time
period is large, the level of accuracy may become better while in situations where the pre-defined
time period is low, the level of accuracy may remain relatively less.
[0064] At block 304, patterns of activity are predicted corresponding to the analyzed
asynchronous requests, received by the ACS. In one implementation, the prediction of the
patterns of activity is based on a time series analysis of the asynchronous requests analyzed
during the pre-defined time period. The time series analysis may be conducted based any known
techniques of time series analysis, such as ARMA and ARIMA.
[0065] In one implementation, based on the time series analysis, such as the ARIMA, the
predicted patterns of activity may provide an estimate of traffic to be received by the ACS at
different time instances. In another implementation, synchronous requests to be scheduled by the
ACS are also analyzed and the quantum of ACS resources required to fulfill a synchronous
request is analyzed in the form of resource parameters associated with the synchronous requests.
[0066] At block 306, synchronous requests associated with the ACS may be scheduled
based on the predicted patterns of activity and resource parameters associated with the
synchronous requests. In one implementation, the scheduling may be performed based on a
regression model to identify available slots of time for scheduling of the synchronous requests.
Therefore, the available slots of time, predicted based on the time series analysis, may be utilized
to schedule the synchronous requests based on the resource parameters associated with the
synchronous requests.
[0067] Although the subject matter has been described with reference to specific
embodiments, this description is not meant to be construed in a limiting sense. Various
modifications of the disclosed embodiments, as well as alternate embodiments of the subject
matter, will become apparent to persons skilled in the art upon reference to the description of the
subject matter. It is therefore contemplated that such modifications can be made without
departing from the scope of the present subject matter as defined.
20
I/We claim:
1. A method for optimizing an Auto Configuration Server (ACS), the method comprising:
analyzing asynchronous requests, received by the ACS, from a plurality of
Customer Premises Equipments (CPEs) for a pre-defined time period, wherein the ACS
and the CPEs communicate over TR-069 protocol, and wherein the asynchronous
requests are stochastic in nature;
predicting patterns of activity corresponding to the asynchronous requests
received by the ACS based on a time series analysis of the asynchronous requests during
the pre-defined time period;
scheduling synchronous requests associated with the ACS based on the predicted
patterns of activity and resource parameters associated with the synchronous requests,
wherein the synchronous requests are deterministic and configurable by the ACS, and
wherein the resource parameters associated with the synchronous requests are indicative
of time and resources utilized by the ACS to process the synchronous requests.
2. The method as claimed in claim 1, wherein the resource parameters comprises at least
one of number of CPEs associated with the ACS, type of operation to be performed on the
synchronous requests, payload of each of the synchronous requests, time taken for processing of
each of the synchronous requests, and priority associated with each of such synchronous
requests.
3. The method as claimed in claim 1, wherein the time series analysis of the asynchronous
requests is based on methods of predictive time series analysis, comprising at least one of an
Autoregressive Integrated Moving Average (ARIMA), an Autoregressive Moving Average
(ARMA), a Hidden Markov Model, and a Conditional Random Field model.
4. The method as claimed in claim 1 further comprising determining resource parameters
associated with the synchronous requests based on regression models.
21
5. The method as claimed in claim 1, wherein the synchronous requests comprises at least
one of requests initiated by the ACS and requests initiated by the CPEs based on schedule
provided by the ACS.
6. The method as claimed in claim 1, wherein the pre-defined time period is defined based
on accepted level of optimization and accuracy of predicted patterns of activity.
7. The method as claimed in claim 1, wherein the analyzing further comprises:
cleaning logs of the asynchronous requests; and
normalizing logs of the asynchronous requests.
8. The method as claimed in claim 1, wherein the method further comprises:
segregating logs of the asynchronous requests into at least a training set and a
validation set;
predicting patterns of activity corresponding to the asynchronous requests of the
training set; and
validating the predicted patterns of activity based on accepted level of
optimization and accuracy.
9. An Auto Configuration Server (ACS) (102) comprising:
a processor(112);
an analysis module (122) coupled to the processor (112) to analyze asynchronous
requests, received by the ACS (102), from a plurality of Customer Premises Equipments
(CPEs) (104) for a pre-defined time period, wherein the the ACS (102) and the plurality
of CPEs (104) communicate over TR-069 protocol, and wherein the asynchronous
requests are stochastic in nature;
a prediction module (124) coupled to the processor (112) to predict patterns of
activity corresponding to the asynchronous requests received by the ACS (102) based on
a time series analysis of the asynchronous requests during the pre-defined time period;
and
a scheduling module (126) coupled to the processor (112) to schedule
synchronous requests associated with the ACS based on the predicted patterns of activity
22
and resource parameters associated with the synchronous requests, wherein the
synchronous requests are deterministic and configurable by the ACS, and wherein the
resource parameters associated with the synchronous requests are indicative of time and
resources utilized by the ACS to process the synchronous requests.
10. The ACS (102) as claimed in claim 9, wherein the analysis module (122) further analyzes
the synchronous requests to determine the resource parameters associated with the synchronous
requests based on regression model of analysis.
11. The ACS (102) as claimed in claim 9, wherein the analysis module (122) further
segregates the asynchronous requests received during the pre-defined time into at least a training
set and a validation set, wherein the training set of the asynchronous requests is utilized for the
purpose of predicting the patterns of activity.
12. The ACS (102) as claimed in claim 11, wherein the prediction module (124) further
validates the predicted patterns of activity on the validation set of asynchronous requests based
on accepted level of optimization and accuracy of predicted patterns of activity.
13. The ACS as claimed in claim 11, wherein the resource parameters comprises at least one
of number of CPEs associated with the ACS, type of operation to be performed on the
synchronous requests, payload of each of the synchronous requests, time taken for processing of
each of the synchronous requests, and priority associated with each of such synchronous
requests.
14. The ACS (102) as claimed in claim 12, wherein the analysis module (122) further
redistributes the asynchronous requests into at least one of training sets and validation sets based
on the validation performed by the prediction module (124).
15. A computer-readable medium having embodied thereon a computer program for
executing a method, the method comprising:
23
analyzing asynchronous requests, received by the ACS, from a plurality of
Customer Premises Equipments (CPEs) for a pre-defined time period, wherein the ACS
and the CPEs communicate over TR-069 protocol, and wherein the asynchronous
requests are stochastic in nature;
predicting patterns of activity corresponding to the asynchronous requests
received by the ACS based on a time series analysis of the asynchronous requests during
the pre-defined time period;
scheduling synchronous requests associated with the ACS based on the predicted
patterns of activity and resource parameters associated with the synchronous requests,
wherein the synchronous requests are deterministic and configurable by the ACS, and
wherein the resource parameters associated with the synchronous requests are indicative
of time and resources utilized by the ACS to process the synchronous requests.