Method and apparatus for the enumeration of sets of concurrently scheduled events

[0001] This application claims the benefit of the filing date of Canadian patent application No. 2,327,001 entitled POLICY SCHEDULE VERIFICATION METHOD AND APPARATUS and filed on Nov. 27, 2000.

[0002] 1. Field of the Invention

[0003] This invention relates to automated scheduling systems. In particular, the invention relates to methods and apparatus for identifying sets of concurrent events in systems of schedules. The invention has application in the field of scheduling generally and has particular application in the field of data communication networks. The invention may be applied in scheduling Quality of Service (QoS) policies for packet handling devices in communications networks. The invention may be applied more generally to identify sets of events which a system of schedules cause to overlap with one another.

[0004] 2. Background of the Invention

[0005] Many fields of endeavour require that series of events be scheduled. An event could be an educational course, a work task, a television or radio program, or any other thing that should occur at a time or during a time period. There may be multiple schedules in effect concurrently. For example a separate schedule may exist for: each lecture room in a university, each work party in a construction crew, or each television channel in a viewing area. Schedules can be complex. This is especially the case if regularly scheduled events can be preempted by special events. For example, in the field of data communications, a QoS policy might be scheduled for activation during specified intervals. Each router or packet forwarding device in a data communications network, or even each interface to a data link within such a device, might have its own set of QoS policies which are activated according to a schedule unique to the device or interface.

[0006] Each schedule is generally associated with a resource whose use is controlled by the schedule. For example, the resource might be a television channel, a work crew, or a lecture hall.

[0007] Each schedule governs the use of its associated resource. The sequence of television programs that can be watched on a television channel is governed by a schedule. The lectures that can be attended in a lecture hall are governed by a schedule.

[0008] Schedules may interdepend—that is, in certain cases an event on one schedule must not be scheduled concurrently with an event on another schedule. For example, consider multiple work crews, each with its own schedule of work tasks. Certain work tasks might require a certain type of equipment that is in limited supply. If there are M items of this type of equipment, only M work crews can perform concurrently work tasks that require this type of equipment. Similarly consider a university that has multiple lecture schedules, one for each lecture room. It would be inappropriate to schedule two lectures at overlapping times where a significant number of students are signed up to attend both lectures.

[0009] Scheduling conflicts may cause a system to malfunction. It is desirable to validate schedules in advance to identify conflicts between scheduled events. While detecting schedule conflicts is trivial where schedules are very simple, detecting conflicts between schedules in a complex system having a large number of schedules which interdepend in various ways is far from trivial. There is currently no satisfactory system for identifying scheduling conflicts in complicated systems.

[0010] In the university lecture scheduling example given above, validation might include checking to see if there are two or more lectures where the number of double or triple booked students exceeds some threshold value. For example, the university may check to see how many students are booked for more than one lecture at 2:30 p.m. on Sep. 20, 2000. In this example, it is not only necessary to validate the set of lectures being held at 2:30 PM, but also those being held at any time on Sep. 20, 2000 which could overlap with any part of the 2:30 p.m. lecture. For the university to validate all of its class schedules, it must perform validation not only for each lecture period on Sep. 20, 2000, but also for every other day of the school term. A first problem that needs to be solved before validation can be performed is to identify all sets of events that a schedule requires to occur concurrently. All such sets of concurrent events from the earliest to the latest date and time in any of the schedules in the group must be enumerated. This invention relates to the efficient enumeration of all sets of concurrent events given a group of schedules.

[0011] On the surface this does not seem to be a difficult problem. All scheduled events can be sorted by their scheduled start date and time. Starting at the earliest start date and time and proceeding to the latest end date and time, the sorted events can be analyzed to identify and enumerate the sets of concurrent events.

[0012] Enumerating sets of concurrent events is often complicated in practice. An enumeration system which mistakenly reports that a conflicting combination of events occurs in a schedule will result in the validation system incorrectly concluding that there is a conflict in the schedule. Therefore, the enumeration system must be accurate. Further, schedules themselves can be complex. First of all, the events in a schedule may be classified into at least three different types as follows:

• • [0013] single-shot events that occur once, starting at a specified date and time and ending at another specified date and time (e.g. a television special);
  • [0014] recurring events that occur on a specified periodic basis between an overall start date and time and an overall end date and time (e.g. a mini-series starting May 1 and running through Jun. 30 that occurs every Monday and Tuesday night between 8:00 and 9:00 PM); and,
  • [0015] recurring events that occur on a specified periodic basis between an overall start date and time and an overall end date and time (e.g. a meeting that takes place in a lecture room on the 1st and the 15th of each month between 7:00 and 10:00 PM).
    For either type of recurring event the overall end date and time may not be known until the event is actually terminated (e.g. a Rotary club meeting may occur on the third Tuesday of each month until the Rotary club ceases operations).

[0016] Secondly, one event can preempt another. For example, regular television network programming may be preempted by coverage of the Academy Awards ceremony. A library in a school might have a schedule for its use as a library which applies except when preempted occasionally for the writing of exams.

[0017] Identifying all sets of concurrent events by sorting all events by their scheduled start date and time will not work because some events may not have a specified end date and time. Unless the searching algorithm is designed carefully, there is a chance of ending up in an infinite loop. Recurring events introduce a serious problem. Within their overall schedules, recurring events have a periodic or aperiodic pattern of occurrence. If the overall end dates and times are not specified, this pattern repeats itself indefinitely.

[0018] Consider three trivial schedules. Each schedule has just one recurring event in it. The overall schedule of each recurring event is from Jan. 1, 2000 until the indefinite future. Suppose the pattern of the three recurring events was that shown below:

