Dsl-home
DSL-ホーム
DSL Homeは、DSL-Forumが主導するイニシアチブです。 以下のポイントでは、さまざまな機能と利点について説明します。
- 住宅用ゲートウェイ、VoIPデバイス、ホームデバイスのローカルおよびリモート管理などのホームデバイスに関連する要件を定義するため。
- 音声、ビデオ、IPTVを含むデータ、オンデマンドビデオ、コンテンツオンデマンドなどのエンドユーザーへのトリプル/クワッドプレイサービスを有効にするには
- DSL Homeリモート管理プロトコル(TR-69)およびその拡張機能は、アクセスに依存しません。
- リモート管理は、DSLホームまたは次世代のレジデンシャルゲートウェイ(RG)およびホームネットワークのコア*です。
- DSL Homeグループは、CPE要件とCPEデバイスの管理に関する標準を策定しました。
- 要件を定義する標準-
- WT-124-TR-068の問題2 -DSLに固有ではなく、xPONなどの他のアクセステクノロジーを含む完全なRG要件を定義するレジデンシャルゲートウェイ。
- TR-122 は音声ATA要件を定義します。
- 管理フレームワークの標準-
- TR-64 -LAN側のCPEの構成と機能強化。 +ローカルLANインターフェイスを介したCPEデバイスの構成と管理用。 + TR-69 -CPE Wan管理プロトコル+リモート側を介したCPEデバイスの構成および管理用。
- TR-111 -ホームネットワーク(HN)内のデバイスのTR69リモート管理を許可します。
- TR-98およびTR-133 -それぞれTR-69およびTR-64を介したCPEデバイスのサービス差別化(QoS)パラメーターの構成と管理。
- TR-104 VoIPサービスのデータモデル +ビデオサービスにも拡張。
- TR-106 は共通データモデルテンプレートを定義します +ベースラインオブジェクト構造とTR-69デバイスのアクセス可能なパラメーターセットを定義します。
- TR-122 -音声ATA要件を定義します。
- WT-135 -STBデバイスのオブジェクトモデル。
- WT-140 -オブジェクトモデルネットワークストレージデバイス。
- WT-142 -TR-069対応のPONデバイスのフレームワーク。
DSLテクノロジーオプション
次の表に、さまざまなDSLテクノロジーオプションの詳細を示します。
Family | ITU | Name | Ratified | Maximum Speed capabilities |
---|---|---|---|---|
ADSL | G.992.1 | G.dmt | 1999 |
7 Mbps down 800 kbpsアップ |
ADSL2 | G.992.3 | G.dmt.bis | 2002 |
8 Mb/s down 1 Mbpsアップ |
ADSL2plus | G.992.5 | ADSL2plus | 2003 |
24 Mbps down 1 Mbpsアップ |
ADSL2-RE | G.992.3 | Reach Extended | 2003 |
8 Mbps down 1 Mbpsアップ a |
SHDSL (2003年に更新) |
G.991.2 | G.SHDSL | 2003 | 5.6 Mbps up/down |
VDSL | G.993.1 | Very-high-data-rate DSL | 2004 |
55 Mbps down 15 Mbpsアップ |
VDSL2 -12 MHz long reach | G.993.2 | Very-high-data-rate DSL 2 | 2005 |
55 Mbps down 30 Mbpsアップ a |
VDSL2-30 MHz 短距離 |
G.993.2 | Very-high-data-rate DSL 2 | 2005 | 100 Mbps up/down |
自宅での収束
複数のブロードバンドおよびネットワーキングテクノロジーは、次のような次世代デジタルホームに収束しています-
- ADSL2/ADSL2 Plus/VDSL2/xPON。
- ワイヤレス/イーサネット/USB/HomePlug A/V、HPNAなど
- 家電はネットワーク化を開始します。
このようなコンバージェンスの管理は複雑であり、エンドデバイスのプロビジョニングとメンテナンスを簡素化する必要があります。
課題-家庭内のさまざまな要素を管理するには?
ソリューション-基本的にホームネットワーキングは、Conexantが作成するすべてのネットワーキングテクノロジーとテクニックの縮図を表しています。 収束は家庭で最初に起こっています。
現在、ホームネットワークデバイスをセットアップおよび構成するには、ITの専門家である(または家に10代の若者がいる)必要があります。 Industry、Applications and Technology Trendsのプレゼンテーションで述べたように、ホームネットワークデバイスの30〜50%が問題なく小売業者に返されます。 ユーザーは、既存のツール/ソフトウェアを使用してデバイスをセットアップおよび構成することができませんでした。
既存のアプローチの問題
以下は、既存のアプローチの問題です。
ユーザーの視点
- 既製の機器を購入する柔軟性はありません。
- 機器を購入した場合、サービスプロバイダーからのサポートはありません。
- デバイスは、ISPとユーザーの両方が何らかの構成を行う必要があるプラグアンドプレイではありません。
- 新しいサービスを追加するには、ISPとエンドユーザーの両方の調整が必要であり、時間がかかります。
- トラックのロールが関与する場合は、自宅で顧客の存在が必要です。
- 最近はより多くのカップルが働いているため、一致させるのは難しいかもしれません。
サービスプロバイダーの視点
- 新しいサービス、トラブルシューティング、および新しいインストールを有効にするには、トラックロールが必要です。 各トラックのロールは、時間とリソースの面でかなりのコストを追加します。
- お客様が苦情を申し立てる場合、「ヘルプデスク」がオフィスに座ってCPEデバイスの何が問題なのかを確認することは非常に困難です。
- ベンダーは、独自の独自のソリューション、さまざまなインターフェイス、パラメーター、手順を提供します。 したがって、ベンダーごとのソリューションのトレーニングが必要です。
- ISPは、仕事を簡単にするためにカスタムオートメーションを行っているため、ISPは少数の選ばれたベンダーに固執しました。 新しいベンダーに切り替えるには、カスタムオートメーションを変更する必要がある場合があります。
- デバイス機能を自動的に検出し、サポートされているパラメーターを判別する方法はありません。
- Web、CLI、SNMPなどのローカル管理インターフェイスを介してユーザーが構成情報を変更したかどうかを判断することはできません。
- ユーザーが設定を変更することを防ぐことはできません。ユーザーが提供するサービスに影響する可能性があります。
DSL Homeが提供するサービス-TR-69
以下は、DSL Home-TR-69が提供するサービスのリストです。
- 安全な方法でのデバイスのリモート管理(SSL/TLSベースのセキュリティを使用)。
- 自動構成によるサービスのリアルタイムプロビジョニング。
- ステータスとパフォーマンスの監視。
- 診断
- アクセス制御
- お知らせ
- ファームウェアのアップグレード
- 音声、ビデオ、データ、IPTVなどのさまざまなサービスを提供するCPEデバイス用に特別に調整された標準化されたデータモデル。 イーサネット、USB、WLANなどの異なるLANテクノロジー上のホームセグメント(STB、VoIP、NAS)のLANデバイスを幅広くカバーします。
- 管理プロトコルは、テクノロジーの不可知論にアクセスすることであるため、さまざまなCPEデバイスに使用できます。 たとえば、xPON、xDSLなどでは、デバイスがIPアドレス指定可能である必要があります。
- Truckrollは、リモート管理によって最小化されます。
- ヘルプデスクは、苦情を申し立てるだけでなく、より良いサービスを提供できます。 ヘルプデスクにはより多くのコンテキストがあり、リモートからCPEに関する完全な構成情報を表示できます。
- データモデルはサービス用に標準化されているため、ベンダー固有のトレーニングは必要ないため、スタッフをトレーニングする必要が少なくなります。
- カスタムの自動化が不要なため、より幅広いベンダーベースから選択できます
- デバイスで使用可能なパラメーターの自動検出を提供します。
- アクセス制御を提供するため、ユーザーが特定の構成を変更することを防止できます。
- 通知メカニズムを提供するため、サービスに関連する構成の変更を知ることができます。
- 運用コストを削減します。
- ユーザーおよびサービスプロバイダーがモデムやベストエフォートルーターを超えてデジタルホームのトリプル/クワッドプレイサービスに移行しやすくします。
TR69-展開シナリオ
次の図は、TR69展開シナリオを示しています。
TR69-Deploymentは、次の機能に役立ちます-
- 家庭内の同時ユーザーにサービスを提供する安全なネットワークソリューション
- トリプル/クアッドプレイサービス(テレビ/ビデオ、電話、インターネット、ワイヤレス)
- 自動構成によるサービスのリアルタイムプロビジョニング
- そのようなプロビジョニングのサポートを管理および自動化するメカニズム
WT-124 ⇒ TR-068v2は、拡張スコープに基づく新しい要件を追加します-
- 光(PON)WAN側のイーサネットポートの要件
- 診断要件のWebリダイレクト
- DHCPクライアントの要件 *ACSは、キャプティブポータルの要件を開始しました。
ネットワーク接続の問題が発生した場合、Webリダイレクトが必要です。* RGは、Webブラウザページをインターセプトするメカニズムを提供する必要があります(つまり、 ポート80のWebページ要求)およびWebブラウザを適切な内部Webページに誘導してこれらに応答し、以下を含むがこれらに限定されないネットワーク接続の問題を特定および解決します-
- DSLはトレーニングできません。 − Q. 適切なPHYポートからWebにこれを取得する方法は?
- DSL信号が検出されません。 − Q. 上記と同じ質問。
- ブロードバンドイーサネットが接続されていない(該当する場合)。
- ATM PVCが検出されません(該当する場合)。
- IEE 802.1x障害(該当する場合)。
- PPPサーバーが検出されません(該当する場合)。
- PPP認証が失敗しました(該当する場合)。
- DHCPは使用できません。
例-TR-069プロトコルの機能
次の図は、TR-069プロトコルの機能を示しています。
上記の図は、次の点で説明されています。
- TR-069は、エンドユーザーデバイス(RG、STB、VoIP)の構成と管理を可能にします。 DSLフォーラムのアプローチの大きな違いは、TR-069がエンドユーザーデバイスに直接アクセスできることです。
- 接続-リモートプロシージャコール(RPC)の送信に基づく汎用メカニズム。これにより、ACSは PE のパラメーターを読み取りまたは書き込み、CPEを監視および制御できます。 RPC、SOAPメッセージ(標準XMLベースの構文)、SSL/TLS(セキュリティレイヤー)、HTTP、TCP/IP接続、CPEと管理サーバー間で転送されます。
- (注)-SNMPは、マネージャーとエージェントの間でUDP上にProtocol Data Unit(PDU)を送信します。 UDPは、TCPと比較すると信頼性が低く、PDUサイズはUDPフレームサイズに制限されています。
- * ACSディスカバリ*-
- CPEは、DHCPを使用して、関連付けられているACSを検出できます。
- 手動構成-ACSのURLを使用してCPEをローカルに構成できます。
- デフォルト設定-CPEには、他のURLが提供されない場合に使用できるデフォルトのACS URLがあります。
- セッション(セットアップおよびティアダウン)-事前に決定されたACSアドレスを使用して、常にCPEからACSに開始されたセッション:セットアップおよびセッションTearDownのInform RPCメソッドを発行します。
- (注)-SNMPはセッションの概念をサポートしていません。 クライアントは、サーバーからのメッセージを特定のUDPポートでリッスンする必要があります。
- 状態管理-
- 単一のセッションを形成する一連のトランザクションの場合、CPEは、セッションの間持続するTCP接続を維持します。
- 連続TCP接続が不可能な場合、ACSはセッションCookieを使用してセッション状態を維持します。
- CPEは、交換されたすべてのメッセージでACSによって設定された情報(Cookie)を返します。 セッションの終了時に、CPEはACSへの関連TCP接続を終了し、すべてのCookieを破棄します。
セキュリティ
すべての通信を開始するCPEによってTR-069によりセキュリティが強化されます。 セキュリティTR-069プロトコルは、次の2つのセキュリティ(レベル)メカニズムをサポートしています-
- SSL/TLSは、CPEとACS間の証明書ベースの認証を定義して、単一の安全な接続を提供します
- CPEは同じx.509証明書を使用して暗号化を提供できます。
広く実装されたHTTP認証を介して認証されたクライアントデバイスは次のとおりです-
- TR-069およびエンドデバイス-*
- TR-069は管理のためにACSで使用できます-
- レジデンシャルゲートウェイ(RG)
- TR-111に基づくエンドデバイス(ED)
- 2つのアプローチ-
- RGはEDのプロキシとして機能します
- EDはACSによって直接管理されます
- TR-111は許可する追加のルールを定義します-
- LAN内のTR-069対応EDを検出するRG
- ACSは、TR-069 RG以外でもTR-069 EDに接続します(STUNを使用、RFC 3489)
TR-064 LANサイドCPE
TR-069 LAN側のCPE設定の機能は次のとおりです。
- UPnP v1.0アーキテクチャを採用し、UPnP IGD v1仕様を拡張します(いくつかの制限があります)。
- 管理アプリケーション(TR-64コントロールポイント)はPC上で実行され、CPEがネットワークに追加されると、サービスプロバイダーと顧客固有の構成をCPEにプッシュします。
- 新しいCPEデバイスの初期インストール中およびWAN側の接続の問題がある場合により便利です。
TR-64展開シナリオ
次の図は、TR-64展開シナリオを示しています。
DSLホームサービスの使用例
DSLホームサービスの次のユースケースを考えてみましょう。
ユースケース-1
顧客は最初にデータ用にブロードバンドサービスを購入し、現在はVoIPサービスに加入する必要があります。
顧客は、SPのウェブサイトを介して新しいサービスリクエストを伝えるか、オフィスに電話することができます。 これらのサービスを提供するために、SPは次の質問に対処する必要があります。 かどうか-
- *オプション1 *-既存のCPEのハードウェアは、要求に応じて新しいサービスを提供できます。
- *オプション2 *-ハードウェアは使用可能ですが、ファームウェアのアップグレードが必要です。
- *オプション3 *-ハードウェアとファームウェアの両方に対応しており、VoIPサービスの設定のみが必要です。
ここで、各オプションを詳細に理解しましょう。
- 最初のオプションでは、SP(サービスプロバイダー)は、VoIP対応のCPEを提供するためにトラックロールを必要とするか、契約に応じてユーザーに市場からデバイスを購入するように依頼できます。
- 2番目のオプションでは、SPはこのCPEデバイスのACSでファームウェアアップグレードおよびVoIP設定要求をキューに入れることができます。 CPEをオンにすると、TR-69を介してCPEで自動的に構成され、ACSに変更が通知されます。 サービスプロバイダーは、サービスを正常に構成するためのイベントを取得したら、ユーザーに電子メール/SMSで通知するようにACSを構成できます。
- 3番目のオプションでは、ACSでVoIPサービス構成要求をキューに入れるだけです。 CPEのスイッチがオンになると、ACSはCPEデバイスの構成を自動的に更新します。 サービスプロバイダーは、サービスを正常に構成するためのイベントを取得したら、ユーザーに電子メール/SMSで通知するようにACSを構成できます。
ユースケース-2
サービスプロバイダーは、ファームウェアのアップグレードを一括で行う必要があります。
SPはすでに何百ものデバイスを展開しており、基本的なサービスレベルを上げるか、何らかの形でサービスに影響を与える可能性のある重大なバグを見つけるため、ファームウェアのアップグレードが必要です。 私たちは次の点を考慮しましょう-
- TR-69管理ソリューションでは、ACSは、デバイスで使用されるハードウェアバージョン、ファームウェアなどのCPEに関する完全な情報を保持する必要があります(この情報は、各セッションセットアップでCPEによって渡されます)。
- オペレーターはCPEデバイスを識別できますが、すべてのデバイスで必要になるわけではないため、アップグレードが必要になる場合があります。
- ACSから、選択したCPEへのファームウェアアップグレードリクエストを時間をずらしてスケジュールできます。
- CPEファームウェアが更新されると、ファームウェアが正常にアップグレードされたCPEのリストを知る必要があります。
- これらはすべて、快適なオフィスからフィールドに出ることなく行われています。
ユースケース− 3
顧客は、音声/ビデオサービスの品質が限界に達していると報告しています。
これは、次の点に付着することによって対処することができます-
- 音声/ビデオの品質に影響する可能性のあるパフォーマンスパラメータを監視して、トラブルシューティングを行い、エンドカスタマーに期待される品質のエクスペリエンスを提供します。
- 音声、ビデオ、およびデータに差別化されたサービスを提供するために、顧客とのサービスレベル契約に従って、必要なQoSパラメーターを構成できます。
ユースケース-4
顧客は接続の問題に直面しており、一部のサービスの問題を報告してから、サービスプロバイダーは次のことができます-
- SPはCPEで診断を実行して、問題をトラブルシューティングできます。
- CPEで診断パラメータを設定でき、診断が完了すると、ACSに完了が通知されます。 その後、ACSはTR-69を介してリモートで結果を取得し、問題を診断できます。
- 全体として、SPは外出せずに原因を把握しているため、状況をより効果的に処理できます。
DSLホームロードマップ
次のポイントは、DSLホームロードマップについて説明しています。
- TR-069の相互運用性-
- Plugfestイベント-3はすでに完了しています。
- 最後のイベントでは、22のCPEと11のACSベンダーが参加しました。
- 検討中のTR-069またはDSL Home認証。
- 進行中の多くのWT:ACSノースバウンドインターフェイス、新しいサービスオブジェクトモデル、QoS、新しいRG仕様、テストおよび相互運用性テストケースなど
- UPnPフォーラム、DLNA、HGIなどと連携して連携し、ホームセグメントのデバイスに対する標準を定義します。
- ITU-T SG16、Home Gateway Initiatives(HGI)、ATIS IPTV Interoperability Forum(IIF)など、ごく少数の標準団体が家庭用デバイスのリモート管理に関するTR-69標準を受け入れています。
- Direct Video Broadcast(DVB)組織(ETSI規格)は、IPTV STBリモート管理またはCableLabsの代替としてTR-069およびWT-135を採用しました。
- 複数の研究グループを含むITU-T IPTVフォーカスグループも、リモート管理プロトコルの問題に対処します。
TR-69 vs SNMP
IETF(Internet Engineering Task Force)は、さまざまな機能と機能を管理するために多くのMIBを定義しています。 ただし、標準団体またはIETFによる統合は行われません。IETFは、MIBのセットを使用して、構成およびサービスプロビジョニング用のCPE(特にトリプルプレイサービスを提供するホームゲートウェイ)デバイスを管理することを推奨します。 CPEデバイスでのMIBサポートは、独自の実装に関して選択するベンダーに完全に委ねられています。 DSL Home傘下のTR-69およびその他のTRは、そのようなタイプのサービスのためにCPEデバイスで必要な一連のパラメーターを定義します。 それは、サービスの各タイプに適用可能なパラメータのセットをお勧めします-
- ベンダーは独自のMIBを使用してソリューションを提供しているため、これらのデバイスの管理はベンダー固有です。
- CPEデバイスのみに固有のファームウェアアップグレード、診断などのシステムサービスに使用できるMIBはありません。
- SNMPを使用するには、ほとんどのホームゲートウェイがNATを使用し、管理対象のデバイスがNATの背後にある可能性があるため、NATを介してSNMPポートを開く必要があります。 SNMPでは、パラメーターの取得/設定要求は常にマネージャーによって開始されます。 したがって、要求を取得するには、CPEでポートを開く必要があります。 TR-69では、TR-69セッションはCPEによって開始され、サーバーは同じセッションを使用してget/set要求を送信します。 これにより、NAT環境でポートを明示的に開く必要がなくなります。 TR-69では、ACSがリクエストをCPEに送信できる方法も定義されており、この部分はTR-111 part2によって透過的に処理されます。
- 現在存在するSNMP実装のほとんどは、SNMPv3を実装していません。 したがって、SNMPを介して交換されるメッセージはあまり安全ではありません。 TR-69では、セキュリティはSSL/TLSまたはHTTPベースの認証スキームによって管理されます。 現在のTR-69実装のほとんどは、SSL/TLSを実装しています。
- CPEからマネージャへの指示は、トラップの観点から対処する必要があり、これらのトラップはMIBで事前に定義する必要があります。 これらのトラップが定義されると、マネージャは、トラップ条件でトラップを生成する必要があるかどうかにかかわらず、CPEを制御できません。 TR-69は、サーバーに対するパラメーターの変更を通知するための非常に一般的な方法を定義しています。 追加のトラップを定義する必要はありません。この機能はプロトコル自体に組み込まれており、マネージャーがパラメーターの通知を必要としない場合は、プロトコルを使用してオフにすることができます。 さらに、TR-69はアクティブまたはパッシブ通知メカニズムを提供しますが、これはSNMPにはありません。
- 別の管理プロトコルを介して変数にアクセスするためのアクセス制御メカニズムはありません。 TR-69は、どの管理プロトコルがどのパラメーターとどのレベルのアクセス(読み取り/読み取り/書き込み)を制御できるかを指定できるメカニズムを定義します。 この機能は、サービスプロバイダーが、変更された場合にエンドユーザーサービスに影響を与える可能性のある一連のパラメーターを制御する場合に非常に便利です。 SNMPはこのレベルの粒度を定義しません。
- 通常、SNMPは通信メカニズムとしてUDPを使用しますが、これはそれほど信頼性が高くありませんが、TR-69はHTTP over TCPを使用します。
- SNMPエージェントでは、SNMPマネージャーアドレスとコミュニティストリングを設定する必要がありますが、TR-69ではACS固有のパラメーターを設定することは必須ではありません。 ACS関連のパラメータは、オペレータが設定しない場合、DHCPベースのメカニズムを介して動的に発見できます。
- SNMPベースの管理を通じて、サポートされるアクションはget/getnextおよびマネージャーからの設定のみです。 デバイスの管理が他の独自のアクションまたはファイルのダウンロードを必要とする場合、TR-69の間は実行できません。 これは、ベンダー固有のRPCを定義することで簡単に実現できます。 既存のRPCメカニズムを使用して、CPEとACSの間の同じセッションでファイルのダウンロードを実現することもできます。
- トリプルプレイサービスをサポートするCPEデバイス用にカスタマイズされたMIBはありません。
- 各ベンダーは、std +独自のMIBに基づいて独自のソリューションを提供します
- SNMPを使用するには、デバイスのSNMPポートを開く必要があります。
- SNMPベースの管理のほとんどは、SNMPv3を実装していません。 したがって、セキュリティが侵害されます。
- パラメータのパラメータ変更に関する通知の実装は困難です。
- 通知の有効化および無効化の制御はありません。
- アクセス制御の規定はありません。
- UDPベースの配信方法の使用。これはあまり信頼できません。
- デバイスは一度に複数のマネージャーによって管理され、同期が追加されます。
- 特定のアクションセットのみがサポートされます。
- SNMPで達成できるものはすべて、TR-69などで実現できます。
結論
- DSL Home仕様のスイートは、次世代のレジデンシャルゲートウェイ(RG)ソリューションを定義します。
- ユーザーおよび電話会社がモデムやベストエフォートのブリッジング/ルーティングをトリプル/クワッドプレイサービスに簡単に移行できるようにします。
- TR-069(CWMP)はDSL Homeの中核です-
- 拡張可能で柔軟な管理プロトコル。
- テクノロジーにとらわれないアクセス。
- DSL以外のアクセステクノロジーに対するTR-069の積極的なプロモーション。 たとえば、ケーブル/DOCSIS、ファイバー/PON(WT-142)。
- 他の機関はTR-069を採用しています:ITU-T SG16 Q21、HGI、DVB、ATIS IIFなど。
- TR-068(ルーティング付きモデム)WT-124で拡張= RGボックスの要件。
- TR-098(RGデータモデル)-
- RG QoSポリシーの豊富なモデリング。
- HGI QoSに採用されました。
- HGI要件を満たすために拡張機能は必要ありません。
- ACSシミュレーションツールは開発されており、お客様がACSに対してCPEソリューションをテストするのに役立ちます。
次の章では、さまざまなDSLシステムコンポーネントについて説明します。