e-peas, a startup that has developed energy-harvesting and low power consumption ICs and microcontrollers raised $4.2M venture funding led by Partech Ventures. Other investors that participated in the funding round include Airbus Ventures, JCDecaux Holding, Semtech, SRIW and Vives.
The Belgian Co-founders Geoffroy Gosset and Julien De Vos run the startup as CEO and CTO respectively.
The startup promises to extend battery lifetime of wireless devices by harvesting photovoltaic, thermal, vibration or RF energy via its ICs called power Management Integrated Circuits (PMIC). For instance, its photovoltaic ICs harvest energy from various light sources such as sun, bulbs, and natural indoor lighting. Similarly, the thermal IC can harvest energy using human heat, motor heat, and waste heat present in an environment.
The other product line of e-peas is a general purpose microcontroller based on a 32-bit ARM architecture. It contains internal communication peripherals, embedded memory, communication modules, and timers. The controller consumes less energy in active and standby mode compared to traditional microcontrollers used in sensor systems.
The startup plans to market the product line to companies developing wireless sensors, wearables, industrial nodes and other IoT systems.
The key industry verticals it plans to sell its product to include retail, security, smart agriculture, and e-Health.
The idea of getting rid of batteries by sucking needed energy from ambient environment is not new, however, few startups are successful at delivering a product at a commercial scale. In March this year Tryst Energy launched its crowdfunding campaign on Kickstarter. It promised to launch energy harvesting hardware intended for IoT devices, though the project never materialized and was canceled.
e-peas launched in 2014 by securing local government grants and private seed investment funding. It used the capital to bring AEM10940 energy harvesting chip to market. The startup plans to use the latest funding proceeds to hire engineers and expand globally via partnerships.
Read more here:: feeds.feedburner.com/iot
The IPv6 protocol introduced very few changes to its IPv4 predecessor. The major change was of course the expansion of the size of the IP source and destination address fields in the packet header from 32-bits to 128-bits. There were, however, some other changes that apparently were intended to subtly alter IP behaviour. One of these was the change in treatment of packet fragmentation.
Read more here:: labs.ripe.net/RSS
There are 12 fundamental steps ISPs can take to enable IPv6 on their networks. I have pulled together a brief executive summary on how ISPs can achieve native IPv6 support and the maintenance of IPv4 as a transparent service (not including services like DNS, web, email, etc.).
12 Steps to IPv6 for ISPs
- Determine how many customers (home+corporate) your network has and the expected growth in the short/medium term. If the total is smaller than 50,000 customers, we recommend you to request a /32 from your RIR, a /31 if you have up to 100,000 customers, a /30 for up to 200,000 customers, and so on. If you already got a /32 and have more than 50,000 customers, you can request an upgrade of your actual prefix. (Note: This example does not apply to the ARIN region. Please see either our Quick Guide or our Requesting Resources page to learn more.
- Audit your network, as you need to know what equipment has the right IPv6 support or what needs to be updated or replaced. It is important to have a detailed inventory from your upstream connections to the customer’s CPEs. If your vendors don’t provide the right support, you should push them to do so. Generally, the market is big and free…
- Get professional training with companies that have a demonstrated experience in IPv6 deployment in ISPs. IPv6 is not more difficult, but IPv4 and IPv6 are different, and the difficulty may be changing your mindset. It is necessary to “unlearn” IPv4 to correctly understand IPv6. Possibly it could be convenient that you agree on a consultancy service together with the training. It may seem excessive, however, you will save a lot of time. As the transition to IPv6 becomes more urgent, that time will cost much more in terms of business losses and problems with IPv4, than the cost of that training and consultancy.
- Confirm with your upstream providers that they have IPv6 support and enable it in your BGP with them. Same for CDNs, caches and IXs. If the actual upstream providers don’t have IPv6 support, you really need to look for better partners. This part of your network must be dual-stack. In the worst case, if there is no way to get dual-stack from one or several of your upstreams, you may need to use a tunnel, typically by means of 6in4 (protocol 41, manually configured) or GRE, but you should consider this only as a temporary bypass.
- Review your security policies. They should be equivalent to what you apply with IPv4, but remember that you should not filter ICMP with IPv6, among other related details that will avoid the correct flow of traffic across your network. Review also the IPv6 prefix filtering in your BGP peers; again, those are policies conceptually equivalent to what you already know for IPv4, but with a different protocol.
- Configure IPv6 support in all your monitoring systems. IPv6 has the same importance as IPv4, so any system that allows you to view the traffic quality, quantity, stability, visibility of your prefixes, etc. (either from inside or outside your network), must support both IPv4 and IPv6 with the same conditions.
- Design your detailed addressing plan. This is your masterpiece for a correct IPv6 deployment, very different from IPv4. For sure you will need an IPAM (IP Address Management) device or tool, as it is impossible to manage millions of IPs with the traditional text file or spreadsheet as you may have done before with IPv4.
- Deploy IPv6 in your core and distribution networks. Dual-stack may be sufficient in a first phase. In a follow-up stage, maybe you will be able to supress IPv4 in parts of those networks, so you can reuse those addresses in more relevant places of your network.
- Start a small trial in your own corporate network. Remember that /64 is the minimum for each LAN or VLAN. The golden rule is to keep dual-stack in the LANs/VLANs (even if using private IPv4 addresses) and that it’s easier to use SLAAC and RDNNS. DHCPv6 is an option, most of the time unnecessary (moreover, Android doesn’t support it). Also in this phase, it may be interesting to involve in the pilot some of your corporate customers, even some residential ones. It is not so relevant if at this stage, manual provisioning is required.
- Prepare your access network as well as the provisioning system. Your billing systems may be affected too. Now is the time to define what transition mechanism is the right one. My recommendation is 464XLAT, at least for the residential customers and cellular networks. 464XLAT is one of the most recent transition mechanisms (and the most used one, with millions of users in 3G/4G networks), which has the advantage of using IPv6-only in the access network, so the ISP doesn’t require IPv4 addresses there; despite that, it provides IPv4 private addresses to the users (by means of the CLAT), so that devices and applications still work in a transparent way. It is a must to have good support from the CPE vendors. For provisioning, the best will be to use DHCPv6-PD. Use the RIPE BCOP in order to understand how to number your customers.
- Configure PLAT (NAT64+DNS64) in your network. Don’t use CGN, as it will bring you many more problems and higher costs (not only the CGN itself, but also the logging systems). If you have a cellular network with PLAT deployment, and set up an IPv6-only APN, you will be all done for the smartphones and other 3G/LTE devices. Android and Windows come with the CLAT, while iOS/Apple only use the PLAT, because all their apps mandatorily support IPv6.
- Update the CPEs. Try again with some customers, once updated; this is the most critical and complex part of all the process. There are many ways to approach it. Once done, you’re ready for a massive IPv6 activation (maybe in phases, regions, etc.) and a commercial announcement.
Bravo, your network is ready for the future! Now, you need to start considering how to take advantage of IPv6 with new services and applications. IoT is one area, but surely you will find others as well.
Read more here:: teamarin.net/feed/
Nearly a third of C-Level directors surveyed across the UK (32%) either do not have a response plan in place to manage a cyber-attack on their business, or they are not sure whether they do. That’s the finding of a new poll of 250 C-suite members in organisations with more than 50 staff. The survey […]
Read more here:: www.m2mnow.biz/feed/
Verizon has announced that starting June 30, 2017, it will stop issuing new Public Static IPv4 addresses due to a shortage of available addresses. While customers that currently have active Public Static IPv4 addresses will be able to retain their addresses, reserving new IP addresses will require companies to convert to the Persistent Prefix IPv6 requirements and implementation of new Verizon-certified IPv6 devices.
To encourage the move to Persistent Prefix IPv6, Verizon says:
— “Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 128-bit addressing scheme, which aligns to current international agreements and standards.”
— “Persistent Prefix IPv6 will provide the device with an IP address unique to that device that will remain with that device until the address is relinquished by the user (i.e., when the user moves the device off the Verizon Wireless network).”
— “IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.”
Follow CircleID on Twitter
Read more here:: feeds.circleid.com/cid_sections/news?format=xml