IMS Architecture: Layers, Components & Call Flow

IMS Architecture: Layers, Components & Call Flow

IMS architecture is the telecom framework that enables operators to deliver IP-based voice and multimedia services such as VoLTE, VoWiFi, messaging and, in 5G networks, VoNR. At its core, IMS separates service logic, SIP session control, subscriber data and media handling so operators can build and operate communication services over packet networks.

For a carrier or MVNO, understanding IMS architecture is important because the IMS core sits between the subscriber access network and the services that handle voice and multimedia sessions. The architecture typically includes CSCF functions such as P-CSCF, I-CSCF and S-CSCF, subscriber data functions such as HSS, application servers, policy and charging functions, and interworking components where required.

This guide explains the main IMS components, the IMS layers from a practical operator perspective, how an IMS call is established, how Cloud IMS changes deployment, and where IMS fits into an MVNO launch.

What Is IMS Architecture?

The IP Multimedia Subsystem (IMS) is a standardized architecture defined by 3GPP for delivering multimedia communication services over IP networks.

IMS is not a single server or product. It is a collection of network functions, databases, interfaces and service components that work together to authenticate subscribers, establish SIP sessions, apply service policies and connect calls to the appropriate destination.

IMS can support services including:

• VoLTE
• VoWiFi
• VoNR
• Video communication
• SMS over IP
• Rich Communication Services (RCS)
• Multimedia and communication applications

One of the most important ideas behind IMS is the separation between signaling and media.

SIP signaling is used to register subscribers and establish, modify and terminate sessions. Media such as voice is carried separately using protocols such as RTP.

This separation makes it possible for operators to introduce new services without redesigning the entire voice network.

Why Does IMS Matter to Telecom Operators?

For a mobile operator, IMS provides a standardized service architecture for IP-based voice and multimedia communication.

For example, an LTE subscriber may use packet connectivity for data while IMS provides the signaling and service framework required for VoLTE.

The same IMS environment can also support other services such as VoWiFi and, with the appropriate network architecture and profiles, 5G voice services.

According to the GSMA, VoLTE uses IMS technology to provide packet voice over LTE and can also support richer services such as video and RCS.

For operators, this means IMS can become a common service platform rather than building a separate voice architecture for every service.

A practical carrier example

Imagine a mobile operator launching VoLTE.

The operator needs more than an LTE radio network. It also needs a service architecture that can:

1. Authenticate the subscriber.
2. Register the device with the voice service.
3. Route SIP signaling.
4. Apply subscriber and service policies.
5. Establish the voice session.
6. Connect the media path.
7. Interwork with other networks when necessary.

IMS provides the framework for these functions.

---

IMS Architecture Layers: A Practical View

IMS can be explained using three conceptual areas:

1. Application and service layer
2. IMS control and signaling layer
3. Connectivity and media layer

This three-layer model is useful for understanding the architecture, although real IMS deployments contain more functions, interfaces and dependencies than a simple three-layer diagram suggests.

1. Application and Service Layer

The application layer contains the service logic that determines what happens after a subscriber requests a service.

Examples include:

• Telephony services
• Call forwarding
• Voice mail
• Number translation
• Business communication services
• Messaging
• RCS
• Other SIP-based applications

Application Servers can interact with the IMS core to provide service-specific logic.

For example, if a subscriber has call forwarding enabled, the Application Server can influence how the SIP session is handled without requiring the operator to redesign the core CSCF architecture.

2. IMS Control and Signaling Layer

This is where the main IMS session-control functions operate.

The most important CSCF functions are:

• P-CSCF
• I-CSCF
• S-CSCF

Other network functions such as subscriber databases, policy functions and charging systems interact with this control environment.

The control layer is responsible for tasks such as:

• Registration
• Authentication support
• SIP routing
• Session control
• Service triggering
• Subscriber profile handling
• Policy interaction

3. Connectivity and Media Layer

The media side carries the actual voice, video and other real-time traffic.

Depending on the deployment, this environment can include:

• IP connectivity
• LTE or 5G access
• Wi-Fi access
• Media gateways
• Media processing functions
• Interworking with legacy or external networks

The important distinction is simple:

SIP controls the session. RTP carries the media.

That distinction is fundamental when troubleshooting an IMS or VoLTE deployment.

IMS Core Components Explained

