Showing posts with label Network Architecture. Show all posts
Showing posts with label Network Architecture. Show all posts

Monday 11 June 2012

The 'Virtual' Femtocell and a competition for OTT Apps

Over the last few months we have been thinking of so many ideas around small cells and this is something that we thought. It looks very simple and straightforward and having talked to a few small cells experts, off the record, none of them seem to be able to see anything wrong with this concept. With the 'Small Cells World Summit' just round the corner I am sure this could be something worth a discussion.

I am explaining the concept using an HSPA+ setup but there is no reason why this would not work in an LTE Setup. This is a typical connection for HSPA+ Femtocell setup with the gateway acting as a concentrator for all Iuh connections and having a single Iu connection towards the core. I have not shown CS/PS connection separately for simplicity. 
We propose a 'Virtual' or 'Invisible' Femtocell concept where we think that the Femtocell is redundant but the concept can be used to avoid the coverage and capacity problems faced by the operators and at the same time avoid the 'Signalling storm', atleast on the access network side. Now most smartphones have WiFi stack inbuilt. For this concept to work, WiFi in the phone is a must. Instead of having a Femtocell in between, a modified stack could be embedded in the phone itself. The output of the phone over WiFi are the Iuh messages that can terminate at the gateway and no difference would be needed from the core network side. This is illustrated in the picture below.
The phones would also need to have an enhanced UI to be able to allow a user to select only this option when roaming. You don't want a situation where the user thinks that he is camped on the 'Virtual' femtocell and making/receiving calls while he is not and run up a huge bill.

Advantages of this approach:

  • The Femtocells are no longer really needed and the end customer does not require to buy a separate equipment, which is different for different operators.
  • The phones can be working whenever a reliable WiFi connection is available, even if they are abroad without incurring costly roaming charges.
  • Some operators that do not have a lot of spectrum available avoid using Femtocells as they can cause interference and black holes in the coverage. 
  • There is no worry of a femtocell being used abroad illegally thereby causing interference with spectrum in another country.
  • Some security issues can be totally avoided and it would be worth for the operators that the keys being used cannot be seen by others.
  • A lot of people use OTT apps like Skype, Viber, Whatsapp when abroad, being camped on WiFi to avoid costly roaming charges. This approach would mean that the normal Voice and Messaging becomes similar to OTT and can help operator avoid losing out to the OTT apps. 


Disadvantages of this approach:

  • WiFi spectrum is already congested and does not always give reliable coverage.
  • Security issues would have to be looked in detail to make sure this would be secure enough. Since this concept is similar to creating a VPN between the phone and the gateway, I wouldnt think there would be any issues though.
  • Roaming revenues are a big cash cow for the operators, most of them would be unwilling to lose this if the phones are using this approach.

I think this concept is more suitable for the Residential Femtocells rather than the other Small Cells (enterprise, metro, pico, etc.) and there will always be a need for them. The main reason being that on a large scale, WiFi is extremely unreliable, prone to interference and not future proofed. A new device may cause interference that may take forever to resolve. Operating a small cell in the licensed spectrum would always make sense and the reliability would be much higher.

If you think this makes sense please click the 'Useful' checkbox so that I know.

As a company we are always looking to engage with other companies to discuss similar ideas. If you are a company dealing with Small Cells and are open to discussing similar ideas, please let us know.

Thursday 7 June 2012

On Signalling Storm... #LTEWS


The Signalling Storm is coming, its not the question of 'if' but when. This was the unanimous message from the Signaling Focus Day of the 8th LTE World Summit 2012. Several high profile outages have been associated to the Signalling storm, NTT Docomo and Verizon being the main one. Luckily the Telenor outage was due to software issues.

The problem is divided into two parts, the Access network part where the Air Interface is the bottleneck and the core network part which can easily be swamped by the overwhelming amount of Signalling due to more intelligent billing system and always on devices with background applications generating much more amount of traffic as would have on an older system. Lets look at them in turn.

Core Network Signalling Storm:

