IP Packet switching in Telecom - Part 3

Posted by leopedrini Wednesday, February 15, 2012 10:08:00 AM Categories: Course
Rate this Content 3 Votes

At the end of the precedent article I’ve told you that we’re going to dig a bit deeper into IMS and NGN signaling protocols (all this happens at the application layer of TCP/IP network architecture – see the first article of this series).

 

Note: My blog Smolka et Catervarii (portuguese-only content for the moment)

 

And so we shall do. I must warning you, though: you’d better fasten your seat belts, ‘cause there’s turbulence ahead. Few things can be more intellectually intimidating than the writing style of telecom standards. Truth be told, they’re getting better, but it’s still a hard proposition to read them. Even the pictures can be daunting. So I urge you: don’t let this picture scare you out of reading the rest of this article.

 

 

This picture comes from ITU-T Recommendation Y.2021. Look at the shaded round-cornered rectangle. There’s “core IMS” written on it – and it really is that. But we’re interested in a single entity in there: the Call Session Control Function (CSCF), and it’s relationship with the user equipment (desktop, laptop or handheld computers, smartphones, tablets, whatever) identified by UE in the picture.

Each line connecting entities are called interfaces (formal terminology is: reference points, but doesn’t matter). They’re the depiction of logical relationships between the entities, and each interface uses an application-layer protocol (more than one, sometimes). The signaling interface between CSCF and UE is identified as Gm in the picture. And the application-layer protocols used in the Gm interface are SIP and SDP (I’m not explaining some acronyms ‘cause they’re already explained elsewhere – I really believe that you’re following these articles from the beginning).

And what does CSCF do? It’s the AAA server (and more) that we’ve talked about in the last article. Since it looks that most of TelecomHall readers have a mobile background then we can explain CSCF functionalities this way: it’s a kind of fusion of HLR (Home Location Registry) and AuC (Authentication Center).

But there’s actually three entities called CSCF, differing by a prefix letter: P (proxy); I (interrogating); and S (serving). These three “flavors” of CSCF exist because we’re talking of telecom services here. So there are operator’s own subscribers, and there can be roaming users.

Whatever the user is local or roamer, one of the first things he/she have to do when connecting to the network is making contact with the P-CSCF. Item 5.1.1 of ETSI TS 123 228 offers two alternative methods for P-CSCF discovery. I think that the practical way is combining both:

  • Dynamic Host Configuration Protocol (DHCP, for IPv4 or IPv6 networks) gives the UE the IP address (v4 or v6) of the primary and secondary Dynamic Name System (DNS) servers which are capable of resolving I-CSCF fully-qualified domain name (FQDN) to its IPv4 and/or IPv6 primary and secondary addresses;
  • During initial configuration, or in the ISIM (IMS Subscriber Identification Module – SIM), or even via over-the-air (OTA) procedures, the UE receives the FQDN of the I-CSCF.

The I-CSCF forwards all user requests to the S-CSCF that’s assigned to serve it. If the user is local, then that’s all. If the user is a roamer, then the S-CSCF of the visited network acts as an I-CSCF and forwards all user requests to the S-CSCF of the native network of the user.

To understand the remaining entities in the core IMS we have first to understand that NGN-based services won’t simply kick the present telecom services out of the market. They’ll have to live together, side by side, for a long time yet. So there’s a definite need for NGN and traditional telecom services to interfunction. That is: there should be possible to calls originated in NGN-connected UEs to terminate on common telephony devices, and vice-versa.

Since about ten years ago operators started to substitute traditional telephony switches with softswitches.

A softswitch is a distributed system (logically, and possibly also geographically), and can be built (more or less) with an open architecture. It’s main building blocks are:

  • One Media Gateway Controller (MGC), which handles signaling between the softswitch and the rest of the network elements;
  • One or more Media Gateways (MGs), which make the translation of media streams between different physical interconnections.

The MGC controls the MGs assigned to it through a IP-carried signaling protocol whose specifications are found on ITU-T Reccomendation H.248.1 – Gateway Control Protocol: version 3. The picture below shows how the softswitch elements interconnect with IP and Public Switchet Telephony Network (PSTN) and the signaling protocols used.

 

 

So the Media Gateway Control Function (MGCF) is the IMS element responsible for setting up the Media Gateway which will bridge the IP data stream to a conventional telephony circuit. Every IMS-enabled MGC have an instance of MGCF within it.

And that brings another question: since there can be many instances of MGCF available, in the operator network and in other operator’s networks which are interconnected, which one is the best option to bridge between the NGN and the PSTN for each call? This is the attribution of Breakout Gateway Control Function (BGCF).

Last, but not least, there’s the Multimedia Resources Function Controller (MRFC). Certain application servers (see AS-FE in the picture) need help to deliver services to the UEs. Such help can be:

  • According to ITU-T Recommendation Y.2021 – “Multi-way conference bridges, announcement playback and media transcoding”;
  • According to TSI TS 123 228 – “mixing of incoming media streams (e.g. for multiple parties), media stream source (for multimedia announcements), media stream processing (e.g. audio transcoding, media analysis), floor control (i.e. manage access rights to shared resources in a conferencing environment)”.

Note that MRFC only does control of these activities. The actual execution is handled by Multimedia Resources Function Processors (MRFPs) in ETSI parlance, or Multimedia Resources Processor Functional Entities (MRP-FEs) in ITU-T jargon – both names refer to the same software object.

And something very important to keep in mind: P-CSCF, S/I-CSCF, BGCF, MRFC and MGCF  are logical functions which are implemented in software, so they can exist in one single host machine, or can be distributed among many host machines. Logically it doesn’t matter, but physical implementations of each vendor can vary, and can cast doubts if you’re not aware of this

Now, this is getting a bit longer than I anticipated, so let’s make a break here, and return with the signaling protocols in the next article, ok? I apologize if this is becoming a little too hard to follow, but I really don’t know how to put this in simpler terms.

Au revoir!