DSL-ホーム

DSL Homeは、DSL-Forumが取ったイニシアチブです。以下のポイントでは、そのさまざまな機能と利点について説明します。

住宅用ゲートウェイ、VoIPデバイス、ホームデバイスのローカルおよびリモート管理などのホームデバイスに関連する要件を定義します。
音声、ビデオ、IPTVを含むデータ、ビデオオンデマンド、コンテンツオンデマンドなどのエンドユーザーに対してトリプル/クワッドプレイサービスを有効にするため。
DSLホームリモート管理プロトコル（TR-69）とその拡張機能は、アクセスに依存しません。
リモート管理 is the core DSLホームまたは次世代レジデンシャルゲートウェイ（RG）およびホームネットワークの
DSLホームグループは、CPE要件とCPEデバイスの管理に関する標準を考案しました。
要件を定義する標準-
- WT-124 − Issue 2 of TR-068 − DSLに固有ではないが、xPONなどの他のアクセステクノロジーを含む完全なRG要件を定義するレジデンシャルゲートウェイ。
- TR-122 音声ATA要件を定義します。
管理フレームワークの基準-
- TR-64 −LAN側のCPE構成と拡張。
  
  ローカルLANインターフェースを介したCPEデバイスの構成と管理用。
  
  TR-69 − CPEWan管理プロトコル
  
  リモート側を介したCPEデバイスの構成と管理用。
- TR-111 −ホームネットワーク（HN）内のデバイスのTR69リモート管理を可能にします。
- TR-98 and 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テクノロジーオプションについて詳しく説明します。

家族	ITU	名前	批准	最大速度機能
ADSL	G.992.1	G.dmt	1999年	7Mbpsダウン 800kbpsアップ
ADSL2	G.992.3	G.dmt.bis	2002年	8 Mb / sダウン 1Mbpsアップ
ADSL2plus	G.992.5	ADSL2plus	2003年	24Mbpsダウン 1Mbpsアップ
ADSL2-RE	G.992.3	リーチエクステンデッド	2003年	8Mbpsダウン 1Mbpsアップ
SHDSL （2003年更新）	G.991.2	G.SHDSL	2003年	5.6Mbpsアップ/ダウン
VDSL	G.993.1	非常に高いデータレートのDSL	2004年	55Mbpsダウン 15Mbpsアップ
VDSL2 -12MHzロングリーチ	G.993.2	非常に高いデータレートのDSL2	2005年	55Mbpsダウン 30Mbpsアップ
VDSL2-30 MHz 短距離	G.993.2	非常に高いデータレートのDSL2	2005年	100Mbpsアップ/ダウン

自宅での収束

複数のブロードバンドおよびネットワーキングテクノロジーが、次のような次世代のデジタルホームに統合されています。

ADSL2 / ADSL2 Plus / VDSL2 / xPON。
ワイヤレス/イーサネット/ USB / HomePlugA / V、HPNAなど。
家庭用電化製品がネットワークを開始します。

このようなコンバージェンスの管理は複雑であり、エンドデバイスのプロビジョニングとメンテナンスを簡素化する必要があります。

Challenge −家の中のさまざまな要素を管理する方法は？

Solution−基本的に、ホームネットワーキングは、Conexantが作成するすべてのネットワーキングテクノロジーとテクニックの縮図を表しています。収束は家で最初に起こっています。

今日、家庭内ネットワークデバイスをセットアップおよび構成するには、ITエキスパートである（または家に10代の若者がいる）必要があります。Industry、Applications and Technology Trendsのプレゼンテーションで取り上げたように、家庭用ネットワークデバイスの30〜50％は、問題なく小売業者に返送されます。ユーザーは、既存のツール/ソフトウェアを使用してデバイスをセットアップおよび構成することができませんでした。

既存のアプローチの問題

以下は、既存のアプローチの問題です。

User Perspective

