Patent Application
20200019918
In commerce, customers place orders with a vendor by specifying different items, each with a quantity. For the logistics, the vendor typically dispatches cargo by units of cartons. Shipment can be either by forwarder or by containers. Forwarder freight will be one lot of all the different cartons, while container freight will be containers of cartons. The logistics is operated on the conversion of units of items to cartons to containers; or more generically referred to items are converted to dispatch load units (DLUs) for dispatch and for container freight, there is a further conversion to container load units (CLUs).
In this conversion of units, the business requirements for forwarding freight are rather straightforward. It is simply different items to their dispatch load units, and all will be freighted in one large lot. However, the business requirements for container freight are more complex; particularly items may not be ordered in unit of containers. The recurring problems for processing containers with different carton sizes, packing constraints and quantities are:
The aspiration of businesses is to have a way to algorithmically determine the quantity of container load units based on industry packing/unpacking preferences of different vendor dispatch load units. The ability to determine quantity of container load units will not only be for packing homogenous vendor dispatch load units, but also for packing heterogeneous vendor dispatch load units of different physical and packing properties.
The invention is an algorithm system that will serve both allocating a container load unit by homogeneous (single type of) dispatch load units, and by heterogeneous (different types of) dispatch load units. Since there can be infinite ways to pack a container load unit, the algorithm is based on a balance of a set of practical operational factors, preferences and overhead cost considerations at both ends of the packing and unpacking operation.
The algorithm component for allocating homogeneous dispatch load units to a container load unit will determine the optimal packing arrangement for the maximum quantity of dispatch load units to the container load unit. The algorithm is based on the physical and loading properties of the dispatch load unit and a set of practical operational factors and preferences. The unit conversion of dispatch load unit and container load unit may be manually adjusted to support preferred empirical quantity. This conversion value typically does not change once put into operation and subsequently proven. The conversion value then becomes a look up value.
The algorithm component for packing heterogeneous item associated dispatch load units to container load units will be based on the algorithm component of the homogeneous packing of dispatch load unit to container load unit, and the packing/unpacking preferences at both ends of the operations. This algorithm component is the modeling component executed dynamically based on scenarios on hand.
The algorithm system can be supported by a user interface to facilitate user interaction on scenarios and view outcomes on container load unit quantity and packing details per container load unit. An outline of the operations, features and options provided by the algorithm system is set forth below.
Although the model can be implemented in a spreadsheet or database system, it is most valuable when implemented on an Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) or similar systems that have product records, sales and transactional process features. Typically, these systems only support interactions based on items and item quantity. Quotations or sales orders or specifications potentially involve multiple item provision sources ranging from own warehouses to different suppliers and their warehouses all can be from different geographical locations, and even be freighted by different freight modes of sea/waterway, road, rail and air. Customers may want to investigate different items, dispatch load units, quantities and container sizes to examine optimal cargo transfer configuration in a quotation for an acceptable logistics cost. This is not exactly easy for the sales team consistently provide good estimations based on dispatch load units and container load units per dispatch location, and their alignment with back office logistics operations. Interaction between customers and sales team, sales team and logistics, and sales team and procurement will need to separately perform unit conversion over and over again and be aligned, which cannot be simple and takes time and is error prone. This algorithm system, in the form of a tool, may potentially help the industry to reduce a lot of waste in the form of costs and time and to improve communication and operational effectiveness.
This algorithm system can be most valuable to merchants of commerce, industry and third party logistics industry who have a high volume of transactions, which are time critical and need operational consistency and accuracy. Furthermore, the use of the model can help companies of these industries to be more immune to skilled staff turnover, reduce training costs, reduce errors and have more continuous process flow. Since the model is not particularly complex and can be a modeling feature put into systems and webpages, it is within the means of the tens of thousands of small and medium size enterprises that exist in the supply chain.
There can be many approaches to the marketing to increase exposure and capture enhancement feedbacks. It could be:
With reference to the drawings, a system of determining container load units from dispatch load units derived from a list of items is illustrated for various embodiments which embrace a wide range of applications depending on the nature of the items, the configurations of possible dispatch load units, such as cartons, pallet-load and the configurations of possible container load units such as intermodal containers, trucks, unit load device, etc. . . . In
1. Container Load Unit
2. Dispatch Load Unit
3. Dispatch Load Unit and Container Load Unit Relationship
4. Item or Product
5. Item and Dispatch Load Unit Relationship
1. The Constraints
2. Packing Preferences
3. Algorithm Strategy
4. Homogeneous Allocation Algorithm Model
5. Heterogeneous Allocation Algorithm Model
Any container load unit (CLU or Container) that may containerized cargo, such as intermodal freight containers, trucks or any unit load device is expected to have the following properties:
Any unit cargo that is dispatched by one party as a dispatch unit, fulfilment unit or shipment unit, and received by another party is a dispatch load unit (DLU). It is considered as having a cubical shape occupying space, typically in a carton form, is expected to have the following properties:
The result of a system algorithm must serve all parties:
1. Rationale:
2. More detailed preference:
1. Rationale:
2. More detailed preference:
1. Rationale:
2. More detailed preference:
1. Rationale:
1. Rationale:
1. Rationale:
The relationship among item, dispatch load unit and container load unit is a unit conversion system of item to dispatch load unit to container load unit.
How many dispatch load units can fit into a container load unit is constrained by geometry. With loading properties, adjustment for loose packing and compliance to packing preferences, the resultant Allocable Quantity (Q) is the maximum quantity of dispatch load units that can be packed into a container load unit. The calculation is by an algorithm on allocating homogeneous dispatch load units into a container load unit. This allocable quantity can be thought of as maximum quantity of empty boxes based on geometry.
When a dispatch load unit is associated with an item (IDLU), as its content, and with the number of items that maybe packed into it, it has an additional weight property as gross weight. Similarly, container load unit has a maximum load limit, which may or may not be respected. If respected, the Allocable Quantity (Q) maybe reduced so the gross weight of all allocable dispatch load units may not exceed the container maximum load. This allocable quantity can be thought of as maximum quantity of cargo boxes. This allocable quantity is also associated with an Allocable Volume (V) to represent the volume required to pack the item-associated dispatch load unit into the container load unit.
For a given list of item-associated dispatch load units (IDLU) and a supported list of container load unit (CLU), to determine the number of container load units required in the scenario, the algorithm strategy is a Setup and Operate model as set forth in
The aim of the homogeneous allocation algorithm model is to determine how many dispatch load units, all being identical (homogeneous), can be allocated into a given container load unit. The allocation will be based on the properties of the dispatch load unit (DLU) and container load unit (CLU) and comply with the packing preferences as indicated at
The homogeneous allocation algorithm model is depicted in
The homogeneous allocation algorithm model is a four steps model as explained below, ref.
The allocation of a dispatch load unit to a container load unit is based on a list of properties and packing preferences, ref.
The algorithm for the allocation by geometry is based on two sets of properties; one from the dispatch load unit, another from the container load unit. For convenience of reading, we will refer to dispatch load unit as DLU or Carton (ctn), and container load unit as CLU or Container (ctr).
For the allocation by geometry, a way to determine the maximum quantity of homogeneous dispatch load units that can be packed into a container load unit is by a Recursive Allocation Method. This method is desirable, as packing cubical objects into a cubical space often cannot achieve 100% utilization. After packing objects into a cubical space in a certain orientation, residual cubical spaces result and may be further packed by objects in different orientations or of different sizes. Based on common warehouse packing preferences, the packing is a recursive process first packing objects in upright orientations and then where allowed may further pack residual spaces by objects in non-upright orientations. Here, a cubical object represents a dispatch load unit or a carton, and a cubical space represents the interior space of a container load unit.
The recursive allocation method starts with a given cubical spatial unit, after it is fully allocated with homogeneous cubical objects in upright orientation, two residual spaces result that may further allocate the same homogeneous cubical objects in non-upright orientations. These residual spaces are the overhead and adjacent spaces around the body of upright objects. Each of these residual spaces, in the form of a cubical spatial unit, may apply the allocation method again; each will result in smaller overhead and adjacent residual cubical spacial units for further allocation,
For a spatial unit, the allocation method applies allocation by a two block system, in the form of a main object block and the other object block, both a cubical block, to fill the space, ref
For the commencing spatial unit is allocated, the residual overhead and adjacent spatial dimensions can be determined for follow-on allocation, ref
The commencing spatial unit is to be allocated by upright objects.
The adjacent spatial unit and overhead spatial unit are to be allocated by non-upright objects.
The quantity of upright objects allocated in the spatial unit, and the quantity of non-upright objects allocated in the overhead spatial unit and adjacent spatial unit are summed to give the total Allocable Quantity (Q) of the object to the spatial unit.
For the application of the recursive allocation method, the properties of a spatial unit are listed at Table III.
The commencing spatial unit, ref. Table IV, is simply the usable dimension of the container load unit. This is the interior container dimension less any reserved for lost space from loose packing, ref. Table I.
The spatial unit dimensions of subsequent residual overhead and adjacent spatial units around the upright object blocks can only be determined after the upright object blocks are calculated.
For the allocating object and its placement orientation, it is represented by dimensions so when a carton is intended to have a specific placement orientation, the length, width and height of the carton is assigned accordingly to the length, width and height of the main block object and that of the other block object.
The allocating objects for the main block and the other block can be modeled by a number of properties, ref. Table V, for allocating in spatial unit; also on properties for stacking objects on top of the object blocks below.
Objects for the main block and other block are separately identified in the Two Blocks System so they maybe separately modeled and applied in the algorithm on the allocation calculation.
For allocating upright dispatch load unit into the commencing spatial unit, two allocation arrangements (FS and SF) are possible. One with main block objects facing front (F), another with main block objects facing side (S). The two blocks system correspondingly will have the objects at the other block turned to face the other direction; see Table VI. Each allocation arrangement will produce its recursive allocation result. The carton loading property (Dfacing) at Table II, will determine the Allocable Quantity (Q) is from which upright arrangement, ref
Upright objects in the commencing spatial unit, with the two allocation arrangements are modelled in Table VII. The objects at the main block and the other block are identical except for their facing direction. The algorithm will manipulate Lu2 and Wu2 accordingly to represent the object rotation about the y-axis in the Cartesian coordinate system for the change in facing direction. The carton length, width and height are mapped to the object length, width and height according to their placement orientation arrangement. The maximum stacking of the current spatial unit (Scurrent) is that of the upright carton. Since there is no cartons stacked below (Sbelow), the maximum total stacking (Stotal) remains to be that of upright carton.
Non-upright objects to be allocated to the residual overhead and adjacent cubical spatial units have a number of orientation combinations are modeled in Table VIII. Since the non-upright orientations are carton lying on its front/back face and lying on its side face, there are total of four combinations, each has two facing arrangements (FS and SF).
Based on the carton dimensions, the non-upright objects allocation combination model can be referenced at Table IX. Carton dimensions are assigned to the appropriate object dimension to represent the required carton placement orientation.
The loading property of the carton may limit whether a carton can be placed lying on its front/back face (Sback) and lying on its side face (Sside), as can be referenced in Table II.
For non-upright cartons to allocate to the residual adjacent space, the object property is modelled in Table X. The maximum stacking at the current spatial unit (Scurrent) is that of the carton stacking property of its lying orientation. Since the cartons are to be allocated at the adjacent spatial unit, they are placed on the base of the spatial unit; so maximum total stacking (Stotal) is the same as the maximum stacking at the current spatial unit. There are no cartons stacked below (Sbelow).
For non-upright cartons to allocate to the residual overhead space, the object property is modelled in Table XI. The maximum stacking at the current spatial unit (Scurrent) is that of the carton stacking property of its lying orientation. Since the cartons are to be allocated on top of the upright cartons, so maximum total stacking (Stotal) is that of the upright cartons, which cannot be exceeded. The cartons stacked below (Sbelow) is the calcuated stacked count (Sm) of the upright carton block, arbitrarily referencing that of the main block.
The calculation logic of the Allocation by Geometry is structured as follow:
For determining allocable quantity of an object into a spatial unit, with the given properties of the object for the main block and the other block, the allocation quantity calculation logic is as follows, ref.
With a given set of spatial unit properties, ref. Table IV, Table XV, Table XVIII, Table XX, Table XXI and allocating objects properties organized in an allocation arrangement, ref. Table VII, Table X, Table XI, the main block allocable quantity (QM) can be calculated as shown in Table XII. For the quotient in the calculations, only the integer value is preserved; the fraction is ignored.
Since QM is calculated from the product of rows (R), columns (C) and stacks (S), if any has a value of zero (0), then QM is zero (0) and the block does not exist. Note for stacks, the object stacking property may be constrained so the calculated stack value can be constrained, can even be constrained to zero (0).
With the main block allocable quantity determined and non-zero, the other block (QN) may exist at two locations, one at the side (QS), another at the front (QF) of the main block, ref
The other block adjacent to the side (S) of the main block can be determined only if the main block exists (QM not equal zero). The spatial dimension at the side can be determined as shown in Table XIII. The allocable quantity (QS) for the other block at the side can be calculated as shown in Table XIV. Again, for the quotient in the calculations, only the integer value is preserved; the fraction is ignored. The corresponding residual front adjacent spatial unit (SSF) can be determined at Table XV for subsequent recursive allocation.
The other block adjacent to the front (F) of the main block can be determined only if the main block exists. The spatial dimension at the front can be determined as shown in Table XVI. The allocable quantity (QF) for the other block at the front can be calculated as shown in Table XVII. Again, for the quotient of the calculations, only the integer value is preserved; the fraction is ignored. The corresponding residual side adjacent spatial unit (SFS) can be determined at Table XVIII for subsequent allocation is shown.
Overhead spatial unit can be determined only if the main block exists. For the main block without the other block, the overhead spatial unit (SO) is shown in Table XIX. For the other block exists at the side of the main block, the overhead spatial unit (SSO) is shown in Table XX. For the other block exists at the front of the main block, the overhead spatial unit (SR)) is shown in Table XXI.
Table XXII summarises the calculation of the Recursive Allocation Method and the Two Blocks System from the commencing spatial unit through all the subsequent residual cubical spatial units to the determination of the final allocable quantity (QG). Each table column shows the cubical spatial unit to calculate in the recursive calculation process. The table rows show the calculation inputs and outputs. The input being the properties of the spatial unit and allocation arrangements possible for the spatial unit. The calculation outputs are for each allocation arrangement; are the allocation quantity for the main block (QM), the two allocation quantity possible of the other blocks (QN), the two possible corresponding adjacent cubical spatial units and the two possible corresponding overhead cubical spatial units. Each calculation references the Table described in earlier sections that has the calculation details. The table also shows three column groups of spatial units. First is the commencing spatial unit (single column) that initiates the calculation process representing a container load unit and for upright objects. Second group (two columns) is based on the result of the first column is of the recursive residual spatial units when the other block (QN) is at the side of the main block. The residual spatial units are the adjacent spatial unit at the front (SSF) and at the overhead (SSO) Third group (two columns) is based on the result of the first column is of the recursive residual spatial units when the other block (QN) is at the front of the main block. The residual spatial units are the adjacent spatial unit at the side (SFS) and at the overhead (SFO). Second and third column groups are for non-upright allocating objects. Do note each spatial unit column has its allocation arrangements listed in each of their table, which means each arrangement will have its one set of output, and lead to its follow on recursive calculation in the second and third column groups. Per spatial unit column, only the largest total quantity of all the allocation arrangements is returned.
Only the commencing spatial unit will determine the residual spatial units (SSF, SFS, SSO, or SFO). Based on the Packing Preference in practice at warehouses, after determining the Allocable Quantity of upright blocks at the commercing spatial unit, all residual spatial units for non-upright blocks (second and third column groups) will ignore their residual spatial units.
For each of the spatial unit column in Table XXII, when the main block (QM) calculation result in zero quantity, the spatial unit as a whole will return zero quantity. This means the other block (QN) will have zero quantity and no residual spatial units (SSF, SFS, SSO, or SFO).
For the commencing spatial unit with an allocation arrangement that lead to a main block (QM) with the other block (QN) at the side of the main block, the follow on adjacent spatial unit at the front (SSF) and overhead spatial unit (SSO) results, which will apply the second column group Adjacent Spatial Unit (SSF) and Overhead Special Unit (SSo) for the non-upright cartons calculation. Each allocation arrangement of Table X will have a total quantity (QSF) which the largest of all allocation arrangements will be returned. Similarly, each allocation arrangement of Table XI will have a total quantity (QSO) which the largest of all allocation arrangements will be returned. The largest returned value of QSF and QSO will sum with QB to return the QG of the commencing spatial unit and the allocation arrangement.
For the commencing spatial unit with an allocation arrangement that lead to a main block (QM) with the other block (QN) at the front of the main block, the follow on adjacent spatial unit at the side (SFS) and overhead spatial unit (SFO) results, which will apply the third column group Adjacent Spatial Unit (SFS) and Overhead Special Unit (SFO) for the non-upright cartons calculation. Each allocation arrangement of Table X will have a total quantity (QFS) which the largest of all allocation arrangements will be returned. Similarly, each allocation arrangement of Table XI will have a total quantity (QFO) which the largest of all allocation arrangements will be returned. The largest returned value of QFS and QFO will sum with QB to return the QG of the commencing spatial unit and the allocation arrangement.
For the commencing spatial unit with an allocation arrangement that lead to a main block (QM) and without the other block (QN), the follow on adjacent spatial unit at the side (SSF), adjacent spatial unit at the front (SFS) and overhead spatial unit (SFO) results, which will apply the column Adjacent Spatial Unit (SSF), Adjacent Spatial Unit (SFS) and Overhead Spatial Unit (SFO) for the non-upright cartons calculation. Each allocation arrangement of Table X will have a total quantity (QSF) which the largest of all allocation arrangements will be returned. Each allocation arrangement of Table X will have a total quantity (QFS) which the largest of all allocation arrangements will be returned. Similarly, each allocation arrangement of Table XI will have a total quantity (QFO) which the largest of all allocation arrangements will be returned. The largest returned value between QSF and QFS and the largest return value of QFO will sum with QB to return the QG of the commencing spatial unit and the allocation arrangement. DO note that QG may be determined based on Overhead Spatial Unit (SFO) or (SSO) as both are identical since the other block (QN) does not exist. Here, Overhead Spatial Unit (SFO) is arbitrarily picked for illustration.
For the commencing spatial unit, two allocation arrangements exist, ref. Table VII, which will result in two allocable quantity QG values. Which allocable value is returned for the commencing spatial unit is governed by Dfacing value of the allocating object, ref. Table II.
Empirical Adjustment of Allocable Quantity from Allocation by Geometry
User may want to override the Allocable Quantity (QG) with a preferred empirical value to result in a new Allocable Quantity (QGE), as referenced in
When subsequently the dispatch load unit is to be adopted by a product item, the item adopts the adjusted unit conversion ratio (QGE) of the dispatch load unit to the container load unit.
Item may adopt one or more dispatch load units as its fulfillment and freighting units. With each dispatch load unit adoption, it is adopting a unit conversion (QW=QGE). As part of the adoption, the number of items to the dispatch load unit, and weight to have the dispatch load unit defined with a gross weight, all need to be specified, ref.
For an item associated dispatch load unit, with its inherited Allocable Quantity (QW=QGE) and with a unit gross weight, the resultant allocated gross weight may exceed the container load unit maximum load limit. If user prefers not to respect this maximum load limit, then the inherited dispatch load unit Allocable Quantity requires no change; otherwise, it is lowered to the maximum quantity not exceeding the container's maximum load limit, as referenced in Table XXIII. Accordingly, Unit Allocable Volume (VW) is recalculated.
Empirical Adjustment of Allocable Quantity from Allocation by Weight
User may want to override the Allocable Quantity (QW) with a preferred empirical value to result in a new Allocable Quantity (QWE), as referenced in
The Allocable Quantity (QWE) for the item is the unit conversion between the item associated dispatch load unit and the container load unit. The Unit Allocable Volume (VWE) for the item dispatch load unit is for use in the heterogeneous allocation algorithm.
For a dispatch load unit to a container load unit, the details on rows, columns and stacks for each dispatch load unit block in each spatial unit can be presented for review and as a packing instruction for packing a container.
As the Allocable Quantity is reduced with an empirical value, the reduction may start from either the overhead (SSO, or SFO) or the adjacent (SSF, SFS) spatial unit as preferred. In either case, reduction starts at the other block (QN) before proceeding to the main block (QM). Only if all the quantity from the overhead and adjacent spatial unit are all reduced to zero can the upright blocks be reduced. At the upright block, again, reduction starts at the other block before proceed to the main block.
The aim of the heterogeneous allocation algorithm is to determine the minimum container load units (CLU) required for a given scenario, typically in the form of a transaction with a list of items, each with a specified dispatch load unit (DLU) and quantity. As the algorithm is dynamically applied, the algorithm will recalculate as the scenario is updated.
The algorithm is depicted in
The algorithm preference is to use the Allocable Quantity (Q) to determine as much of the CLU quantity as possible. Only when the conditions to apply Allocable Quantity is exhausted will Allocable Volume (V), ref.
The preference to use Allocable Quantity is the allocation quantity between a dispatch load unit and a container load unit is known, and often it is empirically tested and refined over time. Thus the calculation based on Allocable Quantity at sales will have become highly trustworthy by backoffice logistics, with calculated quantity is executable by backoffice.
Allocable Quantity is only used when all the dispatch load units being considered for allocating to a container load unit have identical allocation properties, which is the condition that the homogeneous allocation algorithm is applicable. The allocation properties are the dimensional and loading properties as can be referenced in Table II.
If the dispatch load units being considered for allocating to a container load unit do not have uniform allocation properties, allocation calcuation is by unit dispatch load unit Allocable Volume (V). Unlike Allocation by Allocable Quanity, allocation by Allocable Volume is an estimation. For the best possible estimation, Allocable Volume is only applied at the final stage of the heterogeneous allocation algorithm, ref.
The heterogeneous allocation algorithm is a three steps model as referenced in
The heterogeneous allocating algorithm, ref
Per
Per
Line 1 Item A has 3,350 DLU1; with an Allocable Quantity Q of 800 results in 4 full CLU Qty and 150 remaining DLU Qty, which can be referred to as an DLU-lot. The same is applied to each line item to result in a Full CLU Qty sub-total of 16, and each line item DLU-Lot is unable to fill a CLU on its own.
Per
Per
Per
Item A, Item B and Item D of Item Queue 1 all have identical allocation properties despite having different dispatch load unit DLU1 and DLU3. Item C and Item E have identical allocation properties since they have identical DLU2. Item Queue 1 has an Allocable Quantity Q of 800 while Item Queue 2 has an Allocable Quantity Q of 500, both their Q value can be referenced from anyone of their line item Item Allocation Lookup Table.
Each Item Queue is to be sorted, ref.
For Item Queue 1, line items Item A are grouped together with a super-DLU-Lot of 450, which is less than that of Item D of 750 and more than that of Item B of 430. Similarly for Item Queue 2, line items Item C with a total of 325 is more than that of Item E of 15.
Per
Per
All Item C are sorted, per
Per
If CLU maximum load limit is to be respected and if all the allocated item release units have a gross weight exceeding the maximum load limit of the CLU, then item dispatch load units are unallocated from the CLU in reversed allocation order until the CLU is not overloaded.
Allocation of item dispatch load units continues until all are allocated. The last CLU may result in not being fully utilized.
With reference to Table XXXII, it is assumed all the item dispatch load units can be allocated into one CLU.
Per
Allocation Properties, as indicated in Table XXX.
With the same logic but a more complex scenario, the list of items for containerization may be as set forth in the example of Table XXXIII.
Here, items are from three locations. Some items are from location A, some are from location B and some are from location C. Since each location must have their containers arranged for all the DLUs of that location, and may be specified with different CLU, DLUs are grouped and separated by locations. Heterogeneous allocation algorithm is applied to the line items of each location to determine the CLU quantity for each location. The total CLU quantity for the scenario is the sum of CLU quantity of each location.
After a scenario has applied the Heterogeneous Allocation Algorithm and all the CLU allocations are determined, each container load unit can have their list of allocated item dispatch load units with quantity presented. However, for the details on each allocation block and the rows, columns and stacks in the block will depend on whether the container load unit is allocated by Allocable Quantity or by Allocable Volume.
All container load units that are allocated by Allocable Quantity in the heterogeneous allocation algorithm can have the dispatch load unit allocation arrangement details presented in blocks with rows, columns and stacks. This information can be referenced from anyone of the item dispatch load unit record allocated in the container load unit. This is applicable to any CLU determined from
Any container load units that are allocated by Allocable Volume in the heterogeneous allocation algorithm cannot have their dispatch load unit allocation arrangement details presented in blocks with rows, columns and stacks. How such a container load unit is packed is not being predetermined. This is applicable to any CLU determined from
Sorting DLU-Lot in
The algorithm may support packing preference to not have any DLU-Lot to be split over different CLUs in
The algorithm at
While embodiments of the foregoing system have been set forth for purposes of illustration, the foregoing description should not be deemed a limitation of the invention herein. Accordingly, various modifications, adaptations and alternatives may occur to one skilled in the art without departing from the spirit and the scope of the present invention.
