WO2025133972A1 - System and method for periodic inform time normalization - Google Patents

Abstract

System and Method for Periodic Inform Time normalization The present invention is enclosed in the area of communications. Particularly, the present invention focuses on ensuring a uniform distribution of Periodic Inform events sent by Customer Premises Equipments (CPEs) to their Auto-Configuration Server (ACS) during the Periodic Inform Interval. The CPE WAN Management Protocol (CWMP), which is defined by the BroadBand Forum (BBF) in Technical Report 069 (TR-069), is a widely used device management protocol that enables the remote management of a device. Leveraging CWMP, this invention addresses the challenge of request peaks over time, linked to the Periodic Contact association with CPE boot. In response to this issue, the invention introduces a system and method that dynamically distributes the Periodic Contact throughout the Periodic Inform Interval. Through slot allocation and iterative recalculations of CPE-to-slot assignments, the invention ensures the normalization of request peaks, contributing to more efficient and stable device management.

Description

DESCRIPTION

SYSTEM AND METHOD FOR PERIODIC INFORM TIME NORMALIZATION

FIELD OF THE INVENTION

The present invention is enclosed in the area of communications, focusing specifically on a system and method designed to ensure a uniform distribution in time of Periodic Inform events transmitted during the designated Periodic Inform Interval by Customer Premises Equipments (CPE) to their Auto-Configuration Server (ACS).

PRIOR ART

The CPE WAN Management Protocol (CWMP), which is defined by the BroadBand Forum (BBF) in Technical Report 069 (TR-069), is a widely used device management protocol that enables the remote management of a device. This protocol standardizes the communication between a client, the CPE, and a server, the ACS, providing the capacity for automatic configuration, service provisioning, firmware upgrade, diagnostics and also performance monitoring.

Focusing on a subset of methods defined in the protocol and used in this invention, the ACS can call the CPE SetParameterValues method to manage the configuration parameters defined in the data model associated to the CWMP, which are defined in other BBF Technical Reports.

The CPE calls the ACS Inform method to establish a session with the ACS. The Inform method has an Event argument in which the events that cause the session to be established are stated. The event that is most relevant for this invention is the "2 PERIODIC", which is sent on a periodic interval after the CPE boots.

The CPEs implement the CWMP and contact the ACS periodically on the value set on the ManagementServer.PeriodicInformlnterval parameter, typically the Periodic Inform Interval is the same for all the devices in the Network Service Provider (NSP) network. These sessions allow the ACS to manage the CPE even if it cannot contact the CPE directly through a Connection Request (CR) and help determine if the CPE is Seen Missing.

The time when the CPE must send the Periodic Inform is called the Periodic Contact and that time in most common client implementations is associated to the boot sequence of the CPE.

PROBLEM TO BE SOLVED

The bigger problem arises from the association of the Periodic Contact for each Customer Premises Equipment (CPE) with its boot time, resulting in a non-uniform distribution of Periodic Contacts over time. So, during the Periodic Inform Interval we can have a random distribution for the CPE Periodic Contact. This ultimately leads to a large number of requests, associated to the sessions that the CPEs try to establish, to accumulate at certain instants during the Periodic Inform Interval. When for example there is a power outage in a geographical zone normally all CPEs will boot at the same time which causes all of them to have approximately the Periodic Contact in the same instant. There are also the scenarios of new CPEs being registered in the ACS, from new customers or when they are replaced for existing customers, and when an equipment suffers a factory reset, in which the CPE will have the Periodic Contact associated to be boot time causing the non-uniform distribution.

This is not a problem when the number of CPEs associated to the ACS is relatively small, but when the ACS must handle millions of CPEs this can cause peaks of thousands of requests to occur simultaneously.

Even with a distributed architecture, this can strain the parallel processing capacity of the ACS. Employing strategies such as queuing requests aims to address them over time, but persistent timeout issues on the client side during session establishment remain a concern. Additionally, the surge in request peaks may lead to the need to increase the computational resources for the ACS platform.

There is a standard definition of a Session Retry Policy so that the CPE retries failed Sessions and tries to redeliver the events to the ACS, but this is a fallback solution, and it does not change the Periodic Contact, meaning that during the next Periodic Inform Interval the large number of requests problem can occur again. If the Periodic Inform Time is not set the behaviour of the CPE will be the same as it will still use the same Periodic Contact as before the retry process.

This invention provides a system and method to avoid those undesirable request peaks guaranteeing a uniform Periodic Contact distribution during the Periodic Time Interval.

SUMMARY OF THE INVENTION

Upon initiation of the algorithm, the Periodic Inform Time Interval is divided into N time slots, each set to a configurable duration (e.g., 1 minute each), where N represents a user-defined variable.

Eligible CPEs, those that have recently contacted the Auto-Configuration Server (ACS) within the defined contact time window, will be taken into account for the limit of CPES contacting by Periodic Inform Time that a slot can accommodate.

CPEs that contacted during the last Periodic Inform Interval window and find themselves in slots exceeding this measured limit will undergo a reallocation of their Periodic Inform Time to the least populated slot. This mechanism ensures that all eligible CPEs are uniformly distributed among these slots, and further guarantees distribution within each slot by introducing a random value.

The next time these CPEs contact the ACS, the reallocation will be considered, and they will be updated with the new Managementserver. PeriodicInformTime parameter, ensuring that their next Periodic Contact is performed within the intended time slot. This algorithm is scheduled to run every two Periodic Inform Intervals. This delay is purposeful, and it allows sufficient time for all relocated CPEs to converge to their intended time slot. The algorithm will again re-evaluate (based on what is described in the paragraph above) the slots that are above limit (either due to misbehaving CPEs or new CPEs entering the equipment park, for example) and adjusts these slots accordingly by reallocating CPEs. If no inconsistencies are detected between the intended distribution and the time when the Periodic Inform was received, the algorithm assumes everything is in order and does not perform any additional tasks. This mechanism is exclusively activated when the type of event received in the Inform is a "2 PERIODIC".

New CPEs that contact the ACS will be automatically allocated to a slot.

So, starting with the equipments having a non-uniform distribution the convergence for all the eligible equipments associated to the ACS to have a Periodic Contact with a uniform distribution is achieved after the algorithm is running for, in the worst-case scenario, the double of the Periodic Inform Time Interval.

Depending on the number of slots configured during the Periodic Inform Interval we can achieve a greater distribution within the slots, until the limit of it being the same value as the Periodic Inform Interval, but we can also have a greater need of rebalancing the slots when the equipments do not contact exactly within the configured slot.

By achieving a uniform distribution, the invention enhances the efficiency, smoothness and reliability of information exchange in communication networks, contributing to an improved overall system performance.

DESCRIPTION OF FIGURES

Figure 1 shows a diagram representing the environment in which some embodiments of the invention may be implemented.

Figure 2 depicts the Periodic Contact of a CPE.

Figure 3 illustrates how the algorithm performs the distribution.

Figure 4 depicts the ACS setting the intended Periodic Inform Time.

Figure 5 shows how an Inform Bootstrap event from the CPE is handled by the ACS.

Figure 6 illustrates the differences on the CPE Periodic Contact distribution during the Periodic Inform Intervals before and after the algorithm runs. DETAILED DESCRIPTION

The present invention provides a system and a method to guarantee that the Periodic Contact performed by the CPEs to the ACS has a uniform distribution during the Periodic Inform Interval, thereby preventing an accumulation of requests at the same time instant.

Figure 1 shows a typical environment where the invention can be applied. A CPE (100), or a set of CPEs, implementing CWMP contact the ACS (110). The ACS comprises a Connection Handler (111), a Core (112), an API (113), a Database (114) and a Message Bus (115).

The ACS (110) is composed by a set of hosts. Those hosts may be materialized using virtual servers, physical servers, containers, or any other type of computational entities. They can also be located on a single datacenter or spread across several datacenters, with the requests being handled by the most suitable location based on specific criteria as infrastructure or network load or even CPE related information.

The Connection Handler (111) implements the specific format and communication sequence defined by the CWMP. It receives the requests from all the CPEs and sends responses accordingly. This component uses the Database (114) to query and persist information related to each CPE and can produce and consume messages from the Message Bus (115) to communicate with the Core (112) in a decoupled and asynchronous way. It handles the connection with CPEs (100) and serves as a communication bridge between them and the Core (112).

The Core (112) is the component that handles the ACS Methods called by the CPE and decides what actions need to be performed on that specific CPE. For example, reconfiguring the Periodic Inform Time if needed. It consumes from the Message Bus (115) messages produced by the Connection Handler (111) and the API (113) and queries and persists information in the Database (114).

The API (113) implements the ACS (110) API that handles requests from external systems to perform operations on CPEs. These requests are stored in the Database (114) and its operations will later be converted into CPE Methods, such as SetParameterValues and GetParameterValues. If the Connection Request (CR) mechanism is demanded, the associated messages are placed in the Message Bus (115) for consumption by the Connection Handler (111).

The Database (114) holds all the crucial information that enables the ACS (110) to manage the CPEs that it has registered. It has operational information as the last Periodic Contact of each CPE (110) or the methods that must be invoked but also the management information that enables the ACS (110) to request the CPE (100) to contact or to authorize it to be registered in the ACS (110).

The Message Bus (115) is used to the decouple the direct communication between all the applicational modules, the Connection Handler (111), the Core (112) and the API (113). This allows the system to increase its processing capacity by performing seamless horizontal scaling for all the modules.

All the authentication and authorization processes that exist in the ACS are not the subject of this invention so, although they exist, in order to simplify the description, they were not detailed or mentioned.

Figure 2 shows how the CPE Periodic Inform is handled by the system.

On step 200 the CPE establishes a session with the ACS by calling the Inform method. The information is interpreted according to what is defined in the CWMP.

At 201 the Connection Handler (111) gets the information related to the CPE from the Database (114).

On step 202 the Connection Handler (111) produces a message using the system's internal data model with the Inform on the Message Bus (115).

The Core (112) consumes the message from Message Bus (115) on step 203. On this step the "2 PERIODIC" event type is obtained from the Inform, so this session will set the CPE Periodic Contact.

On 204 the Core (112) gets all the information related to the CPE and updates the Periodic Contact in the Database (114).

At 205 the Core (112) generates the InformResponse to send to the CPE. At 206 the InformResponse message is produced and placed in the Message Bus (115) by the Core (112).

The Connection Handler (111) consumes the InformResponse message from the Message Bus (115) at step 207.

On step 208 the InformResponse is sent to the CPE (100).

The CPE (100) at step 209 sends an Empty HTTP POST which means it does not have any further ACS methods to call.

On step 210 the Connection Handler (111) produces a message with the Empty HTTP POST and places it on the Message Bus (115).

The Core (112) consumes the message from Message Bus (115) on step 211.

On 212 the Core (112) retrieves all the information related to the CPE from the Database (113).

At 213 the Core (112) checks if there are any pending actions to perform on the CPE.

At 214, as there aren't any pending actions to perform, an Empty message is produced and placed in the Message Bus (115) by the Core (112).

The Connection Handler (111) consumes the Empty response message from the Message Bus (115) at step 215.

Finally, on step 216 the Connection Handler (111) replies with an Empty HTTP response, this sequence of Empty HTTP messages from the CPE and the ACS ends the session.

Figure 3 depicts how the algorithm interacts with the system to achieve a uniform Periodic Contact for all CPEs.

On step 300 the Core (112) gathers three values: the Periodic Inform Interval, the number of slots and also the CPE last contact time window. With this information the Periodic Inform Interval is split into a N number of slots, where N represents a user-defined variable.