既製の機器を購入する柔軟性はありません。
機器を購入した場合、サービスプロバイダーからのサポートはありません。
デバイスはプラグアンドプレイではなく、ISPとユーザーの両方が何らかの構成を行う必要があります。
新しいサービスを追加するには、ISPとエンドユーザーの両方の調整が必要であり、これには時間がかかります。
トラックロールが関係する場合は、自宅に顧客がいる必要があります。
最近はカップルが増えているので、合わせるのは難しいかもしれません。

Service Provider Perspective

新しいサービス、トラブルシューティング、および新しいインストールをアクティブ化するには、TruckRollが必要です。各トラックロールは、時間とリソースの面でかなりのコストを追加します。
顧客が苦情を申し立てると、「ヘルプデスク」がオフィスに座ってCPEデバイスの何が問題になっているのかを確認することは非常に困難です。
ベンダーは、独自のソリューション、さまざまなインターフェイス、パラメーター、および手順を提供します。したがって、ベンダーソリューションごとのトレーニングが必要です。
ISPは仕事を簡単にするためにカスタム自動化を行ったため、選択したいくつかのベンダーに固執することを余儀なくされました。新しいベンダーに切り替えるには、カスタム自動化の変更が必要になる場合があります。
デバイスの機能を自動的に検出し、サポートされているパラメーターを判別する方法はありません。
Web、CLI、SNMPなどのローカル管理インターフェイスを介してユーザーが構成情報を変更したかどうかを判別することはできません。
ユーザーが設定を変更することを防ぐことはできません。これは、ユーザーが提供するサービスに影響を与える可能性があります。

DSLホームが提供するサービス-TR-69

以下はDSLHome-TR-69が提供するサービスのリストです。

安全な方法でのデバイスのリモート管理（SSL / TLSベースのセキュリティを使用）。
自動構成によるサービスのリアルタイムプロビジョニング。
ステータスとパフォーマンスの監視。
Diagnostics
アクセス制御
Notification
ファームウェアのアップグレード
音声、ビデオ、データ、IPTVなどのさまざまなサービスを提供するCPEデバイス用に特別に調整された標準化されたデータモデル。イーサネット、USB、WLANなどのさまざまなLANテクノロジー上のホームセグメント（STB、VoIP、NAS）のLANデバイスを幅広くカバーします。、など。
管理プロトコルは、テクノロジーにとらわれないアクセスを目的としているため、さまざまなCPEデバイスに使用できます。たとえば、-xPON、xDSLなどでは、デバイスがIPアドレス可能である必要があります。
トラックロールはリモート管理によって最小限に抑えられます。
ヘルプデスクは、苦情を受け入れるだけでなく、より良いサービスを提供できます。Helpdeskにはより多くのコンテキストがあり、リモートからCPEに関する完全な構成情報を確認できます。
データモデルはサービス用に標準化されているため、ベンダー固有のトレーニングを受ける必要がないため、スタッフのトレーニングの必要性が少なくなります。
カスタム自動化は不要であるため、幅広いベンダーベースから選択できます
デバイスで使用可能なパラメーターの自動検出を提供します。
アクセス制御を提供するため、ユーザーが特定の構成を変更するのを防ぐことができます。
通知メカニズムを提供するため、サービスに関連する構成の変更を知ることができます。
運用コストを削減します。
ユーザーとサービスプロバイダーがモデムやベストエフォートルーターを超えて、デジタルホームのトリプル/クワッドプレイサービスに簡単に移行できるようにします。

TR69-展開シナリオ

次の図は、TR69-展開シナリオを示しています。

TR69-導入は、次の機能に役立ちます-

家庭内の同時ユーザーにサービスを提供する安全なネットワーキングソリューション
トリプル/クワッドプレイサービス（テレビ/ビデオ、電話、インターネット、ワイヤレス）
自動構成によるサービスのリアルタイムプロビジョニング
このようなプロビジョニングのサポートを管理および自動化するメカニズム

WT-124 => TR-068v2は、拡張されたスコープに基づく新しい要件を追加して、以下を含めます。

光（PON）WAN側イーサネットポート要件
診断要件のためのWebリダイレクト
DHCPクライアントの要件
ACSはキャプティブポータルの要件を開始しました。

ネットワーク接続の問題が発生した場合は、Webリダイレクトが必要です。ザ・RG MUST 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がエンドユーザーデバイスに直接アクセスできることです。
Connection − ACSがパラメータを読み書きできるようにするリモートプロシージャコール（RPC）の送信に基づく一般的なメカニズム config、CPEを監視および制御します。RPCでは、SOAPメッセージ（標準のXMLベースの構文）がSSL / TLS（セキュリティレイヤー）、HTTP、TCP / IP接続、CPEと管理サーバー間で転送されます。
(Note)− SNMPは、UDP上でマネージャーとエージェント間でプロトコルデータユニット（PDU）を送信します。TCPと比較した場合、UDPは信頼性が低く、PDUサイズはUDPフレームサイズに制限されます。
ACS Discovery −
- CPEは、DHCPを使用して関連するACSを検出できます。
- Manual Configuration − CPEは、ACSのURLを使用してローカルに構成できます。
- Default Configuration −CPEにはデフォルトのACSURLがあり、他のURLが提供されていない場合に使用できます。
Session (Setup and teardown) −事前に決定されたACSアドレスを使用してCPEからACSに常に開始されたセッション：セットアップ用のInform RPCメソッドと、完了時にTCP接続を閉じるSessionTearDownを発行します。
(Note)− SNMPは、セッションの概念をサポートしていません。クライアントは、サーバーからのメッセージを指定されたUDPポートでリッスンする必要があります。
State Management −
- 単一セッションを形成する一連のトランザクションの場合、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 and End Devices −

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-064LAN側CPE

以下は、TR-069LAN側CPE構成の機能です。

UPnP v1.0アーキテクチャを採用し、UPnP IGD v1仕様を拡張します（いくつかの制限があります）。
管理アプリケーション（TR-64コントロールポイント）はPC上で実行され、CPEがネットワークに追加されると、サービスプロバイダーと顧客固有の構成をCPEにプッシュします。
新しいCPEデバイスの初期インストール中、およびWAN側の接続の問題がある場合にさらに役立ちます。

TR-64展開シナリオ

次の図は、TR-64の展開シナリオを示しています。

DSLホームサービスのユースケース

DSLホームサービスの次のユースケースを考えてみましょう。

ユースケース-1

顧客は最初にデータ用のブロードバンドサービスを購入し、現在はVoIPサービスに加入する必要があります。

顧客は、SPのWebサイトを介して新しいサービス要求を伝達するか、オフィスに電話することができます。これらのサービスを提供するために、SPは次の質問に対処する必要があります。かどうか−

Option 1 −既存のCPEのハードウェアは、要求に応じて新しいサービスを提供できます。
Option 2 −ハードウェアは対応していますが、ファームウェアをアップグレードする必要があります。
Option 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の相互運用性−
- プラグフェストイベント-3はすでに完了しています。
- 前回のイベントでは、22のCPEベンダーと11のACSベンダーが参加しました。
検討中のTR-069またはDSLホーム認証。
進行中の多くのWT：ACSノースバウンドインターフェイス、新しいサービスオブジェクトモデル、QoS、新しいRG仕様、テストと相互運用性のテストケースなど。
UPnPフォーラム、DLNA、HGIなどと連携および連携し、ホームセグメントのデバイスに対する標準を定義します。
ITU-T SG16、ホームゲートウェイイニシアチブ（HGI）、ATIS IPTV相互運用性フォーラム（IIF）など、かなりの数の標準化団体がホームデバイスのリモート管理にTR-69標準を受け入れています。
ダイレクトビデオブロードキャスト（DVB）組織（ETSI標準）は、IPTVSTBリモート管理またはCableLabsの代替としてTR-069およびWT-135を採用しました。
複数の研究グループが関与するITU-TIPTVフォーカスグループも、リモート管理プロトコルの問題に対処します。

TR-69とSNMP

