scallionさんアドバイスありがとうございます。
お二方のご指摘を参考にし以下の２つの検証を行ってみました。

ForwardPacket関数も実はすでに見つけていたのですが、StaticRoutingを行っていたシナリオでデバッグをしたところ
desaddressの値がGUIで設定していた宛先ノードIPアドレスと一致していなかったため、この関数は無視していたのですが、
再度、ルーティングミスのご指摘いただいたので、一度OLSRでStaticRouteを用いなかった時のForwardPacket関数の動作を追いました。


【まず最初に】：
「olsrのみでルーティングを行ったシナリオではForwardPacket関数での動作とGUI画面の【Output windows】に表示させた
ルーティングテーブルを追った時の結果が一致しました。(検証1)
今回登場する３つのシナリオは全て１つのCBR通信しか用意していません。
今回追った変数はpreviousHopaddress,noedId,desaddress,nexthopaddressの４つです。

【検証１】olsrのみでルーティングを行った際のForwardPacket関数の動作チェック
routing_olsr-inria.cppファイルの↓の値を0から1に変えるとGUI上の【Outputwindow】にルーティングテーブルが表示されます。
#define DEBUG_OUTPUT 0

【OutputWindow】にて1->2->5->6->9このようにCBR通信がマルチホップされていることが分かりました。
このパケットの流れの動作を確認するためにForwardPacket関数の以下の行の先頭にブレークポイントを設置しました。
●NetworkDataIp *ip = (NetworkDataIp *) node->networkData.networkVar;

NetworkDataIp構造体の中にforwardTable構造体があり、さらにこの中にrow構造体があります。
row構造体のメンバ内にdesAddressとnextHopAddressがあります。
previousHopaddressはForwardPacket関数の引数としてあり、noedIDも引数として読み込まれます。

【実際のルート】1->2->5->6->9
【捕捉】addressに関しては実際は2835349505　このような数値で出力されますが、わかりづらいためここでは、
この数値をIPアドレスに変換した場合の最後の１ケタの数字のみを書いてあります。(数値を2進数に変換→8bitずつに区切り10進数に再度変換することでIPアドレスが得られます。)
2835349505→169.0.0.1→1と書いてあります。
IPアドレスと実際のノード番号のずれがないことは事前に確認済みです。

スタート(F5(デバッグ))→ステップイン(F11)
【デバッグ結果】
previousHopaddress=1
noedId=2
desaddress=9
nexthopaddress=5

↓F5＋F11

previousHopaddress=2
noedId=5
desaddress=9
nexthopaddress=6

↓F5＋F11
previousHopaddress=5
noedId=6
desaddress=9
nexthopaddress=9

以下この流れをループしました。
この動作から1->2->5->6->9のうち2->5->6->9とマルチホップしたことが確認できました。
【疑問点１】
1->2を更新した部分がForwardPacket関数に入るまえに行われたことが考えられますが、visual studioの呼び出し機能などを
使っても中々把握できない現状です。これを把握するにはどうすればいいでしょうか？
上で挙げた流れを考慮すると
previousHopaddress=null
noedId=1
desaddress=9
nexthopaddress=2
となる瞬間があるはずだと考えているのですが、このように変化するポイントが見つかりません。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【検証２】
OLSRを動かしつつStaticRoutingはできないないのではないか？という指摘をいただいたので以下のことを検証してみました。
GUI上で【Nodes】と【Networks】からRouting Protocolをolsr_inriaに設定した場合と
Bellmann Ford(デフォルトでこの設定になっている)に設定した場合で、3kake3の格子上のネットワークにて
1->4->7->8->9->6->3->2このようなStaticRoutingを行わせるように設定しました。
Staticファイルは添付しておきました。(2番と5番以外にこのStaticファイルを持たせています。)
少なくともGUI上では確実にStaticRouteで設定したRouteを通っていることが確認できています。
しかし検証１と同様にForwardPacket関数を追ってみたところ以下のような結果になってしまいました。

previousHopaddress=1
noedId=4
desaddress=9
nexthopaddress=5

↓F5+F11
previousHopaddress=4
noedId=7
desaddress=9
nexthopaddress=8

↓F5+F11
previousHopaddress=7
noedId=8
desaddress=9
nexthopaddress=9
//ここで目的値にたどりついたのかと思いましたが..以下につながる

↓F5+F11
previousHopaddress=8
noedId=9
desaddress=8
nexthopaddress=8
以下の変数の変動は確認していません。