The IMS core contains several functions, but four components are particularly important when learning the architecture.

P-CSCF: Proxy Call Session Control Function

The P-CSCF is normally the first IMS contact point for the user equipment.

It handles SIP signaling between the subscriber and the IMS network and can perform functions related to security, policy and signaling handling.

In a simplified registration flow:

UE → P-CSCF → IMS core

For an operator, the P-CSCF is therefore an important access-side IMS function.

I-CSCF: Interrogating Call Session Control Function

The I-CSCF acts as an entry point toward the home IMS network.

It can use subscriber information to help determine which S-CSCF should handle the subscriber.

This becomes particularly important when dealing with subscriber registration, routing and inter-operator scenarios.

S-CSCF: Serving Call Session Control Function

The S-CSCF is the central session-control function in the IMS core.

It handles tasks such as:

• SIP registration
• Session control
• SIP routing
• Service triggering
• Interaction with Application Servers
• Subscriber service profile handling

A simplified call path can therefore look like:

UE → P-CSCF → S-CSCF → Application Server → destination

The exact signaling path depends on the service and network architecture.

HSS: Home Subscriber Server

The HSS stores subscriber-related information used by the IMS environment.

This can include:

• Subscriber identity
• Authentication information
• Service profiles
• Registration-related information
• Subscription data

The CSCF functions use subscriber information from the HSS to determine how a subscriber should be authenticated and served.

Modern deployments can implement subscriber-data functions using virtualized or cloud-based infrastructure rather than traditional dedicated hardware.

---

Other IMS Components Operators May Need

A production IMS deployment can contain considerably more than P-CSCF, I-CSCF, S-CSCF and HSS.

Depending on the operator’s services and interconnection requirements, additional functions can include:

• Application Servers
• Policy control functions
• Charging systems
• SBC or interconnection functions
• Media Gateway Control Function (MGCF)
• Media Gateways
• Border Gateway Control Function (BGCF)
• Media Resource Functions
• ENUM or DNS infrastructure
• Diameter-related interfaces
• SIP interconnection functions

Not every operator needs every component.

The required architecture depends on the services being offered, the access technology, roaming requirements, PSTN interworking, regulatory requirements and existing network infrastructure.

IMS Protocols: SIP, Diameter and RTP

IMS depends on several protocols and interfaces.

SIP

Session Initiation Protocol is the main signaling protocol used for IMS session control.

SIP can be used to:

• Register users
• Initiate calls
• Modify sessions
• Terminate sessions
• Trigger services

For example, a VoLTE call involves SIP signaling before the voice media starts flowing.

Diameter

Diameter is used in IMS for communication between network functions and subscriber or policy systems.

It can support functions related to:

• Authentication
• Authorization
• Subscriber information
• Policy interaction
• Charging

The exact Diameter interfaces depend on the IMS architecture and deployment.

RTP

Real-time Transport Protocol carries the actual voice or multimedia media.

A simple way to remember the difference is:

Function	Main role
SIP	Controls the communication session
Diameter	Exchanges subscriber, authentication, policy or charging information
RTP	Carries real-time voice or video media

This distinction is particularly useful when diagnosing VoLTE problems.

IMS Call Flow Explained Step by Step

An IMS call does not begin with the phone simply sending voice packets.

The subscriber normally needs to be registered and authenticated before the IMS network can provide the required service.

Step 1: IMS Registration

The UE sends a SIP REGISTER message toward the IMS network.

A simplified path is:

UE → P-CSCF → I-CSCF → S-CSCF

Subscriber information is retrieved from the appropriate subscriber database during the registration process.

After successful authentication and registration, the subscriber can use IMS services according to the configured profile.

Step 2: Subscriber Authentication

The IMS environment verifies that the subscriber is authorized to use the service.

The network checks information associated with the subscriber profile and authentication procedure.

This step is critical for mobile operators because IMS services must be tied to valid subscriptions and service permissions.

Step 3: SIP Call Setup

When the subscriber places a call, the UE sends a SIP INVITE.

A simplified flow may look like:

UE A → P-CSCF → S-CSCF → service logic/interconnect → destination network

The IMS core determines how the request should be routed.

Routing can depend on factors such as:

• Subscriber profile
• Destination
• Numbering information
• Service rules
• Interconnection configuration
• Operator policy

Step 4: Session Negotiation

