linux dns server

Field services operations bullish on emerging technologies, finds Red Hat global survey

By Zenobia Hegde

For many industries, from transportation to utilities, manufacturing and more, field workers are pivotal to the success of business operations, the satisfaction of customers, and the growth of the bottom line.

Field workers are now at the forefront of digital transformation where artificial intelligence (AI), smart mobile devices, the Internet of Things (IoT) and business process management (BPM) technologies have created new opportunities to better streamline and transform traditional workflows and workforce management practices.

To better understand how these technologies are being applied and the impact they are having in the enterprise, Red Hat commissioned research firm Vanson Bourne to survey 300 IT decision makers from organisations in the U.S., Europe and Asia that employ a significant field workforce. The survey examined investment trends, current and future adoption patterns, use cases and implementation challenges.

According to the results, strong technology investment is expected by respondents with an average increase of 25% through November 2018, reflecting the importance of technology in transforming field service operations. Top business factors identified as influencing this investment include increasing field worker productivity (46%), streamlining or optimising field operations and processes (40%), and improving customer service (37%).

When we consider the current trends that are broadly driving conversations in the tech industry, AI is one of the leading topics. While still an emerging category—currently implemented by only 24% of respondents—we believe the technology has great potential across a variety of industries and use cases. It comes as little surprise that an additional 30% of respondents plan to implement AI in 2018, aligning with an average anticipated increase in investment of 26% for certain respondents over the same period.

The AI umbrella encompasses a number of specific technologies for those respondents that have either implemented already or plan to implement to address more specialised uses cases, including:

Predictive analytics (55%)
Machine learning (46%)
Chatbots or virtual digital assistance (45%)
Robotic Process Automation (44%)

Despite being more established technologies, mobile, BPM and IoT seem to defy their relative maturity in the market with respondents indicating double-digit growth across the board in both investment and implementations through November 2018. While 67% of respondents have already implemented mobile apps for field service operations, an additional 19% plan to implement new mobile apps, supported by a 20% average expected increase in investment by certain respondents.

The outlook for BPM and IoT is similar. Respondents expect implementations to grow from 61 to 81% for BPM and from 53 to 73% for IoT, fueled by 20 and 24% average expected increase in investment by certain respondents, respectively.

However, along with the appetite for technology investment and implementation growth, respondents are keenly aware of the technical challenges their organisations face in developing and implementing applications for field workforce management. Access to timely and relevant data is critical for field workers in remote locations, harsh environments, or areas of low network connectivity, as is the ability to protect that data as it flows between the field and back-end systems.

As a result, securing data access was the top challenge identified in the survey at 34%, followed by:

The pace […]

The post Field services operations bullish on emerging technologies, finds Red Hat global survey appeared first on IoT Now – How to run an IoT enabled business.

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

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.