SSM

Source Specific IP Multicast

Services →
Introduced in Rel-8

SSM is an IP multicast delivery model where traffic is forwarded only from a specific source address to a multicast group address.

Category
Services
Introduced
Rel-8
Where
Services › IMS
Specifications
3 specs
SSM Description Purpose Related Classification Detected Changes Specifications

Description

Source Specific IP Multicast (SSM) is an Internet Protocol (IP) multicast service model defined by the IETF and adopted within 3GPP architectures for efficient multimedia content distribution. In contrast to Any-Source Multicast (ASM), where receivers join a group G and receive data from any sender to that group, SSM requires receivers to specify both a multicast group address G and a specific source address S, forming a channel (S,G). This model fundamentally changes the multicast subscription and routing mechanics. A receiver expresses interest by sending an Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) report for the channel (S,G). The network's multicast routing protocols (like Protocol Independent Multicast - Sparse Mode in SSM, PIM-SSM) then build source-specific distribution trees from the specified source S to all receivers of (S,G).

Within 3GPP systems, SSM is particularly relevant for IP Multimedia Subsystem (IMS) and Multimedia Broadcast/Multicast Service (MBMS) architectures. For MBMS, SSM can be used as the IP multicast routing method for delivering content over the core network to multiple Base Stations. The BM-SC (Broadcast Multicast Service Center) acts as the source (S), and UEs join a specific (S,G) channel to receive the broadcast or multicast stream. This architecture simplifies network operation by eliminating the need for shared rendezvous points (RPs) used in ASM and inherently provides a basic level of access control, as receivers only get data from the pre-advertised source.

The operation involves several key components: the content source (e.g., BM-SC), IP multicast routers in the core network, and the UE which supports IGMP/MLD. The BM-SC announces the (S,G) channel information via service announcement procedures. When a UE wishes to receive the service, it triggers a join for that specific channel. The join message propagates hop-by-hop towards the source, building the distribution tree. Data from the source then flows down this tree to all joined receivers. This model is highly efficient for one-to-many distribution of linear media like live TV, as it creates optimal routing paths and prevents traffic from unauthorized or unintended sources from reaching the group.

Purpose & Motivation

SSM was developed to overcome operational and security complexities associated with the original Any-Source Multicast (ASM) model. ASM faced challenges with source discovery (requiring mechanisms like MSDP), vulnerability to denial-of-service attacks from spurious sources sending to a group, and complex inter-domain routing. SSM addresses these by making the source an explicit part of the subscription, which simplifies protocol design, enhances security by limiting valid sources, and improves scalability for widespread content distribution.

In the 3GPP context, the adoption of SSM was motivated by the requirements of efficient multimedia broadcast and multicast services, starting with MBMS in Release 6. Delivering the same content (e.g., a live sports event) to thousands of UEs necessitates an efficient IP multicast mechanism in the core network. SSM provided a cleaner, more manageable model than ASM for this controlled environment where the source (the service provider's BM-SC) is always known and authorized. It solved the problem of how to efficiently scale IP-based broadcast services over mobile networks without the overhead and security risks of the more general ASM model. Its inclusion supported the commercial deployment of mobile TV and group communications services.

Classification

Part ofMBMS
Related approachesBM-SC

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (14 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 3 changes

In Release 15, the SSM function was enhanced through the introduction of vendor-specific NF Types and vendor-specific Information Elements (IEs) within the NF Profile. This allowed for greater implementation flexibility and vendor differentiation in SSM deployments. Additionally, the release standardized the storage of OpenAPI specification files to support these SSM-related functions.

  • Vendor-Specific NF Types TS 29.510CR0010
  • Vendor-Specific IEs in NF Profile TS 29.510CR0163
  • Storage of OpenAPI specification files TS 29.510CR0167
Rel-17 7 changes

In Release 17, enhancements for the SSM function included the introduction of a Service Specific Authorization mechanism and the ability to convey Service Specific Info within Default Notification Subscriptions. Additionally, improvements were made to the Nnrf_NFManagement API's OpenAPI specification, such as adding missing description fields to data type definitions and clarifying the use of query parameters for preferred vendor-specific features.

  • Query parameter for preferred vendor-specific features TS 29.510CR0400
  • Support for Service Specific Authorization TS 29.510CR0587
  • PLMN Specific attributes in NF profile TS 29.510CR0627
  • Issues with definition of heartBeatTimer attribute and limit Query-parameter in Open API specification TS 29.510CR0399
  • Supported Vendor-Specific Features TS 29.510CR0459
  • Adding some missing description fields to data type definitions in OpenAPI specification files of the Nnrf_NFManagement API TS 29.510CR0514

+ 1 more changes

Rel-18 3 changes

In Release 18, the updates to the SSM function were focused on specification alignment and notification enhancements. This included aligning the service name and the ML Model Interoperability indicator with the stage-2 specification. Furthermore, a specific load notification capability was introduced for the NFStatus subscribe procedure.

  • Aligning the service name with stage-2 specification TS 29.510CR0943
  • Align ML Model Interoperability indicator to stage 2 specification TS 29.510CR0962
  • Specific load notification for NFStatus subscribe TS 29.510CR0957
Rel-19 1 change

In Release 19, the SSM (Source Specific IP Multicast) function saw no new feature introductions or protocol changes based on the provided documentation. The only related work item involved a clarification to the description of the Source NF instance ID within Access Token Claims. This update aimed to improve the precision of existing specifications rather than adding new SSM capabilities.

  • Clarification to the Source NF instance ID description in Access Token Claims TS 29.510CR1081

Explore further

Broader topics and technologies where SSM plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.246 vj00 MBMS Bearer Service Stage 2 Description Rel-19
TS 29.510 vj50 NRF Service Based Interface Protocol Rel-19
TS 29.522 vj40 5G NEF Northbound APIs Stage 3 Rel-19