正解はありません、というかシナリオ依存なので一般論になります。
まずは、アプリケーションの1パケットがPHYの送信で幾つになるかを把握することです。
そのためには、アプリケーション設定ないの場合のstatも必要です。

正攻法の場合です。

まず、特定のNodeで追いかけます。
最初に追いかけるのはトラヒック(アプリケーション設定の送信側)を送信しているNode。
上位レイヤのApplicationから順に下位レイヤに値を確認します。

ほとんどの場合、上位レイヤのパケットはそのままPHYレイヤまで到達します。
PHYがbusyだったりするとQueueに溜るか、破棄(drop)されるかもしれません。
ルーティング情報が未完成だと送信先が見つからないかもしれません。この時もQueueに溜るか破棄です。
また、Node内でパケットが分割されているかもしれません。
パケット数とバイト数を比較しながら確認します。

ここまでは、何とか分析できるはずです。

次に中継Nodeを見つけます。これは意外と大変です。
無線であればたぶん一番近いNodeの可能性が高いです。
でもルーティング設定で別のNodeになるかもしれません。

なんとか見つかったら、PHYレイヤの受信カウントを見ます。
理想的には送信側の送信カウントと同じカウントになります。
でもほとんどの場合、周辺の他Nodeからの受信が混ざっています。
中継の場合はPHYからMACまで、さらに中継処理を行うレイヤまで届きます。
中継すべきと判断されると再びPHYまで降りていきます。
理想的には受信カウントと同じ送信カウントになります。

次の中継Nodeを...以下同様です。

最後に受信側NodeでPHYレイヤから上位レイヤに向かって追いかけます。

というように、データの流れをNodeのレイヤに従って地道にたどることになります。

別のアプローチとして、最終的な受信側Nodeをわざと途中の中継Nodeにする方法もあります。
一気に送信側から受信側の流れを解析するのではなく、少しずつ受信側にたどり着く過程を調べる方法です。

Nodeの接続関係を絵にかいて(GUI画面のコピーでもOK)、
送信側からPHYが何個送信して、他のNodeが何個受信しているかを書き込むだけでも傾向が掴めるかもしれません。
アプリケーションに依存しないカウントを排除するためには、アプリケーション設定で送信なしのシナリオ実行結果のstatも参考になると思います。
アプリケーションとして送信するパケットを徐々に増やすことで何か傾向が掴めると思います。

Node数が多かったり、ルーティングが複雑だと解析が大変です。
まずシンプルなモデルで基本的な確認を行い、傾向をつかむことも大切です。

いずれにせよ、1つのシミュレーション結果だけでは解析が難しいことが多いです。
条件を変更しながら結果を比較すると問題点がわかるかもしれません。