サービス提供プラットフォーム

サービス配信プラットフォーム（SDP ）は、顧客または他のシステムであるかどうかにかかわらず、消費者に提供されるサービスの種類に対して、サービス配信アーキテクチャ（サービス作成、セッション制御、プロトコルなど）を提供するコンポーネントのセットです。これは、電気通信のコンテキストでよく使用されますが、サービスを提供する任意のシステム（ VOIP電話、インターネットプロトコルテレビ、インターネットサービス、SaaSなど）に適用できます。^[1] TMフォーラム（TMF）はこの分野で仕様の定義に取り組んでいますが、業界ではSDPの標準的な定義はなく、さまざまなプレーヤーがSDPのコンポーネント、幅、深さをわずかに異なる方法で定義しています。

SDP では、多くの場合、IT 機能の統合と、テクノロジーとネットワークの境界を越えたサービスの作成が必要です。現在利用可能な SDP は、特定のテクノロジーまたはネットワーク ドメイン (たとえば、通信では、Web、IMS、IPTV、モバイル TV など) でのサービスの提供に最適化される傾向があります。通常、SDP は、サービスの制御、作成、オーケストレーション、実行のための環境を提供します。通信では、メディア制御、プレゼンス/場所、統合、およびその他の低レベルの通信機能の抽象化が含まれる場合があります。SDP は、コンシューマー アプリケーションとビジネス アプリケーションの両方に適用できます。

電気通信のコンテキストに限って言えば、SDP を実装するビジネス目標は、基本的なPOTS電話サービスからマルチプレイヤー ビデオ ゲーム(MPG) の複雑な音声/ビデオ会議まで、新しい統合マルチメディア サービスの迅速な開発と展開を可能にすることです。SaaS のコンテキストでは、同様のビジネス目標が達成されますが、特定のビジネス ドメインに固有のコンテキストで達成されます。

AppleのiPhoneやGoogleのAndroidスマートフォンなどのデバイス向けのアプリケーションを作成、ホスト、配信するためのアプリケーションストアの出現により、通信サービスプロバイダー（CSP）がデータから収益を生み出す手段としてSDPに注目が集まっています。^[2] SDPを使用してネットワーク資産をWeb 2.0開発者を含む社内外の開発コミュニティに公開することで、CSPは何千ものアプリケーションとその開発者のライフサイクルを管理できます。^{[3] [4]}

Telcordia Technologies、Nokia Siemens Networks、Nortel、Avaya、Ericsson、Alcatel-Lucentなどの通信会社は、1990 年代前半から中頃にかけて、通信統合インターフェイスとインフラストラクチャを提供してきました。独自の構内交換機 (PBX)システムやデスクトップ電話機の代替としてIP ベースのVoIPシステムがコスト削減に成功したことにより、業界の焦点は独自のシステムからオープンな標準技術へと移行しました。

このオープン環境への変化は、Teligent Telecom ^{[5]のようなソフトウェアに重点を置いた通信会社を引きつけ、} Tieto、Accenture、IBM、TCS、HP、Alcatel-Lucent、Tech Mahindra、Infosys、Wipro、CGIなどのシステムインテグレーターが統合サービスを提供できるようにしました。さらに、通信ソフトウェア製品会社の新しいコンソーシアムは、付加価値サービス、統合課金、コンテンツ/パートナー関係管理などの要素に基づいてSDPを作成するための事前統合ソフトウェア製品を提供しています。

SDP はテクノロジーの境界を越えることができるため、次のような幅広い混合アプリケーションが可能になります。

• ユーザーは、テレビ画面で電話の着信（有線または無線）、IM の仲間（PC）、または友人の位置情報（GPS 対応デバイス）を確認できます。
• ユーザーは携帯電話からVoD（ビデオオンデマンド）サービスを注文したり、自宅と携帯電話の両方でビデオパッケージとして注文したストリーミングビデオを視聴したりできます。
• 航空会社の顧客は、フライトのキャンセルに関する自動システムからのテキストメッセージを受け取り、音声またはインタラクティブなセルフサービスインターフェースを使用してスケジュールを変更することができます。

サービス配信プラットフォーム市場は、2019年から2024年の予測期間にわたって10％のCAGRで成長すると予想されています。^[6]