• • [0019] Event “A”—from 10:00 AM to 12:00 PM every Monday, Wednesday, and Friday
  • [0020] Event “B”—from 9:30 AM to 10:30 AM on the 1st and 15th of each month
  • [0021] Event “C”—from 10:30 AM to 11:30 AM every other day
    Which sets of concurrent events should be validated? Coincidences between the first and third recurring events are fairly easy to figure out (the coincidences repeat every two weeks). The second event is problematic, since there may be a large number of points in the future where the 1st or 15th of each month happens to fall on a Monday, Wednesday, Friday, and/or “every other day”.

[0022] Many real life situations involve a large number of concurrent schedules. For example, a university may have several hundred lecture rooms. In certain data network scenarios, there may be as many as a million routers or packet handling devices, each with several interfaces. Even if each schedule has relatively few events, analysis of the schedules to enumerate the sets of concurrent events may be extremely difficult. A brute force, time-based enumeration of events may easily degenerate into an infinite loop that never terminates.

[0023] Another problem that needs to be solved is to enumerate the minimum set of unique sets of concurrent events that require validating. Validating each set of concurrent events may be very computationally expensive. This is certainly true of QoS policy validation. In addition there may be time constraints on how long it takes to perform validation. It is often desirable to perform validation while a user is waiting for a response so that the user can interactively adjust a schedule.

[0024] To be efficient a validation process should not waste time validating sets of concurrent events that have been previously validated. If one considers the above three schedules with their simple recurring events, it should be obvious that the same sets of concurrent events will repeat themselves. As a trivial example of this, consider two concurrent recurring events:

• • [0025] from 10:00 AM to 12:00 PM every Monday, Wednesday, and Friday
  • [0026] from 10:30 AM to 11:30 AM every other day
    Assume that the overall schedule for these two recurring events is fixed to start on Jan. 1, 2000 and end on Dec. 31, 2000. During the year this schedule is in operation, the first recurring event occurs approximately 52×3=156 times and the second recurring event occurs approximately 365/2=182 times. Iterating through the year checking the set of events whenever one of these events occurs would waste computational resources. It would require validation of approximately 338 sets of events. There is no commonality between the 156 events and the 182 events, because they start at 10:00 AM and 10:30 AM respectively.

[0027] The inventors have identified a solution to this problem which identifies the 4 unique sets of concurrent events: neither event in progress, only the first event is in progress, only the second event is in progress, and both events in progress. This results in an 80-fold reduction in validation effort.

[0028] The fact that, in this example, there are only four unique combinations of the two recurring events suggests another simple method for solving the problem. Instead of performing brute force, time-based enumeration of events, one can calculate all of the possible combinations of events and evaluate all of them. Unfortunately there are two problems with this supposedly simple method. First, the number of possible unique combinations can be quite large. If N resources each have a schedule containing one recurring event, there can be as many as 2^N combinations of these events being in progress or not in progress if the timing of the events is being ignored. It does not take very many resources before it becomes impractical to validate the possible combinations. As an example of how impractical such an approach can be, consider the following. In a packet handling device developed by the inventors, there can be more than 256 output interfaces that are controlled by QoS policies. Each interface has its own schedule of QoS policies to activate. The above approach would require that more than 2²⁵⁶ combinations of QoS policies be identified and evaluated. There is not and never will be enough disk storage to even list the possible combinations, much less validate them. In practice, very few of the 2²⁵⁶ combinations would ever really occur. Most of the interfaces just have a default QoS policy that is scheduled to be always active.

[0029] A method for enumerating sets of concurrent events should be able to deal with schedules made up of sub schedules. A resource might be controlled by a single master schedule. The master schedule could detail all events including multiple levels of preempting events. Typically, however, a master schedule is constructed from multiple partial schedules. For example, FIG. 3 indicates that a television station might develop its schedule of regular programs for the fall season 200 sometime in the summer. The network, of which the television station is an affiliate, might largely determine this schedule. Overlaid on this schedule will be a specialized schedule 201 for major events such as the Olympics. Schedule 201 preempts schedule 200. One can imagine that when the Olympics were held in Atlanta, Ga. several years ago, the schedule of Olympic event and news coverage was unique for the Atlanta affiliate. Overlaid on top of these schedules is yet another schedule 202 pulled together at the last moment to handle breaking news events (e.g. the interviews and coverage immediately following an airplane crash).

[0030] Operational efficiencies can be achieved by constructing a master schedule from simpler schedules. For example, the individuals constructing a detailed schedule of coverage of Olympic events probably do not want to worry about the interaction of this detailed schedule with the coarser-grained schedule of regular programs. Instead, periods of time would be blocked off in the regular schedule for Olympic coverage. The individuals planning the detailed Olympic schedule can then construct a more detailed schedule within the allotted periods of time.

[0031] When a master schedule is constructed from multiple simpler schedules, each schedule can be assigned a priority. A higher priority schedule interrupts or preempts a lower priority schedule.

[0032] In summary, the usage of a set of N resources might be governed by N master schedules, one per resource. Each master schedule might be an amalgamation of multiple simpler mini-schedules. Each of the mini-schedules has a priority that determines which mini-schedule is currently in effect. Each mini-schedule contains a variety of single-shot and recurring events that may or may not have a termination date and time specified.

[0033] It should be obvious that identifying a minimum set of unique sets of concurrent events to be validated is non-trivial in many practical situations. There is a need for some method for enumerating sets of concurrent events from schedules for N resources. Preferably the method should accommodate each resource having a master schedule comprising multiple mini-schedules each with a preemption priority. The method should preferably generate a set having the minimum number of unique sets of concurrent events.

[0034] Various aspects of the invention provide methods, data structures, apparatus and computer program products which relate to the identification of sets of concurrent events. One aspect of the invention provides a computer-implemented method for enumerating sets of concurrently scheduled events for automatic validation. The method comprises, in a programmed computer system:

• [0035] a) providing a universal master schedule comprising a plurality of time period data records (TPDRs) each having a start time and an end time, at least some of the TPDRs comprising references to events, each event having an overall start time and an overall end time, the events including recurring events each having a period;
• [0036] b) retrieving a TPDR from the universal master schedule;
• [0037] c) establishing a time limit for the TPDR;
• [0038] d) performing a time-based iteration to identify sets of concurrent events by:
  • [0039] 1) establishing the start time of the TPDR as a selected time;
  • [0040] 2) identifying a set of zero or more events occurring at the selected time;
  • [0041] 3) creating a record of the set of zero or more events occurring at the selected time;
  • [0042] 4) identifying a new selected time corresponding to a next time when an event referenced by the TPDR could start or stop; and,
  • [0043] 5) repeating actions (2) to (4) until the new selected time is in excess of the time limit; and,
• [0044] e) performing actions (b) through (d) for each TPDR in the universal master schedule.

[0045] Another aspect of the invention provides a universal master schedule data structure for use in a computerized system for enumerating sets of concurrent events between a dawn of time and an end of time. The universal master schedule data structure comprises a plurality of time period data records (TPDRs), each comprising a start time of a corresponding time period; an end time of a corresponding time period; and, references to zero or more events capable of occurring within the time period, the events having overall start times and overall end times. The time periods of the time period data records are non-overlapping and continuous between the dawn of time and the end of time. All of the overall start times and all of the overall end times correspond to the dawn of time, the end of time or one of the start times.

[0046] A further aspect of the invention provides apparatus for enumerating sets of concurrently scheduled events. The apparatus comprises: a first means for collapsing a plurality of mini-schedules into a master schedule; a second means for collapsing a plurality of master schedules into a universal master schedule, the second means connected to receive a plurality of master schedules generated by the first means; and, a third means for extracting a plurality of sets of concurrent events, the third means connected to receive a universal master schedule from the second means and to store a data record containing information identifying sets of concurrent events scheduled in the universal master schedule.

[0047] Further details, features and advantages of the invention are described below.

[0054] A currently preferred embodiment of the invention will now be described. The following description is of a specific embodiment of the invention applied to the validation of Quality of Service (“QoS”) policies in a data communication network. The invention may also be applied to the validation of other schedules.

[0055] A data communication network comprises a number of interconnected data packet handling devices. The packet handling devices typically include routers and may also include other devices such as switches, bridges, gateways, firewall devices, and so on. The QoS policies control the QoS (e.g. bandwidth, delay, jitter, etc.) that is enforced by routers and other packet forwarding devices. QoS policies can be scheduled for activation in various parts of a network at various dates and times. Packets passing through the network must experience a consistent set of QoS policies in order to be provided appropriate treatment. This invention may be used to enumerate all of the sets of QoS policies that may be concurrently active. Each set can then be validated for consistency.

[0056] A data communication network typically has a default QoS policy that is active with an unspecified termination date and time. This QoS policy might be interrupted by a QoS policy with a recurring schedule that specifies the QoS for an enterprise during its normal weekday working hours. Either of these QoS policies might be interrupted by a single-shot QoS policy that specifies the QoS for a specific event (e.g. a one-time video conference call).

[0057] A data communication network has a large number of resources for which schedules may exist. These resources might include central packet forwarding processors in packet handling devices such as routers. The schedule controls when QoS policies are applied to packets transiting through the device. For example, FIG. 1 shows several routers 10-16 whose central packet forwarding processors are controlled by scheduled QoS policies. In some cases. The resource may be the limited bandwidth of a data link leaving the packet handling device. In such cases the interface might have its own schedule of QoS policies for prioritizing access to the bandwidth resource. For example, FIG. 2 shows a router or packet handling device where the packet flows 121-126 being forwarded out of output interfaces 102-107 are controlled by QoS policies 111-116. The packets originate at input interface 101. The QoS policy enforced by the central packet forwarding processor or for each interface in a router or packet handling device is governed by a schedule.

[0058] In a packet handling device, a master schedule might be constructed from several simpler schedules. At the lowest level there is a simple schedule of default QoS policies that specify default treatment of packets when no other policies are active. Layered on top of this, for example, is a slowly evolving schedule of QoS policies to handle long duration data services that are subscribed to well in advance. Layered on top of this is a quickly evolving schedule of QoS policies to handle one-time, short duration data services that are subscribed to on a dynamic basis, perhaps just before the service is used.

[0059] In a packet handling device, QoS policies contain classification rules which select a subset of the packets passing through the device in order to specify the QoS treatment that those packets are to receive. For example, a QoS policy might specify that all TCP packets destined to TCP port 80 at the IP address 208.216.181.15 should take advantage of a reserved pool of 1 Mbps of bandwidth. It so hapens that this policy would match all web browsing traffic (TCP port 80) destined for the web site (208.216.181.15).

[0060] A conflict occurs if another QoS policy in the same packet handling device specifies that this same traffic must compete for whatever bandwidth is available. For example, in FIG. 2 QoS policy 112 might contain the above rules specifying that web traffic boundd for the web site (208.216.181.15) should take advantage of 1 Mbps of bandwidth that is reserved for such traffic on output interface 103. The QoS policy 114 might also contain rules matching the web browsing traffic bound for the web site(208.216.181.15), but QoS policy 114 might specify that this traffic should just compete with other traffic for access to the bandwidth of output interface 105. If both of policies 112 and 114 were in effect simultaneously then a conflict would occur since the router or packet handling device would not know which of the two policies to enforce. Even if the two mismatching policies are in separate routers or packet handling devices and one device is upstream of the other, there may not be a direct conflict, but packets will not be consistently provided with the appropriate QoS treatment.

