JP4077406B2 - オープンサービスアクセスのための拡張された遠隔通信システムアーキテクチャ - Google Patents

オープンサービスアクセスのための拡張された遠隔通信システムアーキテクチャ Download PDF

Info

Publication number
JP4077406B2
JP4077406B2 JP2003513261A JP2003513261A JP4077406B2 JP 4077406 B2 JP4077406 B2 JP 4077406B2 JP 2003513261 A JP2003513261 A JP 2003513261A JP 2003513261 A JP2003513261 A JP 2003513261A JP 4077406 B2 JP4077406 B2 JP 4077406B2
Authority
JP
Japan
Prior art keywords
network
terminal
scf
application
telecommunications system
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.)
Expired - Fee Related
Application number
JP2003513261A
Other languages
English (en)
Other versions
JP2004535141A (ja
Inventor
タン，ド，バン
グレーデム，グンバルト，マルティン
Original Assignee
テレノール アーアスアー
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 テレノール アーアスアー filed Critical テレノール アーアスアー
Publication of JP2004535141A publication Critical patent/JP2004535141A/ja
Application granted granted Critical
Publication of JP4077406B2 publication Critical patent/JP4077406B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H04Q3/0095—Specification, development or application of network management software, e.g. software re-use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Small-Scale Networks (AREA)
  • Input Circuits Of Receivers And Coupling Of Receivers And Audio Equipment (AREA)
  • Radio Relay Systems (AREA)
  • Surgical Instruments (AREA)

Description

本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法及びシステムに関するものである。本発明は移動通信から生じたものではあるが、全ての通信分野に適用できる。また、遠隔通信とコンピューティングとが統合しているので、本発明は、ＩＰ（Internet Protocol）ベースのネットワークなどパケット式ネットワーク上でのデータ通信にも適用できる。
第三者によるアプリケーションの開発を促進するために、第三世代移動通信システム（ＵＭＴＳ）のための標準化組織である 3ＧＰＰ（第三世代パートナーシッププロジェクト）（http://www.3gpp.org ）は、第三世代移動通信システム（ＵＭＴＳ）のためのオープンサービスアクセス（ＯＳＡ）を導入した。ＯＳＡの標準は、3GPP, Virtual Home Environment ; Open Service Architecture （Release 4）. Valbonne, 2001. （3GPP TS 23.127, V4.1.0, 2001-04）に定義されている。
ＯＳＡにより、アプリケーションは オープンインターフェースを介して、コールコントロール（ＣＣ）、ユーザステータス（ＵＳ）、メッセージング（Ｍ）、ロケーションインフォメーション（ＬＩ）などのネットワークサービス機能にアクセスすることができる。そのようなアーキテクチャは、ＵＭＴＳの成功に必要な一以上の「キラー（killer）」アプリケーションの実現において重要な役割を果たすことは間違いない。何がそのような「キラー」アプリケーションになるかは誰もまだ知らないことは強調するに値する。実際、ＧＳＭについては、ＳＭＳ（Short Message Service）が「キラー」アプリケーションになることを誰も予測できなっかった。
ＯＳＡは移動通信ネットワークのみを対象としている。しかし、通信とコンピューティングとが統合し、また固定通信と移動通信とが統合してきているため、アプリケーションは、下層のネットワークと独立して適切に動作できることが非常に重要である。従って、ＯＳＡの適用範囲を広げて、ＰＳＴＮ／ＩＳＤＮなどの移動通信ネットワーク以外のネットワークやＩＰベースネットワークを含めることが必要である。ＩＰベースネットワークは、例えば、無線ＬＡＮ（８０２．１１）、ハイパーＬＡＮ、又はブルートゥースなどのように無線式と有線式があることは注目する価値がある。この状況について以下記載する。
残念なことに、ＯＳＡは移動通信ネットワークのみを対象としており、不均質ネットワークにＯＳＡを実施する方法については明記していない。更に、３ＧＰＰで特定されているように、ＯＳＡは不均質ネットワークに適用するのには充分でない。本発明は、幾つかの異なるネットワークの最上部でＯＳＡを実施するためのいろいろな実施形態を提案する。また、ＯＳＡに追加の機能が必要となり、本発明によってこれが提案される。
発明者らの知識によれば、上記の問題に対する解決策は現在のところ知られていない。ＯＳＡが準拠しているパーレイ（Parlay）アーキテクチャ（http://www.parlay.org ）でさえも、パーレイを不均質ネットワーク上で実施する活動は行われていない。パーレイアーキテクチャの概観では、移動通信ネットワーク、ＩＳＤＮ及びＩＰベースネットワークをカバーするパーレイＡＰＩが示されているが、その実施についの詳細はない。
第１の様相において、本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する遠隔通信システムであって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する少なくとも一つのフレームワークを備えたオープンサービスアクセス（ＯＳＡ）エクステンションを含むシステムを提供する。
端末ＩＤアドミニストレータを設け、端末ＩＤに基づいて必要なネットワークを選択するための情報をアプリケーションに提供するようにしてもよい。
第１の実施形態では、システムは、前記ネットワークのための唯一の共用フレームワークと、ネットワーク毎に設けられ、ネットワーク固有インターフェースを提供する一つのサービスキャパビリティフィーチャ（ＳＣＦ）とを含んでいる。このサービスキャパビリティフィーチャは、ＳＣＦが情報交換する下層ネットワークを示すジェネラルサービスプロパティを含んでいてもよい。このジェネラルサービスプロパティは、<operator, network> のペアを含む文字列として表される。
この実施形態では、端末ＩＤアドミニストレータが端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する。端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含んでいてもよい。また、端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含んでいてもよい。端末ＩＤアドミニストレータはリアルタイムで更新可能である。アプリケーションの問い合わせのためのインターフェースクラスを含む端末アドミニストレータ（ＴＡ ＳＣＦ）によって、要求しているアプリケーションと端末ＩＤアドミニストレータのインスタンスとの間のインターフェースが提供される。端末アドミニストレータ（ＴＡ ＳＣＦ）は、アプリケーションが、所定の端末のための正しいサービスキャパビリティフィーチャについてのリファレンスを得ること、幾つかの端末ＩＤについてのサービスキャパビリティインスタンスのリファレンスを同時に問い合わせること、所定の端末のネットワークＩＤを得ること、そのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ること、及び特定のネットワーク上の全てのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ることを可能にするプログラム手段を含む。
別の実施形態では、システムは、上記の構成に代え、前記ネットワークのための唯一の共用フレームワークと、ネットワークのために設けられ、共用ネットワークインターフェースを提供する共用サービスキャパビリティフィーチャ（ＳＣＦ）とを含んでいる。ジェネラサービスプロパティは、ＳＣＦが情報交換する下層ネットワークを示すサービスキャパビリティフィーチャに含まれてもよい。このジェネラルサービスプロパティは、各々が<operator, network> のペアを含む文字列群として表される。インターフェースは、アプリケーションと下層のネットワークのインターフェースとの間の一から多数のマッピングを提供するサービスキャパビリティインターフェースクラスを含んでいてもよい。
更に、共用サービスキャパビリティフィーチャは、インターフェースクラスからネットワークインターフェースへマッピングを行うマッピング手段と、要求をアプリケーションから正しいネットワークインターフェースクラスに送るディスパッチャ手段とを含んでいてもよい。マッピング手段とディスパッチャ手段との間の登録インターフェースは、ディスパッチャへのネットワークの登録を可能にする。ディスパッチャ手段は、アプリケーションから到着する要求ために正しいサービスキャパビリティフィーチャ（ＳＣＦ）を選択する選択手段を含む。端末ＩＤアドミニストレータは、端末ＩＤに基づいて、アプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャ（ＳＣＦ）を選択する。アプリケーションと端末ＩＤとの間のマッピング情報は、端末ＩＤアドミニストレータのデータベース／ディレクトリに含まれていてもよい。このデータベース／ディレクトリは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含んでいる。本実施形態においても、端末ＩＤアドミニストレータはリアルタイムで更新可能である。端末ＩＤアドミニストレータ（ＴＡ ＳＣＦ）は、ＳＣＦディスパッチャ手段のためのインターフェースを提供し、この端末ＩＤアドミニストレータは、動作時に、そのＳＣＦインスタンスに要求を送るために、所定の端末のための正しいサービスキャパビリティインスタンスについてのリファレンスを得るプログラム手段を含み、これには、アプリケーションが取り扱われる端末ＩＤを得ること、要求しているアプリケーションのアプリケーションＩＤ、及びＳＣＦインスタンスによって返されたサービスキャパビリティフィーチャインスタンスのリファレンスを得ることが含まれる。
更に別の実施形態では、システムは、各ネットワーク用のフレームワークを含んでいてもよく、各フレームワークは，前記ネットワークのためのサービスキャパビリティフィーチャ（ＳＣＦ）を有し、ネットワーク固有のインスタンスを提供する。各フレームワークは、他のフレームワーク内のサービスキャパビリティフィーチャを選択し、このサービスキャパビリティフィーチャに対するリファレンスを受け取ることを可能にする機構を含んでいてもよい。フレームワークのための選択可能なサービスキャパビリティフィーチャは予め定義されてもよい。各フレームワークは，端末ＩＤに基づくネットワーク選択に関連して、アプリケーションにサービスキャパビリティ機能を提供する端末ＩＤインフォメータを含んでいてもよい。端末ＩＤインフォメータは、要求しているアプリケーションに、<terminal ID, belong(True/False)>のペアを含む文字列を返す。全てのフレームワークは、要求された時に相互認証手続きを実行するプログラム手段を含んでいてもよい。これは、前記フレームワークが提供するサービスキャパビリティフィーチャについての情報を他のフレームワークが要求する場合である。これを可能にするために、フレームワークは、拡張されたインターフェースを含んでいてもよい。この拡張されたインターフェースは、要求しているフレームワークの識別情報を、前記フレームワークに提供された予め定義されたサービスキャパビリティフィーチャのリストと共に戻す要求手続きと、あるフレームワークが、要求しているアプリケーションによって指定されたサービスプロパティに従って、サービスキャパビリティフィーチャインスタンスのリファレンスを返すことを他のネットワークに対して要求することを可能にする獲得手続きとを実行するプログラム手段を含んでいてもよい。端末ＩＤアドミニストレータは、端末ＩＤに基づいて、アプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する。選択は、端末ＩＤアドミニストレータと情報交換するデータベース／ディレクトリに基づくマッピング機能によって可能となる。データベース／ディレクトリは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含んでいてもよい。各フレームワークがサポートする端末ＩＤの範囲に関する情報を端末ＩＤアドミニストレータに提供する情報インターフェースもまた端末ＩＤアドミニストレータに含まれてもよい。端末ＩＤアドミニストレータはリアルタイムで更新可能である。
不均質ネットワークの例としては、移動通信、ＵＭＴＳ、ＧＳＭ、ＰＳＴＮ/ ＩＳＤＮなどの遠隔通信ネットワーク（無線又は有線）、及びＩＰ（有線）、無線ＬＡＮ、ブルートゥース又はハイパーＬＡＮ（無線）などのパケット式ネットワークのようなコンピュータネットワークが挙げられるが、これらに限定されるものではない。
更なる様相では、本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法であって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する、不均質ネットワークためのアプリケーションプログラミングインターフェース（ＡＰＩ）中の少なくとも一つのフレームワークを用いてオープンサービスアクセス（ＯＳＡ）エクステンションを実行することを含む方法を提供する。
更に別の様相では、本発明は、アプリケーションのためのオープンサービスアクセスを複数の不均質ネットワークに提供するためのアプリケーションプログラミングインターフェース（ＡＰＩ）のプログラムを提供する。該プログラムは、上記の方法を実施しそして上記のびシステムを確立するための指令群を含んでいる。
別の様相では、本発明は、アプリケーションのためのオープンサービスアクセスを複数の不均質ネットワークに提供するためのアプリケーションプログラミングインターフェース（ＡＰＩ）を記憶した、コンピュータにより読出可能な媒体を提供する。該媒体は、上記の方法を実施し、上記のシステムを確立するための指令群を含んでいる。
本発明は、例えは、ネットワークオペレータ、サービス／アプリケーションプロバイダ、及びユーザなどの、遠隔通信及び情報交換分野における種々の関係者にいろいろな方法で利益をもたらす。ネットワークオペレータは、アプリケーションに対してより柔軟なサービスを提供できるであろう。従って、彼らは、より多くの数のアプリケーション、従って、より高いトラフィックを得ることができ、またより多数のユーザを得ることができる。サービス／アプリケーションプロバイダはアプリケーションをより簡単に開発でき、より興味のあるアプリケーションを開発できる。彼らは、ネットワークの相違を気にする必要がない。アプリケーションは不均質なネットワーク上で動作するため、アプリケーションはより一般的なものとなる。同一のアプリケーションを異なるネットワークで展開できるため、極めて多くの再使用が可能で、大幅な節約になる。ユーザは、ＯＳＡ ＡＰＩによって不均質なネットワーク上で動作可能とされた広範なアプリケーションを楽しむことができるであろう。本発明はＯＳＡヘ適用するものであるが、ＰＡＲＬＡＹアーキテクチャにも適用可能である。何故なら、ＯＳＡは多くをＰＡＲＬＡＹに依存しているからである。
上記のように、本発明は、不均質なネットワークのためのアプリケーションの開発を簡単にできるため、サービス／アプリケーションプロバイダの問題を解決できる。同時に、不均質なネットワーク（例えは、固定及び移動式の遠隔通信、並びにＩＰベースの通信）を有するネットワークオペレータに機会を与えることができる。本発明は添付の請求の範囲に定義されている。
以下、本発明の実施形態を図面を参照して説明する。
本発明は、二つの主要なアイテムから成っている。
・不均質ネットワークへのＯＳＡの適用の提案。
・不均質ネットワーク上でＯＳＡを実施するための実施形態。各実施形態について、必要な付加機能とそれらのＯＳＡへの組み込みについて述べる。
本発明は、本来は第三世代移動通信ネットワークを対象にしていたＯＳＡ（オープンサービスアクセス）の適用範囲を不均質ネットワークまで広げる、即ち、ＰＳＴＮ、ＩＳＤＮ、及びＩＰベースのネットワーク（インターネット、イントラネット）をも含めるようにする。以下、不均質ネットワーク上でＯＳＡを実施するための４つの実施形態について述べる。各実施形態に関連する問題を検討し、必要となる追加機能や特徴を呈示できる。
実施形態１：全てのネットワークのための共用ＯＳＡフレームワークと各ネットワークのための一つのサービスキャパビリティフィーチャ
本実施形態では、単一のＯＳＡフレームワークが全てのネットワークを受け入れるが、各ネットワークは独自のサービスキャパビリティフィーチャ（ＳＣＦ）を有する。ＧＳＭ／ＵＭＴＳネットワークは、コールコントロール（ＣＣ）ＳＣＦ、ユーザインターラクション（ＵＩ）ＳＣＦ、ユーザステータス（ＵＳ）ＳＣＦなどのＳＣＦを有するであろう。図２に示すようにＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワークの場合も同様である。
従って、各ＳＣＦが各ネットワークに固有のインターフェースにマッピングされる。どの様にマッピングが行われるかはネットワークに依存する。例えば、ＧＳＭネットワークについて責任のあるＣＣ ＳＣＦは、ＧＳＭネットワーク内でコールコントロールを出すインターフェースにマッピングされる。ＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワーク内のＣＣ ＳＣＦの場合も同様である。これにより、我々の不均質ネットワーク環境内の各ネットワークのためのコールコントロール・ネットワークサービスキャパビリティに対して標準化されたＣＣ ＡＰＩが得られ、第三者のアプリケーションが全てのネットワーク内でコールコントロールキャパビリティを使用できるようになる。他のＳＣＦについても同様である。
必要とされる追加機能
Ａ．ＳＣＦネーミング方式
各下層ネットワークのためのＳＣＦは、ＯＳＡフレームワークを用いて識別されそして登録される必要がある。従って、ＳＣＦのサービスプロパティの値は、各ＳＣＦがどのネットワークに属しているかを示す必要がある。また、ネットワークの所有者、即ちネットワークオペレータを認識する必要がある。この目的のために、ＳＣＦが情報交換している下層ネットワークを示す、"Underlying Network"と呼ばれるジェネラルサービスプロパティが導入される。このプロパティ値は、<Operator, network> のペアを含む文字列である。例えは、ユーザステータスＳＣＦの場合、その値は<Telenor, GSM>又は<Netcom, GSM>又は<Telenor, IP-based(SIP)>となり得る。
＜オペレータ，ネットワーク＞のペアを含む文字列である。
Ｂ．端末ＩＤに基づくＳＣＦインスタンスの選択
アプリケーションにとっての大きな問題は、端末識別器、即ち、端末ＩＤ、のみに基づいてどの様にして正しいＳＣＦインスタンスを選択するかということである。通常の電話番号、名前、又はＩＰアドレスを端末ＩＤとすることができる。例えば、アプリケーションが、ある端末に対しての呼び出しを確立することを望む場合、アプリケーションは正しいＣＣ ＳＣＦに対して申し込む必要がある。幾つかの端末ＩＤは、ＧＳＭネットワーク、例えばＳＩＰアドレス、の範囲になく、従って、これらの端末に対しての呼び出し要求はＧＳＭネットワークに送ってはならず、ＩＰベースネットワークに送らなければならない。
別の問題は、アプリケーションが、例えば、「クリックツーコール（click to call ）」アプリケーションの呼び出しを確立することを望む場合、その呼び出しを確立する下層ネットワーク、即ち、使用するＣＣ ＳＣＦインスタンスを選択しなければならない。
更に、アプリケーションが、例えばユーザステータスＳＣＦを使用する時に問題が発生する。ユーザステータス（ＵＳ）ＳＣＦは、アプリケーションがユーザの端末の状態（到達可能、到達不可能、及び使用中）を得られるようにする。ＧＳＭネットワークのためのＵＳ ＳＣＦは、ＧＳＭネットワークの範囲内の端末（ＨＬＲに登録されたＧＳＭ電話）にユーザステータスを伝えることができるだけであり、ＩＰベースネットワークのためのＵＳ ＳＣＦは、ＳＩＰサーバなどに登録されたユーザにユーザステータスを伝えることができるだけである。ユーザのユーザステータスをチェックすることを望むアプリケーションは、ユーザの端末ＩＤに従って正しいＳＣＦインスタンス、即ち正しい下層ネットワークを選択しなければならない。例えば、端末ＩＤがＧＳＭ番号である場合、アプリケーションはＧＳＭネットワークのためのＵＳ ＳＣＦインスタンスを選択しなければならない。その後、アプリケーションは、選択したＵＳ ＳＣＦインスタンスと交信することによって要求したユーザステータスを得ることができる。
上記の例から、ＳＣＦに対してアクションを行う時にアプリケーションは正しいＳＣＦインスタンスを選択しなければならないという問題があることが分かる。アプリケーションは、端末の命名法又は番号の付け方についての情報、即ち、どの端末がどのネットワークに属しているかについての情報を有していなければならない。更に、端末ＩＤと正しいＳＣＦインスタンスとの間にリンクがなければならない。そのような情報は定常的なものでなく頻繁に変化し、頻繁に更新しなければならない。何故なら、人々は、端末、オペレータ、及び申し込み（subscriptions）を頻繁に変更するからである。アプリケーションが端末ＩＤに基づいてＳＣＦを選択するのを助ける端末ＩＤアドミニストレータと呼ばれる追加の機能が必要となる。
端末ＩＤアドミニストレータ（ＴＡ）は、図３に示すように、アプリケーションとＳＣＦインスタンスとの間のマッピング、ＳＣＦインスタンスとネットワークとの間のマッピング、そして最後にネットワークと端末ＩＤとの間のマッピングを含むデータベース／ディレクトリを有している。図面中の数字は基数を示す。１は１だけを示し、＋１は１以上を示す。一つのアプリケーションは１以上のＳＣＦインスタンスを有することができる。一つのＳＣＦインスタンスは一つのアプリケーションしか有しない。一つのＳＣＦは一つのネットワークしか有しないが、一つのネットワークが１以上のＳＣＦを有する場合がある。一つのネットワークは１以上の端末を有しているが、一台の端末は一つのネットワークのみに属している。ＴＡは、ネットワークオペレータが、変化が起きた時にそれを登録できるようにし、またアプリケーションが、上記の全てのマッピングに関する情報、例えば図４に示すような端末ＩＤ群のためのＳＣＦインスタンスについて問い合わせできるようにする。
ＴＡは、ＯＳＡを使用する任意のアプリケーションのための有用な機能を提供する。従って、ＴＡは、アプリケーションのために容易にアクセスできなければならない。この目的のために、ＴＡの機能を標準的なＡＰＩとして要約する、端末アドミニストレータＳＣＦ（ＴＡ ＳＣＦ）と呼ばれるＯＳＡサービスキャパビリティフィーチャ（ＳＣＦ）が設けられる。ＴＡ ＳＣＦは、アプリケーションの問い合わせのためのインターフェースクラスを有している。アプリケーションの問い合わせのためのＴＡ ＳＣＦインターフェースは、アプリケーションが使用できる下記のメソッドを含んでいる。
getSCFinstance(<terminalID>,<applicationID><SCFreference>)
<terminalID>は、アプリケーションが取り扱われる端末ＩＤ、例えば、電話番号。
<applicationID> は、要求しているアプリケーションのＩＤ。
<SCFreference>は、ＴＡ ＳＣＦによって返されるＳＣＦインスタンスのリファレンス。
このメソッドにより、アプリケーションは、所定の端末のための正しいＳＣＦインスタンスのリファレンス、例えば電話番号を得ることができる。
getListofSCFinstances(<listofTerminalID>,<applicationID>,<listofSCFreferences>)
<listofTerminalID>は、ＳＣＦインスタンスを見つける端末ＩＤのリスト。
<applicationID> は、要求しているアプリケーションのＩＤ。
<listofSCFreferences> は、ＴＡ ＳＣＦによって返されるリファレンス及び対応する端末ＩＤのリスト。
このメソッドにより、アプリケーションは、幾つかの端末ＩＤのためのＳＣＦインスタンスのリファレンスを同時に問い合わせることができる。
getNetworkID(<terminalID>,<applicationID><NetworkID>)
<terminalID>は、アプリケーションが取り扱われる端末ＩＤ。
<applicationID> は、要求しているアプリケーションのＩＤ。
<NetworkID> は、ＴＡ ＳＣＦによって返される、端末が属しているネットワークのＩＤ。
このメソッドにより、アプリケーションは、所定の端末のネットワークＩＤを得ることができる。
getAllSCFinstance,(<applicationID><ListofSCFreferencse>)
<applicationID> は、要求しているアプリケーションのＩＤ。
<SCFreference>は、ＴＡ ＳＣＦによって返される、アプリケーションのためのＳＣＦインスタンスのリファレンスのリスト。
このメソッドにより、アプリケーションは、アプリケーションの全てのＳＣＦインスタンスのリストを得ることができる。
getAllSCFinstance,(<applicationID>,<networkID>,<ListofSCFreferencse>)
<applicationID> は、要求しているアプリケーションのＩＤ。
<networkID> は、ネットワークのＩＤ、例えば、＜Telenor, GSM> 、 <OperatorX, ISDN>、<OperatorY, IP-based> など。
<SCFreference>は、ＴＡ ＳＣＦによって返される、アプリケーションのためのＳＣＦインスタンスのリファレンスのリスト。
このメソッドにより、アプリケーションは、特定のネットワーク上のアプリケーションの全てのＳＣＦインスタンスのリストを得ることができる。
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいると仮定する。アプリケーションは、<terminalID>=12345678 とＳＣＦの名称 <SCFtype> ="User Status" を含む問い合わせをＴＡ ＳＣＦ（getSCFinstance）に送出する。これに応答して、アプリケーションは、要求した端末ＩＤが属しているユーザステータスＳＣＦに対する目的とするリファレンスを受け取る。これにより、アプリケーションは、下層のネットワークを気にすることなく、正しいＵＳ ＳＣＦを使用できる。従って、ＴＡ ＳＣＦを使用する時、本実施形態は、ＯＳＡのゴールにより確認される。
上記した実施形態１は図５に要約されている。
実施形態２：全てのネットワークのための共用フレームワーク及び共用ＳＣＦ（サービスキャパビリティフィーチャ）
本発明のこの実施形態では、単一のＯＳＡフレームワークが全てのネットワークを受け入れ、ＳＣＦが全ての下層のネットワークを代表する。例えば、コールコントロールＳＣＦは、ＧＳＭ／ＵＭＴＳネットワーク、ＰＳＴＮ／ＩＳＤＮネットワーク、及びＩＰベースネットワークのためのコールコントロールキャパビリティを組入れる。図６に示す他のＳＣＦについても同様である。
従って、各ＳＣＦが全てのネットワークと通信する。例えば、ＣＣ ＳＣＦは、ＧＳＭネットワーク、ＰＳＴＮ／ＩＳＤＮネットワーク、及びＩＰベースネットワーク内でコールコントロールを出すインターフェースにマッピングされる。アプリケーションは、単一のＣＣ ＳＣＦのみを用いて全てのネットワーク上でコールコントロールを行うことができる。他のＳＣＦについても同様である。
追加機能
Ａ．ＳＣＦネーミング方式
この場合、ＳＣＦは幾つかの下層のネットワークを代表しており、それらのすべてを特定する必要がある。また、各ネットワークの所有者、即ち各ネットワークのネットワークオペレータを認識する必要がある。
本発明のこの実施形態では、ＳＣＦが情報交換している下層ネットワークを示す、"Underlying Network"と呼ばれるジェネラルサービスプロパティが導入される。このプロパティ値は、各々が<Operator, network> のペアを含む文字列群である。例えは、ユーザステータスＳＣＦの場合、その値は[<Telenor, GSM>, <Netcom, GSM>, <Telenor, IP-based(SIP)>]となり得る。これは図７の例に示されている。図７では、アプリケーションが、ＯＳＡフレームワーク内の所望のサービスプロパティを使用して、ＧＳＭネットワーク及びＩＰベースネットワーク内のユーザステータスＳＣＦを選択する（とトレードする）。これが図７において１で示されている。その後、ＯＳＡフレームワークは、サービス取引き（service trading ）に同意し、ＧＳＭ／ＵＭＴＳネットワークとＩＰベースネットワークの両方と情報交換できるユーザステータスＳＣＦの新しいインスタンスを作り、図７において１．１「新」によって示されているように、このユーザステータスインスタンスへのリファレンスをアプリケーションに返す。
Ｂ．ディスパッチング機能
本実施形態では、各ＳＣＦは、下層のネットワークの全てに対して責任があり、従って、ＳＣＦのインターフェースクラスが、各ネットワークについて全てのインターフェースにマッピングされる必要がある（一つから多数へのマッピング）。例えば、コールコントロールのインターフェースクラスは、ＯＳＡのコールコントロールＡＰＩとＰＳＴＮ／ＩＳＤＮネットワークのためのＳＳ７ ＩＮＡＰとの間のマッピング、ＯＳＡのコールコントロールＡＰＩとＩＰベースネットワークのためのＳＩＰプロトコルとの間のマッピング、及びＯＳＡのコールコントロールＡＰＩとＧＳＭ／ＵＭＴＳネットワークのためのＣＡＭＥＬとの間のマッピングを実施しなければならない。これが図８に示されている。
各下層ネットワーク内のネットワーク機器は種々のベンダーによって開発される可能性がある（例えば、ＧＳＭのためのＩＮシステムはＥｒｉｃｓｓｏｎ、Ａｌｃａｔｅｌによって開発され、ＳＩＰサーバはＨｏｔＳｉｐ、Ｄｙｎａｍｉｃｓｏｆｔ、Ｕｂｉｑｕｉｔｙなどによって開発されている）ため、幾つかの問題が生じる。各ベンダーは、ＯＳＡインターフェースクラスと彼らのネットワーク機器へのインターフェースとの間のマッピングが実施できるだけである。更に、上記の解決策は柔軟性に欠ける。何故なら、一人のベンダーは、ＯＳＡインターフェースクラスから全ての不均質ネットワーク内の全てのネットワーク固有インターフェースへのマッピングを開発しなければならないためである。
本発明のこの実施形態では、ＯＳＡに対して幾つかの必要な変更を加えている。ＳＣＦが二つの別々のコンポーネントに分割されている。
・一方のコンポーネントがＯＳＡインターフェースクラスから下層ネットワークのインターフェースへのマッピングを実施する。
・他方のコンポーネントが、アプリケーションからの要求を、正しい下層ネットワークに接続された正しいＳＣＦへディスパッチする（送る）責任を負う。
ＳＣＦを二つのコンポーネントに分割することにより、ネットワーク機器のベンダーは、ＯＳＡインターフェースクラスから彼らのネットワーク機器へのマッピング（一対一のマッピング）を開発するだけでよく、アプリケーションは、ＳＣＦが多くの不均質ネットワークと情報交換するのにも関わらず、一つのＳＣＦだけを取り扱えばよい。インターフェースマッピングを実施するコンポーネントは、特にＯＳＡで明記されたＳＣＦと同一である。
アプリケーションからの要求をディスパッチするコンポーネントである「ＳＣＦディスパッチャ」は、ＯＳＡに対する追加の機能である。勿論、アプリケーションへのインターフェースは、ＯＳＡ仕様において各ＳＣＦについて明記されているものと同じでなければならない。
更に、二つのＳＣＦコンポーネントの間には「登録インターフェース」が設けられており、各ネットワークのためのＳＣＦが「ＳＣＦディスパッチャ」に登録することを可能にする。ネットワーク固有ＳＣＦは、「ＳＣＦディスパッチャ」にそれ自身へのリファレンスとそれがサポートするサービスプロパティを提供する。従って、「ＳＣＦディスパッチャ」は、ネットワーク固有ＳＣＦの能力についての知識を保持し、従ってそれ自身をＯＳＡフレームワークに登録し、それがサポートするサービスプロパティ、即ち、各ネットワーク固有ＳＣＦインスタンスによって提供される全てのサービスプロパティの全体を提供することができる。
各アプリケーションのためにＳＣＦディスパッチャのインスタンスが作られる。どの下層ネットワークがアプリケーションによるサービスキャパビリティの使用を許容するかに依存して、各ネットワークのためのＳＣＦの対応するインスタンスが作られる。ＳＣＦディスパッチャインスタンスは、これらのＳＣＦインスタンス全てのリファレンスを記憶する。また、「ＳＣＦディスパッチャ」は、アプリケーションからの要求が到着した時に、正しいＳＣＦインスタンスを選択するための機能も有する。そのような機能の必要性を示すために、アプリケーションがＵＳ ＳＣＦに対してユーザのステータスを要求する場合を想定する。ＧＳＭネットワーク、ＰＳＴＮ／ＩＳＤＮネットワーク、及びＩＰベースネットワーク（ＳＩＰ）のためのＵＳ ＳＣＦをアプリケーションが使用できるようにするサービスレベルアグリーメントの表示をアプリケーションが有している。ＵＳ ＳＣＦ（「ＵＳ ＳＣＦディスパッチャ」）は、三種類の下層ネットワークと情報交換することが可能である。従って、それは、要求を正しいＵＳ ＳＣＦインスタンスにディスパッチするために、どの下層のネットワークが要求に関連しているかを決定できなければならない。これは、前の実施形態１に記載した要件、即ち、端末ＩＤに基づいて正しいＳＣＦインスタンスを選択するという要件と実際には同じである。
従って、「ＳＣＦディスパッチャ」は、端末ＩＤからＳＣＦインスタンスを問い合わせるために端末ＩＤアドミニストレータ（ＴＡ）を使用しなければならない。これにより、「ＳＣＦディスパッチャ」は、端末ＩＤアドミニストレータへの問い合わせ結果を用いて、アプリケーションからの要求を正しいＳＣＦインスタンスにディスパッチできる。なお、ネットワークＳＣＦからの応答や報告は全て、対応するアプリケーションに送られる前に「ＳＣＦディスパッチャ」を通過することに注意されたい。これが図９に示されている。
Ｃ．端末ＩＤに基づくＳＣＦインスタンスの選択
図９にも示されているように、端末ＩＤアドミニストレータが必要とされる。端末ＩＤアドミニストレータ（ＴＡ）は、アプリケーションとＳＣＦインスタンスとの間のマッピング、ＳＣＦインスタンスとネットワークとの間のマッピング、そして最後にネットワークと端末ＩＤとの間のマッピングを含むデータベース／ディレクトリサービスを有している。図１０は端末ＩＤアドミニストレータによって保持されている関係を示す。図面中の数字は基数を示す。１は１だけを示し、＋１は１以上を示す。
端末ＩＤアドミニストレータは、ネットワークオペレータが、変化が起きた時にそれを登録できるようにする。また、端末ＩＤアドミニストレータは、下記のメソッドを含むＳＣＦディスパッチャへのインターフェースを提供する。
getSCFinstance(<terminalID>,<applicationID><SCFreference>)
<terminalID>は、アプリケーションが取り扱われる端末ＩＤ、
<applicationID> は、要求しているアプリケーションのＩＤ、
<SCFreference>は、ＳＣＦインスタンスによって返されるＳＣＦインスタンスのリファレンスである。
このメソッドにより、ＳＣＦディスパッチャは、所定の端末のための正しいＳＣＦインスタンスのリファレンスを得て、そのＳＣＦインスタンスへ要求を送ることができる。
本第２実施形態における端末ＩＤアドミニストレータは見ることができず、第１実施形態と同じ方法でアプリケーションに利用することもできないが、例えば、ＳＣＦディスパッチャのためのフレームワーク内のみに存在している。
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいると仮定する。アプリケーションは、<terminalID>=12345678 とＳＣＦの名称 <SCFtype> ="User Status" を含む問い合わせをＣＣ ＳＣＦディスパッチャに送出する。ＣＣ ＳＣＦディスパッチャは、要求（getSCF instance）を、端末ＩＤからＳＣＦインスタンスへのマッピングを介して端末ＩＤアドミニストレータに送る。これに応答して、ＣＣ ＳＣＦディスパッチャは、要求した端末ＩＤが属しているユーザステータスＳＣＦに対する目的とするリファレンスを受け取る。これにより、ディスパッチャは、下層のネットワークを気にすることなく、正しいＵＳ ＳＣＦを使用できる。
実施形態３：ネットワーク毎のフレームワーク
本実施形態では、一つのＯＳＡフレームワークが一つの下層ネットワークのみを受け入れる。例えば、ＧＳＭネットワーク内のＯＳＡフレームワークは、ＧＳＭネットワーク内のサービスキャパビリティについてのみ責任があり、ＧＳＭネットワーク内の全てのＳＣＦ（図１１に示すＣＣ ＳＣＦ及びＵＳ ＳＣＦ）の全てを制御する。図１１に示すようにＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワークについても同様である。
各ＳＣＦが各ネットワークに固有のインターフェースにマッピングされる。例えば、ＧＳＭネットワークのＣＣ ＳＣＦは、ＧＳＭネットワーク内でコールコントロールを出すインターフェースにマッピングされる。ＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワーク内のＣＣ ＳＣＦについても同様である。これにより、アプリケーションは、各ＯＳＡフレームワークを個別にアドレス指定することにより、全ての下層ネットワーク内のサービスキャパビリティを使用できる。
追加の機能
Ａ．端末ＩＤに基づくフレームワークの選択
アプリケーションは、どのフレームワークがある端末ＩＤをアドレス指定しているのかを知る必要がある。本実施形態では、各フレームワークが、ＳＣＦ「端末ＩＤインフォメータ」を有している。端末ＩＤインフォメータＳＣＦは、フレームワークによってサポートされている下層ネットワークに端末が属しているか否かをアプリケーションが問い合わせることを可能にするインターフェースを有している。この問い合わせ手続きは以下のように表すことができる。
TerminalInfoReq <terminal ID, belong(True/False)>
端末ＩＤは、真(True)又は偽(False) と共に、ＳＣＦインターフェースからＯＳＡフレームワークを介して、問い合わせをしたアプリケーションに返される。端末がフレームワークに属していない場合、手続きは偽(False) を返し、アプリケーションは、真(True)を回答として受信するまで、他のフレームワークを問い合わせることで手続きを進める。この様にして、アプリケーションは所望のＳＣＦを選択して使用できる。真／偽はブール論理によって表される。
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいる。アプリケーションは、<terminalID>=12345678 とＳＣＦの名称 <SCFtype> ="User Status" を含む問い合わせをＯＳＡフレームワークに送出する。ＯＳＡフレームワークはその要求を端末ＩＤインフォメータＳＣＦに送る。端末ＩＤがそのフレームワーク中に存在していた場合、インフォメータＳＣＦインターフェースがＯＳＡフレームワークに真を返す。これにより、アプリケーションは所望のＳＣＦを選択して使用する。偽が返された場合、アプリケーションは、別のＯＳＡフレームワークに要求を送る。
実施形態４：異なるＯＳＡフレームワーク間の通信と協調
本実施形態では、第３実施形態と同様に、一つのＯＳＡフレームワークは単一の下層ネットワークしか受け入れない。しかし、フレームワーク間での通信と協調が可能となっている。フレームワーク間の相互運用可能性が確立され、多くの不均質ネットワークからのサービスキャパビリティを利用するためには、アプリケーションは一つＯＳＡフレームワークだけと取引きをすればよい（図１２参照）。
アプリケーションは、「ホーム」フレームワークのＳＣＦを使用できるだけでなく、それらの「ホーム」フレームワークに向けて要求を出すだけで、他のネットワーク上の他のフレームワークに属しているＳＣＦも使用できる。フレームワークは、その後、実際のフレームワークと通信して、ＳＣＦインスタンスのリファレンスを問い合わせる。そのようなインスタンスがアプリケーションのために作られていない場合には、「外の（foreign）」フレームワークがインスタンス作り、そのリファレンスを「ホーム」フレームワークに返す。その後、「ホーム」フレームワークは要求しているアプリケーションにリファレンスを返す。サービスキャパビリティフィーチャのために、アプリケーションは、ＧＳＭ、ＰＳＴＮ、ＩＰなどの種々のネットワークを表す幾つかのＳＣＦインスタンスのリファレンスを有し得る。従って、各ＳＣＦインスタンスのサービスプロパティは区別されている。端末ＩＤアドミニストレータは、端末ＩＤが与えられると、使用すべきＳＣＦのリファレンスを返す。これが図１３に示されている。図１３は、ＧＳＭネットワークとＩＰベースネットワークの両方におけるＵＳ ＳＣＦの使用を示す。
アプリケーションが、ＧＳＭネットワーク内のフレームワークを使用して、ＧＳＭネットワーク内のユーザステータスＳＣＦ及びＩＰベースネットワーク内のユーザステータスＳＣＦを選択する場合を想定する（図１３の１．及び２．）。ＧＳＭネットワーク内のＵＳがＯＳＡによって定義されたような通常の方法でトレードされる。その後、ＧＳＭネットワーク内のフレームワークは、アプリケーションが提供したサービスプロパティを使用してＩＰベースネットワーク内のフレームワークに対して新たなＵＳ ＳＣＦインスタンスを作ることを依頼し、ＵＳインスタンスへのリファレンスをアプリケーションに返す。（リファレンスは、作られたＳＣＦインスタンスへのポインタである。実際の実施形態は、その実施に依存する）。本実施形態におけるＯＳＡインターフェースは、フレームワークが他のフレームワーク内のＳＣＦを選択すると共に、ＳＣＦインスタンスへのリファレンスを受け取れるようにするための機構を含んでいる。図１３では、この機構が２−１であり、ＧＳＭネットワーク内のＯＳＡフレームワークが、ＩＰベースネットワーク内のＯＳＡフレームワーク内のＯＳＡフレームワーク通信ＡＰＩ内のメソッドを使用して、ＩＰベースネットワーク内のＵＳ ＳＣＦを選択（トレード）する。その後、フレームワークは、ＯＳＡ標準内に明記された通常のトレーディング機能を使用して、ＳＣＦインスタンスに対するリファレンスをアプリケーションに返す。図１３の２−２おいては、ＩＰベースネットワークのＯＳＡフレームワークがサービストレーディングに同意し、ＩＰベースネットワークのためのＵＳ ＳＣＦの新しいインスタンスを作り、このＳＣＦに対するリファレンスをＧＳＭネットワーク内のＯＳＡフレームワークに返す。その後、このフレームワークは、リファレンスをＳＣＦアプリケーションに返す。
追加機能
Ａ．フレームワーク間の通信
種々の下層ネットワークのためのＯＳＡフレームワークは、相手のことを互いに知っており、アプリケーションの役に立つために協調する。異なるフレームワーク間でどのようなＳＣＦを提供するかは事前に決められる。更に、以下の機能がＯＳＡフレームワークに含められる。
フレームワーク間の認証
不正使用や攻撃を防ぐために、フレームワーク間での更なる動作を許可する前にフレームワークで強力な相互認証手続きを行うことが好ましい。この認証手続きは、当技術分野で知られている任意のものでよい。
フレームワーク間のサービストレーディング
本発明のこの実施形態では、各フレームワークがインターフェースで拡張され、これにより他のフレームワークが当該フレームワークが提供するＳＣＦについての情報を要求できるようにしている。従って、インターフェースは以下のＳＣＦ要求メソッドを含んでいる。
SCFrequest（<requestingFrameworkID>, <ListOfSCFoffered> ）
<requestingFrameworkID> は、要求側フレームワークの識別情報であり、
<ListOfSCFoffered>は、要求側フレームワークに提供されるＳＣＦのリストである。このリストは、要求側フレームワークによって異なる。
提供されたＳＣＦのリストを受信すると、要求側ＯＳＡフレームワークは、「ローカル」登録ＳＣＦと同様に、提供されたＳＣＦのリストを保存する。このようにして、要求側ＯＳＡフレームワークは、要求しているアプリケーションにリストを提示できる。また、要求側ＯＳＡフレームワークは、どのＯＳＡフレームワークがどのＳＣＦを有しているかについての情報を保存している。
フレームワーク間のサービス利用
各フレームワークがインターフェースで拡張され、これにより他のフレームワークが当該フレームワークのＳＣＦを利用できるようにしている。インターフェースは以下のメソッドを含んでいる。
getSCFinstance（<serviceID>, <serviceProperties>, <reference>, <frameworkID>, <applicationID>)
<serviceID> は、要求しているＳＣＦのＩＤ、
<serviceProperties> は、要求しているフレームワークに属しているアプリケーションによって特定されたプロパティのリスト、
<reference> は、ＳＣＦインスタンスのリファレンス、
<frameworkID> は、要求しているフレームワークのＩＤ、
<applicationID> は、要求しているアプリケーションのＩＤである。
このメソッドにより、ＯＳＡフレームワークは、他のフレームワークに対して、そのアプリケーションによって依頼されたサービスプロパティに従って、ＳＣＦインスタンスのリファレンスを返すことができる。そのようなインスタンスが存在しない場合、フレームワークはインスタンスを作る。ＯＳＡフレームワークは、受信したリファレンスを各ＯＳＡフレームワークに保存しなければならない。ＯＳＡフレームワークは、ＳＣＦインスタンスのリファレンスとそれらの対応するフレームワークのリストを有していなければならない。上述したインターフェースを用いたＯＳＡフレームワーク間の通信が図１４に示されている。
Ｂ．端末ＩＤアドミニストレータ
端末ＩＤが与えられた場合、アプリケーションは、どのＳＣＦインスタンスを使用すべきかを知る必要がある。何故なら、端末は異なるネットワークに属することがあり、従って異なるＳＣＦインスタンスによって取り扱われる可能性があるからである。ここでも、アプリケーションは、フレームワークの支援を必要とする。本実施形態では、各フレームワークに、ＳＣＦとして実施された端末ＩＤアドミニストレータ（ＴＡ）が設けられている。このＴＡ ＳＣＦは実施形態１で記載したものと同様である。更に、ＴＡ ＳＣＦには、各ＯＳＡフレームワークがサポートする端末ＩＤの範囲が供給される。（端末ＩＤは、例えば、電話番号、ＩＰアドレス、又は名前である。）これらは、ＴＡ間での情報交換を可能するか、又は共通の情報データベースを設けることにより、オフラインインストレーションなどの幾つかの方法で供給できる。
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいる。アプリケーションは、<terminalID>=12345678 とＳＣＦの名称 <SCFtype> ="User Status" を含む問い合わせをＯＳＡフレームワークに送出する。ＯＳＡフレームワークはその要求を端末ＩＤアドミニストレータＳＣＦに送る。端末ＩＤがそのフレームワーク中に存在していた場合、アプリケーションは所望のＳＣＦを選択して使用する。要求された端末ＩＤがＯＳＡでサポートされる範囲に入っていない場合、ＯＳＡフレームワークは、ＳＣＦインスタンスのリファレンス及びそれらの対応するフレームワークのフレームワークリストに従って、別のフレームワークを要求する。
本発明の好適な実施形態について記載したが、本発明の概念を含む他の実施形態も使用可能であることは当業者には明らかであろう。本発明の上記及びその他の実施例は例示を目的とするものであって、本発明の実際の範囲は添付の請求の範囲から決定すべきものである。
ＯＳＡを介してアプリケーションが移動通信ネットワークにアクセスする現在のアーキテクチャを左側に示し、本発明の実施形態による不均質ネットワークのための拡張されたＯＳＡを右側に示す。 共用のフレームワークを使用しているが各ネットワークが独自のＳＣＦを有している、本発明の第１実施形態による不均質ネットワークのための拡張されたＯＳＡを示す。 本発明の第１実施形態におけるＴＡによって保持されている関係を示す。 本発明の第１実施形態における端末ＩＤアドミニストレータの幾つかのプロパティを示す。 本発明の第１実施形態における端末アドミニストレータＳＣＦの使用を示す。 全ての下層ネットワークを受け入れる共用ＳＣＦと共用フレームワークを使用しての本発明の実施を示す図である。 本発明の更なる実施形態によるＳＣＦの使用を示す。 本発明の第２の実施形態の実施の例を示す。 本発明の第２の実施形態によるＯＳＡ内のディスパッチャ機能の図である。 本発明の第２の実施形態による端末ＩＤアドミニストレータによって保持される関係を示す。 下層ネットワーク毎に一つのフレームワークを使用した本発明の第３の実施形態を示す。 本発明の第４の実施形態によるフレームワーク間における通信と協調を示す。 図１２に示す実施形態による、ＧＳＭネットワークとＩＰベースネットワークの両方におけるＵＳ ＳＣＦの使用を示す。 本発明の第４の実施形態によるＯＳＡフレームワーク通信インターフェースを介してのフレームワーク間における通信を示す。

