JP2006345174A - 送受信方法およびプログラム並びに記録媒体 - Google Patents

送受信方法およびプログラム並びに記録媒体 Download PDF

Info

Publication number
JP2006345174A
JP2006345174A JP2005168277A JP2005168277A JP2006345174A JP 2006345174 A JP2006345174 A JP 2006345174A JP 2005168277 A JP2005168277 A JP 2005168277A JP 2005168277 A JP2005168277 A JP 2005168277A JP 2006345174 A JP2006345174 A JP 2006345174A
Authority
JP
Japan
Prior art keywords
information
terminal
communication
path
communication terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2005168277A
Other languages
English (en)
Inventor
Taku Toyokawa
卓 豊川
Hisao Kumai
久雄 熊井
Toru Sugayama
亨 菅山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Priority to JP2005168277A priority Critical patent/JP2006345174A/ja
Publication of JP2006345174A publication Critical patent/JP2006345174A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】通信端末上における複数のフローは、フロー毎にユーザもしくはアプリケーションの嗜好を反映した自分と相手の通信メディアの組み合わせを選択することができ、しかも、嗜好情報を相手に知られることなく実行可能な送受信方法を提供する。
【解決手段】通信端末間で、1以上のパス(通信路)で、1以上のフロー(データの流れ)を送受信する際に、アプリケーションの嗜好情報を参考にして、MobileIPにおけるCoAの組み合わせ(通信相手のCoAと自身のCoA)を選択する手段を提示する。スコア付けは端末毎に別個に行い、そのスコアだけを送信し、スコアの和を取ることによって最適のパスを選択する。その結果、各フローごとに両者の嗜好に適したCoAの選択が行われる。
【選択図】図1

Description

