Category: Blog

P-GW製品開発日記 ─ その2 「P-GWでの認証」

Written by imazu in Blog on 2016-06-07. Tags: PGW, Develop,

前回、P-GWの役割として次のように書きました。

GTP-Cが認証・認可を含む接続状態の管理を、GTP-Uが通信パケットの送受信を扱います。

今回はP-GWが行う認証について調べます。 ターゲットはNTTドコモ様の相互接続サービスです。

P-GWでの「認証」って何

無線LANの認証をはじめ、認証スイッチとRADIUSサーバーの組み合わせでは、接続の際にユーザーIDとパスワードを入力します。RADIUSサーバーは、これらを元に接続可否を判断します。

MVNOのSIMを契約して、最初の設定ではどんな項目があるでしょうか。 自動入力になっていることも多いですが、おおむね次の3つでしょう。

  1. APN
  2. ユーザー名
  3. パスワード

しかし、これらはMVNOごとに固定値である場合が多いです。SIMの説明書に記載されていたりしますね。 ユーザなら(顧客なら)誰でも知ってるので、いわゆる認証が目的だとは言えないでしょう。

相互接続をL3接続で行う場合に使われるRADIUSサーバーで認証条件に使われる項目は主に次の3つです。

  1. ユーザー名
  2. パスワード
  3. 発信者番号(電話番号)

携帯端末の設定で入力する項目以外に電話番号を使っています。 登録された電話番号を持つSIMを認証の条件に加えることで、個別の認証をしていることになりますね。 ではL2接続の場合はどうなるのでしょうか。 P-GWでの認証にあたる処理(接続を許可する・しないを決める部分)がどんなものなのか調べていきます。

ドコモ様の技術的条件集別表9 パケットデータ直収(IMT-2000)ユーザインターフェース仕様を読むと、GTP-Cでは以下のようなメッセージを扱うとあります。

  • ノード監視処理 ...

Continue reading »


P-GW製品開発日記 ─ その1 「MNOとMVNOのL2接続ってどういうもの?」

Written by imazu in Blog on 2016-06-06. Tags: PGW, Develop,

MVNO事業用途でRADIUSサーバーをご利用いただくことは多かったのですが、P-GWってなんですか?L2接続ってどんな仕組み?というところからお勉強です。

P-GWってどこで使うの?

MVNO事業におけるRADIUSサーバーやP-GWの役割の概要は、IIJ様の記事「MVNOによるLTE接続」がとてもわかりやすいです。

要は、携帯電話網からインターネット(またはIP網)に接続する際の出口となる部分がP-GWなのですね。

L3接続とL2接続の図を見比べると、L3接続の場合、MNO側の設備としてのP-GWのインターネット側にRADIUSサーバーが位置しています。 L3接続の場合、携帯電話網からIPレイヤまでの接続は終えた状態でMVNO側にIPパケットが到達し、インターネット側に接続するかしないかを、認証スイッチと同じ要領で制御している構成になるんですね。

一方で、L2接続の場合、MVNO側の設備としてP-GWが存在します。 「L2接続」「L3接続」の違いが、相互接続点がP-GWの携帯電話網側にあるかインターネット側にあるかのように思えますが、ではP-GWの役割はなんでしょうか。

P-GWは何をするものなの?

ドコモ様の技術的条件集 のうち、「技術的条件集別表9 パケットデータ直収(IMT-2000)ユーザインターフェース仕様」の「技術的条件集別表9−1−2 ユーザデータ転送プロトコル仕様」を読むと、GTP-Uプロトコルに関する説明があります。

P-GWは携帯電話網側にあるS-GWと、GTP-C・GTP-Uのプロトコルを用いて通信します。 GTP-Cが認証・認可を含む接続状態の管理を、GTP-Uが通信パケットの送受信を扱います。

携帯電話網側のS-GWとMVNO側のP-GW間では ...

Continue reading »


メールでGitHubにissueを作る

Written by imazu in Blog on 2016-05-06. Tags: GitHub, AWS, Python,

当社では開発はもとより様々な業務でGitHub issuesを利用しています。 今回、社内向けの営業さんからの質問もGitHub issuesでやりましょう、という話をしたところ、「メールで質問投げられるととても楽で助かるんだけど」という意見があったので、やってみることにしました。

AWSのお勉強がてら、メールの受信イベントのハンドリングにAmazon Simple Email Service(SES)を使います。

実現したい業務フローはこんな感じ。

  1. あるメールアドレス宛に質問メールを送る。
  2. GitHubの特定リポジトリのissuesに、メールの内容が登録される。
  3. Slackに登録内容が通知されるのをみて、技術担当が回答する。

メールを利用してGitHubのissueを投稿するにあたって、次の情報が必要です。

  • メール送信者のGitHubアカウント(と、issue作成に関する認可)
  • issueを作る対象のリポジトリ

そこで、簡単なウェブアプリを作って、これらを事前に設定するようにしました。 実際のフローはこのようになりました。

  1. ウェブアプリにアクセスし、GitHub OAuthを使ってログインする。
  2. GitHubアカウントの特定
  3. issue作成の認可
  4. 投稿可能リポジトリ情報の取得
  5. ウェブアプリ上で、投稿先リポジトリを選択・登録する。この時、専用のメールアドレスを発行する。
  6. 投稿先リポジトリとメールアドレスをひもづけることで、メール受信時に TOアドレスからリポジトリを特定可能にする。
  7. 生成されたメールアドレス宛に、質問メールを送る。
  8. GitHub上では ...

Continue reading »