Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Services

Receiving Application

Receiving Application

Services →

Receiving Application is the ultimate destination entity for an Application Message in the 3GPP secured messaging framework, receiving the decrypted and verified payload.

Introduced
Rel-5
Where
Security
Specifications
2 specs
Receiving Application Description Purpose What changed Neighbours Specifications

Description

The Receiving Application is a logical entity defined in 3GPP TS 22.048 and TS 23.048 that represents the final consumer of an Application Message within the secured packet infrastructure. It sits at the top of the receiving-side protocol stack, above the security layer. The Application Message originates from a Sending Application, is packaged into a Secured Packet by the Sending Entity, transported over a bearer such as SMS or USSD, and processed by the Receiving Entity. Once the Receiving Entity has performed all necessary security functions—integrity verification, decryption, replay detection, and timestamp validation—the resulting Application Message is delivered to the Receiving Application.

The Receiving Application is not necessarily a physical network node; it is a functional role. In practice, it may reside on a UICC (e.g., a SIM Toolkit applet), in a terminal, or in an external server such as a (U)SIM Toolkit Server or a dedicated application server. The 3GPP specifications deliberately abstract the Receiving Application from the underlying transport and security mechanisms, allowing the same security framework to serve diverse use cases: remote applet management, OTA provisioning, mobile payment, and machine-to-machine commands.

The interface between the Receiving Entity and the Receiving Application is not fully standardized in terms of API; instead, 3GPP defines the security and packaging formats, leaving the internal delivery to implementation. However, the Receiving Application must be able to interpret the Application Message according to the application-specific protocol agreed with the Sending Application. This separation of concerns—security handled by the Receiving Entity, business logic handled by the Receiving Application—is a key architectural principle.

Because the Receiving Application is the ultimate target, its identity and addressing are crucial for routing. The Sending Application must know how to address the Receiving Application, often via an identifier such as an MSISDN, an IP address, or an application identifier. The security mechanisms ensure that only the intended Receiving Application can process the message, and that the message has not been altered or replayed.

In summary, the Receiving Application is the endpoint of the secured messaging chain. It relies on the Receiving Entity to enforce security, and it embodies the business or operational logic that consumes the Application Message. Its definition in Rel-5 remains unchanged, reflecting the stability of the concept.

Purpose & Motivation

The Receiving Application exists to provide a clear architectural separation between the security processing of a message and the actual consumption of its payload. Before the introduction of the secured packet framework in 3GPP Rel-5, over-the-air application messages were often transported without a standardized, end-to-end security layer, leading to risks of eavesdropping, tampering, and replay. By defining a distinct Receiving Application, 3GPP enabled a modular approach: security can be implemented once in the Receiving Entity, while multiple Receiving Applications can benefit from it without each having to implement complex cryptographic operations.

This abstraction also solves the problem of heterogeneity. Different applications—SIM Toolkit applets, OTA provisioning servers, payment systems—have different data formats and processing requirements. The Receiving Application allows each to focus on its domain logic, while the Receiving Entity handles the common security functions. This reduces development effort, improves interoperability, and ensures consistent security enforcement across services.

Furthermore, the concept supports scalability and flexibility. New applications can be deployed without modifying the security infrastructure, as long as they adhere to the Application Message format. This future-proofs the architecture and encourages innovation in mobile services. The Receiving Application thus plays a vital role in the 3GPP vision of a secure, open, and service-rich mobile ecosystem.

What changed in its specifications

The latest release-to-release comparison of specifications that define Receiving Application. Each summary describes the whole specification, not only this term.

TS 23.048Rel-4 → Rel-5

Rel-5 added applet management commands, minimum security level specification, and a security layer relation to Open Platform architecture.

Full comparison in TS 23.048 →

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-5 Initial

Initial definition introduced in 3GPP TS 22.048 and TS 23.048: 'this is the entity to which the Application Message is destined.' This established the concept of a final recipient distinct from the Receiving Entity, forming part of the secured packet architecture.

Defining Specifications

3GPP specifications that define or reference Receiving Application, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 22.048 v500 Security Mechanisms for SIM Toolkit Rel-5 read
TS 23.048 v590 Secured Packets Structure for SMS and UICC Management Rel-5 read