Saturday, 31 August 2013

VoLTE Bearers

While going through Anritsu whitepaper on VoLTE, I found this picture that explains the concepts of bearers in a VoLTE call well. From the whitepaper:

All networks and mobile devices are required to utilize a common access point name (APN) for VoLTE, namely, “IMS”. Unlike many legacy networks, LTE networks employ the “always-on” conception of packet connectivity: Devices have PDN connectivity virtually from the moment they perform their initial attach to the core network. During the initial attach procedure, some devices choose to name the access point through which they prefer to connect. However, mobile devices are not permitted to name the VoLTE APN during initial attach, i.e., to utilize the IMS as their main PDN, but rather to establish a connection with the IMS AP separately. Thus, VoLTE devices must support multiple simultaneous default EPS bearers.

Note that because the VoLTE APN is universal, mobile devices will always connect through the visited PLMN’s IMS PDN-GW. This architecture also implies the non-optionality of the P-CSCF:

As stated, VoLTE sessions employ two or three DRBs. This, in turn, implies the use of one default EPS bearer plus one or two dedicated EPS bearers. The default EPS bearer is always used for SIP signaling and exactly one dedicated EPS bearer is used for voice packets (regardless of the number of active voice media streams.) XCAP signaling may be transported on its own dedicated EPS bearer – for a total of three active EPS bearers – or it may be multiplexed with the SIP signaling on the default EPS bearer, in which case only two EPS bearers are utilized.

My understanding is that initially when the UE is switched on, a default bearer with QCI 9 (see old posts on QoS/QCI here) is established that would be used for all the signalling. Later on, another default bearer with QCI 5 is established with the IMS CN. When a VoLTE call is being setup, a dedicated bearer with QCI 1 is setup for the voice call. As the article says, another dedicated bearer may be needed for XCAP signalling. If a Video call on top of VoLTE is being used than an additional dedicated bearer with QCI 2 will be setup. Note that the voice pat will still be carried by dedicated bearer with QCI 1.

Do you disagree or have more insight, please feel free to add the comment at the end of the post.

The whitepaper is embedded below and is available to download from slideshare.



Related posts:

Thursday, 29 August 2013

New Mobile related terms added in Oxford dictionary

The Oxford dictionary has just added some new words in its dictionary. Here is a summary of the words related to mobiles.

BYOD: n.: abbreviation of 'bring your own device': the practice of allowing the employees of an organisation to use their own computers, smartphones, or other devices for work purposes. Wikipedia also calls it bring your own technology (BYOT), bring your own phone (BYOP), and bring your own PC (BYOPC).

digital detox, n.: a period of time during which a person refrains from using electronic devices such as smartphones or computers, regarded as an opportunity to reduce stress or focus on social interaction in the physical world.

Another term called "Nomophobia" which has unfortunately not yet entered the dictionary refers to as the fear of being out of mobile phone contact. The term, an abbreviation for "no-mobile-phone phobia". According to a recent survey some 54% of Brits have experienced this. If someone is getting affected by Nomophobia, its time they undergo a 'digital detox' to sort their life out.

emoji, n: a small digital image or icon used to express an idea or emotion in electronic communication.


Everyone using OTT applications would know them well. They are very useful in communicating emotions. I generally think this as one of the drawbacks of SMS that we cant use emoji's. On the other hand OTT apps can be making money by providing extended emoji's for a premium but I havent seen anyone do this yet.

FOMO, n.: fear of missing out: anxiety that an exciting or interesting event may currently be happening elsewhere, often aroused by posts seen on a social media website

'FOMO' is big and I personally know people who suffer from this. In the good old days this was known as jealousy where one would be jealous that someone was going on more holidays, have a bigger house/car, etc. In this connected world where we can get Facebook updates and notifications on the phones and tablets the digital term is FOMO. A slide from Mary Meeker's presentation that I put here shows that a typical user checks their phone 150 times every day and social media is not very far from the top.

internet of things, n.: a proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.

This 'Internet of Things' or 'IoT' has been covered in the blog more than enough times.

phablet, n.: a smartphone having a screen which is intermediate in size between that of a typical smartphone and a tablet computer.


Earlier this year I put a post here that talked all about feature phones, smartphones, phablets, etc. Other terms like Tabphones and Phonetabs didn't make it.

selfie, n. (informal): a photograph that one has taken of oneself, typically one taken with a smartphone or webcam and uploaded to a social media website.


Here is a selfie of me using my phone today to end this post :-)

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.

Friday, 23 August 2013

How Cyber-Attacks Can Impact M2M Infrastructure


An Interesting presentation from Deutsche Telekom in the Network Security Conference which highlights some of the issues faced by the M2M infrastructure. With 500 Billion devices being predicted, security will have to be stepped up for the M2M infrastructures to work as expected. Complete presentation embedded below:


Wednesday, 21 August 2013

eIMTA: Enhanced Interference Mitigation & Traffic Adaptation


eIMTA is one of the features being discussed in 3GPP Rel-12. The pictures above and below provide the details.
As can be seen, at the moment all the eNodeB's associated with a network has to transmit the same UL/DL pattern throughout out the system. With eIMTA, each eNodeB can decide the UL/DL pattern itself depending on the load.
The main challenge would be interference management while using this scheme.

See also, this slideshare presentation for details:

Monday, 12 August 2013

C-RAN Architecture and Challenges


I have blogged about Cloud RAN or C-RAN in the Metrocells blog here and am looking forward to more discussions on this topic in the SON conference later this year.


I came across this interesting presentation from Orange in the LTE World Summit this year where the authors have detailed the C-RAN architecture and also discussing the fronthaul challenges faced by C-RAN. The presentation is embedded as follows. Please feel free to add your comments with your opinions.




Thursday, 8 August 2013

2 Factor and 3 Factor Authentication (2FA / 3FA)

Found an interesting slide showing 2 Factor Authentication in picture from a presentation in LTE World Summit


You can also read more about this and Multi-factor Authentication (MFA) on Wikipedia here.

Tuesday, 6 August 2013

M2M, Cellular and Small Cells

I have written a post on this topic in the Cisco Service Provide Mobility blog here. The article is embedded as follows:



Feel free to add any comments you may have on the blog post here.

Friday, 2 August 2013

Mobile Relay Nodes (MRN) in Rel-12


Interesting article in IEEE Comms Magazine (embedded below) about the Moving Relay Node (MRN). 3GPP has done a study on a similar topic available in 3GPP TR 36.836. To make the case for the MRN they provide a reference scenario of high speed train

The TGV Eurostar in Europe is 393 m long, moves at speed reaching 300 km/h. The Shinkansen in Japan has similar characteristics, with 480 m long, 300 km/h of commercial speed. The high speed train in China is 432 m long moving at speed reaching 350 km/h.

Due to fast moving and well shield carriage, the network in high speed train scenario faces severe Doppler frequency shift and high penetration loss, reduced handover success rate and increased power consumption of UEs.


To improve the coverage of the train deployment, access devices can be mounted on the high speed train, providing a wireless backhaul connection via the eNBs along the railway by outer antenna e.g. installed on top of the train, and wireless connectivity to the UEs inside carriages by inner antenna installed inside.

MRN is a good solution but when it has to operate alongside with many other technologies can pose challenges. The IEEE article summarises it as follows:

Furthermore, new challenges regarding interference management arise due to the use of MRNs. As the distance between an MRN and the vehicular UE served by it is very short, the MRN and the vehicular UE can communicate with each other using very low power. In addition, the VPL can further help to dampen the signal of the MRN access link that propagates out from the vehicle. Thus, compared to direct transmission, the use of MRNs generates less interference from the access link, for both downlink and uplink, to UE outside the vehicles. This is appreciated in a densely deployed urban scenario where link availabilities are usually dependent on interference rather than coverage. For the backhaul link, however, the problem becomes complicated, as interference is expected both between different MRN backhaul links, and between MRN backhaul links and macro UE. The use of predictor antennas can improve CSI accuracy to enable the use of advanced interference avoidance and cancellation schemes for the backhaul links. Nevertheless, whether enhancements on the current intercell interference coordination (ICIC) framework in LTE are needed to support the use of MRNs still requires further investigation.

I have been thinking of possible use of 8x8 MIMO, this can be one possible scenario where the network may use 8x8 or even 4x4. Anyway, the complete article is embedded below: