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

Friday 27 June 2014

Voice over WiFi (VoWiFi)


One of the changes that I have noticed in the last year is that some of the operators who have been opposed to WiFi in the past have not only embraced it but are now trying to monopolise the same WiFi spectrum they billed as interference prone. Personally, I think the future of Wi-Fi is not just offloading but also working together with LTE. We are billing this as 4.5G and have recently produced a whitepaper, available here.

There has been a flurry of activity on Voice over Wi-Fi in the last few months. Recently the UK operators '3' and EE announced that they are both allowing WiFi calling and SMS. While '3' customers will have to use an OTT app for the time being, EE customers will experience this seamlessly.

I heard Taqua in the recent LTE World Summit talking about their solution and have offered to share their slides (embedded below). It was interesting to find out while having a discussion with them that their solution supports 'hand-in' and 'hand-out'. This takes away a major advantage that Small Cells offered, seamless roaming. Anyway, feel free to let me know of you have any opinion on this topic


Wednesday 25 June 2014

Diamater: Market Status, Roaming, NFV and Case Studies

Some more interesting presentations from the Signalling Focus Day of LTE World Summit. Good overview of market by Greg Collins of Exact ventures is embedded below.





A good presentation by Tieto where they presented some good case studies for Diameter Interworking. Presentation embedded below:




The final presentation by Diametriq is very interesting because they presented interesting way of mining the control plane. Thee case study presented was of a 'silent roamer' who is not going to spend money while roaming because he is not sure how much money is spent. This can be exploited by the operator to offer flat packages, 1 day pass, etc. to get some revenue from these roamers. Their presentation included some animations that cannot be shown while being embedded. Please download the PPT from Slideshare to view them.


Monday 23 June 2014

LTE Roaming using IPX


A very interesting presentation from RaphaĆ«l Glatt of Bics in the Signalling Focus Day of LTE World Summit 2014. IPX is probably the most popular solution as its already being used by many operators for roaming agreements. Anyway, his presentation was the most detailed one I have come across and he was happy to share it with me for this blog. His complete presentation is embedded below:



Saturday 17 May 2014

NFV and SDN - Evolution Themes and Timelines


We recently held our first Virtual Networks SIG event in Cambridge Wireless. There were some great presentations. The one by the UK operator EE summarised everything quite well. For those who are not familiar with what NFV and SDN is, I would recommend watching the video on my earlier post here.

One of the term that keeps being thrown around is 'Orchestration'. While I think I understand what it means, there is no easy way to explain it. Here are some things I found on the web that may explain it:
Orchestration means Automation, Provisioning, Coordination and Management of Physical and Virtual resources.  
Intelligent service orchestration primarily involves the principles of SDN whereby switches, routers and applications at Layer 7 can be programmed from a centralized component called the controller with intelligent decisions regarding individual flow routing in real time.
If you can provide a better definition, please do so.
There are quite a few functions and services that can be virtualised and there are some ambitious timelines.

ETSI has been working on NFV and as I recently found out (see tweet below) there may be some 3GPP standardisation activity starting soon.
Anyway, here is the complete presentation by EE:



There was another brilliant presentation by Huawei but the substance was more in the talk, rather than the slides. The slides are here in case you want to see and download.

Related post:



Friday 18 April 2014

International LTE Data and VoLTE Roaming - NTT Docomo


Quick recap of the Bearer Architecture: Remember the interface between S-GW and P-GW is known as S5/S8. S5 in case the S-GW and P-GW are part of the same network (non-roaming case) and S8 in case where P-GW belongs to another network than S-GW (roaming case). The S5/S8 interfaces are generally exactly the same. There is a possibility of different types of S5/S8 interfaces like GTP based and PMIP based but lets not discuss that here.

NTT Docomo published an excellent article in their magazine recently showing the different approaches to International Data roaming.


The different scenarios above are based on the guidelines provided in GSMA PRD IR.88. Each operator has to adopt one of the scenarios above, NTT Docomo has selected scenario 4. The Home PLMN (HPLMN) and the Visited PLMN (VPLMN) connect via IP eXchange (IPX).