[0061] In a complex set of N master schedules, each schedule consisting of prioritized preempting mini-schedules, there will be many different sets of concurrent events that must be validated. Validation is used to detect concurrently scheduled events that are incompatible. A validation method is fed a set of concurrent events. The set of events is analyzed to detect events that are incompatible. For example, the co-pending commonly owned Canadian patent application entitled POLICY VERIFICATION METHODS AND APPARATUS filed on Nov. 27, 2000 describes a policy validation method that can detect conflicts in a set of QoS policies that are scheduled to be active simultaneously.

[0062] The method begins by obtaining a schedule for each of N resources. In a preferred embodiment of the invention, each schedule comprises one or more mini-schedules. The mini-schedules each have a priority. Higher-priority mini-schedules preempt lower priority mini-schedules. Each mini-schedule schedules zero or more events. The events may be one-shot events or recurring events.

[0063] The method of the invention requires the ability to designate when events start and end. In a preferred embodiment of the invention each event has a starting date and time and an ending date and time. In the following discussion, “time” means a date and time. The time may be represented in any format which uniquely specifies a time within a suitable range. In addition to absolute times (e.g. Feb. 7, 2000 8:05 PM), two special values are used:

• • [0064] Dawn of Time (“DOT”) and,
  • [0065] End of Time (“EOT”).
    Dawn of Time represents a time that precedes any other specified start or end time. End of Time represents a time indefinitely in the future. Events with no specific end time can be assigned EOT as their end times.

[0066] Each single-shot event is represented by a data record containing the following information:

• • [0067] overall start time;
  • [0068] overall end time;
  • [0069] preemption priority of the associated mini-schedule;
  • [0070] the identity of the resource for which this event is scheduled; and,
  • [0071] the identity of the single-shot event (event ID).
    The qualifier “overall” has been added to the start and end dates and times of single-shot events to simplify the following discussion by using consistent terminology.

[0072] Each periodic recurring event is represented by a data record containing the following information:

• • [0073] overall start time;
  • [0074] overall end time;
  • [0075] a time pattern for occurrences of the event within the overall period;
    • [0076] the length of the pattern's period;
    • [0077] the start time of the pattern instance that is in progress at the time of the overall start time of the event;
    • [0078] a list of one or more pairs of start dates and times and end dates and times within the pattern;
  • [0079] preemption priority of the associated mini-schedule;
  • [0080] the identity of the resource for which this event is scheduled; and,
  • [0081] the identity of the recurring event (event ID).
    Within the two types of data record, event IDs serve as a reference to more detailed information about the event.

[0082] This invention compiles lists of events that can occur within time periods in time period data records (“TPDRs”). Each TPDR corresponds to a specific time period and contains the following information:

• • [0083] start time of the time period;
  • [0084] end time of the time period; and,
  • [0085] a list of the identities of one or more event data records for events that can occur within the time period.
    An event data record can only be referenced in a TPDR if the event data record's overall start time is earlier or the same as the TPDR's start time. Similarly, an event data record can only be referenced in a TPDR if the event data record's overall end time is later or the same as the TPDR's end time. Those individuals skilled in the art will appreciate that other data record formats can be defined without changing the essential nature of the invention.

[0086] As shown in FIG. 4, a method 100 according to the invention starts by taking all mini-schedules associated with each of N resources and collapsing those mini-schedules into a master schedule for each resource (sub-method 300). The method continues by collapsing the N resource master schedules into a single universal master schedule (sub-method 400). The method concludes by iterating through each time period in the universal master schedule to identify sets of concurrent events (sub-method 500).

[0087] In sub-method 300, if a resource has only a single schedule, that schedule is treated as if it is the only mini-schedule for that resource. A separate master schedule is created for each resource. The resulting resource master schedule comprises a sequence of TPDRs ordered by their start dates and times. The periods covered by the TPDRs do not overlap. Each TPDR references those event data records of events that can occur within the time period covered by the TPDR. An event data record may be referenced by a sub-sequence of one or more TPDRs. During sub-method 300, each event is transformed, if necessary, into an event data record of the appropriate type that is referenced by one or more TPDRs.

[0088] For each of N resources, a master schedule data structure is created to hold the resource's master schedule. The master schedule data structure can hold an sequence of TPDRs ordered by start time of the periods to which the TPDRs relate. The master schedule data structure should provide O(log N) or better performance for the insertion of TPDRs. On request, the master schedule data structure should return, with O(log N) performance or better, the TPDR whose time period contains a given time. The master schedule data structure should also support ordered iteration through the TPDRs in the data structure. The master schedule data structure may comprise, for example, a B-tree or a skip list.

[0089] For each of N resources, method 300 initially creates in the master schedule data structure a single TPDR whose start time is DOT and end time is EOT. The initial TPDR references no event records. For each of N resources, the mini-schedules corresponding to the resource are sorted by preemption priority. The sorted mini-schedules are then processed in order starting with the lowest priority and ending with the highest priority. The order in which mini-schedules of equal priority are processed does not matter.

[0090] The events in each mini-schedule are processed. The order of processing is not important. For each single-shot event, a single-shot event data record is created. For each recurring event, a recurring event data record is created. If a current event has no specified overall end time, it is assigned EOT as its overall end time. It is also allowable for an event to be assigned DOT as its overall start time.

[0091] For each event, the master schedule data structure for the resource is accessed using the start time of the event to retrieve the TPDR whose period includes the event's overall start time (the current TPDR). The event's overall start time is compared to the current TPDR's start time. The event's overall end time is compared to the current TPDR's end time. One of six situations can occur as follows:

