A few questions are being asked recently regarding the impact of M2M on Small Cells. With a prediction of up to 50 billion devices by 2020-25, this is a very valid question.
While M2M applies to a broad range of devices, there are still people in the industry who tend to think of M2M devices as small, cheap devices, generally with little or no mobility, responsible for small amounts of data transfer over long durations. While it is true that a multitude of M2M devices may fall in this category, it is not necessarily applicable for all M2M devices. For instance, the car industry is working very tough on the design and development of various ‘connected car’ initiatives. These connected cars will require high speed data transfer (e.g. SatNav maps, traffic related information, video streaming, etc.) over a fast varying channel due to very high mobility. To facilitate and simplify thisanalysisan assumption of little or no mobility will be made where device ‘may’ or ‘may not’ require reasonable amount of data at regular time intervals. This assumption would also be more applicable to scenarios with possible small cells around. Such devices could be motion sensor based devices like security cameras, connected meters, any other sensors that monitor real time information, etc. We can discount M2M devices like those in connected cars from our analysis because they would most likely rely on macro cellular coverage. Finally, we will consider only ‘open access’ small cells rather than ‘closed access’ (a.k.a. CSG or ‘Closed Subscriber Group’) small cells.
There are many factors that need to be considered in the design of an M2M device such as cost, form factor, power consumption, security, etc.
To keep the cost down while maintaining a small and simple form factor, it may be sensible to stick with one access technology rather than more. Power consumption is very low in certain type of technologies like Bluetooth; it is not always practical for large number of M2M devices. Each of these M2M devices may need a Bluetooth access point which may not always be feasible. On the personal front, many eHealth M2M devices use Bluetooth as access technology where the user provides some sort of input and the M2M device can connect to the Bluetooth on the phone. Generally, most indoor low mobility M2M devices would rather have wireless coverage which is WiFi or cellular.
A point generally made in favor of WiFi is that it’s cheap but as most people would already know, ‘there is no such thing as a free lunch’ and there are other issues that need to be considered along with this. First and foremost being that WiFi coverage area is limited per access point which may be true in case of cellular small cells also. However the M2M device can always fall back on the macro cell usage in case if the small cell becomes unavailable for whatever reason. WiFi makes use of unlicensed spectrum which is prone to interference and jamming issues. Another issue that needs consideration is if the WiFi channel is security protected or not. If unsecured, the data sent by the M2M devices may be visible for others to view unless the M2M devices encrypt it thereby increasing complexity and maybe cost. Security of the devices may also be compromised if some kind of vulnerability is detected after the devices are in the field when using WiFi. With cellular, these issues are much reduced as the SIM provides the additional layer of security against the potential hackers and also the user data is not visible for anyone interested in eavesdropping or sniffing. In case of security protected WiFi devices each of the M2M devices would need to possess the appropriate security credentials. If the WiFi SSID changes or password is changed then each of these devices would have to somehow update their credentials. With cellular, the device relies on SIM for authentication and security and thereby benefits both the network as well as the device as they both know that the other party is a trusted one.
With WiFi out of consideration, an obvious question would be how small cells could do the job better than the macro cell? The ground reality is that the macro cells are quite heavily in use most of the day. There is no longer a ‘peak period’ but the use is generally distributed evenly during an entire day. The standardization bodies along with the operators are working on various ways to offload the traffic from the macro cells to some other form of access networks to make sure there is cell capacity available for users who cannot be or would rather not offload. Going back to the predictions of 50 Billion devices, there is a limit on how many active users the network can simultaneously allow on a cell. The restriction can arise because of the ‘air interface’ bottlenecks or even the ‘core network’ overload. The networks are also wary of ‘Signalling Tsunamis’ which are very much possible with a multitude of M2M devices. Some of the new features, especially in LTE, deal with access barring of M2M devices to avoid overload. Small cells with a restricted coverage area may be less prone to the ‘overload’ situations in the access or/and the core network. There are also features intended for small cells that will allow the user plane data to be offloaded while the signaling data, responsible for security, is still sent through the normal route. The above mentioned and some additional features are still under development and standardization process by the 3GPP which will work to the benefit of Small Cells thereby making them the best solution for certain types of M2M devices that we have considered in this analysis.
Hi all,I planning to upgrade from RSP440 to RSP880 in live environment.The scenario is like this,I have 4 routers running RSP440-TR with IOS-XR 6.1.4 and that will be upgrade to RSP880-TR.My question is below,- Do I have to prepare the new RSP880 card wit...
hi, guys thanks for time and help i have the next configuration: class-map match-any VOIP
match protocol h323
match protocol sip
match protocol rtcp
match protocol rtp
set dscp ef
Good Morning everyone. I have a question regarding basic bandwidth policing and shaping profiles for customers provisioned from ME3800's/ASR9K's/C4900's. My profiles are usually something simple like this to limit a customer to 50Mb/s (add...
Try to verify if your image supports IS-IS, search by platform:
Also check the following link:
Hello guys, Based on this awesome blog https://xrdocs.io/design/blogs/2018-05-09-metro-design-implementation-guide/ with a bit of redesign (also coming from Jiri's idea of non inline PE), would you agree with this topology? Purpose is ...