Showing posts with label LTE. Show all posts
Showing posts with label LTE. Show all posts

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:



Saturday 29 June 2013

Timing Accuracy and Phase Performance Requirements in LTE/LTE-A/4G

Nice quick summary videos from Chronos.



If you are interested in learning more on this topic or discussions, I would recommend joining the Phase Ready Linkedin group.

Thursday 20 June 2013

Economical M2M using LTE - #LTEWS

In the upcoming LTE World Summit 2013 (programme here), I will be doing a briefing on the topic 'Economical M2M using LTE'. I have some ideas but I would like to hear more on what you think? In fact, is LTE the right technology from the M2M device point of view? Or do they better stick to 2G (I dont think 3G is good enough generally from low data M2M point of view). What other issues can be foreseen? Security? Roaming?
A recent presentation from Telefonica shows how they are partnering with other operators worldwide to create universal solutions. Will this help? Why not use these solutions for everything, not just LTE? LTE is data only technology isn't it?

The presentation is embedded below to draw your own conclusion but I an interested in hearing your thoughts on Twitter or here on the blog.

Monday 3 June 2013

New Carrier Type (NCT) in Release-12 and Band 29

One of the changes being worked on and is already available in Release-11 is the Band 29. Band 29 is a special FDD band which only has a downlink component and no uplink component. The intention is that this band is available an an SCell (Secondary cell) in CA (Carrier Aggregation). 

What this means is that if this is only available as an SCell, any UE that is pre-Rel-11 should not try to use this band. It should not read the system information, reference information, etc. In fact the System Information serves little or no purpose as in CA, the PCell will provide the necessary information for this SCell when adding it using the RRC Reconfiguration message. This gives rise to what 3GPP terms as New Carrier Type for LTE as defined here. An IEEE paper published not long back is embedded below that also describes this feature in detail. 

The main thing to note from the IEEE paper is what they have shown as the unnecessary information being removed to make the carrier lean.

China Mobile, in their Rel-12 workshop presentation, have suggested 3 different types/possibilities for the NCT for what they call as LTE-Hi (Hi = Hotspot and Indoor).

Ericsson, in their Rel-12 whitepaper mention the following with regards to NCT:

Network energy efficiency is to a large extent an implementation issue. However, specific features of the LTE technical specifications may improve energy efficiency. This is especially true for higher-power macro sites, where a substantial part of the energy consumption of the cell site is directly or indirectly caused by the power amplifier.

The energy consumption of the power amplifiers currently available is far from proportional to the power-amplifier output power. On the contrary, the power amplifier consumes a non-negligible amount of energy even at low output power, for example when only limited control signaling is being transmitted within an “empty” cell.

Minimizing the transmission activity of such “always-on” signals is essential, as it allows base stations to turn off transmission circuitry when there is no data to transmit. Eliminating unnecessary transmissions also reduces interference, leading to improved data rates at low to medium load in both homogeneous as well as heterogeneous deployments.

A new carrier type is considered for Release 12 to address these issues. Part of the design has already taken place within 3GPP, with transmission of cell-specific reference signals being removed in four out of five sub frames. Network energy consumption can be further improved by enhancements to idle-mode support.

The IEEE paper I mentioned above is as follows:



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.



Wednesday 15 May 2013

Access Class Barring in LTE using System Information Block Type 2


As per 3GPP TS 22.011 (Service accessibility):

All UEs are members of one out of ten randomly allocated mobile populations, defined as Access Classes (AC) 0 to 9. The population number is stored in the SIM/USIM. In addition, UEs may be members of one or more out of 5 special categories (Access Classes 11 to 15), also held in the SIM/USIM. These are allocated to specific high priority users as follows. (The enumeration is not meant as a priority sequence):
Class 15 - PLMN Staff;
 -"-  14 - Emergency Services;
 -"-  13 - Public Utilities (e.g. water/gas suppliers);
 -"-  12 - Security Services;
 -"-  11 - For PLMN Use.

Now, in case of an overload situation like emergency or congestion, the network may want to reduce the access overload in the cell. To reduce the access from the UE, the network modifies the SIB2 (SystemInformationBlockType2) that contains access barring related parameters as shown below:




For regular users with AC 0 – 9, their access is controlled by ac-BarringFactor and ac-BarringTime. The UE generates a random number
– “Rand” generated by the UE has to pass the “persistent” test in order for the UE to access. By setting ac-BarringFactor to a lower value, the access from regular user is restricted (UE must generate a “rand” that is lower than the threshold in order to access) while priority users with AC 11 – 15 can access without any restriction

For users initiating emergency calls (AC 10) their access is controlled by ac-BarringForEmergency – boolean value: barring or not

For UEs with AC 11- 15, their access is controlled by ac-BarringForSpecialAC - boolean value: barring or not.


The network (E-UTRAN) shall be able to support access control based on the type of access attempt (i.e. mobile originating data or mobile originating signalling), in which indications to the UEs are broadcasted to guide the behaviour of UE. E-UTRAN shall be able to form combinations of access control based on the type of access attempt e.g. mobile originating and mobile terminating, mobile originating, or location registration.  The ‘mean duration of access control’ and the barring rate are broadcasted for each type of access attempt (i.e. mobile originating data or mobile originating signalling).

Another type of Access Control is the Service Specific Access Control (SSAC) that we have seen here before. SSAC is used to apply independent access control for telephony services (MMTEL) for mobile originating session requests from idle-mode.

Access control for CSFB provides a mechanism to prohibit UEs to access E-UTRAN to perform CSFB. It minimizes service availability degradation (i.e. radio resource shortage, congestion of fallback network) caused by mass simultaneous mobile originating requests for CSFB and increases the availability of the E-UTRAN resources for UEs accessing other services.  When an operator determines that it is appropriate to apply access control for CSFB, the network may broadcast necessary information to provide access control for CSFB for each class to UEs in a specific area. The network shall be able to separately apply access control for CSFB, SSAC and enhanced Access control on E-UTRAN.

Finally, we have the Extended Access Barring (EAB) that I have already described here before.

Thursday 9 May 2013

eMBMS Physical layer aspects from T&M point of view

Based on the success of the recent posts on eMBMS, here and here, this final post on this topic is a look at physical layer perspective from Test and Measurement point of view. Slides kindly provided by R&S



A video of this is also available on Youtube, embedded below:

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 23 January 2013

LTE-B, LTE-C, ... , LTE-X

Please make sure to read the comment from Kevin Flynn of 3GPP at the end


When I saw this picture above, I started wondering what LTE-B, etc. and started digging a bit deep. Came across this Ericsson presentation (embedded below) that shows the breakdown.

To just be sure that this is not Ericsson specific term, I also found a presentation by NTT Docomo (embedded below)
So I guess using LTE-B, LTE-C, etc. is better than saying 4.1G, 4.2G, etc. as we did in case of 3G/HSPA.


The presentations from Ericsson and NTT Docomo embedded below, available to download from Slideshare.






Thursday 13 December 2012

Half Duplex Operation (HD-FDD) in LTE



It was interesting to hear the other day that there is an option for HD-FDD but it is still undergoing investigation and not standardised yet. From what I hear, operators are showing an interest and we may see it coming to an operator near us in the next couple of years.

Complete presentation below:



The advantages are obvious but probably the only reason this was not standardised actively is probably because then peak rates often quoted when promoting technology will be halved. The economy of scale is also important and we may not see this becoming popular unless many operators decide together to push for this.

Other posts of interest:



Monday 26 November 2012

'LTE' and 'Small Cells' specific applications

Some 4 years back, I posted my first presentation here, titled "LTE Femtocells: Stepping stone for 'killer apps' presentation". I had couple of apps in mind that I thought could benefit from both LTE and Small Cells (or Femtocells to be specific).

The first was your phone acting as a Wireless Hard Disk Drive (HDD) that can be used to store things remotely in a server somewhere. This is similar to what is known as the Cloud nowadays.

Picture Source: Dialaphone.

The other day when I read why LTE is suitable for cloud connectivity, I could see that my old idea could start to become a reality. The article is here. Selective abstract as follows:


The LTE network lends itself well to cloud connectivity because it:
  • provides high-bandwidth connections
  • is IP- and Ethernet-oriented, the technologies used to connect to the cloud and within data centers
  • offers tools that operators didn't have in 2G and 3G (such as more granular ability to manage traffic flows and a better, DPI-based view of traffic running on the network)
  • features low latency, which is vital to the small flows and sessions that characterize M2M communications.
The rise of both cloud services and LTE creates a virtuous cycle. Cloud services continue to grow, which helps operators sustain their LTE business model. That growth enables them to accelerate LTE investments. Then operators can support new types of enterprise services, including cloud-based applications.
To take full advantage of this opportunity, operators have to deploy the right backhaul infrastructure. In addition to IP awareness and content awareness, the right backhaul network can leverage the technical advantages that LTE presents:
  • flattened architecture that helps distribute compute and storage resources
  • seamless migration from 2G and 3G for various physical mediums and networking protocols
  • an increase in capacity that starts to put mobile connectivity on par with fixed broadband access.


My reasoning for Small Cell here is, in most cases when you are doing operations that require large amounts of data to be transferred, you will be indoors, either at home or in office or in a low mobility scenario. The requirement for high security and at the same time high speed data transfer that should not be affected by other users in the cell (capacity issues) can be easily solved by using a Small cell (Femtocell for indoors, Metrocell for outdoors).


The other application I had in mind was the Home Security System. I read the following on TotalTele the other day:


3UK's wholesale division on Friday detailed plans to capture high-margin machine-to-machine traffic by partnering with service providers that are likely to have higher-than-average bandwidth requirements.
As a 3G-only operator, the company cannot go after high volume, low margin M2M traffic because it typically only requires a 2G connection. However, there are opportunities to use its 3G network to address more data-hungry verticals that will generate higher traffic volumes.
"The margin on one CCTV M2M connection is more than 50 times bigger than the margin on a smart meter connection," claimed Tom Gardner, lead wholesale manager at 3UK, during Breakfast with Total Telecom in London.
"There is one CCTV camera for every 14 people in the U.K.," he said. "If I can put a SIM in every one of them I'll be a very happy man."
3UK, which on Thursday launched its Ericsson-based wholesale M2M platform, sees a big opportunity in CCTV, particularly for mobile and temporary installations at festivals, for instance. Other potentially lucrative sectors it has identified include digital signage, back-up for fixed Internet connections, and backhauling WiFi traffic from public transport.


I am sure some of you may be thinking that '3' UK uses HSPA network, not LTE, which is true. The point here is that it could be done better using LTE and Small Cells.

The reason for using LTE would be to provide higher data rates, meaning that information can be sent faster, with higher resolution and more regularly. This will help identify the problems earlier. If the CCTV is used indoors or in high usage areas, it would make sense that it connects via Small Cell to avoid creating capacity issues in the Macro network.

Here is the embed again, of my old presentation just in case if it interests you:




Wednesday 7 November 2012

CSFB Performance

Here is another presentation from Qualcomm from the '4G World'.



With regards to SI Tunneling mentioned in the presentation, I found the following in another Qualcomm whitepapers:


With Release 9 Enhanced Release with Redirection—SI Tunneling, the device follows 3GPP release 9, where SIB information can be tunneled from the target Radio Access Network (RAN) via the core network to the source RAN and be included in the redirection message sent to the device. This can avoid reading any SIBs on the target cell. 

The predominant solutions deployed today are based on Release 8 Release with Redirection — SIB Skipping, in order to achieve good call setup times, good reliability, and simplify deployments. It is anticipated that Release 9 Enhanced Release with Redirection will be deployed in the near future. At this time, there is not as much push for handover-based CSFB since both Release 8 Release with Redirection—SIB Skipping and Release 9 Enhanced Release with Redirection—SI Tunneling have largely addressed any call setup time issues that may have existed with the Basic Release with Redirection solution.


I have blogged on this topic before, here.

More on Dual Radio here and SVLTE here.

Tuesday 6 November 2012

17 LTE Voice Modes

No wonder why LTE chipsets are complicated.


From Qualcomm's presentation in 4G World, available here.

Tuesday 16 October 2012

Extended Access Barring (EAB) in Release 11 to avoid MTC overload

M2M is going to be big. With the promise of 50 Billion devices by 2020, the networks are already worried about the overloading due to signalling by millions of devices occurring at any given time. To counter this, they have been working on avoiding overloading of the network for quite some time as blogged about here.

The feature to avoid this overload is known as Extended Access Barring (EAB). For E-UTRAN, in Rel-10, a partial solution was implemented and a much better solution has been implemented in Rel-11. For GERAN a solution was implemented in Rel-10. The following presentation gives a high level overview of EAB for E-UTRAN and GERAN.



In Rel-11, a new System Information Block (SIB 14) has been added that is used specifically for EAB. Whereas in Rel-10, the UE would still send the RRCConnectionRequest, in Rel-11, the UE does not even need to do that, thereby congesting the Random Access messages.

The following is from RRC 36.331 (2012-09)
***

–                SystemInformationBlockType14

The IE SystemInformationBlockType14 contains the EAB parameters.
SystemInformationBlockType14 information element
-- ASN1START

SystemInformationBlockType14-r11 ::= SEQUENCE {
    eab-Param-r11                        CHOICE {
       eab-Common-r11                       EAB-Config-r11,
       eab-PerPLMN-List-r11                 SEQUENCE (SIZE (1..6)) OF EAB-ConfigPLMN-r11
    }                                                  OPTIONAL, -- Need OR
    lateNonCriticalExtension             OCTET STRING          OPTIONAL, -- Need OP
    ...
}

EAB-ConfigPLMN-r11 ::=               SEQUENCE {
    eab-Config-r11                   EAB-Config-r11            OPTIONAL -- Need OR
}

EAB-Config-r11 ::=               SEQUENCE {
    eab-Category-r11                 ENUMERATED {a, b, c, spare},
    eab-BarringBitmap-r11            BIT STRING (SIZE (10))
}

-- ASN1STOP

SystemInformationBlockType14 field descriptions
eab-BarringBitmap
Extended access class barring for AC 0-9. The first/ leftmost bit is for AC 0, the second bit is for AC 1, and so on.
eab-Category
Indicates the category of UEs for which EAB applies. Value a corresponds to all UEs, value b corresponds to the UEs that are neither in their HPLMN nor in a PLMN that is equivalent to it, and value c corresponds to the UEs that are neither in the PLMN listed as most preferred PLMN of the country where the UEs are roaming in the operator-defined PLMN selector list on the USIM, nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN, see TS 22.011 [10].
eab-Common
The EAB parameters applicable for all PLMN(s).
eab-PerPLMN-List
The EAB parameters per PLMN, listed in the same order as the PLMN(s) occur in plmn-IdentityList in SystemInformationBlockType1.

***

Here is my attempt to explain the difference in overload control mechanism in Rel-8, Rel-10 and Rel-11. Please note that not actual message names are used.





As usual, happy to receive feedback, comments, suggestions, etc.