• [0092] 1. The event's overall start time is identical to the start time of the current TPDR and the event's overall end time is earlier than the end time of the current TPDR. In this case, as shown in FIG. 5A, the overall time period of the event corresponds to a leading part of the current TPDR's time period.
  • [0093] In this situation, two modified versions of the current TPDR are created and saved in the master schedule data record for the resource in place of the current TPDR. A first modified version of the TPDR differs from the current TPDR in that its end time is set to the overall end time of the event. A second modified version of the current TPDR differs from the original in that its start time is set to the overall end time of the event. In practice, this can be done by cloning (i.e. making a copy of) the current TPDR, modifying the current TPDR and the copy of the current TPDR to yield the first and second modified versions of the current TPDR and then saving the modified copy in the master schedule data structure. The first modified version of the TPDR is made to reference the event data record as described below.
• [0094] 2. The event's overall start time is identical to the start time of the current TPDR and the event's overall end time is identical to the end time of the current TPDR. In this case, as shown in FIG. 5B, the overall time period of the event corresponds exactly with the time period of the current TPDR.
  • [0095] In this case the current TPDR is made to reference the event data record as described below.
• [0096] 3. The event's overall start time is identical to the start time of the current TPDR and the event's overall end time is later than the end time of the current TPDR. In this case, as shown in FIG. 5C, the time period of the current TPDR corresponds to a leading edge of the event's overall time period.
  • [0097] In this situation, the current TPDR is made to reference the event data record, as described below.
• [0098] 4. The event's overall start time is later than the start time of the current TPDR and the event's overall end time is earlier than the end time of the current TPDR. In this case, as shown in FIG. 5D, the overall time period of the event is embedded in the middle of the current TPDR's time period.
  • [0099] In this situation, the current TPDR is replaced with three modified versions of the current TPDR. A first modified version of the TPDR differs from the current TPDR in that the end time is set to the overall start time of the event. A second modified version of the TPDR differs from the current TPDR in that the start time is set to the overall start time of the event and the end time is set to the overall end time of the event. A third modified version of the TPDR differs from the current TPDR in that the start time is set to the overall end time of the event. This may be achieved, for example, by cloning the current TPDR twice, changing each of the original and the two cloned copies to create the first, second and third modified versions of the TPDR. The two modified clone copies of the TPDR are then inserted into the resource master schedule data structure. The second modified version of the TPDR is made to reference the event data record as described below.
• [0100] 5. The event's overall start time is later than the start time of the current TPDR and the event's overall end time is identical to the end time of the current TPDR. In this case, as shown in FIG. 5E, the overall time period of the event corresponds to the trailing edge of the time period of the current TPDR.
  • [0101] In this situation, the current TPDR is replaced with two modified versions of the current TPDR. The first modified version differs from the current TPDR in that its end time is set to the overall start time of the event. The second modified version of the TPDR differs from the current TPDR in that its start time is set to the overall start time of the event. This may be implemented, for example, by cloning the current TPDR, modifying the current TPDR and the cloned copy of the TPDR to yield the first and second modified versions of the current TPDR and then inserting the modified clone copy of the current TPDR is inserted into the resource's master schedule data structure. The second modified version of the current TPDR is made to reference the event data record as described below.
• [0102] 6. The event's overall start time is later than the TPDR's start time and the event's overall end time is later than the TPDR's end time. In this case, as shown in FIG. 5F, the overall time period of the event partially overlaps the trailing edge of the time period of the current TPDR.
  • [0103] In this situation, the current TPDR is replaced with first and second modified versions of the current TPDR. The first modified version of the current TPDR differs from the current TPDR in that its end time is set to the overall start time of the event. The second modified version of the original TPDR differs from the current TPDR in that its start time is set to the overall start time of the event. This may be implemented, for example, by making a clone of the current TPDR, modifying bothe the current TPDR and the clone to yield the first and second modified versions of the current TPDR and then inserting the clone copy of the TPDR into the resource's master schedule data structure. The second modified version of the current TPDR is made to reference the event data record as described below.

[0104] In all six situations, each time an event is processed, a TPDR is modified to include a reference to the event. The reference may be, for example, a pointer to the event's data record. If the event is a single-shot event, the reference to its single-shot event data record can replace any other references to event data records in the TPDR. This indicates that a single-shot event preempts any other lower priority event(s) that would otherwise have been scheduled to occur during the time period covered by the TPDR. An error is declared if the single-shot event has the same priority as any other events referenced by the TPDR.

[0105] If the event being processed is a recurring event, the reference to its recurring event data record is added to the list of references to event data records in the TPDR. An error is declared if the recurring event has the same priority as any single-shot events referenced by the TPDR. Where a TPDR includes references to more than one event, all of the referenced events could possibly occur in the time period covered by the TPDR.

[0106] It should be noted that where a TPDR references an event, the event might not actually occur in the time period covered by the TPDR. The time period covered by the TPDR may be too short for a recurring event to actually occur given that the recurring event's period may be quite long and the duration that the event is actually in progress may be short. A low priority single-shot event may never get a chance to occur, because of higher priority recurring events which preempt it.

[0107] In situations 3 and 6 above, the overall time period of the event extends to an overall end time and date which is later than the end time and date of the TPDR. In each of these cases the event overlaps into at least one following TPDR and possibly additional TPDRs. When an event is added to a TPDR, the event is also added to each successively following TPDR in the resource master schedule data structure up to and including the TPDR whose time period includes the overall end time of the event. In the following description, each of the successive TPDRs that are being processed is referred to as an overlapping TPDR, because the time period of the event being processed overlaps with the TPDR.

[0108] If the event's overall end time is later than or equal to the end time of the overlapping TPDR, the event completely overlaps the time period covered by the overlapping TPDR. In this case sub-method 300 modifies the overlapping TPDR to include a reference to the event data record. If the event is a single-shot event, the reference to its single-shot event data record replaces any other references to event data records in the overlapping TPDR. If the event is a recurring event, the reference to its recurring event data record is added to the list of references to event data records in the overlapping TPDR. Errors are declared for events of equal priority as described above.

