packets

Low power means long range coverage for industrial sensors

By IoT Now Magazine

Andrew Brown, the executive director of Enterprise and IoT Research at Strategy Analytics, recently interviewed Matt Bacon, the marketing and communications director at Actility, to discuss the company’s activities in IoT; its network, partners and customers and its efforts in industrial markets. Actility is a founding member of the LoRa Alliance and offers low power wide area (LPWA) infrastructure with its ThingPark IoT communications platform. The platform provides LoRaWAN longrange coverage for low-power sensors used in multiple vertical industry applications

Andrew Brown: What are the key IoT applications that Actility customers are implementing in industrial environments?

Matt Bacon, the marketing and communications director at Actility

Matt Bacon: To begin with, it makes sense to explain what we do at Actility and how we help our customers in IoT. Our core product is the ThingPark communications platform, which was initially focused on LoRaWAN, but will shortly also support licensed 3GPP technologies; first LTE Cat M and then narrowband IoT (NB-IoT) for customers. With the platform, we manage data end-to-end, from the sensor via the gateway to customer applications in the cloud. We are able to handle various additional functions such as protocol translation, if required, also ensuring devices are correctly provisioned and sending their data packets end-to-end. We are not an analytics or visualisation company; we offer key ingredients in a complete IoT solution created by a range of partners. Our initial customers were network operators who chose us to build nationwide LoRaWAN networks in order for them to resell connectivity to their customers. They used ThingPark to manage the LoRaWAN component of their network.

Andrew Brown, Strategy Analytics

There are multiple applications that our customers, like KPN or Orange are enabling through connectivity for their industrial customers. For example, one industrial customer manages thousands of rat traps throughout The Netherlands. Connect them with LoRa and the traps only need to be checked and emptied when they have actually caught a rat, so there are far fewer truck rolls required, which dramatically improves the overall total cost of ownership (TCO) of the project.

Our partnership with Inmarsat has enabled the first globally available LoRaWAN IoT platform and we are supporting the company in building smart city applications in Kigali in Rwanda. In the same country, we are also working with Inmarsat and Carnegie Mellon University on a mountain tea plantation and processing facility. There, IoT will deliver agricultural monitoring such as soil moisture levels, but also precise temperature and humidity monitoring in the processing facility, which need to be monitored and controlled to ensure the best possible tea.

We also handle more traditional plant monitoring projects, such as the work we are doing with IBM Watson and Cougar Automation, a UK systems integrator, for RS Components. RS has a large warehouse with thousands of metres of conveyor belts. It ships up to 44,000 parcels a day, which are moved by conveyor belts. As a parcel drops from one belt to another, it can marginally knock the belts out of alignment. As this is repeated with thousands […]

The post Low power means long range coverage for industrial sensors appeared first on IoT Now – How to run an IoT enabled business.

Read more here:: www.m2mnow.biz/feed/

Akita raises $700,000 crowd-based funding on Kickstarter

Akita, an IoT device watchdog station raised approximately $700,000 crowdfunding on Kickstarter. With 7000 plus backers, the startup promises to provide instant privacy for connected products.

Instant Privacy for Smart Homes

The device performs three core activities i.e. scans connected gadgets/devices, blocks compromised devices and notifies the users of known issues. Akita comes with full support and help desk monitoring powered by Axius.

This device connects to a LAN port on users’ home router (not inline). The startup describes the device working as follows:

“Akita uses a custom form of WiFi sniffing to detect questionable packets and send them to our servers to be analyzed (this is why the hardware can run on low memory/CPU, because it’s mainly a cloud-based system). Once the packets are determined to be malicious, a command is sent from our servers back to the Akita device; this includes custom protocol commands to disconnect the device from the network router.“

Akita’s Kickstarter received significant backing (both in terms o the number of backers and funds raised from the campaign), though, it only aimed to raise $30,000 initially.

The rise in popularity of privacy and network security devices is understandable. A home network, with several connected devices, need robust protections. That’s where other startups like Dojo and F-Secure also promise to secure network traffic and identify rouge devices.

Readers might visit the Postscapes Connected Device Security guide to understand how other devices in the same niche work and how Akita stacks up against its competitors.

Read more here:: feeds.feedburner.com/iot

Why 5G Is in Trouble (and How to Fix It)

By Martin Geddes

I have a somewhat unconventional view of 5G. I just happen to believe it is the right one. It is trapped inside a category error about the nature of packet networking, and this means it is in trouble.

