YTread Logo
YTread Logo

LTE Call Flow - Wireshark (Pcap) analysis of LTE UE Attach

Mar 06, 2024
So in this section we will review the LD connect

call

flow

and the intention here is to cover all the topics that we have covered in chunks so far in this course and put it all together and try to trace the steps that follow. There is a UE and the network will take to provide LD service to a given subscriber, so this chart here is intended to describe the different steps that a UE goes through when it connects to the network so that it has the user equipment that en Right here, this device that connects to the network acquires the network and then it can establish a signaling connection in the control plane and then it starts the LT connection process that we saw in the previous section and goes through authentication. process as we have seen and how it performs the key exchanges and everything it knows, the response and the expected response, the DMM e matches to authenticate a subscriber, once the authentication is successful it continues with the security where the security in the NASA lair. and the RFC layer by the B Mme and the UE, then you go into what is

call

ed an ESM information request and response process where you tell the network that you know what kind of services the UE is requesting or wanting and a time that Is there information about the actual bearer configuration for that given subscriber?
lte call flow   wireshark pcap analysis of lte ue attach
We are a default bearer or a dedicated bearer is configured by the network and once the bearers are configured, IP connectivity is in place and data transfer can then occur. Handovers may occur where the UE moves out of the coverage area of ​​the given interior or it may transfer to a different location where it is not and then it may also go into idle mode where it has done its session and just goes . go back to sleep and then the network can release it, so we will go through at least the points listed here in two three four five six seven eight and see some real Wireshark captures from the network side and try to trace find out the different steps that are followed in the life cycle of the UE, so starting with the initial message of the UE, this is the message that the UE first sends when it connects to the network, either when it connects and knows when it connects. is turning on. or you know when it's coming out of idle mode and going into connected mode, so if you look at this message here, this is the initial message sent through the NASA lair, the protocol is Nass and they're piggybacking on this. message we have the PD n connectivity request so here are some snippets of this message and I have highlighted within the red boxes some key elements that we need to pay attention to so starting here we have the initial message there is a unit of data ass protocol. which we'll look at in more detail and that Nass PDU has been expanded here, so there's actually a drop down menu here, if you click on it, it will open up and you can see that

attach

ed are a prompt message that comes in what type of file

attach

. exists, it is even able to identify that and then there is information from PL MN, MCC MNC, there is an EM timsy, if applicable, if Yui already has an EM timsy, it will connect with an EM timsy, if not, it will connect with the MZ and then there is a PD and a connectivity request that tells you what the motivation is for Yui to connect to the network, so it requests a connectivity request PD n, so I like to summarize Yui's initial message once again for Mme to send an attachment. request message that includes the type of attachment, you know that the type of attachment that is included is defined here: it is permanent or temporary, so it can be temporary or permanent and it also identifies that it also sends what is called a PD request and connectivity that can be seen here testing the other things.
lte call flow   wireshark pcap analysis of lte ue attach

More Interesting Facts About,

lte call flow wireshark pcap analysis of lte ue attach...