As can be seen above, the MME in VPLMN communicates with HSS in HPLMN using Diameter Edge Agent (DEA).



Finally, it is well known that NTT Docomo is not launching VoLTE untill 2015. The above is their proposal on how they handle VoLTE while in Japan and when roaming.

The paper is an interesting read, embedded below:



Another article worth a read is the VoLTE roaming with RAVEL here.

Sunday 23 March 2014

Securing the backhaul with the help of LTE Security Gateway


An excellent presentation from the LTE World Summit last year, that is embedded below. The slide(s) that caught my attention was the overhead involved when using the different protocols. As can be seen in the picture above, the Ethernet MTU is 1500 bytes but after removing all the overheads, 1320 bytes are left for data. In case you were wondering, MTU stands for 'maximum transmission unit' and is the largest size packet or frame, specified in octets (8-bit bytes), that can be sent in a packet or frame based network such as the Internet.

Anyway, the presentation is embedded below:


Thursday 13 February 2014

VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)


Voice over LTE or VoLTE has many problems to solve. One of the issues that did not have a clear solution initially was Roaming. iBasis has a whitepaper on this topic here, from which the above picture is taken. The following is what is said above:

The routing of international calls has always been a problem for mobile operators. All too often the answer—particularly in the case of ‘tromboning’ calls all the way back to the home network—has been inelegant and costly. LTE data sessions can be broken out locally, negating the need for convoluted routing solutions. But in a VoIMS environment all of the intelligence that decides how to route the call resides in the home network, meaning that the call still has to be routed back.

The industry’s solution to this issue is Roaming Architecture for Voice over LTE with Local Breakout (RAVEL). Currently in the midst of standardisation at 3GPP, RAVEL is intended to enable the home network to decide, where appropriate, for the VoIMS call to be broken out locally. 

Three quarters of respondents to the survey said they support an industry-wide move to RAVEL for VoLTE roaming. This is emphatic in its enthusiasm but 25 per cent remains a significant share of respondents still to be convinced. Just over half of respondents said they plan to support VoIMS for LTE roaming using the RAVEL architecture, while 12.3 per cent said they would support it, but not using RAVEL.

Until RAVEL is available, 27.4 per cent of respondents said they plan to use home-routing for all VoLTE traffic, while just under one fifth said they would use a non-standard VoLTE roaming solution.

Well, the solution was standardised in 3GPP Release-11. NTT Docomo has an excellent whitepaper (embedded below) explaining the issue and the proposed solution.

In 3GPP Release 11, the VoLTE roaming and interconnection architecture was standardized in cooperation with the GSMA Association. The new architecture is able to implement voice call charging in the same way as circuit-switched voice roaming and interconnection models by routing both C-Plane messages and voice data on the same path. This was not possible with the earlier VoLTE roaming and interconnection architecture.

Anyway, here is the complete whitepaper




Monday 20 January 2014

Different flavours of SRVCC (Single Radio Voice Call Continuity)



Single Radio Voice Call Continuity (SRVCC) has been quietly evolving with the different 3GPP releases. Here is a quick summary of these different flavors

In its simplest form, SRVCC comes into picture when an IMS based VoLTE call is handed over to the existing 2G/3G network as a normal CS call. SRVCC is particularly important when LTE is rolled out in small islands and the operator decided to provide VoLTE based call when in LTE. An alternative (used widely in practice) is to use CS Fallback (CSFB) as the voice option until LTE is rolled out in a wider area. The main problem with CSFB is that the data rates would drop to the 2G/3G rates when the UE falls back to the 2G/3G network during the voice call.



The book "LTE-Advanced: A Practical Systems Approach to Understanding 3GPP LTE Releases 10 and 11 Radio Access Technologies" by Sassan Ahmadi has some detailed information on SRVCC, the following is an edited version from the book:

SRVCC is built on the IMS centralized services (ICS) framework for delivering voice and messaging services to the users regardless of the type of network to which they are attached, and for maintaining service continuity for moving terminals.

