Yes, see the PDCP-LTE wiki page - it is an option that is switched off by default. I think I made some important fixes/improvements since the 1.2 branch was created, so I'd suggest using the latest svn sources or automated developement builds.
At the moment:
- MAC calls RRC for CCCH, BCH, PCH (i.e. when we know the RLC mode is transparent)
- RLC could do the same, but doesn't yet (it'll be easy to add once people start using the proper 3GPP RRC spec)
- PDCP can call RRC (for all signalling messages) or IP (for user plane messages) (assuming no ciphering)
This is mostly because the product I work with allows logging at all of those levels. And its nice to set a display filter to look at one RLC flow (e.g. UL SRB1 and their DL status PDUs) without cluttering the display with MAC PDUs that have control PDUs and other SDUs that don't relate to the flow I'm interesting in. Or just to look at the PDCP flow for a channel (without having to rely upon RLC re-assembly).
It should be possible to make this all work by reading the RRC messages and remembering the config information. This has been done for UMTS IuB by Tobias Witek, but not yet committed (neither I nor anyone else has properly reviewed it yet). See
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3495 - a similar approach may be feasible for LTE S1.
There are several items of context information that must be known in order to successfully decode MAC-LTE PDUs (and other information that is optional, but useful to display). The same thing applies to RLC, PDCP and RRC.
The file format I work with (
http://wiki.wireshark.org/DCT2000) supplies this information. Several people asked about logging MAC PDUs by sending them over UDP or TCP, but it never went anywhere. So I added an example format over UDP that Wireshark can understand and an example program that sends UDP frames using this format (at least one person is so far using this format). In this format, several fields are mandatory, others are optional and use tags to indicate their presence. I don't use this format.
I didn't want to register a UDP port for this format, so I made it a heuristic dissector (i.e. there is a special string that appears at the front of the frame). Another approach would have been to use a configurable port number.
Hope this helps,
Martin