If the question is really about solution design for a network service providing advanced features, barring in this case, it brings us to an issue I've worried about a lot.
What
@sheharyar arshad describes is operator specific, custom service logic, the seminal work on which is found in the
Intelligent Network (IN) standards from ITU-T and ETSI and the mobile version from 3GPP
Customized Applications for Mobile network Enhanced Logic (CAMEL). What IN intends is to allow CSPs to
rapidly develop custom services, in house, without requiring changes to the elements of the network. This is accomplished through distributing the control functions from the switching functions. A
Service Logic Execution Environment (SLEE) provides an operator with a platform to run their custom
Service Logic processing Programs (SLP). The SS7 protocol applications INAP and CAP enable extensive control over network elements.
3GPP still maintain the CAMEL specifications although it's technically a 2G technology, although in 4G the IMS reference architecture includes a CAMEL gateway. In theory you can implement an IMS
Application Server (AS) providing arbitrary service logic however, unlike IN, there is no standardization for a SLEE and few if any commercial products. With 5GC we have policy control request triggers, and the
Network Exposure Function (NEF) provides a vector to access many capabilities, but no clear path to achieve what IN did exists.
The business value of enabling rapid development of operator specific services isn't being realized in modern networks. It would be great if a modern SLEE specification would emerge so that CSPs could implement differentiating services without leaning on proprietary, vendor specific, solutions.
To directly answer
@sheharyar arshad's question: it depends on your network. At SigScale we build solutions with all of the above. As other's have suggested, if your services are prepaid an OCS/CCS may be the easiest vector to introduce custom SLPs. We decomposed SigScale OCS to separate, and distribute, the rating and charging functions (RF, ABMF) from the network facing OCF. The OCF is implemented as SLPs on a SLEE providing protocol stacks (SBI, DIAMETER/RADIUS, INAP/CAP) allowing for CSP specific SLPs. If it's not prepaid, another vector may be through custom IWFs (Interworking Functions). A semi-transparent IWF, inserted between network elements. may act as a sort of firewall, filtering and rejecting to provide the barring features you require, but that is the sort of messiness we could avoid if the industry provided a standard solution.
.
------------------------------
Vance Shipley
SigScale
------------------------------
Original Message:
Sent: Feb 02, 2023 03:24
From: Konstantin Zayko
Subject: Call Barring A party to B party (based on predefined list)
Hi Sheharyar,
As colleagues already suggested, answer is heavily dependant on network configuration you're talking about and some more detail on requirements.
The main question - is your requirements on a "per subscriber" base (for some given any "A" number to block "a given set of Operators" on "given schedule")
or it is "per network" - For every calling subscriber to block this set.
If first, than you need to think about implementing this Service in either way. - as Service of blocking calls or you may have it as a service for allowing calls - depending on
number of your subscribers using this feature. As @Vance Shipley suggested - it could be defined on a service or level.
The service itself implementation and provisioning (or fulfilment) scheme itself depends on the network architecture.
in typical 2G/3G SS7 - based environment I would recommend to implement the feature using OCS (Online charging system) SS7 interface - assuming 3GPP CAP is available and users are subscribed. If not - you may choose a way to implement custom Operator Defined Barring (ODB) with help of your MSC/VLR vendor.
in 4/5G IMS-based environment the same could be implemented using Application server (ISC) interface. Once again, depending on capabilities of your network by reusing existing AS (or SCIM) or building an additional one.
If we're talking about second scenario (blocking for any calling subscriber for a whole network) - This could be achieved by configuring traffic routing on your interconnect gateways, by creating specific destination sets (code points, etc... - depending on your vendor) and routing them to an answering machine instead of real interconnect trunks.
------------------------------
Konstantin Zayko
Telecom enterprise solitions architect.
Original Message:
Sent: Jan 30, 2023 00:27
From: sheharyar arshad
Subject: Call Barring A party to B party (based on predefined list)
Dear Experts,
We are seeking some guidance on a requirement to block the calling from A party (Any number ) to B party (OpertaorsMSISDN ) based on the identified list of MSISDN on different time schedule. We would like to know which is the best system to fulfil this requirement (eg converge billing system or HLR etc..)
Regards
#OpenDigitalArchitecture
#General
------------------------------
sheharyar arshad
TO BE VERIFIED
------------------------------