SIP signaling is used to negotiate the communication session.

The network determines how the media session should be established, including information such as supported media parameters.

Step 5: Media Establishment

After signaling has successfully established the session, the actual media path is created.

Voice packets can then flow using RTP.

The signaling and media paths should be considered separately when analyzing network behavior.

Step 6: Call Termination

When one party ends the call, SIP signaling is used to terminate the session.

The associated media resources can then be released.

IMS Call Flow Example for a VoLTE Operator

Consider a mobile operator with LTE access and an IMS core.

A simplified VoLTE call looks like this:

Subscriber A

↓

LTE Access Network

↓

P-CSCF

↓

I-CSCF / S-CSCF

↓

Application / Policy Functions

↓

Destination IMS Network

↓

Subscriber B

The SIP signaling establishes and controls the session.

The actual voice media then follows the appropriate media path through the operator’s IP network and any required media or interworking functions.

This is why a VoLTE deployment cannot be treated simply as “voice over LTE.” LTE provides the packet access, while IMS provides the service and session-control framework required for the voice service.

IMS and VoLTE: What Is the Relationship?

VoLTE means Voice over LTE.

IMS is the service architecture used to deliver VoLTE.

In simple terms:

LTE provides the access network.

IMS provides the IP-based voice service architecture.

The GSMA describes VoLTE as a packet voice service delivered over IP via LTE access and based on IMS technology.

This architecture also creates a path toward related services such as VoWiFi and other IP communication services.

For operators, this is important because IMS can become a common platform for multiple communication services instead of being limited to one voice product.

Cloud IMS Architecture

Traditional IMS deployments were often associated with dedicated telecom hardware and large network environments.

Cloud IMS moves the IMS functions toward software-based infrastructure.

Depending on the architecture, IMS network functions can be deployed using:

• Virtual machines
• Virtual Network Functions (VNFs)
• Cloud-Native Network Functions (CNFs)
• Containers
• Automated orchestration
• Cloud-based databases and supporting services

The objective is not simply to “put IMS in the cloud.”

A serious Cloud IMS deployment still needs to address:

• High availability
• Network latency
• Security
• SIP signaling
• Media handling
• Subscriber management
• Monitoring
• Capacity planning
• Interconnection
• Regulatory requirements
• Disaster recovery

Legacy IMS vs Cloud IMS

Area	Traditional IMS	Cloud-oriented IMS
Infrastructure	Dedicated hardware	Virtual/cloud infrastructure
Scaling	Hardware expansion	Software/resource scaling
Deployment	Hardware-led	Software-led
Operations	More infrastructure intensive	More automation potential
Flexibility	More tightly coupled to hardware	Greater deployment flexibility
Upgrade model	Hardware/software lifecycle	Software-driven lifecycle

Cloud does not automatically make an IMS deployment cheaper.

The business case depends on traffic volume, architecture, licensing, cloud resources, operations, redundancy and integration requirements.

What Does an Operator Need to Launch IMS?

An operator planning an IMS deployment should think about the project as a complete telecom system rather than buying an IMS server.

The main areas include:

1. Access Network

The operator needs the relevant mobile or broadband access infrastructure.

For a VoLTE service, this includes the LTE environment and the connectivity required to reach IMS.

2. IMS Core

The required IMS functions need to be deployed and integrated.

This can include:

• P-CSCF
• I-CSCF
• S-CSCF
• Subscriber database functions
• Application Servers
• Policy and charging functions
• Media/interworking functions where required

3. Subscriber and Provisioning Systems

The operator needs a way to provision subscribers and associate them with the correct service profiles.

4. SIP and IP Interconnection

The IMS environment must connect to other networks when calls leave the operator’s own network.

This can include:

• Other IMS networks
• PSTN
• SIP carriers
• Roaming partners
• Wholesale voice networks

5. Operations and Monitoring

Production IMS requires operational visibility.

Operators should monitor areas such as:

• SIP registration success
• Call setup success
• Call drops
• Signaling failures
• Media quality
• Network capacity
• Subscriber provisioning
• Interconnection performance

6. Testing and Interoperability

IMS deployments require extensive testing because multiple network elements, devices, vendors and external networks have to interoperate.

The GSMA’s VoLTE guidance highlights interoperability testing and verification as important parts of commercial IMS deployment.

