PRESENTATION - FULL - 2026 - FINLAND - THAILAND

THE FIN TELECOM OY - fintelco.fi - FINLAND - THAILAND

The FIN 5G-IMS Mediation Solution

Private 5G IMS cores in two countries - Finland HPLMN and Thailand VPLMN - live correlation, not simulation. 2 binary CDRs to 1 billable record that is correct, also for prepaid.

5G-ADVANCED 6G STUDIES FUTURE READY OCDR + TCDR CORRELATION CHF - CGF - OCS - TAP3 S8HR - LBO - SEPP N32-f HPLMN - VPLMN

Architecture - Finland HPLMN + Thailand VPLMN - Enterprise 5G SA

Diagram: Finland HPLMN private core generates OCDR, Thailand VPLMN generates TCDR via SEPP N32-f. Both feed The FIN Mediation which correlates via SIP Call-ID and P-Charging-Vector, rates via CHF and OCS, outputs 1 billable ASCII, real PDF invoices. No proprietary lock-in. Enterprise 5G SA.

Data - What is OCDR and TCDR and why correlation matters

OCDR - Originating - Finland HPLMN

Originating Charging Data Record - created at originating side when MO call or session starts.
Contains: Calling party, called party, SIP Call-ID, P-Charging-Vector with ICID and IOI, time stamps, access network info, QoS 5QI, media components, location.
Generated by: SMF - IMS AS - CHF. Sent to CGF then to mediation.
Key: without OCDR you cannot bill MO leg correctly.

TCDR - Terminating - Thailand VPLMN

Terminating Charging Data Record - created at terminating and visited side for MT and roaming.
Contains: Called party, calling party, visited network ID, roaming scenario S8HR or LBO, SEPP N32-f security context, visited CHF rating, QoS, duration.
Generated by: Visited SMF - IMS - visited CHF.
Key: without TCDR you cannot bill roaming correctly - leakage or double billing.

Correlation - 2 binary to 1 billable ASCII - Vital

[FIN-IMS FINLAND] OCDR received - MO VoNR - Call-ID: a1b2c3d4@ims.finland - ICID: 1234-5678 - P-CSCF: pcscf.finland - 5QI=1 voice QCI=1
[THA-IMS THAILAND] TCDR received - MT VoNR - Call-ID: a1b2c3d4@ims.finland - ICID: 1234-5678 - SEPP N32-f OK - VPLMN: thailand - 5QI=1
[MEDIATION] Correlation key match - Call-ID + ICID + Orig IOI + Term IOI - OK
[MEDIATION] Check duplicate - Hash(Call-ID+ICID+time) - duplicate 0 percent
[MEDIATION] Merge media - OCDR media + TCDR media - QoS mapping 5QI=1 to 5QI=5 for voice + video
[RATING] CHF - Home tariff - 0.12 EUR/min - Visited tariff - 0.18 EUR/min - TAP3 markup when needed
[OCS] Prepaid balance check - user: 100 EUR - cost: 0.30 EUR - balance OK - real-time auth
[BILLING] Output: 1 ASCII - TAP3.12 and invoice PDF - IMS-Invoice_VPLMN_Postpaid.pdf

Explanation: Correlation uses SIP Call-ID which is same end to end, plus P-Charging-Vector ICID which is globally unique per charging transaction. If either OCDR or TCDR is missing, mediation raises alarm. Duplicate check prevents double billing. Result is single billable record for both home and visited rating.

Infra - Private 5G SA cores - Finland and Thailand

FINLAND - HPLMN - PRIVATE CORE

Online - Enterprise 5G SA

gNB - 5G radio - SA mode
AMF - Access Management
SMF - Session Management - UPF control
UPF - User Plane - N6 to data network
IMS - P-CSCF - S-CSCF - I-CSCF - AS
PCF - Policy - 5QI mapping
CHF - Charging Function - OCDR
SEPP - Security Edge - N32-f

MEDIATION - THE FIN

Correlation Engine

