Posts Tagged ‘re-post’

[re-post] IP address allocation

Posted: August 8, 2012 in technical
Tags: , , , ,

To my great surprise IP address distribution to the UEs proves to be quite tricky in 4G. First of all there are 2 types of addresses supported: IPv4 addresses and IPv6 addresses. Each PDN connection needs at least one IP address associated with it, IPv4 or IP6, but it may have one IPv4 and one IPv6 address associated with it. All UEs and PDNs need to support at least IPv4 address allocation during default bearer activation and IPv6 prefix allocation via IPv6 stateless autoconfiguration, but may also support IPv4 and IPv6 address allocation via DHCPv4 and DHCPv6. Also there is the possibility of using static addresses/prefixes, but this is transparent to the UE (23.401 “It is transparent to the UE whether the PLMN or the external PDN allocates the IP address and whether the IP address is static or dynamic. It is transparent to the UE whether the PLMN or the external PDN allocates the IP address and whether the IP address is static or dynamic.”). If a static address/ prefix is to be used this needs to be configured in the HSS or in a DHCP/Radius/Diameter server.

I will not talk about the IPv4 address allocation as it seems to be quite simple. The PGW is allocating or obtaining an IPv4 address for the UE and forwards this address to the SGW and the SGW in turn to the MME in the Create Session Response message (PAA IE). The MME will store it and send it the UE. The address will be released upon the release of the entire session.

IPv6 prefix allocation
– Each UE and PDN connection is allocated a globally unique /64 prefix (23.401 |IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is the basic mechanism to allocate /64 IPv6 prefix to the UE.”)
During default bearer activation the PGW sends to the SGW (and MME) a complete IPv6 address that contains a /64 prefix and an interface identifier. This address is included in the Create Session Response message in the PAA IE. The MME will forward only the interface identifier to the UE and it will store the prefix. Upon activation of the default bearer the UE may send a Router Solicitation message to the PGW. This message will travel encapsulated in GTP-U over the S1-U and S5/S8 interfaces. So, this RS message will be received by the PGW accompanied by a GTP-U header that contains the PGW-U TEID allocated to the UE for the default bearer. After the default bearer activation the PGW will send a Router Advertisement message to the UE containing the same IPv6 prefix as the one allocated during default bearer activation and sent to the SGW and MME. This RA message is sent on the GTP-U tunnel associated with the default bearer and can be sent solicited or unsolicited. Using the prefix received in the RA message and any interface identifier other than the one received the UE creates globally unique IPv6 address (23.401 “For stateless address autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses, other than link-local, without involving the network. “).

Note: The RS message uses the following source and destination IPv6 addresses:
– Source IP address: a link local address formed using the interface identifier received by the UE during the activation of the default bearer (FE80::received prefix)
– Destination IP address: IPv6 all routers (FF01::2)
The RA message uses the following source and destination IPv6 addresses:
– Source IP address: a link local address of the PGW
– Destination IP address can be either:
– IPv6 all nodes: FF01::1
– The source IPv6 address of the RS message.
Source: RFC 4861.

Details on the IP address allocation can be found in:
– 23.401 section 5.3.1
– 29.061 section IPv6 Stateless Address Autoconfiguration for EPC

There are 2 questions that I couldn’t find an answer for yet:
1. Why was the stateless autoconfiguration mechanism chosen? Why not just pass the prefix to the UE?
2. In Create Session Request for handover and sometimes for attach the MME includes the UE’s IPv6 address. What IPv6 address is included, considering that the MME and HSS only keep the prefix in the information storage databases? (per 23.401 Information Storage section)


[re-post] NAS messages format

Posted: August 8, 2012 in technical
Tags: , , , ,

It’s been a long time since the last time I wrote anything, but latly I feel the need to write down what I’ve been reading (just to have some reference for the future). Today’s post will be about how the NAS messages are constructed. As I was used to working with GTPv2, the NAS protocol looked like a big mess to me. Here’s what I’ve figured out so far.

The spec governing the NAS protocol in 4G is 24.301. It describes both the procedures and the message format. Each time I need to figure out what messages should appear for a certain event I first have to read the procedure and find the names of the messages. The description of the procedure usually contains some directions for the content of the messages too. The next phase is analyzing each message. For each message there is a table with the Information Elements (IEs) that are to be included. Note that the IEs are marked as mandatory, conditional or optional. Each IE has the a dedicated chapter where the structure of the IE is described. Note that there are multi types of IEs (V – value, LV – length-value, TV – type-value, TLV-type-length-value, etc.). The mandatory IEs are included in the packets without the type (24.301 8.1 )and that is why for the NAS messages the IEs need to be put in the packet in the exact same order as in the table describing the message. In that table it can be noticed that these mandatory IEs have no IEI (IE Identifier) associated with them.
As the communication between the UE and the MME needs to be secure, usually the NAS messages are integrity protected and sometimes ciphered. Depending on wheather the NAS message is security protected or not, the format changes. In case the message is security protected a security header appears. (24.301 9.1) This security header contains the security type, the protocol discriminator(always “EPS mobility management messages” for security protected messages, – 24.301 9.2), a MAC (message authentication code – a hash that allows the other end of the communication to see if the messages was tempered with) and a sequence number. After this header the NAS message actually begins, with its own header. This header of the plain NAS message consists of protocol discriminator (this time it can be different tha “EPS mobility management messages”), EPS bearer identity or security header type (this time “Plain NAS message, not security protected”), a procedure transaction identifier and a message type. After this mandatory header the other information elements appear.

Note: When setting the security type the negotiated encryption and ciphering algorithms play no part at all. (24.301 4.4.5 Ciphering of NAS signalling messages). This means to say a message that was encrypted with the NULL algorithm (not encryoted at all) can still be encoded as a security protected message that is ciphered.

The first post is about handovers in LTE. I will not describe the LTE architecture because anyone who might be interested in the subject must already knows that. This post is not about what happens in the core of the network when a handover is decided, but what happens in the access area. Between two eNBs that are connected though an X2 link, as far as I understand, there are two types of handovers: seamless and lossless. The names are not very intuitive, but the idea is that seamless handover is used for bearers transporting traffic that is very sensitive to delay and jitter and would rather accept retransmissions than delay, like VoIP, while the lossless handover is used for bearers that transport traffic that does not care too much about delay but is sensitive to retransmissions, like FTP and HTTP.

The decision for one of the HO types or the other is made by the source eNB. The major difference between the two HO types is that when using lossless HO besides the information sent by the source eNB to the target eNB in the Handover Request message, the source eNB also sends on the X2 link the downlink packets it received for the UE and which have not been sent or acknowledged yet. This way all the packets are delivered and no retransmission should occur. When thinking about this one must take into consideration that in a VoIP conversation the packets used are very small while for HTTP an FTP large packets are used. The retransmission of such large packets would use valuable bandwidth and TCP would protocol to slow down the conversation. On the other hand for VoIP the packets used are very small (retransmission of a few packets is not very expensive in terms of bandwidth), and it is very important that the packets arrive with the smallest delay possible.