まずdesaddress=9になっている時点でおかしいことがわかります。
宛先受信端末ノードは2番に設定してあります(1->4->7->8->9->6->3->2)

【疑問点２】
結局,StaticRoutingは設定できいないということなのでしょうか。
デフォルト設定のBellmann FordでもStaticRoutingの動作がForwadPacket関数で確認できなかったわけですが、
結局StaticRoutingとは何だったのかという疑問が残ります。

【疑問点３】
GUI上では間違いなくStaticRouteを通っているわけですが、ForwardPacket関数内とは別のところで
StaticRoutingを用いたフォワーディングが行われれていたか、ForwardPacket関数での謎のフォワーディング動作が行われてしまい
、本題であるパケットを分散したにも関わらず結果が逆に悪くなってしまったことにつながったと考えるべきでしょうか。
そうだとした場合はForwardPacket関数を読み込んでいる部分を全てコメントアウトすれば、期待通りの結果が得られるのか（これは後日また検証しています）

【疑問点4と仮説】
検証１に書いたようにStaticRoutingを用いない場合ではForwardPacket関数での動作をほぼ追えたわけですが、
その際に、このForwardPacket関数が何回デバッグで通過したのかを確認しました。
結果は1200回、ForwardPacket関数がデバッグされました。

検証１に挙げた通りnexthopaddress=9になる（宛先端末ノードに到達する）のに３回
このForwardPacket関数を通過することが簡単に確認していただけるかと思います。
つまり,宛先端末ノードに到達するのに必要なデバッグ回数は3回ということ。
1200/3=400

実はこの400という数字は1番から9番に送信させたときのItems to sendの値を一致します。
何がいいたいかというと、QualNetでは（少なくとも本シナリオでは）１パケットずつソースプログラム上で
送信しており、現在送っているパケットが宛先端末ノードにたどりついてから、次のパケットを送信する。
このプロセスを400回繰り返し、400パケット宛先端末ノードに送信しているということです。

StaticRoutingの未だによくわからない現象により、トラフィックの分散による結果がよくならないということに、悩まされているわけですが、
もし上で挙げた仮説を真とした場合、この関数に通った回数が300を超えたら
previousHopaddress,noedId,desaddress,nexthopaddressこれらの値を下記の直後で変更することで、
StaticRoutingを用いなくても、パケットの分散をすることができ、(400パケットを300パケット用のルートと100パケット用のルートで分断)期待通りの結果が得られるのではないかと考えているのですが
どうでしょうか？

●NetworkDataIp *ip = (NetworkDataIp *) node->networkData.networkVar;

この方針で今後頑張っていこうと考えているわけですが、ここで疑問点１が浮上し
1->2->5->6->9の流れのうち、1->2の経路選択を変更できない点に悩まされています。

情報が不足してる点などがあれば、ご指摘いただければ捕捉いたします。
アドバイスしていただけると幸いです。よろしくお願いします。


添付ファイル：
1to9_NoStatic_olsr：検証１用のシナリオ
1to2_14789632：検証２用のolsr+static
Bellmann_Ford_static:検証２用のBellmann Ford用のStatic

1月28日まとめ.zip



＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【追記】1月28日
お恥ずかしながら、RoutingProtocolの選択の覧に【None】があることに気づきました。これを知らなかったので上記の検証2で、RoutingProtocolを態々デフォルトのBellmann Fordを選択していたわけですが...

Routing Protocolを【None】にしたうえで、Static Routingを設定し
ForwardPacket関数の動作を追ってみたところ。
GUIのアニメーション画面、ForwardPacket関数の動作の両方でStaticRoutingで設定した経路を通っていたことを確認しました。
つまり、お二方からご指摘いただいた通り、Routingの設定がうまくいっていなかった模様です。
ただ未だに何故GUI画面ではStatic Routeを通っていたのかが分かりません。とりあえず、この理由は今すぐに知る必要はないのですが、やはり
疑問点１に書いたように、1->2へとパケットをフォワーディングする部分がソースプログラム上で見つかりません。

【疑問点１】
1->2を更新した部分がForwardPacket関数に入るまえに行われたことが考えられますが、visual studioの呼び出し機能などを
使っても中々把握できない現状です。これを把握するにはどうすればいいでしょうか？
上で挙げた流れを考慮すると
previousHopaddress=null
noedId=1
desaddress=9
nexthopaddress=2
となる瞬間があるはずだと考えているのですが、このように変化するポイントが見つかりません。