When should networks share?

1. The question we are testing

At the same time, in the same place, one operator may be short of capacity while another has resources sitting idle. The question is whether a small, temporary purchase can meet that need at a lower cost, without putting either operator's service at risk.

Our working thesis is that dynamic sharing becomes useful when local demand, available resources or the cost of supply changes faster than a standing allocation can follow. Agents could make these purchases practical at scale. They would work within agreed budgets, service requirements and permissions.

The research must separate the benefit of sharing from the extra benefit of deciding at runtime. A standing arrangement may capture most of the value. Dynamic control earns its place only where its additional benefit covers switching, coordination and commercial costs.

2. What this studio represents

The network model follows three representative service groups over 48 hours, in 24 two-hour windows. Each group has a radio access network (RAN) host and a co-located transport route. Traffic is allocated in 10 Mbps blocks. An operator group is the illustrative unit labelled A, B or C. Its demand, RAN site and co-located transport route belong to that operator in the assumed inventory. Sharing lets demand use another group's permitted resources. A group is not a surveyed tower or a measured coverage area.

Power availability and energy cost affect the RAN and transport resources. Access failures remove a host's uplinks. The model does not calculate a separate access-link capacity or RF propagation. The drawing is a schematic, even when inventory records contain coordinates.

This is a small mechanism test. A whole-town claim needs verified sites, sectors, coverage, connections and a larger solver.

3. The decisions and their constraints

For each window, the allocator considers which RAN hosts and transport routes remain active, which can sleep, and how to route each group's traffic. It enumerates the possible active-resource combinations and uses minimum-cost network flow to allocate demand within each combination.

A plan must carry all offered demand, respect resource capacity after reserve, use only permitted connections, and meet the configured minimum numbers of active resources. The cheapest plan depends on its energy, transport and switching costs. Choosing a plan does not create a connection or grant sharing rights.

Σₕ xᵢₕ = dᵢ                           all demand allocated
Σᵢ xᵢₕ = Σᵣ yₕᵣ                       flow conserved at a host
Σᵢ xᵢₕ ≤ floor(Cₕ × (1 − reserve))     active, available RAN
Σₕ yₕᵣ ≤ floor(Cᵣ × (1 − reserve))     active, available route
xᵢₕ = 0 if Aᵢₕ is false
yₕᵣ = 0 if Bₕᵣ is false

4. What we compare

All policies face the same realised demand and events. Their information and planning rules differ.

Hindsight helps select a fixed active-resource set, but that set cannot change during the 48 hours. Scheduled sharing can change which resources are active over time, so it can cost less even without knowing unexpected events in advance.

The best qualified baseline is the cheapest independent, fixed or scheduled policy that passes the service checks. If no baseline passes, there is no valid baseline saving to report.

5. What happens when you inject an event

Overlapping demand multipliers compound. Overlapping power cuts share the same continuous-outage endurance counter. Grid return resets that allowance. Events can remove a permitted path, but cannot create new rights. Event starts and durations use two-hour boundaries.

Unexpected events appear in the realised state, not the schedule's advance information. The planner receives the complete 48-hour baseline and planned events; a second-day maintenance window does not repeat on the first day.

6. Read service before cost

The capacity check asks whether all offered demand fits in a valid plan. A result of 24/24 means all two-hour windows have a full allocation. It is not measured uptime or delivered packet volume.

The switching check asks whether the previous active resources can support the incoming state during overlap. It uses raw capacity before reserve and checks failures of previously active resources. The initial window has no previous configuration to test. The check allows the headroom held back for normal operation to carry traffic during overlap. It does not establish that the same headroom remains available during a switch. This is a proxy for transition continuity, not a handover or restoration-time model.

A full allocation can therefore pass while switching fails. In that case the displayed operating cost is not a qualified saving. An unavailable plan has no assessed transition for that window. An unavailable fixed arrangement does not mean that a real static network would deliver no service.

When allocation fails, the studio shows an all-available-resource flow bound to help identify shortages or path restrictions. It does not execute that partial allocation. Per-group diagnostic amounts are one flow solution; they do not establish fair allocation or independent guarantees for each group.

7. How the costs are calculated

The network model estimates a 48-hour operating subtotal in model USD. These are synthetic cost inputs expressed in US dollars. A comparison is a model cost difference under assumed inputs, not a measured saving. It includes energy, generator idle cost, transport commitments, switching and coordination. These are small-cluster marginal assumptions, not an operator budget.

Operating subtotal = energy and generator idle cost
                   + transport charges
                   + switching and overlap cost
                   + coordination fees

For each powered resource group, consumption includes retained facility power, active or sleep RAN power, traffic-dependent RAN power, and active or sleep transport power. Multiply kW by the two-hour window and the applicable grid or diesel rate. Generator idle cost is added during diesel operation.