1990 年代後半には、クライアント サーバー アーキテクチャの制約が徐々に緩和され、n 層アーキテクチャの登場により、エンタープライズ アプリケーションは前例のない変化を遂げました。これは、ダム ターミナルとロジックを多用するクライアント PCの絶対的な制約の間の柔軟な妥協策であるアプリケーション サーバーの出現を意味しました。アプリケーション サーバー業界への参入者は多種多様でしたが、データベース ベンダーの抽象化、オープン スタンダード (主にオブジェクト指向) プログラミング モデル、高可用性とスケーラビリティの特性、プレゼンテーション フレームワークなど、共通の利点がありました。これらの変革は、インターネット ブームという猛烈な津波を含むビジネス要因によって引き起こされましたが、 TCP/IPプロトコル、Javaプログラミング言語、Java EE Web アプリケーション サーバー アーキテクチャなどの標準の普及なしには実現できませんでした。この変革を背景に、通信業界の急速な変化の時代が始まりました。

2000 年の最初の数年間まで、商業およびビジネス通信技術の市場は、依然として独自のハードウェアとソフトウェアで飽和状態でした。IP 技術が導入され、パケットネットワーク経由で音声データを伝送するVoice-over-IP (VoIP) と、特に企業の音声通信に関する標準化されたメディア制御のためのセッション開始プロトコル(SIP) が急速に普及するにつれて、オープン スタンダードが普及し始めました。

この新しい標準規格をサポートする環境では、音声とデータの世界の融合は、悲惨な通信/IT 統合の試みの呼び名ではなく、新しくて優れた消費者向けおよびビジネス向けサービスを生み出すための真の手段となっています。過去数年間、さまざまな SIP プログラミング ライブラリ (reSIProcate、Aricent、MjSip および HSC によるその派生ポート) や、比較的新しい SIP 規格に基づく製品が導入または急増しており、3GPPによって定義されたIP マルチメディア サブシステム規格は大きな支持を得ています。サービス配信プラットフォームの威力は、これらのサポート標準の品質と受け入れ度に大きく依存しており、幅広く適用可能なアーキテクチャ パターンとして急速に受け入れられつつあります。

現在、業界ではサービス配信プラットフォーム (SDP) の複数の定義が使用されていますが、共通の意味についてのコンセンサスは確立されていません。このため、またサービス プロバイダーが SDP をより適切に管理する方法を理解する必要があることから、TM フォーラム(TMF) はサービス配信フレームワーク (SDF) と SDF 管理の概念の標準化を開始しました。SDF 定義は、アプリケーションとイネーブラー、ネットワークとサービスの公開、オーケストレーションなど、関連するさまざまなコンポーネントを参照するために必要な用語と概念を提供します。

複数の SDP からエンド ユーザーにパーソナライズされたサービスを組み合わせて提供するために必要なのは、共通のサービス イネーブラーとネットワーク リソースを通じてそれらの SDP を相互運用する手段です。ただし、これらのサービスの側面の基盤となっているのは、ユーザーの属性とユーザーが受けるサービスには、LDAP/X.500 ディレクトリや HSS データベースによって提供されるものなどの共通のリポジトリと共通のデータ モデルが必要であるという基本的な概念です。この種の初期の SDP 実装は、1990 年代中期から後半にかけて ISP 統合サービス向けに開始されました。過去 5 年間で、より大規模で複雑な SDP が MSO タイプの環境やモバイル オペレーター向けに実装されてきました。

SDP は、一般的に、顧客のアクセスおよびネットワーク インフラストラクチャを OSS システムおよび BSS システムと相互接続するコア システムとして、通信事業者タイプの環境向けと見なされます。このコンテキストでの SDP は、通常、携帯電話などの特定のサービス体制または統合サービスに関連付けられます。

SDP は、かなりの予算を必要とする非常に大規模な変換、コンバージェンス、統合プログラムのコンテキストでも検討されます。このようなプロジェクトで難しいのは、アーキテクチャが合意された後、数十万の設計および実装の決定を行う必要がある場合があることです。当然、この問題だけでも、ソフトウェア開発と運用エンジニアリングのスキルが必要になります。おそらく、これらの設計および統合の問題を軽減する最善の方法は、大規模なプロジェクトが実際に開始される前に、小規模システムで SDP をシミュレートすることです。これにより、アーキテクチャが運用、サービス提供、およびビジネス要件を満たしていることを検証できます。

SDP は、オペレータ内のコア機能としてだけでなく、冗長性のため、およびさまざまなビジネスおよび市場セクターに対するさまざまなサービス プロファイルのために、相互接続された分散サービス ノード (例) として考慮する必要があります。多くのオペレータは、バンドルされた音声、Web ホスティング、VPN、メール、会議、メッセージング機能などの商用規模/グレードの製品を政府および法人の顧客に提供しています。このようなバンドルされたサービスは、断片化された管理システムから「仮想プライベート サービス環境」へと進化する可能性があります。この環境では、オペレータは、オンデマンドで制御可能なサービスを必要とする各顧客に対して専用の SDP を実行します。

