LTE decoding options.

That's a pretty open-ended question. Assuming you're coming from the radio side based on the viewpoint of your question:

For "not talking to MME/SGw issues", if you mean at a UE Context level or bearer level, you can create all sorts of stats out of packet captures (especially with tshark -z options), though usually the eNodeB would have these kinds of success rate info in KPIs also (I can't imagine an eNodeB supplier who wouldn't support that). Stats at the eNodeB level are probably more practical since they're also going to have stats on far more common problems like handover failures, pilot pollution indicators, etc. While packet captures in theory can get most of that, X2AP traces are a challenge to capture across a network due their extremely distributed, multipoint nature across geographic areas whereas S1 interfaces would be terminating in operator COs. If really limited to just captures, S1-MME can serve as a poor man's X2 since you can use path switch indicators to indirectly determine handover rates.

At a node level, MME connections from the EUTRAN are all carried over SCTP, in always-on stateful sessions or 'associations'. Any MME worth its salt will have some kind of PM or alarming functionality for detecting that type of failure, even if the eNodeB isn't still alive to tell the tale. To the question on-point, again yes in concept scripted tshark reads could look for error indicators (eg:S1AP setup procedure attempts, SCTP-level INIT/Abort/Shutdown chunks).

At an individual UE level, usually when troubleshooting in the EPS it's very call flow driven. So, if the UE can't register The first thing to do is grab the NAS exchanges to the MME(s) and confirm if it is even requesting an attach. If it is, move on to authentication over S6a, then gateway selection and so on. 99% of the time if it is a problem beyond the EUTRAN you will eventually trace the normal call flow out to a tangible error code between one node or another.