[0109] If the event's overall end time is earlier than the end time of the overlapping TPDR, the event partially overlaps the time period covered by the overlapping TPDR. In this case the overlapping TPDR is replaced with first and second modified versions of the overlapping TPDR. The first modified version of the overlapping TPDR differs from the overlapping TPDR in that its end time is set to the overall end time of the event. The second modified version of the overlapping TPDR differs from the overlapping TPDR in that its start time is set to the overall end time of the event. This may be implemented by making a clone of the overlapping TPDR, modifying the clone and the overlapping TPDR to yield the first and second modified versions of the overlapping TPDR and then inserting the modified clone copy into the resource's master schedule data structure.

[0110] The first modified version of the overlapping TPDR is made to include a reference to the event data record. If the event is a single-shot event, the reference to its single-shot event data record replaces any other references to event data records in the first modified version of the overlapping TPDR. If the event is a recurring event, the reference to its recurring event data record is added to the list of references to event data records in the first modified version of the overlapping TPDR. Errors are declared for events of equal priority as described above.

[0111] Sub-method 300 processes events from mini-schedules of increasingly higher priority until all of the mini-schedules for a given resource have been processed. The resulting resource master schedule data structure contains one or more TPDRs, each of which references zero or more event data records. A TPDR references zero event data records, if there is no event whose overall time period includes the time period covered by the TPDR. With the possible exceptions of the start time of the first TPDR and the end time of the last TPDR in the resource master schedule data structure, the start and end dates and times of all TPDRs coincide with the start or end dates and times of events. The corollary is that for each event's overall start time, there is a TPDR with that time as its end time followed immediately by another TPDR with that time as its start time. Similarly, for the end time of each event (other than events having end times of EOT), there will be a TPDR with that time as its end time followed immediately by another TPDR with that time as its start time. For any event referenced by a TPDR, the time period covered by the TPDR will be identical to or a sub-period of the event's overall time period. Processing of resources continues until a resource master schedule has been constructed for each resource.

[0112] Software instructions which cause a date processor to perform sub-method 300, together with the date processor on which they are run may be called a means for collapsing a plurality of mini-schedules into a master schedule. The software instructions themselves may be termed software means for collapsing a plurality of mini-schedules into a master schedule.

[0113] The method of the invention proceeds by collapsing the N resource master schedules into a single universal master schedule (sub-method 400 in FIG. 4). In sub-method 400 a first one of the N resource master schedule data structures is preferably re-designated as the single universal master schedule data structure. Each of the remaining N−1 resource master schedule data structures is then iteratively collapsed into the universal master schedule data structure. The order in which the remaining N−1 resource master schedule data structures is collapsed into the universal master schedule data structure does not matter.

[0114] Each one of the remaining N−1 master schedule data structures is processed by taking each of its TPDRs, in order. The current TPDR can be designated as “TPDR A”. Each TPDR A is collapsed into the universal master schedule data structure as follows. The universal master schedule data structure is accessed in order to retrieve the TPDR whose time period includes the start time of TPDR A. This TPDR may be called “TPDR B”. The start time of TPDR A is compared to the start time of TPDR B. The end time of TPDR A is compared to the end time of TPDR B. Once again, one of six situations can occur as follows:

• [0115] 7. The start time of TPDR A is identical to the start time of TPDR B and the end time of TPDR A is earlier than the end time of TPDR B.
  • [0116] In this situation, TPDR B is replaced with first and second altered TPDRs. The first altered TPDR differs from TPDR B in that its end time is set to the end time of TPDR A. The second altered TPDR differs from TPDR B in that its start time is set to the end time of TPDR A. This may be accomplished, for example, by cloning TPDR B, altering the original and cloned copies of TPDR B to yield the first and second altered TPDRS and then saving the cloned TPDR B in the universal master schedule data structure. The first altered TPDR is modified as described below to include references to the event data records in TPDR A.
• [0117] 8. The start time of TPDR A is identical to the start time of TPDR B and the end time of TPDR A is identical to the end time of TPDR B. In this case the time period of TPDR A corresponds perfectly with the time period of TPDR B.
  • [0118] In this situation, TPDR B is modified as described below to include references to the event data records in TPDR A.
• [0119] 9. The start time of TPDR A is identical to the start time of TPDR B and the end time of TPDR A is later than the end time of TPDR B.
  • [0120] In this situation, TPDR B is modified as described below to include references to the event data records in TPDR A.
• [0121] 10. The start time of TPDR A is later than the start time of TPDR B and the end time of TPDR A is earlier than the end time of TPDR B.
  • [0122] In this situation, TPDR B is replaced with first, second and third altered TPDRs. The first altered TPDR differs from TPDR B in that its end time is set to the start time of TPDR A. The second altered TPDR differs from TPDR B in that its start time is set to the start time of TPDR A and its end time is set to the end time of TPDR A. The third altered TPDR differs from TPDR B in that its start time is set to the end time of TPDR A. This may be implemented, for example, by creating two clone copies of TPDR B, modifying the original and cloned copies of TPDR B to yield the first second and third altered TPDRs and inserting the two modified clone copies into the universal master schedule data structure. The second altered TPDR is modified as described below to include references to the event data records in TPDR A.
• [0123] 11. The start time of TPDR A is later than the start time of TPDR B and the end time of TPDR A is identical to the end time of TPDR B.
  • [0124] In this situation, TPDR B is replaced by first and second altered versions of TPDR B. The first altered version of TPDR B differs from TPDR B in that its end time is set to the start time of TPDR A. The second altered version of TPDR B differs from TPDR B in that its start time is set to the start time of TPDR A. This may be implemented, for example, by creating a clone copy of TPDR B, modifying the original and clone copies of TPDR B to yield the first and second altered TPDRs and inserting the modified clone copy into the universal master schedule data structure. The second altered TPDR is modified as described below to include references to the event data records in TPDR A.