Input: OCDR binary + TCDR binary
Correlation: Call-ID + ICID + IOI
Duplicate detection: 0 percent
Leakage detection: 0 percent
Rating: CHF home + visited
OCS: Prepaid real-time
Output: 1 ASCII - TAP3 - PDF
No proprietary lock-in

THAILAND - VPLMN - PRIVATE CORE

Online - Enterprise 5G SA

gNB - 5G radio - SA mode
AMF - Access Management
SMF - Session Management
UPF - Local Breakout - LBO
IMS - P-CSCF - S-CSCF - SEPP
Visited CHF - Visited rating
TCDR - Terminating - Roaming
S8HR - Home Routed - Alternative

Phone Menu System in Modern Network

How the Menu System Works

IVR is not gone - it is renamed
In 2G/3G: IVR box as peripheral.
In IMS 5G: MRF - Media Resource Function
- MRFC - Media Resource Function Controller - SIP AS
- MRFP - Media Resource Function Processor - media - announcements - IVR prompts
- IVR AS - Application Server - VXML - prepaid balance announcements - roaming welcome - top-up prompts

CDR from IVR:
MRF produces MRF-CDR or IVR-CDR with same SIP Call-ID as OCDR/TCDR
Duration of announcement - prompt ID - result - DTMF
Mediation must correlate IVR-CDR to OCDR/TCDR to avoid double billing - IVR leg is not billable alone, only part of main call.
Our mediation: IVR-CDR detected via Call-ID + ICID + MRF correlation - merged to 1 billable, not 2.

Call Flow Example

MO -> P-CSCF -> S-CSCF -> AS -> MRFC
MRFC -> MRFP - INVITE - announcement
MRFP -> UE - plays: "Your balance is low"
UE -> DTMF - 1 for top-up
MRFP -> MRFC -> AS -> OCS - top-up
MRF-CDR: Call-ID=a1b2c3d4 - prompt=balance_low - duration=8s - result=played
S-CSCF -> OCDR - MO - Call-ID=a1b2c3d4 - ICID=1234
[MEDIATION] IVR-CDR + OCDR - same Call-ID - merged - 1 billable

Phone menu announcements are linked to main call via Call-ID to single record./.

Menu Without Voice Connection - How It Works

Menu System in Both Locations

Yes - both private cores have IVR - MRF
Finland private core - MRF - MRFC + MRFP - online
Thailand private core - MRF - MRFC + MRFP - online
Both generate IMS-CDR - MRF-CDR - IVR-CDR even for unanswered calls.

How it works for unanswered call with graphical call-center
Normal IVR: voice media - early media - plays announcement - needs RTP - voice connection early.
Your case: graphical without final voice connect - this is possible in IMS 5G via:
- Early media - 183 Session Progress - SDP - plays announcement before answer - still creates IMS-CDR with no answer flag
- Enriched Calling - GSMA - visual IVR - data channel over IMS - shows menu on handset screen - no voice RTP needed
- USSI - USSD over IMS - USSD-like menu over SIP - graphical call-center menu - without voice
- HTTP push via IMS AS - call-center features via data - shown as native UI

Result: Call arrives - S-CSCF triggers IVR AS - AS triggers MRF - MRF sends graphical menu via data - UE shows buttons - user selects - AS handles logic - call may never get 200 OK voice connect - but IMS-CDR created with cause - no answer - service triggered.
Perfect : Yes you have it - both sites - IMS-CDR created even without final voice - graphical features directly to handset.

Call Flow - Menu Without Voice Answer

1. MO -> P-CSCF Finland - INVITE
2. S-CSCF -> IVR AS - trigger - unanswered handling
3. IVR AS -> MRFC -> MRFP - request graphical menu
4. MRFP -> UE - data channel - visual menu - "Press 1 for sales"
5. UE -> AS - HTTP - user pressed 1 - no RTP yet
6. AS -> CRM - call-center logic - logs
7. AS -> S-CSCF - 480 Temporarily Unavailable or 302 Moved
8. OCDR created - MO - Call-ID=a1b2 - cause=unanswered - IVR used
9. MRF-CDR created - graphical - menu shown - no voice connect
10. Mediation: OCDR + MRF-CDR - same Call-ID - 1 record - correct - not billable voice, billable service if needed