本発明は、MobileIPなどの第三層移動管理プロトコルにおける通信路選択機能を有し、アプリケーションに帯域を割り当てる送受信方法に関する。
近年、MobileIPv6(Mobility Support in IPv6、RFC3775)等のIP層でのモビリティサポートの研究・開発が盛んである。MobileIPは、OSI(Open Systems Interconnection)7階層モデルにおける第三層のプロトコルで、上位アプリケーションからクライアントの移動(ネットワーク/通信メディアの切り替えや、通信の瞬断など)を隠蔽し、通信を継続させる技術である。このMobileIPは、モバイルノード(MN:Mobile Node)・ホームエージェント(HA:Home Agent)、コレスポンデントノード(CN:Correspondent Node)と呼ばれるノードから構成される。
モバイルノード(MN)は、ホームアドレスと呼ばれる常に不変なアドレスを有しており、そのアドレスを管理するノードがホームエージェント(HA)である。MNはHAのリンクであるホームリンク以外のネットワークに接続した際、ケアオブアドレス(CoA:Care-of Address)と呼ばれるアドレスを何らかの手段(RA、DHCPv6など)で得る。ここで得たCoAは、HAにBinding Updateというメッセージで通知される。
この結果、MNと通信したいノード(=CN)がホームアドレス宛にパケットを送信すると、ホームアドレスはHAの管理するリンクのアドレスであるので、一旦、HAに届く。その際に、HAは、ホームアドレスを関連付けされたCoA宛に転送する。この結果、常にMNは、ホームアドレスで通信可能となる。MNにおいては、MN上で動作するアプリケーションが、前記ホームアドレスと呼ばれるIPアドレスを常に使用し通信する。
MobileIPにおいてMNとの通信には、実際のIPv6(Internet Protocol Version 6)パケットのソースアドレス、もしくは、ディスティネーションアドレスにはCoAを用い、IPv6 over IPv6カプセル化、mobility headerなどの技術を用いて、HoAを記述する。アプリケーションにはホームアドレスを通知し、実際に用いるIPv6アドレス(CoA)を隠蔽している。その結果、前記アプリケーションは、以下のような特性を持つ。
(1)ネットワークとの接続性がある際には、ホームアドレスで常に通信が可能である。(2)通信中に、複数の異なるネットワークへのハンドオーバーが出来るようになる。すなわち、MobileIP対応端末は、複数の通信メディア(例えば、NIC:Network Interface Card)を有することが可能で、前記複数の通信メディアに跨ったハンドオーバーが可能である。MobileIPの既知の問題点として、MobileIP対応端末が複数の通信メディアを有する場合に、どの通信メディアを使用するか、すなわちCoAにどのアドレスを用いるかという問題がある。
そこで、自身に最適な通信メディアを選択するための技術として、特許文献1に開示の技術がある。この技術は、所有者の好みに基づき、現在使用可能な通信メディアから、最適な通信メディアを選択し、その通信メディアの有するIPアドレスをMobileIPの最優先気付けアドレスとして用いるものである。
特開2004−129024号公報
前記発明では端末が自身の無線強度等の状態と所有者の好みから最適な通信メディアを選択するものである。しかしながら、複数の通信メディアを有する端末同士での通信においては、ネットワークの相性などから、お互いが勝手にベストを選んだ場合がベストな解になるとは限らない。前記特許文献1においては、例えば、端末Aが2つの通信メディアを有し、端末Bが3つの通信メディアを有している場合、前記発明では端末Aが2つの自由度、端末Bが3つの自由度を持つだけであるが、実際には2×3=6のうち最も適切なものを選択する必要がある。また、アプリケーションによっては、帯域よりもその他のパラメータが重要なことも想定される。
例えば、VoIP(Voice over Internet Protocol)においては、最高レートのコーデックを用い、MobileIPv6で接続したところで、たかだかOSIの第2層の通信速度において120kbps程度あれば十分である。その結果、120kbps以上であれば、帯域よりも遅延等を優先するべきなどの嗜好が存在する。また、MobileIPでは、基本的に複数の通信メディアでのハンドオーバーには対応しているが、それらをどう上手く使うか、どう操るかは規定されていない。嗜好は各人で異なり、その結果、二つ以上の嗜好情報(相手の嗜好情報および自分の嗜好情報等)が存在する場合に不具合が起こる可能性がある。
また、通信の品質と課金問題は密接に関係するが、一方が課金を気にせずに高品質な通信を望み、他方では品質よりも課金を重要視することもある。さらに、課金には様々な形態がありえるため、双方が自分にとって最適な通信メディアを選択するだけでは解決できない問題が起こりうる。そのため、これらを実現する際に、例えば、通信端末同士が嗜好情報そのものをやり取りすることも考えられるが、これはプライバシー上の問題ともなる。また、複数のアプリケーションが存在する場合にも各アプリケーションの嗜好情報は異なり、整合性を取ることは困難である。
本発明は、上述した実情に鑑みてなされたもので、通信端末上における複数のフローは、フロー毎にユーザもしくはアプリケーションの嗜好を反映した自分と相手の通信メディアの組み合わせを選択することができ、しかも、嗜好情報を相手に知られることなく実行可能な送受信方法の提供を目的とする。
本発明による送受信方法は、通信端末Aと通信端末B間で、1以上のパスで、1以上のフローを送受信する際に、使用パスを選択する送受信方法である。
通信端末Aにおいて、アプリケーションは、通信管理部に少なくともアドレス情報及びネットワークに関する嗜好情報を含むフロー情報を渡し、通信端末Bにおいても、アプリケーションは通信管理部に少なくともアドレス情報を含むフロー情報を渡す。通信端末Aの通信管理部は、前記フロー情報に基づき通信端末Aの有する通信メディア情報を通信端末Bに送信し、通信端末Bの通信管理部は、受信した通信端末Aの有する通信メディア情報と通信端末Bの有する通信メディア情報から、パス情報を作成して通信端末Aに送信する。
通信端末A及び通信端末Bの通信管理部では、パスを使用した場合のスコアを各パスに関して計算し、通信端末Aは通信端末Bに各パスのスコアを送信し、通信端末Bにおいて合計スコアを計算して通信端末Aに対して送信し、通信端末B、通信端末Aの各々において、スコアの高いパスを選択し、そのパスに基づく通信メディアをお互いに選択する。
前記の嗜好情報は、少なくともアプリケーションで使用可能なコンテンツに対応した1以上の要求帯域情報、遅延差情報、課金情報、単位時間当たりのパケットロス率情報、無線通信メディアのセル情報等を含む。また、フローの使用するパスが決定した後に、通信管理部はアプリケーションに少なくとも数値で表されるフローに割り当てられた帯域を含むフロー情報を通知し、アプリケーションは割り当てられた帯域をもとにコンテンツを選択する。
本発明によれば、通信端末上における1以上のフローは、各フローごとにユーザもしくはアプリケーションの嗜好を反映したパス、すなわち、自分と相手の通信メディアの組み合わせを選択することができる。これらは、嗜好情報を相手に知られることなく実行可能である。また、アプリケーションは、使用するパスにおいて使用可能な伝送速度に見合ったコンテンツを選択することが可能となる。
本発明は、通信端末Aと通信端末Bとの間で、1つ又は複数のパス(通信路)で、1つ又は複数のフロー(データの流れ)を送受信する際に、嗜好(プリファレンス)情報を参考にして、MobileIPにおけるCoAの組み合わせ(通信相手のCoAと自身のCoA)を選択する手段を提示するものである。具体的には、フローを考えうるパスに当てはめてスコア付けを行なう。これに際して、スコア付けは端末毎に別個に行い、そのスコアだけを送信し、スコアの和を取ることによって最適のパスを選択する。その結果、両者の嗜好情報に適したCoAの選択が行われる。これらは以下のステップを経て実現される。
例えば、通信端末A(例えば、発呼側とする)は、通信メディア情報を受信側の通信端末B(例えば、着呼側とする)に送信し、通信端末Bは、両者の通信メディア情報をマージしたパス情報を作成し、通信端末Aに返信する。通信端末Aと通信端末Bは、通信端末Aと通信端末B間の各パスにおけるネットワーク状態を把握し、通信端末Aはパスにフローの要求に対するマッチ具合をスコアリングして順位付けをし、順位およびスコアを通信端末Bに送信する。同時に通信端末Bは自身の嗜好情報によりパスに点数付けを行ない、通信端末Aから送信された順位およびスコアを加算し最適パスを選択する。選択したパスを通信端末Aに返信し、通信端末Aおよび通信端末Bは選択したパスの情報をもとにアプリケーションに最適な帯域幅を割り当てる。
(第1の実施形態)
図1〜図6により、第1の実施形態について説明する。そのシステム構成例の模式図を図1、シーケンス図を図2に示す。この第1の実施形態は、互いに通信する端末10と端末11が存在し、端末10及び端末11に実装された通信管理部14,15とVoIP(Voice over Internet Protocol)アプリケーション12,13から構成される。また、一方の端末10は、通信メディアNIC100でインターネットと接続しており、他方の端末11は、通信メディアNIC110及び通信メディアNIC111でインターネットに接続しているものとする。
現在、VoIPで使われる呼制御プロトコルは、SIP(Session Initiation Protocol)が多い。SIPを用いる場合には、SDP(Session Description Protocol)の受信が完了するまで相手端末とのフローの情報は確定しない。呼制御すなわちSDPの送受信がお互いに完了しフローの情報が確定したら、VoIPアプリケーション12は、フローの情報を通信管理部14に渡す。また、本実施形態においては、例えば、SDPの最低帯域幅(8kbps)で通信を開始するものとする。フロー情報(図3(A))は、少なくともディスティネーションアドレス(Dst Addr)、ソースアドレス(Src Addr)、ディスティネーションポート(Dst Port)、最低限必要な帯域幅BW(min)、最高クオリティに必要な帯域幅BW(max)を含んでいる。
ここでのディスティネーション及びソースアドレスは、MobileIP対応端末ではMobileIPでのホームアドレスとなっている。その他の第三層の移動プロトコルを利用する場合には、各プロトコルにおける端末識別子となるアドレスを用いる。また、同時に端末11においてもフロー情報(図3(B))は、通信管理部15に渡される。このとき、通信管理部15においてどちらがイニシエータとなるべきかを、アプリケーションから通知される。
本実施形態においては、発呼端末である端末10のVoIPアプリケーション12が、自身の通信管理部14に対してイニシエータである旨をフロー情報とともに通知する。なお、本実施形態では、VoIPアプリケーションの発呼側(端末10側)をイニシエータとしたが、VoIPアプリケーションでの着呼側(端末11側)がイニシエータとなってもよい。これらの情報をもとに端末10の通信管理部14は、通信相手端末とのパスを生成するために自身の通信メディア情報(図3(C))すなわち、通信メディアNIC100の情報を相手端末11の通信管理部15に送信する。端末11では受信した通信メディア情報と自身の通信メディア情報からパス情報(図3(D))を作成し端末10に送信する。ここで、パスは上りと下りを別なパスと認識してもよいし、上りと下りを同じパスとしてもよい。本実施形態においては、上りと下りは別なパスとしている。また、パス情報には、お互いの通信メディアの情報(図3(E))も含まれているものとする。
次に、このパス情報中の足りないデータ(例えば、図3(D)の帯域幅BW(測定))を埋めるためにネットワーク状況を調査する。この調査は、例えば、データベースにおいて様々なネットーク状況を蓄えていて、前記データベースからネットワークの情報を取得しても良いし、END−ENDで計測してネットワーク情報を取得しても良いし、その他の手法を用いても問題ない。本実施形態では、END−ENDで計測するものとする。パス情報を得た端末10は、ネットワーク情報を得るために、端末11との間でネットワーク状態を測定する。こうして、パス情報中の使用可能な帯域幅BWが埋まる(図4)。
その結果、端末11側の通信メディアNIC110を用いるのがよいか、通信メディアNIC111を用いた方がいいのかを決定するのが可能となる。本実施形態の場合、端末11→端末10のフローにおいては、測定した帯域の広いほうが有利であると単純に考えれば端末11の通信メディアNIC111を用いた方が好都合だが、端末10→端末11のフローにおいては、通信メディアNIC110を用いた方が好都合である。しかしながら、MoileIPにおいて上下で通信パスを変えることは想定されておらず、どちらを用いるか決定しなくてならない。この判断を下すために以下の方法を用いる。
先ず、各パスを用いた際のフローに割り当てられる帯域幅を知る必要が有る。これには、種々の方法が考えられる。実施形態では、フロー毎に割り与えられた帯域は既知のものとする。フローがパスに割り当てられた際に割り振られる帯域の一例を図5(A),図5(B)に示す。なお、図5(A)は端末10側で、図5(B)は端末11側で所有するものとする。
ここで、端末10の通信管理部14ではVoIPアプリケーション12の嗜好情報に基づき、BW(64kbps)が割り振られているパスには100点、BW(8kbps)が割り振られたパスには90点、Minを満たせないパスには0点とスコアリングを行う。本実施形態においては、パス1、パス2ともに100点と評価される。この結果を端末10の通信管理部14は端末11の通信管理部15に送信する(図6(A))。
また、端末11側でも同様にスコア付けを行う(図6(B))。図6(A)を受け取った端末11では、パス情報の通信メディア組み合わせからパス1とパス3はセットで、同様にパス2とパス4はセットであることを認識する。その結果、パス1とパス3のスコアは200点で、パス2とパス4のスコアが190点と評価される。この結果パス1とパス3を用いるものと判定し、その結果を端末10に送信する。
また、これらの選択されたパスに基づき、各々の通信管理部14,15は、フローに割り当てられた帯域を各アプリケーションに送信する。その結果、端末10のVoIPアプリケーション12ではそれに応じてSIP/SDPでコーデック変更の旨を相手端末11のVoIPアプリケーション13に伝える。端末11のVoIPアプリケーション13ではそれに応じてSIP/SDPでコーデック変更の旨を相手端末10のVoIPアプリケーション12に伝える。その結果、通信パスに適切な帯域での通信がなされる。また、パスが選択された結果、端末11ではIP110をPrimaryCoAとして端末10にバインディングアップデートを行う。この結果、選択されたパスを利用することが実現される。
(第2の実施形態)
図7〜図20により第2の実施形態について説明する。その構成例の模式図を図7、シーケンス図を図8に示す。この第2の実施形態は、TV電話の例で、第1の実施形態に比べてフローが増えていること、嗜好情報に用いるパラメータが帯域、遅延差、コスト、ネットワーク安定度、モビリティ性と増えていることが異なる。これらを図9(A),図9(B)に示す。ここで、図9(A)は端末10で、図9(B)は端末11で渡されるフロー情報である。このフロー情報を主に図9(A)に沿って説明する。
図9(A)は端末10側で渡されるため、端末11→端末10方向のフローに主な嗜好情報が含まれている。この嗜好情報は、TV電話アプリケーション16,17で作成するものとする。また、本嗜好情報は一例であり、本発明では、この嗜好情報を可変とする。先ず、フロー10−1に注目する。帯域BW1が75kがMustとなっていることが分かる。これは、音声75kbpsによる通信は必須であることを意味している。また、帯域BW2が130kに「*5」とあるのは、「5」は重みであり、後に説明する採点に5倍の重みをつけることを意味する。帯域BWに関しては、本アプリケーションは、2段階の音声コーデックをサポートしているので、第三番目の帯域は空欄となっている。
次にDelay差のMinは、小さければ小さい程よいことを示している。また同様に「*4」は重み付けである。このフローは自身(端末10)に対して下りであるので、上りのコストは空欄となる。次に下りのコストで、本例では「*0」すなわち考慮しないことを意味している。また、安定性とモビリティに関してはどちらも高いほど良いが、重みは「*1」で、さほど重要視されていないことを示している。次にフロー10−2をみる。先ず、帯域BW1を見ると、0kとある。これは、「0kbps」すなわち本フロー無しを許容することを意味している。同様に帯域BW2は、100kが「*3」で、帯域BW3は、500kが「*2」となっている。
コスト下りが安くければ安いほどよく、「*3」となっている。安定性・モビリティはフロー10−1と同様である。次にフロー11−1であるが、フロー11−1,11−2は上りフローであるため、上りのコストだけを考慮する。これは声の品質や画像の大きさなどに好みがあるのは受信者であって、送信者側ではないからである。
また、コスト上りだけは自身にかかってくる問題なので、ここだけは考慮することとする。通常の電話システムでは発信者課金となるが、パケット通信では受信者にも課金される。同様に端末11側でも同様に図9(B)の嗜好情報が渡される。これら嗜好情報を含むフロー情報が渡された端末11の通信管理部15は、フロー情報から判明する端末10のIPアドレスを頼りに端末10の通信管理部14宛に通信メディア情報を送信する。このとき、通信メディア情報としてコスト(上り・下りともに)は送信しないものとする。端末10は、送信された通信メディア情報と自身の有する通信メディア情報からパス情報を作成し、端末11の通信管理部15に送信する。その後、双方の端末間において使用可能帯域を測定する。
以上のシーケンスから得られるパス情報を図10(A),図10(B)に示す。図10(A)は端末10で、図10(B)は端末11で渡されるパス情報である。ここで、相手通信メディアのコスト情報は分からなく、あくまでも自身のコスト状態とコストに関する嗜好情報で決定することとなる。各々の端末では、あるパスを利用した際のフローの使用可能帯域を計算する。図11は、得られた結果の一例を示し、その結果を受けて、パスにスコアを付ける。
このスコア付けの際に、例えば、以下のような値を用いる。帯域BWに関しては、条件を満足している場合は100点、条件を満足していない場合は70点とする。遅延差に関しては、最低値の場合を100点、10ms増毎に2点減点、0点未満は0点とする。コストに関しては、定額性のものは100点、それ以外はコスト値が1増加する毎に1減点を行なう。安定性に関しては、A評価のものは100点で、B評価は90点、以下80、70・・・とする。モビリティも同様に、A評価のものは100点で、B評価は90点、以下80、70・・・とする。本スコアリングは一例であって、例えば一般的に遅延は短ければ短いほど良いが、「遅延は普通のものより300ms程度遅い方がよい」等といった嗜好情報にも対応できるように、嗜好情報の与えられ方でスコアリング方法を変えられるようにする。
具体的には、条件満足/最大希望/最小希望/希望値希望等の条件と重み付けを通信管理部に渡す。また、スコアリング方法は予め公開しておきアプリケーション作成者が最適な重み付けを行なうことができるようにすることが望ましい。本実施例形態は、前記のスコアリングを行なうものとし、そのスコアリングを図12,図13に記す。図12は端末10側で、図13は端末11側で計算される値とする。端末10は、計算したスコア結果(図14(A))を端末11の通信管理部15に送信する。端末11の通信管理部15では自身の結果(図14(B))を加え、図14(C)のような結果を得る。
その結果、高質な画像伝送が可能な「パス1+パス3」よりもコストが優先されて「パス2+パス4」が選択され、端末11の通信管理部15は、端末10の通信管理部14に送信する。また、これらの結果から、端末11ではIP111をCoAとして利用することとなり、通信管理部15は、MobileIP管理部に通知し、MobileIP管理部はIP111を利用することをバインディングアップデートで端末10に通知する。また、各端末における通信管理部14,15では、選択パスで利用可能な帯域などのフロー情報をTV電話アプリケーション16,17に送信する。その結果、TV電話アプリケーション16,17では、与えられた帯域に応じてコーデック変更のオファーをSIP/SDP等の既存の技術を用いてお互いに行なう。
また、本実施形態で異なったスコア付けをする例について説明する。ここで、例えば、変更点としては、帯域BWに関して、上述した「条件を満足している場合100点、条件を満足していない場合70点」とするのを「条件を満足している場合100点、条件を満足していない場合0点」に変えるだけとする。この場合、図15,図16のような結果となり、図17(A)のようなパス優先順位が端末10で得られ、端末11の通信管理部15に送信する。端末11の通信管理部15では自身の結果(図17(B))を加え、図17(C)のような結果を得る。その結果、「パス1+パス3」が選択され、端末11の通信管理部15は、端末10の通信管理部14に送信する。
これらの結果から、端末11ではIP110をCoAとして利用することとなり、通信管理部15は、MobileIP管理部に通知する。MobileIP管理部はDefaultでのCoAがIP110で、IP110をCoAとして既に利用している(既にIP110を端末10にバインディングしている)ので、バインディングアップデートは行なわない。また、各端末における通信管理部14,15では、選択パスで利用可能な帯域などのフロー情報をTV電話アプリケーション16、17に送信する。その結果、TV電話アプリケーション16、17では、与えられた帯域に応じてコーデック変更のオファーをSIP/SDP等の既存の技術を用いてお互いに行なう。この結果は、コストよりも両方が動画像を見れるパスが選択されたこととなる。
また、本実施形態で異なった嗜好情報を渡す例について説明する。ここで、TV電話アプリケーション16、17が通信管理部14,15に渡す嗜好情報を変更する。スコアリングは、上述(前者)したものを利用し、変更するのは端末11側だけとして、その内容を図18に示す。変更点は1点だけで、フロー10−2に関する上りコストを5倍→2倍に変更しただけである。その結果、端末11でもつパス情報は、図19のようになる。端末10でもつスコア情報は図20(A)で、これは(フロー情報が変わらないので)図17(A)と同じものを得る。端末11では、フロー情報、すなわち、嗜好情報が異なるためスコアが変わり、図20(B)のスコア情報を得る。この結果、合計のスコア情報は図20(C)となり、「パス1+パス3」が選択される。
以上のようにスコアリングによって挙動が変わる。そのため、本実施形態においては、通信管理部14,15におけるスコアリングを公開し、TV電話アプリケーション16,17側で効果的な嗜好情報を実現できるようにするのが望ましい。また、各端末が好き勝手に嗜好情報を設定すると、嗜好情報での倍率を高く取った端末の嗜好情報が有利となってしまう。それらを踏まえ、倍率の数字の合計を決めておくことが有効となる。例えば嗜好情報で渡す倍率の合計は、「20」にする等といった方法である。以下の実施形態では、これを含めたもので説明する。
(第3の実施形態)
図21〜図26により第3の実施形態について説明する。その構成例の模式図を図21、シーケンス図を図22に示す。この第3の実施形態は、TV電話の例で、第2の実施形態に比べて双方の端末でそれぞれが2つの通信メディアを有している点、及び他のスコアリング方法を用いる点が異なる。
先ず、端末10は端末11に対して、SIP/SDP INVITEを行なう。端末11は、SIP/SDP 200−OKを返す。このとき、INVITEにおいては、SIP呼のBODYである、SDP内にてTV電話である旨を伝える。また、200−OKの中のSDP内では、音声のみの最低帯域の利用であることを返す。これらの送受信から、最初は音声のみの通信から始まる。各端末10,11のTV電話アプリケーション16、17は、これらSIP/SDPパケットからフロー情報(嗜好情報を含む)を作成し、通信管理部14,15に伝える。
この嗜好情報を、端末10では図23(A),端末11では図23(B)に示す。また、各端末においては自身が有する通信メディア情報として、端末10では図24(A),端末11では図24(B)をそれぞれの通信管理部14,15において保有している。フロー情報が渡された、端末10の通信管理部14では自身の通信メディア情報のうちコスト情報を除いたものを通信相手の端末11の通信管理部15に送信する。その通信メディア情報を受け取った端末11の通信管理部15では、パス情報を作成し端末10に送信する。
このパス情報には、端末11の通信メディア情報(コスト情報除く)も含まれている。その結果、端末10においては、図25(A)+図25(B)、端末11においては、図25(A)+図25(C)を保有することとなる。これで、パス情報とフロー情報を通信管理部14,15は把握することが可能となる。この実施形態では、フローに帯域を割り当てずにパス情報だけで評価する例で説明する。
スコアリングルールは、帯域BWに関しては、同一方向で最大のものを100点、次点のものを95点・・・以下、順位が一つ落ちる毎に5点ずつ、点が下がるものとする。遅延差に関しては、同一方向で最小のものを100点、次点のものを95点・・・以下、順位が1つ落ちる毎に5点ずつ、点が下がるものとする。コストに関しては、無料(定額制)のものは100点で、従量制のものは1単位に付き2点減点するものとする。
この例では、フローに帯域BWは割り当てられないので、フローの要求する最大帯域・最小帯域(図23(A),図23(B)中のBW1,2,3)はそれぞれを合計したものを倍率とする。例えば、図23(A)中のフロー10−1であれば、2+5=7倍で、フロー10−2においては、4+2=6倍とする。これらを踏まえて、各パスに採点を行なうと、端末10での結果は図26(A)のようになり、端末11での結果は図26(B)のようになる。これらのスコアの合計から、「パス3+パス7」を利用することが好ましいことがわかり、端末10及び、端末11において、それらのパスを利用することを選択する。
(第4の実施形態)
図27〜図39により第4の実施形態について説明する。その構成例の模式図を図27に示す。この第4の実施形態は、動画ストリーミングを見ながら、TV電話をする例である。例えば、サッカーをIPネットワークストリーミングで視聴しながら、TV電話をする例で説明する。
先ず、端末10では、例えば、ユーザによるアクションで、サッカーの動画の受信を開始する。このとき、アプリケーション層における呼制御が行なわれ、例えば、RTSP(Real Time Streaming Protocol)等を用いて、サーバ端末22の動画ストリーミングサーバでのエンコード可能なコーデックと、受信端末である端末10側でデコード可能なコーデックのネゴシエーションをとる。RTSPではDESCRIBEというメソッドを用いて、サーバ端末22の使用可能なコーデックを得る。その後、SETUPというメソッドを用いて使用コーデックおよび再生場所の指定を、サーバ端末22に対して端末10が連絡し、PLAYというメソッドを端末10がサーバ端末22に送ることでストリーミングを開始する。
本実施形態は、DESCRIBEメソッドに対する応答を得た後に、端末10はその情報をフロー情報として通信管理部14に通知する。この結果、使用可能なコーデック情報の考慮がなされたフロー情報が、端末10及びサーバ端末22において、アプリケーションから通信管理部に渡される。ストリーミングの例で特異なことは、端末10側では下りのみのフローで、サーバ端末22側では上りフローのみとなることである。端末10側で渡されるフロー情報を図29に示す。また、この実施形態では、説明を簡単にするためにコストは考慮しないものとする。
端末10側の通信管理部14ではフロー情報を得た後、通信メディア情報(図30)をサーバ端末22に送信する。サーバ端末22側の通信管理部では受け取った通信メディア情報を元にパス情報を作成する。本実施形態においては、サーバ端末22は、1つの通信メディアしか有していないし、サーバ端末22から端末10方向へのフローしかないので、パスは通信カード数と同じ2つとなる。このパス情報を図31に示す。この後、個々のフローに使用可能な帯域を割り当てる。
その結果、パス1を用いた場合は、フロー10−1が120kbpsのコーデックで、フロー10−2が1Mのコーデックとなる。同様にパス2を用いた場合は、フロー10−1が120kbpsのコーデックで、フロー10−2が6Mのコーデックとなる。この結果、パス2の方がスコアが高くなり、パス2を用いることを選択し、RTSPのSETUPメソッドを用いてサーバ端末22にそのコーデックを連絡し、PLAYメソッドで動画ストリーミングを開始する。
次に、この状態の端末10に、他の端末11のユーザがTV電話をかける。この時、端末10側で渡されるTV電話に関するフロー情報を図32(A)に示す。また、端末11側で渡されるTV電話に関するフロー情報を図32(B)に示す。この図の一番の違いは、端末側10側ではTV電話の画質は重視せず(TV電話の画像に関しては見れれば良いというユーザの嗜好)、端末11側では、TV電話の最高画質を重視(TV電話を綺麗に見たいという嗜好、相手の顔の画像を鮮明に見たい願望)することである。結果として、端末10側で有する(下りの)フロー情報は、図32(C)に示すように4つとなる。ここで、図32(C)において、各フローに優先度が設定されているものとする。
この優先度は、予めフローに対する優先度を決めておいてもよいし、フローの優先順位を選択する図28に示すようなUI(user interface)のようなタブ画面を用い、フローを増減する際に、その都度、設定するようにしても良い。いずれにしても、各フローに優先度がつき、そのフロー情報は通信管理部14で管理される。その結果、端末10では、サーバ端末22との通信のためのパス以外に、端末11とのパスも作成するため、端末11に通信メディア情報を送信する。端末11の通信管理部15では得た通信メディア情報を元に端末11とのパスを作成する。端末11の通信管理部15では、作成したパス情報を端末10に送信する。このパス情報を図33に、パス情報に含まれる通信メディア情報を図34に示す。
端末10では、動画ストリーミングフロー(図29)に対するパス1,2(図31)とTV電話フロー(図32(A))に対するパス3〜8(図33、34)が存在する。また、それに対して端末11側では、現在はTV電話フロー(図32(B))に対して、パス3〜8の情報を所有している。また、このとき、パス3とパス7、パス4とパス8、パス5とパス9、パス6とパス10が表裏一体であると共に、「パス3+パス7」もしくは「パス4+パス8」を選択した場合には、通信メディアNIC100を利用するので、動画ストリーミングにはパス1を選択することになることが解かる。
逆に「パス5+パス9」、「パス6+パス10」を選択した場合には、動画ストリーミングに対してパス2を選択する必要があることが解かる。ここで、各パスを選択した場合の、各フローへの帯域を割り振る。各フローへの帯域の割り振りは、例えば、第1の方法としては、そのパスを利用した際は、END−ENDの計測によって得られたパスの帯域をフローの数で割った帯域を、フローに割り当てられた帯域として割り当てる方法が考えられる。また、第2の方法としてはそのパスを利用した際は、END−ENDの計測によって取得されたパスの帯域を、フローの優先度の高いものから順に半分の権利を持つようにする方法も考えられる。つまり、第2の方法では、優先度の低いフローは、より優先度の高いフローの半分の帯域しか得る権利を持っていないこととなる。
割り振られた帯域の例を図35に示す。ここで、フロー11−1、11−2に関しては、上りフローなので端末10側では帯域の割り振りは行なわない。また、端末10では割り振られた帯域をもとに、各パスのスコアリングを行なう。この場合、本実施形態では、フロー情報中の帯域を満たした場合は100点、満たさなかった場合は90点、遅延差Xに関しては遅延差量が0≦X<50の場合は100点、50≦X<100の場合は90点、100<Xの場合は80点としている。
本実施形態において、このスコアリングルールには大きな意味は無く、重み付け(前記スコアに対する倍率)を行なうことには意味がある。この重み付けは、TV電話アプリケーション16から通信管理部14に渡されるデータとなっている部分が重要という意味である。その結果、例えば、図36に示すような合計スコアが算出される。
端末10側では、通信メディアNIC100を、端末11側では通信メディアNIC111を用いることが、端末10のユーザにとって望ましいことを意味している。一方、端末11側でもスコア計算を行なっている。端末11側では図32(B)のようなフロー情報を有していて、帯域が一定のアルゴリズムに基づきフローに帯域が割り当てられ、結果として、図38に示すような合計スコアが得られる。また、端末10側では、例えば、得られた合計スコアを、満点の2900点を100点とした点数(比例計算)に置き換えたものを端末11に送信するようにしてもよい。
また、この際、端末11側でも、満点の1500点を100点(比例計算)したスコアを端末10に送信するようにしてもよい。お互いにスコアを送信し、合計値と使用パスもお互いに送信する。送信した合計スコアと受信した合計スコア(図39)が一致することを確認し、端末10側では通信メディアとしてNIC101を、端末11側では通信メディアとしてNIC111を利用することが好ましいことがわかる。端末10ではサーバ端末22とも通信しているため、端末10と端末11とのやりとりと、ほぼ同じことを行なう。但し、フローが片方向のため、自身の下りのみを考慮したときと同じ結果となるため、上述の結果と同じく、通信メディアNIC101を利用することが好ましい。
端末10では通信メディアNIC101に付いているCoAを端末11、サーバ端末22、HAに対してバインディングアップデートし、使用通信メディアとなることを通知する。また、端末11では通信メディアNIC111に付いているCoAを端末10、HAに対してバインディングアップデートし、使用通信メディアとなることを通知する。
これらの結果、アプリケーションに適した通信メディアを選択することが可能となり、また、アプリケーションは帯域に適したコンテンツを選択することが可能となる。
上述した、本発明による送受信方法は、通信端末に搭載されたコンピュータによって実行される。このため、各種アプリケーションと通信管理部間におけるデータの送受、及び各種通信メディアを通じての通信端末間の送受信を実行する手順を示したプログラムが用いられる。また、本発明による送受信を、コンピュータに実行させるための前記プログラムを記録したコンピュータ読み取り可能な記録媒体を用いて実施することができる。
本発明の第1の実施形態を説明するシステム構成例の模式図である。 図1のシーケンス図である。 (A),(B)はフロー情報、(C),(E)は通信メディア情報、(D)はパス情報の例を示す図である。 パス情報の使用帯域の例を示す図である。 割り当てられた帯域の例を示す図である。 スコア表の例を示す図である。 本発明の第2の実施形態を説明するシステム構成例の模式図である。 図7のシーケンス図である。 フロー情報の例を示す図である。 (A),(C)はパス情報、(B),(D)は通信メディア情報の例を示す図である。 フローの割り当て帯域の例を示す図である。 スコア計算表の例を示す図である。 スコア計算表の例を示す図である。 優先順位表の例を示す図である。 スコア計算表の例を示す図である。 スコア計算表の例を示す図である。 スコア情報と優先順位表の例を示す図である。 フロー情報の例を示す図である。 スコア計算表の例を示す図である。 スコア情報と優先順位表の例を示す図である。 本発明の第3の実施形態を説明するシステム構成例の模式図である。 図21のシーケンス図である。 フロー情報の例を示す図である。 通信メディア情報の例を示す図である。 (A)はパス情報、(B),(C)は通信メディア情報の例を示す図である。 パスのスコア表の例を示す図である。 本発明の第4の実施形態を説明するシステム構成例の模式図である。 フローの優先順位を選択するUI画面の例を示す図である。 フロー情報の例を示す図である。 通信メディア情報の例を示す図である。 パス情報例を示す図である。 フロー情報の例を示す図である。 パス情報例を示す図である。 通信メディア情報の例を示す図である。 フロー割り当てられた帯域の例を示す図である。 スコア計算表の例を示す図である。 フロー割り当てられた帯域の例を示す図である。 スコア計算表の例を示す図である。 合計スコアの例を説明する図である。
符号の説明
10,11…端末、12,13…VoIPアプリケーション、14,15…通信管理部、16,17…TV電話アプリケーション、22…サーバ端末。

Claims (15)

  1. 通信端末Aと通信端末B間で、1以上のパスで、1以上のフローを送受信する際に、フローとパスの組み合わせを選択する送受信方法であって、
    前記通信端末Aにおいて、アプリケーションは通信管理部に少なくともアドレス情報及びネットワークに関する嗜好情報を含むフロー情報を渡し、
    前記通信端末Bにおいても、アプリケーションは通信管理部に少なくともアドレス情報を含むフロー情報を渡し、
    前記通信端末Aの通信管理部は、前記フロー情報に基づき前記通信端末Aの有する通信メディア情報を前記通信端末Bに送信し、
    前記通信端末Bの通信管理部は、受信した通信端末Aの有する通信メディア情報と前記通信端末Bの有する通信メディア情報から、パス情報を作成して前記通信端末Aに送信し、
    前記通信端末A及び前記通信端末Bの通信管理部では、パスを使用した場合のスコアを各パスに関して計算し、前記通信端末Aは前記通信端末Bに各パスのスコアを送信し、
    前記通信端末Bにおいて合計スコアを計算して前記通信端末Aに対して送信し、前記通信端末B、前記通信端末Aの各々において、前記スコアの高いパスを選択し、そのパスに基づく通信メディアをお互いに選択することを特徴とする送受信方法。
  2. 前記嗜好情報は、アプリケーションで使用可能なコンテンツに対応した1以上の要求帯域情報を含むことを特徴とする請求項1に記載の送受信方法。
  3. 前記要求帯域情報は、数値で表現される1以上の要求帯域情報と、その各々に対応する数値で表現される嗜好レベルと、を含むことを特徴とする請求項2に記載の送受信方法。
  4. 前記嗜好情報は、遅延差情報を含むことを特徴とする請求項1に記載の送受信方法。
  5. 前記遅延差情報は、数値で表現される嗜好レベルを含むことを特徴とする請求項4に記載の送受信方法。
  6. 前記嗜好情報は、課金情報を含むことを特徴とする請求項1に記載の送受信方法。
  7. 前記課金情報は、数値で表現される嗜好レベルを含むことを特徴とする請求項6に記載の送受信方法。
  8. 前記課金情報は、上りと下りに関して別に嗜好レベルを持つことを特徴とする請求項7に記載の送受信方法。
  9. 前記嗜好情報は、単位時間当たりのパケットロス率情報を含むことを特徴とする請求項1に記載の送受信方法。
  10. 前記パケットロス率情報は、数値で表現される嗜好レベルを含むことを特徴とする請求項9に記載の送受信方法。
  11. 前記嗜好情報は、無線通信メディアのセル情報を含むことを特徴とする請求項1に記載の送受信方法。
  12. 前記無線通信メディアのセル情報は、数値で表現される嗜好レベルを含むことを特徴とする請求項11に記載の送受信方法。
  13. フローの使用するパスが決定した後に、通信管理部はアプリケーションに少なくとも数値で表されるフローに割り当てられた帯域を含むフロー情報を通知し、アプリケーションは前記割り当てられた帯域をもとにコンテンツを選択することを特徴とする請求項1〜12のいずれか1項に記載の送受信方法。
  14. 請求項1〜13のいずれか1項に記載の送受信方法を、コンピュータにより実行させるためのアプリケーションプログラム。
  15. 請求項14に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
JP2005168277A 2005-06-08 2005-06-08 送受信方法およびプログラム並びに記録媒体 Pending JP2006345174A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005168277A JP2006345174A (ja) 2005-06-08 2005-06-08 送受信方法およびプログラム並びに記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005168277A JP2006345174A (ja) 2005-06-08 2005-06-08 送受信方法およびプログラム並びに記録媒体

Publications (1)

Publication Number Publication Date
JP2006345174A true JP2006345174A (ja) 2006-12-21

Family

ID=37641805

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005168277A Pending JP2006345174A (ja) 2005-06-08 2005-06-08 送受信方法およびプログラム並びに記録媒体

Country Status (1)

Country Link
JP (1) JP2006345174A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011524684A (ja) * 2008-06-09 2011-09-01 クゥアルコム・インコーポレイテッド ネットワーク制御されたモバイルipフロー動作のための方法および装置
JP2013219766A (ja) * 2012-04-06 2013-10-24 Kotatsu Kokusai Denshi Kofun Yugenkoshi 無線データネットワーク切替方法及び電子装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011524684A (ja) * 2008-06-09 2011-09-01 クゥアルコム・インコーポレイテッド ネットワーク制御されたモバイルipフロー動作のための方法および装置
JP2013219766A (ja) * 2012-04-06 2013-10-24 Kotatsu Kokusai Denshi Kofun Yugenkoshi 無線データネットワーク切替方法及び電子装置
US9445370B2 (en) 2012-04-06 2016-09-13 Htc Corporation Wireless data network switching method and electronic device thereof

Similar Documents

Publication Publication Date Title
JP4100182B2 (ja) 通信端末装置及びその制御方法
AU2005222356B2 (en) Method in a communication system to allocate resources
US8229087B2 (en) Relay apparatus, relay method, relay program, and communication system
JP4594771B2 (ja) ネットワークQoS制御システムおよび制御方法
CN102365850B (zh) 用于提供相关服务级别的方法和装置
MX2007013843A (es) Senalizacion de parametros de calidad de servicio para sesion multimedia.
JP2005527133A (ja) マルチストリーム及びマルチメディアアプリケーションのためのQoSサポートを目的としたエンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル
JP2010200359A (ja) 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム
JP2009522959A (ja) Qos資源を解放することによってネットワーク容量を保存する方法と装置
JP4801069B2 (ja) 異種環境での透過的なサービス適合
CN102301659A (zh) 通信系统和方法
CN105049402B (zh) 用于数据的传输和适配的方法和设备、计算机可读介质
WO2007022440A2 (en) Resource selection in a communication network
JP3819019B1 (ja) 送受信方法およびプログラム並びに記録媒体
Vidales et al. Mobisense testbed: Merging user perception and network performance
JP3766087B2 (ja) 符号化方式選択方法及び端末装置
JP2006345174A (ja) 送受信方法およびプログラム並びに記録媒体
JP4574558B2 (ja) 通信品質変更システム、通信品質変更方法および通信品質変更プログラム
Hartenstein et al. High quality mobile communication
Pichon et al. Adaptation of multimedia flows in a seamless mobility context using overlay networks
JP4578414B2 (ja) 階層符号化マルチキャスト通信システム
Escobar et al. Convivo communicator: An interface‐adaptive VoIP system for poor quality networks
Venâncio Neto et al. Context-aware session and network control in future internet
Chang et al. Integrated multi-layer registration combining SIP with mobile IP schemes
Dutt Seamless mobility across next generation heterogeneous network

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20060919

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070822

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090916

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090929

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100216