# TelAF Simulation
Source: [https://docs.qualcomm.com/doc/80-41102-1/topic/use-telaf-simulation.html](https://docs.qualcomm.com/doc/80-41102-1/topic/use-telaf-simulation.html)
TelAF Simulation provides a hardware-independent environment that makes TelAF application
development and validation faster, more convenient, and easier to automate. Customers
can develop and validate TelAF applications using production-aligned APIs and service
behavior, while the underlying hardware-dependent functionality is simulated in
software.
The following figure shows an overview of the TelAF Simulation architecture.
Figure : TelAF Simulation architecture
Customer applications and TelAF services use the same APIs and implementation as they do
on the real target platform. No application or service-level changes are required. The
simulation environment is beneath the TelAF service layer, where the PA layer and its
hardware-dependent sublayers are simulated.
The simulated PA components communicate with the simulated modem-side and AP-side
components through MQTT. Developers can reproduce device behavior, inject events,
validate responses, and exercise functional scenarios without requiring physical
Telematics hardware.
Based on the MQTT bus, the customer can leverage the existing MQTT CLI tools to monitor
the interaction messages exchanged between publishers and consumers, and to observe
messages that remain held by the broker. These CLI tools allow visibility into the
message flow and into any messages that are currently retained or queued by the broker.
This visibility allows for low-level system debugging and investigation of delivery and
message state issues.
## Simulation layers
TelAF Simulation is organized into the layers listed in the following table.
Table : TelAF simulation layers
| Layer | Description |
| --- | --- |
| TelAF application layer | Customer applications use the standard TelAF APIs. No
simulation-specific application code is required.
Applications communicate with TelAF services through generated
TelAF IPC interfaces. Application isolation, access control, and
service binding continue to be managed by the TelAF application
framework. |
| TelAF service layer | TelAF services provide the functional APIs used by applications,
including data connectivity, SIM, radio, network, power, eCall,
location, and other platform services.
The service implementations and their public APIs remain
unchanged when running in simulation. |
| Simulated PA layer | The simulated PA layer implements the same PA interfaces expected
by TelAF services. It simulates the hardware-backed PA
implementation while preserving the service-to-PA contract.
Because the service and simulated PA execute within the same
process context, the service interacts with its PA through the
normal internal PA interface. The service doesn't need to know
whether the PA is connected to physical hardware or a simulation
backend. |
| Simulation daemon layer | The simulation daemon layer models the lower-level platform
behavior.
- The MPSS daemon provides simulated modem-side behavior such
as data connectivity, SIM, radio, network, and eCall
functions.
- The APSS daemon provides simulated AP-side low-level
behavior, including power management, wakeup handling, and
related AP functionality.
These daemons run as independent processes and can be configured
to reproduce different operating conditions and test
scenarios. |
## Communication mechanism
TelAF applications communicate with TelAF services through TelAF IPC.
The southbound communication between simulated PA components and the simulation
daemons uses MQTT through a shared message bus. The MQTT bus provides consistent
communication between the service process contexts and the independent MPSS and APSS
daemons.
The communication model supports:
- Synchronous request and response operations
- Asynchronous indications and events
- Fire-and-forget commands
- Correlation of requests and responses
- Payload and message-schema validation
- Reconnection and message resubscription
- Communication over a Unix-domain socket by default or TCP, depending on the
deployment configuration
The topic prefixes identify the communication direction:
Table : Communication direction related topic prefixes
| Topic prefix | Description |
| --- | --- |
| `mp/req` | Request sent to the MPSS daemon |
| `mp/rsp` | Response returned by the MPSS daemon |
| `mp/ind` | Indication generated by the MPSS daemon |
| `mp/ff` | Fire-and-forget command sent to the MPSS daemon |
| `ap/req` | Request sent to the APSS daemon |
| `ap/rsp` | Response returned by the APSS daemon |
| `ap/ind` | Indication generated by the APSS daemon |
| `ap/ff` | Fire-and-forget command sent to the APSS daemon |
For example, a data-call request follows this path:
TelAF Application
│
│ TelAF IPC
▼
TelAF Data Call Service
│
│ PA interface
▼
Simulated Data PA
│
│ MQTT request
▼
MPSS Data Simulation
│
│ MQTT response or indication
▼
Simulated Data PA
│
▼
TelAF Data Call ServiceCopy to clipboard
## Configuration and tools
TelAF Simulation provides configuration and control mechanisms for developers to
tailor simulated behavior without modifying TelAF application or service code.
Configurations can define:
- Enabled simulation services
- Initial modem, SIM, radio, power, and network states
- Data profiles and connectivity parameters
- Simulation scenarios and event timelines
- APSS and MPSS broker settings
- Persistent runtime data
- Message and action schemas
Control simulation behavior through:
- Build-time feature configuration
- YAML-based device, environment, and scenario files
- JSON message schemas
- MQTT command-line tools
- `sml alias` shortcuts for frequently used commands
- `sml cc` command cards for reusable and reviewable test
procedures
- `sml mqttcli`, which is a command-line tool for monitoring and
injecting MQTT traffic in the simulation target
- `sub` subscribes to simulator topics and displays
incoming messages
- `pub` reads a YAML command file and publishes one or more
messages
- Supports message sequences with configurable intervals
- Validates known payloads against generated JSON schemas before
transmission
- Automatically applies the appropriate envelope format and uses the same
broker configuration as the APSS/MPSS processes
This layered configuration model allows customers to reproduce normal operation,
error conditions, timeouts, state transitions, and asynchronous events in a
repeatable way.
For example, to inject an out-of-service scenario during a normal runtime:
1. Create an MQTT command sequence YAML setup.
Save as
sml/tools/mqttcli/commands/radio\_out\_of\_service\_sequence.yaml.
The
following example defines an out-of-service environment setup lasting 15
seconds:
topic: ctrl/cmd/action/radio/force_sys_info
qos: 1
retain: false
interval: 15s
data:
- slot: 1
rat: RADIO_TECH_LTE
domain: NO_SRV
state: NO_SERVICE
- slot: 1
rat: RADIO_TECH_LTE
domain: CS_PS
state: IN_SERVICECopy to clipboard
2. Monitor the radio indication.
In a terminal, use the following
command:
sml mqttcli sub 'mp/ind/radio/sys_info'Copy to clipboard
3. Inject the sequence.
In another terminal, use the following
command:
sml mqttcli pub \
sml/tools/mqttcli/commands/radio_out_of_service_sequence.yamlCopy to clipboard
This
sends the out-of-service command immediately and restores service after 15
seconds. No MPSS restart is required.
Expected indications:
{
"rat": "RADIO_TECH_LTE",
"domain": "NO_SRV",
"state": "NO_SERVICE"
}Copy to clipboard
After 15 seconds:
{
"rat": "RADIO_TECH_LTE",
"domain": "CS_PS",
"state": "IN_SERVICE"
}Copy to clipboard
- **[Set up the basic development environment on PC host](https://docs.qualcomm.com/doc/80-41102-1/topic/set-up-the-development-host-environment.html)**
- **[Install docker engine on the host](https://docs.qualcomm.com/doc/80-41102-1/topic/install-docker-engine-on-the-host.html)**
- **[Change storage location of the docker data (optional)](https://docs.qualcomm.com/doc/80-41102-1/topic/change-storage-location-of-the-docker-data-optional.html)**
- **[Get the source code from the CLO website](https://docs.qualcomm.com/doc/80-41102-1/topic/get-the-source-code-from-the-clo-website.html)**
- **[Build TelAF simulation docker images](https://docs.qualcomm.com/doc/80-41102-1/topic/build-docker-image-for-telaf-simulation.html)**
- **[Build the TelAF simulation in the develop docker container](https://docs.qualcomm.com/doc/80-41102-1/topic/build-the-telaf-simulation-in-the-docker-container.html)**
- **[Deploy TelAF on the simulation environment](https://docs.qualcomm.com/doc/80-41102-1/topic/deploy-telaf-on-the-simulation-environment.html)**
- **[Build an application with simulation target](https://docs.qualcomm.com/doc/80-41102-1/topic/build-an-application-with-simulation-target.html)**
- **[Use SSH to connect to the TelAF simulation container](https://docs.qualcomm.com/doc/80-41102-1/topic/use-ssh-to-connect-to-the-telaf-simulation-container.html)**
- **[Multiple containers support](https://docs.qualcomm.com/doc/80-41102-1/topic/multiple-containers-support.html)**
- **[Configure Cgroup in simulation](https://docs.qualcomm.com/doc/80-41102-1/topic/configure-cgroup-in-simulation.html)**
- **[Features supported by simulation](https://docs.qualcomm.com/doc/80-41102-1/topic/features-supported-by-simulation.html)**
Last Published: Oct 28, 2026
[Previous Topic
On the client PC](https://docs.qualcomm.com/bundle/publicresource/80-41102-1/topics/on_the_client_pc.md) [Next Topic
Set up the basic development environment on PC host](https://docs.qualcomm.com/bundle/publicresource/80-41102-1/topics/set-up-the-development-host-environment.md)