28
M2M NETWORKS
ISSUE 05 2014
2. Signalling behaviour
The behaviour of human subscribers as it relates to telecom networks is familiar to network planners, with predictable peak usages occurring before and after work, on weekends and holidays, etc. However, machines are not humans and require different network architecture and scaling to support their behaviour.
For example, consider what happens in a network when one million ATMs (cash machines) simultaneously send updates to a central office at the end of the day, or when 10 million electricity meters send an update on the last day of the month all at 8am. This will create a tsunami of signalling hitting the network all at once. Now think what happens if the ATMs don’t receive a reply in time; think about the retransmissions (an automatic repeated request) and how all of these will affect the network.
In addition, the routing of the signalling messages to the correct billing servers is critical and if not properly configured can wreak havoc in accounting.
The same goes for connection times. Again, human voice and data behaviours have been tracked over the years with their signalling well architected in a network. We know some connections will be on constantly, sending signalling all the time. We know which connections will be very short and will turn off after a specified period. However, some machines are sending thousands of messages a day in a very rapid manner. These patterns and behaviours vary completely from typical network and signalling behaviours known to date.
In short, the learning curve for Diameter signalling is still on the rise for LTE networks. No doubt that learning curve will have to be revisited totally for M2M. But we need to move quickly before large-scale deployments are rolled out to avoid serious service interruptions.
The learning curve for Diameter signalling is still on the rise for LTE networks. No doubt that learning curve will have to be revisited totally for M2M
3. Network and signalling infrastructure In terms of hardware, so far LTE networks continue to be built in the same way as legacy networks. CSPs can use proprietary hardware or off-the-shelf hardware.
Machine-to-machine networks will use emerging cloud and virtualisation technologies. There are both technically and commercially strong reasons for this major shift. From my discussions with CSPs on M2M architecture, moving ahead to cloud and virtualisation is the only viable option. Any other way just doesn’t make sense.
Cloud and virtualisation are game changers and there are many reasons to push these forward. However, they also have signalling effects that need to be taken into account in the M2M network design process. For example, a 4G cloud- based network will be more fragmented making it much more complex with many more dedicated network elements and functionalities. Complexity slows down the network if not planned for properly.
In a virtualised M2M signalling domain, there will be many more Diameter router instances – Diameter Routing Agents (DRAs). However, they need to be software-based and will behave differently. In contrast to LTE, in which dedicated core Diameter routers need to handle hundreds of thousands of transactions per second, in M2M the Diameter routers will have fewer transactions per router. However, we will see M2M Diameter routers hosted in the virtualised network and handle M2M signalling behaviour, cope with longer session times and bursts of signalling messages. In short, the management and synchronisation of hundreds of Diameter routers is a huge challenge.
However, there is much to gain from the virtual capacity of spinning up a virtual version of a Diameter router as a fast reaction to on-the-fly capacity demands.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52