Sleeping a transport route does not erase a committed lease. Only the configured avoidable fraction can disappear. Switching adds a charge for each resource whose active state changes, plus the extra power used by outgoing resources during the overlap allowance. Coordination fees accrue per day.

Energy(window) = Σgroups 2h × [kW × USD/kWh + diesel idle USD/h]
Transport(window) = Σroutes 2h × rate × [1 − avoidable + active × avoidable]
Switching = changed resources × change fee + outgoing overlap energy
Coordination = policy daily fee × 48h / 24h

The default dynamic run has the following components, generated from the same engine as the studio.

Do not multiply these dollars by a country's subscriber count. Scaling requires measured resource costs, realistic service topology and an estimate of integration and operating effort.

8. Which inputs come from evidence

Souillac is the first local example because its census population is identifiable. Statistics Mauritius reports 4,941 residents in Souillac Village Council Area in the 2022 census. That boundary supplies context; it does not identify an operator's coverage footprint.

The saved ITU 2026 dataset contains 2024 inputs used to derive 17.18 GB per resident per average month for Mauritius. The calculation combines annual traffic per mobile-broadband subscription with subscriptions per 100 residents. It is a national aggregate, not measured Souillac usage or unique-user behaviour.

Mean Mbps = population × GB/resident/month × 8,000
            ÷ seconds in an average calendar month × local factor

The average calendar month uses 365.25/12 days. A normalised daily profile and provider shares distribute the volume, then repeat for day two. Rounding across the horizon limits aggregate baseline error to half a 10 Mbps two-hour block, or 4.5 GB. Event multipliers are applied afterward.

The default 48-hour baseline contains 5,580 GB after rounding. Three assumed groups each have 300 Mbps of RAN and 600 Mbps of transport before a 20% reserve. The minimum of two active RAN groups is an assumption. Local traffic shape, operator shares, resource positions, permissions, energy prices and costs need operator evidence.

The other study profiles cover Kenya, Sri Lanka, South Africa, the UK, Germany, Saudi Arabia and the UAE. Their regional anchors use an assumed 10,000-person study population and the same illustrative inventory. Changing a national traffic benchmark can overload that inventory. This is not a ranking of real country networks.

9. A worked example and what it tells us

The following run uses the saved default Souillac scenario: power fails at group A at hour 12 for eight hours, with eight hours of assumed backup. The eight-hour backup covers the eight-hour cut. This example tests a higher energy cost rather than exhaustion of backup. It is a reproducible example of the mechanism, not a measured deployment outcome.

Independent operation costs 130.70 model USD, scheduled sharing 114.51 and dynamic sharing 113.79. Scheduled sharing captures about 96% of the saving available against independent operation. The additional benefit of deciding at runtime is 0.72 (0.6%) against the schedule, the cheapest qualifying non-dynamic plan.

Increasing demand by 25% tests a different question. The comparison below reports each run's own checks; the lower-demand run cannot establish a like-for-like saving against the higher-demand run.

At 25% higher demand, dynamic sharing allocates all 24 windows but fails two switching checks. Its lower operating cost does not qualify as a saving. Scheduled sharing is the cheapest plan that passes both screens.

These results belong to the network allocator. The separate purchasing experiment has its own scenarios and accounting. Its results must not be presented as outcomes of this default network run.

Default scenario SHA-256: 0449ea9a3c02e30c603518b7d9c06d23af7d2280e0fcde3274bb52d2903641ed. The Node build reruns the JavaScript engine. The JavaScript engine uses canonical-json-v1 sorted-key JSON for input hashes. The Python reference uses its historical encoding, so equivalent inputs can have different hashes; that difference alone does not mean an input changed.

9a. Who gains when operators buy capacity?

This is a separate purchasing experiment. A asks for 20 Mbps for two hours, twice in each of 24 windows. A block-hour is 10 Mbps for one hour. The two scenarios below use the same workload and serve it in full. In price discovery, B and C alternate as the cheaper supplier. In predictable, B stays cheaper. Scheduled sharing uses B; buying against current offers includes five minutes of own supply while each purchase starts.

When offers change, A saves 42.24 model USD and combined cost falls by 21.04 (14.5%). But B earns 23.00 instead of 67.20 under the schedule. C earns 23.00 instead of zero. A positive combined result gives the partners room to agree terms; it does not mean every partner would accept these prices.

When the cheaper supplier is predictable, A saves the same 42.24, yet combined cost rises by 17.36 (16.3%). The price A pays is revenue for the seller. Combined cost counts the resources used, backup and transaction costs. A lower invoice alone cannot establish a saving for the group.

The build runs the JavaScript purchasing model with its default warm backup and seed 0. In the studio, choose Data & model, then open the purchasing experiment to try the presets. It does not use the Souillac network trace or its energy costs. The current-offer decision is a rule; an agent would need to beat that rule on the same information and service target.

