スキップしてメイン コンテンツに移動

5G時代の情報通信サービス~ソフト化とSliceでどう変わるのか~ 【情報通信技術委員会(TCC)】 -- CEATEC JAPAN 2018 カンファレンス


この投稿は https://nmizos.blogspot.com/2018/10/ceatec-japan-2018-detail-4.html のつづきです。

5G時代の情報通信サービス~ソフト化とSliceでどう変わるのか~ 【情報通信技術委員会(TCC)】

【主催者による概要】
https://regist.ceatec.com/?act=Conferences&func=Detailed&event_id=7&conference_id=467
【メモ&コメント】
  • TTC(情報通信技術委員会 = 電話事業の通信規格とかの日本国内での元締め団体)主催のシンポジウム。
  • ソフト化(Softwareization)はまだしも、スライス(Slice)は聞きなれないなと思ったが、、、
  • SDN(主にONF)とNFV(主にETSI)が提唱しているコンセプトを焼き直しただけのような気がしてならない。専門外の人にひとことで説明するとしたら「つまりネットワークも仮想化が進んでいるということ」というまとめ方が適しているように思う。

開会挨拶

情報通信技術委員会 代表理事専務理事 前田 洋一 氏
  • TTCの紹介と、TTCのスタンスについての説明。

5G有無線ソフトウェア化がもたらす便益

東京大学 教授 中尾 彰宏 氏

【メモ&コメント】
  • 5G関連の規格とか定義とか現状とかをまとめたレクチャー。…かな。
  • 5GはITU-RのIMT Vision(IMT2020)で規格化。(3GPPだよね)。
  • 「ネットワークのソフトウェア化とは?」も、ITUで定義がされている。
  • Slicing(スライス)とは、要件が異なるNWを分離する(レーンを分ける)こと。QoSの進化系と言っていいだろうか?
  • 「Tactile Network」という、人の神経伝達に近いネットワークを模索するうごきもある(ITU)。
  • 「考えるネットワーク勉強会」というのをやっていて、これまでは招待制でやってきたが、一般に参加者を募るようにするかもしれない。

5G及びその先の社会創造に向けたネットワーク技術

日本電信電話株式会社 未来ねっと研究所 所長 吉野 修一 氏

【メモ&コメント】
  • NW屋の視点でNWを語っているので、NW技術の最新状況のお勉強教材としてはよくまとまっている感じはするものの、「だからどうした?」という感じもある。
  • 自動ログ分析、自動障害箇所推定の研究 … NTTでももちろんやっている。そりゃそうだよね。←ところで今日のテーマにどう関連するのかは不明。
  • どうもNTT未来ねっと研の取り組み紹介の割合が多い気がするのはご愛敬か。

5G時代到来によるこれからのビジネスチャンスの可能性 ~ソフトウェア化によるシェア前提への社会変革の中で~

新たなサービスを創出するための課題と今後のネットワークの発展方向
さくらインターネット株式会社 代表取締役社長 田中 邦裕 氏

【メモ&コメント】
  • TTC主催の今日のこのテーマで、なぜ田中社長が呼ばれたのか、最後まで不明のまま。「あるところで中尾先生(東大)とお知り合いになって」と言っていたが、もしかしたら本当にそれだけなのかもしれない。
  • 本セッションのテーマとの整合性は無視するとして、
    • 「シェアが前提になると◯◯がかわる」のいろんな例や、
    • 巨大からの脱却、(あらゆるものが)疎結合、個の尊重、
    • …といった話は興味深い。

パネルディスカッション

モデレーター/パネリスト
情報通信技術委員会 事務局長 稲田 修一 氏
東京大学 教授 中尾 彰宏 氏
日本電信電話株式会社 未来ねっと研究所 所長 吉野 修一 氏
さくらインターネット株式会社 代表取締役社長 田中 邦裕 氏
株式会社インフォシティ 代表取締役 岩浪 剛太 氏

  • 興味深い or おや?と思うコメントがいくつかあったが… パス。

--


x

コメント

このブログの人気の投稿

5600ページのIEEE 802.3-2018が入手可能になった

IEEE 802.3の名称は今では「IEEE Standard for Ethernet」になっている。 「イーサネットとIEEE 802.3は別物なんだよ」という話は,今では昔話でしかない。もうひとつ“いまはむかし”な話をすると,「イーサネットはCSMA/CDだよ」なんて言うと恥をかくのでやめた方がいい。こちらは名称の問題では無く中身の話だが,ここでは詳しい説明は割愛する。 この「イーサネット標準」の2015年以来の改訂版が,2018年8月に発行。6ヶ月のIEEE会員限定期間が過ぎたので,一般にも入手可能になった。ただし個人アカウントは取得する必要がある。この話は以前に書いた ( https://nmizos.blogspot.com/2017/12/ieee802.html 参照)。 https://ieeexplore.ieee.org/document/8457469 このネタをブログにしようと思った動機はタイトルに記してしまった。この規格は改定されるたびにドンドン太って巨大になってきている。本編改訂の間に発行されたamendment (補遺と訳すのがいいのかな)が取り込まれるので,太るのはしょうがない面もある。でもねぇ,ついに5600ページ。もちろん通し読みするようなものじゃない。PDFファイルなので「厚さ」は無いが,印刷したらどれくらいになるんだろう。 参考までに,過去10年の本編のボリュームを比較してみた。  2008 = 5分割,2977ページ  2012 = 6分割,3748ページ  2015 = 4017ページ,56Mバイト  2018 = 5600ページ,98Mバイト 以前は数セクションにファイルを分割して公開されていた。ファイルが大きすぎるのを気にしてたんだろう。2018版も中身は8セクションに分かれている(ページ番号も別に付いている)のを,PDFファイルとしては合体してある。100Mバイト程度のPDFが「デカ過ぎて開けない」ってことも無いだろうから,1本になっていた方が全文検索ができて都合がいい。ちなみにiPadで開いて全文検索しても,今の98Mバイトなら困らない。 参考までに,無線LANのIEEE 802.11の方は,802.11-2016が3534ページ。こちらも結構なもんだ。 --

IEEE802標準文書の入手

■概要 入手方法が変わった。たぶん2017年のどこかから。 ダウンロードの都度メルアド等を入力するのではなくて,メンバ登録&ログイン形式に。 個別の参照(入手)時点の操作も変わった。 概要の表示ページから“Download PDF”を選ぶとPDFファイルが呼び出されるが… 即ダウンロードでは無くて,(ブラウザ依存だと思うがFirefoxの場合は)インラインでPDF表示になるので,その後に表示しているPDFをダウンロードさせることになる。 802.3の場合は困ったことに文書がデカ過ぎる。従来は複数パート(セクション)にPDFが分割されていたが,参照方法が上記の様に変わったのに合わせて,802.3全体が1本のPDFに。なんと4000ページ超,50MB超の1本のPDFになり,それをまとめてインライン表示しようとするので,待ち時間がとても長い。メモリの少ないPCだと途中でアカンことになりそう。   ---- ■操作 入口=  http://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68 (  http://ieeexplore.ieee.org/  からでもたどれるだろう )。 メニューをたどって,例えばIEEE 802.11(無線LAN)の標準文書を参照しようとすると… “Download PDF”は選択できなくなっている。 画面最上部の“Personal Sign In”からログインすると… “Donwload PDF”が有効になる。 概要でも記したように標準文書フルテキストPDFのダウンロードは,Firefoxの場合にブラウザのインラインでの表示になるので,保存する場合にはブラウザの操作でファイル保存する。 ユーザ登録は“Create Account”から。 入力方法などは自助努力で。(画面のガイダンスや注意事項を読みましょう)。 --

RFCは番号を無駄遣いしていないか?

新規に発行されるRFCの番号が8000番台になっていて,その8000番台も1年くらいで食い潰しそうな勢いだ。実は8年ほど前にも同じ様に「なんと6000番台後半だよ」と思ったのだった。 ところで,RFCの番号って,几帳面にきっちりと順番に使っているわけでは無い。大物RFCにはキリ番を使うことがある様だし(RFC 8200とか),規格のバージョンアップの際には旧番号から覚えやすいものにすることがある(RFC 822 → RFC 2822など)。 …ということは,ところどころ虫食い状態で空き番号がたくさんあるんじゃないかな?と,ふと思った。 RFCの一覧ページはこれ:   https://tools.ietf.org/rfc/ これを眺めると,ところどころに「Not Issued」となっている番号があるので,虫食いになっているのはたしかなようだ。無効化(Obsoletes)されたRFCもたくさんあるけれど,一度は使われた番号だから,これについては「使った」ということでいいだろう。 もう1つの一覧形式で,Mini-Indexページなるものがあった:   https://tools.ietf.org/rfc/mini-index ぱっと見で,虫食い状態がわかる。言い換えるとそれしかわからない。 上記のMini-IndexのHTMLを解析して,具体的にどれくらい虫食いなのかを調べて見た。単なる酔狂でしかないけれど。 結果(RFC 8754まで) 個数 RFC番号  735 8000番台  996 7000番台  973 6000番台  971 5000番台  973 4000番台  982 3000番台 1000 2000番台  995 1000番台  933 999番以下 こうしてみると,最初の999番までが一番大雑把だ。 RFC化の検討に入ったけど最終的に発行されないものもあるから,2000番台の様に完全に埋まることは珍しいと思う。そういう意味では,まぁまぁ,几帳面に番号割当てをしていると思っていいのだろう。 さて,RFC 10000に到達するまで残り約1250。そこに達するのは,だいたい4年ちょっと後の2024年頃だろうか。 【参考: カウントスクリプト】 : count.sh #...