Hi Russell, this was an amazing introduction to IMS. The way you've explained different node functionalities is brilliant! Thanks a lot for your effort. :)
Hello Russell, Thanks for making this video. I want to let you know that I aced an interview for a new job solely based on the knowledge I gained from this video which I could use to build on the expertise that I already have. I want to point out a mistake in your video. I think you should not use ATCF/ATGW the way you are showing in this diagram, A better node to show at that location is SBC-Session Border Controller. ATCF is exclusively used for SRVCC functionality which is used when you want to do a handover from an IMS domain to a CSFB domain. In fact, ATCF for SRVCC is only used when it is Rel 10 implementation. For Rel 9 implementation of SRVCC does not use ATCF. Keep up the good work and thanks again.
jyotiroby Hi jyotiroby, I'm glad that you brought up the access gateway and control elements. To be honest, when I made that video and put together the pictures for it, I changed the name of ATCF/ATGW back and forth SOOO many times! At around the 15:45 mark when you hear me say "the access........ side", that was me resisting from breaking out into a rant about all the different acronyms there. To use the completely correct, formal 3GPP terminology there I should have referred to them as "IMS-ALG" for control and "IMS-AGW" for the media part, meanwhile to use common terminology I could also have used A-SBC or jsut SBC. I settled on ATCG/ATGW is for a few reasons. First, the most common audience for the video is likely operators or vendors interested in VoLTE as opposed to IMS specifically, and of those operators in most cases they would likely be deploying eSRVCC, for which the concept of access transfer in IMS is a dominant part of the call flows. So in short, since of all the terms I could have used I figured ATCF and ATGW would be the more common, and since I wanted to resist digging into any piece too deeply (keeping the ~30 minute/video goal), I drew them the way I *thought* most people would see it in their networks.
Anyway, thanks again and I'm glad you liked the video. It wasn't just by the videos that you did well in the interview though - you knew enough to read up on SRVCC to understand the access nodes involved. :)
Hi Russell, This is excellent stuff. It'd suggest the following for your future videos: How important it is for EPC and IMS HSS to converg. Also how the 'concept' of AS have taken away the control from the core network. Also paving way for future application servers. How SIP and Diameter have overtaken as the dominant protocols. Covering SMS, charging, etc. Thanks
Hi nice explanation, but I dont see the actual volte call flow once set up by the IMS, can you specify the voice call flow between two users accessing a single eNodeB base station. Thanks
+Info Online Possibly. Diameter routing and where the industry is going with it is definitely video-worthy, though lately it's just been a time issue for putting something like that together.
Thats exactly the way i was looking for ..breaking the elements and explain its significance ..you definitely saved time ...appreciate your effort here...keep up the good work ..:)
Great video. :) One small correction, in case it hasn't been mentioned already: on the "Roaming" slide, the interface between SGW and PGW is S5, not S8.
alexdimo60 Actually that's not an error - for inter-operator SGW - PGW, the reference point actually is S8, not S5. Please refer to figure 4.2.1-2 of 3GPP TS 23.402 for the definitive source on that but S8 is correct.
Hi Russell, Could you make a session to show they way to move from NGN-softswitch to NGN-IMS. Why do we replace Softswitch by IMS? I have some questions: 1. NGN-Softswitch: I see MGC+MG is core network of NGN, I also see that softswitch is applied in 3G UMTS network. So could you show the different between them? 2. I searched on internet the reason why we replace softswitch by IMS but the answer is not satify me :). Thanks you so much, Trung.
There are a few differences there that I'd highlight: - The IMS architecture is heavily standardized and rigored, whereas the concept of an MGC (or, for that matter, SBG/SBC) is not nearly as much so. - The scope of IMS is much greater than voice service, going so far as to completely isolate telephony as a specific service with its own network element (MMTel/TAS) outside of the IMS Core itself. In contrast, the softswitch concept was originally tailored for VoIP specifically. - The IMS architecture provides consistent standards for inter-carrier, roaming and charging (areas where many operators need to be on the same page), whereas again, the general view of the 'softswitch' is more ambiguous in these areas. Now, these two things aren't necessarily competing technologies either. An MGC that can support SIP and Diameter could potentially serve the logical role of one or more (or even all) elements in the IMS architecture. IMS defines specific functions that need to be performed, not what equipment or platforms need to perform them.
hello , sir i have work on ims related project in my master degree . plz tell me where i gate the information related to paging in lte ims for cs and ps.
Hello, which book or resource would you recommend for some one who is well verse in IP network (in between CCNP-CCIE level) with bare basics in telcomm/PSTN/GSM(theoretical) and VOIP in general. what do you think of the book "the ip multimedia subsytem (IMS)" by travis russell. would you recommend getting it?
From a Cisco background, the first thing I would say (if you haven't already realized) is that there really isn't an equivalent to a "CCNA of telecom" in this part of the industry. For VoIP and SIP specifically there are courses you can take, some of which are reputable (eg: SIP School). For books, I haven't read that one but to be honest most of the ones I've picked up just read like a copy&paste of the whitepapers they are describing. Most authors of these materials seem to write like engineers rather than as educators, where the approach is just to describe a single, virticle architecute with no context to it, in such a way that it's difficult to relate the book to practical reality of the industry. One of the more approachable sources for a lot within wireless specifically would be the GSMA. They take the raw standards and develope service profiles tailored to practical use-cases of a given technology, referencing the raw whitepaper material when needed. It's not really tailored for "training", but it's one layer higher up than raw whitepapers themselves. For example, GSMA's profile guide for Voice/SMS over LTE, which goes over a lot of the practical use of IMS: www.gsma.com/newsroom/wp-content/uploads/IR.92-v9.0.pdf Now, for myself I usually learn through the 3GPP whitepapers themselves because it's gap-free, and because it is terminology that transcends vendors so it's the important "language" to learn. If you're going to do that, start with the high-level architecture papers (namely the 23.xxx series standards), and follow the referrals within it as required to drill down to things in as much detail as needed. For example, this is the IMS architecture whitepaper (TS 23.228): www.etsi.org/deliver/etsi_ts/123200_123299/123228/13.06.00_60/ts_123228v130600p.pdf That maps out into more specific papers, such as the SIP profile spec for IMS, which is also one of the "key" standards for IMS telephony: www.etsi.org/deliver/etsi_ts/124200_124299/124229/13.06.00_60/ts_124229v130600p.pdf Anyway, I think it depends on how you learn. The whitepapers can be daunting since it's the equivalent of learning WIFI by reading 802.11 itself, but other than the high-level RUclips video intros like this one it's hard to find any good materials to fill the gab in between those two extremes.
Thanks for the swift response, i appreciate your input. And i do understand what you are trying to say. During my final year in Engineering(electronics and Communication) i had "Computer Communication Network" and "Mobile communication system" as core subjects, i still remember how different Networking means in academics(atleast in India) and in cisco world since i already did CCNA course at the time. And the books( Andrew S. Tanenbaum and Behrouz A. Forouzan, former was way over top) i guess where just theoretical perspective and lack any practical significances when it comes to implementation in real world. Thing is, as you mention whitepapers are probably best way to understand technology from ground up, but it need lot of time and devotion. I might get an opportunity to work in IMS/VoLTE/iptv testing role and need to get up to speed with those system. So i guess video tutorial is very handy because i could just watch it during daily commute on public transport. Thank you for providing those links, I'll have to check it. Do you think CCNA/CCNP voice might be good stop gap solution? I already have video material for those.
For CCNA/CCNP Voice, their focus is really on Cisco's product line for enterprise VoIP (CUCM, Unity, etc.), as opposed to telephony theory in general. At least for the CCNA version of it, you learn how to configure call manager to provision a VoIP phone, how to troubleshoot its configuration, and how to set up the underlying IP network, but you don't really learn much there about how SIP signaling works. I'm not sure what type of testing role it would be, but one skillset which I'd call invaluable in telecom testing as well as operations in most contexts is protocol analysis, whether it's in wireshark or proprietary tools. If you develop a strong ability to read the packets themselves and trace them out to the failure points in call flows, you'll be a great asset to any operations team whether it's in EPC, IMS or traditional telecom. It's a skill that transcends vendors, protocols and UIs, and one which is challenging enough to be hard to find in high doses.
I stumbled across this IMS video. The information is good and I lie the presentation. I was going to send an InMessage but I'm too cheap to upgrade my account. My question to you is, have you worked with a specific vendor? Just curious.
I have experience with different vendors, depending on which part of the architecture. I do try to stay away from vendor-specific topics here, though. That's in part because I don't want to show any bias for or against any vendors I've work with, but also because as a public forum I need to be respectful of various NDA's. Personally, what I would love to see happen is for vendors to open up their product documentation to the public, so as to make these kinds of video series free to compare different ways that these logical architectures can be realized rather than only being able to explain the logical architecture itself. As it is, too much of the real-world practice of IMS design and operation is protected, other than what can be gleaned from GSMA guidelines and the raw 3GPP whitepapers themselves.
Interesting. In my position I tap Ethernet networks and create rules for forwarding specific traffic to tools. Some traffic is "unreachable" for me as it occurs across a back plane or between processes. I asked about your vendor experience because I was curious about E/// and Nokia IMS offerings. As you pointed out in the presentation I watched BGCF would probably not be deconstructed to individual hardware. I was curious if you were familiar with these products in particular. Regards, Dale
Ah, I see. I'm familiar with both, though for setting up a tap infrastructure for an IMS network there are going to be at least two significant challenges regardless of vendor. The first is, as you point out, many of these logical functions would never leave a single "box" in almost any practical deployment. The second, and perhaps even greater challenge, is the NFV movement of telecom and the cloud computing models that the industry is moving toward, because in such models the logical architecture becomes very dynamic from the perspective of the physical network interfaces being tapped, where east/west traffic becomes increasingly internal to a "box" even across different vendor products. Software-based network taps, for capturing traffic within (for example) an Openstack or VMWare cloud environment, is probably going to be the future in my opinion, just because of the dynamic, software-defined nature of the envisioned future architectures, where the specific physical wires to tap become so dynamic if they do exist at all. An adaptive, software-defined tap network, ideally built into the VM management layer of the cloud architecture (eg: as a Neutron plugin in the case of Openstack), is probably what will end up being required although at the moment that's just my opinion. Another possibility for what might happen in the future is the development of a standards-based API for requesting/retrieving trace data from 3GPP-defined network functions, whether they exist as their own boxes or not, similar to something like Wireshark's remote capture protocol, or 3GPP's existing TS 32.422. If they took that idea and defined something like an open SOAP interface for operators to make API calls to various network functions, with a separate (virtual) network used to carry replicated data based on those calls, across all relevant 3GPP-defined network functions, that would be in-line with the future NFV model and I think it would provide great flexibilty to probe vendors. Much of that is just theory right now though. Specific solutions to these kinds of problems in today's practical deployments are exactly the kinds of topics I can't really bring up in public forums, but I would say if you're confined to a physical tap network design, much will depend on what does or does not leave a physical server bay, what does or does not leave a cabinet, and what form the data appears in when it's intra-vendor east/west signaling, where standards-conformance is not necessarily required for the actual service architecture.
Wow, you've given be a lot to think about. Though I can tell you Gigamon does have a Virtual Tap and is deployed in one large cloud vendor (I'm not sure I can say who yet). The challenge with Virtual Taps in vendor equipment would be vendors refusing to allow outside applications within their equipment. So far I have seen NFV deployments where COTS hardware hosts a single logical application, not multi-tenant or spanning hardware. A third party app would be viewed as a source of instability and a threat to business. I worked for ALU and the thought of 3rd party apps on ALU equipment gives me the shivers. I *think* I understand SOAP as nothing more than html based requests and responses between machines. So far, assuming my model is correct, I am disappointed by the length of time a request/reply occurs. Anyway, thank you. Now I have a little more grist for the mill ... Happy New Year.
To your shivers, I think the answer has got to be a trusted/reliable quota system in the cloud management layer of the architecture. As long as the mission is to have a cloud computing model where you have pooled hardware resources, and a full abstraction between "equipment" and the applications that are running on them, we just need that model to work well enough and for long enough for confidence to grow and for the shivers to subside. :) For the SOAP question, yes, it would be an HTTP GET/OK exchange similar to Openstack's own API's. The advantage to that type of trace method is that it would be able to be granular to the 3GPP-defined nodes and call flows, making it operationally useful for various types of troubleshooting. The downside is that it would require "smarts" on the 3GPP functions to intelligently forward specific types of flows to a trace interface, which is why I think there will still always be a need for a low-level trace, say from the cloud layer. For low level tracing across the cloud, transcending 3GPP-defined functions, we really just need a much, much better Neutron-plugin for virtual network tapping than what the existing OVS plug-in provides today. For what Gigamon had presented in the "TaaS" presentation with Ericsson a few years ago, something that can follow the Nova migrations and Neutron network movements to keep tracing an instance as it moves, or to build taps as NFV orchestration grows it, plus the ability to apply more than interface-level capture filters on the interfaces being tapped... I think those kinds of features would really make TaaS light up in terms of value. *And* that's probably not going to be possible unless the feature is Neutron-aware, which means it needs to be part of the Openstack cloud layer and cannot really be its own NFV application.
+Russell DeLong HI Russell..I am looking for pictures you are narrating too about the telecom architecture and how exactly the services work in telecom industry..
It's good to go through your video. I thought network would be complex , but it is more complex than I expected. Thanks for sharing the knowledge. Probably I need to go through your channel about telecom functionality to explore more.
Hi Russell, this was an amazing introduction to IMS. The way you've explained different node functionalities is brilliant! Thanks a lot for your effort. :)
Hello Russell, Thanks for making this video. I want to let you know that I aced an interview for a new job solely based on the knowledge I gained from this video which I could use to build on the expertise that I already have. I want to point out a mistake in your video. I think you should not use ATCF/ATGW the way you are showing in this diagram, A better node to show at that location is SBC-Session Border Controller. ATCF is exclusively used for SRVCC functionality which is used when you want to do a handover from an IMS domain to a CSFB domain. In fact, ATCF for SRVCC is only used when it is Rel 10 implementation. For Rel 9 implementation of SRVCC does not use ATCF.
Keep up the good work and thanks again.
jyotiroby
Hi jyotiroby,
I'm glad that you brought up the access gateway and control elements. To be honest, when I made that video and put together the pictures for it, I changed the name of ATCF/ATGW back and forth SOOO many times! At around the 15:45 mark when you hear me say "the access........ side", that was me resisting from breaking out into a rant about all the different acronyms there.
To use the completely correct, formal 3GPP terminology there I should have referred to them as "IMS-ALG" for control and "IMS-AGW" for the media part, meanwhile to use common terminology I could also have used A-SBC or jsut SBC.
I settled on ATCG/ATGW is for a few reasons. First, the most common audience for the video is likely operators or vendors interested in VoLTE as opposed to IMS specifically, and of those operators in most cases they would likely be deploying eSRVCC, for which the concept of access transfer in IMS is a dominant part of the call flows.
So in short, since of all the terms I could have used I figured ATCF and ATGW would be the more common, and since I wanted to resist digging into any piece too deeply (keeping the ~30 minute/video goal), I drew them the way I *thought* most people would see it in their networks.
Anyway, thanks again and I'm glad you liked the video.
It wasn't just by the videos that you did well in the interview though - you knew enough to read up on SRVCC to understand the access nodes involved. :)
This video is brilliant! Good amount of detail and well explained. Thank you Russell.
Interesting approach and great intro to IMS and VoLTE. It changed the way how I look at Standards and networks. Thanks a Million.
Been working with (some parts of) IMS for a while now, but finally everything makes sense. Great video. Thanks a TON!
You were right, there really isn't any 'approachable' material on this topic. i needed some squares and lines. :-)
Thanks for doing all this work!
Very Good tutorial, Excellent Break down, Loved it . Looking forward for more tutorials Ahead..
Hey Russell, Thank you very much. You simplified IMS in this Video. It's very approachable and easy to follow.
nice presentation . I like the way you explode things to make it simpler.
Well done Russell. Keep it up. Very informative series.
I really liked the way you divided the big 3GPP diagram into small simple diagrams ... That helped me a lot ... Thanks :)
Hi Russell,
This is excellent stuff. It'd suggest the following for your future videos:
How important it is for EPC and IMS HSS to converg.
Also how the 'concept' of AS have taken away the control from the core network. Also paving way for future application servers.
How SIP and Diameter have overtaken as the dominant protocols. Covering SMS, charging, etc.
Thanks
Hi nice explanation, but I dont see the actual volte call flow once set up by the IMS, can you specify the voice call flow between two users accessing a single eNodeB base station. Thanks
Hey russel really great explanations..Can you please start the video to explain about 5G concepts.
Hello Russell, thank you for these videos! Do you have any plans to do video on Diameter Traffic?
+Info Online
Possibly. Diameter routing and where the industry is going with it is definitely video-worthy, though lately it's just been a time issue for putting something like that together.
Thats exactly the way i was looking for ..breaking the elements and explain its significance ..you definitely saved time ...appreciate your effort here...keep up the good work ..:)
Just finished the entire series. So helpful thank you so much for the Videos.
bashywash is volte based job is also involves coding?
Hi Russell, thanks a lot for your work. Really helps a lot. When are your Diameter videos coming? Have been waiting for them for a long time now :)
Great video. :)
One small correction, in case it hasn't been mentioned already: on the "Roaming" slide, the interface between SGW and PGW is S5, not S8.
alexdimo60
Actually that's not an error - for inter-operator SGW - PGW, the reference point actually is S8, not S5.
Please refer to figure 4.2.1-2 of 3GPP TS 23.402 for the definitive source on that but S8 is correct.
excellent material and presentation flow. Thanks Russell
well this is the best video for explaining IMS stuff
Hi Russell, Could you make a session to show they way to move from NGN-softswitch to NGN-IMS. Why do we replace Softswitch by IMS?
I have some questions:
1. NGN-Softswitch: I see MGC+MG is core network of NGN, I also see that softswitch is applied in 3G UMTS network. So could you show the different between them?
2. I searched on internet the reason why we replace softswitch by IMS but the answer is not satify me :).
Thanks you so much,
Trung.
There are a few differences there that I'd highlight:
- The IMS architecture is heavily standardized and rigored, whereas the concept of an MGC (or, for that matter, SBG/SBC) is not nearly as much so.
- The scope of IMS is much greater than voice service, going so far as to completely isolate telephony as a specific service with its own network element (MMTel/TAS) outside of the IMS Core itself. In contrast, the softswitch concept was originally tailored for VoIP specifically.
- The IMS architecture provides consistent standards for inter-carrier, roaming and charging (areas where many operators need to be on the same page), whereas again, the general view of the 'softswitch' is more ambiguous in these areas.
Now, these two things aren't necessarily competing technologies either. An MGC that can support SIP and Diameter could potentially serve the logical role of one or more (or even all) elements in the IMS architecture. IMS defines specific functions that need to be performed, not what equipment or platforms need to perform them.
hello , sir i have work on ims related project in my master degree . plz tell me where i gate the information related to paging in lte ims for cs and ps.
Hello,
which book or resource would you recommend for some one who is well verse in IP network (in between CCNP-CCIE level) with bare basics in telcomm/PSTN/GSM(theoretical) and VOIP in general.
what do you think of the book "the ip multimedia subsytem (IMS)" by travis russell. would you recommend getting it?
From a Cisco background, the first thing I would say (if you haven't already realized) is that there really isn't an equivalent to a "CCNA of telecom" in this part of the industry. For VoIP and SIP specifically there are courses you can take, some of which are reputable (eg: SIP School).
For books, I haven't read that one but to be honest most of the ones I've picked up just read like a copy&paste of the whitepapers they are describing. Most authors of these materials seem to write like engineers rather than as educators, where the approach is just to describe a single, virticle architecute with no context to it, in such a way that it's difficult to relate the book to practical reality of the industry.
One of the more approachable sources for a lot within wireless specifically would be the GSMA. They take the raw standards and develope service profiles tailored to practical use-cases of a given technology, referencing the raw whitepaper material when needed. It's not really tailored for "training", but it's one layer higher up than raw whitepapers themselves.
For example, GSMA's profile guide for Voice/SMS over LTE, which goes over a lot of the practical use of IMS:
www.gsma.com/newsroom/wp-content/uploads/IR.92-v9.0.pdf
Now, for myself I usually learn through the 3GPP whitepapers themselves because it's gap-free, and because it is terminology that transcends vendors so it's the important "language" to learn. If you're going to do that, start with the high-level architecture papers (namely the 23.xxx series standards), and follow the referrals within it as required to drill down to things in as much detail as needed.
For example, this is the IMS architecture whitepaper (TS 23.228):
www.etsi.org/deliver/etsi_ts/123200_123299/123228/13.06.00_60/ts_123228v130600p.pdf
That maps out into more specific papers, such as the SIP profile spec for IMS, which is also one of the "key" standards for IMS telephony:
www.etsi.org/deliver/etsi_ts/124200_124299/124229/13.06.00_60/ts_124229v130600p.pdf
Anyway, I think it depends on how you learn. The whitepapers can be daunting since it's the equivalent of learning WIFI by reading 802.11 itself, but other than the high-level RUclips video intros like this one it's hard to find any good materials to fill the gab in between those two extremes.
Thanks for the swift response, i appreciate your input.
And i do understand what you are trying to say. During my final year in Engineering(electronics and Communication) i had "Computer Communication Network" and "Mobile communication system" as core subjects, i still remember how different Networking means in academics(atleast in India) and in cisco world since i already did CCNA course at the time. And the books( Andrew S. Tanenbaum and Behrouz A. Forouzan, former was way over top) i guess where just theoretical perspective and lack any practical significances when it comes to implementation in real world.
Thing is, as you mention whitepapers are probably best way to understand technology from ground up, but it need lot of time and devotion. I might get an opportunity to work in IMS/VoLTE/iptv testing role and need to get up to speed with those system. So i guess video tutorial is very handy because i could just watch it during daily commute on public transport.
Thank you for providing those links, I'll have to check it.
Do you think CCNA/CCNP voice might be good stop gap solution? I already have video material for those.
For CCNA/CCNP Voice, their focus is really on Cisco's product line for enterprise VoIP (CUCM, Unity, etc.), as opposed to telephony theory in general. At least for the CCNA version of it, you learn how to configure call manager to provision a VoIP phone, how to troubleshoot its configuration, and how to set up the underlying IP network, but you don't really learn much there about how SIP signaling works.
I'm not sure what type of testing role it would be, but one skillset which I'd call invaluable in telecom testing as well as operations in most contexts is protocol analysis, whether it's in wireshark or proprietary tools. If you develop a strong ability to read the packets themselves and trace them out to the failure points in call flows, you'll be a great asset to any operations team whether it's in EPC, IMS or traditional telecom. It's a skill that transcends vendors, protocols and UIs, and one which is challenging enough to be hard to find in high doses.
thanks Russell simply explained
Kindly do more video on this please
Hi
Russell DeLong
,I need some info
What about the feature as IMS Engineer Fresher.
I stumbled across this IMS video. The information is good and I lie the presentation. I was going to send an InMessage but I'm too cheap to upgrade my account.
My question to you is, have you worked with a specific vendor? Just curious.
I have experience with different vendors, depending on which part of the architecture.
I do try to stay away from vendor-specific topics here, though. That's in part because I don't want to show any bias for or against any vendors I've work with, but also because as a public forum I need to be respectful of various NDA's.
Personally, what I would love to see happen is for vendors to open up their product documentation to the public, so as to make these kinds of video series free to compare different ways that these logical architectures can be realized rather than only being able to explain the logical architecture itself. As it is, too much of the real-world practice of IMS design and operation is protected, other than what can be gleaned from GSMA guidelines and the raw 3GPP whitepapers themselves.
Interesting. In my position I tap Ethernet networks and create rules for forwarding specific traffic to tools. Some traffic is "unreachable" for me as it occurs across a back plane or between processes. I asked about your vendor experience because I was curious about E/// and Nokia IMS offerings. As you pointed out in the presentation I watched BGCF would probably not be deconstructed to individual hardware. I was curious if you were familiar with these products in particular.
Regards,
Dale
Ah, I see.
I'm familiar with both, though for setting up a tap infrastructure for an IMS network there are going to be at least two significant challenges regardless of vendor. The first is, as you point out, many of these logical functions would never leave a single "box" in almost any practical deployment. The second, and perhaps even greater challenge, is the NFV movement of telecom and the cloud computing models that the industry is moving toward, because in such models the logical architecture becomes very dynamic from the perspective of the physical network interfaces being tapped, where east/west traffic becomes increasingly internal to a "box" even across different vendor products.
Software-based network taps, for capturing traffic within (for example) an Openstack or VMWare cloud environment, is probably going to be the future in my opinion, just because of the dynamic, software-defined nature of the envisioned future architectures, where the specific physical wires to tap become so dynamic if they do exist at all. An adaptive, software-defined tap network, ideally built into the VM management layer of the cloud architecture (eg: as a Neutron plugin in the case of Openstack), is probably what will end up being required although at the moment that's just my opinion.
Another possibility for what might happen in the future is the development of a standards-based API for requesting/retrieving trace data from 3GPP-defined network functions, whether they exist as their own boxes or not, similar to something like Wireshark's remote capture protocol, or 3GPP's existing TS 32.422. If they took that idea and defined something like an open SOAP interface for operators to make API calls to various network functions, with a separate (virtual) network used to carry replicated data based on those calls, across all relevant 3GPP-defined network functions, that would be in-line with the future NFV model and I think it would provide great flexibilty to probe vendors.
Much of that is just theory right now though. Specific solutions to these kinds of problems in today's practical deployments are exactly the kinds of topics I can't really bring up in public forums, but I would say if you're confined to a physical tap network design, much will depend on what does or does not leave a physical server bay, what does or does not leave a cabinet, and what form the data appears in when it's intra-vendor east/west signaling, where standards-conformance is not necessarily required for the actual service architecture.
Wow, you've given be a lot to think about. Though I can tell you Gigamon does have a Virtual Tap and is deployed in one large cloud vendor (I'm not sure I can say who yet). The challenge with Virtual Taps in vendor equipment would be vendors refusing to allow outside applications within their equipment. So far I have seen NFV deployments where COTS hardware hosts a single logical application, not multi-tenant or spanning hardware. A third party app would be viewed as a source of instability and a threat to business. I worked for ALU and the thought of 3rd party apps on ALU equipment gives me the shivers. I *think* I understand SOAP as nothing more than html based requests and responses between machines. So far, assuming my model is correct, I am disappointed by the length of time a request/reply occurs. Anyway, thank you. Now I have a little more grist for the mill ... Happy New Year.
To your shivers, I think the answer has got to be a trusted/reliable quota system in the cloud management layer of the architecture. As long as the mission is to have a cloud computing model where you have pooled hardware resources, and a full abstraction between "equipment" and the applications that are running on them, we just need that model to work well enough and for long enough for confidence to grow and for the shivers to subside. :)
For the SOAP question, yes, it would be an HTTP GET/OK exchange similar to Openstack's own API's. The advantage to that type of trace method is that it would be able to be granular to the 3GPP-defined nodes and call flows, making it operationally useful for various types of troubleshooting. The downside is that it would require "smarts" on the 3GPP functions to intelligently forward specific types of flows to a trace interface, which is why I think there will still always be a need for a low-level trace, say from the cloud layer.
For low level tracing across the cloud, transcending 3GPP-defined functions, we really just need a much, much better Neutron-plugin for virtual network tapping than what the existing OVS plug-in provides today. For what Gigamon had presented in the "TaaS" presentation with Ericsson a few years ago, something that can follow the Nova migrations and Neutron network movements to keep tracing an instance as it moves, or to build taps as NFV orchestration grows it, plus the ability to apply more than interface-level capture filters on the interfaces being tapped... I think those kinds of features would really make TaaS light up in terms of value. *And* that's probably not going to be possible unless the feature is Neutron-aware, which means it needs to be part of the Openstack cloud layer and cannot really be its own NFV application.
Do you know Interface between SBC and IM-MGW.
Great explanation. please consider making a video of IP-SM Gateway. there are very few good explanations, and absolutely no good videos on youtube
Good one. Thanks for sharing your knowledge and explaining it very well.
Hi Russell,
Thanks for sharing the video. Can you share us the excel sheet too..
+sathish p
What excel sheet?
+Russell DeLong HI Russell..I am looking for pictures you are narrating too about the telecom architecture and how exactly the services work in telecom industry..
It's good to go through your video. I thought network would be complex , but it is more complex than I expected. Thanks for sharing the knowledge. Probably I need to go through your channel about telecom functionality to explore more.
This is very much useful.Thanks a lot.
I got Good learning from this video
Thanks Russell
Ims security???
Very well explained Russell !!!
Hi Russell...this is really useful...
intex aqua ace ko vote keshe kare
Really many thanks for excellent presentation, hope to see more and more and hope for you the best - en cha'a allah
wow this was great...well done , thanks a lot
Hello Russell, Thanks for ur good work on making such video. It is useful !! Thanksss
Thank You Sir for sharing the knowledge! :)
层层推进，神人！
Excellent intro. Thanks
excellent Russel..
very well explained !!
Really great tutorial thank you !
Hi Russell,thanx for sharing this video really helpful it is
I'm loving it !
Fantastic video, Russell. Anyway you can share this OneNote presentation :D
Great video.
thanks for your video
thumb
Nice tutorial.
Thank you very much!. Very clear and well put!. I appreciate it!.