10. Where agents and IODSP fit

The intended commercial workflow is simple. An operator publishes a requirement at a place and time. Another operator responds with a service and price. The buyer accepts only if the service fits, the full bundle is affordable, and it improves on the available alternative.

Agents could find offers, assemble compatible resources, check policies and execute approved transactions. A bounded purchase does not need open-ended negotiation. More complex negotiation should be justified by a measurable improvement over simple offers and rules.

The present allocation controller is deterministic. The purchasing experiment also uses rules. Neither evaluates a live LLM. To test agent value, hold inventory, demand, permissions and objectives constant, then compare a candidate agent with the rules on total cost, service failures, invalid actions, decision time and recovery.

Automation must cover the commercial transaction and fulfilment together. TM Forum Open APIs are proposed as the interfaces between requirements, offers, orders and network delivery. The separate fulfilment demonstration illustrates that workflow in principle; it is not connected to this simulator.

A robust commercial framework makes or breaks adoption. IODSP is the proposed inter-operator commercial settlement framework in this research. It connects agreements and orders to delivery evidence, rating, charges, credits, disputes and netting. An allocation that saves combined resource cost does not by itself ensure that both operators benefit. The price must leave the buyer better off and cover the seller's supply cost and obligations.

Disaster support is a further use of an exercised sharing mechanism. The current studio tests availability and transition conditions; it does not establish independent failure domains, dual-provisioning reliability or a live resilience SLA.

11. How to use the studio

1. Start with a location and inspect its evidence. Keep the assumed inventory visible.
2. Choose a situation, such as a power interruption or planned maintenance. All policies receive the same realised event.
3. Step to the event. Follow the demand, active resources and selected paths. Inspect a resource to see capacity, cost and backup remaining.
4. Read capacity and switching checks before comparing cost. Inspect the first failing window when a check fails.
5. Compare against the best qualified baseline. Pin a run before changing an assumption.
6. Use the bounded stress test to vary demand or energy prices by 25%, or enabled backup by two hours. It changes one axis at a time, with at most seven runs including the reference.
7. Save the completed inputs and export the run. A session restores through fresh calculations, not trusted result blobs. Separate purchasing inputs are not included in the network session.

A useful experiment has a question before it has a result. For example: at what demand does switching stop being feasible during this power interruption? Or: how much avoidable transport cost is needed before sleeping a route pays?

12. What would justify an operator trial

Start with competing operators willing to cooperate in one geography. Choose a recurring local need and resources that can serve the same demand. Agree the permitted actions, information access, price rules and service evidence before automating purchases.

The next data set needs site and sector inventory, offered traffic by time and location, usable interconnections, sharing permissions, power records, avoidable costs and activation constraints. Record units, timestamps, missing values and source status. The current input kit accepts three groups, 24 rows of traffic and two 3×3 Boolean connectivity matrices. A larger inventory needs a new solver and validation.

Then replay real operating periods against independent, planned and dynamic alternatives. Include common failures, unavailable counterparties, stale inventory and the cost of integration. A supervised trial should measure delivery, cost and operational effort before increasing authority or geographic scope.

Test break-even for each participant. Over one month, compare its net cost or margin with its best alternative that meets the same service target. Include unsuccessful requests, support time and any better use of the capacity. If the average gain per attempt after variable costs is positive, divide monthly fixed costs (including the monthly share of setup) by that gain to find the minimum number of attempts. Compare it with the observed volume. If the gain is zero or negative, more trades at those terms will not recover the fixed cost.

Further modelling should examine forecast errors, larger topologies, finer time steps, correlated failures, battery and fuel constraints, commercial incentives and field-service scheduling. These are extensions to test, not benefits already demonstrated.

13. Sources and review record

• Statistics Mauritius, Census 2022, Volume III. Table G1, printed page 5, PDF page 15. Souillac VCA population. The project retains the cached PDF hash and locator.
• ITU IDI 2026 dataset. Underlying 2024 Mauritius inputs, Data!O96 and Data!I96. The project retains these values in its calibration file; the paper does not claim a fresh data release check.
• The browser implementation and worked examples use cloudflare/src/model/simulation.mjs; the Python reference allocation rules come from omniboss/location_lab.py and omniboss/simulation_lab.py. The browser transaction model is cloudflare/src/model/market.mjs; its Python reference is omniboss/agent_market.py.
• V2 to V5 development records and V6 to V8 independent Fable and Astra UX reviews are retained with the studio. Review scores assess implementation and presentation, not commercial viability. Each preserved version retains the reviews available at its release.
• Version gallery lists the earlier interfaces and engines retained locally. Download the input kit for the data shapes and labelled examples.

Sources retain their original reference periods. Technical findings are based on synthetic or assumed local network inputs unless explicitly identified otherwise.