How Much Does IMS Infrastructure Cost?

There is no single reliable IMS deployment price.

The total cost depends heavily on the operator’s architecture and business model.

Important cost drivers include:

• Number of subscribers
• Expected concurrent sessions
• Geographic coverage
• High-availability requirements
• Cloud or physical infrastructure
• IMS licensing
• SBC and interconnection requirements
• Subscriber management
• Number portability
• Charging and billing integration
• Roaming
• PSTN interconnection
• Monitoring and operations
• Support and engineering

For a large MNO, the IMS project can become a major network infrastructure program.

For a smaller operator or MVNO, buying and operating every IMS component independently may not be commercially attractive.

This is where hosted or Cloud IMS models can change the economics.

Instead of building the complete infrastructure internally, an operator can use an existing telecom platform and focus internal resources on subscribers, commercial services, integration and operations.

IMS for MNO vs MVNO vs MVNE vs MVNA

These business models should not be treated as interchangeable.

Model	Basic role	Typical IMS responsibility
MNO	Owns/operates mobile network infrastructure	May operate its own IMS environment
MVNO	Provides mobile services using an MNO’s network	Depends on MVNO model and host-network integration
MVNE	Provides technology/platform services to MVNOs	Can provide core technology and operational capabilities
MVNA	Aggregates or represents multiple MVNO relationships	Business/network aggregation role varies by market

MNO

An MNO operates its own mobile network infrastructure and normally has significantly more control over the underlying network architecture.

IMS can therefore be deeply integrated into its mobile core, service platforms and interconnect environment.

MVNO

An MVNO does not necessarily need to build every part of the mobile network itself.

The exact IMS requirements depend on the MVNO model and the commercial and technical agreement with the host MNO.

Some MVNOs may rely heavily on the host operator’s network functions, while others need more independent service and core capabilities.

MVNE

An MVNE provides technology and operational capabilities that help MVNOs launch and operate services.

An MVNE model can therefore reduce the amount of telecom infrastructure an individual MVNO needs to build internally.

MVNA

An MVNA generally focuses on aggregating or enabling multiple MVNO relationships.

The exact responsibilities vary between markets and commercial models.

The key point is that IMS architecture should be selected after defining the mobile business model, not before.

Where IMS Fits Into an MVNO Launch

IMS is only one part of an MVNO architecture.

A typical MVNO launch also requires areas such as:

• Host MNO connectivity
• Subscriber management
• SIM/eSIM provisioning
• Numbering
• Billing
• CRM
• Mobile data services
• Voice services
• SMS
• Roaming
• Interconnection
• Regulatory compliance
• Customer support
• Network monitoring

A practical launch sequence can therefore look like:

Business model

↓

Host MNO agreement

↓

Network and service requirements

↓

Subscriber and provisioning architecture

↓

Voice/IMS requirements

↓

Interconnection

↓

Billing and OSS/BSS integration

↓

Testing

↓

Commercial launch

The exact sequence depends on the country, host MNO and MVNO model.

When Does a Cloud IMS Platform Make Sense for an MVNO?

A Cloud IMS approach becomes particularly interesting when the MVNO wants to provide mobile voice services without building a large traditional telecom infrastructure environment.

The operator can focus on:

• Subscriber acquisition
• Product design
• Pricing
• Customer experience
• Distribution
• Mobile service integration

while the technology platform provides the underlying communication infrastructure.

However, an MVNO should not select a platform based only on the word “cloud.”

Before choosing an IMS platform, evaluate:

Subscriber scalability

Can the platform support the expected subscriber base and future growth?

Voice services

Does it support the services the MVNO actually plans to launch, such as VoLTE or VoWiFi?

Integration

Can it integrate with the host MNO and the operator’s provisioning, billing and business systems?

Interconnection

Can it connect to the required voice and SIP networks?

Operations

What monitoring, reporting and troubleshooting capabilities are available?

Security and resilience

How are redundancy, signaling security, data protection and disaster recovery handled?

Commercial model

Understand whether the platform is priced around subscribers, sessions, traffic, licenses, infrastructure or a combination of factors.

IMS Architecture Deployment Checklist

Before moving from architecture design to deployment, a telecom operator should confirm:

• IMS architecture has been defined
• P-CSCF requirements are documented
• I-CSCF and S-CSCF requirements are documented
• Subscriber database requirements are defined
• Application Server requirements are defined
• Policy and charging requirements are documented
• SIP interconnection is planned
• Media/interworking requirements are defined
• LTE/5G/Wi-Fi connectivity is ready
• Provisioning is integrated
• Billing and charging are integrated
• Monitoring is available
• High availability has been tested
• Disaster recovery has been planned
• Device interoperability has been tested
• Commercial launch criteria are defined

IMS Architecture in 5G and VoNR

IMS remains relevant as operators move toward 5G voice.

Voice over New Radio (VoNR) uses the 5G radio environment while relying on IMS for the IP-based voice service architecture.

This means an operator moving toward 5G does not simply replace IMS with the 5G Core.

Instead, the 5G network and IMS architecture work together to provide voice services.

For operators planning long-term infrastructure, this makes IMS an important part of the transition from LTE voice to 5G voice.

Common IMS Architecture Mistakes

Treating IMS as a single product

IMS is an architecture made up of multiple network functions and interfaces.

Buying one IMS component does not create a complete production voice environment.

Ignoring interconnection

A private IMS network is not enough if subscribers need to call users on other networks.

SIP interconnection, PSTN connectivity and routing need to be designed from the beginning.

Focusing only on signaling

A call can successfully establish at the SIP level while still having media-quality problems.

Signaling and media must therefore be monitored independently.

Assuming Cloud means zero infrastructure

Cloud IMS can reduce infrastructure ownership and improve deployment flexibility, but operators still need networking, security, monitoring, integration and operational expertise.

Choosing the IMS architecture before defining the business model

An MNO, MVNO, MVNE and MVNA can have very different infrastructure responsibilities.

The business model should drive the technical architecture.

Frequently Asked Questions About IMS Architecture

What is IMS architecture?

IMS architecture is a standardized telecom framework used to deliver IP-based voice and multimedia services. It includes session-control functions, subscriber databases, application functions, policy and charging systems, and media/interworking components.

What are the main IMS components?

The core IMS components commonly discussed include P-CSCF, I-CSCF, S-CSCF and subscriber database functions such as HSS. Production networks can also require Application Servers, policy and charging functions, media gateways and interconnection components.

How does IMS support VoLTE?

VoLTE uses LTE as the access network and IMS as the service and session-control architecture. IMS handles functions such as registration, authentication support, SIP signaling, routing and service control, while the media is carried separately.

What is an IMS call flow?

An IMS call flow describes how a subscriber registers, becomes authenticated, establishes a SIP session, negotiates media and terminates the call.

What is Cloud IMS?

Cloud IMS is an IMS deployment model in which IMS functions run on virtualized or cloud-oriented infrastructure instead of relying exclusively on dedicated telecom hardware.

Do MVNOs need their own IMS?

Not necessarily. IMS requirements depend on the MVNO model, host MNO relationship, services being offered and the degree of network control the MVNO needs.

For some MVNOs, using a hosted or Cloud IMS platform can be more practical than building every IMS function internally.

What is the difference between IMS and VoLTE?

IMS is the service architecture.

VoLTE is a voice service delivered over LTE using IMS.

In short:

IMS = architecture

VoLTE = voice service over LTE using IMS

Final Takeaway

IMS architecture is the foundation for IP-based voice and multimedia services across modern telecom networks.

The most important IMS components to understand are P-CSCF, I-CSCF, S-CSCF and subscriber-data functions, but a production deployment can require additional application, policy, charging, media and interconnection functions.

For an MNO, IMS can form part of the operator’s core service infrastructure.

For an MVNO, the question is different: how much of the IMS and voice infrastructure should be built internally, integrated through the host operator, or delivered through a technology platform?

That decision should be based on the MVNO business model, expected subscriber scale, required voice services, integration requirements and operating capabilities.

If you are planning to launch an MVNO and do not want to build the complete telecom infrastructure from scratch, explore VoiceBuy’s MVNO platform to evaluate a more practical infrastructure approach.

For operators specifically looking for IMS infrastructure, you can also review VoiceBuy’s Cloud IMS platform and discuss the technical requirements of your planned deployment with the team.

Ready to Plan Your IMS or MVNO Infrastructure?

Define your target market, subscriber model, host-network requirements and voice services first. Then select the IMS and telecom platform that matches those requirements instead of overbuilding the network from day one.