As I understand it, before upgrading the Mango SDK (7.1), you could access a fairly wide network type using the NetworkInterface.NetworkInterfaceType property. This will return an enumeration such as Wireless80211 , MobileBroadbandGSM or MobileBroadbandCDMA .
After the release of the Mango SDK, we can now access NetworkInterfaceSubtype through an open socket using a call like this: socket.GetCurrentNetworkInterface(); The return object property ( 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 found access was to open an asynchronous host name resolution request and capture the information in the async callback function, for example below (borrowed from this message: How can I check 3G, Wi-Fi, 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 actually opening a data connection. The reason I need a passive method for requesting this information is because I need to know when the type of network changes, but constantly opening a data connection in a loop that requests it can potentially prevent this change.
UPDATE 1: I found through testing that, as Richard Salay suggested, the DeviceNetworkInformation.NetworkAvailabilityChanged event really fires when the phone switches network technologies (e.g. 3G to EDGE or WiFi to HSPA) and you have access to NetworkInterfaceSubtype . Unfortunately, I also found that when switching from Wi-Fi to cellular network technology (for example, HSPA, EDGE), the specified network subtype can often be inaccurate. For example, if you switch from Wi-Fi to HSPA, the event arguments may indicate a Wi-Fi connection when it starts, and no second event will be sent for the HSPA message. Thus, you get the wrong type of connection. This insecurity may make using this trigger ultimately useless, but I'm going to do some network testing (without WiFi) to see if this problem is limited to switching WiFi. I hope this is just a problem with the Wi-Fi radio and this message about the cellular network is being reported accurately. I will update this when I learn more.
UPDATE 2: I found that during testing (driving), when the DeviceNetworkInformation.NetworkAvailabilityChanged event leads to network changes, it is not possible to pinpoint what triggers / triggers the event. For example, if you record a network interface every time an event is triggered, you can get results such as: HSPA, EDGE, EDGE, EDGE, GPRS, GPRS, HSPA. The event argument object has a variable called NotificationType that should tell you the reason it was run, but in my tests it always sets CharacteristicUpdate , so I have no idea why it runs several times for the same type of network (e.g. EDGE , EDGE, EDGE). For my purposes, I simply record changes that have not yet been recorded, and ignoring the multiplicity. It's not perfect (and seems a little less reliable), but it's better than nothing, I suppose.