We should also note that as part of this attach request, the final PD connectivity request, there are certain protocol configuration options that Yui sends and right now they are all empty, but they are just placeholders in this, so if you were to expand each of these in a Wireshark capture, they would be empty, but when the attachment is completed, all of these are populated by the network and sent back to the US so Yui has all the information to you know, in order to process data, this is a placeholder right now, but they are also sent to the network, so one thing I would like to point out is that there is another piece of information that is called node b ue s1, a PID and that is, it is located right here, so the PID to node b ue s1 a is actually assigned by node B and is used during the entire connection s1 ap between this node B and the Mme and identifies a UE without ambiguities within that e node B, so node B U assigns this ID of s1 ap and that is a PID that is used throughout the life of that particular Yui, as long as it is connected to the scene o V, so that the first downlink Nass transport message from s1 ap sent by the mme then this is sent to the mme and now there will be a corresponding message that will return from the mme which will have another s1 a PID but which will be assigned by the mme and again that mme s1 a PID would be a unique identifier of that ue in the AP entity s-1 in the mme, then there are two s1, one PID, one is assigned by the node B and the other is assigned by the Mme.
lte call flow   wireshark pcap analysis of lte ue attach
They are not the same, but there are unique identifiers for this one. particular ue within the node e B and Mme respectively. There are now two types of connections that can occur in an LT network. We have the first type which is called connected EPS and the other is a connected MZ combined EPS. What is the difference between these? two is if there is only one attached EPS which is not here, this is a combined one in the case of an attached EPS, what the UE requests is that it is only intended for LTE data, while in an attached MZ combined EPS, the UE you want to register on both your LT domain and your voice domain essentially, and those voice domains can be, you know, it can be if it was a 3gpp network, it can be your broadband UMTS or CDMA, so if this is attached enters, then Mme would also register this subscriber on the other non-LD systems, so hopefully you already understand the different parts of Yui's initial message, so here we have listed the messages that happen after Yui's initial message has been received so that Yui's initial message comes from Yui to Mme.
lte call flow   wireshark pcap analysis of lte ue attach
It has some of this information that we reviewed on the previous slide. It has the type of attaching the identity of that subscriber and it also has the connected connection request message PD PD n which can be. a v4 v6 or a dual stack now, once this message reaches Mme, the Mme that you know, as we had seen in the Security section, goes through the HSS to look for the authentication vector, so this is the IR message what you see inside that IR. message we send what is the MZ the identity of the subscriber the PLM N visited and the RAC the type of radio access technology whether it is LTE or something else the HSS responds to the mme with the authentication information response and includes these vectors of authentication here includes the authentication token includes the expected response the Mac and the random number and also includes the cash B now the Mme sends the authentication request to the UE includes the authentication token and the random number the MA Yui responds with what is called a response and then if the response Mme compares the response it received from the UE with the response it received from the HSS, if everything matches the user is authenticated and then there is the security command for encryption and integrity protection in the grinding. lair and send a remote command and then complete a security mode, so this is what is shown here, this is simply listed here, while this is the royal ladder diagram, so we have already covered the details of these. messages in the previous section on LT security.
I'm not going to repeat all of that information, but if you want to look at that information again, I would recommend that you go back and just read it or listen to those slides and review that information, assuming everything is going well so far, we'll move on to the next slide here and in This slide, once the encryption and integrity protection at the NASA and RC layers is completed, Mme sends an ESM information request to the UE to get more details on what type of service the UE wants connect, so if you look at this message here, this is the ESM information request message, this is what it looks like in Wireshark, you have the API DS s1 API, so if you remember, we had talked about Ino. to be s1, a PID right that is right here, you assign it in or B, the Mme also assigns an API D s1 that is here and this again uniquely identifies that subscriber and then if you open the protocol data unit NASS here, you can see that this is the name of that message, the ESM information request now, when the UE receives this message, it responds with what is called ESM information response and in that response it sends a lot of information through the network about what kind of services the eu wants to acquire, so it sends what is called an access point name, if you remember, the name acts is a concatenation of network identifiers and an operator, i.e. fired for access, my name is sent to the network here and PLM also returns an identity along with the tracking area code that the user is currently in and then the mme uses that information to set up the known bearers as we'll see in just a second here, so the ESM information asks yes M, answer the information now once you've done that.
The ESM process is complete, the mme sends to the HSS a message through the diameter interface which is called location update request and receives a response from the HSS which is called location update response, so in summary, They are called ul AR and ul a. so if you look at the ul AR message, this is again a Wireshark capture, this is the name of that message. Update location request. If you open the diameter protocol message, you can see that we passed the MZ again because that's how the HSS can look. its database to n identify a given subscriber the type of send trap the user is currently connected to in this case it is an LT connection and we also send PL MN information that tells the HSS which BL MN the subscriber is connected to Currently the HSS processes this information and returns what is called an update location response.
This is again a Wireshark capture. This shows which interface we are looking for and sends a successful diameter. If this had failed, it would come back with a diameter error message and there would be some type. There is no reason within these attribute value pairs as to why the update location failed, so at this point the HSS has done its part, you know the HSS has done its part, the user is now located inside the HSS and its location has been updated and it is now moving towards the Mme send now because now we know that we have authenticated the user so far.
We have done all the encryption and integrity protection that we have obtained from the EU. What type of services does the EU want to obtain? We have that information. Now we have to configure. configure bearers to configure bearers, we know from our discussion on MMI side that mme is the controller for all eps management, evolved packet system bearer management, everything is controlled by mme, so the meme ma sends a message to the service gateway and that message name is called session creation request, it sends that session creation request and that message looks like this, this is from Wireshark here is the session creation request here, within that session creation request, we pass user identification information because the service gateway also keeps track of that user, so we have the MZ, we have the MSISDN, we have the mobile equipment identifier, you know the IMEI, we tell you which PL MN the subscriber is connecting to the type of radio access technology and we also assign an identifier of the tunnel endpoint, so it is assigned by the Mme and then the mme includes its IP address and In addition, it also includes the IP address of the gateway p to which the service gateway must communicate to configure the bearers and that IP address is included here we also pass the APN name to which the subscriber is connecting and we say what type of PD endpoint type it is, in this case it is an ipv4 and we also pass some amber values ​​so that the maximum aggregate bit rate that the bearer should have Comply with so one thing I would like to point out here is the identifier of the endpoint of the tunnel, so if you remember there is a gtp protocol GPRS tunnel protocol running between Mme and SK Dre, now the tunnel is big, it's a small pipe, think of it's like a pipe and the two ends from that pipe there is an ideal id and those ids are nothing more than numbers that help identify the tunnel now, since Mme sent that initial message to the service gateway, it will add a tunnel endpoint identifier right here. and this is what she did now, the other end of this pipe is not configured yet, that's why the tunnel endpoint identifier all values ​​are zero, but you will see when we start receiving responses to this requestinitial, this tunnel endpoint identifier will start to be completed and we will start to see information here, okay, now the service gateway has all the information for that subscriber that is connecting to the network, it knows which APN it is connecting to connecting the subscriber and knows what type of bearer you need to configure. it knows what the throughput limits are on that bearer and it knows which subscriber, so it communicates with the corresponding gateway P which was identified by the IP address here because the mme makes the gateway p NS k to a select, essentially sends that same message to that gateway p, gateway p allocates the resources for that eps bearer and sends a response and that response is sent by the serving gateway to the mme and here is a fragment of that response, so now if you look at this answer here we have a tunnel endpoint identifier, so this tunnel endpoint identifier actually identifies the tunnel session on gateway P and has a bunch of information in the configuration options from the protocol, this was again the placeholder that Yui had initially sent if you remember, but now it has all the information, so now the mme has all the information for all the bearers that were requested by the user and now it has to communicate that information to you on o B and to Yui, the way it does this is to send what is called an AP s-1 initial context setup request, so after the bearers have been established on the core network, It is now necessary to establish simple user traffic or simple user transport functions on the radio interface as well as on the s1 s1 AP.
The initial context request message is sent by mm e to node e B it. includes all the ue-specific parameters to be stored on node B, such as the simple tunnel endpoint identifier of the serving gateway user for establishing the gtp tunnel on s1, to be sent and also to that the tunnel endpoint identifier is actually here. it also sends the nasa jiz such as attach, accept and activate the best default requests which are transparently forwarded to the eu via the radio interface, so as part of this message we have the point identifier end of the tunnel which is sent to the u node and then the NASS layer we send these messages to the u informing that the attachment has been accepted and we pass certain values ​​of the timer t34 one tired - the timer is a timer between consecutive updates of the tracking area that the UV must comply and we also assign agouti to globally unique temporary identifier for this UE here, so they are passed as part of the NASS message, so this is NASA, this is a tunnel point identifier, then we also send to the node e information about the ear, the evolved one. radio access bearers that would need to be configured, you know, they go to the UE and we send an ID that identifies the bearer, in this case its ID is the number five and we also tell it what the q CI parameter would be for that corresponding bearer , so in this In case we have the bearer Q CI 9 that is being configured and we also pass our p value, they serve the assignment hold priority value for that bearer, so they are passed to in would be like part of this message, so if you remember from our discussion about LT security that Mme also sends to node a B K e node will be a security key for note e B which is right here and this is passed as part of its request message of initial context configuration that is sent to note B by Mme and then there are some added maximum bit rate parameters that are also sent by MM e to e note B so that note B knows what kind of limits in terms of speeds that the user can comply. once it observes that B receives the initial context configuration request, it responds with a configuration response message and the response configuration message, since these parameters there have what it does for one thing it does is respond with its address IP.
Look at the IP address listed here and it also maps a gtp tunnel endpoint, so the gtp endpoint tunnel would be the tunnel that would run from node II B to gateway s, so in the previous section, the previous slide we had sent the Ino would be the TE ID of that tunnel that was assigned by the service gateway, but there would also be an endpoint of the tunnel that would be defined by enote B, which is this value which is sent from node B in the response. to Mme or about s1 AP yes, and then what happens after that is at the NASS layer at the NASS layer, the ue responds with an attached accept message which attaches the accept message if it reads it in the Nash lair, recognizes the activation of Default EPS Bearers and you know it says "Okay", your node B is now ready to send and receive traffic, so it's the ue that sends the Nasser and attaches it, accepts an array, activates the default value, you better accept the message now, following this, the Mme. it reaches the serving gateway with the message which is called a modify request message better using gtp protocol and this is again a Wireshark trace here where we tell you the details of the serving gateway around that bearer , we tell you how many carriers are being established in this case. was only one if you remember, the best idea was five: we give the serving gateway the IP address of inside B to be sent here and we also tell the tunnel endpoint identifier that was assigned by node B to the service gateway which way the service gateway has the tunnel endpoint identifiers for eNote B and then once the service gateway receives this request it sends a response with a modify answer best again there is best id out of 5 because there is only one best here and it responds with its ip address and that ip address is stored in the mme and also the tunnel endpoint id is stored in the mme at the end of the step number 20, the ue is now connected and has the default best set between it and the network and can now actively exchange data on both the downlink and uplink, so this is kind of a summary of the

