こんにちは．初めての投稿になります．

シミュレータを使うのがこれが初めてです．

シンクノード4台，センサノード100台置き，シンクノードからlookupでデータを要求してセンサノードがシンクノードへデータを返すシミュレーションをしました．またセンサノード100台のうち10台のみデータサイズを大きくしました．経路はマルチホップです．
大きいデータサイズを含めることでデータの取得率が下がることは予想していた通りです．
そこで，パケットロスが原因なのは分かりますがどこのノードでどれだけのパケットがロスしているのかを知りたいです．シンクから1ホップのノードの受信データ量が大きいため，その辺のノードだと予測しています．また，要求のパケットではなくデータを返すパケットが落ちていると考えています．
どこにどのようなプログラムを書けばよいのかが分からない状態です．

よろしくお願いします．

QualNet改造して状況を分析する前に、
まず最初に.statを詳細に分析することをお勧めします。
PHYで落ちているのか、MACで落ちているのか、などを確認して
どのレイヤで想定した数と合わなくなっているのかを分析してみる。

.statの統計情報で把握できなければStatistics Databaseを使って
より詳細な時系列情報で確認してみる。

まず既存機能で収集可能な情報を使ってみるのが良いと思います。

返信遅くなりました．
コメントありがとうございます．

GUIのAnalyzerでNetworkではData bytes sent unicast(bytes),Data bytes received unicast(bytes),
MACではUnicast packets sent to channel,Unicast packets received clearly,
PhysicalではSignals received with errors(signals),Signals sent to mac(signals)
を見ているのですが，パケットがどこで落ちているのか判断の仕方が分かりません．見ているところが違うのか，見方を誤っているのかもしれませんが宜しくお願い致します．

正解はありません、というかシナリオ依存なので一般論になります。
まずは、アプリケーションの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つのシミュレーション結果だけでは解析が難しいことが多いです。
条件を変更しながら結果を比較すると問題点がわかるかもしれません。

MACで落ちていることが分かりました。

シンクノードへどのセンサノードからのデータがどこで落ちたのかまでは分からなかったので、各ノードでreceiveErrorOccurred = 1であった数をカウントして傾向を見ました。
receiveErrorOccurredとデータの到達率には関係性はありますか。また、receiveErrorOccurredの定義を確認したいため教えてください。

使用しているのは、802.15.4ですよね。
> receiveErrorOccurred = 1であった数をカウントして傾向を見ました。
すみません、具体的にどのような方法で確認したのか教えて下さい。
ソースコードにログを追加した?

> receiveErrorOccurredとデータの到達率には関係性はありますか。
receiveError という事なので、受信エラーが発生してさらに再送がなければ
当然そこで落ちているはずです。

> receiveErrorOccurredの定義を確認したいため教えてください。
receiveErrorOccurredがどのような条件で1に設定されるか?
という事であればソースコード見るのが早いです。
receiveErrorOccurredという変数がソースコードに出現するのは
phy_802_15_4.cppのみで、3カ所なので簡単だと思います。

>具体的にどのような方法で確認したのか教えて下さい。
Physical LayerのRadioTypeをAbstractに設定し，
phy_abstract.cppの中に追加しました．
添付したテキストの最後にある
//コメント追加
の部分が足したところです．

>receiveError という事なので、受信エラーが発生してさらに再送がなければ当然そこで落ちているはずです。
再送がなければとはどういうことでしょうか．

>receiveErrorOccurredという変数がソースコードに出現するのは
phy_802_15_4.cppのみで、3カ所なので簡単だと思います。
シンクからの要求，要求を受けたセンサがシンクへの返信を含めたエラーであると思っています．
memo.txt

フォーラム管理者からのお願いです。
オリジナルソースコードをそのままアップロードすることはご遠慮下さい。

該当ファイルについては削除させて頂きました。

必要であれば追加部分のみの引用にして頂くか、
ソースコードを含まない情報にしていただくようお願いいたします。

>具体的にどのような方法で確認したのか教えて下さい。
Physical LayerのRadioTypeをAbstractに設定し，
phy_abstract.cppの中に
if文でreceiveErrorOccurred == 1なら
node->receiveErrorOccurred++するように
追加しました.
．

>receiveError という事なので、受信エラーが発生してさらに再送がなければ当然そこで落ちているはずです。
再送がなければとはどういうことでしょうか．

>receiveErrorOccurredという変数がソースコードに出現するのは
phy_802_15_4.cppのみで、3カ所なので簡単だと思います。
シンクからの要求，要求を受けたセンサがシンクへの返信を含めたエラーであると思っています．

ちょっと整理させて下さい。
PHYは802.15.4 RadioではなくAbstractですね。

前後しますが、
receiveErrorOccurred はBOOLなのでTRUE/FALSEのみで、
一般的にはTRUEは1で、FALSEは0です。

receiveErrorOccurred に値を設定している箇所は以下の部分。
receiveErrorOccurred = phy_abstract->rxMsgError;

phy_abstract->rxMsgError はその直前で
関数 PhyAbstractCheckRxPacketError呼び出しによって設定します。
具体的な処理(エラー判定)内容はここでは省略するので、
ご自分で確認して下さい。

再送についてですが、
receiveErrorOccurredはPHYレイヤの処理です。
上位層に何を使用しているか不明だったので、
再送の可能性が否定できずに再送の有無としました。

ここまではよろしいですか?