Capacity and Stability⚓︎
The platform sustains the Mobile Asset counts, attach rates and throughput each tier is rated for, and stays stable under sustained churn: no restarts, no failed procedure, no leaked session, no memory growth, and complete records.
| ID | Test | Category | Applies to |
|---|---|---|---|
| EXP-CAP-001 | xCore maximum concurrent Mobile Assets | Capacity | 4G, 5G · Local radio, Public radio · Single node, HA cluster, Geo-redundant |
| EXP-CAP-002 | Attach rate | Capacity | 4G, 5G · Local radio · Single node, HA cluster, Geo-redundant |
| EXP-CAP-003 | Throughput at the rated tier | Capacity | 4G, 5G · Local radio · Single node, HA cluster, Geo-redundant |
| EXP-CAP-004 | Stability soak | Capacity | 4G, 5G · Local radio · Single node, HA cluster, Geo-redundant |
EXP-CAP-001 — xCore maximum concurrent Mobile Assets⚓︎
| Attribute | Value |
|---|---|
| Status | Accepted |
| Category | Capacity |
| Components | xCore |
| Applies to | 4G, 5G · Local radio, Public radio · Single node, HA cluster, Geo-redundant |
| Duration | About 4 h |
| Prerequisite procedures | EXP-SES-001 — UE-initiated attach |
| Automated by | Platform suite, 4G split core: 10 000 concurrently held sessions Platform suite, Kubernetes-operator managed core: 10 000-session capacity ramp |
Objective. A non-redundant Expeto Edge (xCore) supports the maximum number of active Mobile Assets it is designed for, with every one of them connected and able to pass traffic.
Service impact
This procedure interrupts service. Run it in a maintenance window or in a pre-production environment.
Preconditions
- Platform
- An xCore is deployed and operational, and its Site shows as online in xControl.
- The xCore has a System.
- Mobile Asset
- As many Mobile Assets as the xCore's designed maximum are provisioned on the System.
- Tooling and access
- With real devices, enough UEs to reach the maximum; otherwise the 3GPP peer simulator configured with the provisioned IMSIs.
- Procedures executed first
Procedure
| # | Where | Action | Expected result |
|---|---|---|---|
| 1 | — | Execute EXP-SES-001 — UE-initiated attach as a prerequisite procedure. | As defined in EXP-SES-001. |
| 2 | Tester | Repeat the previous procedure for further UEs (or start the simulator's attach ramp) until the number of connected Mobile Assets reaches the designed maximum of the xCore. | Every attach succeeds. |
| 3 | xControl | Open Mobile Assets filtered by the System and by status Connected. | The count equals the designed maximum. |
| 4 | UE | Pass traffic from a sample of the connected UEs. | The sampled UEs upload and download data. |
| 5 | Kubernetes | Check the pods of the xCore. | No pod has restarted during the ramp. |
| 6 | Tester | Detach all the UEs (or stop the simulator) and run read mme (or read amf) in the CLI, reading the table footer total. |
The count returns to the pre-test baseline. |
Pass criteria
- Every Mobile Asset up to the designed maximum is connected at the same time.
- Sampled UEs pass traffic at the maximum.
- No pod restarted, and the context count returns to the baseline after release.
Evidence collected: xControl connected Mobile Asset count; UE connectivity check; Kubernetes pod and node status.
EXP-CAP-002 — Attach rate⚓︎
| Attribute | Value |
|---|---|
| Status | Accepted |
| Category | Capacity |
| Components | xCore |
| Applies to | 4G, 5G · Local radio · Single node, HA cluster, Geo-redundant |
| Duration | About 45 min |
| Prerequisite procedures | EXP-SES-001 — UE-initiated attach |
Objective. The xCore sustains the attach rate agreed for the deployment, accepting every attach of a sustained burst with no failure and no restart.
Service impact
This procedure interrupts service. Run it in a maintenance window or in a pre-production environment.
Preconditions
- Platform
- The 3GPP peer simulator is connected to the xCore as a radio and configured with at least 1 000 provisioned IMSIs.
- Container CPU and memory of the core pods can be read.
- Tooling and access
- Access to the CLI.
- Procedures executed first
Procedure
| # | Where | Action | Expected result |
|---|---|---|---|
| 1 | CLI | Run read mme (or read amf) and record the table footer total as the baseline. |
The baseline is recorded. |
| 2 | Tester | Start the simulator attaching at the agreed rate (for example 20 attaches per second) with sessions held, for five minutes. | Attaches are accepted continuously. |
| 3 | Tester | Read the simulator's counters at the end of the ramp. | Every attempt succeeded; the number of attempts is recorded. |
| 4 | Kubernetes | Check the pods and their CPU use during the ramp. | No pod restarted; CPU stayed below the container limits. |
| 5 | Tester | Release all sessions and read the MME or AMF context total again. | The count returns to the baseline. |
Pass criteria
- Every attach at the agreed rate succeeds.
- No pod restarted; the context count returns to the baseline after release.
Evidence collected: CLI output; Kubernetes pod and node status.
EXP-CAP-003 — Throughput at the rated tier⚓︎
| Attribute | Value |
|---|---|
| Status | Accepted |
| Category | Capacity |
| Components | xCore |
| Applies to | 4G, 5G · Local radio · Single node, HA cluster, Geo-redundant |
| Duration | About 1 h |
| Prerequisite procedures | EXP-SES-007 — Multiple UE attach |
Objective. The xCore forwards user traffic at the aggregate throughput its tier is rated for, in both directions, for a sustained period, without loss attributable to the core.
Service impact
This procedure interrupts service. Run it in a maintenance window or in a pre-production environment.
Preconditions
- Platform
- The radio capacity, or the simulator's user-plane injection, is sufficient to offer the tier's rated throughput.
- Tooling and access
- A tool that measures upload and download throughput from the UE against a server on the enterprise network, such as iperf3 or OpenSpeedTest.
- An iperf3 server on the enterprise LAN with enough network capacity.
- Procedures executed first
Procedure
| # | Where | Action | Expected result |
|---|---|---|---|
| 1 | — | Execute EXP-SES-007 — Multiple UE attach as a prerequisite procedure. | As defined in EXP-SES-007. |
| 2 | UE | Start iperf3 clients on every UE toward the LAN server, downlink, for fifteen minutes, with enough parallel streams to reach the rated throughput. | The aggregate throughput reported by the server is recorded. |
| 3 | UE | Repeat uplink for fifteen minutes. | The aggregate throughput is recorded. |
| 4 | Kubernetes | Read the user-plane pods' CPU and memory during the runs. | Resource use stays within limits; no pod restarts. |
| 5 | Capture | Compare the packet counts on the radio side and the enterprise side of the user plane for a one-minute window. | Every packet that entered the core left it; no loss is attributable to the core. |
Pass criteria
- Aggregate throughput reaches the tier's rated figure in each direction for fifteen minutes.
- No packet loss is attributable to the core.
- No pod restarts.
Evidence collected: Speed test result; Kubernetes pod and node status; 3GPP signalling capture (pcap).
EXP-CAP-004 — Stability soak⚓︎
| Attribute | Value |
|---|---|
| Status | Accepted |
| Category | Capacity |
| Components | xCore, xControl |
| Applies to | 4G, 5G · Local radio · Single node, HA cluster, Geo-redundant |
| Duration | About 24 h |
| Prerequisite procedures | EXP-SES-001 — UE-initiated attach EXP-SES-002 — UE-initiated detach EXP-SES-004 — UE idle mode EXP-SES-005 — UE-triggered service request |
| Automated by | Platform suite, 4G split core: mixed-flow soak (100 live sessions, random flow per session) and weekly deep soak |
Objective. Under sustained session churn for at least 24 hours (72 hours as the target), no network function restarts, no procedure fails, no session leaks, memory does not grow after warm-up, and every session is recorded.
Service impact
This procedure interrupts service. Run it in a maintenance window or in a pre-production environment.
Preconditions
- Platform
- The 3GPP peer simulator is connected to the xCore as a radio and configured with at least 200 provisioned IMSIs and a scenario mixing attach, data, idle, reactivation and detach.
- Container restart counts and memory of every core pod can be read over the period (xView container metrics).
- Tooling and access
- Access to the CLI.
- Log in to xControl with an account that holds the ADMIN role.
- Procedures executed first
Procedure
| # | Where | Action | Expected result |
|---|---|---|---|
| 1 | CLI | After a fifteen-minute warm-up of the scenario, record the MME or AMF context total (read mme or read amf), the session total (read pgw or read smf) and the PFCP association state (read associations -f type=pfcp) as the baseline, and record every pod's restart count and memory. |
The baseline is recorded. |
| 2 | Tester | Run the scenario with about 100 live sessions and a ten-second session lifetime for the soak period. | The simulator reports attempts and outcomes continuously. |
| 3 | Tester | At the end, stop the scenario, wait for the simulator to release every session, and read its counters. | Every attach, every procedure and every detach succeeded; the simulator holds no session. |
| 4 | CLI | Read the totals again. | Each equals the baseline exactly. |
| 5 | Kubernetes | Read every pod's restart count and memory. | No restart; the memory of every core container is flat after warm-up, with no upward trend over the second half of the period. |
| 6 | xControl | Generate a Summary Usage Report for the period. | The number of sessions recorded equals the number the simulator completed. |
Pass criteria
- No pod restarted during the soak.
- Every attach, every procedure and every detach succeeded.
- Context and session counts return exactly to the baseline.
- The memory of every core container is flat after warm-up.
- Every completed session has a record.
Evidence collected: CLI output; Kubernetes pod and node status; xControl screenshot.