IETF（Internet Engineering Task Force）は、さまざまな機能を管理するために多くのMIBを定義しています。ただし、構成とサービスプロビジョニングのためにCPE（特にトリプルプレイサービスを提供するホームゲートウェイの場合）デバイスを管理するためにMIBのセットの使用を推奨する標準機関またはIETFによる統合は行われません。CPEデバイスでのMIBサポートは、ベンダーが独自の実装に関して選択することを完全に任されています。DSLホーム傘下のTR-69およびその他のTRは、そのようなタイプのサービスのためにCPEデバイスに必要なパラメータのセットを定義します。各タイプのサービスに適用可能なパラメータのセットを推奨します。

ベンダーは独自のMIBを備えたソリューションを提供しているため、これらのデバイスの管理はベンダー固有になっています。
CPEデバイスのみに固有のファームウェアアップグレード、診断などのシステムサービスに使用できるMIBはありません。
ほとんどのホームゲートウェイはNATを使用し、管理対象のデバイスはNATの背後にある可能性があるため、SNMPを使用するにはNATを介してSNMPポートを開く必要があります。SNMPでは、パラメータを取得/設定する要求は常にマネージャによって開始されます。したがって、要求を取得するには、CPEでポートを開く必要があります。TR-69では、TR-69セッションはCPEによって開始され、サーバーは同じセッションを使用してget / set要求を送信します。これにより、NAT環境で明示的にポートを開く必要がなくなります。TR-69は、ACSがCPEに要求を送信できる方法も定義しており、この部分はTR-111part2によって透過的に処理されます。
現在存在する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 overTCPを使用します。これは信頼性が高くなります。
SNMPエージェントでは、SNMPマネージャーアドレスとコミュニティストリングを構成する必要がありますが、TR-69ではACS固有のパラメーターを構成する必要はありません。ACS関連のパラメータは、オペレータが設定していない場合、DHCPベースのメカニズムを介して動的に検出される可能性があります。
SNMPベースの管理を通じて、サポートされるアクションはget / getnextであり、マネージャーから設定されます。デバイスの管理に他の独自のアクションまたはファイルのダウンロードが必要な場合、TR-69では実行できません。これは、ベンダー固有のRPCを定義することで簡単に実現できます。ファイルのダウンロードでさえ、既存のRPCメカニズムを使用して、CPEとACSの間の同じセッションで実行できます。
TriplePlayサービスをサポートするCPEデバイス用に調整されたMIBはありません。
各ベンダーは、いくつかの標準+独自のMIBに基づいて独自のソリューションを提供しています
SNMPを使用するには、デバイスのSNMPポートを開く必要があります。
ほとんどのSNMPベースの管理はSNMPv3を実装していません。したがって、セキュリティが危険にさらされます。
任意のパラメータのパラメータ変更に関する通知の実装は困難です。
通知の有効化と無効化を制御できません。
アクセス制御の準備はありません。
信頼性の低いUDPベースの配信方法の使用。
デバイスは一度に複数のマネージャーで管理できるため、同期が強化されます。
特定のアクションのセットのみをサポートできます。
SNMPで実現できることはすべて、TR-69などで実現できます。

結論

DSLホーム仕様のスイートは、次世代のレジデンシャルゲートウェイ（RG）ソリューションを定義します。
ユーザーと電話会社がモデムを超えて、トリプル/クワッドプレイサービスへのブリッジング/ルーティングに最善を尽くすことを容易にします。
TR-069（CWMP）はDSLホームのコアです-
- 拡張可能で柔軟な管理プロトコル。
- アクセステクノロジーにとらわれない。
- DSL以外のアクセス技術のためのTR-069の積極的な宣伝。例–ケーブル/ DOCSIS、ファイバー/ PON（WT-142）。
- 他の機関はTR-069を採用しています：ITU-T SG16 Q21、HGI、DVB、ATISIIFなど。
WT-124 = RGボックス要件で拡張されたTR-068（ルーティング付きモデム）。
TR-098（RGデータモデル）-
- RGQoSポリシーの豊富なモデリング。
- HGIQoSに採用されました。
- HGI要件を満たすために拡張機能は必要ありません。
ACSシミュレーションツールが開発されており、お客様がACSに対してCPEソリューションをテストするのに役立ちます。

次の章では、さまざまなDSLシステムコンポーネントについて説明します。