To support GSM and UMTS, some modifications in the MSC server are required. When the E-UTRAN selects a target cell for SRVCC handover, it needs to indicate to the MME that this handover procedure requires SRVCC. Upon receiving the handover request, the MME triggers the SRVCC procedure with the MSC server. The MSC then initiates the session transfer procedure to IMS and coordinates it with the circuit-switched handover procedure to the target cell.

Handling of any non-voice packet-switched bearer is by the packet-switched bearer splitting function in the MME. The handover of non-voice packet-switched bearers, if performed, is according to a regular inter-RAT packet-switched handover procedure.

When SRVCC is enacted, the downlink flow of voice packets is switched toward the target circuit-switched network. The call is moved from the packet-switched to the circuit-switched domain, and the UE switches from VoIP to circuit-switched voice.

3GPP Rel-10 architecture has been recommended by GSMA for SRVCC because it reduces both voice interruption time during handover and the dropped call rate compared to earlier configurations. The network controls and moves the UE from E-UTRAN to UTRAN/GERAN as the user moves out of the LTE network coverage area. The SRVCC handover mechanism is entirely network-controlled and calls remain under the control of the IMS core network, which maintains access to subscribed services implemented in the IMS service engine throughout the handover process. 3GPP Rel-10 configuration includes all components needed to manage the time-critical signaling between the user’s device and the network, and between network elements within the serving network, including visited networks during roaming. As a result, signaling follows the shortest possible path and is as robust as possible, minimizing voice interruption time caused by switching from the packet-switched core network to the circuit-switched core network, whether the UE is in its home network or roaming. With the industry aligned around the 3GPP standard and GSMA recommendations, SRVCC-enabled user devices and networks will be interoperable, ensuring that solutions work in many scenarios of interest.

Along with the introduction of the LTE radio access network, 3GPP also standardized SRVCC in Rel-8 specifications to provide seamless service continuity when a UE performs a handover from the E-UTRAN to UTRAN/GERAN. With SRVCC, calls are anchored in the IMS network while the UE is capable of transmitting/ receiving on only one of those access networks at a given time, where a call anchored in the IMS core can continue in UMTS/GSM networks and outside of the LTE coverage area. Since its introduction in Rel-8, the SRVCC has evolved with each new release, a brief summary of SRVCC capability and enhancements are noted below

3GPP Rel-8: Introduces SRVCC for voice calls that are anchored in the IMS core network from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN circuit-switched. To support this functionality, 3GPP introduced new protocol interface and procedures between MME and MSC for SRVCC from E-UTRAN to UTRAN/GERAN, between SGSN and MSC for SRVCC from UTRAN (HSPA) to UTRAN/GERAN, and between the MME and a 3GPP2-defined interworking function for SRVCC from E-UTRAN to CDMA 2000.

3GPP Rel-9: Introduces the SRVCC support for emergency calls that are anchored in the IMS core network. IMS emergency calls, placed via LTE access, need to continue when SRVCC handover occurs from the LTE network to GSM/UMTS/CDMA2000 networks. This evolution resolves a key regulatory exception. This enhancement supports IMS emergency call continuity from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/ GERAN circuit-switched network. Functional and interface evolution of EPS entities were needed to support IMS emergency calls with SRVCC.

3GPP Rel-10: Introduces procedures of enhanced SRVCC including support of mid-call feature during SRVCC handover (eSRVCC); support of SRVCC packet-switched to circuit-switched transfer of a call in alerting phase (aSRVCC); MSC server-assisted mid-call feature enables packet-switched/ circuit-switched access transfer for the UEs not using IMS centralized service capabilities, while preserving the provision of mid-call services (inactive sessions or sessions using the conference service). The SRVCC in alerting phase feature adds the ability to perform access transfer of media of an instant message session in packet-switched to circuit-switched direction in alerting phase for access transfers.

3GPP Rel-11: Introduces two new capabilities: single radio video call continuity for 3G-circuit-switched network (vSRVCC); and SRVCC from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC). The vSRVCC feature provides support of video call handover from E-UTRAN to UTRAN-circuitswitched network for service continuity when the video call is anchored in IMS and the UE is capable of transmitting/receiving on only one of those access networks at a given time. Service continuity from UTRAN/GERAN circuitswitched access to E-UTRAN/HSPA was not specified in 3GPP Rel-8/9/10. To overcome this drawback, 3GPP Rel-11 provided support of voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. To enable video call transfer from E-UTRAN to UTRAN-circuit-switched network, IMS/EPC is evolved to pass relevant information to the EPC side and S5/S11/Sv/Gx/Gxx interfaces are enhanced for video bearer-related information transfer. To support SRVCC from GERAN to E-UTRAN/HSPA, GERAN specifications are evolved to enable a mobile station and base station sub-system to support seamless service continuity when a mobile station hands over from GERAN circuit-switched access to EUTRAN/ HSPA for a voice call. To support SRVCC from UTRAN to EUTRAN/ HSPA, UTRAN specifications are evolved to enable the RNC to perform rSRVCC handover and to provide relative UE capability information to the RNC.

NTT Docomo has a presentation on SRVCC and eSRVCC which is embedded below:



Tuesday 29 October 2013

ANDSF: Evolution and Roaming with Hotspot 2.0


Access Network Discovery and Selection Function (ANDSF) is still evolving and with the introduction of Hotspot 2.0 (HS 2), there is a good possibility to provide seamless roaming from Cellular to Wi-Fi, Wi-Fi to Wi-Fi and Wi-Fi to Cellular.


There is a good paper (not very recent) by Alcatel-Lucent and BT that explains these roaming scenarios and other ANDSF policies related information very well. Its embedded below:




Tuesday 15 October 2013

What is Network Function Virtualisation (NFV)?


Software Defined Networking (SDN) and Network Function Virtualization (NFV) are the two recent buzzwords taking the telecoms market by storm. Every network vendor now has some kind of strategy to use this NFV and SDN to help operators save money. So what exactly is NFV? I found a good simple video by Spirent that explains this well. Here it is:


To add a description to this, I would borrow an explanation and a very good example from Wendy Zajack, Director Product Communications, Alcatel-Lucent in ALU blog:

Let’s take this virtualization concept to a network environment. For me cloud means I can get my stuff where ever I am and on any device –  meaning I can pull out my smart phone, my iPad, my computer – and show my mom the  latest pictures of  her grand kids.  I am not limited to only having one type of photo album I put my photos in – and only that. I can also show her both photos and videos together – and am not just limited to showing her the kids in one format and on one device.
Today in a telecom network is a lot of equipment that can only do one thing.  These machines are focused on what they are do and they do it really well – this is why telecom providers are considered so ‘trusted.’ Back in the days of landline phones even when the power was out you could always make a call.  These machines run alone with dedicated resources.  These machines are made by various different vendors and speak various languages or ‘protocols’ to exchange information with each other when necessary. Some don’t even talk at all – they are just set-up and then left to run.  So, every day your operator is running a mini United Nations and corralling that to get you to access all of your stuff.  But it is a United Nations with a fixed number of seats, and with only a specific nation allowed to occupy a specific seat, with the seat left unused if there was a no-show. That is a lot of underutilized equipment that is tough and expensive to manage.  It also has a shelf life of 15 years… while your average store-bought computer is doubling in speed every 18 months.
Virtualizing the network means the ability to run a variety of applications (or functions) on a standard piece of computing equipment, rather than on dedicated, specialized processors and equipment, to drive lower costs (more value), more re-use of the equipment between applications (more sharing), and a greater ability to change what is using the equipment to meet the changing user needs (more responsiveness).  This has already started in enterprises as a way to control IT costs and improve the performance and of course way greener.
To give this a sports analogy – imagine if in American football instead of having specialists in all the different positions (QB, LB, RB, etc), you had a bunch of generalists who could play any position – you might only need a 22 or 33 man squad (2 or 3 players for every position) rather than the normal squad of  53.   The management of your team would be much simpler as ‘one player fits all’ positions.   It is easy to see how this would benefit a service provider – simplifying the procurement and management of the network elements (team) and giving them the ability to do more, with less.