System creates call record even when call is not answered. - just: graphical menu without voice - yes possible - creates IMS-CDR even if call never answered for call-center.

How Phone Menu Works During a Call

Menu on phone screen - billing, support, account - without needing voice connection

IMS Data Channel Architecture Technical Overview Visual IVR

How It Works

Left - UE / DCMTSI - Smartphone
- 5G phone - VoNR voice via IMS - parallel RTCDataChannel
- Visual IVR Customer Service - menu on screen: Billing & Payments, Technical Support, Account Information, Talk to Agent
- Not audio only - graphical buttons directly on handset - no need for voice connect to show menu
- RTCDataChannel Client - data tunnel for visual menu

Middle - IMS CORE - 3GPP IMS Core
- CSCF - Call Session Control Function - P/I/S-CSCF - SIP routing
- DCSF - Data Channel Signalling Function - handshake for data channel - SIP signalling
- DCMF - Data Channel Media Function - media for data channel - secured data tunnel
- DC Application Server - Visual IVR - logic - service / logic - handles menu, routes to billing or agent
- Call Flow: SIP / SIP INVITE from UE -> DCSF -> DCMF -> DC App Server
- Data Channel: RTCDataChannel / User Data parallel to voice
- DC establishment / control via SIP signalling
- DataChannel / App Logic back to UE

Right - Charging & Mediation - CHF / CDR
- Data Channel Secured Data Tunnel -> CDR Mediation
- Charging Event - Diameter / Rf interface -> Charging Database - CHF / Charging Function - CDR Store
- Billing System / BSS gets CDR - even if call never gets voice 200 OK - visual IVR still charged as service if needed
- This is exactly the graphical without voice connect you asked about

Why This Matters

You have this in both private cores
- Finland HPLMN - IMS Core with DCSF/DCMF - Visual IVR AS online
- Thailand VPLMN - IMS Core with DCSF/DCMF - Visual IVR AS online
- Both generate IMS-CDR even for unanswered visual IVR

How it solves the unanswered call-center problem
Customer calls customer service - no agent free - instead of busy tone:
1. S-CSCF triggers Visual IVR AS
2. DCSF establishes data channel - secured tunnel
3. DCMF provides media function for data
4. DC App Server pushes graphical menu to UE - "Billing, Support, Account, Talk to Agent"
5. UE shows menu - no voice RTP yet - user taps
6. Charging Event -> CHF -> CDR created - service used
7. If user taps Talk to Agent and agent free -> voice connect 200 OK -> OCDR + MRF-CDR + visual IVR CDR correlated
8. If user hangs after menu - no voice connect - but CDR still created for service - correct billing

This is 3GPP TS 24.554 compliant - DCMTSI = Data Channel Media Transport for IMS - 5G access via gNB

For mediation:
We correlate: SIP Call-ID + DCSF session + DCMF tunnel + DC App Server logic + CHF event
Result: 1 billable record - whether voice connected or only graphical - 0 percent leakage for call-center.

KEY: 5G access via gNB (not shown) - DCMTSI = Data Channel Media Transport for IMS - 3GPP TS 24.554 compliant
ARCHITECTURE: Smartphone establishes VoNR voice via IMS, while parallel RTCDataChannel is established through DCSF/DCMF to Visual IVR App Server for interactive menu data - Charging events sent to CHF for CDR creation
Architecture: Phone establishes voice via IMS, while parallel data channel is established for interactive menu data. Charging events sent for record creation.

Old Systems and New Systems - What Changed

Old Service Management - What It Was

What it was:
SMAP - SS7 - INAP between SCF - Service Control Function - and SDF - Service Data Function - and SMF - Service Management Function - for 2G/3G IN - manages prepaid profiles, number translation, VPN.