14. From a decision to a settled purchase

The archived V10 walkthrough introduced an HTTP mock beside the browser simulation. It follows one purchase of a RAN and backhaul bundle, from a quote to a payment record. It tests the transaction mechanism; it does not measure a new saving or connect to an operator network.

The browser sends real JSON requests to the local Cloudflare Worker. Each session has its own Durable Object, which stores the accepted terms, reservations, evidence and commercial records. The request inspector shows what the browser sent and what the server returned. Replaying a request with the same idempotency key returns its original result. The simulated clock pauses between actions, while the session expires after 24 real hours.

IODSP consumes the commercial terms and delivery evidence. Service ordering and fulfilment remain separate responsibilities. The payment button represents an external payment confirmation; creating a statement does not pay it.

A small worked purchase

With the default assumptions, 20 Mbps for two hours costs $4 for RAN capacity and $2 for backhaul: $6 for the usable bundle. These are demonstration prices, not operator quotations. The buyer must have enough unspent budget, and the seller enough credit allowance and capacity, before the order is admitted.

The ledger separates budget held, budget spent, seller credit held, unpaid receivables and payment received. Payment clears the receivable; it does not undo the buyer's incurred spending. This distinction matters when agents make repeated purchases.

What this implementation establishes

The mock implements a limited API subset, using the fullCIRCLE catalogue and quote references and pinned TM Forum order, service and agreement schemas. The proposed IODSP routine profile is draft work. This is not a conformance or production-readiness claim.

Each session contains one buyer, one seller, one currency and one bundle. Offers and outcome evidence are synthetic. The location name provides context; it does not supply measured inventory. The standalone V10 walkthrough does not connect the network allocator to procurement. The current studio connects them as described in section 15. Neither view evaluates an LLM, provisions equipment or moves real money.

Server guide · API sources and limits · Supported requests

15. The network simulation calls the APIs

The V15 studio connects the allocation model to the commercial and fulfilment workflow. The browser first proposes paths for the selected policy. It then sends those exact paths, quantities, operator groups and two-hour windows to the mock server. Only verified API outcomes appear as delivered traffic on the map.

For example, if group A's traffic is routed through RAN B and backhaul C, the purchase carries those owners and the model's actual quantity. Both resources must be verified before the path counts as delivered. Each external owner receives its own bilateral statement. If an order is refused or fulfilment fails, that path contributes no verified traffic.

One shared mock run accounts for all three groups' demand, RAN capacity, transport capacity, spending and directional credit. Own-network paths also pass through API admission, but generate no inter-operator purchase or charge. Their fulfilment is assumed after the server checks availability and capacity. The failure and unknown-outcome controls apply to external purchases. Unknown activation retains reservations and blocks further execution until it is resolved. A retry uses the original key; inspecting or replaying the timeline creates no extra purchases.

The network map separates the proposed allocation from API-verified delivery. The cost comparison remains a planning estimate. Inter-operator charges are transfers, not additional combined resource savings, and a refused plan has not delivered its estimated saving. This version reports the shortfall; it does not search for a new supplier after rejection.

Sim executes as quickly as the APIs respond. Demo follows the active window at one simulated hour per second, with a pause control. Unresolved API outcomes can hold the clock. The log on the right scrolls independently and exposes each call beside the animated network.

Use Execution accounts, tariffs and outcome in the network view to test a tight buyer budget, restricted seller credit, failed fulfilment or an unknown outcome. These are synthetic assumptions. The single shared server authority is a demonstration design, not a model of production trust between competitors.

Execution design and limits · Supported network API requests

16. Which hours does the agreement pay for?

A books 100 Mbps in Souillac for four hours. B reserves the radio at $8 per hour. C supplies backhaul at $12 per hour of verified end-to-end service. It starts an hour late. With three hours delivered, what should A owe?

The $8 difference is who bears the first hour of radio cost. The network delivered the same service in both cases. If evidence for C’s final hour is missing when the statement closes, $12 stays on hold. Under the reservation tariff, $56 is due at close; late confirmation posts the other $12 in the next period. A confirmed failure releases the hold instead.

The proposed Inter-Operator Dynamic Settlement Protocol (IODSP) builds on the disaster settlement work in OmniBOSS Phase III. A simple purchase can settle against its order and invoice. A shared settlement record earns its place when several suppliers, different charging rules or late evidence give the parties different answers. Each line needs an agreement, order, supplier, service interval, evidence and amount. The buyer still sets its mandate; each seller controls its credit risk. A statement records an obligation. Payment and network fulfilment stay separate.

Try the standing-agreement replay: change the radio tariff or the late evidence and see what A owes and what it can spend next. This is a standalone synthetic example with its own rates, not another cost to add to section 9 or 9a.

Model review and corrections, 11 November 2026