• [0125] 12. The start time of TPDR A is later than the start time of TPDR B and the end time of TPDR A is later than the end time of TPDR B.
  • [0126] In this situation, TPDR B is replaced by first and second altered versions of TPDR B. The first altered version of TPDR B differs from TPDR B in that its end time is set to the start time of TPDR A. The second altered version of TPDR B differs from TPDR B in that its start time is set to the start time of TPDR A. This may be implemented, for example, by creating a clone copy of TPDR B, modifying the original and clone copies of TPDR B to yield the first and second altered TPDRs and inserting the modified clone copy into the universal master schedule data structure. The second altered TPDR is modified as described below to include references to the event data records in TPDR A.

[0127] In all six situations, TPDR B or an altered TPDR which replaces TPDR B is modified by adding to any references to events in TPDR B references to each of the events referenced in TPDR A. References from TPDR A do not replace any references already present in TPDR B. The universal master schedule aggregates the events of N resources. The events for any resource may occur simultaneously with events for other resources.

[0128] In situations 9 and 12 above, the overall time period of TPDR A extends into the time period of at least one TPDR following TPDR B and possibly into the time periods of additional TPDRs. For each TPDR A, the successively following TPDRs in the universal master schedule data structure are iteratively processed up to and including the TPDR whose time period includes the end time of TPDR A. In the following description, each of the successive TPDRs that are being processed is referred to as an overlapping TPDR, because its time period overlaps that of TPDR A.

[0129] If the end time of TPDR A is later than or equal to the end time of the overlapping TPDR, TPDR A completely overlaps the time period covered by the overlapping TPDR. In this case sub-method 400 modifies the overlapping TPDR by adding references to the event data records in TPDR A. If the end time of TPDR A is earlier than the end time of the overlapping TPDR, TPDR A partially overlaps the time period covered by the overlapping TPDR. In this case, the overlapping TPDR is replaced with first and second altered overlapping TPDRs. The first altered overlapping TPDR differs from the overlapping TPDR in that its end time is set to the end time of TPDR A. The second altered overlapping TPDR differs from the overlapping TPDR in that its start time is set to the end time of TPDR A. This may be implemented by cloning the overlapping TPDR, modifying the original and cloned overlapping TPDRs to yield the first and second altered overlapping TPDRs and then inserting the modified cloned overlapping TPDR into universal master schedule data structure. Sub-method 400 modifies the first altered overlapping TPDR by adding references to the event data records in TPDR A.

[0130] At this point, TPDR A can be discarded.

[0131] Sub-method 400 continues until all of the TPDRs in the remaining N−1 resource master schedule data structures have been processed. The resulting universal master schedule data structure contains one or more TPDRs, each of which references zero or more event data records. The characteristics of the universal master schedule data structure are identical to those of the individual resource master schedule data structures.

[0132] The start time and end time of all TPDRs in the universal master schedule data structure account for all of the overall start time and overall end time of all events scheduled on all resources. The list of referenced event data records in each TPDR enumerates all of the events that could possibly occur on all of the resources between the start time and the end time of the time period covered by the TPDR.

[0133] Software instructions which cause a data processor to perform sub-method 400 together with the data processor which the instructions are run may be termed a means for collapsing a plurality of resource master schedules into a universal master schedule. The software itself may be termed software means for collapsing a plurality of resource master schedules into a universal master schedule.

[0134] In a variation of the method of the invention, a universal master schedule is created without performing the preliminary step of creating N resource master schedule data structures. The alternate method would require a more sophisticated means than a list to track references to event data records in TPDRs.

[0135] The method of the invention proceeds to identify all of the unique sets of concurrent events that need to be validated (sub-method 500 in FIG. 4). All of the TPDRs in the universal master schedule data structure are processed to identify sets of concurrent events. The order in which TPDRs is processed does not matter.

[0136] The set of concurrent events that is in progress at a specified time may be represented as a bit vector. The bit vector is made at least large enough to assign one bit to each existing event. The bit corresponding to an event is set to 1 if the event is in progress at the specified time. The bit corresponding to an event is reset to 0 if the event is not in progress at the specified time.

[0137] In preferred embodiments of the invention, each event is assigned a unique integer event ID whose value numbers upwards from either 0 or 1 depending on the implementation technology being used. Event IDs are preferably reclaimed when events are destroyed and reassigned to new events in order to keep the set of assigned event IDs compact. The value of the event ID is used to determine the bit position within the bit vector that is assigned to the event. The bit vector described above need only be large enough to hold the largest assigned event ID.

[0138] In order to generate the minimum number of sets of concurrent events to be validated, a data structure is established to hold an ordered sequence of concurrent event bit vectors. Ordering is, for example, by the binary value of the bit vector. The data structure is initially empty. The data structure should provide O(log N) performance or better for the insertion of bit vectors. If an attempt is made to store a new bit vector into the data structure that is a duplicate of an existing bit vector in the data structure, the new bit vector is not stored in the data structure. Examples of an appropriate data structure include a B-tree or skip list. This data structure may be called a bit vector repository.

[0139] As each TPDR in the universal master schedule data structure is processed, its list of event data record references is examined to identify sets of concurrent events. If a TPDR's list of event data record references only includes references to single-shot events then the only set of concurrent events for that TPDR is the set of events referenced by the event data record references. A concurrent event bit vector is created having bits set to 1 that correspond to the listed events. The bit vector is added to the bit vector repository.