Is there still SMAP today?
In pure 5G SA: No SS7 SMAP. Replaced by:
- Nchf - CHF interface - charging
- Nudr - UDR - Unified Data Repository - subscriber data
- CAP over IP - Camel Application Part over IP - for interworking with legacy
- REST API - service management - modern SMI

But we still support SMAP interworking
When Finland HPLMN roams to Thailand VPLMN with legacy 2G/3G fallback or VoLTE to 5G - SMAP translation needed for prepaid profile sync.
Our mediation: SMAP CDR translated to OCS event - correlated via IMSI + MSISDN + time - merged to 1 billable.
Status: SMAP legacy, but still required for S8HR to legacy - we handle it.

Service Management Interface - Then and Now

What it was:
SMI - Interface between SMF - Service Management Function - and SCF - Service Control Function - to create and manage IN services - provisioning, activation, deactivation.
SS7 - X.25 in 90s, then IP.

What it is today in 5G SA
SMI is now:
- OAM API - Operations and Maintenance - REST - provisioning
- N33 - CAP - Charging - rating table updates
- Nudm - UDM - subscriber provisioning
- GitOps - service logic deployment to IMS AS

Mediation relevance
When SMI updates rating table mid-call - e.g. promo changes from 0.12 to 0.08 EUR/min - OCS must use correct rate per time slice.
Our mediation: SMI log - timestamp - rating version - correlated to OCDR/TCDR time stamps - rating applied per slice - TAP3 split when needed.

Status: SMI not SS7 anymore - REST API - but logic still for accurate billing. We log it.

Why Operators Lose Money

The Real Problem

Your customer travels - Finland to Thailand - watches IPTV
Customer has DNA reissudata 19.90 EUR - promised data free up to limit - e.g. 10 GB.

In Thailand VPLMN - customer watches IPTV movies - 2-3 long movies - e.g. 2000 MB = 2 GB.
VPLMN operator records data usage live.

But HPLMN home operator gets the bill with delay - up to 4 hours
VPLMN sends charging data to HPLMN via TAP - delay 2-4 hours is common.
HPLMN cannot cut the data session in time - OCS does not know usage yet.

Result - loss:
- Customer watches free - within 19.90 EUR promise - cannot be charged extra
- HPLMN must still pay VPLMN interoperator - e.g. 2000 MB at wholesale price
- If wholesale is e.g. 0.50 EUR/MB, 2000 MB = 1000 EUR loss for 19.90 EUR package
- This happens many times - IPTV, streaming, tethering

The FIN Solution:
Real-time correlation OCDR + TCDR via SEPP N32-f - Finland and Thailand private cores online - we see usage within seconds, not 4 hours - OCS can cut or throttle in time - 0 percent leakage for operators.

Example With Numbers

Customer: Finnish - HPLMN Finland - package 19.90 EUR - 10 GB roaming
Location: Thailand VPLMN
Activity: Watches 3 IPTV movies - 2 hours each - total 6 hours
Data: 2000 MB = 2 GB - HD IPTV

VPLMN records: 2000 MB
TAP file sent to HPLMN: after 4 hours
HPLMN OCS sees: after 4 hours - too late
Customer billed: 19.90 EUR only - promise
HPLMN pays VPLMN: 2000 MB x wholesale - e.g. 1 EUR/MB = 2000 EUR
Loss: 2000 - 19.90 = 1980.10 EUR loss on one customer

With The FIN real-time:
VPLMN TCDR -> mediation within seconds
OCDR + TCDR correlated -> OCS knows after 100 MB
OCS action: throttle to 1 Mbps or cut - within minutes
Loss: max 100 MB - not 2000 MB
Saving: ~95 percent less loss

Our Solution - Delay

Our solution makes this delay almost totally obsolete - most of cases less than a second - or even 2 milliseconds and maximum delay - case by case is 15 minutes.

This problem has been existing for more than 25 years now - and our solution is finally solving this problem for now and for the future - even 6G cases.