アカウント名:
パスワード:
というのが見つかりました。特に後者は全域FTTHのみのようですね。 設備や光ファイバー、ONUの価格がこなれてくれ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
FTTHとの合わせ技 (スコア:3, 興味深い)
そしたらY!BBやフレッツの顧客を食えるし、何よりライセンスがあるのだからそのまま膨大なチャンネルをストリーミング配信できるではないですか。
うちのように電波の入りにくい場所では死ぬ程欲しいサービスなんですが、経営再建の礎にできるほどの需要は無いのかな……
Re:FTTHとの合わせ技 (スコア:3, 興味深い)
>メタルだそうですけど、そのままFTTHなIP接続サービスにはできないんですかね。
うちの会社じゃないけど、FTTH開始しているところあります。
例えば、三重県の伊賀上野地区のアドバンスコープ社 [advanscope.jp]とか。他にも
あるかも。サービスエリア全体FTTH化というのは多分ないと思いますが。
(ちゃんと調べてないので、「多分」)
何にしても、既存の設備をリプレースして新しくするのにはお金も時間も
かかりますので、すぐというわけにはいかないでしょうけど
2~3年もしたら
FTTHサービスやる会社もそこそこ出てくると思いますよ。
#CATV社員なのに自宅BフレッツだけどID
Re:FTTHとの合わせ技 (スコア:0)
Re:FTTHとの合わせ技 (スコア:0)
というのが見つかりました。特に後者は全域FTTHのみのようですね。
設備や光ファイバー、ONUの価格がこなれてくれ
Re:FTTHとの合わせ技 (スコア:2, 参考になる)
・長距離伝送の際に信号減衰が少ない
・通信サービスの多重化が容易
(同軸と違い、多数のブランチに対し、分岐直前まで一本のファイバで持ち込める)
の2点から利用されています。
例えば、CATVとして100チャンネル提供し、かつ1ブランチ上下30Mbps(CATVのチャンネル2つ分相当を、同一ブランチにぶら下がっているお客でシェア)のサービスをする際(これで同軸ケーブルは一杯一杯)に、ファイバ部が4Gbpsの伝送容量(現状で普通に使えるEthernet製品の上限)を持っていれば、基幹線では15ブランチ(CATV3G、通信部1G)を多重化できるので、ラインの敷設費用を大幅に下げられます。
というわけで、FTTHにしちゃった場合には、
・基幹線のファイバを沢山束ねる(当然装置数も嵩む)
・局舎及び分岐部で高価な10GbitEther用多重・分離装置を使う
のどちらかに陥ります。
#で、普通のFTTH並みの値段になる。
#あ、あと、「FTTHにしたけど、通信速度は変えない」という手もあるか(^^;
あと、ストリーミング配信とCATV配信とでは、コンテンツの利用権が異なる(CATV配信は「有線放送」の許諾で十分なのに対し、ストリーミング配信の際には「有線放送」を包含する概念である「公衆送信」の許諾が必要)ので、通信サービスとしてコンテンツを提供するのは結構大変です。
#平たく言えば、「コンテンツの権利者は、PCを再生機として使うと、違法複製されると思っている」ってこと。
通信と放送 (スコア:1)
大変かもしれませんね。
FTTHでTCP/IPのマルチキャストを放送の伝達手段として、関係省庁が認めてくれるとかの、いろいろな
問題がありそうですが。
/* Kachou Utumi
I'm Not Rich... */
Re:通信と放送 (スコア:2, 参考になる)
別に無いはず。
殆どのCATV会社は、電気通信事業者でもあり、有線テレビジョン放送事業者でもある。
#ごく一部、有線テレビジョン放送事業者ではなく、有線「役務利用放送」事業者だったりすることはあるけど。
で、テレビは「放送事業者」として、ケーブルインターネットは「通信事業者」としてサービスを提供している状態。
#両方の事業者で「設備共用している」という解釈になります。
なお、「免許」か「登録」が「届出」かは、形態によってコロコロ変わるので、敢えて触れない。
>FTTHでTCP/IPのマルチキャストを放送の伝達手段として、関係省庁が認めてくれるとかの
んっとだねぇ、TCP/IPのマルチキャストってなんですか?
UDP over IGMPのことだと良心的に解釈すると、「品質が保障されている」のであればokです。
#現に、Softbank BBは、それで事業者登録されているし。
で、IPベースのストリーミングであれば、現状ではユニキャスト(1対1通信)を同時に沢山やっているだけなので、「放送事業者」である必要がありません。
さもなきゃ、Internet上で動画コンテンツを提供してる多数の人々が全部事業者登録する羽目になります。
#IPv6のマルチキャストが、デイジーチェーン転送ではなく、パケットの複写転送になった場合には、話は変わるかもしれないけど。
Re:通信と放送 (スコア:0)
> UDP over IGMPのことだと良心的に解釈すると、「品質が保障されている」のであればokです。
えっと、本当に分かってて書いてる?
IGMPはIPv4でMulticastをコントロールするためのプロトコルで、IPの上に乗ってるやつ。そういう意味ではICMPと似てるし、IPv6ではIGMPもICMPに統合され
Re:通信と放送 (スコア:1)
--- show mpls ldp neighbor
Re:通信と放送 (スコア:1)
う~ん、どういえば分かってもらえるやら…。
#多分、L3制御の概念が分かって無いんじゃないか、という気がしますが…。
以下、長くなることを予めお詫び。
とりあえず「IPの上にのってる」というのが、何を意味しているのか理解できませんが、そもそもIPとIGMPは同一レイヤーのプロトコルなので、IGMPが「IPの上にのる」ってのはかなり変です。
#そもそもIGMP/IPって、ちゃんと機能するのかなぁ…。
#まぁ、Ethernet over TCPが動くみたいなので、論理的には有り得るかな?
#だれかSoftEtherを途中にかました閉鎖網でIGMPを流してみません?
で、IPとICMPとIGMPも、同一レイヤー上で混在可能なように設計されたプロトコルであることは間違いないです。
で、こいつらの差異は、大雑把に言えば、
・ICMPは、「どこか」に命令なりレスポンスなりを送りつけるもの
・IPとIGMPは、「どこか」に「ペイロードを送りつける」ためのもの
・IPは、送り先のマシンのアドレスを指定する
・IGMPは、ペイロード内のデータをラベリングする
のそれぞれに特化している点にある。
したがって、この3者は少なくとも同一プロトコルではない(だからこそ、IGMPはRFC791の改定と言う形では定められていない)し、少なくとも「IGMPはIPv4でMulticastをコントロールするためのプロトコル」ではない。
#IPv4前提のL3ネットワークに障害を与えないように設計されたMulticast Protocol(概念的にはMulticastというよりはBroadcastだけど)、なら正しい。
更に言えば、IGMPは閉鎖網前提のプロトコルであって、The Internetには流してはいけない代物なので、「IP」のグループに入れるのは、相当変。
#「インターネットで使われるプロトコル群」という意味で用いられる「TCP/IP」に包含されない。
あと、あなたの感覚ではIPv4もIPv6も同じ「IP」なのかも知れないが、混在利用を前提として設計されていない段階で、「プロトコルの概念」的には「同じプロトコル群に属する」ということはありえない。
#私の感覚では、IPv6は、IGMPよりもIPv4から遠い。
#ただし、IPv6はIPv4の後継となる(replaceする)ことを意図たものではある。
で、大本に返ると、「IPマルチキャスト」って書いてあれば何も突っ込む気はなかったけど、「TCP/IPのマルチキャスト」って一体なんだよ(セッションをどうやって張る気なのか。というか、セッションを張った瞬間にユニキャストに戻るじゃん)と思ったので、わざわざ突っ込んでみた、というのが本意。
だから、「UDP」という単語を出したかったんだけど、UDP/IGMPっていう標記は普通しないので、「/」をわざわざ「over」と単語に開いて書いただけ。
というわけで、あなたは「/」の意味も理解して無い、ということでよろしいでしょうか?
Re:通信と放送 (スコア:1)
スカパー子会社で光ファイバー放送をやっているオプティキャストは、IPに乗せない方式 [opcas.jp]でやってます。
Re:FTTHとの合わせ技 (スコア:1)
>何よりライセンスがある、中略、ストリーミング配信できる
公衆送信権と送信可能化権のからみで著作権的に困の難ではな
いだろうか?ストリーミング配信についての契約を局側で締結
していれば可能でしょうが、、、技術以外のハードルですね。
@mojohandblues
Re:FTTHとの合わせ技 (スコア:0)
なんとなく思っただけなんだけど