As I reported earlier, Diameter has been highlighted as a way of salvation for the operators with dozens of use cases but due to its immaturity has caused outages and have given it a bad name. As Connected Planet mentions, "According to one signaling expert, launching the iPhone’s browser, for example, instantly sets off about fifteen individual network signaling requests. Beyond that, 4G network software elements supporting increasingly sophisticated mobile service scenarios “talk” to each other at rates that traditional TDM/SS7-based networks never had to deal with." Hopefully a stable implementation of Diameter protocol will help not only solve the signalling storm but will help generate new models for charging and revenue generation.

A presentation by Ed Gubbins of Current Analysis, comparing the big vendors of Diameter Signalling is available here.

Access Network Signalling Storm:

My thinking is that the Core Network Signalling problem will become an issue some years down the road whereas the Access Network Signalling problem will be seen sooner rather than later. In fact for 3G/HSPA the problem is becoming more visible as the market has matured and more and more users are moving towards using smartphones, Since LTE rollouts are in its infancy (in most markets) the problem is still some way away.

One of the reasons for Signalling storm is the incorrect APN name. I reported earlier about Telefonica's approach to solve this problem by using 'Parking APN', see here.

Also embedded below are couple of presentations from the Signalling Focus day that talk about the problem from Access Network point of view



Other Interesting Reading Material

Finally there is an excellent whitepaper from Heavy Reading titled "The Evolution of the Signalling Challenge in 3G & 4G networks", available here to download.

Another excellent article summarising the problem is from Huawei magazine available here.

Friday 1 June 2012

On LTE Roaming ...

The IP eXchange (IPX) is used for data when the users roam between different networks. GPRS Roaming eXchange (GRX) is a service within IPX. One of the main areas of discussion within the LTE World Summit 2012 in the Signalling Focus day was roaming on LTE. Different vendors have different proposals and solutions; couple of them are as follows:



Interesting to see that iBasis has proposed LTE Signalling eXchange (LSX) as a way forward.

A presentation from Acme Packet (for an earlier conference) has interesting VoLTE roaming options proposal.

Finally, while everyone was focussing on LTE-LTE roaming, only Diametriq was looking at LTE-LTE/3G/2G Roaming. The relevant part of their presentation is embedded below.
Happy to hear more on this topic if anyone else wants to contribute. Please feel free to add comments.

Friday 11 May 2012

Updated LTE Architecture with LCS and MBMS entities

Here is an attempt to update the LTE Architecture with MBMS and Location Services (LCS) entities included



You can also refer to the following old posts:



Monday 26 March 2012

3GPP LTE Evolved Packet System & Application to Femtos

A video of the actual presentation is embedded below. Its quite long (94 minutes)



The presentation is available to download in PDF format from here.

Thursday 9 February 2012

Evolution towards ALL-IP Single RAN (SRAN)




Presented by Matthias Sauder and Dr. Volker Sebastian, VodafoneD2 GmbH in the 2nd FOKUS FUSECO Forum 2011, Berlin 17-18 Nov. 2011

Monday 30 January 2012

More on Policy and Charging in LTE

Continuing on the Policy and Charging in LTE from the previous post here.




Presented by Erik P. Neitzel, DMTS, Technology Development Group, U.S. Cellular in the LTE North America 2011 conference

Wednesday 25 January 2012

Introduction of HSS in the LTE

Click on the pic to enlarge

Interesting slides from E-Plus Mobilfunk GmbH & Co. KG presented in FUSECO Forum 17th-18th November 2011, Berlin.

Wednesday 14 December 2011

ETSI INT IMS/EPC Interoperability Standardisation: Motivation, Roadmap & First Results

INT = IMS Network Testing. ETSI INT website here. More details below the presentation:

This was presented by Giulio Maggiore, Telecom Italia, ETSI TC INT Chairman in the 2nd FOKUS FUSECO Forum 2011, Berlin 17-18 Nov. 2011

From the ETSI leaflet (note that this is quite old information but still on the ETSI website here):

IMS interoperability is a key issue for boosting IMS (IP Multimedia Subsystem) roll-out and more specifically network interconnection between operators. Only through thorough testing in practical scenarios can operators ensure operational excellence in a multi-vendor and multi-provider environment.


IMS comprises a set of specifications designed to enable network operators to implement IP-based networks that can carry services for both fixed and mobile customers simultaneously.


