TM Forum Community

 View Only
  • 1.  Call Barring A party to B party (based on predefined list)

    Posted Jan 30, 2023 05:37

    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
    ------------------------------


  • 2.  RE: Call Barring A party to B party (based on predefined list)

    TM Forum Member
    Posted Jan 31, 2023 01:47
    Seems to me like a policy controller might be the best place to enforce this, Sheharyar. Or a real time charging system. But it may also depend on the nature of your network (3/4/5G), and your specific network equipment capabilities.
    Billing (not charging) systems don't normally have direct interaction with the network.
    Amdocs and many other vendors offer both policy controllers and online charging systems, I'm sure that vendor solution architects or sales engineers would be happy to advise you further.
    Hope it helps

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: Call Barring A party to B party (based on predefined list)

    Posted Jan 31, 2023 04:23
    Dear Jonathan,

    Thank you for your reply, could you more elaborate on the policy controller? Are you referring to SS7 voice firewall?

    Regards



    ------------------------------
    sheharyar arshad
    TO BE VERIFIED
    ------------------------------



  • 4.  RE: Call Barring A party to B party (based on predefined list)

    TM Forum Member
    Posted Feb 01, 2023 03:44
    Hi - I'm no expert on policy control, it's generally a player in a mobile network (3/4/5G) and is a defined part of 5G architecture. In 3G it was tied to the Sy/Gx/Gy interfaces and so dealt with data not voice. But maybe in 5G it could be used also for voice. Happy to hear from experts in the field, maybe @Vance Shipley can provide additional insights.​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 5.  RE: Call Barring A party to B party (based on predefined list)

    TM Forum Member
    Posted Feb 01, 2023 08:34
    Edited by Vance Shipley Feb 01, 2023 08:48

    These sort of questions are great to illustrate the interactions between domains.

    In the Product domain we could have Product Offerings (PO) which allow, or do not allow, subscribers to call other operator networks, presumably with different Prices (POP). You could control the set of Operators with Characteristics defined in a Product Specification allowing the PO designer flexibility in creating offers. This would be a Product Catalog driven solution as demonstrated in the 5G Chargers Catalyst project.

    In the Service domain we could control the set of Operators with Characteristics defined in a Service Specification. This is a more typical approach than above. Either way a Service Orchestration system shall have to arrange for provisioning towards whatever systems implement the operator barring features.  By modeling as Service Characteristics however we can manage different technology domain implementations consistently.

    In the Resource domain we manage the network functions which implement features such as required here.  You will find that Operator Determined Barring (3GPP TS 22.041) is part of subscriber data held in an HLR, HSS, UDM and transferred to the service nodes where barring occurs.  Subscriber data may be represented in Resource Specifications and captured in Resource Inventory.

    So we could manage this feature using Product, Service and Resource APIs in ODA.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 6.  RE: Call Barring A party to B party (based on predefined list)

    Posted Feb 02, 2023 03:25
    Edited by Konstantin Zayko Feb 02, 2023 03:25

    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.
    ------------------------------



  • 7.  RE: Call Barring A party to B party (based on predefined list)

    TM Forum Member
    Posted Feb 03, 2023 04:52
    Edited by Vance Shipley Feb 03, 2023 05:25
    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
    ------------------------------