[0140] If a TPDR's list of event data record references includes any references to recurring events then there may be multiple sets of concurrent events for that TPDR. The sets of concurrent events will depend on which recurring events (and lower priority single-shot events) actually occur during the period of time covered by the TPDR.

[0141] In this situation brute force, time-based iteration could be used to identify all of the sets of concurrent events. Bit vectors can be created for the sets of concurrent events and added to the bit-vector repository. It is desirable, however, to identify efficiently all sets of concurrent events, especially for TPDRs which cover long periods of time. Further, it is necessary to handle the last TPDR in the universal master schedule data structure. The last TPDR has an end time of EOT (i.e. unspecified).

[0142] To prevent an infinite loop of time-based iteration a time limit is established to limit the iteration. All recurring events recur on some periodic basis. Different recurring events may have different time periods. The time limit is the lesser of the time period associated with the TPDR or the least common multiple of all the periods of recurring events referenced by the TPDR. The resulting time limit is added to the start time of the TPDR to derive the stop time for the time-based iteration.

[0143] For example, if a TPDR references three recurring events with periods of 1.5, 2, and 3 weeks, the least common multiple of their periods is 6 weeks. If the time period of a TPDR referencing these events is 10 weeks, a 6 week period would be used.

[0144] Time-based iteration proceeds by establishing a reference time. The reference time is initially the start time of the TPDR. An initial set of concurrent events is determined by examining the event data records referenced by the TPDR to determine which events are in progress on the N resources at the start time of the TPDR. A bit vector is created representing the set of concurrent events that are in progress at the start time of the TPDR. The bit vector is added to the bit vector repository.

[0145] A current bit vector reference is established which points to the bit vector representing the set of concurrent events that are in progress at the reference time. The current bit vector reference is initially set to point to the bit vector representing the set of concurrent events that are in progress at the start time of the TPDR. Time-based iteration iteratively proceeds to identify additional sets of concurrent events. At the start of each iteration, the recurring event data records referenced by the TPDR are examined to identify the nearest time following the reference time where any referenced event either starts or stops. An easiest way to do this is to identify the next significant time following the reference time for each event referenced by the TPDR. The resulting dates and times are then sorted to find the closest time following the reference time.

[0146] The event data records, for which the selected time is significant, are examined. There may be multiple event data records, because multiple events may be scheduled to stop or start at the same time. The event data records for events that are scheduled to stop at the selected time shall hereafter be referred to as the current event data records and their events as the current events. The event data records for events that are scheduled to start at the selected time shall hereafter be referred to as the next event data records and their events as the next events.

[0147] Each current event that is scheduled to stop may or may not correspond to the event that has been in progress for the corresponding resource. The current event may be a lower priority event that has been previously preempted by a higher priority event. The current event may be scheduled to stop while the preempting event is in progress. Similarly, each next event that is scheduled to start may or may not actually be starting for the corresponding resource. The next event may be a lower priority event that has been previously preempted by a higher priority event.

[0148] If a current event is the highest priority event for its resource, a transition may be underway to an event that is not a next event, because the event does not have a significant time corresponding to the selected time. A transition may be underway to an event that was previously preempted. Similarly, if a next event is the highest priority event for its resource, a transition may be underway from an event that is not a current event. The next event may be preempting the in progress event.

[0149] The current and next data records and the other event data records associated with the same resources as the current and next data records are examined to identify which in progress events are stopping and which other events are starting to be in progress at the significant time. A bit vector which represents the concurrent events immediately after the selected time is then created. This bit vector may, for example, be created by cloning the bit vector referenced by the current bit vector reference, resetting to 0 any bits in the cloned copy of the bit vector which correspond to in progress events that will stop at the selected time, and setting to 1 bits in the cloned copy of the bit vector which correspond to any events that will start to be in progress at the selected time. The modified cloned copy of the bit vector is inserted into the bit vector repository. The current bit vector reference is set to point to the modified cloned copy of the bit vector. The reference time is advanced to the selected time.

[0150] At this point an iteration of the time-based iteration is complete. Further iterations are performed for the same TPDR until the reference time points to a time that is equal to or greater than the time limit calculated earlier.

[0151] Upon completion of time-based iteration, processing of the TPDR has been completed. Processing of additional TPDRs in the universal master schedule data structure continues until all TPDRs have been processed. Software instructions cause a data processor to perform sub-method 500, taken together with the data processor may be termed a means for extracting a plurality of sets of concurrent events. The software instructions alone may be termed software means for extracting a plurality of sets of concurrent events.

[0152] Once all of the TPDRs in the universal master schedule data structure have been processed, the method of the invention is complete. The bit vector repository holds a minimum unique set of bit vectors representing sets of concurrent events that must be validated. These bit vectors may be passed to a validation system which can check to determine whether the concurrent events exhibit incompatibilities.

[0153] Preferred implementations of the invention include a computer system programmed to execute a method of the invention. The computer systems includes a data processor which may comprise a plurality of processors of any suitable type(s). The invention may also be provided in the form of a program product. The program product may comprise any medium which carries a set of computer-readable signals corresponding to instructions which, when run on a computer, cause the computer to execute a method of the invention. The program product may be distributed in any of a wide variety of forms. The program product may comprise, for example, physical media such as floppy diskettes, CD ROMs, DVDs, hard disk drives, flash RAM or the like or transmission-type media such as digital or analog communication links. The computer-readable signals preferably comprise software means for collapsing a plurality of mini-schedules into a master schedule; software means for collapsing a plurality of master schedules into a universal master schedule and software means for extracting a plurality of sets of concurrent events. Specific embodiments of the invention may comprise a computer connected to receive QoS schedules from a plurality of packet handling devices, the computer programmed to perform the methods of the invention to identify sets of concurrent events in the QoS policies and to pass those sets of concurrent events as a data record, preferably a bit vector repository to a validation system.