Claims (40)

  1. 複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する遠隔通信システムであって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する少なくとも一つのフレームワークを備えたオープンサービスアクセス（ＯＳＡ）エクステンションを含むシステム。
  2. 端末ＩＤに基づいて必要なネットワークを選択するための情報をアプリケーションに提供する端末ＩＤアドミニストレータを含む、請求項１に記載のシステム。
  3. アプリケーションのための拡張されたオープンサービスアクセスを複数の不均質ネットワークに提供する遠隔通信システムであって、前記ネットワークのための唯一の共用フレームワークと、ネットワーク毎に設けられネットワーク固有のインターフェースを提供する一つのサービスキャパビリティフィーチャ（ＳＣＦ）とを含むシステム。
  4. サービスキャパビリティフィーチャは、どの下層（underlying）ネットワークとＳＣＦが情報交換しているかを示すジェネラルサービスプロパティを含む、請求項３に記載の遠隔通信システム。
  5. ジェネラルサービスプロパティは、<operator, network> のペアを含む文字列である、請求項３に記載の遠隔通信システム。
  6. 端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する端末ＩＤアドミニストレータを含む、請求項３に記載の遠隔通信システム。
  7. 端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間のマッピング情報を含むデータベース／ディレクトリを含む、請求項６に記載の遠隔通信システム。
  8. 端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間のマッピング情報、サービスキャパビリティフィーチャのインスタンスとネットワークとの間のマッピング情報、及びネットワークと端末ＩＤとの間のマッピング情報を含むデータベース／ディレクトリ含む、請求項６又は７に記載の遠隔通信システム。
  9. 端末ＩＤアドミニストレータは、リアルタイムで更新可能である、請求項６に記載の遠隔通信システム。
  10. アプリケーションの問い合わせのためのインターフェースクラスを含む端末アドミニストレータ（ＴＡ ＳＣＦ）を含み、要求しているアプリケーションと端末ＩＤアドミニストレータとの間のインターフェースを提供する、請求項６に記載の遠隔通信システム。
  11. 端末アドミニストレータ（ＴＡ ＳＣＦ）は、アプリケーションに対して、
    −所定の端末のための正しいサービスキャパビリティフィーチャのインスタンスについてのリファレンスを得ること、
    −幾つかの端末ＩＤについてのサービスキャパビリティインスタンスのリファレンスを同時に問い合わせること、
    −所定の端末のネットワークＩＤを得ること、
    −そのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ること、及び
    −特定のネットワーク上のそのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ること
    を可能にするプログラム手段を含む、請求項４に記載の遠隔通信システム。
  12. アプリケーションのための拡張されたオープンサービスアクセスを複数の不均質ネットワークに提供する遠隔通信システムであって、前記ネットワークのための唯一の共用フレームワークと、ネットワークのために設けられ共用ネットワークインターフェースを提供する共用サービスキャパビリティフィーチャ（ＳＣＦ）とを含むシステム。
  13. サービスキャパビリティフィーチャは、どの下層ネットワークとＳＣＦが情報交換しているかを示すジェネラルサービスプロパティを含む、請求項１２に記載の遠隔通信システム。
  14. ジェネラルサービスプロパティは、各々が<operator, network> のペアを含む文字列群である、請求項１３に記載の遠隔通信システム。
  15. インターフェースは、アプリケーションと下層のネットワークのインターフェースとの間の一から多数へのマッピングを提供するサービスキャパビリティインターフェースクラスを含む、請求項１２に記載の遠隔通信システム。
  16. 共用サービスキャパビリティフィーチャは、インターフェースクラスからネットワークインターフェースへマッピングを行うマッピング手段と、要求をアプリケーションから正しいネットワークインターフェースクラスに送るディスパッチャ手段とを含む、請求項１２に記載の遠隔通信システム。
  17. ディスパッチャへのネットワークの登録を可能にする、マッピング手段とディスパッチャ手段との間の登録インターフェースを含む、請求項１６に記載の遠隔通信システム。
  18. ディスパッチャ手段は、アプリケーションから到着する要求のために正しいサービスキャパビリティフィーチャ（ＳＣＦ）を選択する選択手段を含む、請求項１６に記載の遠隔通信システム。
  19. 端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャ（ＳＣＦ）を選択する端末ＩＤアドミニストレータを含む、請求項１２に記載の遠隔通信システム。
  20. 端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含む、請求項１５に記載の遠隔通信システム。
  21. 端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含む、請求項１９又は２０に記載の遠隔通信システム。
  22. 端末ＩＤアドミニストレータは、リアルタイムで更新可能である、請求項１９に記載の遠隔通信システム。
  23. 端末ＩＤアドミニストレータ（ＴＡ ＳＣＦ）は、ＳＣＦディスパッチャ手段のためのインターフェースを提供し、前記端末ＩＤアドミニストレータは、
    −そのＳＣＦインスタンスに要求を送るために、所定の端末のための正しいサービスキャパビリティインスタンスについてのリファレンスを得るプログラム手段を含み、これには
    −アプリケーションが取り扱っている端末ＩＤを得ること、
    −要求しているアプリケーションのアプリケーションＩＤ、及びＳＣＦインスタンスによって返されたサービスキャパビリティフィーチャインスタンスのリファレンスを得ることが含まれる、請求項１９に記載の遠隔通信システム。
  24. アプリケーションのための拡張されたオープンサービスアクセスを複数の不均質ネットワークに提供する遠隔通信システムであって、ネットワーク毎に設けられたフレームワークを含み、各フレームワークは，前記ネットワークのためのサービスキャパビリティフィーチャ（ＳＣＦ）を有し、ネットワーク固有のインスタンスを提供するシステム。
  25. 各フレームワークは，端末ＩＤに基づくネットワーク選択に関連して、アプリケーションにサービスキャパビリティ機能を提供する端末ＩＤインフォメータを含んでいる、請求項２４に記載の遠隔通信システム。
  26. 端末ＩＤインフォメータは、要求しているアプリケーションに、<terminal ID, belong(True/False)>のペアを含む文字列を返す、請求項２５に記載の遠隔通信システム。
  27. 各フレームワークは、他のフレームワーク内のサービスキャパビリティフィーチャを選択し、このサービスキャパビリティフィーチャに対するリファレンスを受け取ることを可能にする機構を含んでいる、請求項２４に記載の遠隔通信システム。
  28. フレームワークのための選択可能なサービスキャパビリティフィーチャは予め定義されている、請求項２７に記載の遠隔通信システム。
  29. 全てのフレームワークが相互認証手続きを含む、請求項２４に記載の遠隔通信システム。
  30. 各フレームワークは、前記フレームワークが提供するサービスキャパビリティフィーチャについての情報を他のフレームワークが要求することを可能にする拡張されたインターフェースを含む、請求項２４に記載の遠隔通信システム。
  31. 拡張されたインターフェースは、要求しているフレームワークの識別情報を、前記フレームワークに提供された予め定義されたサービスキャパビリティフィーチャのリストと共に返す要求手続きと、あるフレームワークが、要求しているアプリケーションによって指定されたサービスプロパティに従って、サービスキャパビリティフィーチャインスタンスのリファレンスを返すことを他のネットワークに対して要求することを可能にする獲得手続きとを含む、請求項３０に記載の遠隔通信システム。
  32. 端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する端末ＩＤアドミニストレータを含む、請求項２４に記載の遠隔通信システム。
  33. 端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間でマッピング情報を含むデータベース／ディレクトリを含む、請求項３２に記載の遠隔通信システム。
  34. 端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間でマッピング情報を含むデータベース／ディレクトリ含む、請求項３２又は３３に記載の遠隔通信システム。
  35. 端末ＩＤアドミニストレータは、各フレームワークがサポートする端末ＩＤの範囲に関する情報を端末ＩＤアドミニストレータに提供する情報インターフェースを含む、請求項３２に記載の遠隔通信システム。
  36. 端末ＩＤアドミニストレータは、リアルタイムで更新可能である、請求項３２に記載の遠隔通信システム。
  37. ネットワークは少なくとも一つの遠隔通信ネットワークと少なくとも一つのコンピュータネットワークである、請求項１、３、１２、又は２４に記載の遠隔通信システム。
  38. 遠隔通信ネットワークは、移動通信、ＵＭＴＳ、ＧＳＭ、ＰＳＴＮ/ ＩＳＤＮなどの無線又は有線ネットワークである、請求項３７に記載の遠隔通信システム。
  39. コンピュータネットワークは、ＩＰ（有線）、無線ＬＡＮ、ブルートゥース又はハイパーＬＡＮ（無線）などのパケット式ネットワークである、請求項３７に記載の遠隔通信システム。
  40. 複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法であって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する、不均質ネットワークためのアプリケーションプログラミングインターフェース（ＡＰＩ）中の少なくとも一つのフレームワークを用いてオープンサービスアクセス（ＯＳＡ）エクステンションを実行することを含む方法。
JP2003513261A 2001-07-13 2002-07-12 オープンサービスアクセスのための拡張された遠隔通信システムアーキテクチャ Expired - Fee Related JP4077406B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US30478001P 2001-07-13 2001-07-13
PCT/NO2002/000260 WO2003007628A1 (en) 2001-07-13 2002-07-12 Extended telecommunication system architecture for open service access

Publications (2)

Publication Number Publication Date
JP2004535141A JP2004535141A (ja) 2004-11-18
JP4077406B2 true JP4077406B2 (ja) 2008-04-16

Family

ID=23177981

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003513261A Expired - Fee Related JP4077406B2 (ja) 2001-07-13 2002-07-12 オープンサービスアクセスのための拡張された遠隔通信システムアーキテクチャ

Country Status (10)

Country Link
US (1) US7660881B2 (ja)
EP (1) EP1407623B1 (ja)
JP (1) JP4077406B2 (ja)
CN (1) CN1543748B (ja)
AT (1) ATE378784T1 (ja)
CA (1) CA2453536A1 (ja)
DE (1) DE60223541D1 (ja)
ES (1) ES2296994T3 (ja)
NO (1) NO323264B1 (ja)
WO (1) WO2003007628A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030095566A1 (en) * 2001-11-20 2003-05-22 Bunting Roger L. Providing a camel based service to a subscriber terminal in a win network and vice versa
SE0203297D0 (sv) * 2002-11-05 2002-11-05 Ericsson Telefon Ab L M Remote service execution in an heterogenous network
GB0312009D0 (en) 2003-05-24 2003-07-02 Univ Strathclyde Management and control of telecommunication services delivery
EP1787437B1 (en) * 2004-09-06 2011-11-23 Telefonaktiebolaget LM Ericsson (publ) Multiple access communications over diverse access technologies
KR100609689B1 (ko) * 2004-12-20 2006-08-08 한국전자통신연구원 개방형 서비스 게이트웨이에서의 ｓｃｆ와 프로토콜간연동 시스템 및 방법
CN100421435C (zh) * 2005-11-30 2008-09-24 北京邮电大学 用于下一代网络、可动态扩展、开放接口技术的网关
CN101584192B (zh) * 2006-11-27 2013-10-30 艾利森电话股份有限公司 节点注册方法
US8046419B2 (en) * 2006-12-01 2011-10-25 Electronics And Telecommunications Research Institute Method of processing open asynchronous application service event and open web service gateway implementing the same
KR100901703B1 (ko) 2006-12-01 2009-06-08 한국전자통신연구원 개방형 비동기 응용 서비스 이벤트 처리 방법 및 이를구현한 개방형 웹서비스 게이트웨이
US8302017B2 (en) * 2008-03-05 2012-10-30 Microsoft Corporation Definition for service interface
US8079820B2 (en) 2008-12-18 2011-12-20 General Electric Company Blade module, a modular rotor blade and a method for assembling a modular rotor blade
CN101568099B (zh) * 2009-05-27 2011-02-16 华为技术有限公司 实现智能业务的方法及通信系统
EP4017041B1 (en) * 2017-03-20 2023-09-27 InterDigital Patent Holdings, Inc. Service capability exposure at the user equipment

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6282575B1 (en) * 1997-12-11 2001-08-28 Intel Corporation Routing mechanism for networks with separate upstream and downstream traffic
US6463470B1 (en) * 1998-10-26 2002-10-08 Cisco Technology, Inc. Method and apparatus of storing policies for policy-based management of quality of service treatments of network data traffic flows
US6940847B1 (en) * 1999-01-15 2005-09-06 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing access to service nodes from entities disposed in an integrated telecommunications network
EP1107550B1 (en) * 1999-12-06 2005-11-09 Alcatel A terminal to execute a terminal application
US6615276B1 (en) * 2000-02-09 2003-09-02 International Business Machines Corporation Method and apparatus for a centralized facility for administering and performing connectivity and information management tasks for a mobile user
AU2001253043A1 (en) * 2000-03-31 2001-10-15 Coppercom, Inc. Telecommunications system and methods
US20020013827A1 (en) * 2000-05-18 2002-01-31 Edstrom Claes G.R. Personal service environment management apparatus and methods
US8699472B2 (en) * 2000-05-24 2014-04-15 Nokia Corporation Common charging identifier for communication networks
AU2000268392A1 (en) * 2000-08-16 2002-02-25 Nokia Corporation System and method for the provision of services over different networks
US20020026473A1 (en) * 2000-08-31 2002-02-28 Telefonaktiebolaget Lm Ericsson (Publ) Application-programming-interface-based method and system including triggers
US7454505B2 (en) * 2001-01-25 2008-11-18 International Business Machines Corporation Communication endpoint supporting multiple provider models
US20020154755A1 (en) * 2001-04-23 2002-10-24 Telefonaktiebolaget L M Ericsson Communication method and system including internal and external application-programming interfaces

Also Published As

Publication number Publication date
ATE378784T1 (de) 2007-11-15
DE60223541D1 (de) 2007-12-27
ES2296994T3 (es) 2008-05-01
US7660881B2 (en) 2010-02-09
CN1543748B (zh) 2010-09-22
CA2453536A1 (en) 2003-01-23
EP1407623A1 (en) 2004-04-14
NO323264B1 (no) 2007-02-19
CN1543748A (zh) 2004-11-03
NO20023372D0 (no) 2002-07-12
NO20023372L (no) 2003-01-14
EP1407623B1 (en) 2007-11-14
JP2004535141A (ja) 2004-11-18
WO2003007628A1 (en) 2003-01-23
US20040242186A1 (en) 2004-12-02

Similar Documents

Publication Publication Date Title
EP3669275B1 (en) A method of discovering services provided by a network repository function
US10455383B2 (en) Method and unit used to determine useable services
EP1334639B1 (en) Optimal gateway discovery while roaming
KR101143667B1 (ko) 인터넷 멀티미디어 서브시스템에서의 라우팅 방법 및 ｉｍｓ 구현 시스템
US7426737B2 (en) Method and apparatus for operating an open API network having a proxy
KR100661313B1 (ko) 평생 번호를 사용한 이동성 제공이 가능한 ｓｉｐ 기반의멀티미디어 통신 시스템 및 이동성 제공 방법
JP4077406B2 (ja) オープンサービスアクセスのための拡張された遠隔通信システムアーキテクチャ
KR20050057638A (ko) 통신 시스템에서 사용자의 진짜 신원을 숨기는 방법 및장치
CN113826424B (zh) 用于向网络提供外部业务的实体
EP1442583A1 (en) Maintenance of third party service&#39;s subscription information
KR20060111172A (ko) 발신자 정보 제공 방법, 이를 위한 서버 및 시스템
EP3937521A1 (en) Method for an improved exchange and/or interworking functionality between a first mobile communication network and a second mobile communication network, system, network exchange function, program and computer program product
US8001234B2 (en) Method and server for coordination of telecommunication services
US20080139221A1 (en) System for providing address using geocoding application programming interface in open service platform
JP2005236670A (ja) セッション確立、セッション確立処理装置及びプログラム
WO2022093085A1 (en) Obtaining information pertaining to a network function in lawful interception
KR101659326B1 (ko) ＶｏＩＰ 번호이동 가입자의 ＥＮＵＭ 가입자 정보를 활용한 번호이동가입자 정보 생성 방법 및 장치
KR100748089B1 (ko) 가입자 데이터 개방을 통한 개인 정보 제공 방법 및 시스템
JP2000196679A (ja) 下位ネットワ―クから独立して新しいサ―ビスを開発できるゲ―トウェイ
KR100628708B1 (ko) 자동 통화 연결 방법 및 장치
KR100863209B1 (ko) 단말기 식별을 통한 공통 경로 접속 시스템 및 그 방법
JP2002314721A (ja) 低額通信接続システム，低額通信接続方法，通信接続プログラムおよびそのプログラム記録媒体
KR20020091217A (ko) 제 1 및 제 2 통신 엔티티 사이에 통신을 설정하는 방법과시스템
KR20080114633A (ko) 단말기 식별을 통한 공통 경로 접속 시스템 및 그 방법
JP2005218129A (ja) パケット交換網における音声通信端末装置および発呼方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20041217

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20061127

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080129

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080131

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110208

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120208

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees