(57)【要約】【課題】  ＶＯＤデータの処理速度を向上させた携帯用端末機のＶＯＤサービス方法を提供する。【解決手段】  一般的な端末の制御を実行するＭＳＭに具備された携帯用端末機のＶＯＤデータ処理方法であって、ＭＳＭを通じてＷＡＰに接続する際に、サーバーとの通信のためのＰＰＰ交渉を実行してＰＰＰオプション情報を交渉する過程と、ＭＳＭを通じて交渉されたＰＰＰオプション情報をマルチメディア処理部に伝送する過程と、伝送されたＰＰＰオプション情報をマルチメディア処理部のＰＰＰ情報として使用してＶＯＤデータ経路を設定する過程と、設定されたＶＯＤデータ経路によってＭＳＭに受信されるＶＯＤデータの中でＲＬＰフレームまで処理した後にマルチメディア処理部に伝送する過程と、マルチメディア処理部に伝送されたＶＯＤデータをマルチメディア処理部の最下位階層であるＰＰＰ階層から処理する過程からなることを特徴とする。【選択図】  図５
2005204322.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアデータを処理するマルチメディア処理部と、一般的な端末の制御を実行するＭＳＭと、が具備された携帯用端末機のＶＯＤデータ処理方法であって、
ＭＳＭを通じてＷＡＰに接続する際に、サーバーとの通信のためのＰＰＰ交渉(nego)を実行してＰＰＰオプション情報を交渉する過程と、
前記ＭＳＭを通じて交渉されたＰＰＰオプション情報をマルチメディア処理部に伝送する過程と、
前記伝送されたＰＰＰオプション情報を前記マルチメディア処理部のＰＰＰ情報として使用してＶＯＤデータ経路を設定する過程と、
前記設定されたＶＯＤデータ経路によって前記ＭＳＭに受信されるＶＯＤデータの中でＲＬＰフレームまで処理した後に前記マルチメディア処理部に伝送する過程と、
前記マルチメディア処理部に伝送されたＶＯＤデータを前記マルチメディア処理部の最下位階層であるＰＰＰ階層から処理する過程からなることを特徴とする携帯用端末機のＶＯＤデータ処理方法。
【請求項２】
前記ＰＰＰオプション情報は、ＭＳＭがＶＯＤサービスを開始するという信号を伝送する際に、その伝送された信号の応答としてＶＯＤサービスが可能という信号を伝送すれば、マルチメディア処理部に伝送されることを特徴とする請求項１記載の携帯用端末機のＶＯＤデータ処理方法。
【請求項３】
携帯用端末機であって、
前記携帯用端末機の送信及び受信機能を実行する高周波部と、
送信される信号を符号化及び変調する送信機と、受信される信号を復調及び復号化する受信機と、を備えたデータ処理部と、
前記データ処理部から出力される受信オーディオ信号を再生し、マイクから発生される送信オーディオ信号を前記データ処理部に伝送するオーディオ処理部と、
数字及び文字情報を入力するためのキーと多様な機能設定のための機能キーと、を備えたキーパッドと、
プログラムメモリーと、データメモリーと、を備えたメモリーと、
無線網を通じて受信されるＶＯＤデータを処理し、ＭＳＭからＷＡＰ接続のときに交渉されたＰＰＰオプション情報を受信してそれによってＰＰＰオプション情報をマルチメディア処理部のＰＰＰ情報として使用するマルチメディア処理部と、を含むことを特徴とする携帯用端末機。
【請求項４】
前記ＰＰＰオプション情報を前記マルチメディア処理部のＰＰＰ情報として使用することにおいて、前記マルチメディア処理部は、前記ＭＳＭのＲＬＰプロトコルで処理されたＶＯＤデータを処理するための上位階層を形成することを特徴とする請求項３記載の携帯用端末機。
【請求項５】
ＶＯＤをサービスするときに無線網を通じて受信されるＶＯＤデータを処理するための携帯用端末機のマルチメディア処理部であって、
前記マルチメディア処理部は、ＭＳＭでＷＡＰ接続を実行する際に前記ＭＳＭにより交渉されたＰＰＰオプション情報を受信し、受信したＰＰＰオプション情報を前記マルチメディア処理部のＰＰＰ情報として使用し、前記ＶＯＤデータを処理するためのＩＰ、ＴＣＰ/ＵＤＰ、Ｓｏｃｋｅｔ及びＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層を含む上位階層を形成し、各階層による前記ＶＯＤデータのカプセル解除処理を実行するようにプログラムされることを特徴とするマルチメディア処理部。
【請求項６】
前記マルチメディア処理部は、前記ＭＳＭから受信されたＶＯＤデータによる送信データを上位プロトコルから下位プロトコルまでカプセル化して前記ＭＳＭに前記送信データを伝送するようにさらにプログラムされることを特徴とする請求項５記載のマルチメディア処理部。
【請求項７】
前記マルチメディア処理部は、ＰＰＰ階層を最下位階層としてその次にＩＰ階層、ＴＣＰ/ＵＤＰ階層とＳｏｃｋｅｔ階層及びＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層が連続的に積層されたプロトコルステックを使用して動作することを特徴とする請求項５記載のマルチメディア処理部。
【請求項８】
前記ＭＳＭは、最下位階層である物理的階層、ＲＬＰ階層、ＰＰＰ階層、ＩＰ階層、ＴＣＰ/ＵＤＰ階層、Ｓｏｃｋｅｔ階層及び最上位階層であるＷＡＰ階層を含むプロトコルステックを使用して動作可能であり、前記ＭＳＭは、受信されたデータを各階層によってカプセル解除して前記ＷＡＰ階層を介して応用プログラムに伝送し、ＰＰＰ階層のＰＰＰオプション情報をマルチメディア処理部に伝送してマルチメディア処理部で前記ＰＰＰオプション情報を受信してマルチメディア処理部のＰＰＰオプション情報として用いるようにし、それによって、前記ＭＳＭを通じて受信されるＶＯＤデータは、ＭＳＭによりＲＬＰ階層までだけ処理され、前記ＰＰＰ階層から最上位階層までは、前記マルチメディア処理部により処理されるように構成することを特徴とする請求項７記載のマルチメディア処理部。
【請求項９】
携帯用端末機でＶＯＤデータを処理するために使われるＭＳＭであって、
前記ＭＳＭは、使用者がＶＯＤサーバー接続を要請する際には、設定されたＰＰＰオプション情報及びＩＰ、ＴＣＰ/ＵＤＰ及びＳｏｃｋｅｔにより構成されたグループから選択された上位プロトコルに関する情報を伝送することにより、前記携帯用端末機を制御するように構成され、ＷＡＰに接続する際には、ＰＰＰ交渉を実行して設定されたＰＰＰオプション情報と、前記ＷＡＰ接続により形成された上位プロトコルに関する情報と、を前記マルチメディア処理部に伝送可能に構成されることを特徴とするＭＳＭ。
【請求項１０】
前記ＭＳＭは、前記マルチメディア処理部が受信されたＶＯＤデータによって出力する送信データを受信して前記ＶＯＤサーバー側に伝送することを特徴とする請求項９記載のＭＳＭ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯用端末機に関し、特に、ＶＯＤ(Video On Demand)サービスに接続した携帯用端末機のＶＯＤコンデンツ処理実行速度を改善した携帯用端末機のＶＯＤデータ処理方法に関する。
【背景技術】
【０００２】
最近、技術発展に従って携帯用端末機は基本通話機能の外に多様な付加機能を具備するようになった。前記付加機能には、カメラ機能、キャムコーダ機能、マルチメディア機能などがある。ここで、前記マルチメディア機能は、音声、文字、静止画、動画などが混合された多様な媒体のデータを再生する機能として、マルチメディア提供業者により多数のマルチメディアコンデンツ、即ち、映画やミュージックビデオのような映像データ(以下、“ＶＯＤデータ”と称する)を無線網を通じてＶＯＤサービスを受けることができるようになった。
【０００３】
ＶＯＤサービスは、マルチメディアコンデンツをストリーミング(Streaming)、即ち、リアルタイムでサービスする。この時、もう少し安定的にＶＯＤデータを処理するために携帯用端末機を全般的に制御するチップ(ＭＳＭ: Mobile Station Modem)の以外に単独のマルチメディアチップ(マルチメディア処理部)を内蔵する。
【０００４】
図１Ａ及び図１Ｂは、従来携帯用端末機のＶＯＤサービスのためのマルチメディア処理部とＭＳＭのＶＯＤプロトコルステックを示す例示図であり、図２は、従来携帯用端末機のＴＡＳＫ別にＭＳＭ占有率及び優先順位を示す例示図である。
【０００５】
図１Ａを参照すれば、ＭＳＭのプロトコルステックとして、最下位階層である物理的階層(Physical Layer)、ＲＬＰ(Radio Link Protocol)階層、ＰＰＰ(Point to Point Protocol)階層、ＩＰ(Internet Protocol)階層、ＴＣＰ/ＵＤＰ(Transmission Control Protocol/User Datagram Protocol)階層と、Socket階層及び最上位階層であるＷＡＰ(Wireless Application Protocol)階層からなっている。
即ち、ＭＳＭは、ＰＰＰ階層の交渉によりＷＡＰに接続する。
【０００６】
また、図１Ｂは、マルチメディア処理部のプロトコルステックとして、マルチメディア処理部は、ＩＰ階層、ＴＣＰ/ＵＤＰ階層とＳｏｃｋｅｔ階層及びＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層のプロトコル階層からなっている。
【０００７】
マルチメディア処理部は、ＭＳＭがＷＡＰに接続して受信したＶＯＤデータのＰＰＰ階層までカプセル解除したＶＯＤデータを受信してＩＰ階層から ＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層までカプセル解除してＶＯＤデータを処理する。また、ＶＯＤサーバー側にデータを送信する際、マルチメディア処理部は、送信データを受信ＶＯＤデータ処理過程の逆順によりＭＳＭに伝送する。
【０００８】
この時、ＭＳＭは、図２のような優先順位によりＶＯＤデータを処理するようになる。参照として、図２のＴＡＳＫは、 ＭＳＭでＶＯＤサービスのために実行するＴＡＳＫを示し、ＣＰＵ ｔｉｍｅ(ms)は、１分当たりＭＳＭ占有率、ＮＯ taskswitchingは、占有時間の間の優先順位により他のＴＡＳＫに占有率を奪われた回数を示し、Ｐｒｉｏｒｉｔｙは、ＴＡＳＫの優先順位を示す。この時、Ｐｒｉｏｒｉｔｙは、数字が高いほど優先順位が早い。
【０００９】
図２から優先順位が高いほどＭＳＭ占有率が高く、ＴＡＳＫの間のスイッチング回数が少ないことが分かる。
したがって、従来携帯用端末機のＶＯＤサービス方法は、ＭＳＭのＷＡＰを通じてＶＯＤサーバーに接続した後にＰＰＰ階層までだけマルチメディアデータを処理し、以後、ＩＰデータからＳｏｃｋｅｔ階層とＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層からは、マルチメディア処理部を通じてＶＯＤデータを処理する過程を実行する。したがって、従来の携帯用端末機は、マルチメディア処理部を通じて無線網のＶＯＤサーバーから自分が希望するＶＯＤデータを鑑賞することができるようになる。
【００１０】
しかし、従来の携帯用端末機は、図２に示したように、優先順位が“７０”、“６０”として非常に低いデータサービス(ＤＳ)とデータプロトコルサービス(ＰＳ)をＭＳＭで処理しなければならないので、過負荷がかかるようになり、それによって最大限の速度を保障できない問題点がある。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、上述したような従来技術の問題点を解決するためになされたもので、その目的は、ＭＳＭを通じてＷＡＰに接続する際に、交渉されたプロトコルを通じてＶＯＤデータを処理するマルチメディア処理部のプロトコルステックを改選してＶＯＤデータの処理速度を向上させた携帯用端末機のＶＯＤサービス方法を提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するための本発明は、マルチメディアデータを処理するマルチメディア処理部と、一般的な端末の制御を実行するＭＳＭに具備された携帯用端末機のＶＯＤデータ処理方法であって、ＭＳＭを通じてＷＡＰに接続する際に、サーバーとの通信のためのＰＰＰ交渉を実行してＰＰＰオプション情報を交渉する過程と、ＭＳＭを通じて交渉されたＰＰＰオプション情報をマルチメディア処理部に伝送する過程と、伝送されたＰＰＰオプション情報をマルチメディア処理部のＰＰＰ情報として使用してＶＯＤデータ経路を設定する過程と、設定されたＶＯＤデータ経路によってＭＳＭに受信されるＶＯＤデータの中でＲＬＰフレームまで処理した後にマルチメディア処理部に伝送する過程と、マルチメディア処理部に伝送されたＶＯＤデータをマルチメディア処理部の最下位階層であるＰＰＰ階層から処理する過程からなることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、マルチメディア処理部の最下位階層をＰＰＰ階層としてＭＳＭでＶＯＤデータをＲＬＰまでだけ処理し、残りのプロトコルは、マルチメディア処理部で処理できるようにすることにより、ＶＯＤサービスを用いる際に、ＶＯＤデータの処理速度が向上される効果がある。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の好適な一実施形態について添付図面を参照しつつ詳細に説明する。下記の説明において、本発明の要旨のみを明確にする目的で、関連した公知機能又は構成に関する具体的な説明は省略する。
【００１５】
図３は、本発明の実施の形態による携帯用端末機の構成を示す図である。
図３を参照すれば、ＲＦ部２１は、携帯用端末機の通信を実行する。このＲＦ部２１は、送信される信号の周波数を上り変換及び増幅するＲＦ送信機と、受信される信号を低雑音増幅して周波数を下り変換するＲＦ受信機と、を含む。
【００１６】
データ処理部２３は、送信される信号を符号化及び変調する送信機及び受信される信号を復調及び復号化する受信機等を備える。即ち、データ処理部２３は、モデム(ＭＯＤＥＭ)及びコデック(ＣＯＤＥＣ)で構成できる。
【００１７】
オーディオ処理部２５は、データ処理部２３から出力される受信オーディオ信号を再生するか又はマイク(ＭＩＣ)から発生される送信オーディオ信号をデータ処理部２３に伝送する機能を実行する。また、オーディオ処理部２５は、本発明の実施の形態によってリアルタイムのＶＯＤデータを通じて出力される音声信号をスピーカー(ＳＰＫ)に出力する。
【００１８】
キーパッド２７は、数字及び文字情報を入力するためのキー及び各種機能を設定するための機能キーを備える。また、キーパッド２７は、本発明の実施の形態によってＶＯＤ接続キー、メニューキー、方向キー、確認キーなどを備えることができる。
【００１９】
メモリー２９は、プログラムメモリー及びデータメモリーで構成できる。プログラムメモリーには、携帯用端末機の一般的な動作を制御するためのプログラム及び本発明の実施の形態によってＶＯＤデータを処理するプログラムが保存される。
【００２０】
マルチメディア処理部３１は、ＶＯＤサービスを実行する際に、無線網を通じて受信されるＶＯＤデータを処理する。また、本発明の実施の形態によってマルチメディア処理部３１は、ＭＳＭ１０からＷＡＰに接続する際に、交渉されたＰＰＰオプション情報を受信してそれによるＰＰＰオプション情報をマルチメディア処理部３１のＰＰＰ情報として使用する。また、ＰＰＰオプション情報を前記マルチメディア処理部３１のＰＰＰ情報として使用するとともに、ＭＳＭ１０のＲＬＰプロトコルで処理されて出力されるＶＯＤデータを処理するための上位階層(ＩＰ、ＴＣＰ/ＵＤＰ、Ｓｏｃｋｅｔ、ＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ)を形成して各階層によるＶＯＤデータのカプセル解除手続きを通じてＶＯＤデータを処理する。また、上位プロトコルから下位プロトコルまでカプセル化してＭＳＭ１０に受信されたＶＯＤデータによる送信データを伝送する。
【００２１】
ＭＳＭ１０は、携帯用端末機の全般的な動作を制御する機能を実行する。また、ＭＳＭ１０は、本発明の実施の形態によってキーパッド２７を通じてＶＯＤサーバー接続メニューを選択する際、それを認識してＷＡＰ接続のためのＰＰＰ交渉を実行して設定されたＰＰＰオプション情報と、そのＷＡＰ接続によって形成された上位プロトコル(ＩＰ、ＴＣＰ/ＵＤＰ、Ｓｏｃｋｅｔ)に関する情報と、をマルチメディア処理部３１に伝送する。また、ＭＳＭ１０は、マルチメディア処理部３１が受信されたＶＯＤデータによって出力する送信データを受信してＶＯＤサーバー側に伝送する。
【００２２】
表示部４０は、ＭＳＭ１０の制御によりプログラムを実行するうちに発生するメッセージを表示する。また、ＭＳＭ１０から出力される使用者データを表示する。また、表示部４０は、本発明の実施の形態によってマルチメディア処理部３１で処理されて出力されるＶＯＤデータを表示する。表示部４０としては、ＬＣＤを使うことができ、この場合、表示部４０は、ＬＣＤ制御部(ＬＣＤ controller)、映像データを保存することができるメモリー及びＬＣＤ表示素子などを備えることができる。ここで、ＬＣＤをタッチスクリーン(touch screen)方式で具現する場合、キーパッド２７とＬＣＤは、入力部になる。
【００２３】
かかる携帯用端末機の動作について説明すれば、まず、発信する際には、使用者がキーパッド２７を通じてダイアルリング動作を実行した後に発信モードを設定すれば、ＭＳＭ１０は、それを感知してデータ処理部２３を通じて受信されるダイアル情報を処理した後にＲＦ部２１を通じてＲＦ信号に変換して出力する。以後、相手の加入者が応答信号を発生すれば、ＲＦ部２１及びデータ処理部２３を通じてそれを感知する。以後、オーディオ処理部２５を通じて音声通話路が形成されて通信機能を実行するようになる。
【００２４】
一方、着信モード時には、ＭＳＭ１０は、データ処理部２３を通じて着信モードであることを感知し、オーディオ処理部２５を通じてリング信号を発生する。以後、使用者が応答すれば、ＭＳＭ１０は、それを感知して、同様にオーディオ処理部２５を通じて音声通話路が形成されて通信機能を実行するようになる。
【００２５】
発信及び着信モードでは、音声通信を一例として説明しているが、音声通信の以外にパケットデータ及び映像データを通信するデータ通信機能を実行することもできる。また、待機モード又は文字通信を実行する場合、ＭＳＭ１０は、データ処理部２３を通じて処理される文字データを表示部４０上に表示する。
【００２６】
前記のような携帯用端末機によりＷＡＰに接続して受信されるＶＯＤデータを処理する過程について説明すれば、キーパッド２７を通じてＶＯＤ接続キーを入力するか或いはメニューキーを入力した後に、ディスプレーされるメニューの中で確認キーによりＶＯＤ接続キーと同一である該当メニューを選択する。それでは、ＭＳＭ１０は、前記ＶＯＤ接続キー、確認キーにより発生するキーデータを認識してＷＡＰに接続を試みる。この時、前記ＭＳＭ１０は、ＷＡＰに接続してＶＯＤサービスを受けるために優先的にＶＯＤサーバー側と基地局との間にデータ伝送規約のための交渉過程を実行する。
【００２７】
ＷＡＰに接続してＶＯＤサービスを用いるための交渉過程について、添付した図面を参照して説明すれば、次のようである。
図４Ａ及び図４Ｂは、図３において、ＶＯＤサービスのためのマルチメディア処理部とＭＳＭのＶＯＤプロトコルステックを示す例示図である。
【００２８】
図４Ａを参照すれば、ＭＳＭ１０のプロトコルステックとして、既存のＭＳＭのプロトコルステックと同一である。即ち、最下位階層である物理的階層、ＲＬＰ階層、ＰＰＰ階層、ＩＰ階層、ＴＣＰ/ＵＤＰ階層と、Ｓｏｃｋｅｔ階層及び最上位階層であるＷＡＰ階層のプロトコル階層からなっている。
即ち、ＭＳＭ１０は、受信データを各階層によるカプセル解除手続きを通じて前記最上位階層であるＷＡＰ階層を介して応用プログラムに伝送する。
【００２９】
また、図４Ｂは、マルチメディア処理部３１のプロトコルステックとして、既存のマルチメディア処理部の最下位階層であるＩＰ階層、ＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層からなったプロトコルステックと相違にＰＰＰ階層を最下位階層とする。
即ち、ＰＰＰ階層を最下位階層としてその次にＩＰ階層、ＴＣＰ/ＵＤＰ階層とSocket階層及びＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層のプロトコル階層からなっている。
【００３０】
ＭＳＭ１０は、ＷＡＰに接続する際に、交渉されたＰＰＰ階層のオプション情報をマルチメディア処理部３１に伝送し、マルチメディア処理部３１は、ＰＰＰ階層のオプション情報を受信してマルチメディア処理部３１のＰＰＰ情報として用いる。
【００３１】
したがって、ＭＳＭ１０を通じて受信されるＶＯＤデータはＲＬＰ階層までだけ処理され、ＲＬＰ階層の上位階層であるＰＰＰ階層からはマルチメディア処理部３１で処理するようになる。
【００３２】
図５は、本発明の一実施の形態による携帯用端末機のＶＯＤデータ処理方法を示す流れ図である。
図５を参照すれば、ＭＳＭ１０は、待機モードでキーパッド２７を通じてＶＯＤ接続キー或いはＶＯＤ接続キーと同一なメニューが選択されたかを感知する(Ｓ５１１)。
【００３３】
該感知の結果、ＶＯＤ接続キー又はＶＯＤ接続キーと同一なメニューが選択される場合、ＭＳＭ１０は、それを認識してＷＡＰ接続を試みるようになる。この時、ＭＳＭ１０は、ＷＡＰを通じて無線インターネット網のＶＯＤサーバーからＶＯＤデータを受信するために無線インターネット網と交渉を実行する(Ｓ５１２)。
【００３４】
ＭＳＭ１０がＷＡＰに接続する際のＰＰＰ交渉進行手続きについて、添付した図面を参照して説明すれば、次のようである。
図６は、本発明の一実施の形態による携帯用端末機と無線インターネット網との間の概略的なＰＰＰ交渉手続きを示す例示図である。後述する図６の前記携帯用端末機は、ＭＳＭ１０を示す。
図７は、図６において、ＬＣＰ交渉する際のＬＣＰフレームの構造を示す例示図であり、図８は、図７において、ＬＣＰフレームの詳細構造を示す例示図であり、図９は、図６において、ＩＰＣＰ交渉する際のＩＰＣＰフレームの詳細構造を示す例示図である。
【００３５】
図６を参照すれば、ステップ６１１〜６１６は、ＬＣＰ交渉過程を示し、ステップ６１７、ステップ６１８は、認証(Authentication、PAP/CHAP)過程を示し、ステップ６１９〜ステップ６２６は、ＩＰＣＰ交渉過程を示す。
【００３６】
まず、携帯用端末機は、ＰＤＳＮ(Packet Data Serving Node、無線インターネット網)側にＬＣＰ交渉のための“conf_Req(1)”を伝送する(ステップ６１１)。ここで、“conf_Req(1)”の数字“1”は、伝送データの一連番号を示すＩＤ情報である。
【００３７】
この時、“conf_Req(1)”は、図７のように、フラッグ(Flag)、アドレス(Address)、コントロール(Control)、情報(Information)、ＣＲＣ及びフラッグフィールドからなるフレーム構造として、最大１５００バイト(byte)からなる。各フィールドについての説明は、一般的なフレームフィールドと同一であるので具体的な説明は省略する。ここで、ＰＰＰ交渉のためのＰＰＰデータフレームのフラッグは、“７Ｅ”、アドレスは、“ＦＦ”、コントロールは、“０３”からなる。情報フラッグは、プロトコルとデータ(ＩＰ/ＬＣＰ/ＩＰＣＰ/ＰＡＰデータ)情報からなる。したがって、プロトコルによってＩＰ/ＬＣＰ/ＩＰＣＰ/ＰＡＰデータを区分するようになる。
【００３８】
図７のように、ＩＰフレームの場合、ＩＰプロトコルは“００２１”、ＬＣＰフレームの場合、ＬＣＰプロトコルは“Ｃ０２１”、ＩＰＣＰフレームの場合、ＩＰＣＰプロトコルは“８０２１”、ＰＡＰフレームの場合、ＰＡＰプロトコルは“Ｃ０２３”からなり、上述したプロトコルの後端には該当プロトコルのデータが含まれる。したがって、プロトコル情報を通じてＩＰ/ＬＣＰ/ＩＰＣＰ/ＰＡＰについてのデータであるか否かが分かるようになる。ＰＡＰ/ＩＰＣＰについてのフレームの詳細な説明は、ＩＰＣＰとＰＡＰ交渉過程を説明する部分で後述する。また、後述されるＰＰＰ交渉のためのデータフレーム(ＬＣＰ、ＰＡＰ/ＣＨＡＰ、ＩＰＣＰ)とＶＯＤデータのＰＰＰデータフレームは、図７を通じて上述したように、情報フィールド(プロトコル＋該当プロトコルデータ)のみが相違である同一なフレーム構造からなる。
【００３９】
情報フィールドは、図７の情報フィールドの中でプロトコル情報を除外した残りの該当プロトコルデータを、図８に示したように細分化する。即ち、８ビット(bit)のコード情報とＩＤ情報、１６ビットのオプション情報(Type＋Length＋Data、Type＋Length)を示すＬｅｎｇｔｈ情報と残りのビットに実際該当プロトコルのデータ、即ち、オプション情報が含まれる。ここで、図８は、ＬＣＰ交渉オプション情報が３種である場合を示し、コード情報が“１”、タイプ情報が“２”、“７”、“８”である場合を一例として示している。
【００４０】
図８において細分化されたプロトコルデータについて詳細に説明すれば、次のようになる。
まず、コード情報の番号が意味することは、下記の表１のようである。
【００４１】
【表１】
2005204322.tif 000003
【００４２】
表１に示したコード番号の中で“１”、“２”と“３”及び“４”について簡単に説明すれば、コード番号“１”はＰＰＰ交渉手続きのうちにＬＣＰ交渉により携帯用端末機からＰＤＳＮ側、或いはその反対にＰＤＳＮ側から携帯用端末機側に伝送されるデータとして、ＬＣＰ交渉を要請する信号を意味する。これは図６のconf_Req(1)とconf_req及びconf_Req(2)信号に含まれるコード番号になる。
【００４３】
一方、コード番号が“２”である場合は、ＬＣＰ交渉過程で受信側携帯用端末機やＰＤＳＮが送信側に受信データを正常に受信して、その受信データを許可することを知らせる信号になる。これは、図６のconf_Ack信号に含まれるコード番号になる。
【００４４】
しかし、コード番号が“３”である場合は、ＬＣＰ交渉過程で受信側携帯用端末機やＰＤＳＮが送信側のデータを正常に受信することができなかったかコード番号“１”のConfigure Requestを拒絶してさらにＬＣＰ交渉を要請することを知らせる信号になる。これは、コード番号“２”と対比されるコード番号になる。
一方、コード番号が“４”である場合は、ＬＣＰ交渉過程で受信側携帯用端末機やＰＤＳＮがConfigure Requestを拒絶する信号になる。
【００４５】
また、コード情報とともに該当プロトコルデータの情報であるＩＤ情報は、データの一連番号を示す。conf_req(1)の数字“１”と後述するconf_Req(2)の数字“２”がここに該当する。
【００４６】
また、Ｌｅｎｇｔｈは、データの長さを示し、以後前記length情報の後端に位置するオプション情報は、ｃｏｎｆｉｇｕｒｅ Ｒｅｑｕｅｓｔしようとするタイプと、そのオプション情報に該当するデータ長さのＬｅｎｇｔｈと、ｃｏｎｆｉｇｕｒｅ Ｒｅｑｕｅｓｔしようとするデータからなる。
【００４７】
タイプ情報の番号が意味することは、下記の表２のようである。
【００４８】
【表２】
2005204322.tif 000004
【００４９】
即ち、タイプ番号“１”は、実際ＶＯＤータを受信することができる最大サイズに関する情報を含む情報を示す。基本的に１５００バイトのＶＯＤデータを受信することができる。タイプ番号“３”は、認証のために使用されるプロトコル(ＰＡＰ、ＣＨＡＰ)を何にするかに関する情報を示す。タイプ番号“４”は、周期的に損失されたパケットと伝送されたオクテット(octets)の数に関する情報を示す。タイプ番号“５”は、エラーが発生した状況やＰＤＳＮ或いは携帯用端末機を区分するために使用されるランダム(random)に選択された数として、サーバーや携帯用端末機に関する情報を示す。タイプ番号“７”は、圧縮されたＰＰＰプロトコルフィールドを受けることができるかに関する情報を示す。タイプ番号“８”は、アドレスと制御フィールドなしにＶＯＤデータフレームを受けることができるかに関する情報を示す。また、タイプ番号“０Ｄ”は、サーバーに認証した後に連結を終了したいことを知らせて他のアプリケーションからそれをさらに呼んで使うようにする情報を示す。
【００５０】
Ｌｅｎｇｔｈ情報は、ＬＣＰオプション情報に関するデータ長さ情報を示す。即ち、図８のように、一番目のＬＣＰオプション情報のＬｅｎｇｔｈ情報は、タイプ情報２バイト、データ情報４バイトとして、総６バイトになって“０６”になり、以後、ＬＣＰオプション情報のＬｅｎｇｔｈ情報は、タイプ情報のみを２バイトを有しているので、Ｌｅｎｇｔｈ情報は、“０２”になる。ここで、前記図８は、ＬＣＰオプション情報個数を一例として３個としたが、これは可変的である。
Ｌｅｎｇｔｈ情報の後端に位置するデータは、タイプによるデータを意味する。
【００５１】
上述した構造のＬＣＰフレームの“conf_Req(1)”を受信したＰＤＳＮは、前記“conf_Req(1)”について正常に受信されたことを知らせる“conf_Ack(コード番号:２)”を携帯用端末機側に伝送する(ステップ６１２)。それとは反対に、正常に受信されなければ、ＰＤＳＮは携帯用端末機に“conf_Nak(コード番号:３)”を伝送する。
【００５２】
“conf_Req(1)”を伝送した携帯用端末機は、ＬＣＰ交渉過程で要求データがさらにある場合には、“conf_Req(2)”を伝送するようになる(ステップ６１３)。この場合も同様にＰＤＳＮ側で正常にデータを受信すれば、“conf_Ack”を携帯用端末機に伝送し、正常にデータが受信されなければ、“conf_Nak”を伝送したさらにＬＣＰ交渉要求データを伝送する(ステップ６１４)。
【００５３】
しかし、ＰＤＳＮが“conf_Req(1)”の応答信号として“conf_Rej(コード番号:４)”を携帯用端末機に伝送すれば(ステップ６１５)、携帯用端末機は、これを受信した後にＬＣＰオプション情報を変化させてＬＣＰ交渉要求データを伝送する。
次に、携帯用端末機は、“conf_Ack”を受信しながらＬＣＰ交渉過程を終了する。
【００５４】
一方、ステップ６１１では、携帯用端末機がＰＤＳＮ側に“conf_Req(1)”を伝送するが、それと反対に、先にＰＤＳＮ側からＬＣＰ交渉要求データを携帯用端末機側に伝送することもできる。
【００５５】
ステップ６１４で“conf_Ack”を受信した後に、ＬＣＰ交渉過程を終了すれば、携帯用端末機は、ＰＤＳＮ側に認証を要求するようになる(ステップ６１６)。
即ち、前記携帯用端末機がＰＤＳＮに“Authenticate_Req”を伝送して認証を要求するようになり、その認証要求を受けたＰＤＳＮは、その認証要求による応答信号として“Authenticate_Ack”を前記携帯用端末機に伝送する(ステップ６１７)。
以後、携帯用端末機は、“Authenticate_Ack”を受信すれば、認証過程を終了してＩＰＣＰ交渉過程を実行する。
【００５６】
“Authenticate_Ack”を受信した携帯用端末機は、ＩＰＣＰ交渉のために“IPCP_Req(1)”をＰＤＳＮ側に伝送する(ステップ６１８)。即ち、携帯用端末機は、ＩＰ及びＤＮＳ(Domain Name System)住所を要求し、それによって、ＰＤＳＮは、ＩＰ及びＤＮＳ住所を携帯用端末機に割り当てる。ここで、“IPCP_Req(1)”の数字“１”は、伝送データの一連番号を示すＩＤ情報である。
【００５７】
次に、ＰＤＳＮは、それによる応答信号として“IPCP_Ack(コード番号:２)”を携帯用端末機に伝送してＩＰＣＰ交渉を終了するか(ステップ６１９)、下記のステップ６２１によるＰＤＳＮの応答信号として“IPCP_Ack(コード番号:２)”が携帯用端末機に伝送される場合、ＰＰＰ交渉進行過程を終了する(ステップ６２３)。これとは反対に、正常に受信されなかった場合は、ＰＤＳＮは携帯用端末機に“IPCP_Nak(コード番号:３)”を伝送する。
【００５８】
しかし、ＰＤＳＮが“IPCP_Req(1)”の応答信号として“conf_Rej(コード番号:４)”を携帯用端末機に伝送する場合、携帯用端末機は、それを受信した後にＩＰＣＰオプション情報を変化させてＩＰＣＰ交渉要求データを伝送する(ステップ６２０)。このような過程は、図６のステップ６２１とステップ６２２の“IPCP_Req(2)”、“IPCP_Req(3)”についても同一に適用される。
【００５９】
以後、携帯用端末機は、ＩＰＣＰ交渉要求データがさらに存在すれば、要求データの量によってステップ６２１とステップ６２２を通じて“IPCP_Req(2)”と“IPCP_Req(3)”を伝送するようになる。
【００６０】
ＩＰＣＰフレームは、図７に示したように、プロトコルとＩＰＣＰデータフィールドからなるので、図９に示したように、ＩＰＣＰデータフィールドを細分化できる。ここで、図８と図９から分かるように、ＬＣＰとＩＰＣＰのフレーム構造は同一である。したがって、相違であるコード情報とタイプ情報についてだけ説明し、他のフィールドについての説明は省略する。
【００６１】
ＩＰＣＰフレームのコード情報は、下記の表３ようである。
【００６２】
【表３】
2005204322.tif 000005
【００６３】
表３に示したコード番号“１”は、ＩＰＣＰ交渉手続きのうちにＩＰＣＰ交渉により携帯用端末機からＰＤＳＮ側、或いはその反対にＰＤＳＮ側から携帯用端末機側に伝送されるデータとして、ＩＰＣＰ交渉を要請する信号を意味する。これは、図６のIPCP_Req(1)とIPCP_req(2)及びIPCP_Req(3)信号に含まれるコード番号になる。
【００６４】
一方、コード番号が“２”である場合は、ＬＣＰ交渉過程で受信側携帯用端末機やＰＤＳＮが送信側に受信データを正常に受信し、その受信データを許可することを知らせる信号になる。これは、図６のIPCP_Ack信号に含まれるコード番号になる。
【００６５】
しかし、コード番号が“３”である場合は、ＩＰＣＰ交渉過程で受信側携帯用端末機やＰＤＳＮが送信側のデータを正常に受信することができなかったか、コード番号“１”のＣｏｎｆｉｇｕｒｅ Ｒｅｑｕｅｓｔを拒絶してさらにＩＰＣＰ交渉を要請すること知らせる信号になる。これは、コード番号“２”と対比されるコード番号になる。
【００６６】
一方、コード番号“４”である場合は、ＩＰＣＰ交渉過程で受信側携帯用端末機やＰＤＳＮがＣｏｎｆｉｇｕｒｅ Ｒｅｑｕｅｓｔを拒絶する信号になる。
また、上述のコード情報とともにＩＰＣＰフレームとＬＣＰフレームの中で相異なっているタイプ情報は、下記の表４のようになる。
【００６７】
【表４】
2005204322.tif 000006
【００６８】
上述した過程を通じてＭＳＭ１０は、ＰＰＰ交渉した後にそのＰＰＰ交渉されたＰＰＰオプション情報をマルチメディア処理部３１に伝送する(ステップ５１３)。したがって、マルチメディア処理部３１は、受信したＰＰＰオプション情報をそのマルチメディア処理部の最下位階層であるＰＰＰ情報として使用する。
【００６９】
以後、ＭＳＭ１０のＲＬＰ階層までだけ処理されてマルチメディア処理部３１に伝送されるデータ経路が設定される。したがって、ＭＳＭ１０は、ＶＯＤデータをＲＬＰフレームまでだけ処理した後にマルチメディア処理部３１に伝送する(ステップ５１４)。
【００７０】
次に、マルチメディア処理部３１は、ＭＳＭ１０から受信されたＶＯＤデータをＰＰＰ階層から最上位階層であるＲＴＰ/ＲＴＣＰ/ＲＴＳＰ/ＨＴＴＰ階層までカプセル解除してＶＯＤデータを処理する(ステップ５１５)。
【００７１】
以後、マルチメディア処理部３１は、ＶＯＤサービスが終了されることをＭＳＭ１０に知らせれば、設定されたマルチメディア処理部のデータ経路が解除され、ＭＳＭで一般データを処理する経路が設定されてＶＯＤサービスは終了される(ステップ５１６)。
【００７２】
したがって、下記の表５のように、アップロードとダウンロードする際のＶＯＤデータ処理速度が向上されることが分かる。
【００７３】
【表５】
2005204322.tif 000007
【００７４】
ここで、表５は、送受信ＶＯＤデータをファイルシステムまで保存するためにかかる負荷まで考慮した結果を示し、テスト環境によって多少差が発生できる。また、各比較値は、実際サービスを通じて数回テストを通じて測定された平均値であり、それによる最大値も共に示した。
【００７５】
本発明による携帯用端末機のＶＯＤデータ処理方法は、ＭＳＭを通じてＷＡＰに接続する際に、交渉されたＰＰＰオプション情報をマルチメディア処理部のＰＰＰ階層のＰＰＰ情報として用いるようにする。したがって、ＭＳＭは、受信されるＶＯＤデータの処理速度を最大限保障できるＲＬＰまでだけ処理してマルチメディア処理部に伝送し、そのマルチメディア処理部は、受信したＶＯＤデータをＰＰＰフレームから処理することにより、携帯用端末機のＶＯＤデータ処理速度が向上される。
【００７６】
以上、本発明を具体的な実施形態を参照して詳細に説明したが、本発明の範囲は前述の実施形態によって限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で様々な変形が可能なことは、当該技術分野における通常の知識を持つ者には明らかである。
【図面の簡単な説明】
【００７７】
【図１Ａ】従来携帯用端末機のＶＯＤサービスのためのマルチメディア処理部とＭＳＭのＶＯＤプロトコルステックを示す例示図である。
【図１Ｂ】従来携帯用端末機のＶＯＤサービスのためのマルチメディア処理部とＭＳＭのＶＯＤプロトコルステックを示す例示図である。
【図２】従来携帯用端末機のＴＡＳＫ別にＭＳＭ占有率及び優先順位を示す例示図である。
【図３】本発明の実施の形態による携帯用端末機の構成を示す図である。
【図４Ａ】図３において、ＶＯＤサービスのためのマルチメディア処理部とＭＳＭのＶＯＤプロトコルステックを示す例示図である。
【図４Ｂ】図３において、ＶＯＤサービスのためのマルチメディア処理部とＭＳＭのＶＯＤプロトコルステックを示す例示図である。
【図５】本発明の一実施の形態による携帯用端末機のＶＯＤデータ処理方法を示す流れ図である。
【図６】本発明の一実施の形態による携帯用端末機と無線インターネット網との間の概略的なＰＰＰ交渉手続きを示す例示図である。
【図７】図６において、ＬＣＰ交渉する際のＬＣＰフレームの構造を示す例示図である。
【図８】図７において、ＬＣＰフレームの詳細構造を示す例示図である。
【図９】図６において、ＩＰＣＰ交渉する際のＩＰＣＰフレームの詳細構造を示す例示図である。
【符号の説明】
【００７８】
１０      ＭＳＭ
２１      ＲＦ部
２３      データ処理部
２５      オーディオ処理部
２７      キーパッド
２９      メモリー
３１      マルチメディア処理部
４０      表示部
【図１Ａ】
2005204322.tif 000008
【図１Ｂ】
2005204322.tif 000009
【図２】
2005204322.tif 000010
【図３】
2005204322.tif 000011
【図４Ａ】
2005204322.tif 000012
【図４Ｂ】
2005204322.tif 000013
【図５】
2005204322.tif 000014
【図６】
2005204322.tif 000015
【図７】
2005204322.tif 000016
【図８】
2005204322.tif 000017
【図９】
2005204322.tif 000018