As context, we are seeing the present broadband Internet access model maturing and begin to reach its peak. 5G eagerly anticipates the next wave of applications.

The 5G Difference: “Purpose-for-Fitness” to “Fitness-for-Purpose”

As such, 5G is attempting to both extend and transcend the present “undifferentiated data sludge” model of mobile broadband.

Firstly, it pumps the “undrinkable” mucky bandwidth harder and faster, to give a modified version of what we have today with 4G. We will gloss over the minor miracle that needs to happen with backhaul, or that the mobility protocols today with 4G struggle when you get on the train (and 5G makes it worse).

Secondly, its other goal is to deliver differentiated “drinkable” access for different enterprise cloud and industrial applications. This essentially is a generic version of the very specific VoLTE solution developed for voice telephony in 4G, extended to any cloud application. It can be expressed as being for low-latency applications, or packed in a variety of other guises.

The Slow Evolution Towards General-Purpose Assured APP Access

The conventional wisdom is that packet networks enable networked computing (“join devices”), and networks do “work”. As such, the job of the network is to forward as many packets as fast as possible, and what matters most is “speed”. 5G fits this.

The unconventional wisdom is that packet networks enable interprocess communications (“join computations”), and networks don’t do “work”. As such, the job of the network is to trade resources around to deliver the “just right” quantity of quality to optimise the trade-offs of QoE risk.

The former model is “pipe”, the latter is “futures and options trading”. The former works with TCP/IP, the latter needs new packet architectures (RINA). The former can extend radio network protocols from 2G, 3G and 4G; the latter needs new ones. The former has a low-frequency resource trading model, the latter a high-frequency trading one.

A Paradigm Change in Engineering is Needed for 5G to Succeed

5G is making the network far more dynamic, without having the mathematics, models, methods or mechanisms to do the “high-frequency trading”. The whole industry is missing a core performance engineering skill: they can do (component) radio engineering, but not complete systems engineering. When you join all the bits, you don’t know what you get until you turn it on!

The result will not be pretty.

In particular, 5G is primarily delivering into the tail of the last S curve of generic unassured broadband Internet access; it is not on its present path fit-for-purpose for assured cloud application access (inc VR/AR and IoT), which is the new S curve of growth.

Telephony is virtual reality. VoLTE wasn’t solving the problem of how to extend the life of the past; it was solving a corner case of how do we communicate in future. Understand this, and the future and fate of 5G makes more sense.

The key question is whether 5G is aimed at extending the VoLTE part of 4G (fit-for-purpose voice) or improving the rest (purpose-for-fitness Internet access). It is trying to serve two strategic masters, the past and the future, at once.

Is 5G trying to “buy back up the curve”, implying doom for its makers and buyers?
Watch the video presentation: The Death of Cellular by Francis McInerney

So, what to do about it? I see three key industry actions.

Firstly, we need to narrow the intentional semantics. 5G is trying to do too many things.

The focus of the generic broadband access should not be peak speed, or even “antipeak” latency under ideal conditions. It should be to establish a consistent quality floor under real-world conditions with graceful degradation in overload. That floor should be adjustable so that you can segment the market by quality.

This is a precursor to a 6G, where the two sides of unassured and assured can be unified through a shared framework for managing the quality floor.

Whilst we need a “generic VoLTE”, only about 5 people on the planet know how to do it (and we’re all busy on other things). So for the assured access part, it should not attempt to make the leap from singular VoLTE to a generic offer in one go.

There needs to be a series of smaller and less ambitious steps that allow the coexistence of a modest number of managed services with different latency and throughput needs. However, the real issue is to assure complete supply chains, not just one part (the access) or sub-part (the radio link).

Which brings us to the second issue, the denotational semantics. As an industry, we’ve yet to agree on the standard units for broadband supply and demand (if you can believe it). So the next thing 5G has to fix is the lack of a shared requirements specification language for performance.

The good news is that this is a solved problem.

Key Action Needed: Upgrade Engineering to Align Supply to Demand/span>

Finally, the operational semantics. If 5G is going to be of any use to anyone but equipment salespeople, it has to demonstrate the difference it makes. That implies it needs to have improved mechanisms that allow for high-fidelity measurement of what QoE was being delivered, high-frequency control to deliver it, and new architectures that appropriately join these together.

