## 2 Materials and Methods
### Implementation of the Work Pattern  
In Figure 11 is detailed the pattern that implements the proposed framework using AWS Services. It receives information from the OSS and returns a set of frequency allocations to each cell we are trying to plan. We can also see in the same figure that between each Lambda, all processed data are saved in S3 buckets whose IDs depend on the client information. This data include but are not limited to: propagation grids, intersection files, world maps, interference matrixes, cell configurations, and other client data. Each lambda receives a JSON file as input. In this case, the file must have the names of the cells we want to plan, the frequency to which they must be planned as designed by the International  
Figure 11: AWS cloud services integration on work pattern. Telecommunication Union (ITU) in GSM operations, and client information for file access, which is automatically input based on the login session. There are some restrictions about each individual lambda one needs to take into account:  
* Maximum memory allocated is 3008 MB;
* Timeout of 900 s (15 min);
* Virtual storage is limited to 500 MB. This is important because the world map can take a considerable amount of space; therefore, the implementation of streaming when reading a world map is a must. The same happens when uploading a file to a bucket, since the file must first be created in Lambda's temporary storage and only then uploaded. Problems might appear when planning a large problem, where the optimization can take a long time. Another possible problem was the fact that S3 buckets have a limit of 5 TB per object, but that does not compare to the 500 MB of Lambda virtual storage, meaning that it can be ignored. There is also a limit of 100 buckets (1000 with premium) per account, which again is not a problem, since we would need five at max. In Figure 11 we have the following AWS lambdas:  
* **Cell coverage estimation and grid generation**_AWS Lambda_ (**L1**): Using client information imported from a S3 bucket (B0), this lambda creates a pixelized grid with coverage information around an antenna. This coverage is calculated using propagation modules, drive tests, and other cell parameters, such as elevation, azimuth, and tilt [32]. Those grids will be saved in an S3 bucket (B1);
* **Intersections**_AWS Lambda_ (**L2**): Using a metadata file imported from B1, L2 compiles that data verifying which cells' coverage intersects, by getting two opposite max distance corners. Finally, it outputs that data in a CSV file to B2. * **World Map**_AWS Lambda_ (**L3**): This lambda is responsible for creating a TSV file with Geohash keys and pairs of cell/power, which we call a \"World Map.\" Both those grids and the map must have the same Geohash precision (BitSet size) in order to avoid scale/localization incoherence. First, we use the intersection files from B2 to iterate trough the set of cells that we are trying to plan and find the corresponding intersection files. A new set of cells is created that includes all the cells that intersect the ones we are trying to plan. We use the propagation grids of those cells (imported from B1) to compile and create a world map containing all those cells. At first, we tried to use a Json file, but its size ended up being too large to read in a reasonable amount of time. * **Planning**_AWS Lambda_ (**L4**): First, we count both the amount of interference in the world map, and the amount of possible interference in the case in which the unplanned cells end up with the same frequency. Reminder that interference is defined by Equation (1). All data are written and sent to the GLPSOI module from GLPK library [33], a linear solver, in a \"mathProg\" file. In that file is also written the solver's objective (Equation (2)) and all rules (Equations (3)-(7)). The outputted solution should have multiple \(x[c,f]\) where \(x\) equals either 1 or 0. In case of the former, it means that frequency \(f\) should be attributed to cell \(c\).