SDP は、ショッピング モール、空港、老人ホーム、アウトケア センターなどの独立したワイヤレス対応地区の管理にも使用できます。

多くの場合、通信ソフトウェア開発者の主なアクセス ポイントであるサービス作成環境 (SCE、アプリケーション作成環境または統合開発環境とも呼ばれる) は、公開するサービスを表すソフトウェア、スクリプト、およびリソースを作成するために開発者によって使用されます。これらは、基本的な Eclipse プラグインから、完全に抽象化されたメタデータ駆動型の通信アプリケーション モデリング アプリケーション (Avaya の廃止された CRM Central 製品など) まで、複雑さの範囲が広くなります。

SCE の目的は、新しい通信サービスの迅速な作成を促進することです。マーケティングなどの要素を当面無視すると、開発者が特定のプラットフォーム向けのサービスを作成しやすくなるほど、利用可能なサービスの数が増え、より広範な通信市場でプラットフォームが受け入れられるようになります。したがって、通信インフラストラクチャ プロバイダーは、迅速なサービス作成を可能にする SDP によって大きな利点を得ることができます。

統合された Java EE と SIP のサービス作成環境を活用することで、サービス配信プラットフォームの採用が加速しました。従来 IT アプリケーションに重点を置いていた Java ベースのアプリケーション開発者は、Java EE と、SIP やParlay X Web サービスなどのネットワーク接続プロトコルを使用して、リアルタイム通信アプリケーションを開発しています。ソフトウェア ベンダーは、これらのテクノロジ (Oracle Jdeveloper、基本的な Eclipse プラグインを備えた Oracle Communication and Mobility Server など) を組み合わせて、より幅広い開発者層にリーチしています。

サービス実行環境 (SEE) は、SCE で開発された通信サービスを実行するために使用されます。実行環境は通常、特定のサービスが実行されるハードウェアを模倣するように設計されます。SEE は、IDE として SCE にバンドルされる場合があります。

SDP の 1 つの側面は、新しい「プレゼンス ポイント」を中心とする必要があることです。これは、ユーザーの好みと権限がリアルタイムで評価される、統合サービスへのユーザー アクセス ポイントです。好みと権限の処理により、ユーザーのデバイス/場所のコンテキストでユーザーのサービスが正しく提供されることが保証されます。権限はオペレーターの製品およびサービス管理体制に関連しているため、SDP のコア アーキテクチャでは、管理対象の製品、サービス、ユーザー、好み、権限のプロセスを定義する必要があります。

標準の実装は、プレゼンス アプリケーションにおいて依然として重要な要素です。SIP や SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions) などの標準の実装は、ますます普及しつつあります。SIMPLE プレゼンスは、SIMPLE クライアント (ウォッチャー) とプレゼンス サーバー (プレゼンス エージェント) 間のプレゼンス情報を操作するための、標準のポータブルで安全なインターフェイスを提供します。SIMPLE プレゼンスについては、JSR 164 を参照してください。SIMPLE プレゼンス サーバーのプロバイダーには、Oracle や Italtel などがあります。

SDP 間および SDP 内のインターフェースを公開するための標準を使用すると、次の 3 つの主要領域での統合の必要性が最小限に抑えられます。(1) 基盤となるネットワーク コア コンポーネントへのサウスバウンド (2) CRM、課金、サービス アクティベーションなどのサポート アプリケーション間 (3) サード パーティ アプリケーションとサービス。サービス指向アーキテクチャ(SOA) の実装では、標準インターフェースと Web サービスが使用される場合があります。

ソフトウェア ベンダーには、HP、wwite、IBM、Oracle、Sun microsystems などがあります。ネットワーク機器ベンダーも、IMS、IPTV、モバイル TV などの SDP を提供し、これらの SDP の進化形を提供しています。

近年、サービス指向アーキテクチャ⁽ SOA)の概念が盛んに^{議論されています。かつて}はエンタープライズ アプリケーション統合​​(EAI) のテクノロジと概念が中心だった議論は、SOA の領域に移行し、単純なメッセージの適応や抽出、変換、ロードの手法よりも、サービスの構成などのアイデアが好まれるようになりました。

SOA は SDP 内のアプリケーション統合テクノロジとして使用できますが、トランザクションOSSおよびBSSアプリケーションと SDP間の接続など、パフォーマンスが低い機能で使用する場合に最適です。SOA は、統合されたイベント型サービスによって SDP に課されるリアルタイムの要求を満たすには、慎重に検討する必要があります。

SOA の領域で SDP に類似した概念として、Web サービス エコシステム (Web サービス マーケットプレイスとも呼ばれる) と SaaS プラットフォームがあります。Web サービス エコシステムは、参加者がHTTP、XML、SOAP、RESTなどの一般的な Web テクノロジを使用してサービスを公開するホスト環境です。このホスト環境は、認証、 ID 管理、使用状況の計測と分析、コンテンツの適応、データ形式の変換、課金と支払いなどの側面をカバーする、多数のサービス配信コンポーネントを提供します。これにより、サービス プロバイダーはコア機能に集中し、サービス配信をサード パーティにアウトソースできます。Web サービス エコシステムで展開されるサービスはビジネス クリティカルな場合がありますが、通常、SDP が従来想定されていた通信サービスに関連するリアルタイム性と高パフォーマンスの要件はありません。通常、見積もり、注文管理、マーケティング キャンペーン管理、顧客ケアなどの一般的なビジネス機能をサポートします。SOA は、運用プロセスを標準化し、SDP 間で再利用するためにも使用できます。

現実世界でリアルタイムの統合サービス、運用 SDP を実装するには、IT およびネットワーク アーキテクチャに大幅な変更が必要です。多くの SDP は、「サービス抽象化レイヤー」などのラベルを使用した図を含む抽象的なフレームワークとして設計されています。実際のシステムでは、このような「レイヤー」は実際には存在しません。さらに、抽象的な図から、現実世界の運用データ モデルが何であるか、統合サービス SDP およびセルフケア機能を形成するために使用または統合されるサーバー、データベース、またはディレクトリの数が何であるかを把握することは困難です。オペレーターは、システムの年間数百万ドルの電気料金に直面する可能性があります。したがって、同じ機能を統合して消費電力を大幅に削減できる場合、マルチサーバー/マルチデータベース SDP は環境に優しくなく、コスト効率も良くありません。

アイデンティティと情報の管理: SDP を指定または設計するには、顧客とデバイスのサービス ディメンションが何であるかを決定する必要があります。SDP 設計で、たとえば 100 万のユーザーに対応してデバイスを管理する必要があり、識別された各項目に 5 ～ 10 個の情報オブジェクトが必要な場合、コア SDP はおそらく 2000 万個のオブジェクトをリアルタイムで処理します。これらのオブジェクトの管理によってプラットフォームのコア アイデンティティ管理プロセスが決まることから、実装方法には細心の注意を払う必要があります。経験上、統合サービス SDP の 1 人のユーザーは、100 個の情報オブジェクトを必要とし、設定などの一部のオブジェクトには 100 個の属性が含まれる場合があります。1000 万のユーザーに対する容量要件は、プラットフォームが 10 億個のオブジェクトと最大 500 億個の属性をサポートする必要があることを示しています。

グループ ID と権限:従来、ID 管理は、名前とパスワードを使用してログオンする単一のユーザーまたはデバイスとして扱われ、名前とパスワードを保持する Identity Server が問題を解決するものと想定されていました。しかし実際には、MSO の世界では、アカウント所有者、セカンダリ アカウント所有者 (家族の子供)、ゲスト、ギフト、コンテンツ、デバイス、設定があり、管理されたサービスを受けるためには、これらすべてをリンクする必要があります。グループ化された ID が受け取るサービスは、名前とパスワードによって承認される場合がありますが、製品のプロビジョニングに関連する権限を通じてのみ有効にする必要があります。SDP アーキテクチャは、グループ ID 管理と製品/サービス権限機能に対応する必要があります。

プレゼンスとイベント:プレゼンスは、すべてのオンライン アセットのステータス管理です。しかし、これはシステム アーキテクチャにとって何を意味するのでしょうか。従来、たとえばユーザーがログオンして、ネットワーク スイッチ、Web サーバー、またはデータベース アプリケーションにトランザクションを作成するという「トランザクション」パラダイムを適用してきました。プレゼンス サービスとは、従来のトランザクション システムよりもはるかに高い速度でステータス イベントを管理することを意味します。問題は、断片化されたシステム、複数のデータベース アーキテクチャ、または実際にはフレームワークで、数百万、あるいは数十億のイベントをどのように管理するかということです。SDP アーキテクチャには、コア機能として、一貫性があり、高度に統合されたイベント管理システムも必要です。

統合アイデンティティ: 3G IMS と SIP および統合サービスでは、運用上の問題が浮上します。SIP は、メッセージの To、From、Via、および Contact フィールドに IP アドレス (IPv4 または v6)、SIP URI (電子メール アドレス)、および SIP TEL URI (電話番号) を適用できます。このような識別子は、電話機、冷蔵庫のドア、コンテンツ ファーム、単一のコンテンツ、ユーザー、またはユーザー グループを指すことができます。この柔軟性により、SIP コールは、権限があれば、ほぼあらゆるものから他のあらゆるものに行うことができます。SIP は、コール プロセスでこれらのインターネット システムと電話システムの識別子を組み合わせて適用できるため、SDP は SIP 処理を DHCP システムとDNS、HSS モバイル データベース、ユーザー認証システム、プレゼンス イベント システム、ユーザーのアドレス帳、電話コール機能処理、およびオペレータのサービス/製品管理と権限付与システムと緊密に結合させる必要があります。これらはすべてリアルタイムで行われます。したがって、このような機能を「SOA」を使用して相互接続された多数の機能や断片化されたデータベースに適用することは非常に困難になります。

SDPテクノロジーとツールキットは、3つの基本的な問題に対処する必要があります。^{[引用が必要]}

1. オペレータと顧客セルフケア システムによってリアルタイムで提供および管理されている商品とサービスは何ですか。これには、プレゼンス ベース サービス (イベント駆動型インターネットの世界) の管理と、リアルタイムのユーザー権限の処理方法が含まれます。
2. SDP 設計で使用される統合サービス情報モデルとは、加入者、デバイス、電話、設定、権限、アドレス帳などを扱うオペレータのオンライン ビジネスを表すものです。多くの場合、顧客数が 1,000 万人の MSO でも 5 億の情報項目を持つ SDP が必要であり、これらの項目はさまざまな SDP 機能によって 1 秒間に何千回もアクセスされます。
3. SDP 設計でオンライン ビジネス イベントの速度を処理するために使用されるイベント/プレゼンス管理アーキテクチャとは何ですか。状況としては、夜に帰宅する都市の住民が数十億のオンライン ステータス イベントを生成する可能性があります。これらは SDP によってどのように処理されますか。

これら 3 つの主要なシステム要件は、論理モデル、SOA、メッセージ バス プロトコル、サーバー相互接続に適用する「抽象的なラベル」に関係なく、実際に運用される SDP のアーキテクチャを決定します。これらの基本的な要件が SDP 設計から省略されると、オペレータは次のような多くのビジネス、サービス管理、運用上の問題に対処する必要があります。

• アイデンティティ管理（オペレーターのオンライン資産を表すSDP内のすべての情報）、
• SDP のサービス敏捷性 (つまり、提供される製品とサービスは SDP にハードコードされており、新しいサービスによってコードがアップグレードされる)。
• ハードワイヤードなセルフケア設備（言語、年齢、視力、好みなど、SDP ユーザーの柔軟性や配慮がない）。

状況によっては、MSO のシステム内にハードコードされた製品およびサービス管理フローが何百万行もあり、新しい統合サービス ディメンションに簡単に移行できないことがあります。

SDP 設計の簡単なテストは、情報モデルを評価し、それが統合サービスのユーザー環境に基づいているかどうかを確認し、そのモデルがプレゼンスおよびイベント管理機能を組み込む必要があるすべてのシステムによってどのように使用および管理されるかを確認することです。

SDP 開発とリアルタイムで機敏なサービス提供への進化をサポートするために、次世代システム^{[引用が必要]}を検討する必要があります。

• ディレクトリ サービスは SDP 内で重要な役割を果たします。「ディレクトリ サービスとID 管理」を参照してください。
• IP マルチメディア サブシステム
• 次世代ネットワーク
• エンタープライズアプリケーション統合によく使用されるエンタープライズサービスバス統合プラットフォーム
• Javaビジネス統合Javaの世界におけるエンタープライズサービスバスの標準化
• 3GPP標準
• ネットワーク要素、運用サポートシステム、ビジネスサポートシステムの統合に関するオープンモバイルアライアンス標準
• Parlay Group、Parlay Xネットワーク要素、運用サポートシステム、ビジネスサポートシステムの統合に関する標準
• JSLEE、Java Service Logic Execution Environment、サービス配信プラットフォームで使用されるイベント駆動型アプリケーション サーバーの Java 標準
• セッション開始プロトコルIP通信の標準プロトコル
• 運用サポート システム向けJava 仕様要求(JSR)
• サービス提供フレームワーク