This QoE control is a paradigm change. Today the radio people constructing a bandwidth supply, and the packet people chopping up whatever is there, using whatever transport protocols they inherited from the IETF.

The future is a demand-led model that is the antithesis of the IETF’s “rough consensus and running code” approach. That means a deep rethink because at present the radio folk are running the show, as they have always done. It’s a supply-led industry.

The problem has to be reframed as a distributed computing one that makes the radio subservient to the computational outcome. That’s going to ruffle a lot of feathers and upset a lot of power structures. The limiting factor in my experience is always human, never technical.

The alternative is that 5G gets stuck between two mutually incompatible goals, and serves neither well. Then eventually the whole ecosystem eventually gets bypassed in the 2020s, say by an IoT specialist player being bought by an Amazon, rather like how the iPhone overtook the handset space a decade ago.

Couldn’t ever happen? Ask him…

Written by Martin Geddes, Founder, Martin Geddes Consulting Ltd

Follow CircleID on Twitter

More under: Mobile Internet, Networks, Telecom, Wireless

Read more here:: feeds.circleid.com/cid_sections/blogs?format=xml

How to configure the Kerlink IoT Station for GPRS/3G uplink connectivity

I have been working on getting a Kerlink IoT Station to work with GPRS/3G as its primary uplink path.

A client asked me to do this configuration because they did not have the resources to it themselves. No problem. I have been working with LoRa and Kerlinks for a while now doing a consultancy job for another client (a big telco). They did not want to connect the Kerlink to their local network for security reasons. They wanted to add their gateway to TheThingsNetwork.org (TTN), a global open crowdsourced Internet of Things data network that started in The Netherlands. Reading the forums, I noticed that many trying to do the same have run into issues. The documentation is sometimes incomplete and scattered so it takes a bit of effort to get it to work.

IoT lab at the home office

IoT lab at the home office

The task at hand:

Configure a Kerlink IoT station to use its GPRS/3G modem as its uplink path and connect it to TheThingsNetwork.org. The SIM provided was a PukData M2M SIM which uses the KPN mobile network in The Netherlands.

Normally, the Kerlink will use its  ethernet (eth0) uplink as its default path. The basic idea here is that, if configured correctly, an autoconnect mechanism will trigger the GPRS bearer, establishes a PPP connection and set a default route and DNS.

I had already installed the TTN firmware with the polypacket forwarder on the Kerlink and got it to work using the ethernet uplink. I used a LoRaMote to check if packets actually showed up in the TTN api. For the next step, I basically followed the GPRS/3G guide on the TTN Wiki  which boils down to:

  • Set the GPRS options to match your SIM and telco’s APN settings (i.e. APN name, pincode, username and password).
  • Configure auto connect in the knet monitor.
  • Set the bearers priority.
  • Because no username/password is set for this APN, and empty username/password fields trigger a bug, I also installed the patched GPRS init script.

 

I ran into a couple of things so these considerations may be useful:

  • If your SIM comes with a pin code (usually 0000), set it with ‘GPRSPIN=<your pin here>’.
  • If your APN username and password are to be left empty, replace the GPRS init script with the patched version as mentioned at the bottom of the guide.
  • Carefully choose your ip_link address in /knet/knetd.xml depending on your requirements. This address is pinged periodically to determine if the GPRS auto connect needs to be activated. In my case I wanted one that is only reachable over the GPRS APN (e.g. for KPN use their DNS server: 194.151.228.34) to force it to bring up the ppp0 interface whenever possible. If you’re using GPRS as a backup path this should be different (I guess an address only reachable via eth0 but make sure the PPP session is terminated as soon as the primary path becomes available again). Use tcpdump (e.g. tcpdump -i ppp0 -n -v port 1700 or icmp) to check if it is pinging the correct address and if status updates are sent.
  • I chose not to use peerdns (GPRSDNS=no) because the default DNS servers are not restored in case of a GPRS connection failure, thus breaking eth0 as a fallback path. I used the Google public DNS servers in stead as they work on both paths. This could also be fixed in /etc/ppp/ip-down.
  • Remember that your default gateway will be set to the ppp0 interface whenever that interface comes up. You may want to be able to connect through eth0 for maintenance…
  • The (poly) packet forwarder needs to be restarted whenever there is an interface change to make sure it binds to the right source address. If it isn’t you will see packets going out the ppp0 interface with the eth0 source address (or vice versa). I added ‘/usr/bin/killall poly_pkt_fwd’ to /etc/ppp/ip-up and /etc/ppp/ip-down.
  • The firewall is not enabled by default. Make sure to edit /etc/init.d/firewall to your needs and turn it on in /etc/sysconfig/network (FIREWALL=yes). Don’t forget IPv6 although dropbear for instance does not listen on a v6 socket.

Tests to do to make sure it all works:

  • Check if the gateway is still active (is sending status updates) and node messages are received in the TTN API after unplugging the ethernet uplink cable. If you’re using an ethernet power injector, make sure to unplug the cable going into the injector rather than the one going out to the Kerlink. Duh! 😉 Remember that you can’t log in to the gateway anymore, assuming access to the GPRS/3G address is blocked.
  • Plug the ethernet cable back in and see if you can log in again. Then check if updates/messages are still being sent over the ppp0 interface using tcpdump.
  • Power cycle the Kerlink while leaving the ethernet uplink cable unplugged. This will make sure the Kerlink will boot successfully in stand-alone mode, which was the whole purpose of this exercise.

Configuration:

/etc/sysconfig/network:

 # Selector operator APN
 GPRSAPN=internet.access.nl
 # Enter pin code if activated
 GPRSPIN=0000
 # Update /etc/resolv.conf to get dns facilities
 GPRSDNS=no
 # PAP authentication
 GPRSUSER=
 GPRSPASSWORD=
 # Bearers priority order
 BEARERS_PRIORITY="ppp0,eth0,eth1"

/knet/knetd.xml:

<!-- ############## connection parameters ############## -->
<!-- nb of second to retry to connect to server if connection failed-->
<CONNECT retry_timeout="10" />
<!-- port nunmber for local application kms connection -->
<CONNECT kms_port="35035" />
<CONNECT auto_connection="YES" />
<!-- frequency of connection monitoring -ping- (in seconds) -->
<CONNECT link_timeout="30"/>
<!-- DNS servers will be pinged if commented or deleted. Some operators can block the ping on there DNS servers -->
<CONNECT ip_link="194.151.228.34"/>

Questions?

Don’t hesitate to leave a comment below or send a message.

Book review – IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6

There are many IPv6 books around nowadays with many different approaches to the subject. IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 by Rick Graziani is an excellent book that will help you fully understand the fundamentals of IPv6. It has a great balance of theory and practical information and is a good starting point for learning about IPv6. Other IPv6 books can be found on our books and e-books pages. We have included a number of Amazon reader reviews below:

[amazon template=image&asin=1587143135]
[amazon template=add to cart&asin=1587143135]

Graziani provides straightforward understanding.
By M.B. Reynolds on June 5, 2013

The title of the book is an accurate depiction of the contents of this work. The material is presented in a straightforward, methodical manner. The material is presented with understanding and teaching in mind utilizing repetition, sample code, examples, and review. The book is primarily a walk through the various Internet Engineering Task Force (IETF) Requests for Comments (RFC) that comprises the aspects, features, and options of IPv6. Most of these RFC walkthroughs are accompanied with Cisco IOS example code for setting up a router to implement the RFC.

After some of these examples, output from a packet sniffer demonstrates the changes to the packet headers. The book finishes with mechanisms for implementing mixed IPv4 and IPv6 environments and approaches to transitioning from IPv4 to IPv6. Additional references and notes point the reader to more details or topics not covered by the book. Overall I certainly recommend this book as a starting point into IPv6 if the reader has some IPv4 and routing experience. I believe for the novice an additional more general book on networking should be digested first.
The book covers the Internet history and the motivation of IPv6. The IPv6 headers and Extension headers are presented in (again) a straightforward explanation with plenty of diagrams and tables. This explanation includes the specific differences between IPv4 and IPv6 headers. A nice overview of IPSec headers includes authentication, transport, and tunneling modes. Chapter four outlines the multitude of unicast, multicast, and anycast address types. The Neighborhood Discovery Protocol is a new feature of Internet Control Message Protocol version 6 (ICMPv6). Graziani shows ICMPv6 with its enhancements is an important change in how IP hosts identify themselves and others hosts and routers on the network.

The middle of the book discusses IPv6 configuration and routing. Initially, a router is configured from scratch with the various address types. The same example configuration and network is nicely used through the middle of the book. This method is useful for continuity and context. Building on this initial configuration static routes and routing tables are built. The old and new RIPng, EIGRP, and OSPF are compared and contrasted in Chapter 8. The middle ends with Dynamic Host Configuration Protocol version 6 (DHCPv6). The new features such as stateless & stateful DHCP and relay agents are covered. Some interesting differences in Domain Name Service (DNS), TCP, and UDP are explained.

The book ends with mixed IPv4 and IPv6 environments. Graziani shows dual stack allows for parallel IPv4 and IPv6 networks. He covers tunneling methods such as 6to4 and ISATAP that allow for IPv6 packets to be encapsulated in IPv4 packets and routed through an IPv4 network. He shows this allows for a smooth transition from IPv4. Finally Network Address Translation IPv6 to IPv4 (NAT64) is walked through. He shows this allows and IPv4 address to be mapped to a IPv6 address and vice versa to allow coexisting IPv4 and IPv6 networks to communicate.

 

One of the most substantial changes from IPv4 to IPv6 is the addresses and their types. After introducing hexadecimal and the address format short hands, Graziani explains well the structure of the new 128-bit address: prefix, subnet, and interface id.

After trying others – THIS is THE BOOK!
By John Scott on March 22, 2013

The review written by Cosmic Traveler says it well. I purchased 2 other books before this one and they both ended up on the bottom shelf of my bookshelf. I ordered this one and I couldn’t put it down. If the mere thought of a 128-bit address represented in hexadecimal format makes your hair stand up, you need to order this book and then go have a glass of wine – or a cold beer.

IPv6
By Matthew Petersen on February 14, 2014

To support future business continuity, growth, and innovation, organizations must transition to IPv6, the next generation protocol for defining how computers communicate over networks. IPv6 Fundamentals provides a thorough yet easy-to-understand introduction to the new knowledge and skills network professionals and students need to deploy and manage IPv6 networks.

Excellent book, highly recommended!
By MSG causes migraines on October 15, 2013

Even though I have been a CCIE since the 1990s and have dealt with IPv6 successfully on the re-certification exams, this book added a lot of needed clarity on the context and usage of IPv6 so the concepts are more readily absorbed and made intuitive. For those network engineers not yet exposed to IPv6 due to their individual customer/employer situations, it is a near-term reality everyone is going to have to deal with as the IPv4 private addressing RFC 1918 (and the updated IPv4 content in RFC 6761) cannot eliminate the reality that IPv4 is nearing address depletion.
[amazon template=add to cart&asin=1587143135]
UNDERSTANDING IPV6!!!
By COSMIC TRAVELER on November 17, 2012

Are you a network engineer; network designer; network technician; part of the technical staff; and, networking student, including those of the Cisco Networking Academy; who are seeking a solid understanding of the fundamentals of IPv6? If you are, then this book is for you! Author Rick Graziani, has done an outstanding job of writing a book that focuses on the basics of IPv6.

Author Graziani, begins by discussing how the Internet of today requires a new network layer protocol, Ipv6, to meet the demands of its users. Then, the author examines the Ipv6 protocol and its fields. Next, he introduces IPv6 addressing and address types. The author continues by examining the different types of IPv6 addresses in detail. Then, he examines ICMPv6. The author then illustrates the configuration of IPv6, addressing the use of a common topology. Next, he examines the IPv6 routing table and changes in the configurations pertaining to IPv6. The author continues by discussing three routing protocols: RIPng, EIGRP for IPv6 and OSPFv3. Then, he examines DHCP for IPv6 or DHCPv6. The author then covers two of three strategies for IPv4 and IPv6 integration and coexistence: dual-stack and tunneling. Finally, he discusses the third technique for transition from IPv4 and IPv6: Network Address Translation or NAT.

This most excellent book provides a thorough yet easy-to-understand introduction to IPv6. More importantly, this great book is also intended to provide a foundation in IPv6 that will allow you to build on it.

Great book to begin IPv6 study
By Cord Scott on March 22, 2013

Really like this book. Information is accurate and concise and concentrates on the protocol and not just how to configure Cisco gear for IPv6, which is what too many people look for. Not a whole lot on migration but Cisco Press has another book that deals with that.

Everyone should start IPv6 with this book
By Andras Dosztal on May 13, 2013

Detailed but still easy to understand, having a good balance of theory and practical knowledge. Up to date, covers all topics needed for someone who’s getting familiar with IPv6. Having prior IPv4 and routing knowledge is recommended.

[amazon template=add to cart&asin=1587143135]