We are developing a mobile application that tracks users while they are picking up and delivering commodities. We have overcome many issues, including poor connectivity in rural areas, the app going into the background, and so on.
One issue continues to befuddle us. When receiving calls some drivers lose connectivity, other drivers will gain connectivity, and others (most) have no change in connectivity.
I remember earlier that Verizon iPhone users couldn't access data while on a call. Naively I thought that this issue was completely overcome, but perhaps it is not.
My understanding is that a) there are still some cellular protocols that cannot handle voice and data and b) there are (or were) some settings in mobile phones that give the user a choice.
I have searched for some list of cellular protocols and iOS and Android settings but so far come up empty.
Any guidance would be greatly appreciated.
Hopefully this will provide some more clarity; it all depends on the Radio Access Network (RAN) technology they're using (2G/3G/4G) and the terminal itself's capabilities.
There's 3 umbrella terms of technologies, each with their own revisions and variants, but this should cover it:
LTE (4G) only supports voice calls via VoLTE (Voice over LTE). Calls made over VoLTE will allow the user to continue accessing data at the same time. Many devices & some networks don't yet have VoLTE capability, so they use Circuit Switched Fall Back (CSFB) to drop to a 2G/3G Radio Access Network for making voice calls. (If your terminal does this you then have that RAN's ability to allow simultaneous voice/data.)
3G - There's a few flavors of "3G", depending on the terminal and the RAN variant (UMTS / EDGE / CDMA / HSDPA / HSDPA+) you may be able to access data and be on a call at the same time.
GSM (2G) does not have this functionality, the handset is either in Circuit Switched (Voice) or Packet Switched (Data) mode but not both.
The decision of which RAN to use is based off the priorities stored in the SIM/USIM, the received signal strength of the available networks and the capabilities of the terminal.
This means for example your users who may gain connectivity may find themselves using a 3G access technology on a 4G enabled terminal, with VoLTE support, jumping up to VoLTE to make the call. (Some operators resell to MVNOs but default to slower / older RAN technology like the 3G family)
Others may loose connectivity as you've seen, if they're happily using LTE on a device with no VoLTE support and need to drop to 2G/3G for a call (CSFB) they may loose data services as they're back to the limitations of these older RAN technologies.
Related
I'm most likely not using the correct terminology in my question.
Is it somehow possible for an iphone to receive an "audio stream" from other iPhones over Bluetooth?
The idea is to make an app that makes it possible to listen to the music libraries of other iPhones in the Bluetooth range. All while not having access to the internet and not needing to pair up and transfer the actual song onto the phone.
The thing you ask of is doable, but is not something trivial. Bluetooth communication can be implemented to work like a TCP/IP socket implementation, the only problem is, there is no actual protocol to follow. Usually the apps that implement bluetooth communication use they own protocols definitions in order to serve the purpose of the app.
There are several steps that have to take in consideration:
The transfer speed over bluetooth, it's not fast but it's not slow either, the main problem with the transfer over bluetooth is that you have to implement the data transfer, for example in TCP/IP the whole package exchange (send/acknowledge/receive) is done by the system, there's no general protocol implementation to do such thing using bluetooth.
The connection handling, this is something really tricky depending on OS & OS version, especially on iOS the connect/disconnect handling is clumsy & often buggy.
Security, without pairing and bonding there's no security. Even with pairing & bonding the security is flacky. Without security you might get your app hammered down and bricked by a simple bluetooth sniffer.
Other apps that use bluetooth, for IoT or other gadgets this is not an actual problem, but when you have a client/server like approach via bluetooth using two mobile phone you might get in trouble because of other apps that wrongly use the bluetooth (don't close connections, try to scan to frequently) and you can't do anything about it.
These are the things that cross trough my mind about the bluetooth communication, I've worked on several apps that connect to IoT and I can tell you it's not something trivial to implement. You get a lot of headache for things that you can't imagine.
As an alternative you could use WI-FI without internet connection, there was a trending post some time ago about Mesh Networks that use only the WIFI signal to transmit data, not even actual wifi network, worth checking out IMO.
I have just delivered a prototype for a big client, everything was fine but I'm now curious to know if the solution/architecture I've chosen was the right one or there's place for improvement in case the project will keep on.
The task was to build two iOS apps: one running on 5 different iPhones, and another running on 2 iPads. Basically the iPhone applications had to communicate information to the iPads, and occasionally they also had to send information between each other (iPhone to iPhone). All the infos where small JSON objects/chunks whose size was small, really small.
The app was not intended to reach the app store, is a working prototype to test out some ideas in a user testing environment.
I discarded bluetooth because we are talking about a peer-to-peer communication, not a one-to-one.
What I did was to use web sockets thanks to SocketIO, through a small Node.js server that was running on my mac. The server was really simple, just receiving the messages from the clients and broadcasting information to the other ones.
What do you think? Is the solution I've chosen ok, or there are better ones?
For example, this morning I've just found out these thread here on SO, and I've discovered I could have used GameKit. What do you think?
Socket.IO is nice because it is fairly simple to implement but it has the downside of requiring a central server. If you wanted to avoid that, you could use the Multipeer Connectivity framework that was introduced in iOS 7.
It will let you create one-to-one communication channels between devices on either the same WiFi network or Bluetooth. Once the channel is created, you can send whole NSData objects (or create streams but it doesn't seem relevant to your use case).
A good read : http://nshipster.com/multipeer-connectivity/
The WiTap sample from Apple demonstrates peer-to-peer networking over Wi-Fi and Bluetooth. Using Bonjour, the application both advertises itself on the local network and displays a list of other instances on the network. Supports infrastructure networks, peer-to-peer Bluetooth, and peer-to-peer Wi-Fi (on compatible hardware).
I have personally tested it and it works fine and well documented.
I think socket.io is the best choice. It is built on top of engine.io (which in turn is built on the fastest websocket implementation: ws) It has oldest to newest fallbacks, so it starts with long polling and works its way up. This guarantees a quick initial connection instead of needing to poll the device for features. You can read more on this here. Best of all, it handles everything seamlessly. You write your code as if websockets are supported on connecting devices and if not it will use other methods behind the scenes.
This post details many of the websocket libraries you could use with your server. Which websocket library to use with Node.js?
I am convinced Bonjour is the best solution:
Apps can also leverage Bonjour to automatically detect other instances
of the app (or other services) on the network.
However I've never used it myself; perhaps someone who has can comment?
I want to know how to get WIFI channel and frequency information in iOS.
It would be better not to get from the private APIs (because I need to submit it to the iTunes Store).
There's no way to do this using publicly available APIs, as of iOS 7. The OS algorithm controls networking and decides which channel to use based on congestion, interference, and other factors.
If you're okay with using private APIs, then you can use Stumbler, a library that exposes the data you're interested in: https://code.google.com/p/iphone-wireless/wiki/Stumbler
Warning: If you want to use private APIs, then you won't be able to distribute through the App Store (and you'll have all the other hazards that come with using Apple's private API: the banhammer, breakage at any time, et cetera).
As others noted there is no way to get wi-fi frequency on iOS using official APIs.
There is one work-around to determine whether user is connected to 2.4Ghz or 5Ghz range by actively running a wifi measurement. You can set a limit which will not be realistic on 2.4Ghz (e.g. typically speeds over 100 Mbit on wi-fi are not achievable on 2.4 Ghz).
To run wi-fi measurement its better to run true wi-fi speed measurement and not internet speed measurement as the latter can be slowed down by the ISP (and not the wi-fi).
Here is relevant Stackoverflow comment how to measure wi-fi speed - iOS Get Link Speed (Router Speed Test)
In either way you will not be able to determine actual wifi channel, only whether its 2.4 or 5Ghz. This can be further complicated in the future with 6Ghz ranges where it will not be that easy to split between 5 and 6 Ghz.
I'm trying to find out what AWDL is. On iOS, if you use Apple's peer-to-peer networking over BlueTooth, it seems Apple creates a new Network Interface "awdl0" to implement (I guess) IP-over-BT.
But I can't find any docs on this tech, or this interface, how it behaves, things we must / must not do with it, etc. Google comes up blank :(.
In particular, I believe it means "established a BT connection, and I'm running an IP bridge over the top, and you can use this to communicate peer-to-peer". Apple's own system libraries have bugs where this bridge isn't setup quickly enough, and if you send data too soon, it appears to get dropped by the OS. So ... if I can query this awdl0, I hope to check "are you ready yet?" and delay P2P messages until the OS is happy.
UPDATE
More info: I can get pairs of iOS devices to create awdl0 connections to each other - but they never get created to OS X machines, whether BT and Bonjour are on or not, whether the devices are paired or not.
Some background:
In iOS5, Apple permanently disabled the Bluetooth parts of Bonjour/Peer-to-peer networking, and published a technote instructing everyone to use DNS-SD if they wanted to keep using Bluetooth as a transport between iOS devices. This is fine, but it means you must use DNS-SD if you want high-performance BT, and you want it reliable.
(GameKit sometimes works fine, but we often see terrible performance in real-world scenarios, e.g. crowded public places - which goes away if you use DNS-SD)
DNS-SD protocol doesn't include info to tell you what the hardware is using. But it does tell you the Network Interfaces (which is how I know we're running on awdl0)
DNS-SD is awesome, and we have high-speed, low latency connections peer-to-peer between iOS devices - all the stuff that GameKit promises but often fails to deliver whenever there's more than a few wifi/BT devices in range.
AWDL recently caught a lot of attention when it caused Wi-Fi issues in iOS 8 and OS X Yosemite devices.
What is AWDL?
AWDL (Apple Wireless Direct Link) is a low latency/high speed WiFi peer-to peer-connection Apple uses for everywhere you’d expect: AirDrop, GameKit (which also uses Bluetooth), AirPlay, and perhaps elsewhere. It works using its own dedicated network interface, typically “awdl0".
While some services, like Instant HotSpot, Bluetooth Tethering (of course), and GameKit advertise their services over Bluetooth SDP, Apple decided to advertise AirDrop over WiFi and inadvertently destroyed WiFi performance for millions of Yosemite and iOS 8 users.
How does AWDL work?
Since the iPhone 4, the iOS kernels have had multiple WiFi interfaces to 1 WiFi Broadcom hardware chip.
en0 — primary WiFi interface
ap1 — access point interface used for WiFi tethering
awdl0 — Apple Wireless Direct Link interface (since iOS 7?)
By having multiple interfaces, Apple is able to have your standard WiFi connection on en0, while still broadcasting, browsing, and resolving peer to peer connections on awdl0 (just not well).
You can find more info here and here.
I'd like to provide a more precise answer as to how the protocol works internally. I quote part of the abstract of this paper.
In short, each AWDL node announces a sequence of Availability Windows
(AWs) indicating its readiness to communicate with other AWDL nodes.
An elected master node synchronizes these sequences. Outside the AWs,
nodes can tune their Wi-Fi radio to a different channel to communicate
with an access point, or could turn it off to save energy.
From a user perspective, AWDL allows a device remain connected to an infrastructure-based Wi-Fi network and communicate with AWDL peers "at the same time" by quickly hopping between the channels of the two networks (AWDL uses fixed social channels 6, 44, and 149). In contrast to the previous answer, we found that current versions of AWDL work fairly well and channel hopping only induces a small overhead.
Disclaimer: I'm co-author of this paper and we retrieved this information by means of reverse engineering. If you are interested in the details, please read the paper and have a look at the Wireshark dissector (published soon).
I have a situation where I would like to communicate between 2-4 devices over the 3G network (it should also work over WLAN, but 3G solution is critical).
Every device (except one) asks for a GPS-location every ~5 seconds, but when this process is cancelled by the user of that device, one device needs to be informed of this event.
I was thinking that one device could act as a server, and the rest as clients that should connect to the server. Is this possible over the 3G network?
I've also read about push-notifications, is this relevant here? Can you receive notifications without disturbing the user with a popups etc?
Are there other ways?
Basically I would like to use apple "standard" solutions (if there are any) before diving into eventual socket-programming or anything similar...
What I would like to avoid is to have a webserver or some similar "3rd-party" solution, because I don't want many users to simultaniously connect and "pull" from the same external server in a final solution...
UPDATE:
Basically my application will have thousands of users that will need to be informed if an even occurs. Also this happens simultanously ~5 second, what would be the best solution to reduce load and avoid spamming?
I was thinking that one device could act as a server, and the rest as
clients that should connect to the server. Is this possible over the
3G network?
It could work, but having a dedicated server would be a better choice
I've also read about push-notifications, is this relevant here? Can
you receive notifications without disturbing the user with a popups
etc?
In your case no, since you will need a server to communicate with apple
Basically I would like to use apple "standard" solutions (if there are
any) before diving into eventual socket-programming or anything
similar...
There are no standard solution, other than you should probably rethink about using a dedicated remote server for this
iPhones can't communicate directly with each other using 3G. You can access the internet through the 3G, but you can't do peer-to-peer as you are suggesting. If you were close enough, you could use bluetooth, but I expect you are too far away.
You would have no way of detecting the one device that acts as a server from the other devices. The IP address could (and probably would) change every time the device connects to a mobile data network. You would need a central server to co-ordinate all of the clients.
You have multiple questions, but I'll try to address as many of them as I can:
I was thinking that one device could act as a server, and the rest as
clients that should connect to the server. Is this possible over the
3G network?
No, you cannot run a server on a iPhone/iPad that is accessible over 3G without an external website acting as an intermediary. (You can run one that is accessible over Wi-Fi, but this does not solve your problem as stated.)
I've also read about push-notifications, is this relevant here? Can
you receive notifications without disturbing the user with a popups
etc?
Push requires you (or a third party contracted by you) to have a web server, so if you want a server-free solution it is not relevant here.
Are there other ways?
Over 3G you will, under the current Apple restrictions, always need an external server.
Basically I would like to use apple "standard" solutions (if there are any) before diving into eventual socket-programming or anything similar...
Diving won't help you here. Even using low-level socket programming you will not be able to run a server on an iPhone accessible over 3G without an external website to aid in establishing a connection.
You can try using GameCenter. The mechanism of network games in Game Center allows connect up to four players with no third-party solutions.