I've just gone through half of the video and already liking it so much! It's way better than reading the boring 3gpp tech specs. Can't thank you enough ☺️
Love it! Can we have a hand-on session on an end-to-end behavrou analysis of and UE when trying to cement the the core network? e.g., UE first connect to gNB, then trying to connect to EMF and NRF what are the exchanged information ? can we see those information in K8S cluster ? Such information and hands on experience will be highly beneficial.
Excellent. Many Thanks as video being very Insight. Pls post more frequent Videos as you have not posted much Videos over the Years. Video on 5G Mobility Management is desired.
Hi Russell, now that 5G is a reality and all the specs are out, any chance you could do an updated video with the actual implementations beyond the white paper concepts.Your explanations normally bring things out very clearly!
So many reasons... To name a few: - SIP allows a single call dialogue to exist simultaneously in a UDP stream and a TCP session, interleaving based on packet size, while also maintaining ordered sequencing requirements between transactions ("CSEQ" being the sequence number). This is just asking for race conditions, and they do happen. For example, in an MMTel-based conference call scenario a REFER and SUBSCRIBE transaction trigger at the same time, where the small UDP-based message happens immediately after the large TCP-based message, but if the small/fast message arrives first at the UAS then you'll get a sequence error. There are solutions for this but SIP creates this possibility in a way that no other signaling protocol does. - SIP is encoded in ASCII, whereas virtually all signalling protocols are encoded in binary ASN.1. From a computing perspective this is very inefficient especially where SIP architectures make such heavy use of proxies, becauase you have systems encoding/decoding in English at every step, instead of binary to machine language. It's also very inefficient from an audit perspective, since binary is far more efficient to store or read. - SIP headers have different ABNF formats called to in different RFCs. For example demarc rules between a URI parameter and a header parameter is ambiguous unless you know that specific header's format. The base structure of an attribute/value pair is normally defined top-down as part of the protocol itself, not at the discretion of the particular attribute. That's wild-wild-west. - SIP gives too many options for things like DTMF (at least three options) and ring tone generation (at least three options). For interworking this leaves some ambiguity on whether the local or far end play ringback, or whether the phone generates its own ringback on signal of "ringing", etc. - SIP has too many options for how to preserve ISUP-equivalent of OCN values (original calling number). The current header "History-Info" competes with the deprecated but widely used "Diversion" header, where in practice systems tend to give up and just always send/read both. - SIP itself has no inherent distinction between "who they say they are" and "who the network says they are". That makes sense for Internet-based "alice calls bob" scenarios (which is what it was built for), but not for telecom environments. Later implementations improved this with the concept of P-Asserted-Identity headers, Privacy headers, etc., but this is not part of the base SIP protocol itself. - SIP's original signaling methods invited "ghost ring" situations because "RINGING" in signaling happens prior to actual media setup completion. The concept of preconditions which already existed in other signaling protocols didn't get written to spec until much later. - SIP has a far greater attack surface to an end-user terminal than any other signaling protocol exposed to end-user equipment. Previous models inherently pigeon-holed the end user through the structure of what binary messages could be accepted (eg: GSM DTAP signaling), and by making the "user to network" protocol fully distinct from the protocol used within the network (GSM DTAP vs ISUP, instead of all being SIP). Because of this, end users of a SIP network have the inherent ability to (for example) pass XML files between each other, or add device/app-specific information to calls. Instead of starting off secure and working up, SIP starts off extremely flexible and you have to tighten it down.
I had to stop myself at some point, but honestly the few good things I can say about SIP are also true of H.323. It's a "signaling protocol" originally written for Internet-based media applications. Telecom has added to it, and improved it to make it more workable, but it was never really fit for the purpose.
Hi! Excellent video. Please do more. This has been outstanding. I have one question though. At the end you mention a reference for people who have difficulty with reading specs, but I cannot understand what it is. At 1:03:15
I was referring to these two places in 3GPP: www.3gpp.org/DynaReport/23-series.htm www.3gpp.org/DynaReport/29-series.htm If you scroll down to the 23.5xx and 29.5xx sections of those two pages, you'll find the architecture and protocol specs respectively, for 5GS.
Thank you for the clarification . Great job on the videos. Ps: I'm also a packet core planner from Brazil. Starting to work on 5g trials in the US. guess I'll be reading a lot of those specs in the near future.
The concept of DHCP, although in actual signaling it would be "PCO Options" as opposed to DHCP attributes and options in an "offer" message. That's not to say you couldn't have a DHCP server being queried by an SMF, but the protocol in use isn't DHCP between the UE and SMF for address assignment.
What are the fundamental difference between a Service Based Architecture and Reference Point Architecture of 5GC? Can you please list down few of them?
They're different ways of illustrating the same thing. The reference point architecture specifically says what NF communicates with what NF for what purpose (with a reference point number, eg: "N26"), whereas the SBA defines more generally what systems exist to be talked to within the ecosystem. When all the systems in the SBA speak the same language (HTTP2/JSON), a common web service can be provided to any client by an NF in concept, so there's no need to draw every possible line between all of them.
That would be: N1 = NAS N2 = NG-AP N3 = GTP-U N4 = HTTP2 N6 is simply the Gi/SGi interface of the 5GS. There's no defined protocol there. In fact, 5GS supports non-IP protocols out of that interface such as Ethernet (whereas EPS only supported IPv4 or IPv6 on SGi interface).
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Last time I have learned EPC,IMS ..now learning 5G ..great lecture ..Many many thanks
I've just gone through half of the video and already liking it so much! It's way better than reading the boring 3gpp tech specs. Can't thank you enough ☺️
Heyy buddy, just checking in on you, are you okay? I love your content. Hands down the best core network content across the whole internet.
I love this, thank you so much for sharing, i am a newbie in this area.
Love it!
Can we have a hand-on session on an end-to-end behavrou analysis of and UE when trying to cement the the core network? e.g., UE first connect to gNB, then trying to connect to EMF and NRF what are the exchanged information ? can we see those information in K8S cluster ?
Such information and hands on experience will be highly beneficial.
Being frustrated reading 3gpp docs.. just before I found this video! Thanks!
Hi Russell, when is your next tutorial coming? Eagerly waiting :)
Thanks for putting this presentation. Very useful, indeed. Looking forward to your next videos.
you are doing great service Russel... Always waiting for your videos and it was after long time :) hope you will put more of 5G...
Thanks, this is a very nice introduction to 5G. Hope you have more videos somewhere :)
Very clearly explained, easy to follow. Thank-you Russell
Excellent. Many Thanks as video being very Insight. Pls post more frequent Videos as you have not posted much Videos over the Years. Video on 5G Mobility Management is desired.
Hi. Great lecture. looking forward for more of such videos. If you don't mind, can you please share the workbook or a pdf version of the same?
Hello Russell, im following ur many videos. Thanks for 5G video. Pls make many video's upon 5G for basics
Hi Russell, now that 5G is a reality and all the specs are out, any chance you could do an updated video with the actual implementations beyond the white paper concepts.Your explanations normally bring things out very clearly!
Simple and great. Appreciate the effort Russell.
Thanks a lot for making the time to publish this!. Are the notes shared somewhere?
Very nice video.Thanks for uploading
Excellent exposition
Thank you. I learned so much from this video.
Thanks Russel .. You are an exceptional Mentor ..
thank you for this summary
Thanks. A great introduction to 5G core network.
Ineed this one note file please
Would be brilliant if you could do a video on the differences (evolution) between 3GPP release 15 and 16. 😊
It creates confusion, how you reflected slicing.
57:55 - can you elaborate on why SIP is a bad signaling protocol?
So many reasons... To name a few:
- SIP allows a single call dialogue to exist simultaneously in a UDP stream and a TCP session, interleaving based on packet size, while also maintaining ordered sequencing requirements between transactions ("CSEQ" being the sequence number). This is just asking for race conditions, and they do happen.
For example, in an MMTel-based conference call scenario a REFER and SUBSCRIBE transaction trigger at the same time, where the small UDP-based message happens immediately after the large TCP-based message, but if the small/fast message arrives first at the UAS then you'll get a sequence error. There are solutions for this but SIP creates this possibility in a way that no other signaling protocol does.
- SIP is encoded in ASCII, whereas virtually all signalling protocols are encoded in binary ASN.1. From a computing perspective this is very inefficient especially where SIP architectures make such heavy use of proxies, becauase you have systems encoding/decoding in English at every step, instead of binary to machine language. It's also very inefficient from an audit perspective, since binary is far more efficient to store or read.
- SIP headers have different ABNF formats called to in different RFCs. For example demarc rules between a URI parameter and a header parameter is ambiguous unless you know that specific header's format. The base structure of an attribute/value pair is normally defined top-down as part of the protocol itself, not at the discretion of the particular attribute. That's wild-wild-west.
- SIP gives too many options for things like DTMF (at least three options) and ring tone generation (at least three options). For interworking this leaves some ambiguity on whether the local or far end play ringback, or whether the phone generates its own ringback on signal of "ringing", etc.
- SIP has too many options for how to preserve ISUP-equivalent of OCN values (original calling number). The current header "History-Info" competes with the deprecated but widely used "Diversion" header, where in practice systems tend to give up and just always send/read both.
- SIP itself has no inherent distinction between "who they say they are" and "who the network says they are". That makes sense for Internet-based "alice calls bob" scenarios (which is what it was built for), but not for telecom environments. Later implementations improved this with the concept of P-Asserted-Identity headers, Privacy headers, etc., but this is not part of the base SIP protocol itself.
- SIP's original signaling methods invited "ghost ring" situations because "RINGING" in signaling happens prior to actual media setup completion. The concept of preconditions which already existed in other signaling protocols didn't get written to spec until much later.
- SIP has a far greater attack surface to an end-user terminal than any other signaling protocol exposed to end-user equipment. Previous models inherently pigeon-holed the end user through the structure of what binary messages could be accepted (eg: GSM DTAP signaling), and by making the "user to network" protocol fully distinct from the protocol used within the network (GSM DTAP vs ISUP, instead of all being SIP).
Because of this, end users of a SIP network have the inherent ability to (for example) pass XML files between each other, or add device/app-specific information to calls. Instead of starting off secure and working up, SIP starts off extremely flexible and you have to tighten it down.
I had to stop myself at some point, but honestly the few good things I can say about SIP are also true of H.323. It's a "signaling protocol" originally written for Internet-based media applications. Telecom has added to it, and improved it to make it more workable, but it was never really fit for the purpose.
I am so stuck with 5g core microservices , where would be the best point to start prototyping?which function to pick first?
Hi Russell .. can you please share the link for slides/one-note file that you are using in this video?
Hi! Excellent video. Please do more. This has been outstanding. I have one question though. At the end you mention a reference for people who have difficulty with reading specs, but I cannot understand what it is. At 1:03:15
I was referring to these two places in 3GPP:
www.3gpp.org/DynaReport/23-series.htm
www.3gpp.org/DynaReport/29-series.htm
If you scroll down to the 23.5xx and 29.5xx sections of those two pages, you'll find the architecture and protocol specs respectively, for 5GS.
Thank you for the clarification . Great job on the videos. Ps: I'm also a packet core planner from Brazil. Starting to work on 5g trials in the US. guess I'll be reading a lot of those specs in the near future.
Logically SMF must also do conventional DHCP function......is that understanding correct??
The concept of DHCP, although in actual signaling it would be "PCO Options" as opposed to DHCP attributes and options in an "offer" message.
That's not to say you couldn't have a DHCP server being queried by an SMF, but the protocol in use isn't DHCP between the UE and SMF for address assignment.
@@QuadraticSquared Like NRF subsumes DNS function, which element of 5G core is responsible for dhcp function....Thank you for your patient response
Do you have a link to your workbook? I'd love to store a copy on my computer as I manage these Network projects for reference!
Hi Mate, Thanks for the detailed explanation. is it possible to get this document for reference ?.
What are the fundamental difference between a Service Based Architecture and Reference Point Architecture of 5GC? Can you please list down few of them?
They're different ways of illustrating the same thing.
The reference point architecture specifically says what NF communicates with what NF for what purpose (with a reference point number, eg: "N26"), whereas the SBA defines more generally what systems exist to be talked to within the ecosystem.
When all the systems in the SBA speak the same language (HTTP2/JSON), a common web service can be provided to any client by an NF in concept, so there's no need to draw every possible line between all of them.
@@QuadraticSquared Many Thanks it helped!
SBA..... North, South East West API based comn and N1 to N... are traditional comn protocol.
Can you please detail on which protocols are used for N1, N2, N3, N4, N6
That would be:
N1 = NAS
N2 = NG-AP
N3 = GTP-U
N4 = HTTP2
N6 is simply the Gi/SGi interface of the 5GS. There's no defined protocol there. In fact, 5GS supports non-IP protocols out of that interface such as Ethernet (whereas EPS only supported IPv4 or IPv6 on SGi interface).
great absolutely great
Very good, appreciate it .
nice but , explanation is some what fast... my view is to low the speed
Well done!
Great and clear!
Sir tried sending u mail, but mail id mentioned in video is not working. Can u pls share ur mail id again?
The email is valid (russelldelong@ymail.com).
It's a military weapon