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, 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.
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’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
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
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: 188.8.131.52) 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.
# 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"
<!-- ############## 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="184.108.40.206"/>
Don’t hesitate to leave a comment below or send a message.
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=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.
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]
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]
Network Working Group J. Reynolds, Editor Request for Comments: 3232 RFC Editor Obsoletes: 1700 January 2002 Category: Informational
Assigned Numbers: RFC 1700 is Replaced by an On-line Database
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. Description From November 1977 through October 1994, the Internet Assigned Numbers Authority (IANA) periodically published tables of the Internet protocol parameter assignments in RFCs entitled, "Assigned Numbers". The most current of these Assigned Numbers RFCs had Standard status and carried the designation: STD 2. At this time, the latest STD 2 is RFC 1700. Since 1994, this sequence of RFCs have been replaced by an online database accessible through a web page (currently, www.iana.org). The purpose of the present RFC is to note this fact and to officially obsolete RFC 1700, whose status changes to Historic. RFC 1700 is obsolete, and its values are incomplete and in some cases may be wrong. We expect this series to be revived in the future by the new IANA organization. Security Considerations This memo does not affect the technical security of the Internet. Reynolds Informational [Page 1]