Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I had an Idea and I was wondering if it was possible. I've googled it and can't seem to find any existing solutions. I was thinking of having a Bluetooth mesh network. The layout I was hoping to achieve is to have one central station (PC with bluetooth dongle) and then a bunch of bluetooth modules (preferably these) that would all form a mesh network with the modules around them. Not all of them would be in range of the "central station" but would need to communicate with it through the other nodes. The bluetooth modules would be hooked up to ATtiny85 chips if it makes any difference. If you have any questions just ask.
Is this possible?
Is it possible with the above bluetooth module?
Would they all have to be set up individually or could there be some sort of neighbor discovery?
Would there be security risks?
What would the limitations on the size of the network be?
Where should I start?
CSR has delivered a BLE mesh network solution
http://www.csr.com/news/pr/2014/csr-mesh
Not sure if you have found a reasonable solution yet, I am new to the BLE and was also thinking along the same lines of having a BLE mesh that can permit transmitting of signal up to a few miles or so. This way, sensors can be placed in remote rural areas and utilizing multiple hops of sensors, the data can be transmitted to the central controlling station. However, as of yet, I haven't seen a dual mode sensor that can assume both roles as needed.
The other approach can be to make use of TCP/IP bridge. This way, the device, which can be an iPhone or Android, listens to the advertised data, creates an IP packet and send it to the remote server. Obviously, for this to work you need to have cellular data network available. But granting ubiquitous data network or Wi-Fi coverage this solution sounds more promising to me.
NOTE: Here http://www.bluetooth.com/Pages/low-energy-tech-info.aspx they talk about star topology though, below is the excerpt:
Topology – Bluetooth low energy technology uses a 32 bit access address on every packet for each slave, allowing billions of devices to be connected. The technology is optimized for one-to-one connections while allowing one-to-many connections using a star topology. With the use of quick connections and disconnections, data can move in a mesh-like topology without the complexities of maintaining a mesh network.
Also have a look at FruityMesh. It is an open source implementation of a mesh network that is based on standard Bluetooth Low Energy 4.1 connections.
They use the Nordic nRF51 chipset in combination with the S130 SoftDevice.
Found on github: https://github.com/mwaylabs/fruitymesh/wiki
So bluetooth - as clearly pointed out in the comments - is not designed for mesh networking. Nor, honestly would you want to. It would be far to expensive both in fincances AND in processing time and battery power to handle such an operation.
Instead, why not use XBee? https://www.sparkfun.com/search/results?term=xbee&what=products
These XBee modules are not only designed to do EXACTLY what you want, but they are low cost and HEAVILY documented.
A much better choice for your wifi mesh.
well, theoretically it should possible to build a mesh networking behavior with BLE devices, though it has not been designed that way.
The idea would be to use the fact that BLE has been designed so it can work over disconnections.
So you could handle two connections with your device: one as a bluetooth master and the other as a bluetooth slave. Then you could run once as a slave and listen to the next device's services see if there is any event, and if there is, become a master and broadcast the event to the previous device until the event reaches the host. The tricky part would be to tweak the timings so it works fastly and smoothly.
Another way that should be less a hack would be to build an ANT network for the mesh topology, while having BLE to be able to connect each node to Bluetooth enabled devices. You could use something like the nRF51422 to do such thing.
HTH
As I undertand, Bluetooth is something designed to do data transmission with a low power consumption. So compared to 802.15.4, Bluetooth shows a much shorter communication range which means more device maybe used to build a network. And I think BLE is just a name, just some code pre-programmed into chip ROM. Anyone can modify the BLE protocol, if he gets enough coding experience.
Related
I have been looking into LoRaWAN for a low cost waterproof asset tracker I am looking at building.
AFAIK, the primary benefits of LoraWAN over say LTE-M or cellular are: no connectivity costs and potentially lower power consumption.
What I'm wondering is: why can't we use our own cellphones as the "base station" that the IOT device talks with? We can do this with bluetooth and WiFi, why not cell? Is it the LTE protocol that prevents it? Physics? What am I missing?
There's quite a few architectural reasons why Peer-to-Peer LTE isn't feasible, but the largest is probably the fact that in LTE the uplink and downlink use different modulation techniques.
In the downlink (the connection from the Base stations (eNodeBs) to the User Equipment (our mobile phones)) Orthogonal Frequency Division Multiplex (OFDMA) is used, this means the phone listens out onto the RF interface for the OFDMA signal.
This works well, OFDMA is a great way of encoding the data onto the air interface, but it has a very high peak-to-average-power ratio, this means if the UEs used OFDMA in the Uplink (From the UE to the eNodeB) they'd have awful battery life.
Instead in the Uplink LTE uses Single Carrier Frequency Division Multiple Access (SC-FDMA), which is much more power efficient and allows you talk all day, so the eNodeBs listen on their RF interface for the SC-FDMA modulated traffic.
This means our UEs (Mobile phones) use one type of modulation to send and a different modulation scheme to receive, so they can't talk directly to one another as they can't send OFDMA modulated data, only receive & visa-versa.
Some more reading on OFDMA & SC-FDMA.
The LTE relay interface inducted as part of Release 10 allows the deployment of relay nodes (a kind of low cost eNB) that are fixed and that use in-band LTE to extend the coverage of standard eNodeBs by one hop, improve signal quality and to increase the network capacity. Relays can be placed such that it converts the long single hop into two shorter hops.
However the approach of using UE seems have many challenges as it can make UE to get bit loaded with more functional changes across layers(MAC, PHY, RRC, NAS) as it has to take additional functionalities from Relay nodes/eNB as well ranging from lower layer signalling, co-ordination, mobility to forwarding. Also, there might be additional power consumption and change in antenna to support the same which all will add to more cost of UE.
I am writing an app that is suppose to work without a connection to mobile carrier and without local WiFi. Each device will act as transmitter, receiver and router.
My main challenge so far is that I cannot figure out how exactly MultipeerConnectivity works as documentation on MC is really limited. Apple denied revealing technical specification of MC claiming it's a proprietary network stack, so I have to rely on network sniffers and reverse-engineering which is not the quickest way to figure out how MC works.
Suppose I have 100 devices forming a mesh network in such way that each device is within the range of at least one other device and at maximum three other devices.
Is there any way to send a message from node A to node B that is not within the range of node A without the need to broadcast the message to all other nodes? I mean that message should be properly routed through all other nodes.
Does MC include a routing layer too or I have to write it myself?
From what I can see ad hoc delay tolerant wireless networks is still a hot subject in research.
These slides on ad hoc delay tolerant wireless network shed more light on the subject as it was a few years ago. And also this paper. Has Apple progressed it much with MC?
I cannot really see any way to send a message between nodes not directly connected to each other without flooding.
Correct?
The MCSession Reference states that
Sessions currently support up to 8 peers, including the local peer.
Also, the overview you cited says
In the discovery phase, your app uses a browser object […] to browse for nearby peers[.]
Moreover, the documentation on managing peers manually suggests that all peers in a session must be connected with each other to have them in a session.
This is suggesting that the framework only covers the communication between nearby devices, as in 'reachable by bluetooth or WiFi'. Naturally, those devices do not need complex routing, as they do communicate with each other and the benefit of the framework is simple multicasting between nearby devices, from a programmers' point of view.
As far as your question goes, this is about it - trivially, since all peers an a MCSession have links to each other - there is no routing needed.
This does however, allow you to construct a routing layer pretty easy.
Given your scenario, there will be multiple MCSessions with devices being part of at least one. All devices that are part of more than one MCSession do become routers and interconnect the MCSessions with each other.
The rest of the task should be straight forward; defining a namespace for addressing devices and implementing a routing protocol of your choice.
The old days of the internet, with unstable dialup connections, might be a plus factor for you as the routing protocols in place are rather stable in regards of link loss.
Here are two good starting points for you to make your choice of better fit:
Link state routing
Distance vector routing
I want to create a network intrusion detection system for iOS application. The main function is to allow the user to select a home network (maybe prompt them to simply enter the IP address only) and to be able to monitor the packets and if there is anything suspicious- we need to alert user via push notification or email. i wanted to use the features and functions of Snort, an open source network intrusion detection system.
Any Suggestions,Sample code ?! Where to start?
VM's do not have native hardware access, which is necessary for monitor mode. Maybe IOMMU PCI passthrough or bridged devices might work. It is probable that it is possible to compile the iOS kernel with a module that works for the wireless nic. I don't think it's a proprietary chip specific to apple, because a chip with multie technology capabilities in RF wouldn't be cost effective qt all. I'm just not sure if the filesystem blocks access in the OS framework or whatever. I have tried to compile linux/iOS ARM packages natively in the shell with the aircrack-ng source, but have not had any luck. Maybe someone would have better luck actually cross-compiling a package and sideloading it somehow.
I don't think this is possible for multiple reasons:
You wouldn't be able to compile snort for iOS.
In order to run snort you have to have the interface (NIC) in promiscuous mode, which I really don't think you can do on an iOS device (iPhone, iPad, etc) but I have never really looked into it, but Apple probably locks this down and restricts this for security purposes so if you could do it you'd likely have to jail-break the device first. It's not even possible to put the wifi card in an Apple laptop into monitor mode, which is similar.
There are a lot of dependencies for snort, most importantly the DAQ. You would probably only be able to monitor the wifi interface (even this might not be possible), not the interface used for the cellular network as this is probably a different daq than standard Ethernet nics.
This very likely is not possible on iOS, if it is it would be VERY difficult to pull off and even if you did the use case isn't really good. Even if you could get a daq for the cellular card, I don't know if promiscuous mode even exists and if it did all of the traffic on the cellular network is encrypted, so inspecting this with snort would be pointless. If you could do it for the wifi traffic it's probably not worth the effort honestly, especially since almost all traffic nowadays is encrypted, you'd have to decrypt it first, which certainly isn't possible to do.
In the view of Johnjg12's comments, I am wondering about your goal. If you want to make a NIDS, you can make it OS independent, anyway. If you want to consider only HIDS that monitors packet destined to it, we don't need it to be in promiscuous mode (a comment to Johgj12's response). so, now it is something to do with Snort on iOS. I am wondering if we can do it on a VM and then turning its promiscuous mode? Having said that I came across a link: https://www.securemac.com/macosxsnort.php
I need to connect around 25 client devices to one server device (will all be iOS, though Android would be nice). I know there are several solutions to this problem, and I'd lean towards MultipeerConnectivity myself, but there is a limit of 8 simultaneous users. As dicussed elsewhere, there are workarounds, and I am not opposed to opening multiple sessions, but it it seems rather roundabout. I thought about using CocoaHTTPServer to make an API and advertise over Bonjour, but I would like it to work with a restrictive network, and preferably bypassing a public network all together. GameKit seems out for me because I don't want it to be open to the public (not a game, and specific to a confined area).
An HTTP server on some obscure (random) port seems like a good option, being cross-platform and easily testable with multiple devices, but school networks can be very restrictive. Multipeer gives the limitations of device numbers and other difficult-to-test variables, and GameKit is too public. Is there another route here, or should I narrow it down to CocoaHTTPServer, MultipeerConnectivity, or a combination of the two?
I decided to go with MultipeerConnectivity and using only one session, and letting some client devices wait for an opening in the server. I didn't really need every device to be connected simultaneously, and figured that the odds of Bluetooth being reliable with that many devices is unlikely anyways.
I'm working on an engineering project where I want a go-kart to maintain a direct connection with a base station. The base and go-kart can be separated by about a half mile (with lots of obstacles in between) which is too far for WiFi.
I'm thinking about using 3G/4G to directly connect the two. Does anyone have any resources or ideas that might help?
Or, alternatively, a better way to connect them? I'm just trying to send some sensor data (pretty low bandwidth) in real-time.
The biggest problem you face is radio spectrum that you are allowed to use. All 3G/4G spectrum is licensed to some firm and they get really unhappy (e.g. have you hunted down and fined) when you transmit in their space.
I did find DASH7 which
is an open source wireless sensor networking standard … which operates in the 433 MHz unlicensed ISM band. DASH7 provides multi-year battery life, range of up to 2 km, indoor location with 1 meter accuracy, low latency for connecting with moving things, a very small open source protocol stack …
with a parts cost around US$ 10. This sounds like it satisfies your requirements and keeps the local constabulary from bothering you.
You could maybe use SMS, between a modem on the kart and a mobile phone or modem at the base.
A mobile data connection like a telephone call isn't possible directly between the two; you have to make a data connection from the kart to a server in your operator's core network, identified by the APN. Then you can access IP addresses as for a normal internet connection - so the base computer would have to be a web server.