Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Proposals for Japanese next generation terrestr...
Search
Soichi Sato
March 11, 2020
Technology
1
65
Proposals for Japanese next generation terrestrial TV
Proposals
Next generation
DTTV (Digital Terrestrial TV)
one seg (1seg)
FeMBMS
5G Broadcast
JAPAN
Soichi Sato
March 11, 2020
Tweet
Share
More Decks by Soichi Sato
See All by Soichi Sato
Local 5G and FeMBMS
soichi1
1
430
5G-Broadcast experiments using SDR (Under construction)
soichi1
1
270
Brasil SET2020 MMT by Eiden
soichi1
1
140
China 5G-Broadcast
soichi1
1
370
Presentation at the Ministry of Internal Affairs and Communications in Japan.
soichi1
1
110
異能vation(innovation)2019
soichi1
1
92
Other Decks in Technology
See All in Technology
現地速報!Microsoft Ignite 2025 M365 Copilotアップデートレポート
kasada
2
1.5k
重厚長大企業で、顧客価値をスケールさせるためのプロダクトづくりとプロダクト開発チームづくりの裏側 / Developers X Summit 2025
mongolyy
0
160
Progressive Deliveryで支える!スケールする衛星コンステレーションの地上システム運用 / Ground Station Operation for Scalable Satellite Constellation by Progressive Delivery
iselegant
1
210
グローバルなコンパウンド戦略を支えるモジュラーモノリスとドメイン駆動設計
kawauso
3
6.6k
LINEギフト・LINEコマース領域の開発
lycorptech_jp
PRO
0
350
AWS re:Invent 2025 で頻出の 生成 AI サービスをおさらい
komakichi
2
180
仕様は“書く”より“語る” - 分断を超えたチーム開発の実践 / 20251115 Naoki Takahashi
shift_evolve
PRO
1
1.1k
AI × クラウドで シイタケの収穫時期を判定してみた
lamaglama39
1
380
Javaコミュニティの歩き方 ~参加から貢献まで、すべて教えます~
tabatad
0
140
レガシーで硬直したテーブル設計から変更容易で柔軟なテーブル設計にする
red_frasco
4
510
re:Invent2025 事前勉強会 歴史と愉しみ方10分LT編
toshi_atsumi
0
240
Service Monitoring Platformについて
lycorptech_jp
PRO
0
330
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Raft: Consensus for Rubyists
vanstee
140
7.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
How GitHub (no longer) Works
holman
315
140k
Agile that works and the tools we love
rasmusluckow
331
21k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
980
Speed Design
sergeychernyshev
33
1.2k
For a Future-Friendly Web
brad_frost
180
10k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Transcript
次世代地上デジタルテレビジョン方式に関する技術の提案 -FeMBMS(5G)+1セグ方式- スペクトラムイメージ FeMBMS 1 S E G G B
0.5M 0.5M 5MHz 6MHz(放送1ch帯域幅) 約0.5MHzの帯域幅のワンセグと帯域幅約5MHzの5G(5世代移動通信システム)にて利用可能な FeMBMSを1つの送信機から送信。合計約5.5MHzの占有帯域となるが、0.5MHzのガードバンドを設け 隣接との干渉を避け6MHzの放送チャンネルにて運用する。 2020/03/11 SS Page.1
UHF放送周波数チャンネルプランの見直し 従来はワンセグをほぼ中心に左右3MHzを地デジ放送の周波数チャンネル(アナログ地上波のときも同 様)としていたが、FeMBMSとして5MHzを連続で確保する為にワンセグを一番左端にして周波数を割り 当てる必要がある。チャンネルの周波数幅は6MHzのままで変更はない。このようにするのはワンセグ の周波数の位置をずらしてしまうと受信できなくなる為である。 1 S E G 6SEG
6SEG 1 S E G 6SEG 6SEG 1 S E G 6SEG 6SEG 1 S E G FeMBMS 1 S E G FeMBMS 1 S E G FeMBMS 地デジ6MHzチャンネル 地デジ6MHzチャンネル 地デジ6MHzチャンネル 本方式6MHzチャンネル 本方式6MHzチャンネル 本方式6MHzチャンネル 2020/03/11 SS Page.2
サブ6GHz帯等の周波数を利用した4K地デジ移行プラン 今回の提案は地デジのRF伝送方式の新方式の提案であり、ワンセグ以外においては従来の方式との 互換性が無い。テレビで利用しているUHFの周波数においては新しい地デジ4Kに割り当てる周波数が 既に無い状態になっており、UHFで従来の地デジ放送を行いながら4K地デジに移行するのは困難とさ れている。 そこで、サブ6GHzの周波数帯(例えばローカル5G等に利用予定の4.6-4.8GHz)を利用して一部の地域 でFeMBMSを利用した4Kの放送を開始。十分な移行期間を経た後UHFにて1seg+FeMBMSに移行する 方法が考えられる。東京スカイツリーから出力しているNHK+民放は8局であり、サブ6GHz帯においては ワンセグは不要なので1局5MHzとして合計40MHzの帯域のFeMBMSを出力すればよいことになる。 4.6GHz
4.8GHz 470MHz 710MHz UHF(地デジ) サブ6GHz帯 地デジ8局(各6MHz) FeMBMS(8局×5MHz=40MHz) 2020/03/11 SS Page.3
FeMBMS概要 LTEから本格的な運用検討 がされている方式であり、 MBMS、eMBMS、 FeMBMSと進化してきてい る。 GI(ガードインターバル) 長が長く取れるようになっ てきており、地上波運用時 のフェージングに耐えられ、
SFNの運用も可能。 多くのLTE受信チップが eMBMS受信機能を持つた めソフトの対応で受信可能 となっている。(ドイツの テレビ局、アメリカのスタ ジアムのデモ等の実績あ り) ※図はNHK技研 R&D No.172 2018.11より引用 2020/03/11 SS Page.4
5G NR スループット計算 5G NR スループットの計算を 以下の条件で行った結果。 サブキャリア間隔15kHz (μ=0) 帯域幅5MHz
(RB数=25) 256QAM (MO=8) 結果 約26Mbps 2020/03/11 SS Page.5
FLUTE+MPEG-DASH+HEVC ※図はRohde & Schwarz社の資料より引用 図はeMBMSのプロトコルであるがFeMBMSも ほぼおなじと考えられる。 日本の高度BSにおいてはMMTが利用されてい る。これはリアルタイム性が求められる放送に 最適であるとの理由からである。 しかしながら、インターネット等ではMPEG-
DASHによるリアルタイム再生が主流となって いる。MPEG-DASHは数秒単位のセグメント ファイルでの伝送になる為セグメントデータの バッファリングなどを含めると数秒の遅延が生 じる。そのようなデメリットはあるが、標準的 なブラウザでの動画再生がサポートされている こと、民放にとって重要な個人の嗜好等にあわ せたCM差し替えが容易という大きなメリット がある。 MPEG-DASHのセグメントファイル伝送の仕組 みとしてFLUTEが利用されるがFLUTEは日本で もマルチメディア放送のIPDC(IP Data Cast)にて利用されている方式である。 映像のエンコードにはHEVCが利用できる。 プロトコールスタック 2020/03/11 SS Page.6
本提案のメリット・課題など [メリット] • 放送と通信の受信チップの共通化が可能。あるいは、放送用の受信チップなしにスマホ等で受信可能に。ちなみに、 放送の受信にSIMカードは不要である。 • 本当の意味での放送と通信の融合につながり、放送に新しいイノベーションを生む可能性がある。 • 放送業界を巻き込み積極的に国際規格(5G、あるいは次の6Gの通信規格)に関わることにより技術的な主導権を 獲得できる。
[課題など] • 地デジの4K化にはアメリカ・韓国が採用したATSC3.0の方式もあり、5GとATSC3.0の組み合わせが世界的な標準と なる可能性がある。アメリカの放送局大手SiclairがONE MEDIAとして活動している。 • 現時点で5Gは最新テクノロジーであるが、将来的に6G等新しいテクノロジーが出てくると通信はそちちらに移って いく可能性がある。あるいは放送も移ることによりレガシー性が失われる。 • 256QAM等の高次QAMを利用した場合、CATV(FTTHではなく、銅線の場合のみ)での再送信がC/Nの確 保の関係で難しい(※1)。 ※1 CATVはトランスモジュレーションを利用して解決する方法もある(64QAM利用時は約30Mbbps可能)。あ るいは、本方式のように新しい伝送方式を利用するのではなく、現在のISDB-Tと同一の方式を利用して12セグの 中のデータを2kから4Kに変えてしまう方法も考えられなくないため、その場合はそのままCATVにて伝送可能。 • DRMの為のスクランブルの仕組みについて、高度BSにおいてA-CASが利用されていてIPパケット単位でのスクラン ブルが行われているが、MPEG-DASHの場合セグメントファイル単位でのスクランブルをかけるほうが適切と思われ る。 2020/03/11 SS Page.7