JP2012514363A - 2層の(bi−level)アドレス指定スキームを用いて通信をルーティングするための方法および通信ノード - Google Patents
2層の(bi−level)アドレス指定スキームを用いて通信をルーティングするための方法および通信ノード Download PDFInfo
- Publication number
- JP2012514363A JP2012514363A JP2011542901A JP2011542901A JP2012514363A JP 2012514363 A JP2012514363 A JP 2012514363A JP 2011542901 A JP2011542901 A JP 2011542901A JP 2011542901 A JP2011542901 A JP 2011542901A JP 2012514363 A JP2012514363 A JP 2012514363A
- Authority
- JP
- Japan
- Prior art keywords
- network
- destination
- identification information
- visited
- user address
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/64—Distributing or queueing
- H04Q3/66—Traffic distributors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0075—Details of addressing, directories or routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/005—Personal communication services, e.g. provisions for portability of subscriber numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13034—A/D conversion, code compression/expansion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13097—Numbering, addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13102—Common translator
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13141—Hunting for free outlet, circuit or channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13298—Local loop systems, access network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13383—Hierarchy of switches, main and subexchange, e.g. satellite exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13389—LAN, internet
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
方法および通信ノードが、相互接続オペレータネットワーク経由で通信をルーティングするために提供される。これらの通信は、個人および/または組織間でルーティング可能である。典型的には、これらの通信は、データベース(410)内の情報に基づいてルーティングされ、セッション開始プロトコル(SIP)通信の中に記憶される。
Description
本書の例示的実施形態は、一般にシステムとデバイスとソフトウェアと方法とに関し、より詳細には、相互接続ネットワークを通ってメッセージをルーティングするためのメカニズムおよび技法に関する。
技術的能力が拡大を続けるのにつれて、通信の選択肢は多様化してきた。例えば、この30年余りの間に通信業界では個人間の通信が進化し、以前は家庭にダイヤル式電話が1台しかなかったのに、今では家庭には電話とケーブルと、および/または、音声とデータとの両方に対応する光ファイバ回線とが複数ある。さらに、携帯電話およびWi−Fiによって、通信に移動要素が加わった。同様に娯楽業界では、30年前にはテレビ用のフォーマットは1つしかなく、このフォーマットが電波で送信され、家庭にあるアンテナを介して受信された。これが進化して、例えばSDTV(standard definition television:標準画質テレビ)、EDTV(enhanced definition TV)、およびHDTV(high definition TV:高精細度テレビジョン)のように画質の標準が多様化しただけでなく、ケーブルや衛星というように、これらの多様なテレビジョン表示フォーマットを配信するためのシステムも多様化した。さらに、これらの2つの業界の間で各種のサービスが成長してオーバラップするようになってきた。これらのシステムが両方の業界において進化し続けるにつれて、サービス提供は融合し続けるであろうし、消費者は新たなサービスの利用可能性を期待できよう。また、これらのサービスの一部は、より多くの情報を処理して出力するための技術的能力に基づくことが予想される。
通信業界と娯楽業界との両方に影響を与えるもう1つの関連技術は、相互接続ネットワークである。また、これらの通信ネットワークと関連の通信ストリームとの物理的構造の進化によって、より多量のデータフローを処理できるようになってきた。サーバは、かつてないほど多量のメモリを有し、これまで以上の高い帯域幅を有する通信リンクが存在し、プロセッサは以前より高速かつ高性能であり、そして、これらの要素を活用するプロトコルが存在する。これらの通信ネットワークは、ユーザと企業とを結びつけるものであれば、いかなるネットワークであってもよい。消費者によるこれらのネットワークの利用が増加すれば、この増加は、サービス提供のための、相互接続されうるより多くのネットワークの創造を促す可能性がある。これらのサービスには、例えば、IPTV(Internet Protocol television:IPデータパケットを用いるネットワーク経由でテレビ番組を配信するシステムまたはサービスのことを言う)と、インターネットラジオと、ビデオ・オン・デマンド(VoD)と、ライブイベントと、VoIP(Voice over IP:IP電話)と、その他の単独で受信されるかまたはバンドルで一緒に受信されるウェブ関連サービスとが含まれてもよい。また、技術革新とサービス拡大とに伴って、新たなネットワークと通信プロトコル、例えば、IMS(Internet Protocol Multimedia Subsystem:IPマルチメディア・サブシステム)ネットワークおよびSIP(session initiation protocol:セッション開始プロトコル)が開発されて、これらの多様なサービスを改良し、それらの利用を進めた。
通信ネットワークの1つの特徴は、そのようなネットワークが多数存在し(それぞれがネットワークオペレータによって運用され)、そして、これらのネットワークが相互接続されていることである。この相互接続は、2つのネットワーク間で直接的であってもよいし、1つ以上の相互接続ネットワークまたは中継ネットワークを介して間接的であってもよい。これらのネットワークオペレータ各社は、その相互接続パートナ各社と業務上のSLA(サービス品質保証契約)を締結しているであろうし、1)宛先ユーザアドレスと、2)業務上のSLAと、に基づいてルーティングの決定を行う装置を有するであろう。宛先ユーザアドレスは或るユーザを識別し、このユーザは或るネットワークオペレータによってサービス提供される。宛先ユーザアドレスは、電話番号であってもよいし、何らかの電子メールのような形式のURI(uniform resource identifier:ユニフォーム・リソース・アイデンティファイア)であってもよい。後者の場合、宛先ユーザアドレスは、例えばjohn@bank.com、john@baldwin.orgのように、在圏ネットワークオペレータを即座に識別しないことがある。これは、要求をどうルーティングするかを発信側ネットワークオペレータが知ることの難しさを示す。
従って、多様な相互接続ネットワーク経由の通信を改良するためのデバイス、システム、および方法を提供することが望ましいであろう。
例示的実施形態によるシステムおよび方法が、とりわけ、多様な相互接続ネットワーク経由の通信を改良するための2層のアドレス指定スキームおよびルーティングスキームによって、このニーズなどに対応する。
例示的な一実施形態によれば、在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法が、前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを識別する情報を含む応答メッセージを受信するステップと、前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを識別する前記情報とを組み込むステップと、前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、を備える。
別の例示的実施形態によれば、通信ノードにおける、通信をルーティングするための方法が、各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、宛先ユーザアドレスに関連する各宛先識別情報が少なくとも1つの在圏ネットワークにも関連する、ステップと、宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの1つを含むクエリメッセージを受信するステップと、前記宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも1つの在圏ネットワークを判定するステップと、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも1つの在圏ネットワークを識別する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、を備える。
更に別の例示的実施形態によれば、通信ノードが、宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも1つの在圏オペレータネットワークと、の間のマッピングを記憶するメモリと、前記宛先ユーザアドレスに関連する前記宛先識別情報を受信する通信インタフェースと、前記宛先ユーザアドレスに関連する前記受信した宛先識別情報に関するルックアップを実行するプロセッサと、を備え、前記ルックアップは、セッション開始プロトコル(SIP)メッセージ中で前記宛先ユーザアドレスに関連する前記宛先識別情報を含むクエリメッセージを前記通信インタフェースが受信した場合に、前記少なくとも1つの在圏オペレータネットワークを結果として返し、前記通信インタフェースは、前記少なくとも1つの在圏オペレータネットワークを含む応答メッセージを送信する。
添付の図面は、本明細書に組み込まれて本明細書の一部を構成するものであって、1つ以上の実施形態を図解し、記述と共にこれらの実施形態を説明する。
例示的実施形態についての下記の記述は、添付の図面を参照する。別の図面における同じ参照番号は、同じかまたは類似の要素を示す。下記の詳細記述は、本発明を限定するものではない。そうではなく、本発明の範囲は、添付の請求項によって定義される。下記の実施形態は、話を簡単にするために、以下に記述する通信ネットワークの用語および構造に関して論じている。しかし、次に論じることになる実施形態は、これらのシステムに限定されるのではなく、他の既存の通信システムに適用されうる。
本明細書を通じて、「一実施形態」または「ある実施形態」または「例示的実施形態」への言及は、ある実施形態に関連して述べた特定の特徴、構造、または特性が、本発明の少なくとも1つの実施形態に含まれることを意味する。従って、本明細書の全体を通じていろいろな箇所で「一実施形態では」または「ある実施形態では」または「例示的実施形態では」という表現があっても、必ずしもそれらすべてが同じ実施形態に言及しているとは限らない。また、特定の特徴、構造または特性が、1つ以上の実施形態においていずれかの適切なやり方で組み合わされてもよい。
上記のように、各種の相互接続ネットワーク経由の通信を改良するためのデバイス、システム、および方法を提供することが望ましい。以下の例示的実施形態は、メッセージ、例えばSIP(セッション開始プロトコル)メッセージを、多様な相互接続ネットワーク経由で、例えば、IMS(インターネットプロトコル・マルチメディア・サブシステム)を用いるネットワーク経由で、ルーティングすることについて記述する。この議論について何らかの文脈を提供するために、図1に例示的な通信の枠組みを示す。
例示的実施形態によれば、図1は、複数の相互接続ネットワーク経由で中継される通信を使って、或るユーザが別のユーザ(または、企業内のリソース、例えば会社内のデバイスまたは人物)と通信することを示す。詳細には、例示的な通信の枠組み100は、ユーザ1 102が、例えばSIPメッセージを送信することができるデバイス、例えば移動電話およびコンピュータを使って企業/ユーザ2 110と通信することを示す。これらのSIPメッセージは、最初に発信側ネットワーク104を通って、次いで1つ以上の中継ネットワーク106を通って、次いで在圏ネットワーク108を通って送信される。しかし、これらの多様なネットワーク、例えば各種のパブリック通信ネットワークおよび相互接続ネットワークにおいてそのようなメッセージをアドレス指定するのに用いられるDNS(domain name system:ドメイン・ネーム・システム)の規則に関して多様な提案が存在し、それが、今度は、これらのSIPメッセージの正確かつ効率的な配信についての課題となる。また本書では、「発信側ネットワーク」、「発信側オペレータネットワーク」および「発信側ネットワークオペレータ」とは、呼を開始するデバイスが接続している発信側ネットワークのことを言う。また本書では、「在圏ネットワーク」、「在圏オペレータネットワーク」および「在圏ネットワークオペレータ」とは、エンドユーザにサービス提供し、呼を宅内ユーザまたは企業内ユーザに配信するネットワークのことを言う。
IMSネットワークを相互接続するための1つのありうる枠組みが、図2に示すようにGSMA(Global System for Mobile Communications Association)によって提案されている。このグローバルなサービスプロバイダ間のIPバックボーンは、典型的にはIPX(Internetwork Packet Exchange)と呼ばれ、GSMA IR.34の中に記述されている。この枠組みの中には、オペレータA 202とオペレータB 204とが含まれ、それらはいずれもIPXプロバイダX 208に接続しており、さらにオペレータC 214も含まれるが、こちらはIPXプロバイダY 210に接続している。IPXプロバイダX 208およびIPXプロバイダY 210は、IPX206の一部であり、ENUM(Electronic Number Mapping System)を備えたDNS(domain name system)ルートデータベース212と通信する。IPX206の1つの目的は、合意された共同利用できるサービス定義および業務契約、例えばSLA(サービス品質保証契約)に従ってサービスプロバイダ間の相互接続を円滑化することである。これを円滑化するために、IPX206は、この通信の枠組みに複数の利害関係者を導入することによって、GPRS(general packet radio service)のアーキテクチャの上にGRX(roaming exchange)を構築してGPRSのアーキテクチャを拡張する。これらの利害関係者には、固定ネットワークオペレータ、インターネットサービスプロバイダ、およびアプリケーションサービスプロバイダが含まれうる。IPX206は、メッセージトラヒックをルーティングする目的で、自分自身のDNSインフラストラクチャを有すると想定され、その関連情報はDNSルートデータベース212の中に記憶されうる。IPXに接続するオペレータのためのGSMAが定義したDNS命名規則は、MNC(mobile network code)とMCC(mobile country code)とを利用することに基づいている。GSMA提案に基づくSIPメッセージのための一意の識別情報の一例をあげると、以下のようであろう。
sip:+447703123456@mnc001.mcc234.3gppnetworks.org
sip:+447703123456@mnc001.mcc234.3gppnetworks.org
ネットワークの相互接続のためのもう1つの提案が、ETSI(European Telecommunications Standards Institution)TISPAN(Telecommunications and Internet Services and Protocols for Advanced Networks)NGN(next generation network:次世代ネットワーク)リリース2によって行われた。より詳細には、図3(a)に示すように、ETSI TS 182 025は、ビジネス・トランキング(business trunking)NGCN(next generation corporate network:次世代企業ネットワーク)304が、加入に基づいて在圏オペレータのIMSネットワーク302にどのようにして接続されうるかについてのアーキテクチャ300を提供する。Gm参照ポイント306は、在圏オペレータのIMSネットワーク302と企業ネットワークとの境界を示す。加入相互接続の場合、NGCN304は、IMSの文脈の中の単一ユーザとして実現され、NGCN304は、在圏オペレータのIMSネットワーク302にユーザ登録を行うと想定される。次いで、在圏オペレータのIMSネットワーク302は、CSCF(呼セッション制御機能)、例えばS−CSCF(サービングCSCF)310およびP−CSCF(プロキシCSCF)308、並びにAS(アプリケーションサーバ)312を通してユーザにサービスを提供することができる。
ETSI TS 182 025は、その他のビジネスシナリオについて図3(a)に示すアーキテクチャの変形を可能にし、そしてそれを特定する。一例では、図3(b)に示すように、ビジネス・トランキングNGCNが、加入協定の代わりにピアリング協定によって在圏オペレータのIMSネットワーク302に接続する。ピアリング相互接続の場合、在圏オペレータのIMSネットワーク302の中には、NGCN304についてのユーザがいない。代わりに、NGCN304は、在圏オペレータのIMSネットワーク302の中で、IBCF(Interconnect Border Control Function:相互接続境界制御機能)314を通してルーティングされるセッション情報と共にIBCF314によって示される。
Hosted Enterprise Service(ホストされた企業サービス)NGCNと呼ばれる別のケースでは、NGCN304の中の各ユーザが、在圏オペレータのIMSネットワーク302の中の1人のユーザとして実現され、従って、NGCN304の中の各ユーザが、在圏オペレータのIMSネットワーク302にユーザ登録し、CSCFを通してサービスをルーティングしてもらうと想定される。また、大企業のネットワーク(または複数のネットワーク)については、NGCN304のサイトと在圏オペレータネットワーク(または各種の在圏オペレータネットワーク)との間のこれらの接続に複数の事例がある可能性があり、この場合、これらの接続の事例は、上記の3つのケースが混じり合ったものでありうる。
上述したこれらのケースの各々において、TISPANアーキテクチャを用いてSIPメッセージを通信することができ、それによってユーザは、RFC(request for comments)3261の中で記述されたようにsip:user@domainという形式のURI(Uniform Resource Identifier)によってアドレス指定されることができる。企業、例えば会社の場合には、URIは、電子メールアドレスから導出することができ、例えば、sip:john@enterprise.comのように表されてもよいだろうし、あるいは、IP(Internet Protocol)−PBX(Private Branch eXchange)から導出することができ、例えばsip:8501234@enterprise.com;user=phoneのように表されてもよいだろう。その他の許容される選択肢には、宅内ユーザ、例えばsip:john@baldwin.orgまたは、ユーザフレンドリーなオペレータ名、例えば、sip:john@telia.se等がある。
GSMAおよびTISPANによって定義された、提案のネットワークアーキテクチャの文脈では、既存の標準および解決策は、RFC3261に基づいて上記で示した形式のSIP URIにアドレス指定されたセッションを発信側オペレータがどのようにルーティングできるかに関して、決定的とはいえない。この分野では、諸標準は、SIP URIにアドレス指定されたセッションをルーティングするため、DNSの使用を一般的に言及するが、それは、いろいろな理由で大規模な展開には不十分である。例えば、複数のネットワークが関与する場合、各ネットワークは、IPX用に提案されたもののような共有DNSに接続するだけでなく、内部的なDNSを有することがある。しかし、各種の標準は、これらの多様なDNSがどのようにして設定され使用されることになるのかを記述していない。事態を一層複雑にするのだが、完全修飾ドメイン名(fully qualified domain names:FQDN)がパブリックインターネット上に数千万も存在することを考えると、一意のアドレスの全体量は相互接続ネットワークでも同様となりうるだろうと想定されることから、スケーラビリティが問題である。これは、トラヒック、例えばSIPトラヒックを複数の相互接続ネットワーク経由でルーティングするための課題となりうる。
加えて、オペレータ各社は、他のパブリックネットワークへの自社の相互接続の知識だけでなく、これらのネットワークオペレータ各社に対する相互接続合意に基づいてルーティングの決定をしたいと望むことが多い。この情報は、彼らのローカルなDNSサーバや関連のインフラストラクチャによって完全に供給されるとは限らない。在圏ネットワークオペレータがURIから容易に導出できないSIP URIも多い。例えば、sip:john@enterprise.comまたはsip:john@baldwin.orgまたはjohn@brand_name.comのようなSIP URIには、在圏ネットワークオペレータが示されない。従って、特定のオペレータにメッセージをルーティングするのに複数のやり方がある場合、発信側オペレータがどの相互接続選択肢を用いるかという決定は、典型的には、企業ユーザまたは宅内ユーザにサービス提供しているオペレータの知識に基づいて行われうるだけである。また、電話セッションについての既存の課金モデルは、一部は発呼ユーザと被呼ユーザの地理的位置に基づき、そして多くの場合、一部は発呼ユーザと被呼ユーザにサービス提供するオペレータにも基づく。言い換えれば、オペレータ各社は、典型的には、着信側オペレータについての情報に基づいて課金の決定を行うことを望むのだが、それはsip:john@enterprise.comまたはsip:john@baldwin.orgのようなSIP URIには示されない。従って、以下の例示的実施形態は、SIP URIにアドレス指定されたセッションが、複数のネットワークを通って正確な宛先までルーティングされることを可能にする、アドレス指定メカニズムとルーティングメカニズムとを提供する。
上記のように、これらの例示的実施形態についての一般的な文脈には、各種の通信ネットワークと在圏ネットワークとを含むオペレータネットワーク上の電話が含まれる。しかし、理解されるであろうが、本発明は、電話に限らず、いかなるタイプのメッセージをルーティングするのにも使用されうる。これらのネットワークは典型的には、多様な通信経路と、各種のネットワークを分離するIBCFと、に関する可能性を有するであろう。加えて、メッセージトラヒックが所望のエンドポイントに到達することができるように、これらの各種のネットワーク間で通信を転送するための必要な詳細を詳述するSLA(サービス品質保証契約)が作成されるであろうと予想される。一部の詳細には、サービス品質要件やコストを含んでもよいし、さらに、例えばネットワークを識別するためにネットワークによって用いられることになる合意済み形式のようなアドレス指定の規則が含まれてもよい。
例示的実施形態によれば、要求またはメッセージの所望のルーティング経路を(例えば発信側ネットワークが)判定するための解決策には、発信側ネットワークがデータベースにクエリを行って、メッセージのルーティングを判定するのに用いられる応答を受信することが含まれる。例えば、発信側ネットワークが、宛先ユーザアドレス、例えばsip:john@bank.comというSIP URIを含むSIPメッセージをユーザから受信すると仮定しよう。この発信側ネットワークは発信側ネットワークとして動作しているため、どの在圏ネットワークがサービスをbank.comに提供するのか分からず、従って、どこにメッセージを送信するのか分からない。次いで、発信側ネットワークが、何らかのタイプの宛先識別情報、例えばsip:john@bank.com、またはbank.com、または、宛先ユーザアドレスに関連するいずれかの他のタイプの宛先識別情報を使って、(マスタDNSデータベースを含みうるであろう)在圏オペレータデータベースにクエリを行って、そして、在圏ネットワークを識別する情報、例えば在圏ネットワークのFQDNまたはその他の合意された識別情報を含む応答を受信する。
例示的実施形態によれば、この在圏オペレータデータベースは、典型的なネットワークレベルDNSサーバより相当多くの情報を含むことが可能であり、例えば、在圏オペレータデータベースは、すべてのFQDNについての情報と、相互接続されている各種ネットワークについての情報とを含んでもよいだろう。それに比べて、ネットワークレベルDNSは典型的には、共有の相互接続からのネットワークオペレータの入口ポイント(ingress points)についてのレコードを保持するだけであり、各種のオペレータまたはIPXのようなグループによって運用される。従って、本書で議論されるネットワークレベルDNSが、典型的にはネットワーク毎に用いられて、単一のオペレータネットワークについてドメイン名とIPアドレスとの間の翻訳を行うのに対し、本書で議論される在圏オペレータデータベースは、特に、特定のメッセージに関連する在圏ネットワークを識別するのに用いられる。その後、在圏オペレータデータベースからデータを受信した時点で、発信側ネットワークは、例えば、各種のネットワーク間の適切なSLAと、コストと、トラヒック管理の検討材料とのうちのいずれか、または一部、または全部に基づいて、ルーティング経路を判定する。次いで、発信側ネットワークは、メッセージを在圏ネットワークに向けて送信し、そして、宛先ユーザアドレスと在圏オペレータを識別するための情報とを両方含める。このように宛先ユーザアドレスと在圏オペレータを識別するための情報とを両方共用いることは、2層のアドレス指定の一例である。
例示的実施形態によって、一企業(または複数の企業)および個人ユーザに通信をルーティングすることができる各種の相互接続ネットワークを図4に示す。この例示的通信の枠組みは、2つのオペレータネットワークであるTele2 402およびTelia404と、IPX406と、企業ネットワークであるBank408とを含む。SBG(セッション境界ゲートウェイ)は典型的にはアクセスポイントであるが、同時に、各種のオペレータネットワークおよびIPX406に出入りする通信のためのファイアウォールとしても動作することができる。加えて、オペレータネットワークであるTele2 402およびTelia404はそれぞれ、少なくともローカルに格納されたドメイン情報を有する、自分自身のネットワークレベルDNSサーバ422および424(またはその同等物)を有する。在圏オペレータデータベース410は、IPX406に関連するすべてのネットワークについてのDNS情報を含む。この例ではIPX406の中に位置しているが、在圏オペレータデータベース410は、オペレータネットワークに接続されていてそれらにアクセス可能ならばどこに存在してもよく、例えば、第三者の所在地に存在してもよい。在圏オペレータデータベース410に記憶されたDNS情報は、例を挙げれば、例えばTele2 402およびTelia404のようなネットワークによって在圏オペレータデータベース410に報告された、各ネットワークによってサービス提供される住居や企業について記述する情報を含んでもよい。
企業ネットワークBank408は、各種のリソースおよび個人をアドレス可能な場所を表すBank Centrex412と2つのBank PBX414および416とを含む。ユーザ1 418は、Tele2によってサービスを提供されるユーザを表し、ユーザ2 420は、Bank PBX414に関連することが知られているBank408のために働いているユーザを表す。本書ではBank Centrex412は、バーチャルPBXであると考えられている。バーチャルPBXは、典型的には小規模なリモートの企業拠点に関連付けられる。本書で記述する例示的実施形態において、在圏ネットワークは、通常のPBXとバーチャルPBXとをいずれも呼とメッセージとをエンドユーザに配信することについては同様に取り扱い、すなわち、本書で記述する例示的実施形態は、通常のPBXとバーチャルなPBXとのうちのいずれを利用するのかによって制約されない。
上記の例示的実施形態によれば、在圏オペレータデータベース410は、ユーザに関連する宛先識別情報と、それらの個別の在圏オペレータネットワークについての情報との両方に関連する情報を含む。在圏オペレータデータベース410は、この情報を用いてこれらの情報の集合間のマッピングを行うことができる。加えて、この情報は、さまざまなかたちで存在しうる。例えば、各種のネットワークおよびユーザを識別するのに、一般的なドメイン名、例えばericsson.com、telia.se、baldwin.orgが用いられてもよいし、構造化された通信名、例えばmnc001、mcc234が用いられてもよい。また、在圏オペレータデータベース410は、一般的なドメイン名と、mncやmccを用いる構造化された識別情報との間のマッピングを行ってもよい。
次に、図5に示すシグナリング図に関して、例示的実施形態によって、例えば図4に示す通信ネットワーク経由で呼をルーティングするメッセージについて記述しよう。最初に、ユーザ1 418が、メッセージINVITE sip:gert@bank.com 502を、発信側オペレータネットワークとして動作するTele2 402に送信する。Tele2 402は、どのネットワークがサービスをbank.comに提供するのか分からず、従って、「bank.com」(またはその翻訳バージョン)を含むクエリメッセージ504を在圏オペレータデータベース410に送信する。在圏オペレータデータベース410は、ルックアップを行って、「bank.com」がTelia404によってサービス提供されることを見つけ、応答メッセージ506の一部として「vpnservice@telia.se」を送信する。Tele2 402は、この情報を用いて、Tele2 402とTelia404との間の相互接続および契約、例えばSLAに基づいてルーティング経路を判定する。
図4に示すように、Tele2 402は、直接接続とIPX406経由との両方を通してTelia404に接続している。この事例では、Tele2 402は、「INVITE vpnservice@telia.se Target sip:gert@bank.com」を含むメッセージ508で示すようにIPX406を通してトラヒックをルーティングすることを選ぶ。IPX406は受信したメッセージ508の中の「telia.se」を見て、メッセージ510をTelia404へルーティングする。次いでTelia404は、「INVITE sip:gert@bank.comを含むメッセージ512をユーザ2 420に送信する。
上記のように、上述したルーティング情報は、宛先アドレスと、例えばユーザまたは企業のような宛先にサービスを提供するネットワークについて記述する情報とを両方含む。後者の情報は、在圏オペレータデータベース410への発信側ネットワークのクエリへの応答を介して発信側ネットワークが利用できるようにされる。例示的実施形態によれば、ルーティング情報は、さまざまなやり方でSIPメッセージに組み込むことができる。当業者であれば理解するであろうが、SIPメッセージは、Request URIとTarget URIヘッダとを両方含むことができる。例示的な一実施形態によれば、在圏オペレータID、例えばtelia.seをRequest URIに入れることができ、そして、宛先の元のSIP URI、例えばgert@bank.comを、SIPメッセージのTarget URIヘッダに入れることができる。呼が在圏オペレータネットワークに到着すると、在圏オペレータは、Target URIをRequest URIに戻すように促し、呼をNGCN304へとさらに配信させる。
別の例示的実施形態によれば、在圏オペレータIDを、Request URIに添付することができる(例えば、sip:john@enterprise.com.marker.mnc123.mcc234.3gppnetworks.orgのように)。あるいは、新たなパラメータをSIP Request URIに入れることができる。例えば、在圏オペレータをパラメータとしてSIP Request URIに追加し、sip:john@enterprixe.com;so=mnc123.mcc234.3gppnetoworks.orgのようにすることができる。別の例示的実施形態によれば、情報をRequest URIに添付するために上記で述べたのと同様のやり方でRN(ルーティング番号)またはTRGP(トランクグループパラメータ)のような他の既存のパラメータを拡張することによって、必要な在圏オペレータ情報を搬送することができる。
上記の例示的実施形態によれば、SIPメッセージの中で最初のSIP URIと在圏オペレータIDとを両方搬送することによって、発信側ネットワークと中継/相互接続ネットワークとが、中枢の在圏オペレータデータベース410によって取得された在圏オペレータ識別情報に基づいてメッセージをルーティングすることが可能になる。従って、在圏オペレータネットワークルーティング情報は、中継/相互接続ネットワークが知っていて読み取ることができるSIPメッセージについての通常のルーティング情報の一部として提供されるのだから、中継/相互接続ネットワークは、典型的には、企業または住宅用FQDNについての情報を知る必要はないし、在圏オペレータデータベース410にクエリを行う必要もない。
例示的な一実施形態によれば、メッセージがその中を移動できる各種のネットワークはそれぞれ、典型的には、内部では別個のローカルIPアドレスを用いる。従って、IPアドレスとIPアドレスを用いたルーティングとを求める従来のDNSクエリは、典型的には、発信側オペレータネットワークから在圏ネットワークおよび宛先までルーティングするためには用いられない。加えて、IPアドレスによるルーティングは、発信側ネットワークによって制御されない状態で使用ルートの選択を行う自動ルーティングであると考え得ることから、典型的には望まれない。これでは、発信側オペレータネットワークが経路を制御することができず、SLAに関する問題や、収入が最適にならないことにつながりうるであろう。
一企業について複数の在圏オペレータの事例
上記の例示的実施形態は、企業が単一の在圏オペレータネットワークによってサービス提供される場合にメッセージトラヒックをルーティングするためのシステムおよび方法を記述する。しかし、大企業については、NGCNサイトと在圏オペレータネットワークとの間に複数の接続事例がありうる。例えば、大規模な企業ネットワークについては、企業は、企業の各部門が地理的に広域に位置していることや、ビジネス上の競合の理由等から、複数の在圏オペレータを望むことがある。例示的実施形態によって、企業が2つの異なる在圏オペレータネットワークを用いる通信の枠組みについて、図6に関して以下に述べる。
上記の例示的実施形態は、企業が単一の在圏オペレータネットワークによってサービス提供される場合にメッセージトラヒックをルーティングするためのシステムおよび方法を記述する。しかし、大企業については、NGCNサイトと在圏オペレータネットワークとの間に複数の接続事例がありうる。例えば、大規模な企業ネットワークについては、企業は、企業の各部門が地理的に広域に位置していることや、ビジネス上の競合の理由等から、複数の在圏オペレータを望むことがある。例示的実施形態によって、企業が2つの異なる在圏オペレータネットワークを用いる通信の枠組みについて、図6に関して以下に述べる。
図6は、例示的な通信の枠組みを示すが、ここにはIPX406が含まれ、それが各種のオペレータネットワーク、例えばTelia404、Tele2 402、Jersey Tel604、Gamma Tel608に接続する。また、この例では、IPX406は、一次DNSデータベース410を含むが、これは宛先のFQDNを、その宛先にサービスを提供する在圏ネットワークにマッピングするための情報を含む。企業Bankが、Telia404によってサービス提供されるBank PBX414と、Jersy Tel604によってサービス提供されるBank PBX602とで示すように、2つの異なる在圏オペレータネットワークによってサービス提供され、Bank PBX414とBank PBX602とはVPN606によって接続される。さらに、ユーザ1 418とユーザ2 420とを示す。
次に、例示的実施形態によって、一企業について複数の在圏オペレータネットワークを有するケースについて図6に示すアーキテクチャを用いる、図7に示すようなシグナリングフローについて記述しよう。最初に、ユーザ1 418が、「INVITE sip:gert@bank.com」を含むメッセージ702を、発信側ネットワークとして動作するTele2 402に送信する。次いでTele2 402は、例えば「bank.com」や「gert@bank.com」のような宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージ704を在圏オペレータデータベース410に送信する。在圏オペレータデータベース410は、ルックアップを行って、2つの在圏オペレータネットワーク、例えばvpnservice@telia.seやvpnservice@jersey.ukについての識別情報を含む応答メッセージ706を送信する。次いでTele2 402は、どの在圏オペレータネットワークに要求を送信し、要求をどのようにルーティングするかを決定する。これらの決定は、既知の相互接続、SLA、地理的位置、コスト、その他の関連情報に基づいて行われてもよい。これらの決定に基づいて、Tele2 402は、「INVITE vpnservice@telia.seおよびTarget sip:gert@bank.com」を含むメッセージ708をIPX406に送信する。IPX406は、自分が必要とするルーティング情報、例えばtelia.seが分かり、そして、メッセージ710に示すように、メッセージをTelia404に転送する。ついでTelia404は、メッセージの内容をよく調査して、それらを、gert@bank.comであることが分かっているユーザ2 420に転送する。
上記のように、企業は、その企業の異なる部門について各種の在圏オペレータネットワークを有することがある。例示的実施形態によれば、すべての在圏オペレータネットワークが、対応する識別情報またはルーティング情報を在圏オペレータデータベース410の中に記憶しておく必要はない。加えて、クエリメッセージ704に応じて、在圏オペレータデータベース410の中に記憶された1つの、または少数の、またはすべての在圏オペレータネットワークが、応答メッセージ706の中で返信されてもよい。応答メッセージ706の中で用いられる在圏オペレータネットワークは、在圏オペレータネットワークと企業との間で事前に定められ、それに従って一次DNSデータベース410に記憶されてもよい。
例示的実施形態によれば、不適切な在圏オペレータネットワークがメッセージを受信した場合、すなわち、在圏オペレータネットワークがそのメッセージについてはその宛先にサービス提供しないと判定する場合、システムと方法とを用いてメッセージを別の在圏オペレータネットワークにさらにルーティングすることができる。ある場合には、例えば、宅内ユーザが企業に電話をかけることによって、呼がパブリックネットワークにおいて開始される。発信側オペレータネットワークが、(そのクエリによって受信された)複数の在圏オペレータのうちの1つを選択し、呼をその在圏オペレータに配信した。しかし、これは実際には、当該ユーザにとっては不適切な在圏オペレータであった。在圏オペレータネットワークは、企業にクエリを行うことができ、例えば企業内のデータベースにルーティングについての指示を求めるクエリを行って、次いで、上記の2層のアドレス指定スキームを用いて呼を正しい在圏オペレータネットワークにルーティングすることができる。
別の例示的実施形態によれば、呼は、企業内で、例えば企業ユーザが別の企業ユーザに対して開始することができる。宛先企業ユーザは、発信企業ユーザとは別の在圏ネットワークオペレータによってサービス提供される企業ネットワークの一部である。この場合、これはオンネット・コールとして知られるものだが、呼は、各種の相互接続ネットワークを経て正しい在圏オペレータネットワークにルーティングされる必要がある。また、上記の2層のアドレス指定スキームを用いてこの呼を正しい在圏オペレータに転送することもできる。
ドメイン名ポータビリティ
例示的実施形態によれば、上記のシステムおよび方法の実装によって、ドメイン名ポータビリティが可能になる。本書ではドメイン名ポータビリティとは、ユーザまたは企業のドメインを、1つの在圏オペレータから別の在圏オペレータに最小限のオーバーヘッドまたは作業で移動させることを言う。例えば、上記のように、これらの例示的実施形態で用いられる在圏オペレータデータベース410は、各ネットワークで用いられる典型的なネットワークレベルのDNSデータベース422、424とは別である。この在圏オペレータデータベース410は、在圏オペレータデータベース410のプロバイダと各ネットワークオペレータとによって定められたように各ネットワークによって更新されるが、更新は変更が行われる時にタイムリーに行われることが望ましく、それによってドメイン名ポータビリティが円滑化される。
例示的実施形態によれば、上記のシステムおよび方法の実装によって、ドメイン名ポータビリティが可能になる。本書ではドメイン名ポータビリティとは、ユーザまたは企業のドメインを、1つの在圏オペレータから別の在圏オペレータに最小限のオーバーヘッドまたは作業で移動させることを言う。例えば、上記のように、これらの例示的実施形態で用いられる在圏オペレータデータベース410は、各ネットワークで用いられる典型的なネットワークレベルのDNSデータベース422、424とは別である。この在圏オペレータデータベース410は、在圏オペレータデータベース410のプロバイダと各ネットワークオペレータとによって定められたように各ネットワークによって更新されるが、更新は変更が行われる時にタイムリーに行われることが望ましく、それによってドメイン名ポータビリティが円滑化される。
例えば、企業Bank408が、Telia404を自社のサービスプロバイダとして用いていると仮定する。次いで、企業Bank408は、自社のサービスプロバイダとしてTele2 402に変更することを決め、すなわち、Bank408から在圏ネットワークへの接続ポイントが、新たな在圏ネットワークに変更されるが、Bank408の中の内部アドレス指定は典型的には変更されず、例えば個別のSIP URI、内線番号、直通電話番号(direct dialing inwards:DDI)は以前と同じであろう。次いで、この変更が行われた後、Tele2 402は、その変更について、在圏オペレータデータベース410を更新する。典型的には、2つのネットワークがこの変更によって直接影響を受ける場合を除き、DNSインフラストラクチャの低い方のレベルでは変更が行われる必要はない。また、Bank408のネットワーク構造の範囲内での内部変更は、大部分は、修正される必要はないだろう。また、このプロセスは、住宅用についても当てはまるであろう。例えば、ユーザがgert@baldwin.orgというドメイン名を有していて、在圏オペレータネットワークを変更した場合、ドメイン名は、新たな在圏オペレータネットワークへ持ち運ぶことができるであろうし、依然としてgert@baldwin.comへのシームレスな移行により使用することができるであろう。
上述の例示的実施形態は、相互接続ネットワーク(例えば、相互接続IMSネットワーク)経由でトラヒックをルーティングするために使用される在圏オペレータネットワークと照合される宛先アドレス情報を記憶するために、在圏オペレータデータベース410を使用する方法およびシステムを図解する。ここで、図8に関して、在圏オペレータデータベース410を表す例示的通信ノード800を説明する。通信ノード800は、プロセッサ802(または複数のプロセッサコア)と、メモリ804と、1つ以上の二次ストレージデバイス806と、通信を円滑化する通信インタフェースユニット808とを含むことができる。メモリ804(または二次ストレージデバイス806)は、宛先アドレス(例えば、FQDN)およびこれらの宛先にサービス提供する在圏オペレータネットワークに関するストレージとして使用可能である。それゆえ、例示的実施形態による通信ノード800は、クエリを受信し、宛先に関連する在圏オペレータネットワーク(または複数のネットワーク)を返すことができる。加えて、通信ノード800は、上記の各種の通信ネットワークにおけるその他のノード、例えばネットワークレベル(ローカル)DNSサーバ、またはDNSサーバおよび在圏オペレータデータベース410の組み合わせ、の機能を実行することができる。
例示的実施形態による上述の例示的システムを利用して、通信をルーティングするための方法を図9のフローチャートに示す。最初に、在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法は、ステップ902において、前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、ステップ904において、前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを特定する情報を含む応答メッセージを受信するステップと、ステップ906において、前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを特定する前記情報とを組み込むステップと、ステップ908において、前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、を備える。
例示的実施形態による上述の例示的システムを利用して、通信をルーティングするための方法を図10のフローチャートに示す。最初に、通信ノードにおける、通信をルーティングするための方法は、ステップ1002において、各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、前記宛先ユーザアドレスに関連する各宛先識別情報が少なくとも1つの在圏ネットワークにも関連する、ステップと、ステップ1004において、宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの1つを含むクエリメッセージを受信するステップと、ステップ1006において、宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも1つの在圏ネットワークを判定するステップと、ステップ1006において、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも1つの在圏ネットワークを特定する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、を備える。
上記で開示した例示的実施形態は、相互接続ネットワークを経てメッセージトラヒックをルーティングすることに関連するシステムおよび方法について記述する。理解されるべきだが、この記述は、本発明を限定することを意図していない。例えば、上述の例示的実施形態は、各々が移動電話を使用している2人の別個のユーザ間で相互接続IMSネットワーク経由で呼をルーティングするために実装可能である。対照的に、例示的実施形態は、代替形態、修正形態、均等形態をカバーすることが意図されており、それらは添付の請求項によって定義されるように本発明の精神と範囲に含まれる。さらに、例示的実施形態の詳細記述において、請求された本発明の完全な理解を提供することを目的として多数の個別の詳細が記述されている。しかし、当業者であれば、そのような個別の詳細がなくても各種の実施形態が実施されうることを理解するであろう。
本書の例示的実施形態の特徴および要素は、特定の組み合わせにおける実施形態として記述されているけれども、それぞれの特徴または要素は、実施形態のその他の特徴および要素なしに単独で用いられてもよいし、本書で開示した他の特徴および要素と共にかまたはそれらなしに各種の組み合わせで用いられてもよい。本願で提供した方法またはフローチャートは、汎用コンピュータまたはプロセッサによって実行するための、コンピュータ可読記録媒体に収録されるコンピュータプログラム、ソフトウェア、またはファームウェアとして実装されてもよい。
Claims (24)
- 在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法であって、
前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、
前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを識別する情報を含む応答メッセージを受信するステップと、
前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを識別する前記情報とを組み込むステップと、
前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、
を備えることを特徴とする方法。 - 前記メッセージは、セッション開始プロトコル(SIP)メッセージである
ことを特徴とする請求項1に記載の方法。 - 前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記SIPメッセージのTargetユニフォーム・リソース・アイデンティファイア(URI)ヘッダに配置し、前記在圏ネットワークを識別する前記情報を前記SIPメッセージのRequest URIに配置するステップをさらに備える
ことを特徴とする請求項2に記載の方法。 - 前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記SIPメッセージのRequest URIに配置し、前記在圏ネットワークを識別する前記情報を前記SIPメッセージの前記Request URIに添付するステップをさらに備える
ことを特徴とする請求項2に記載の方法。 - 前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記SIPメッセージのRequest URIに配置し、前記在圏ネットワークを識別する前記情報を、前記SIPメッセージの前記Request URI中の新しいパラメータとして追加するステップをさらに備える
ことを特徴とする請求項2に記載の方法。 - 前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報をRequest URIに配置し、前記在圏ネットワークを識別する前記情報を、前記SIPメッセージ中の既存のパラメータを用いて添付するステップをさらに備える
ことを特徴とする請求項2に記載の方法。 - 前記SIPメッセージ中の前記既存のパラメータは、ルーティング番号パラメータおよびトランクグループパラメータのうちの少なくとも一方である
ことを特徴とする請求項6に記載の方法。 - 前記応答メッセージの中で、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する複数の在圏ネットワークに関する識別情報を受信するステップと、
コスト、サービス品質保証契約、およびトラヒック管理の検討材料のうちの少なくとも1つに基づいて、前記複数の在圏ネットワークのうちの1つへ前記メッセージをルーティングすることを決定するステップと、
を更に備えることを特徴とする請求項1に記載の方法。 - 前記宛先ユーザアドレスに関連する前記宛先識別情報は、住宅および企業のうちの少なくとも一方に関連する
ことを特徴とする請求項1に記載の方法。 - 前記宛先ユーザアドレスに関連する前記宛先識別情報は、完全修飾ドメイン名(FQDN)である
ことを特徴とする請求項1に記載の方法。 - 前記宛先ユーザアドレスに関連する前記宛先識別情報は、FQDNの一部である
ことを特徴とする請求項1に記載の方法。 - 通信ノードにおける、通信をルーティングするための方法であって、
各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、前記宛先ユーザアドレスに関連する各宛先識別情報が少なくとも1つの在圏ネットワークにも関連する、ステップと、
宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの1つを含むクエリメッセージを受信するステップと、
前記宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも1つの在圏ネットワークを判定するステップと、
前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも1つの在圏ネットワークを識別する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、
を備えることを特徴とする方法。 - 前記少なくとも1つの在圏ネットワークは、複数の在圏ネットワークである
ことを特徴とする請求項12に記載の方法。 - 前記少なくとも1つの在圏ネットワークの中でメッセージのルーティングをサポートするステップを更に備え、
前記少なくとも1つの在圏ネットワークは、ドメイン・ネーム・システム(DNS)サーバを含み、
前記DNSサーバは、前記通信ノードとは別物である
ことを特徴とする請求項12に記載の方法。 - 前記通信ノードはデータベースである
ことを特徴とする請求項12に記載の方法。 - 前記宛先ユーザアドレスに関連する前記宛先識別情報の1つと前記対応する少なくとも1つの在圏ネットワークとの間の変更を示すメッセージまたはデータベース管理アクションを受信するステップと、
前記受信したメッセージに基づいて前記記憶された対応を更新するステップと、
を更に備えることを特徴とする請求項12に記載の方法。 - 前記宛先ユーザアドレスに関連する前記宛先識別情報は、企業を識別する
ことを特徴とする請求項12に記載の方法。 - 前記宛先ユーザアドレスに関連する前記宛先識別情報は、宅内ユーザを識別する
ことを特徴とする請求項12に記載の方法。 - 通信ノードであって、
宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも1つの在圏オペレータネットワークと、の間のマッピングを記憶するメモリと、
前記宛先ユーザアドレスに関連する前記宛先識別情報を受信する通信インタフェースと、
前記宛先ユーザアドレスに関連する前記受信した宛先識別情報に関するルックアップを実行するプロセッサと、
を備え、
前記ルックアップは、セッション開始プロトコル(SIP)メッセージ中で前記宛先ユーザアドレスに関連する前記宛先識別情報を含むクエリメッセージを前記通信インタフェースが受信した場合に、前記少なくとも1つの在圏オペレータネットワークを結果として返し、
前記通信インタフェースは、前記少なくとも1つの在圏オペレータネットワークを含む応答メッセージを送信する
ことを特徴とする通信ノード。 - 前記少なくとも1つの在圏オペレータネットワークは、複数の在圏オペレータネットワークである
ことを特徴とする請求項19に記載の通信ノード。 - 前記少なくとも1つの在圏オペレータネットワークの各々は、当該在圏オペレータネットワークの中でメッセージのルーティングをサポートするドメイン・ネーム・システム(DNS)サーバを含み、
前記DNSサーバは、前記通信ノードとは別物である
ことを特徴とする請求項19に記載の通信ノード。 - 前記通信ノードはデータベースである
ことを特徴とする請求項19に記載の通信ノード。 - 前記宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも1つの在圏オペレータネットワークと、の間の前記マッピングは、一般的なドメイン名と構造化された名前との間で行われる
ことを特徴とする請求項19に記載の通信ノード。 - 前記構造化された名前は、mncxxx.mccyyyというフォーマットを持ち、
mncは移動体網コードであり、mccは移動体国コードである
ことを特徴とする請求項23に記載の通信ノード。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/IB2008/003626 WO2010073058A1 (en) | 2008-12-26 | 2008-12-26 | Methods and communications node for routing communications using a bi-level addressing scheme |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2012514363A true JP2012514363A (ja) | 2012-06-21 |
Family
ID=41040662
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011542901A Pending JP2012514363A (ja) | 2008-12-26 | 2008-12-26 | 2層の(bi−level)アドレス指定スキームを用いて通信をルーティングするための方法および通信ノード |
Country Status (6)
Country | Link |
---|---|
US (1) | US20120143982A1 (ja) |
EP (1) | EP2380360A1 (ja) |
JP (1) | JP2012514363A (ja) |
CN (1) | CN102265635A (ja) |
CA (1) | CA2748403A1 (ja) |
WO (1) | WO2010073058A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012514364A (ja) * | 2008-12-26 | 2012-06-21 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 企業ネットワークアクセスポイントの判定のための方法およびシステム |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8386590B2 (en) * | 2009-10-01 | 2013-02-26 | At&T Intellectual Property I, Lp | Method and apparatus for managing rehoming of user endpoint devices in a communication network |
JP5505170B2 (ja) * | 2010-07-30 | 2014-05-28 | 富士通株式会社 | 処理装置、処理方法、及び通信システム |
US9485548B2 (en) | 2010-10-27 | 2016-11-01 | Comcast Cable Communications, Llc | Origination and destination based routing |
US8442205B2 (en) | 2010-10-27 | 2013-05-14 | Comcast Cable Communications, Llc | Data and call routing and forwarding |
CA2812571A1 (en) * | 2012-04-16 | 2013-10-16 | Comcast Cable Communications, Llc | Origination and destination based routing |
US9197487B2 (en) | 2013-03-15 | 2015-11-24 | Verisign, Inc. | High performance DNS traffic management |
US9900281B2 (en) | 2014-04-14 | 2018-02-20 | Verisign, Inc. | Computer-implemented method, apparatus, and computer-readable medium for processing named entity queries using a cached functionality in a domain name system |
EP3251465A4 (en) | 2015-01-30 | 2018-02-21 | Hewlett-Packard Enterprise Development LP | Communication using virtual numbers |
US9819703B2 (en) * | 2015-09-23 | 2017-11-14 | T-Mobile Usa, Inc. | SIP server with multiple identifiers |
US11165833B2 (en) | 2016-11-02 | 2021-11-02 | T-Mobile Usa, Inc. | Network routing based on terminal's media path |
US11032127B2 (en) | 2017-06-26 | 2021-06-08 | Verisign, Inc. | Resilient domain name service (DNS) resolution when an authoritative name server is unavailable |
CN112202842A (zh) * | 2017-08-29 | 2021-01-08 | 华为技术有限公司 | 数据传输方法、设备及系统 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08214059A (ja) * | 1994-10-18 | 1996-08-20 | At & T Corp | 競合的な環境内でのローカル及び市外電話通信呼の接続 |
WO2002037788A2 (en) * | 2000-11-02 | 2002-05-10 | Telefonaktiebolaget L M Ericsson (Publ) | Domain name portability |
JP2005094297A (ja) * | 2003-09-17 | 2005-04-07 | Matsushita Electric Ind Co Ltd | ネットワーク制御装置、通信端末、ネットワーク制御方法 |
KR20050083428A (ko) * | 2004-02-23 | 2005-08-26 | 주식회사 케이티 | 차세대 네트워크에서의 세션 개시 프로토콜 라우팅 시스템및 그 라우팅 방법 |
JP2008092578A (ja) * | 2006-10-03 | 2008-04-17 | Research In Motion Ltd | ユーザの機器デバイスから回路交換ネットワークを介してsipコールを開始するためのシステムおよび方法 |
JP2008098888A (ja) * | 2006-10-11 | 2008-04-24 | Murata Mach Ltd | 中継サーバ |
EP1950942A1 (en) * | 2005-11-15 | 2008-07-30 | Huawei Technologies Co., Ltd. | A system of realizing number portability service and a method thereof |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7042864B1 (en) * | 2000-08-01 | 2006-05-09 | Cisco Technology, Inc. | Enabling push technologies for mobile IP |
KR20060102412A (ko) * | 2005-03-23 | 2006-09-27 | 삼성전자주식회사 | 푸쉬투토크 오버 셀룰러 망의 애드 혹 세션 개설 방법 및그 시스템 |
CN101669376A (zh) * | 2007-01-18 | 2010-03-10 | 泰克莱克公司 | 用于将来自2g网络的短消息服务(sms)消息路由到基于会话发起协议(sip)的网络的方法、系统和计算机程序产品 |
RU2474067C2 (ru) * | 2007-02-22 | 2013-01-27 | Телефонактиеболагет Лм Эрикссон (Пабл) | Групповой доступ к услугам мультимедийной подсистемы на базе ip-протокола |
CA2711467A1 (en) * | 2008-01-23 | 2009-07-30 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for pooling network resources |
CN101983499B (zh) * | 2008-02-06 | 2014-07-23 | 诺基亚西门子通信公司 | 基于设备位置的服务器标识符采集 |
US8782286B2 (en) * | 2008-09-12 | 2014-07-15 | Cisco Technology, Inc. | Optimizing state sharing between firewalls on multi-homed networks |
-
2008
- 2008-12-26 CA CA2748403A patent/CA2748403A1/en not_active Abandoned
- 2008-12-26 EP EP08875790A patent/EP2380360A1/en not_active Withdrawn
- 2008-12-26 JP JP2011542901A patent/JP2012514363A/ja active Pending
- 2008-12-26 WO PCT/IB2008/003626 patent/WO2010073058A1/en active Application Filing
- 2008-12-26 CN CN2008801325569A patent/CN102265635A/zh active Pending
- 2008-12-26 US US13/141,539 patent/US20120143982A1/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08214059A (ja) * | 1994-10-18 | 1996-08-20 | At & T Corp | 競合的な環境内でのローカル及び市外電話通信呼の接続 |
WO2002037788A2 (en) * | 2000-11-02 | 2002-05-10 | Telefonaktiebolaget L M Ericsson (Publ) | Domain name portability |
JP2005094297A (ja) * | 2003-09-17 | 2005-04-07 | Matsushita Electric Ind Co Ltd | ネットワーク制御装置、通信端末、ネットワーク制御方法 |
KR20050083428A (ko) * | 2004-02-23 | 2005-08-26 | 주식회사 케이티 | 차세대 네트워크에서의 세션 개시 프로토콜 라우팅 시스템및 그 라우팅 방법 |
EP1950942A1 (en) * | 2005-11-15 | 2008-07-30 | Huawei Technologies Co., Ltd. | A system of realizing number portability service and a method thereof |
JP2008092578A (ja) * | 2006-10-03 | 2008-04-17 | Research In Motion Ltd | ユーザの機器デバイスから回路交換ネットワークを介してsipコールを開始するためのシステムおよび方法 |
JP2008098888A (ja) * | 2006-10-11 | 2008-04-24 | Murata Mach Ltd | 中継サーバ |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012514364A (ja) * | 2008-12-26 | 2012-06-21 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 企業ネットワークアクセスポイントの判定のための方法およびシステム |
Also Published As
Publication number | Publication date |
---|---|
EP2380360A1 (en) | 2011-10-26 |
CA2748403A1 (en) | 2010-07-01 |
CN102265635A (zh) | 2011-11-30 |
WO2010073058A1 (en) | 2010-07-01 |
US20120143982A1 (en) | 2012-06-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2012514363A (ja) | 2層の(bi−level)アドレス指定スキームを用いて通信をルーティングするための方法および通信ノード | |
US8780738B2 (en) | Method and apparatus for supporting enterprise addressing in networks | |
US9398163B2 (en) | Methods, systems, and computer program products for providing intra-carrier IP-based connections using a common telephone number mapping architecture | |
US7948967B2 (en) | Methods, systems, and computer program products for enabling non-IMS queries of a common telephone number mapping system | |
US11824903B2 (en) | Voice service restoration after element failure | |
US8571015B2 (en) | Methods, systems, and computer program products for enabling non-IMS queries of a common telephone number mapping system | |
US8867547B2 (en) | Method and apparatus for processing a call to an aggregate endpoint device | |
JP5330540B2 (ja) | 企業ネットワークアクセスポイントの判定のための方法およびシステム | |
US20140334426A1 (en) | Method and apparatus for processing a call to an aggregate endpoint device | |
JP2005515665A (ja) | インターネット・プロトコルを用いて通信するための電気通信ネットワーク用の方法および装置 | |
US8750884B1 (en) | Call routing using domain name service and electronic number mapping | |
US20220060521A1 (en) | Automated IPv4-IPv6 Selection for Voice Network Elements | |
KR100923569B1 (ko) | 위치 서버, 이를 포함하는 통신 시스템 및 통신 방법 | |
US20130017853A1 (en) | Wholesale Network User Identity Mapping in a Mobile Network | |
JP5679577B2 (ja) | 中継システム及び中継網のコーディック選択方法 | |
KR20010067254A (ko) | 멀티미디어 지능망을 위한 에이치.323 사용자, 서비스, 및서비스 제공자 이동도 구조 | |
KR20080051813A (ko) | 이종 ims망간 글로벌번호 적용방법 | |
JP4582647B2 (ja) | Sipネットワークシステムのメッセージ交換方法 | |
US20110158230A1 (en) | Method and apparatus for providing multi-homing to an aggregate endpoint device | |
JP4582646B2 (ja) | Sipネットワークシステムのメッセージ交換方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130201 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130409 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20131021 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140320 |