5G Base Station Energy Consumption Prediction

The Problem

5G energy modeling is not a typical regression problem. The target — energy consumption of a base station — depends on hardware configuration, traffic load, frequency band, and energy-saving mode states that interact in complex, physics-driven ways. A station with two cells operating at different frequencies doesn't simply use twice the energy of a single-cell station. The relationship between load, frequency, antenna count, and energy consumption follows hardware-specific rules that standard ML models struggle to discover from data alone.

The competition provided base station-level energy measurements, but the modeling needed to happen at the cell level — individual radio units within a station. The problem was that no per-cell energy measurement existed in the data. The total energy reading is all you get, and you need to predict at a granularity finer than your labels. This is a target construction problem that precedes any modeling.

Beyond the target issue, the categorical variables in this domain have meaningful structure. Day of week isn't nominal — Monday is adjacent to Tuesday. Hardware generations are ordered. Antenna types have a hierarchy. Using default one-hot encoding for everything throws away information that domain experts would consider obvious. The challenge became: how do you encode domain knowledge into features that gradient boosting can exploit?

My Approach

The first and most consequential decision was solving the target construction problem. For multi-cell stations operating two cells at different frequencies, I attributed total energy to each cell using frequency-specific proportions derived from hardware characteristics. These proportions aren't arbitrary splits — they come from the physical relationship between frequency band and power consumption. Without this step, the label itself is undefined at the modeling granularity. Every team that skipped this step was predicting an ill-defined target.

Next, I built domain-derived indicator features that encode known hardware behavior as explicit binary flags. Rather than hoping the model discovers that energy-saving mode ES1 activates under very low load with large antenna arrays, I created features that directly encode these rules. These interaction terms — load level × energy-saving state × antenna count × frequency — give the model a structured representation of physics-driven hardware behavior that would take thousands of trees to approximate from raw features.

For encoding, I matched each categorical variable to the contrast structure that respects its semantics: Helmert contrasts for day of week (each day compared to all prior days), polynomial contrasts for hardware generation (ordered, with potential nonlinear effects), backward difference for antenna type, Weight of Evidence for binary indicators, and M-estimator smoothing for high-cardinality time features. This per-variable encoding strategy ensures that the numeric representation preserves the structure that exists in the domain.

The modeling itself operated at two levels — base station and cell — with independent model training at each granularity. A three-way split (train/freeze/test) kept ensemble weight optimization honest. The final pipeline spans 18 scripts in R, orchestrated by a single entry point, with models from LightGBM, XGBoost, CatBoost, Random Forest, GLMNet, H2O AutoML, SuperLearner, and tidymodels stacking all contributing to the final ensemble.

Key Decisions

Key Takeaway

The deepest lesson from this project is that label construction and feature encoding are modeling decisions, not preprocessing steps. Getting the target right — disaggregating station energy to cell level using domain-appropriate proportions — was worth more than any hyperparameter tuning. And matching each variable's encoding to its semantic structure transforms domain knowledge from something external to the model into something the model can directly exploit.