To get a better understanding of how GPRS looks like at the air interface, I implemented some first experimental code in Airprobe (this is not yet ready to be released). The output of this code are the RLC/MAC blocks on the downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC yet.The GPRS air interface is not that different than "standard" GSM (signalling or voice). The PDCH (Packet Data Channel) uses its own multiframe structure with a length of 52 frames, the biggest difference are four coding schemes (CS-1 to CS-4, CS-1 and CS-2 use puncturing) which are chosen depending on the quality of the radio link. If the link quality is good, a coding scheme with less forward error correction and more information bits is used which results in a higher data rate. As a side note, you can test how good your receiver really is if CS-4 is used (very good radio link quality, no forward error correction at all), you should have nearly no bit errors in the decoded data (the phone also receives error free data, otherwise CS-4 would not be used).
I have not yet implemented decoding EDGE, besides other coding schemes EDGE can also use a different modulation (8-PSK instead of GMSK).
Please note that being able to decrypt the A5 encryption does not help with GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm (GEA) at a higher level. If you want to experiment with GPRS encryption, the easiest to start with is probably using a GPRS setup with OpenBSC plus the nanoBTS and look at the traces to the SGSN with WireShark (you have to implement a GPRS encryption algorithm in osmo-SGSN first, the specification of GEA3 is publicly available).