flow

of LT connection calls and hopefully you now understand the different aspects of LT.
I now attach this section to bring everything together, we have included this. Image here where you have Mme, you have HSS, you have e note, Yui serves the gateway and the P gateway, so it's all here, where you can see very well that Yui has an IP address assigned by the P gateway Here and then, you have a connection with your node, be it the RLC connection and the in or B has a connection with Mme, as well as with the service gateway, sir, there is a tunnel between node B and the Gateway. link and there are tunnel endpoint identifiers on both sides of this tunnel, on this side, node B assigned a T ID equal to 1.
This tunnel endpoint identifier was assigned by the serving gateway and again , this has a tunnel to the mme. identifiers on both sides of this tunnel or towards mme on interface s11 and similarly on port P, there are tunnel endpoint identifiers, so the tunnel endpoint identifiers, a pair of tunnel endpoint identifiers they actually correspond to a tunnel, this is how they can to uniquely identify the tunnel and then obviously here you have the HSS that can find information for this given UE based on the MZ and then the mme allocates the loot and delivers it to the eu through the NASS layer, so that's the duty. for you guys and the s-1 a PID again there are two endpoints there is your B endpoint and then there is the mm en and these are also listed here so yeah this concludes our LT connection call flow and I hope We have been able to explain how the U can connect to the network and explain the activation of its default bearers for a given UE, so see you in the next section.
Thank you.

If you have any copyright issue, please Contact