Dimitris Mavrakis from Informa wrote an excellent summary from the IIR SDN and NFV conference in Informa blog here. Its worth reading his article but I want to highlight one section that shows how the operators think deployment would be done:

The speaker from BT provided a good roadmap for implementing SDN and NFV:
  1. Start with a small part of the network, which may not be critical for the operation of the whole. Perhaps introduce incremental capacity upgrades or improvements in specific and isolated parts of the network.
  2. Integrate with existing OSS/BSS and other parts of the network.
  3. Plan a larger-scale rollout so that it fits with the longer-term network strategy.
Deutsche Telecom is now considered to be deploying in the first phase, with a small trial in Hrvatski Telecom, its Croatian subsidiary, called Project Terrastream. BT, Telefonica, NTT Communications and other operators are at a similar stage, although DT is considered the first to deploy SDN and NFV for commercial network services beyond the data center.
Stage 2 in the roadmap is a far more complicated task. Integrating with existing components that may perform the same function but are not virtualized requires east-west APIs that are not clearly defined, especially when a network is multivendor. This is a very active point of discussion, but it remains to be seen whether Tier-1 vendors will be willing to openly integrate with their peers and even smaller, specialist vendors. OSS/BSS is also a major challenge, where multivendor networks are controlled by multiple systems and introducing a new service may require risking several parameters in many of these OSS/BSS consoles. This is another area that is not likely to change rapidly but rather in small, incremental steps.
The final stage is perhaps the biggest barrier due to the financial commitment and resources required. Long-term strategy may translate to five or even 10 years ahead – when networks are fully virtualized – and the economic environment may not allow such bold investments. Moreover, it is not clear if SDN and NFV guarantee new services and revenues outside the data center or operator cloud. If they do not, both technologies – and similar IT concepts – are likely to be deployed incrementally and replace equipment that reaches end-of-life. Cost savings in the network currently do not justify forklift upgrades or the replacement of adequately functional network components.
There is also a growing realization that bare-metal platforms (i.e., the proprietary hardware-based platforms that power today’s networks) are here to stay for several years. This hardware has been customized and adapted for use in telecom networks, allowing high performance for radio, core, transport, fixed and optical networks. Replacing these high-capacity components with virtualized ones is likely to affect performance significantly and operators are certainly not willing to take the risk of disrupting the operation of their network.
A major theme at the conference was that proprietary platforms (particularly ATCA) will be replaced by common off-the-shelf (COTS) hardware. ATCA is a hardware platform designed specifically for telecoms, but several vendors have adapted the platform to their own cause, creating fragmentation, incompatibility and vendor lock-in. Although ATCA is in theory telecoms-specific COTS, proprietary extensions have forced operators to turn to COTS, which is now driven by IT vendors, including Intel, HP, IBM, Dell and others.


ETSI has just published first specifications on NFV. Their press release here says:

ETSI has published the first five specifications on Network Functions Virtualisation (NFV). This is a major milestone towards the use of NFV to simplify the roll-out of new network services, reduce deployment and operational costs and encourage innovation.
These documents clearly identify an agreed framework and terminology for NFV which will help the industry to channel its efforts towards fully interoperable NFV solutions. This in turn will make it easier for network operators and NFV solutions providers to work together and will facilitate global economies of scale.
The IT and Network industries are collaborating in ETSI's Industry Specification Group for Network Functions Virtualisation (NFV ISG) to achieve a consistent approach and common architecture for the hardware and software infrastructure needed to support virtualised network functions. Early NFV deployments are already underway and are expected to accelerate during 2014-15. These new specifications have been produced in less than 10 months to satisfy the high industry demand – NFV ISG only began work in January 2013.
NFV ISG was initiated by the world's leading telecoms network operators. The work has attracted broad industry support and participation has risen rapidly to over 150 companies of all sizes from all over the world, including network operators, telecommunication equipment vendors, IT vendors and technology providers. Like all ETSI standards, these NFV specifications have been agreed by a consensus of all those involved.
The five published documents (which are publicly available via www.etsi.org/nfv) include four ETSI Group Specifications (GSs) designed to align understanding about NFV across the industry. They cover NFV use cases, requirements, the architectural framework, and terminology. The fifth GS defines a framework for co-ordinating and promoting public demonstrations of Proof of Concept (PoC) platforms illustrating key aspects of NFV. Its objective is to encourage the development of an open ecosystem by integrating components from different players.
Work is continuing in NFV ISG to develop further guidance to industry, and more detailed specifications are scheduled for 2014. In addition, to avoid the duplication of effort and to minimise fragmentation amongst multiple standards development organisations, NFV ISG is undertaking a gap analysis to identify what additional work needs to be done, and which bodies are best placed to do it.
The ETSI specifications are available at: http://www.etsi.org/technologies-clusters/technologies/nfv

The first document that shows various use cases is embedded below:


Monday 23 September 2013

Push to talk (PTT) via eMBMS


I was talking about push to share back in 2007 here. Now, in a recent presentation (embedded below) from ALU, eMBMS has been suggested as a a solution for PTT like services in case of Public safety case. Not sure if or when we will see this but I hope that its sooner rather than later. Anyway, the presentation is embedded below. Feel free to add your comments:



Sunday 25 August 2013

Centralized SON


I was going through the presentation by SKT that I blogged about here and came across this slide above. SKT is clearly promoting the benefits of their C-SON (centralized SON) here.


The old 4G Americas whitepaper (here) explained the differences between the three approaches; Centralized (C-SON), Distributed (D-SON) and Hybrid (H-SON). An extract from that paper here:

In a centralized architecture, SON algorithms for one or more use cases reside on the Element Management System (EMS) or a separate SON server that manages the eNB's. The output of the SON algorithms namely, the values of specific parameters, are then passed to the eNB's either on a periodic basis or when needed. A centralized approach allows for more manageable implementation of the SON algorithms. It allows for use case interactions between SON algorithms to be considered before modifying SON parameters. However, active updates to the use case parameters are delayed since KPIs and UE measurement information must be forwarded to a centralized location for processing. Filtered and condensed information are passed from the eNB to the centralized SON server to preserve the scalability of the solution in terms of the volume of information transported. Less information is available at the SON server compared to that which would be available at the eNB. Higher latency due to the time taken to collect UE information restricts the applicability of a purely centralized SON architecture to those algorithms that require slower response time. Furthermore, since the centralized SON server presents a single point of failure, an outage in the centralized server or backhaul could result in stale and outdated parameters being used at the eNB due to likely less frequent updates of SON parameters at the eNB compared to that is possible in a distributed solution.

In a distributed approach, SON algorithms reside within the eNB’s, thus allowing autonomous decision making at the eNB's based on UE measurements received on the eNB's and additional information from other eNB's being received via the X2 interface. A distributed architecture allows for ease of deployment in multi-vendor networks and optimization on faster time scales. Optimization could be done for different times of the day. However, due to the inability to ensure standard and identical implementation of algorithms in a multi-vendor network, careful monitoring of KPIs is needed to minimize potential network instabilities and ensure overall optimal operation.

In practical deployments, these architecture alternatives are not mutually exclusive and could coexist for different purposes, as is realized in a hybrid SON approach. In a hybrid approach, part of a given SON optimization algorithm are executed in the NMS while another part of the same SON algorithm could be executed in the eNB. For example, the values of the initial parameters could be done in a centralized server and updates and refinement to those parameters in response to the actual UE measurements could be done on the eNB's. Each implementation has its own advantages and disadvantages. The choice of centralized, distributed or hybrid architecture needs to be decided on a use-case by use case basis depending on the information availability, processing and speed of response requirements of that use case. In the case of a hybrid or centralized solution, a practical deployment would require specific partnership between the infrastructure vendor, the operator and possibly a third party tool company. Operators can choose the most suitable approach depending upon the current infrastructure deployment.

Finally, Celcite CMO recently recently gave an interview on this topic on Thinksmallcell here. An extract below:

SON software tunes and optimises mobile network performance by setting configuration parameters in cellsites (both large and small), such as the maximum RF power levels, neighbour lists and frequency allocation. In some cases, even the antenna tilt angles are updated to adjust the coverage of individual cells.

Centralised SON (C-SON) software co-ordinates all the small and macrocells, across multiple radio technologies and multiple vendors in a geographic region - autonomously updating parameters via closed loop algorithms. Changes can be as frequent as every 15 minutes– this is partly limited by the bottlenecks of how rapidly measurement data is reported by RAN equipment and also the capacity to handle large numbers of parameter changes. Different RAN vendor equipment is driven from the same SON software. A variety of data feeds from the live network are continuously monitored and used to update system performance, allowing it to adapt automatically to changes throughout the day including outages, population movement and changes in services being used.

Distributed SON (D-SON) software is autonomous within each small cell (or macrocell) determining for itself the RF power level, neighbour lists etc. based on signals it can detect itself (RF sniffing) or by communicating directly with other small cells.

LTE has many SON features already designed in from the outset, with the X.2 interface specifically used to co-ordinate between small and macrocell layers whereas 3G lacks SON standards and requires proprietary solutions.
C-SON software is available from a relatively small number of mostly independent software vendors, while D-SON is built-in to each small cell or macro node provided by the vendor. Both C-SON and D-SON will be needed if network operators are to roll out substantial numbers of small cells quickly and efficiently, especially when more tightly integrated into the network with residential femtocells.

Celcite is one of the handful of C-SON software solution vendors. Founded some 10 years ago, it has grown organically by 35% annually to 450 employees. With major customers in both North and South America, the company is expanding from 3G UMTS SON technology and is actively running trials with LTE C-SON.

Quite a few companies are claiming to be in the SON space, but Celcite would argue that there are perhaps only half a dozen with the capabilities for credible C-SON solutions today. Few companies can point to live deployments. As with most software systems, 90% of the issues arise when something goes wrong and it's those "corner cases" which take time to learn about and deal with from real-world deployment experience.

A major concern is termed "Runaway SON" where the system goes out of control and causes tremendous negative impact on the network. It's important to understand when to trigger SON command and when not to. This ability to orchestrate and issue configuration commands is critical for a safe, secure and effective solution.

Let me know your opinions via comments below.

Sunday 30 June 2013

Multi-RAT mobile backhaul for Het-Nets

Recently got another opportunity to hear from Andy Sutton, Principal Network Architect, Network Strategy, EE. His earlier presentation from our Cambridge Wireless event is here. There were many interesting bits in this presentation and some of the ones I found interesting is as follows:

Interesting to see in the above that the LTE traffic in the backhaul is separated by the QCI (QoS Class Identifiers - see here) as opposed to the 2G/3G traffic.




This is EE's implementation. As you may notice 2G and 4G use SRAN (Single RAN) while 3G is separate. As I mentioned a few times, I think 3G networks will probably be switched off before the 2G networks, mainly because there are a lot more 2G M2M devices that requires little data to be sent and not consume lots of energy (which is an issue in 3G), so this architecture may be suited well.


Finally, a practical network implementation which looks different from the text book picture and the often touted 'flat' architecture. Andy did mention that they see a ping latency of 30-50ms in the LTE network as opposed to around 100ms in the UMTS networks.


Mark Gilmour was able to prove this point practically.

Here is the complete presentation:



Tuesday 28 May 2013

NEC on 'Radio Access Network' (RAN) Sharing

Its been a while we looked at anything to do with Network Sharing. The last post with an embed from Dr. Kim Larsen presentation, has already crossed 11K+ views on slideshare. Over the last few years there has been a raft of announcements about various operators sharing their networks locally with the rivals to reduce their CAPEX as well as their OPEX. Even though I understand the reasons behind the network sharing I believe that the end consumers end up losing as they may not have a means of differentiating between the different operators on a macro cell.

Certain operators on the other hand offer differentiators like residential femtocells that can enhance indoor coverage or a tie up with WiFi hotspot providers which may provide them wi-fi access on the move. The following whitepaper from NEC is an interesting read to understanding how RAN sharing in the LTE would work.



Saturday 23 March 2013

LTE for Public Safety Networks

The last presentation on this topic couple of months back has reached nearly 7K views so here is another one from a recent article on the same topic from IEEE Communications Magazine



Thursday 14 March 2013

What is WebRTC and where does it fit with LTE and IMS

This simple video from MWC should give an idea on what WebRTC is and can do:


So what exactly WebRTC is in technical terms. Here is a recent presentation from WebRTC Conference and Expo



And here is another presentation that explains where it fits in with the LTE Architecture.



Dean Bubley from Disruptive Analysis has writted extensively on this topic and his recent post "Is the telephony "threat" from VoIP & WebRTC about competition or contextualisation?" is an interesting read.

Iain Sharp from Netovate recently pointed out that 3GPP have 'nearly' approved a work item for WebRTC access to IMS.

It would be interesting to see how operators will view WebRTC. As an opportunity or as a threat. Please feel free to air your opinions via comments.

Wednesday 27 February 2013

Wi-Fi & Packet Core (EPC) Integration

Yesterday I wrote a blog post on whether Wi-Fi is the third RAN in the Metrocells blog. Today I am posting this excellent presentation that details how this Wi-Fi integration with EPC will be done.



Monday 15 October 2012

Machine Type Communications (MTC): Architecture, Features, Standards in 3GPP Rel-10



The following 14 MTC Features have been identified during the 3GPP Release-10 timelines:


  • Low Mobility
  • Time Controlled
  • Time Tolerant
  • Packet Switched (PS) Only
  • Small Data Transmissions
  • Mobile Originated Only
  • Infrequent Mobile Terminated
  • MTC Monitoring
  • Priority Alarm Message (PAM)
  • Secure Connection
  • Location Specific Trigger
  • Network Provided Destination for Uplink Data
  • Infrequent Transmission
  • Group Based MTC Features




In Rel 10, 3GPP will focus on the general functionality required to support these features:

  • Overload control (Radio Network Congestion use case, Signalling Network Congestion use case and Core Network Congestion use case)
  • Addressing
  • Identifiers
  • Subscription control
  • Security



The following specifications are associated with the MTC work

Spec   - Specifications associated with or affected by MTC work
22.011 - Service accessibility
22.368 - Service requirements for Machine-Type Communications (MTC); Stage 1
23.008 - Organization of subscriber data
23.012 - Location management procedures
23.060 - General Packet Radio Service (GPRS); Service description; Stage 2
23.122 - Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode
23.203 - Policy and charging control architecture
23.401 - General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
23.402 - Architecture enhancements for non-3GPP accesses
23.888 - System improvements for Machine-Type Communications (MTC)
24.008 - Mobile radio interface Layer 3 specification; Core network protocols; Stage 3
24.301 - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
24.368 - Non-Access Stratum (NAS) configuration Management Object (MO)
25.331 - Radio Resource Control (RRC); Protocol specification
29.002 - Mobile Application Part (MAP) specification
29.018 - General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification
29.060 - General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface
29.118 - Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification
29.274 - 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
29.275 - Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage 3
29.282 - Mobile IPv6 vendor specific option format and usage within 3GPP
31.102 - Characteristics of the Universal Subscriber Identity Module (USIM) application
33.868 - Security aspects of Machine-Type Communications
36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification
37.868 - RAN Improvements for Machine-type Communications
43.868 - GERAN Improvements for Machine-type Communications
44.018 - Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol
44.060 - General Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control / Medium Access Control (RLC/MAC) protocol
45.002 - Multiplexing and multiple access on the radio path


Here are couple of presentations I have extracted the above information from: