Showing posts with label M2M. Show all posts
Showing posts with label M2M. Show all posts

Friday 13 December 2013

Advancements in Congestion control technology for M2M


NTT Docomo recently published a new article (embedded below) on congestion control approaches for M2M. In their own words:

Since 3GPP Release 10 (Rel. 10) in 2010, there has been active study of technical specifications to develop M2M communications further, and NTT DOCOMO has been contributing proactively to creating these technical specifications. In this article, we describe two of the most significant functions standardized between 3GPP Rel. 10 and Rel. 11: the M2M Core network communications infrastructure, which enables M2M service operators to introduce solutions more easily, and congestion handling technologies, which improve reliability on networks accommodating a large number of terminals.

Complete article as follows:



Other related posts:

Monday 9 December 2013

Rise of the "Thing"

Light Reading carried an interesting cartoon on how M2M works. I wouldnt be surprised if some of the M2M applications at present do work like this. Jokes apart, last week the UK operator EE did a very interesting presentation on Scaling the network for the Rise of the Thing.

A question often asked is "What is the difference between the 'Internet of Things' (IoT) and 'Machine to Machine' (M2M)?". This can generate big discussions and can be a lecture on its own. Quora has a discussion on the same topic here. The picture above from the EE presentation is a good way of showing that M2M is a subset of IoT. 

Its also interesting to note how these 'things' will affect the signalling. I often come across people who tell me that since most M2M devices just use small amounts of data transfer, why is there a need to move from GPRS to LTE. The 2G and 3G networks were designed primarily for Voice with Data secondary function. These networks may work well now but what happens when the predicted 50 Billion connected devices are here by 2020 (or 500 Billion by 2030). The current networks would drown in the control signalling that would often result in congested networks. Congestion control is just one of the things 3GPP is working on for M2M type devices as blogged earlier here. In fact the Qualcomm presentation blogged about before does a decent job of comparing various technologies for IoT, see here.

The EE presentation is embedded as follows:



Another good example website I was recently made aware of is http://postscapes.com/internet-of-things-examples/ - worth checking how IoT would help us in the future.

Friday 13 September 2013

LTE for Utilities and Smart Grids

This has been an area of interest for the last couple of years. Discussions have been centred around, "Is LTE fit for IoT?", "Which technology for IoT", "Is it economical to use LTE for M2M?", "Would small cells be useful for M2M?", etc.

Ericsson has recently published a whitepaper titled "LTE for utilities - supporting smart grids". One of the table that caught my eye is as follows:


LTE would be ideally suited for some of the "Performance class" requirements where the transfer time requirements is less than 100ms. Again, it can always be debated if in many cases WiFi will meet the requirements so should WiFi be used instead of LTE, etc. I will let you form your own conclusions and if you are very passionate and have an opinion, feel free to leave comment.

The whitepaper is embedded below:



Related posts:


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:


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.

Wednesday 31 July 2013

Making LTE fit for the IoT

Another presentation from the #FWIC2013. This presentation by Vodafone covers some of the areas where the LTE standards are being tweaked for making M2M work with them without issues.


Another area is the access barring that I have blogged about before here. This will become important when we have loads of devices trying to access the network at the same time.

The presentation is embedded below and you can also listen to the audio here.


Friday 12 July 2013

Thursday 11 July 2013

Present and Future Technologies for Internet of Things (IoT)

An Interesting presentation from our Future of Wireless Conference (#FWIC2013) in Cambridge earlier this month. A question being asked is what technology will be used for Internet of Things (IoT) or Internet of Everything (IoE) as its also referred to nowadays. These 3 slides below summarises what technologies are see applicable to which scenarios.




Complete slides are embedded below and if you like to see the video, its available here.



Sunday 7 July 2013

500 Billion devices by 2030, etc...

Few weeks back in the LTE World Summit 2013, I heard someone from Ericsson mention that internally they think that by 2030 there will be 500 Billion Connected devices on the planet. The population projections for 2030 is somewhere around 8.5 Billion people worldwide. As a result the figure does not come much as a surprise to me.

John Cunliffe from Ericsson is widely credited for making the statement 50 Billion connected devices by 2020. Recently he spoke in the Cambridge Wireless and defended his forecast on the connected devices. He also provided us with the traffic exploration tool to see how the devices market would look up till 2018. Here is one of the pictures using the tool:



In terms of Cellular connectivity, we are looking at 9 Billion devices by 2018. The interesting thing to notice is that in 2017, there are still some 4 Billion feature phones. While in the developed world our focus is completely on Smartphones, its interesting to see new and existing SMS/USSD based services are still popular in the developing world. Some months back I heard about Facebook developing SMS/USSD based experience for Feature phones, I am sure that would attract a lot of users from the developing world.

One thing missing from the above is non-cellular connections which will make bulk of connectivity. Wi-Fi for example is a major connectivity medium for tablets. In fact 90% of the tablets have only WiFi connectivity. Bluetooth is another popular method of connectivity. While its mostly used in conjunction with phones, it is going to be a popular way of connecting devices in the Personal Area Network's (PAN's). So its no surprise that we will see 50 Billion connected devices but maybe not by 2020. My guess would be around 2022-23.

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 18 March 2013

From M2M Communications to IoT

M2M was again in the news recently when a new report suggested that it would be $1 Trillion industry. Back in december I posted a detailed presentation on M2M that has now crossed over 6K views. This shows that there is an appetite for this topic. So here is a three part presentation on M2M and IoT. In fact as I pointed out in a post last year, it is very often referred to as IoE (Internet of Everything) rather than IoT (Internet of Things). If this is a topic close to your heart then please do come to the Future of Wireless International Conference (FWIC) organised by Cambridge Wireless on 1st and 2nd July 2013. Details here.










Friday 16 November 2012

Evolution of 'Internet of Things' to 'Internet of Everything' #IoE



Will the 'Internet of Humans' and the 'Internet of Things' (IoT) evolve into 'Internet of Everything' (IoE). This is certainly what Dave Evans, the Cisco Futurist thinks. This is from his blog:


From the Internet of Things (IoT), where we are today, we are just beginning to enter a new realm: the Internet of Everything (IoE), where things will gain context awareness, increased processing power, and greater sensing abilities. Add people and information into the mix and you get a network of networks where billions or even trillions of connections create unprecedented opportunities and give things that were silent a voice.

As more things, people, and data become connected, the power of the Internet (essentially a network of networks) grows exponentially. This thinking (“Metcalfe’s law”) comes from Robert Metcalfe, well-known technologist and founder of 3Com, who stated that the value of a network increases proportionately to the square of the number of users. In essence, the power of the network is greater than the sum of its parts, making the Internet of Everything, incredibly powerful.


You can read more here.

See Also:


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.

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:



Tuesday 25 September 2012

LTE, M2M Device Addressing and IMSI


I was made aware of the following statement on the Verizon wireless brochure:

LTE’s inherent support for IPV6 addressing and IMSI-based telephone number identifiers makes mass deployments over LTE more easily achievable. The deployment of large numbers of mobile devices (think tens of thousands) becomes much more feasible because of LTE’s use of 15-digit IMSI telephone number identifiers for large-scale deployments, such as M2M or embedded wireless applications. 3G network technologies were limited by their use of 10-digit telephone number identifiers, which made large-scale deployments more difficult. With LTE, mass deployment of wireless services and applications, such as VoIP, smart metering, vending, and telematics, is now practical.

Now we know about the much touted 50 Billion connections by 2025 of which the majority would be M2M devices. So how are we going to handle the issue of addressing these many devices.

In the earlier presentation here, there was a mention of the direction for the solution as below:





The IMSI structure is as shown above. So depending on how it is used this can help alleviate the number shortage problem. 3GPP TR 23.888 gives the following information:


5.13      Key Issue - MTC Identifiers

5.13.1    Use Case Description

The amount of MTC Devices is expected to become 2 orders of magnitude higher than the amount of devices for human to human communication scenarios. This has to be taken into account for IMSI, IMEI and MSISDN. Regulatory bodies indicate shortages of IMSIs and MSISDNs.
The MTC Feature PS Only in TS 22.368 [2] includes a requirement that PS Only subscriptions shall be possible without an MSISDN. In principle an MSISDN is not used in any of the PS based signalling procedures. However, it will have to be assured that all PS procedures indeed work and subscriptions can be uniquely identified without providing an MSISDN. Furthermore, TS 22.368 [2] specifies that remote MTC Device configuration shall be supported for PS only subscriptions without an MSDISDN assigned. Current remote MTC Device configuration solutions (i.e. Device Management and Over-the-Air configuration) are based on SMS, which assumes the use of MSISDNs. So a solution to support remote MTC Device configuration that does not require the use of MSISDNs is needed.
The identifiers can be categorised into:
-     Internal Identifiers: used within the 3GPP system to identify a UE using a subscription (or the subscription itself e.g. when the UE is not registered).
-     External Identifiers: used from outside the 3GPP system (e.g. at the MTCsp interface), to refer to a UE using a subscription (or the subscription itself e.g. when the UE is not registered).

5.13.2    Required Functionality

-     It shall be possible to uniquely identify the ME.
NOTE 1:   This requirement relates to the ME which is generally identified by the IMEI.
-     It shall be possible to uniquely identify the UE using a subscription or the subscription itself.
NOTE 2:   The two requirements above also apply to human-to-human communications. However, for Machine-Type Communication identifiers will have to be able to cater for a number of identifiers up to two orders of magnitude higher than for human-to-human communications.
-     It shall be possible to use the following identifiers:
1.       IMSI, for internal usage within the 3GPP operator domain, and either
2.       E.164 MSISDN, for usage outside the 3GPP operator domain, or
3.       Unique identifier (e.g. FQDN), other than E.164 MSISDN, for usage outside the 3GPP operator domain.
NOTE 3: Use of IMSI outside the 3GPP operator domain is an operator option (i.e. not subject to standardization)
-     If no (unique or common) MSISDN is assigned to a PS only subscription, the Internal Identifier (IMSI) shall be used as charging identifier.
-     It shall be possible to associate one or more External Identifiers to the same Internal Identifier (e.g. several MSISDNs associated with the same IMSI).
-     Globally unique External Identifiers shall be supported for identifying UEs used for MTC that must be globally reachable (i.e. irrespective of which mobile operator owns the subscription)
-     Operator specific External Identifiers (e.g. based on a private numbering plan) may be supported for identifying UEs used for MTC that have to be reachable only from the operator domain to which they are subscribed.
-     The Internal Identifier shall be globally unique.
-     Remote MTC Device configuration shall still be supported for subscriptions without an MSISDN.
NOTE 4:   Current remote MTC Device configuration solutions (i.e. Device Management and Over-the-Air configuration) are based on SMS, which assumes the use of MSISDNs.


Any more information on this subject, more than welcome.