Question

As I understand, before the Mango SDK update (7.1), you were only able to access a rather broad network type via the property NetworkInterface.NetworkInterfaceType. This would return an enumeration like Wireless80211, MobileBroadbandGSM, or MobileBroadbandCDMA.

After the release of the Mango SDK, we are now able to access the NetworkInterfaceSubtype via an open socket using a call similar to this: socket.GetCurrentNetworkInterface(); A property of the returned object (NetworkInterfaceInfo.InterfaceSubtype) will give you more specific network information such as Cellular_EDGE, Cellular_HSPA, or Cellular_EVDV. This is the information I need.

The most efficient way I have found to access this is to open an async host name resolution request and grab the information in the async callback function, such as below (borrowed from this post: How can I check for 3G, wifi, EDGE, Cellular Networks in Windows Phone 7?):

DeviceNetworkInformation.ResolveHostNameAsync(
        new DnsEndPoint("microsoft.com", 80), 
        new NameResolutionCallback(nrr =>
            {
                var info = nrr.NetworkInterface;
                var subType = info.InterfaceSubtype;
            }), null);

What I’m looking for is a way to access this NetworkSubtype information without having to actually open a data connection. The reason I need a passive method for querying this information is that I need to know when the network type changes, but continually opening a data connection in a loop that queries this could potentially prevent that change from taking place.

UPDATE 1: I have found through testing that, as Richard Szalay suggested, the DeviceNetworkInformation.NetworkAvailabilityChanged event does indeed fire when the handset switches network technologies (i.e. 3G to EDGE, or WiFi to HSPA), and you do have access to the NetworkInterfaceSubtype. I unfortunately have also found that when switching from WiFi to a cellular network technology (e.g. HSPA, EDGE) that the reported network subtype can often be inaccurate. For instance, if you switch from WiFi to HSPA, the event arguments may still report a connection to WiFi when it gets fired, and no second event is fired to report HSPA. You are thus given the wrong connection type. This unreliability may make using this trigger ultimately useless, but I am going to do some network testing (without WiFi) to see if this issue is confined to WiFi switching. I’m hoping that it’s just an issue with the WiFi radio, and that cellular network switching is reported accurately. I’ll update this when I know more.

UPDATE 2: I have found through a lot of (driving around) testing that while the DeviceNetworkInformation.NetworkAvailabilityChanged event will get you the network changes, it does not seem possible to determine exactly what raises/triggers the event. For instance, if you’re recording the network interface each time the event is triggered, you could end up with results like: HSPA, EDGE, EDGE, EDGE, GPRS, GPRS, HSPA. The event argument object has a variable named NotificationType that is supposed to tell you the reason it was triggered, but this is always set to CharacteristicUpdate in my tests, so I have no idea why it is being triggered multiple times for the same network type (e.g. EDGE, EDGE, EDGE). For my purposes, I am just recording the changes that have not already been recorded and ignoring the multiples. It is not ideal (and seems slightly less than trustworthy), but it’s better than nothing, I suppose.

Answer 1

I posted the answer you grabbed the code from, and I did a bit of research for that question (including going through the reflected source of the WP7 framework).

Unfortunately NetworkSubType is not publically exposed from any location that is not the result of an open connection, with host name resolution being the simplest.

The only thing I can recommend is doing a test to determine if DeviceNetworkInformation.NetworkAvailabilityChanged is fired when your data type changes (say, from 3G to H). If so, you can perform another resolution at that time (though even that may prove too costly). If not, I’m afraid you’re out of luck.