At 301 the CPEs that have a Periodic Contact within the last contact window are retrieved from the Database (114). At step 302, the Core (112) assesses each CPE's Contact Time to determine whether it should be assigned to a new slot or remain in its current allocation. During the evaluation within each slot, priority is given to the busiest moment, leading to the reallocation of CPEs to the least populated slots, having a new randomized time within these ones. This approach not only optimizes slot allocation but also reduces peaks for CPEs already in their correct slots. After this relocation, all slots are expected to be populated below a calculated limit, contributing to a more stable distribution of CPEs over time and reducing peaks.

On step 303 the Core (112) persists the Periodic Inform Time is the Database (114) for each CPE that was in the CPE last contact time window. For the CPEs that need to be reallocated a request order with the SetParametersValue Method for the ManagementServer.PeriodicInformTime is created with the intended Periodic Contact for that CPE.

Finally, on 304 the algorithm is scheduled to run again after two Periodic Inform Intervals so it can re-evaluate the Periodic Contact of each CPE that meets the conditions previously specified. It will, like in step 302, determine which slots are above a calculated limit, either due to misbehaving CPEs or new CPEs entering the park, for example, and adjust those slots accordingly by reallocating CPEs to the correct slot. If no inconsistencies are detected between the intended distribution and the time when the Periodic Inform was received, the algorithm determines that the normalization was achieved and does not perform any additional tasks until the next run.

Figure 4 shows the process of how the Periodic Inform Time is set on the CPE (100) by the ACS (110).

Steps 400 to step 412 are exactly the same as the previously described steps 200 to 212.

On step 413 the Core (112) processes the CPE Empty HTTP POST message, which means that there is no other ACS method to call by the CPE, and so it checks if there are any pending actions to perform on the CPE. An order to perform the configuration of the Periodic Inform Time for the CPE is retrieved. The SetParametersValue Method payload for the ManagementServer.PeriodicInformTime parameter is generated.

At 414 the SetParameterValues message is produced and placed in the Message Bus (115) by the Core (112).

The Connection Handler (111) consumes the SetParameterValues message from the Message Bus (115) at step 415.

On step 416 the Connection Handler (111) calls the SetParameterValues CPE Method.

The CPE (100) replies with a SetParameterValuesResponse at step 417.

On step 418 the Connection Handler (111) produces a message using the system's internal data model with the SetParameterValuesResponse on the Message Bus (115).

The Core (112) consumes the message from Message Bus (115) on step 419.

On 420 the Core (112) gets all the information related to the CPE (110).

At 421 the Core (112) processes the result of the SetParameterValuesResponse which is successful. After that it checks if there are any pending actions to perform on the CPE.

At 422, as there aren't any actions to perform, an Empty message is produced and placed in the Message Bus (115) by the Core (112).

The Connection Handler (111) consumes the Empty message from the Message Bus (115) at step 423.

Finally, on step 424 the Connection Handler (111) replies with an Empty HTTP response, this sequence of Empty HTTP messages from the CPE and the ACS ends the session.

From this moment on the ACS considers the CPE to be configured accordingly with the new Periodic Inform Time and may only perform any additional action, regarding the Periodic Inform, if the CPE Contact Time is not within the allocated slot.

Figure 5 shows how the CPE Bootstrap Inform is handled by the system. On step 500 the CPE establishes a session with the ACS by calling the Inform method. The information is interpreted according to what is defined in the CWMP.

At 501 the Connection Handler (111) gets the information related to the CPE from the Database (114).

On step 502 the Connection Handler (111) produces a message using the system's internal data model with the Inform on the Message Bus (115).

The Core (112) consumes the message from Message Bus (115) on step 503. On this step the "0 BOOTSTRAP" event type is obtained from the Inform. This type of event is associated to the first-time connection of the CPE after it was turned on for the first time, after a factory reset or after the ACS URL is changed.

On 504 the Core (112) gets all the information related to the CPE from the Database (114).

At step 505, if the CPE has a prior history of contacting the ACS and is already set with a specific Managementserver. PeriodicInformTime, a request order is generated. This order includes the SetParameterValues Method for the ManagementServer.PeriodicInformTime, using the previous value. In the scenario where the CPE has never contacted the ACS before, and no request order for setting the Periodic Inform Time has been created by the algorithm, the ACS takes no further operations. It only evaluates its slot allocation after the first CPE's periodic contact and during the next iteration of the algorithm.

Steps 506 to step 517 are exactly the same as the previously described steps 205 to 216.

Figure 6 illustrates a practical scenario to use this system and method. In this example, the Periodic Inform Interval is split into 6 slots, with the last Periodic Inform Interval, prior to the first run of the algorithm, serving as the basis for evaluation. There are 13 active CPEs identified by the letter A through M.

In the first Periodic Inform Interval, the graph displays accumulated CPE Periodic Contacts at two instants. After the algorithm initiation and considering the division into 6 slots for each Periodic Inform Interval, all CPEs undergo reallocation within the slots to achieve uniform distribution. Order Requests to change the Periodic Inform Time are generated for CPEs requiring reallocation to the least populated slot or for those that haven't had the parameter set in their configuration, despite remaining in the same slot.

Upon contacting the ACS after the initial algorithm run, these CPEs receive a SetParameterValues Method with the new Periodic Inform Time, placing them in their designated slots. CPEs such as L, D, K, E, M, and F, having already sent their Periodic Inform in the Interval but placed in slots after their Periodic Contact, contact the ACS again on their new Periodic Contact, achieving uniformization in the first Periodic Inform Interval and causing them to contact twice within this Interval.

CPEs reallocated to slots before their Periodic Contact time will contact the ACS in their slot only during the second Periodic Inform Interval after the algorithm's run.

During slot evaluation, allocation to the least populated slot prioritizes the busiest moment within each above-limit slot. In the second Periodic Inform Interval, all CPEs contact the ACS in their intended slots.

In the third Periodic Inform Interval, the algorithm runs again, but no further changes are needed.

This algorithm is scheduled to run every two Periodic Inform Intervals. As shown in the last figure, this delay is purposeful, and it allows sufficient time for all relocated CPEs to converge to their intended time slot. The algorithm will again reevaluate (based on what is described in the paragraph above) the slots that are above limit (either due to misbehaving CPEs or new CPEs entering the ACS equipment park, for example) and adjusts these slots accordingly by reallocating CPEs. If no inconsistencies are detected between the intended distribution and the time when the Periodic Inform was received, the algorithm determines that the normalization was achieved and does not perform any additional tasks until the next run. DESCRIPTION OF THE EMBODIMENTS

The following description is presented to enable any person skilled in the art to build and use the invention. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown.

Claims

Claims

1- A system and method designed to ensure a uniform distribution in time of Periodic Inform events transmitted during the designated Periodic Inform Interval, thereby optimizing network and service resources utilization, wherein: a. the Periodic Inform Interval is divided into N time slots, where N represents a user-defined variable, and each time slot is assigned to one or more CPEs; b. the system continuously monitors the time slots to ensure that CPEs uniformly contact the ACS and dynamically reassigns each CPE to a new slot when its slot is exceeding a measured limit.

2- The system and method of claim 1, that enforces the reallocation of CPEs to their assigned slots: a. the slot assignment is based on the criteria of distributing the number of CPEs evenly within the number of defined N time slots; b. Every time the algorithm runs it evaluates the Periodic Inform Time that is used by every CPE and if it does not meet the intended distribution a new Periodic Inform Time is set so that the CPEs in overpopulated slots are transferred to the least populated slots.

3- The system and method of any preceding claim, wherein the continuous operation of slot assignment, monitoring, and reallocation ensures the normalization of the Periodic Inform Time distribution across all the managed CPEs.