IMS was developed originally in the mobile world (specifically in the specifications created by the 3rd Generation Partnership Project, 3GPP), and was adopted for fixed networks by ETSI’s TISPAN Technical Committee (Telecoms & Internet Converged Services & Protocols for Advanced Networks).


However this promise of advanced communications over the next generation network will only be delivered if those same networks can interconnect.


ETSI’s Technical Committee INT: IMS Network Testing


ETSI is bridging the existing gap between 3GPP IMS Core Network standards and the initial industry IMS implementations through the organization of IMS interoperability events in connection with ETSI’s Centre for Testing & Interoperability (CTI) and Plugtests™ interoperability testing service.


Our Technical Committee for IMS Network Testing (TC INT) is actively establishing close contact with a number of industry fora and organizations dealing with IMS interoperability, including 3GPP, GSMA, MSF (Multi Service Forum), IMS Forum and the ITU-T. TC INT develops IMS test specification according to conformance, network integration and interoperability testing methodologies. Other ongoing work includes development of tests for Supplementary Services based on regulatory requirements and IMS tests with legacy networks (e.g. SIP-I).


ETSI has already held two IMS interoperability events. The first examined interconnection aspects of 3GPP IMS Release 6, including such issues as basic call on the Mw interface. The second event had a wider scope that included the testing of 3GPP IMS Release 7 interworking, roaming, border control, and integration of application servers executing selected Multimedia Telephony supplementary services.


Future ETSI activities and events will go even deeper towards bridging 3GPP IMS standards and industry implementations. These will include the organization of further IMS interoperability events designed to boost the roll-out and take-off of IMS services and operators’ network interconnections.

Tuesday 25 October 2011

Donor eNB (DeNB) and Relay Node (RN)

Extracted from 3GPP 36.300:

The eNB hosts the following functions:
- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);
- IP header compression and encryption of user data stream;
- Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;
- Routing of User Plane data towards Serving Gateway;
- Scheduling and transmission of paging messages (originated from the MME);
- Scheduling and transmission of broadcast information (originated from the MME or O&M);
- Measurement and measurement reporting configuration for mobility and scheduling;
- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);
- CSG handling;
- Transport level packet marking in the uplink.
The DeNB hosts the following functions in addition to the eNB functions:
- S1/X2 proxy functionality for supporting RNs;
- S11 termination and S-GW/P-GW functionality for supporting RNs.

E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface. The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also applies to RNs unless explicitly specified. RNs do not support NNSF. In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2, RRC, and NAS functionality, in order to wirelessly connect to the DeNB.

The architecture for supporting RNs is shown in Figure 4.7.2-1. The RN terminates the S1, X2 and Un interfaces. The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and S GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for X2) and an S-GW (for S1-U) to the RN.

For more details see - 3GPP TS 36.300 : Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)

Thursday 4 August 2011

Detailed presentation on Femtocell Security from Black Hat 2011

Femtocells: a Poisonous Needle in the Operator's Hay Stack
View more presentations from Zahid Ghadialy
Presentation available to download from here.
Detailed write-up on: Exploiting the Ubiquisys/SFR femtocell webserver here.
My earlier blogpost 'Femto Hacking in UMTS and LTE' here.

Monday 25 July 2011

Femto Hacking in UMTS and LTE

Couple of weeks back, The Hacker’s Choice (THC) made available some documents about how the Vodafone's (UK) Femtocell (a.k.a. SureSignal) is unsecure and can be hacked. Everyone seemed to jump on this bandwagon with some news articles even sounding like the whole Vodafone network has been hacked and hackers may be sending messages and making calls via your phone number.

In the end it came to light that the problem was fixed over a year back when Vodafone was made aware of this problem. THC is still arguing that there is an architecture fault and the Femto can be compromised.

As a result I decided to think about what could happen if the Femtocell is hacked.

Lets take case of UMTS Femtocell. A simple network architecture with femtocell (oficially known as Home NodeB) is as follows:

As you can see, the signalling over the air interface is encrypted and integrity protected. If a hacker is able to get into the Femto and able to listen to all the packets using some tool like WireShark, he would be able to get hold of the Ciphering and Integrity Keys as they come in cleartext in the RANAP Security Mode Command message.

It wouldnt be difficult to have a device that can listen to the conversations once provided with this keys. In fact if the hacker is able to listen to the messages, there is no reason he cannot stick his own messages at the right interval (when a voice call is ongoing) to send SMS and would appear that the message actually went from the phone number. Note that this message would be inserted in the Home NodeB and would be a NAS message. The end user would generally never find out that a message has been sent on behalf of his phone.

One thing that should be remembered though is that the phone would have to be in the range of the Femtocell and connected successfully to the network (via the Femto). One question someone may have is that can I not reverse engineer the key so that I can clone the SIM card. Fortunately for us, this is not easily possible. There are multiple levels of protection and generally it would be difficult to get the algorithms for generating the key. Also it should be noted that the authentication algorithms are confidential and only the operators know the algorithm.


Now lets look at the LTE Femtocell (a.k.a. Home eNodeB) as shown below:

One of the differences you may notice is that the signalling from Femto to the Core Network over S1 is encrypted and Integrity Protected. In case of the LTE Femto, there are multiple keys and only the required key (Kenb) is provided to the Femto. See the key hierarchy below:

Source: RedYoda

This would sound like an ideal protection from the end user perspective but some of the problems still remain. If the hacker can get hold of the Kenb which is sent in cleartext over the S1 interface via Initial Context Setup Request message then he could easily use it to listen to the packets. Since there is no voice support as of yet in LTE, it would only be the packets that the hacker can listen to.

As you may notice, there is now an Integrity and Ciphering on the S1 interface for the UE messages, the hacker cannot get hold of the Kasme or the master keys K, CK and IK. This means that he cannot insert rouge messages that would for example send unsolicited SMS on behalf of the user as he would be able to do in case of UMTS.

There is a small caveat though. There are multiple Ciphering and Integrity algorithms defined in the standard. No ciphering is defined as eea0 algorithm. In Release-8 of LTE, there was no possibility to have Integrity switched off as there was no eia0 algorithm defined. In Release-9 though, the new eia0 has been defined which means that the network can set the Integrity to NULL. I am sure that the network would not want to do so as it makes absolutely no sense but the hacker can force it to do so.

When the Network requests the UE to send the capability information, the hacker can force it to say that it only supports eia0 and eea0 which would mean that the integrity and ciphering in the call would be off. To be honest, this is quite a difficult thing to do in real time and also the network would not accept a UE that does not support other Integrity and Ciphering algorithms.


3GPP has already forseen these kind of threats that could be affecting the networks in the future when they roll out the Femtocells. As a result they have produced 3GPP TR 33.820 that lists all the possible threats and the best practices that can help to minimise the chances of the network being compromised. If that document is too big and technical, you can go though this presentation as it summarises some of the problems.

Feel free to comment or correct any mistakes that you think I have made.

Sunday 17 July 2011

Network Mode of Operation (NMO)

Picture Source: Tektronix

The Network Mode of Operation (NMO) is also sometimes referred to as Network Operation Mode (NOM). The Network Modes have different values and interpretation in UTRAN and GERAN

In both the cases the Operation modes is decided based on the Gs interface between the CS CN (core network) a.k.a. MSC and the PS CN a.k.a. SGSN

In UTRAN:

Network Operation Mode I (NMO-I) is used when the Gs interface is present. In this case during the registration a Combined Attach (includes GPRS Attach & IMSI Attach procedures) procedure can be performed. A GMM Attach Request message with the attach type set to Combined Attach is used. Upon completion of this procedure, MM Status is IMSI Attached and GMM State is Attached.

In Network Operation Mode II (NMO-II) the GS Interface is not present. So the GMM attach procedure and the IMSI Attach (via Location Update) has to be performed seperately. This causes additional signalling.

Basic air interface signalling in case of NMO2 is shown here.


In GERAN:

Network operation mode 1. A network which has the Gs interface implemented is referred to as being in network operation mode 1. CS and PS paging is coordinated in this mode of operation on either the GPRS or the GSM paging channel. If the mobile device has been assigned a data traffic channel then CS paging will take place over this data channel rather than the paging channel (CS or PS).

Network operation mode 2. The Gs interface is not present and there is no GPRS paging channel present. In this case, paging for CS and PS devices will be transferred over the standard GSM common control channel (CCCH) paging channel. Even if the mobile device has been assigned a packet data channel, CS paging will continue to take place over the CCCH paging channel and thus monitoring of this channel is still required.

Network operation mode 3. The Gs interface is not present. CS paging will be transferred over the CCCH paging channel. PS paging will be transferred over the packet CCCH (PCCCH) paging channel, if it exists in the cell. In this case the mobile device needs to monitor both the paging channels.

The GERAN part above is extract from the book Convergence Technologies for 3G Networks.


The Gs interface, has a number of subtle but important advantages:

During an ongoing GPRS / EDGE data transfer (TBF established), mobiles can't detect incoming voice calls and SMS messages as they are focused on receiving packets and thus can not observe the paging channel. In NMO-1, the circuit switched part of the network forwards the paging message to the packet switched side of the network which then forwards the paging message between the user data blocks while a data transfer is ongoing. Mobiles can thus receive the paging message despite the ongoing data transfer, interrupt the session and accept the voice call or SMS.

Location/Routing area updates when moving to a cell in a different location/routing area are performed much faster as the mobile only communicates with the packet switched part of the network. The packet switched network (the SGSN) then forwards the location update to the circuit switched part of the network (to the MSC) which spares the mobile from doing it itself. This is especially important for ongoing data transfers as these are interrupted for a shorter period of time.

Cell reselections from UMTS to GPRS can be executed much faster due to the same effect as described in the previous bullet. Whithout NOM-1 an Inter RAT (Radio Access Technology) cell reselection with Location and Routing Area update requires around 10 to 12 seconds. With NOM-1 the time is reduced to around 5 to 6 seconds. An important difference as this reduces the chance to miss an incoming call during the change of the radio network. Also, ongoing data transfers are interrupted for a shorter time,an additional benefit that should not be underestimated.


Tuesday 12 July 2011

Couple of presentations on GNSS and LCS

I came across couple of presentations from International Conference on Localization and GNSS, held in Tampere, Finland, June 29-30, 2011

This first presentation by Lauri Wirola of Nokia gives good summary of standardized positioning technologies in use today. It also lists the difference between control plane and user plane positioning. The 3GPP based positioning from Rel 5 to Rel 8 has been listed. Overall a very interesting presentation.

The second presentation by Ignacio Fernández Hernández of the European Commission, gives an overview of the EU satnav programmes (Galileo, EGNOS) and current R&D status; Present some numbers and findings of the overall GNSS R&D panorama in EU and abroad; Present some trends and challenges in location technologies for the following years. Another interesting presentation I think.


Monday 20 June 2011

Roaming with the IP eXchange (IPX)


From Wikipedia:

Traditionally, voice traffic interconnection between different operators has utilized the international SS7/TDM networks. However, lately the all-IP paradigm with VoIP is being rapidly introduced by different operators in various forms, such as IMS. In order to minimize the number of conversions between packet-switched voice and circuit-switched voice there is a clear need to deploy an IP based NNI (Network-to-Network Interface) and therefore an IP based interconnection network.

It is also evident that a large number of IP based services (such as Presence or IM) simply cannot be interconnected using a SS7/TDM network, further increasing the need for evolution into an IP based interconnection network.

Since the year 2000 GSM operators have been using GRX (GPRS Roaming Exchange) network for routing the IP based commercial roaming traffic between visited and home operators. Mainly 2.5G and 3G data roaming has been using GRX. GRX is a private IP network (separated from internet) consisting of multiple different GRX carriers that are connected to each other via peering points. However, GRX is limited only to GSM operator community and not all GRX's are capable of meeting the demands of real-time services.

Even though the GRX environment is not entirely suitable as a common IP network for interconnection and roaming, it offers a good starting point for the development of IPX. IPX development has been done in various GSM Association projects and working groups since 2004.


The following presentation is from LTE World Summit:

Monday 19 July 2010

NTT DoCoMo: Core Network Evolution and Voice Strategy

Presentation by Seizo ONOE, Senior Vice President and Managing Director of R&D Strategy Department NTT DOCOMO, INC. in LTE World Summit 2010 on the 18th May 2010

Friday 19 March 2010

IPv6 transition in cellular networks gaining momentum


IPv6 is good and we all know that. I has been talked for years but practically it hasnt found much success. Verizon made some noise last year but I am not sure of the conclusion.

Just to recap, IPv4 was introduced back in 1982 and IPv6 work started since 1995. IPV4 uses 32 bit (4 bytes) addresses while IPV6 uses 128 bit (16 bytes) addresses. Theoretically we would now have 2^96 times more addresses than in case of IPv4.

Most of network infrastructure manufacturers have their equipment ready for IPv6 as some of the handset manufacturers. The main driver being that someday soon IPv4 addresses would be exhausted (Internet Assigned Numbers Authority will run out of IPv4 addresses in September of 2011, based on current projections) and their equipment would be ready to provide IPv6 addresses without any problems.

Recently, IETF-3GPP Workshop on IPv6 in cellular networks was held in San Francisco, USA on 1 - 2 March, 2010. There are lots of interesting presentations available here for people who want to dig a bit deeper. The concluding report that summarises the presentations and discussions are available here. Here is a brief summary from one of the reports (with links at the end):

Summary
  • Scenarios for IPv6 migration were discussed based on 3GPP Technical Report 23.975
    • The discussion focused on validating the scenarios
  • General IPv6 transition and deployment guidelines were outlined based on input from IETF
  • Solutions for migration and v4-v6 co-existence were presented
    • Solutions included existing RFCs and working group items but also proposals in Internet Drafts
    • Gap analysis wrt transition scenarios was discussed

Conclusions on scenarios
  • Scenarios 1 and 3 based on dual-stack and IPv6-only deployments were generally recognized as valid
  • Scenario 2 was also recognized as valid, addressing two separate problems related to insufficient RFC1918 space and subscriber identification
  • Scenario 4 did not receive wide support from the workshop, largely because it was felt that it addressed a problem already solved by other scenarios
  • Variants of some of these scenarios were brought up during the discussions, conclusions were not reached on these
    • These may need further discussion

Conclusions on solutions
  • It was recognized that necessary support in the network and devices is already available to “switch on” IPv6 in 3GPP networks
    • Some networks reported running dual stack
    • Some networks reported running IPv6-only now
  • Solutions enhancing existing mechanisms for dual stack deployments and new solutions for IPv6-only deployments drew wide support
    • Gateway-initiated Dual Stack Lite
    • Stateful IPv4/IPv6 translation
Next steps: 3GPP
  • IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
    • Note that the workshop itself does not have the mandate to make formal decisions
  • 3GPP is expected to identify possible normative specification impacts, if any, of the preferred solutions
  • A need was identified to provide more operational guidelines about IPv6 deployment to 3GPP operators
    • The best location for these guidelines is FFS (e.g. 3GPP TR 23.975, GSMA, etc)
Next steps: IETF
  • IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
    • Note that the workshop itself does not have the mandate to make formal decisions
  • IETF is encouraged to continue working on stateless and stateful IPv4/IPv6 translation mechanisms
    • These mechanisms are being worked on in IETF BEHAVE group
  • IETF is also encouraged to consider new solutions that are not yet working group items
    • Gateway Initiated DS Lite
    • Per-interface NAT44 bindings addressing IPv4 address shortage
  • Note that the workshop has not set any timelines

Further reading:

Monday 8 March 2010

Evolution of 3G Networks: The Concept, Architecture and Realisation of Mobile Networks beyond UMTS

This book has a title that can be a bit misleading but the main focus is on LTE network. One of the main problems that I generally notice is the lack of understanding of the bigger picture from the network point of view. This book can help fill that gap. The book starts with Mobile Network Evolution in General and moves to explain the evolved 3GPP network.
The different layers and interfaces have been explained quite well and the concepts have been well illustrated with the diagrams. A lot of books have diagrams that are verbatim copy of the standards of illustrated in a complicated way, these have been avoided in this book. To illustrate my point lets look at this image below that shows example arrangement of bearers with multiple PDN connectivity.
Later on the signalling for different scenarios have been explained in a rather nice way. For example of we look at PDN connectivity again, its rather simply explained.
There are many examples of signalling and once they are complete, there is a chapter looking at different protocols like GTP, PMIP, DIAMATER, SCTP, etc.
The book is a bit pricey though but worth the investment if your focus is on the signalling side of things and if you are required to understand the concepts quite well. You can also have a look at the book n google books as embedded below: