(57)【特許請求の範囲】
【請求項１】
移動通信システムであって、
ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）をソース基地局(ｅＮｏｄｅＢ)に提供し、さらに前記ソース基地局を介してソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）に前記ＬＡＰＩを通知して保持させる手段と、
前記ソースＭＭＥは、前記端末がハンドオーバする場合に、前記ソース基地局からＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄを受信し、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する手段と、
を有する移動通信システム。
【請求項２】
移動通信システムであって、
ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）をソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に提供し、さらに前記ソースＲＮＣを介してソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に前記ＬＡＰＩを通知して保持させる手段と、
前記ソースＳＧＳＮは、前記端末がハンドオーバする場合に、前記ソースＲＮＣからＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄを受信し、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する手段と、
を有する移動通信システム。
【請求項３】
移動通信システムに用いられるＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）であって、
ソースＭＭＥが、ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末からソース基地局(ｅＮｏｄｅＢ)に提供されたＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）を前記ソース基地局を介して受信し、保持する手段と、
前記ソースＭＭＥが、前記端末がハンドオーバする場合に、前記ソース基地局よりＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄを受信して、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する手段と、
を有するＭＭＥ。
【請求項４】
移動通信システムに用いられるＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）であって、
ソースＳＧＳＮが、ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末からソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に提供されたＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）を前記ソースＲＮＣを介して受信し、保持する手段と、
前記ソースＳＧＳＮが、前記端末がハンドオーバする場合に、前記ソースＲＮＣよりＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄを受信して、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する手段と、
を有するＳＧＳＮ。
【請求項５】
移動通信システムに用いられるローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末であって、
ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ )を保有する手段と、
前記ＬＡＰＩをソース基地局(ｅＮｏｄｅＢ)に提供し、さらに前記ソース基地局を介してソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）に前記ＬＡＰＩを通知し、前記ソースＭＭＥに前記ＬＡＰＩを保持させる手段と、
を有し、
前記端末がハンドオーバする場合に、前記ソース基地局が前記ソースＭＭＥにＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄを送信し、前記ソースＭＭＥが前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する端末。
【請求項６】
移動通信システムに用いられるローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末であって、
ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ )を保有する手段と、
前記ＬＡＰＩをソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に提供し、さらにソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に前記ＬＡＰＩを通知して前記ソースＳＧＳＮに前記ＬＡＰＩを保持させる手段と、  を有し、
前記端末がハンドオーバする場合に、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄを送信し、前記ソースＳＧＳＮが前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する端末。  
【請求項７】
移動通信システムの通信方法であって、
ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）をソース基地局(ｅＮｏｄｅＢ)に提供し、さらに前記ソース基地局を介してソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）に前記ＬＡＰＩを通知して保持させ、
前記ソースＭＭＥは、前記端末がハンドオーバする場合に、前記ソース基地局からＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄを受信し、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する、移動通信システムの通信方法。
【請求項８】
移動通信システムの通信方法であって、
ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）をソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に提供し、さらに前記ソースＲＮＣを介してソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に前記ＬＡＰＩを通知して保持させ、
前記ソースＳＧＳＮは、前記端末がハンドオーバする場合に、前記ソースＲＮＣからＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄを受信し、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する、移動通信システムの通信方法。
【請求項９】
移動通信システムに用いられるＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）の通信方法であって、
ソースＭＭＥが、ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末からソース基地局（ｅＮｏｄｅＢ）に提供されたＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）を前記ソース基地局を介して受信して保持し、
前記ソースＭＭＥが、前記端末がハンドオーバする場合に、前記ソース基地局よりＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄを受信して、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する、ＭＭＥの通信方法。
【請求項１０】
移動通信システムに用いられるＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）の通信方法であって、
ソースＳＧＳＮが、ローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末からソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に提供されたＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）を前記ソースＲＮＣを介して受信して保持し、
前記ソースＳＧＳＮが、前記端末がハンドオーバする場合に、前記ソースＲＮＣよりＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄを受信して、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する、ＳＧＳＮの通信方法。
【請求項１１】
移動通信システムに用いられるローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末の通信方法であって、
ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ )を保有し、
前記ＬＡＰＩをソース基地局(ｅＮｏｄｅＢ)に提供し、さらにソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）に前記ＬＡＰＩを通知して前記ソースＭＭＥに前記ＬＡＰＩを保持させ、
前記端末がハンドオーバする場合に、前記ソース基地局が前記ソースＭＭＥにＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄを送信し、前記ソースＭＭＥが前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する、端末の通信方法。  
【請求項１２】
移動通信システムに用いられるローアクセスプライオリティ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ )の端末の通信方法であって、
ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ )を保有し、
前記ＬＡＰＩをソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に提供し、さらにソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に前記ＬＡＰＩを通知して前記ソースＳＧＳＮに前記ＬＡＰＩを保持させ、
前記端末がハンドオーバする場合に、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄを送信し、前記ソースＳＧＳＮが前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する、端末の通信方法。  
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願についての記載］
本発明は、日本国特許出願：特願２０１３−１４１１２７号（２０１３年７月４日出願）及び特願２０１３−１８７１０６号（２０１３年９月１０日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システムと方法と装置に関する。
【背景技術】
【０００２】
移動体通信システムのコアネットワークにおいては、様々な端末（移動機）に対して様々なサービスを提供するために、サービス毎に必要な機能を、コアネットワーク内のノードの全てが具備する必要がある。大規模移動体通信網等においては、コアネットワーク内に多くのノードが配備されている。端末は、位置登録毎に、コアネットワーク内のノードに分散して接続される。
【０００３】
このため、コアネットワーク内の全てのノードがサービス毎に必要な機能（サービス提供機能）を具備する必要がある。コアネットワーク内のノードにおいて一部のノードでも、当該サービス提供機能を具備していない場合には、端末に対してサービス継続性を保証することができなくなる。
【０００４】
なお、移動局が利用するサービスの種類に応じてパケット転送経路を最適化する構成として、例えば特許文献１には、移動局が外部網からのサービスを利用する場合、外部網に応じた特定のパケット転送装置を経由するようにパケット転送経路に制約を加え、移動局が移動通信ネットワークで提供されるサービスを利用する場合には、パケット転送経路に制約を与えない構成が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００３−３３８８３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
以下に関連技術の分析を与える。
【０００７】
上記したように、コアネットワーク内の各ノードは、全てのサービス提供機能を具備することから、高機能・高性能を要求されることになる。結果として、各コアネットワークノードが高価なものとなっている。
【０００８】
例えば、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で標準化されており、同報型配信を実現するベアラサービスであるＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）サービス（同時配信サービス）は、これに対応している移動機が比較的少ないため、サービス提供の機会は少ない。しかしながら、少数のＭＢＭＳユーザに対してサービスを提供しようとした場合、通信事業者としては、コアネットワーク内の全てのノードでＭＢＭＳ機能を具備しなければ、当該数のＭＢＭＳユーザに対してサービスを提供することは出来ない。
【０００９】
移動機のＭＢＭＳサービスの利用の要否に応じて、コアネットワークのノードを選択することができれば、通信事業者は、比較的に少数の高価なＭＢＭＳ対応コアネットワークノードと、多数の安価なＭＢＭＳ非対応コアネットワークノードを組み合わせて配備することで、全体の設備コストを効率化することが出来る（本発明者らの第１の知見）。
【００１０】
また、近年普及が進んでいる、３ＧＰＰにおけるマシン通信（ＭＴＣ：Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイス（Ｍ２Ｍデバイス）は、通話等に用いる携帯電話端末やスマートフォン等の通常の端末（ハンドセット端末）とは、移動特性や要求される通信品質などが大きく異なる。ここで、マシン通信サービスとして、例えば自動販売機の在庫や課金の遠隔管理や、センサシスム等の遠隔監視制御、車両監視、スマートグリッド等のほか、多岐に渡ることが知られている。
【００１１】
しかしながら、通信事業者としては、全コアネットワークノードにおいて、ＭＴＣデバイスと、ハンドセット端末の双方を、問題なく接続できる能力・機能を具備しない場合には、ＭＴＣデバイスと、ハンドセット端末の双方に対してサービスを提供することが出来ない。
【００１２】
ＭＴＣデバイスとハンドセット端末を適切なコアネットワークノードに接続することができれば、通信事業者は、相対的に安価なハンドセット端末用コアネットワークノードと、相対的に安価なＭＴＣデバイス用コアネットワークノードとを組み合わせて配備することが出来る。ＭＴＣデバイスは、低アクセス優先情報、又は通信遅延に対する耐性情報をコアネットワークノードに通知する端末でもよい（本発明者らの第２の知見）。
【００１３】
これは、１つのノードでハンドセット端末と、ＭＴＣデバイスの両方に対応可能とした、相対的に高価なコアネットワークノードを配備するよりも、全体の設備コストを効率化することが出来る（本発明者らの第３の知見）。
【００１４】
したがって、本発明は、上記問題点を解決すべく創案されたものであり、その目的は、コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供する、システム、方法、装置を提供することにある。
【課題を解決するための手段】
【００１５】
前記課題を解決する本発明は、概略以下の構成とされる（ただし、以下に限定されない）。
【００１６】
本発明の１つの側面によれば、移動通信システムであって、端末（ＵＥ）と、ソースｅＮｏｄｅＢまたはソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）と、ターゲットｅＮｏｄｅＢと、特定の端末を専門に扱うコアネットワーク内のソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）またはソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）と、前記特定の端末を専門に扱うコアネットワーク内のターゲットＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）と、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバと、を有し、前記ソースｅＮｏｄｅＢまたは前記ソースＲＮＣが前記ターゲットｅＮｏｄｅＢにハンドオーバを開始し、前記ソースｅＮｏｄｅＢは前記ソースＭＭＥにＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄメッセージを送信し、前記ソースＭＭＥまたは前記ソースＳＧＳＮは、前記ＤＮＳサーバを用いて前記ターゲットＭＭＥを選択する、移動通信システムが提供される。前記移動通信システムは、前記ターゲットＭＭＥの選択において前記特定の端末が保有するＬＡＰＩ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ）を用いてもよい。
あるいは、移動通信システムであって、端末（ＵＥ）と、ソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）またはソースｅＮｏｄｅＢと、ターゲットＲＮＣと、特定の端末を専門に扱うコアネットワーク内のソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）またはソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）と、前記特定の端末を専門に扱うコアネットワーク内のターゲットＳＧＳＮと、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバと、を有し、前記ソースＲＮＣまたは前記ソースｅＮｏｄｅＢが前記ターゲットＲＮＣにＲｅｌｏｃａｔｉｏｎを開始し、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースｅＮｏｄｅＢが前記ソースＭＭＥにＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージを送信し、前記ソースＳＧＳＮまたは前記ソースＭＭＥは、前記ＤＮＳサーバを用いて前記ターゲットＳＧＳＮを選択する、移動通信システムが提供される。前記移動通信システムは、前記ターゲットＳＧＳＮの選択において前記特定の端末が保有するＬＡＰＩ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ）を用いてもよい。
【００１７】
本発明の別の側面によれば、端末（ＵＥ）と、ソースｅＮｏｄｅＢまたはソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）と、ターゲットｅＮｏｄｅＢと、特定の端末を専用に扱うコアネットワーク内のソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）またはＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）と、前記特定の端末を専門に扱うコアネットワーク内のターゲットＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）と、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバと、を含む移動通信システムの通信方法であって、
前記ソースｅＮｏｄｅＢまたは前記ソースＲＮＣが前記ターゲットｅＮｏｄｅＢにハンドオーバを開始し、
前記ソースｅＮｏｄｅＢが前記ソースＭＭＥにＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースＲＮＣが前記ＳＧＳＮにＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄメッセージを送信し、
前記ソースＭＭＥまたは前記ソースＳＧＳＮは、前記ＤＮＳサーバを用いて前記ターゲットＭＭＥを選択する、移動通信システムの通信方法が提供される。
あるいは、端末（ＵＥ）と、Ｒｅｌｏｃａｔｉｏｎ元のソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）またはソースｅＮｏｄｅＢと、Ｒｅｌｏｃａｔｉｏｎ先のターゲットＲＮＣと、特定の端末を専用に扱うコアネットワーク内のソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）またはソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）と、前記特定の端末を専用に扱うコアネットワーク内のターゲットＳＧＳＮと、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバと、を含む移動通信システムの通信方法であって、
前記ソースＲＮＣまたは前記ソースｅＮｏｄｅＢが前記ターゲットＲＮＣにＲｅｌｏｃａｔｉｏｎを開始し、
前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースｅＮｏｄｅＢが前記ソースＭＭＥにＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージを送信し、
前記ソースＳＧＳＮまたは前記ソースＭＭＥが前記ＤＮＳサーバを用いて前記ターゲットＳＧＳＮを選択する、移動通信システムの通信方法が提供される。
【００１８】
本発明の別の側面によれば、移動通信システムに用いられ、ハンドオーバ機能を有する端末であって、ＬＡＰＩ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ）に関する情報を保有する手段と、前記端末に接続するソースｅＮｏｄｅＢまたはソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）からターゲットｅＮｏｄｅＢにハンドオーバする場合に、前記端末を専門に扱うコアネットワーク内のソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）またはソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に前記ＬＡＰＩを通知することにより前記端末を専門に扱うコアネットワーク内のターゲットＭＭＥの選択を指示する手段と、を有する、端末が提供される。
あるいは、移動通信システムに用いられ、ハンドオーバ機能を有する端末であって、ＬＡＰＩ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ）に関する情報を保有する手段と、前記端末に接続するソースｅＮｏｄｅＢまたはソースＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）からターゲットＲＮＣにハンドオーバする場合に、前記端末を専門に扱うコアネットワーク内のソースＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）またはソースＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に前記ＬＡＰＩを通知することにより前記端末を専門に扱うコアネットワーク内のターゲットＳＧＳＮの選択を指示する手段と、を有する、端末が提供される。
【発明の効果】
【００１９】
本発明によれば、コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供することができる。
【図面の簡単な説明】
【００２０】
【図１】本発明の第１の実施形態のシステム構成を例示する図である。
【図２】本発明の第２の実施形態のシステム構成を例示する図である。
【図３】本発明の第１の実施例のシーケンス例を例示する図である。
【図４】本発明の第２の実施例のシーケンス例を例示する図である。
【図５】本発明の第３の実施例のシーケンス例を例示する図である。
【図６】本発明の第３の実施例のシーケンス例を例示する図である。
【図７】本発明の第４の実施例のシーケンス例を例示する図である。
【図８】本発明の第５の実施例のシーケンス例を例示する図である。
【図９】本発明の第５の実施例のシーケンス例を例示する図である。
【図１０】本発明の第６の実施例のシーケンス例を例示する図である。
【図１１】本発明の第７の実施例のシーケンス例を例示する図である。
【図１２】本発明の第８の実施例のシーケンス例を例示する図である。
【図１３】本発明の第８の実施例のシーケンス例を例示する図である。
【図１４】本発明の第９の実施例のシーケンス例を例示する図である。
【図１５】本発明の第１０の実施例のシーケンス例を例示する図である。
【図１６】本発明の第１０の実施例のシーケンス例を例示する図である。
【図１７】本発明の第１１の実施例のシステム構成を例示する図である。
【図１８】本発明の第１１の実施例のシーケンス例を例示する図である。
【図１９】本発明の第１２の実施例のシステム構成を例示する図である。
【図２０】本発明の第１２の実施例のシステム構成を例示する図である。
【図２１】本発明の第１２の実施例のシーケンス例を示す図である。
【図２２】本発明の第１３、第１４の実施例のシーケンス例を示す図である。
【図２３】本発明の第１３、第１４の実施例のシーケンス例を示す図である。
【図２４】本発明の第１５の実施例のシーケンス例を示す図である。
【図２５】本発明の第１６の実施例のシーケンス例を示す図である。
【発明を実施するための形態】
【００２１】
本発明のいくつかの形態の１つによれば、移動体通信システムのコアネットワークが、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノード（特定ＭＭＥ／特定ＳＧＳＮ）を備え、前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する。
【００２２】
コアネットワークが、端末に対して提供するサービス機能が異なる複数のノード（２１／２２、又は、１２１／１２２）を備え、加入者情報と端末情報に基づき、前記端末に接続するノードを、前記端末が利用するサービス特性又は端末種別に応じて、前記複数のノードから選択し、前記端末（１）と前記選択されたノードとが接続する。すなわち、コアネットワークでは、予め定められた特定のサービス提供機能を具備したノード（２２、又は１２２）と、当該特定のサービス提供機能を具備しないノード（２１、又は１２１）を、組み合わせて配備する。
【００２３】
このため、特定サービス提供機能に最適化したノードと、特定サービス提供機能自体を具備しないノードとに分離することが可能とされ、ノードのコストの低減を可能としている。
【００２４】
本発明によれば、移動体通信ネットワークにおいて、サービス特性や端末種別などの条件に応じて、端末が特定のコアネットワークノードに接続できるようにし、さらにハンドオーバを可能としたものである。
【００２５】
＜態様１＞
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ユーザ装置、端末、移動機ともいう）から、アタッチリクエスト（Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ）を受信した、一般ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ：モビリティ管理エンティティ）は、前記ＵＥを、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ、Ｓｐｅｃｉｆｉｃ  ＭＭＥ）に接続するために、ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄ  ＮｏｄｅＢ：基地局装置）に対して、ＭＭＥ再選択要求信号（モビリティ管理エンティティ再選択要求信号）を送信する。なお、ＭＭＥ再選択要求信号は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。ＬＡＰＩは、Ｍ２Ｍ通信を一般の音声データ通信よりも低い優先度に設定するものである。例えばＭＴＣデバイスがネットワークに位置登録や発信するたびにＬＡＰＩがネットワークに通知され（例えばＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）プロトコルのアタッチ要求信号がＬＡＰＩを含む）、ｅＮｏｄｅＢ、ＭＭＥ、ＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）、ＰＧＷ（ＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋｓ）  Ｇａｔｅｗａｙ）等で保持される。またｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓは、例えばＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）  ｃｏｎｎｅｃｔｉｏｎ  ｒｅｑｕｅｓｔメッセージに設定され、ネットワークが過負荷（ｏｖｅｒｌｏａｄ）となった場合の制御を行うために導入されている（例えば３ＧＰＰ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ２３．３６８）。ＬＡＰＩ、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓは、例えばＭＴＣデバイス（ＭＴＣ端末）がネットワークに通知する情報要素であり、これらの情報要素を基（目印）に、基地局（ｅＮｏｄｅＢ）でＭＭＥを特定するようにしてもよい。
基地局（ｅＮｏｄｅＢ）は、ローアクセスプライオリティ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ）の端末（ＵＥ）に対して前記特定ＭＭＥを選択するようにしてもよい。前記ローアクセスプライオリティ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ）の端末（ＵＥ）はＭＴＣ機能を有する端末である。前記ローアクセスプライオリティ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）は、前記基地局にＲＲＣコネクション要求が前記ローアクセスプライオリティ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ）であることを指示する情報（ＬＡＰＩ）を提供し、前記基地局（ｅＮｏｄｅＢ）は、前記端末からの情報（ＬＡＰＩ）を用いて、ローアクセスプライオリティ（ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）を、前記特定ＭＭＥに向けるようにしてもよい。
【００２６】
前記ｅＮｏｄｅＢは、前記特定ＭＭＥに、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを再送することで、ＵＥを特定ＭＭＥへ接続している。
【００２７】
＜態様２＞
ＵＥからＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した一般ＭＭＥは、前記ＵＥを、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続するために、前記特定ＭＭＥに対して、ＭＭＥ変更要求信号（モビリティ管理エンティティ変更要求信号）を送信する。前記特定ＭＭＥは、アタッチ処理（Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅ）を継続することで、前記ＵＥを特定ＭＭＥへ接続している。
【００２８】
＜態様３＞
ＵＥからＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した一般ＭＭＥは、前記ＵＥを特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続するために、前記特定ＭＭＥの識別子を付与したアタッチリジェクト（Ａｔｔａｃｈ  Ｒｅｊｅｃｔ）を、前記ＵＥに送信する。前記ＵＥは、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔに、特定ＭＭＥの識別子を付与して、再送信することで、前記ＵＥを、前記特定ＭＭＥへ接続している。
【００２９】
＜態様４＞
ＵＥは、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）接続要求情報を付与したＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを、ＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。ＬＡＰＩ、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓは、例えばＭＴＣ端末がネットワークに通知する情報要素であり、これらの情報要素を基に基地局（ｅＮｏｄｅＢ）でＭＭＥを特定するようにしてもよい。
【００３０】
＜態様４−１＞
前記ＵＥから、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続するための特定ＭＭＥ接続要求情報を付与したＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）信号を受信した前記ｅＮｏｄｅＢは、前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて特定ＭＭＥに通知する。
【００３１】
＜態様４−２＞
前記ｅＮｏｄｅＢから前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて受信した特定ＭＭＥは、前記特定ＭＭＥ接続要求情報を保持する。
【００３２】
＜態様５＞
ＵＥとセッションを確立している一般ＭＭＥは、ｅＮｏｄｅＢと前記一般ＭＭＥとの間で確立されているＳ１コネクションの開放（Ｓ１  Ｒｅｌｅａｓｅ）時に、次回にＭＭＥを選択する際に、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）を選択するように、前記ｅＮｏｄｅＢに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（ＴＡ（Ｔｒａｃｋｉｎｇ  Ａｒｅａ）  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を送信した際に、前記ｅＮｏｄｅＢが前記特定ＭＭＥを選択することで、前記ＵＥを特定ＭＭＥへ接続している。
【００３３】
＜態様６＞
ＵＥからＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した一般ＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ：特許請求の範囲では「サービングＧＰＲＳサポートノード」と表記）は、前記ＵＥを特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）に接続するために、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワークコントローラ）に、ＳＧＳＮ再選択要求信号を送信し、前記ＲＮＣは、前記特定ＳＧＳＮに、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを再送することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。なお、ＳＧＳＮ再選択要求信号は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。すなわち、例えばＭＴＣ端末からネットワークに通知する、ＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基に、ＲＮＣでＳＧＳＮを特定するようにしてもよい。
【００３４】
＜態様７＞
ＵＥからＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）に接続するために、前記特定ＳＧＳＮにＳＧＳＮ変更要求信号を送信し、前記特定ＳＧＳＮはアタッチ処理（Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅ）を継続することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。
【００３５】
＜態様８＞
ＵＥからＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）に接続するために、前記特定ＳＧＳＮの識別子を付与したアタッチリジェクト（Ａｔｔａｃｈ  Ｒｅｊｅｃｔを前記ＵＥに送信し、前記ＵＥは、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔに、特定ＳＧＳＮ識別子を付与して再送信することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。
【００３６】
＜態様９＞
ＵＥは、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）接続要求情報を付与したコネクションリクエスト（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＡｔｔａｃｈ  ＲｅｑｕｅｓｔをＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。すなわち、例えばＭＴＣ端末からネットワークに通知する、ＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基にＲＮＣでＳＧＳＮを特定するようにしてもよい。
【００３７】
＜態様９−１＞
前記ＵＥから、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）に接続するための前記特定ＳＧＳＮ接続要求情報を付与したＲＲＣ信号を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮに通知する。
【００３８】
＜態様９−２＞  
前記ＲＮＣから前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する。
【００３９】
＜態様１０＞
ＵＥとセッションを確立している一般ＳＧＳＮは、Ｉｕ開放（Ｉｕ  Ｒｅｌｅａｓｅ）時に、次回ＳＧＳＮ選択で特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）を選択するようにＲＮＣに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（ＲＡ（Ｒｏｕｔｉｎｇ  Ａｒｅａ）  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を送信した際に、ＲＮＣが特定ＳＧＳＮを選択することで、ＵＥを特定ＳＧＳＮへ接続している。
【００４０】
＜態様１１＞
ＭＭＥを跨ぐハンドオーバが起動されると前記特定ＭＭＥは、保持している前記特定ＭＭＥ接続要求情報に応じてハンドオーバ先のＭＭＥを選択する。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基にＭＭＥを特定するようにしてもよい。
【００４１】
＜態様１１−１＞
前記特定ＭＭＥは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＭＭＥは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＭＭＥを決定してもよい。
【００４２】
＜態様１１−２＞
前記特定ＭＭＥは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。
【００４３】
＜態様１１−３＞
加入者の位置情報、及び前記特定ＭＭＥ接続要求情報などを入力情報として、１つ又は複数のＭＭＥを提供可能なＤＮＳサーバ。
【００４４】
＜態様１１−４＞
ＭＭＥを跨ぐハンドオーバが起動された際、ハンドオーバ元前記特定ＭＭＥは保持している前記特定ＭＭＥ接続要求情報をハンドオーバ先の特定ＭＭＥに通知する。
【００４５】
＜態様１２＞
ＳＧＳＮを跨ぐハンドオーバが起動されると、前記特定ＳＧＳＮは、保持している前記特定ＳＧＳＮ接続要求情報に応じてハンドオーバ先のＳＧＳＮを選択する。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基にＳＧＳＮを特定するようにしてもよい。
【００４６】
＜態様１２−１＞
前記特定ＳＧＳＮは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＳＧＳＮは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＳＧＳＮを決定してもよい。
【００４７】
＜態様１２−２＞
前記特定ＳＧＳＮは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＳＧＳＮの候補群の中から選択してもよい。
【００４８】
＜態様１２−３＞
加入者の位置情報、及び前記特定ＳＧＳＮ接続要求情報などを入力情報として、１つ或いは複数のＳＧＳＮを提供可能なＤＮＳサーバ。
【００４９】
＜態様１２−４＞
ＳＧＳＮを跨ぐハンドオーバが起動された際、ハンドオーバ元前記特定ＳＧＳＮは保持している前記特定ＳＧＳＮ接続要求情報をハンドオーバ先特定ＳＧＳＮに通知する。
【００５０】
＜態様１３＞
ＭＭＥからＳＧＳＮに移動するハンドオーバが起動されると前記特定ＭＭＥは、保持している前記特定ＭＭＥ接続要求情報に応じてハンドオーバ先のＭＭＥを選択する。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基にＭＭＥを特定するようにしてもよい。
【００５１】
＜態様１３−１＞
前記特定ＭＭＥは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＭＭＥは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＳＧＳＮを決定してもよい。
【００５２】
＜態様１３−２＞
前記特定ＭＭＥは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。
【００５３】
＜態様１３−３＞
ＭＭＥからＳＧＳＮに移動するハンドオーバが起動された際、ハンドオーバ元前記特定ＭＭＥは保持している前記特定ＭＭＥ接続要求情報をハンドオーバ先特定ＳＧＳＮに通知する。
【００５４】
＜態様１３−４＞
前記特定ＭＭＥ接続要求情報と、前記特定ＳＧＳＮ接続要求情報が区別無く、同一の情報として扱われるシステム。
【００５５】
＜態様１３−５＞
前記特定ＭＭＥ接続要求情報と、前記特定ＳＧＳＮ接続要求情報とが、それぞれ別の情報として扱われるシステム。
【００５６】
＜態様１４＞
ＳＧＳＮからＭＭＥに移動するハンドオーバが起動されると、前記特定ＳＧＳＮは、保持している前記特定ＳＧＳＮ接続要求情報に応じて、ハンドオーバ先のＭＭＥを選択する。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基に、ＭＭＥを特定するようにしてもよい。
【００５７】
＜態様１４−１＞
前記特定ＳＧＳＮは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＳＧＳＮは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＭＭＥを決定してもよい。
【００５８】
＜態様１４−２＞
前記特定ＳＧＳＮは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。
【００５９】
＜態様１４−３＞
ＳＧＳＮからＭＭＥに移動するハンドオーバが起動された際、ハンドオーバ元前記特定ＳＧＳＮは保持している前記特定ＳＧＳＮ接続要求情報をハンドオーバ先特定ＭＭＥに通知する。
【００６０】
＜態様１４−４＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。
【００６１】
＜態様１４−５＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。
【００６２】
＜態様１５＞
ＵＥは、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）接続要求情報を付与したＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＴｒａｃｋｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔを、ｎｅｗ  ＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基にｅＮｏｄｅＢでＭＭＥを特定するようにしてもよい。
【００６３】
＜態様１５−１＞
前記ＵＥから、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続するための前記特定ＭＭＥ接続要求情報を付与したＲＲＣ信号を受信した前記ｅＮｏｄｅＢは、前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて特定ＭＭＥに通知する。
【００６４】
＜態様１５−２＞
前記ｅＮｏｄｅＢから前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて受信した特定ＭＭＥは、前記特定ＭＭＥ接続要求情報を保持する。
【００６５】
＜態様１５−３＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。
【００６６】
＜態様１５−４＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。
【００６７】
＜態様１６＞
ＵＥは、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）接続要求情報を付与したコネクションリクエスト（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＲｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔをｎｅｗ  ＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ、又はｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ等の情報要素を基にＲＮＣでＳＧＳＮを特定するようにしてもよい。
【００６８】
＜態様１６−１＞
前記ＵＥから、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）に接続するための前記特定ＳＧＳＮ接続要求情報を付与したＲＲＣ信号を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮに通知する。
【００６９】
＜態様１６−２＞
前記ＲＮＣから前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する。
【００７０】
＜態様１６−３＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。
【００７１】
＜態様１６−４＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。
【００７２】
上記態様１乃至１６に記載したように、本発明によれば、端末毎に接続するコアネットワークノードを、端末の利用するサービス特性に応じて選択して接続する構成としている。こうすることで、コアネットワークでは、特定のサービス提供機能を具備したノードと具備しないノードを、組み合わせて配備し、各ノードのうち、あるノードを特定サービス提供機能に最適化し、他のノードは当該特定サービス提供機能を具備しないという具合に差異を設けることで、ノードのコストの低減を図るようにしている。以下、図面を参照して、いくつかの実施形態と具体的な実施例に即して説明する。
【００７３】
＜実施形態１＞
図１は、本発明の実施形態１を説明する図である。実施形態１として、ＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）において、Ａｔｔａｃｈ時に、ＵＥと特定ＭＭＥを接続させる構成について説明する。
【００７４】
図１において、ＵＥ１（ユーザ装置）は、例えば携帯電話端末（移動機）を示す。あるいは、例えば上記したＭＴＣデバイス、ＭＢＭＳ対応端末等であってもよい。
【００７５】
ｅＮｏｄｅＢ１１は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）の基地局装置である。
【００７６】
ＭＭＥ２１、２２は、ＥＰＣで導入されたモビリティを管理する装置である。Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＵＥ１を接続させたい特定ＭＭＥであり、一般ＭＭＥ（２１）は、それ以外のＭＭＥである。特に制限されないが、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、例えばマシン通信（ＭＴＣ）サービスと、対応端末（Ｍ２Ｍデバイス）向けにカスタマイズした構成（例えばネットワーク制御を扱うＣ−Ｐｌａｎｅを補強）のＭＭＥとして構成される。あるいは、ＭＢＭＳ対応のＭＭＥとして構成してもよい。
【００７７】
ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）３１は、加入者情報を保持するデータベースである。
【００７８】
Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  ＧａｔｅＷａｙ）４１、及びＰ−ＧＷ（Ｐａｃｋｅｔ  ｄａｔａ  ｎｅｔｗｏｒｋ  ＧａｔｅＷａｙ:ＰＤＮ−ＧＷともいう）５１は、ユーザプレーンを扱う装置である。
【００７９】
サービスネットワーク６１は、外部ネットワークを示す。
【００８０】
図１において、ｅＮｏｄｅＢが無線アクセスネットワーク（ＲＡＮ：Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）、ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ等がコアネットワーク（ＣＮ：Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）に対応する。
【００８１】
以下、上記した実施形態１について、制御方式が互いに相違した、いくつかの実施例を説明する。実施例１−５は上記態様１−５にそれぞれ対応する。
【００８２】
＜実施例１＞
図３は、実施例１の動作例を説明するためのシーケンス図である。図３において、
ＵＥは図１のＵＥ１、
ｅＮｏｄｅＢは図１のｅＮｏｄｅＢ１１、
一般ＭＭＥは図１の一般ＭＭＥ２１、
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥは、図１のＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ（特定ＭＭＥ）２２、
Ｓｅｒｖｉｎｇ  ＧＷは、図１のＳ−ＧＷ４１、
ＰＤＮ  ＧＷは、図１のＰ−ＧＷ５１、
ＨＳＳは、図１のＨＳＳ３１にそれぞれ対応する。
【００８３】
ＰＣＲＦは、ポリシと課金ルール機能（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ）である。また、ＥＩＲ（Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ  Ｒｅｇｉｓｔｅｒ）は、ＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ）等を保持し、ＭＭＥとＳ１３インタフェースで接続される。
【００８４】
なお、図３において、例えば「１．Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ」は、ＵＥからｅＮｏｄｅＢへのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔの送信がシーケンス１であることを表わしている。図のＵＥの参照符号１（構成要素の参照符号）とは異なることを区別するため、以下の説明では、このシーケンス番号１を、「Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）」のように、括弧書きで表記する。他のシーケンス番号についても同様とする。また、図４以降のシーケンス図についても同様の表記とする。なお、図３は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．３．２．１−１：  Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．３．２の記載が参照される。以下、図１及び図３を参照して、動作シーケンスを説明する。
【００８５】
図３を参照すると、ＵＥ１が、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１は、ＭＭＥに、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を中継する。
【００８６】
この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）は、ｅＮｏｄｅＢ１１から一般ＭＭＥ２１に転送される場合がある。
【００８７】
一般ＭＭＥ２１では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（４、５ｂ）にて、ＵＥ１から、端末情報（ＭＥ  Ｉｄｅｎｔｉｔｙ）を取得する。
【００８８】
なお、一般ＭＭＥ２１は、ＭＥ  Ｉｄｅｎｔｉｔｙ  Ｃｈｅｃｋ  Ｒｅｑｕｅｓｔ（５ｂ）をＥＩＲに送り、ＥＩＲはＭＤ  Ｉｄｅｎｔｉｔｙ  Ｃｈｅｃｋ  Ａｃｋ  を一般ＭＭＥに返す。更に、ＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイル取得まで、一般ＭＭＥ２１で行う。
【００８９】
端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続するべきか判断する。
【００９０】
一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【００９１】
ＵＥ１を、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を指示するために、ＭＭＥ選択信号：ＭＭＥ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ（本実施形態で新規に導入した、Ｓ１ＡＰ（Ｓ１  アプリケーション）信号）を送信する。
【００９２】
この時、一般ＭＭＥ２１は、ＭＭＥ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ信号に、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２の識別子（例えばＧＵＭＭＥＩ（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  ＭＭＥ  Ｉｄｅｎｔｉｔｙ））を設定する。すなわち、コアネットワーク内でベアラ生成前にｅＮｏｄｅＢに再選択要求を送信し、新たなＭＭＥ選択に必要な情報（ＧＵＭＭＥＩ）を載せる。ＭＭＥは、ＵＥが、ｒｅ−ｓｅｌｅｃｔｉｏｎ対象であるか否かを判断する機能を具備する。
【００９３】
ｅＮｏｄｅＢ１１は、ＭＭＥ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ信号を受信すると、この信号に設定された識別子に従って、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２を選択し、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）をＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送する。特定ＭＭＥ２２では、Ａｔｔａｃｈ  ＲｅｑｕｅｓｔのＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）パラメータ（ＵＥとＭＭＥ間の認証に用いられる）が必要であるため、ｅＮｏｄｅＢ１１で再送する。ｅＮｏｄｅＢ１１では、ＮＡＳメッセージを保持する機能が必要である。
【００９４】
新ＭＭＥ（＝Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２）では、旧ＭＭＥ（＝一般ＭＭＥ）を特定できないため、コンテキスト（Ｃｏｎｔｅｘｔ）を、旧ＭＭＥ（＝一般ＭＭＥ）から引き継ぐことはできない。そのため、新ＭＭＥ（＝Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥＭＭＥ２２）では、再度、認証／加入者プロファイルの取得を行う必要がある。
【００９５】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更にＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、一般ＭＭＥ２１と同様の処理を行う。
【００９６】
端末情報及び加入者プロファイルを取得したＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＵＥ１を、一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続するべきか判断する。
【００９７】
ここでは、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ｅＮｏｄｅＢ１１で再選択された後である為、ＭＭＥ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ信号を送信せずに、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。すなわち、
・Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２からＨＳＳ３１へのＵｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ（８）の送信、
・ＨＳＳ３１からＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２へのＵｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  Ａｃｋ（１１）の送信、
・Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２からＳ−ＧＷ４１へのＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ（１２）の送信、
・Ｓ−ＧＷ４１からＰ−ＧＷ５１へのＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ（１２）の送信、
・Ｐ−ＧＷ５１とＰＣＲＦでのＰＣＥＦ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ）  Ｉｎｉｔｉａｔｅｄ  ＩＰ−ＣＡＮ（ＩＰ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）  Ｓｅｓｓｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ／Ｍｏｄｉｆｉｃａｔｉｏｎ手順（１４）、  
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｃｅ（１５）の送信、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのＦｉｒｓｔ  Ｄｏｗｎ  Ｌｉｎｋ  Ｄａｔａの送信  （ハンドオーバ（ＨＯ）でない場合）、
・Ｓ−ＧＷ４１からＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２へのＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｃｅ（１６）の送信、
・Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２からｅＮｏｄｅＢ１１へのＩｎｉｔｉａｌ  Ｃｏｎｔｅｘｔ  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ  Ａｃｃｅｐｔ（１７）の送信、
・ｅＮｏｄｅＢ１１からＵＥ１へのＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（１８）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅ（１９）の送信、
・ｅＮｏｄｅＢ１１からＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２へのＩｎｉｔｉａｎｌ  Ｃｏｎｔｅｘｔ  Ｓｅｔｕｐ  Ｒｅｓｐｏｎｃｅ（２０）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのＤｉｒｅｃｔ  Ｔｒａｎｓｆｅｒ（２１）の送信、
・ｅＮｏｄｅＢ１１からＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２へのＡｔｔａｃｈ  Ｃｏｍｐｌｅｔｅ（２２）の送信、
・ＵＥ１からＳ−ＧＷ４１、Ｐ−ＧＷ５１へのＦｉｒｓｔ  Ｕｐｌｉｎｋ  ｄａｔａの送信、
・Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２からＳ−ＧＷ４１へのＭｏｄｉｆｙ  Ｂｅａｅｒ  Ｒｅｑｕｅｓｔ（２３）の送信、
・Ｓ−ＧＷ４１からＰ−ＧＷ５１ヘのＭｏｄｉｆｙ  Ｂｅａｅｒ  Ｒｅｑｕｅｓｔ（２３ａ）の送信、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのＭｏｄｉｆｙ  Ｂｅａｅｒ  Ｒｅｓｐｏｎｃｅ（２３ｂ）の送信、
・Ｓ−ＧＷ４１からＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２へのＭｏｄｉｆｙ  Ｂｅａｅｒ  Ｒｅｓｐｏｎｃｅ（２４）の送信、
・Ｐ−ＧＷ５１、Ｓ−ＧＷ４１からＵＥ１への最初のダウンリンクデータ（Ｆｉｒｓｔ  Ｄｏｗｎｌｉｎｋ  ｄａｔａ）の送信、
が行われる。
【００９８】
また、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この判断は、
ＵＥ１からの情報、例えば、
・ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ：国際移動体加入者識別番号）、
・ＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ：  国際移動体装置識別番号（端末識別番号））、
・ＵＥ  ｎｅｔｗｏｒｋ  ｃａｐａｂｉｌｉｔｙ、
・ＭＳ  ｎｅｔｗｏｒｋ  ｃａｐａｂｉｌｉｔｙ、
・Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  ｃｌａｓｓｍａｒｋ  ２、
・Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  ｃｌａｓｓｍａｒｋ  ３、
・Ｄｅｖｉｃｅ  ｐｒｏｐｅｒｔｉｅｓ、又は、
・ＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）、又は、
・ＭＴＣグループを識別するＩＤ、又は、
・ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ、又は、
・ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ、又は、
・今後追加されるＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ、また、ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔなどのその他のＮＡＳ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ（Ｐｕｂｌｉｃ  ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）−ｉｄなど）、
ＨＳＳ３１からの情報、例えば、
・Ｆｅａｔｕｒｅ−Ｌｉｓｔ、
・ＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）、又は、
・今後追加されるＵｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  Ａｎｓｗｅｒ／Ｉｎｓｅｒｔ  Ｓｕｂｓｃｒｉｂｅｒ  Ｄａｔａ  Ｒｅｑｕｅｓｔ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子、
のいずれか、もしくは複数、
を組み合わせた上で行う。
【００９９】
また、図３では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に対して、一般ＭＭＥ２１に接続すべきＵＥ１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を促すことが可能である。
【０１００】
以上説明したように、本実施形態においては、ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けてＭＭＥを再選択した上で、アタッチ処理（Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
【０１０１】
＜実施例２＞
実施例２として、ＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）において、Ａｔｔａｃｈ時にＵＥとＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを接続させる別の例を説明する。実施例２のシステム構成は、実施例１と同様である。
【０１０２】
図４は、実施例２の動作例を示すシーケンス図である。なお、図４は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．３．２．１−１：  Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．３．２の記載が参照される。以下、図１及び図４を参照して動作を説明する。
【０１０３】
ＵＥ１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、ｅＮｏｄｅＢ１１が受信し、ＭＭＥにＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を中継する。この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。
【０１０４】
一般ＭＭＥ２１では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（５ｂ）にて、端末情報（ＭＥ  Ｉｄｅｎｔｉｔｙ）を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイルまでは一般ＭＭＥ２１で行う。
【０１０５】
端末情報、及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１０６】
ＵＥ１をＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に対して、ＭＭＥ変更を指示するために、ＭＭＥ変更要求信号（ＭＭＥ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ）（本実施例で新規に導入した、ＧＴＰ（ＧＰＲＳ  Ｔｕｎｎｅｌｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）信号）を送信する。
【０１０７】
この時、一般ＭＭＥ２１は、ＭＭＥ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ信号に、端末認証や加入者プロファイルの取得によって生成したコンテキスト（ｃｏｎｔｅｘｔ）情報を設定する。
【０１０８】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＭＭＥ変更要求信号（ＭＭＥ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｔ）を受信すると、該ＭＭＥ変更要求信号に設定されたｃｏｎｔｅｘｔ情報を保持し、一般ＭＭＥ２１に対して、ＭＭＥ  Ｃｈａｎｇｅ  Ｒｅｓｐｏｎｓｅ信号（本実施例で新規に導入した、ＧＴＰ信号）を送信する。
【０１０９】
その後、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＨＳＳ３１に対して、Ｕｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ信号（８）を送信し、ＭＭＥが変更されたことをＨＳＳ３１に通知する。
【０１１０】
ＨＳＳ３１に対して、ＭＭＥの変更ＭＭＥを通知するため、Ｕｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  ＲｅｑｕｅｓｔをＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２で再実施する。以降のＡｔｔａｃｈ  ＰｒｏｃｅｄｕｒｅはＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２で実施する。
【０１１１】
また、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、一般ＭＭＥ２１から受け取ったセキュリティ・コンテキスト（ｓｅｃｕｒｉｔｙ  ｃｏｎｔｅｘｔ）情報が有効であれば、再認証を省略することが出来る。
【０１１２】
その後、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、アタッチ処理（Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅ）を継続し、ｅＮｏｄｅＢ１１は、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２から、Ｉｎｉｔｉａｌ  Ｃｏｎｔｅｘｔ  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ  Ａｃｃｅｐｔ（１７）を受信する。
【０１１３】
Ｉｎｉｔｉａｌ  Ｃｏｎｔｅｘｔ  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ  Ａｃｃｅｐｔ（１７）は、一般ＭＭＥ２１で受けたＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）に対する応答である。なお、一般ＭＭＥ２１とは、別のＭＭＥからの応答（Ｒｅｓｐｏｎｃｅ）を受信できる機能がｅＮｏｄｅＢ１１に実装されている必要がある。
【０１１４】
その後は、通常のアタッチ処理（Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅ）を継続する。
【０１１５】
また、一般ＭＭＥ２１、及びＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、実施例１と同様である。
【０１１６】
また、図４には、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で一般ＭＭＥ２１にＭＭＥ変更を促すことが可能である。
【０１１７】
以上説明したように、本実施例においては、一般ＭＭＥがＣｕｓｔｏｍｉｚｅｄ  ＭＭＥに対してＭＭＥ変更を指示し、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥはそれを受けてＭＭＥを変更した上で、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
【０１１８】
＜実施例３＞
実施例３として、ＥＰＣにおいてＡｔｔａｃｈ時に、ＵＥとＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを接続させる例を説明する。実施例３のシステム構成は、実施例１と同様である。
【０１１９】
図５、図６は、実施例３の動作例を説明するシーケンス図である。なお、図５、６は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．３．２．１−１：  Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．３．２の記載が参照される。以下、図１及び図５、図６を参照して動作を説明する。
【０１２０】
ＵＥ１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を、一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。
【０１２１】
一般ＭＭＥ２１では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（５ｂ）にて端末情報（ＭＥ  Ｉｄｅｎｔｉｔｙ）を取得する。更に、一般ＭＭＥ２１は、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。
【０１２２】
端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１２３】
ＵＥ１を、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続せずに、ＵＥ１に対してアタッチリジェクト（Ａｔｔａｃｈ  Ｒｅｊｅｃｔ）メッセージを送信する。すなわち、一般ＭＭＥ２１はＩｎｉｔｉａｌ  Ｃｏｎｔｅｘｔ  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ  Ｒｅｊｅｃｔ（１７）をｅＮｏｄｅＢ１１に送信する。
【０１２４】
この時、一般ＭＭＥ２１は、Ａｔｔａｃｈ  Ｒｅｊｅｃｔ信号に、再アタッチ（ｒｅ−ａｔｔａｃｈ）を指示するパラメータ（本実施例で導入した、新規パラメータ）、及び、ｒｅ−ａｔｔａｃｈ時に、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２を、ｅＮｏｄｅＢ１１が選択できるように、ＧＵＭＭＥＩ（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  ＭＭＥ  ｉｄｅｎｔｉｆｉｅｒ）を含むＧＵＴＩ（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｙ）パラメータ（本実施例で導入した、新規パラメータ）を設定する。ＧＵＴＩパラメータは、ＧＵＭＭＥＩとＭ−ＴＭＳＩ（Ｔｅｍｐｏｒａｙ  Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ  Ｉｄｅｎｔｉｔｙ）から構成される。ＭＭＥＩは、ＭＣＣ（Ｍｏｂｉｌｅ  Ｃｏｕｎｔｒｙ  Ｃｏｄｅ）とＭＮＣ（Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ  Ｃｏｄｅ）とＭＭＥ  Ｉｄｅｎｔｉｆｉｅｒから構成される。これらは本実施例で導入した新規なパラメータであるが、ｅＮｏｄｅＢ１１は、透過（ｔｒａｎｓｐａｒｅｎｔ）であるため、ｅＮｏｄｅＢ１１には影響はない。
【０１２５】
ＵＥ１は、ｅＮｏｄｅＢ１１からＡｔｔａｃｈ  Ｒｅｊｅｃｔ信号を受信すると、図６に示すように、Ａｔｔａｃｈ−Ｒｅｊｅｃｔ信号に設定されたｒｅ−ａｔｔａｃｈを指示するパラメータ、及び、ＧＵＴＩパラメータに従って、ＧＵＴＩを設定したＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）（ＧＵＴＩによるＡｔｔａｃｈ）を、ｅＮｏｄｅＢ１１に送信する。この時、ｅＮｏｄｅＢ１１は、ＧＵＴＩに含まれるＧＵＭＭＥＩから適切なＭＭＥを判断し、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送する。
【０１２６】
なお、ＵＥ１には、Ａｔｔａｃｈ  Ｒｅｊｅｃｔ信号にてＧＵＴＩを受け付け、ｒｅ−ａｔｔａｃｈ（図６のＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１））送信時に、Ａｔｔａｃｈ  ｒｅｊｅｃｔで指示されたＧＵＴＩを使用する機能が実装されている。ＭＭＥは、このＵＥがＲｅ−Ｓｅｌｅｃｔｉｏｎ対象か判断する機能が実装されている。
【０１２７】
その後、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。ただし、ＧＵＴＩが設定されたＡｔｔａｃｈ  Ｒｅｑｕｅｓｔだが、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２自身は、ｃｏｎｔｅｘｔ情報を保持していない。
【０１２８】
このため、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（４）にて、端末情報を取得し、更にＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。
【０１２９】
また、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２はＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、前記実施例１と同様である。
【０１３０】
また、図５及び図６では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様にして、ＵＥ１にＭＭＥ再選択を促すことが可能である。
【０１３１】
以上説明したように、本実施例においては、一般ＭＭＥがＵＥに対してＭＭＥ再選択を指示し、ＵＥはそれを受けてＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを指定した上で、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
【０１３２】
＜実施例４＞
実施例４として、ＥＰＣにおいてＡｔｔａｃｈ時にＵＥとＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを接続させる例を説明する。実施例４の構成は実施例１と同様である。図７は、実施例４の動作例を説明するためのシーケンス図である。なお、図７は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．３．２．１−１：  Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．３．２の記載が参照される。以下、図１及び図７を参照して動作を説明する。
【０１３３】
ＵＥ１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）をＭＭＥに送信する為に、まずｅＮｏｄｅＢ１１とのＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を送信する。
【０１３４】
この時、ＵＥ１は、本信号にＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ  Ｉｄｅｎｔｉｔｙ）等））を設定する。
【０１３５】
ＵＥ１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｑｕｅｓｔにてｅＮｏｄｅＢに、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥに接続可能であることを通知する  ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの新規パラメータ（ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅ（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔを発信した原因を示す情報要素（通信確立要因）)の新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。
【０１３６】
ｅＮｏｄｅＢ１１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１がＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続すべきことを記憶し、その後のＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１３７】
ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ（１）の受信した時に記憶した情報（ＵＥ１がＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続すべきこと）から、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送する。  
【０１３８】
Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）には、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄ  ＭＭＥに接続可能であることを通知するＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）がｅＮｏｄｅＢ１１によって設定されＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に通知される。
【０１３９】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を受信した後、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）で受信した、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄ  ＭＭＥに接続可能であることを通知するＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの新規パラメータ（ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）を保持する。
【０１４０】
また、ＵＥ１は、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２のどちらのＭＭＥに接続するべきかを、ｅＮｏｄｅＢ１１に指示する機能を具備する。この時、ＵＥ１はコアネットワーク上の全てＭＭＥの情報を保持することは出来ないので、ｅＮｏｄｅＢ１１への指示は、ＭＭＥを一意に選択できる識別子ではなく、ＭＭＥ種別、若しくはサービス種別等の情報が用いられる。
【０１４１】
また、ｅＮｏｄｅＢ１１は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備している。
【０１４２】
ｅＮｏｄｅＢ１１において、ＭＭＥの選択は、前述のとおり、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ内のユーザＩＤ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ）、通信確立要因（Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅ）の新規Ｖａｌｕｅ、又は新規パラメータ、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
【０１４３】
以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを指定した上で、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
【０１４４】
＜実施例５＞
実施例５として、ＥＰＣにおいて、トラッキングエリア更新（ＴＡ  Ｕｐｄａｔｅ）時に、ＵＥとＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを接続させる例を説明する。実施例５の構成は、実施例１と同様である。
【０１４５】
図８、図９は、実施例５の動作例を説明するためのシーケンス図である。なお、図８は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．３．５−１：  Ｓ１  Ｒｅｌｅａｓｅ  Ｐｒｏｃｅｄｕｒｅに基づく。ＴＳ２３．４０１  ５．３．５が参照される。図９は、Ｆｉｇｕｒｅ  ５．３．３．１−１：  Ｔｒａｃｋｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  ｐｒｏｃｅｄｕｒｅ  ｗｉｔｈ  Ｓｅｒｖｉｎｇ  ＧＷ  ｃｈａｎｇｅに基づく。３ＧＰＰ  ＴＳ２３．４０１  ５．３．３が参照される。図１、図８、図９（及び図３の一部）を参照して、動作を説明する。
【０１４６】
ＵＥ１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを送信すると（図３の１）、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＡｔｔａｃｈ  ＲｅｑｕｅｓｔがＭＭＥに中継される（図３の２参照）。
【０１４７】
この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔが一般ＭＭＥ２１に転送される場合がある。
【０１４８】
一般ＭＭＥ２１ではＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（図３の４参照）にて端末情報を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。
【０１４９】
端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続するべきか判断する。その後、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。一般ＭＭＥ２１に接続する場合は、ここで処理が完了する。
【０１５０】
ＵＥ１を、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続する場合、一般ＭＭＥ２１はＵＥ１に対して、トラッキングエリア更新（ＴＡ  Ｕｐｄａｔｅ）を行わせるために、図８に示すように、Ｓ１  Ｒｅｌｅａｓｅを行う。この時、一般ＭＭＥ２１はｅＮｏｄｅＢ１１に、Ｓ１  ＵＥ  Ｃｏｎｔｅｘｔ  Ｒｅｌｅａｓｅ  Ｃｏｍｍａｎｄ（４）を送信する。
【０１５１】
一般ＭＭＥ２１は、Ｓ１  ＵＥ  Ｃｏｎｔｅｘｔ  Ｒｅｌｅａｓｅ  Ｃｏｍｍａｎｄ（４）で、次にｅＮｏｄｅＢがＭＭＥとＳ１  Ｃｏｎｎｅｃｔｉｏｎを確立するときに選択するべきＭＭＥを、ＭＭＥ識別子（例えばＧＵＭＭＥＩ）で指示する。Ｌｏａｄ  Ｂａｌａｎｃｉｎｇ  ＴＡＵ起動のためのＳ１  Ｒｅｌｅａｓｅ時に、ｅＮｏｄｅＢに対して、次のＭＭＥを指定するＧＵＭＭＥＩを指示するためのパラメータは新規パラメータである。この時、ｅＮｏｄｅＢ１１は、Ｓ１  Ｒｅｌｅａｓｅ完了後もＵＥ１に対するセッション情報を保持している間、次回ＭＭＥ選択の為の情報として、ＭＭＥ識別子を保持し続ける。
【０１５２】
Ｓ１  Ｒｅｌｅａｓｅが行われると、次にＵＥ１は、図９に示すように、ＴＡＵ  Ｒｅｑｕｅｓｔ（２）を送信する。ＴＡＵ  Ｒｅｑｕｅｓｔ（２）を、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＴＡＵ  Ｒｅｑｕｅｓｔ（３）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、Ｓ１  Ｒｅｌｅａｓｅ済みの状態であることから、ＭＭＥ選択を行い、Ｓ１  Ｃｏｎｎｅｃｔｉｏｎを確立する。ｅＮｏｄｅＢは、Ｓ１  Ｒｅｌｅａｓｅ時にｏｌｄ  ＭＭＥ（＝一般ＭＭＥ）から指示されたＧＵＭＭＥＩに従ってＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを選択する（※ｅＮｏｄｅＢはＵＥ毎に次のＧＵＭＭＥＩを保持する機能を有する）。
【０１５３】
ＭＭＥの選択において、ｅＮｏｄｅＢ１１は、一般ＭＭＥ２１から受信したＳ１  ＵＥ  Ｃｏｎｔｅｘｔ  Ｒｅｌｅａｓｅ  Ｃｏｍｍａｎｄ信号で指示されたＧＵＭＭＥＩのＭＭＥ識別子（ＭＭＥ  Ｉｄｅｎｔｉｆｉｅｒ）に従い、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２を選択する。ＮＡＳ上のＧＵＴＩ（ＧＵＭＭＥＩ）は、ｏｌｄ  ＭＭＥ（＝一般ＭＭＥ）を示しているのでｃｏｎｔｅｘｔ取得が可能である。
【０１５４】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＴＡＵ  Ｒｅｑｕｅｓｔ（３）を受信した後、通常のＴＡ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、一般ＭＭＥ２１にＣｏｎｔｅｘｔ  Ｒｅｑｕｅｓｔ（４）を送信し、その応答Ｃｏｎｔｅｘｔ  Ｒｅｓｐｏｎｃｅ（５）を受け取る。
【０１５５】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、Ｓ−ＧＷがリロケート（ｒｅｌｏｃａｔｅ）した場合、一般ＭＭＥにＳ−ＧＷの変更指示を含むＣｏｎｔｅｘｔ  Ａｃｋｎｏｗｌｅｄｇｅ（７）を送信し、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２が新たなＳ−ＧＷ４１（ｎｅｗ  Ｓｅｒｖｉｎｇ  ＧＷ）を選択すると、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、新たなＳ−ＧＷ４１に、Ｃｒｅａｔｅ  Ｓｅｓｓｈｏｎ  Ｒｅｑｕｅｓｔ（８）を送信する。
【０１５６】
これを受けて新たなＳ−ＧＷ４１（ｎｅｗ  Ｓｅｒｖｉｎｇ  ＧＷ）は、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔ（９）をＰ−ＧＷ５１に送信し、その応答をＰ−ＧＷ５１から受けると、新たなＳ−ＧＷはＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｃｅ  （１１）をＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に返す。
【０１５７】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２はＵｐｄａｔｅ  Ｌｏｃａｔｉｏｎ（１２）をＨＳＳ３１に送信する。
【０１５８】
ＨＳＳ３１からＣａｎｃｅｌ  Ｌｏｃａｔｉｏｎ（１３）を受け取った一般ＭＭＥ２１は、ＭＭコンテキストを削除し、肯定応答（Ｃａｎｃｅｌ  Ｌｏｃａｔｉｏｎ  Ａｃｋ）（１４）をＨＳＳ３１に送信する。ＨＳＳ３１からのＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２にＵｐｄａｔａ  Ｌｏｃａｔｉｏｎ（１２）に対する肯定応答（Ｕｐｄａｔａ  Ｌｏｃａｔｉｏｎ  Ａｃｋ）（１７）が送信される。
【０１５９】
一般ＭＭＥ２１は、旧Ｓ−ＧＷ４１（ｏｌｄ  Ｓｅｒｖｉｎｇ  ＧＷ）にＤｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ（１８）を送信し、その応答（１９）が、旧Ｓ−ＧＷ４１（ｏｌｄ  Ｓｅｒｖｉｎｇ  ＧＷ）から一般ＭＭＥ２１に送信される。
【０１６０】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２からＵＥ１にＴＡＵ  Ａｃｃｅｓｐｔ（２０）が送信される。
【０１６１】
ＴＡＵ  Ａｃｃｅｐｔ（２０）にＧＵＴＩが含まれる場合、ＵＥ１は、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に対して、ＴＡＵ  Ｃｏｍｐｌｅｔｅ（２１）を返すことで、受信した信号ＴＡＵ  Ａｃｃｅｓｐｔ（２０）の肯定応答とする。
【０１６２】
一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は実施例１と同様である。
【０１６３】
また、図８及び図９では、図示していないが、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に対して一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＵＥ１にＭＭＥ再選択を促すことが可能である。
【０１６４】
また、本実施例では、図９の手順にて、ＴＡ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅを用いたが、本実施例での特徴は、ｅＮｏｄｅＢ１１でＭＭＥの選択を行うことである。このため、例えば、Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ等、Ｓ１  Ｃｏｎｎｅｃｔｉｏｎを再確立するための、その他の手続き（Ｐｒｏｃｅｄｕｒｅ）を用いても実現可能である。
【０１６５】
以上説明したように、本実施例においては、一般ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けて次回ＭＭＥ選択時にＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを指定した上で、手続き（Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＭＭＥに接続させることができる。
【０１６６】
＜実施形態２＞
実施形態２として、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）においてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）を接続させる例を説明する。図２は、実施形態２のシステム構成を例示する図である。
【０１６７】
ＵＥ１０１は、例えば携帯電話端末（移動機）である。あるいは、例えば上記したＭＴＣデバイス、ＭＢＭＳ対応端末等であってもよい。
【０１６８】
ＮｏｄｅＢ１１１及びＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）１７１は、ＵＭＴＳシステムで採用された無線アクセス（Ｒａｄｉｏ  ａｃｃｅｓｓ）用の装置を表している。
【０１６９】
一般ＳＧＳＮ１２１、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、ＵＭＴＳ用に用いる在圏装置であり、接続形態により、ユーザープレーンを扱う場合と扱わない場合がある。ＳＧＳＮがユーザープレーンを扱わない場合のユーザープレーンは、Ｓ−ＧＷとＲＮＣ間に設定される。
【０１７０】
ＨＬＲ（Ｈｏｍｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）１３１は、加入者情報を保持するデータベースである。
【０１７１】
ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ：特許請求の範囲では「ゲートウェイＧＰＲＳサポートノード」と表記）１４１は、外部網と接続するゲートウェイ装置である。サービスネットワーク１６１は、外部網（データパケットネットワーク）を示す。
【０１７２】
図２において、ＮｏｄｅＢ１１１とＲＮＣ１７１は無線アクセスネットワークＲＡＮ、ＳＧＳＮ、ＧＧＳＮ等はコアネットワークに対応する。
【０１７３】
以下、実施形態２について、制御方式の相違したいくつかの実施例を説明する。以下の実施例６−１０は上記態様６−１０にそれぞれ対応する。
【０１７４】
＜実施例６＞
図１０は、実施例６の動作例を説明するためのシーケンス図であり、３ＧＰＰ  ＴＳ  ２３．０６０  ６．５  Ｆｉｇ  ２２に基づく。
【０１７５】
図１０において、
ＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）は、図２のＵＥ１０１、
ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）は、図２のＮｏｄｅＢ１１１とＲＮＣ１７１、
一般ＳＧＳＮは、図２の一般ＳＧＳＮ１２１、
Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ（特定ＳＧＳＮ）は、図２のＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ（特定ＳＧＳＮ）１２２、
ＧＧＳＮは、図２のＧＧＳＮ１４１、
ＨＬＲは、図２のＨＬＲ１３１に対応している。
【０１７６】
ＭＳＣ（Ｍｏｂｉｌｅ  Ｓｗｉｔｃｈｉｎｇ  Ｃｅｎｔｅｒ）／ＶＬＲ（Ｖｉｓｉｔｏｒ  Ｌｏｃａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）のＶＬＲはＨＬＲ以外のＣＳサービス用のローケーションレジスタである。ＥＩＲ（Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ  Ｒｅｇｉｓｔｅｒ）は有効な移動装置の識別子を保持する。  
【０１７７】
図２、図１０を参照して動作を説明する。なお、以下では、図１０のＭＳを、図２のＵＥ１０１に読み替えて説明する。
【０１７８】
ＵＥ１０１（ＭＳ）がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）をＲＮＣ１７１に転送する。ＲＮＣ１７１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）をＳＧＳＮに転送する。この時、ＲＮＣ１７１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
【０１７９】
一般ＳＧＳＮ１２１では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて端末情報を取得し、更にＨＬＲ１３１と連携して、認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。
【０１８０】
端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１８１】
ＵＥ１０１を、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、ＲＮＣ１７１に対して、ＳＧＳＮ再選択を指示するために、ＳＧＳＮ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ（本実施例で新規に導入した、ＲＡＮＡＰ信号）を送信する。この時、一般ＳＧＳＮ１２１はＳＧＳＮ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ信号にＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２を特定する識別子（例えばＲＡＩ（Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｉｄｅｎｔｉｆｉｅｒ）、ＮＲＩ（Ｎｅｔｗｒｏｋ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）など）を設定する。すなわち、一般ＳＧＳＮ１２１は、ＲＮＣに１７１対して、ＳＧＳＮ再選択要求し、その際、特定ＳＧＳＮ１２２の選択に必要な情報（ＲＡＩ）を載せる。なお、同一プール内での再選択の場合は、ＮＲＩでよい。ＳＧＳＮは、ＵＥ１０１が、ｒｅ−ｓｅｌｅｃｔｉｏｎ対象か判断する機能を有する。
【０１８２】
ＲＮＣ１７１は、ＳＧＳＮ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ信号を受信すると、本信号に設定された識別子に従ってＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２を選択し、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を転送する。特定ＳＧＳＮ１２２でＡｔｔａｃｈ  ＲｅｑｕｅｓｔのＮＡＳ（Ｎｏｎ  Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）パラメータが必要なので、ＲＮＣ１７１でＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを再送する。ＲＮＣ１７１ではＮＡＳメッセージを保持する機能が実装されている。
【０１８３】
新たなＳＧＳＮ（＝Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）では旧ＳＧＳＮ（＝一般ＳＧＳＮ）を特定できないため、コンテキスト（ｃｏｎｔｅｘｔ）を引き継ぐことができない。そのため、新たなＳＧＳＮでも認証／加入者プロファイル取得を行う必要がある。Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。つまり、一般ＳＧＳＮ１２１と同様の処理を行う。
【０１８４】
端末情報及び加入者プロファイルを取得したＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、ＵＥ１０１を、一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきか判断する。ここでは、ＲＮＣ１７１で再選択された後の為、ＳＧＳＮ  ｒｅ−ｓｅｌｅｃｔｉｏｎ  Ｃｏｍｍａｎｄ信号を送信せずに、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１８５】
また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断はＵＥ１０１からの情報（例えば、
・ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）、
・ＩＭＥＩ、
・ＵＥ  ｎｅｔｗｏｒｋ  ｃａｐａｂｉｌｉｔｙ、
・ＭＳ  ｎｅｔｗｏｒｋ  ｃａｐａｂｉｌｉｔｙ、
・Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  ｃｌａｓｓｍａｒｋ  ２、
・Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  ｃｌａｓｓｍａｒｋ  ３、
・Ｄｅｖｉｃｅ  ｐｒｏｐｅｒｔｉｅｓ、
・ＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）、又は、
・ＭＴＣグループを識別するＩＤ、又は、
・ｌｏｗ  ａｃｃｅｓｓ  ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｉｏｎ、又は、
・ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ａｃｃｅｓｓ、又は、
・今後追加されるＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ、又は、ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔなどのその他のＮＡＳ信号の新規パラメータ、又は、これらのパラメータを構成する一部分の識別子※ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等）、
ＨＬＲ１３１からの情報（例えば
・Ｆｅａｔｕｒｅ−Ｌｉｓｔ、
・ＡＰＮ、
・ＭＴＣグループを識別するＩＤ、又は、
・又は今後追加されるＵｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  Ａｎｓｗｅｒ／Ｉｎｓｅｒｔ  Ｓｕｂｓｃｒｉｂｅｒ  Ｄａｔａ  Ｒｅｑｕｅｓｔ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子）
のいずれか、若しくは複数を組み合わせて行う。
【０１８６】
また、図１０では明示していないが、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＲＮＣ１７１にＭＭＥ再選択を促すことが可能である。
【０１８７】
以上説明したように、本実施例においては、ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けてＳＧＳＮを再選択した上で、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮにＡｔｔａｃｈさせることができる。
【０１８８】
＜実施例７＞
実施例７として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例７の構成は実施例６と同様である。図１１は、実施例７の動作例を説明するためのシーケンス図である。図２、図１１を参照して動作を説明する。
【０１８９】
ＵＥ１０１が、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
【０１９０】
一般ＳＧＳＮ１２１では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。
【０１９１】
端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１９２】
ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に対してＳＧＳＮ変更を指示するために、ＳＧＳＮ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。
【０１９３】
この時、一般ＳＧＳＮ１２１は、ＳＧＳＮ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ信号に、移動機認証や加入者プロファイルの取得によって生成したｃｏｎｔｅｘｔ情報を設定する。すなわち、一般ＳＧＳＮ１２１からＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に、ＳＧＳＮ  ｃｈａｎｇｅを要求する際に、ｃｏｎｔｅｘｔを新たなＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２）に通知する。ＳＧＳＮはＵＥ１０１がｒｅ−ｓｅｌｅｃｔｉｏｎ対象か判断する機能が実装されている。
【０１９４】
Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、ＳＧＳＮ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ信号を受信すると、ＳＧＳＮ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ信号に設定されたコンテキスト（ｃｏｎｔｅｘｔ）情報を保持し、一般ＳＧＳＮ１２１に対して、ＳＧＳＮ  Ｃｈａｎｇｅ  Ｒｅｓｐｏｎｓｅ信号（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。
【０１９５】
その後、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、ＨＬＲ１３１に対して、Ｕｐｄａｔｅ  Ｌｏｃａｔｉｏｎ信号（８）を送信し、ＳＧＳＮが変更されたことをＨＬＲ１３１に通知する。
【０１９６】
また、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、一般ＳＧＳＮ１２１から受け取ったセキュリティ・コンテキスト（ｓｅｃｕｒｉｔｙ  ｃｏｎｔｅｘｔ）情報が有効であれば、再認証を省略することが出来る。
【０１９７】
その後、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続し、ＲＮＣ１７１は、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２からＡｔｔａｃｈ  Ａｃｃｅｐｔ信号（９）を受信する。その後は、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０１９８】
また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。
【０１９９】
また、図１１では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で一般ＳＧＳＮ１２１にＳＧＳＮ変更を促すことが可能である。
【０２００】
以上説明したように、本実施例においては、一般ＳＧＳＮが特定ＳＧＳＮに対してＳＧＳＮ変更を指示し、特定ＳＧＳＮはそれを受けてＳＧＳＮを変更した上で、アタッチ処理（Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＳＧＳＮに、Ａｔｔａｃｈさせることができる。
【０２０１】
＜実施例８＞
実施例８として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例８の構成は実施例６と同様である。図１２、図１３は、実施例８の動作例を説明するためのシーケンス図である。図２、図１２、図１３を参照して動作を説明する。
【０２０２】
ＵＥ１０１（ＭＳ）が、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
【０２０３】
一般ＳＧＳＮ１２１では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。
【０２０４】
端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０２０５】
ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続せずに、ＵＥ１０１に対してＡｔｔａｃｈ  Ｒｅｊｅｃｔ信号（９）を送信する。
【０２０６】
この時、一般ＳＧＳＮ１２１はＡｔｔａｃｈ  Ｒｅｊｅｃｔ信号に、再アタッチ（ｒｅ−ａｔｔａｃｈ）を指示するパラメータと、ｒｅ−ａｔｔａｃｈ時に、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２を、ＲＮＣ１７１が選択できるようＲＡＩ（Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｉｄｅｎｔｉｔｙ）パラメータ（本実施形態で新規に導入した、パラメータ）を設定する。これらは本実施例で導入した新規なパラメータであるが、ＲＮＣ１７１では、透過であるため影響はない。
【０２０７】
ＵＥ１０１は、Ａｔｔａｃｈ  ＲｅｊｅｃｔでＲＡＩを受け付け、Ｒｅ−ａｔｔａｃｈ時に、ｒｅｊｅｃｔで指示されたＲＡＩを使用する機能が必要である。ＳＧＳＮはＵＥ１０１がｒｅ−ｓｅｌｅｃｔｉｏｎ対象か判断する機能を有する。
【０２０８】
ＵＥ１０１は、Ａｔｔａｃｈ  Ｒｅｊｅｃｔ信号（９）を受信すると、該Ａｔｔａｃｈ  Ｒｅｊｅｃｔ信号（９）に設定されたｒｅ−ａｔｔａｃｈを指示するパラメータ及びＲＡＩパラメータに従って、図１３に示すように、ＲＡＩを設定したＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号（１）を、ＲＮＣ１７１に送信する（Ｐ−ＴＭＳＩ（Ｐａｃｋｅｔ  Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｎｄｅｎｔｉｆｉｅｒ）によるＲｅ−Ａｔｔａｃｈ）。この時、ＲＮＣ１７１は、ＲＡＩから適切なＳＧＳＮを判断し、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送する。
【０２０９】
その後、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０２１０】
ただし、ＲＡＩが設定されたＡｔｔａｃｈ  Ｒｅｑｕｅｓｔであるが、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２自身は、ｃｏｎｔｅｘｔ情報を保持していない。このため、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号（１）を受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて、端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。
【０２１１】
また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。
【０２１２】
また、図１２及び図１３では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に対して一般ＭＭＥ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で、ＵＥ１０１に、ＭＭＥの再選択を促すことが可能である。
【０２１３】
以上説明したように、本実施例においては、一般ＳＧＳＮがＵＥに対してＳＧＳＮ再選択を指示し、ＵＥはそれを受けて特定ＳＧＳＮを指定した上で、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮにＡｔｔａｃｈさせることができる。
【０２１４】
＜実施例９＞
実施例９として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例９の構成は実施例６と同様である。図１４は、実施例９の動作例を説明するシーケンス図である。図２及び図１４を参照して動作を説明する。
【０２１５】
ＵＥ１０１がＡｔｔａｃｈ  ＲｅｑｕｅｓｔをＳＧＳＮに送信する為に、まずＲＮＣ１７１とのＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立の為、ＵＥ１０１は、まずＲＮＣ１７１にＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を送信する。
【０２１６】
この時、ＵＥ１０１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号に、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。
【０２１７】
ＲＮＣ１７１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１０１がＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきことを記憶し、その後のＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０２１８】
ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１０１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。
【０２１９】
ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号の受信時に記憶した情報から、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号を、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送する。Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔには、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））がＲＮＣ１７１によって設定されＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に通知される。
【０２２０】
Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２では、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した後、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔで受信した、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＲＮＣ１７１がＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信し、Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔに設定したパラメータであって、Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を保持する。
【０２２１】
また、ＵＥ１０１は、一般ＳＧＳＮ１２１、及びＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２のどちらのＳＧＳＮに接続するべきかをＲＮＣ１７１に指示する機能を具備するが、この時、ＵＥ１０１は、コアネットワーク上の全てＳＧＳＮの情報を保持することは出来ないので、ＲＮＣ１７１への指示は、ＳＧＳＮを一意に選択できる識別子ではなく、ＳＧＳＮ種別若しくはサービス種別等の情報である。
【０２２２】
また、ＲＮＣ１７１は、ＵＥ１０１を、どのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
【０２２３】
以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、Ａｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮにＡｔｔａｃｈさせることができる。
【０２２４】
＜実施例１０＞
実施例１０として、ＵＭＴＳにおいてＲＡ  Ｕｐｄａｔｅ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例１０の構成は、実施例６と同様である。図１５、図１６は、実施例１０の動作例を説明するためのシーケンス図である。以下、図２、図１５、図１６、及び図１０の一部を参照して、動作を説明する。
【０２２５】
ＵＥ１０１がＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを送信すると（図１０の１参照）、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
【０２２６】
一般ＳＧＳＮ１２１ではＡｔｔａｃｈ  Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し（図１０の３参照）、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。
【０２２７】
端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０２２８】
ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１はＵＥ１０１に対して、ＲＡ（Ｒｏｕｔｉｎｇ  Ａｒｅａ）  Ｕｐｄａｔｅを行わせるために、図１５に示すように、Ｉｕ  Ｒｅｌｅａｓｅを行う。
【０２２９】
この時、一般ＳＧＳＮ１２１は、ＲＮＣ１７１にＩＵ  Ｒｅｌｅａｓｅ  Ｃｏｍｍａｎｄ信号を送信する（図１５の４参照）。一般ＳＧＳＮ１２１は、ＩＵ  Ｒｅｌｅａｓｅ  Ｃｏｍｍａｎｄ信号にて、次にＲＮＣがＳＧＳＮとＩｕ  Ｃｏｎｎｅｃｔｉｏｎを確立するときに選択するべき、ＳＧＳＮをＳＧＳＮ識別子（例えばＲＡＩ、ＮＲＩ等）で指示する。なお、同一プール内の場合、ＮＲＩでもよい。
【０２３０】
ＲＮＣ１７１は、Ｉｕ  Ｒｅｌｅａｓｅ完了後も、ＵＥ１０１に対するセッション情報を保持している間、次回ＳＧＳＮ選択の為の情報として、ＳＧＳＮ識別子を保持し続ける。
【０２３１】
Ｉｕ  Ｒｅｌｅａｓｅが行われると（ＲＮＣ１７１から一般ＳＧＳＮ１２１へのＩＵ  Ｒｅｌｅａｓｅ  Ｃｏｍｐｌｅｔｅ（６）の送信後）、次に、図１６に示すように、ＵＥ１０１はＲＡＵ（ＲＡ  Ｕｐｄａｔｅ）  Ｒｅｑｕｅｓｔ（２）を送信する。
【０２３２】
ＲＡＵ  Ｒｅｑｕｅｓｔ（２）を、まず、ＮｏｄｅＢ１１１が受信し、ＮｏｄｅＢ１１１は、ＲＡＵ  Ｒｅｑｕｅｓｔ（３）をＲＮＣ１７１に転送する。
【０２３３】
ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＩｕ  Ｒｅｌｅａｓｅ済みの状態なので、ＳＧＳＮ選択を行い、Ｉｕ  Ｃｏｎｎｅｃｔｉｏｎを確立する。
【０２３４】
ＳＧＳＮ選択において、ＲＮＣ１７１は、一般ＳＧＳＮ１２１から受信したＩＵ  Ｒｅｌｅａｓｅ  Ｃｏｍｍａｎｄ信号で指示されたＳＧＳＮ識別子に従い、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２を選択する。ＲＮＣはＩｕ  Ｒｅｌｅａｓｅ時にｏｌｄ  ＳＧＳＮ（＝一般ＳＧＳＮ）から指示されたＲＡＩ（若しくはＮＲＩ）に従ってＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮを選択。なお、ＲＮＣはＵＥ毎に次のＲＡＩを保持する機能を有する。
【０２３５】
Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、ＲＡＵ  Ｒｅｑｕｅｓｔを受信した後、通常のＲＡ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅを継続する。ＮＡＳ上のＰ−ＴＭＳＩ（ＲＡＩ）は旧ＳＧＳＮである一般ＳＧＳＮを示しているので、Ｃｏｎｔｅｘｔを取得する。
【０２３６】
また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。
【０２３７】
また、図１５及び図１６では図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ  Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＵＥ１０１にＭＭＥ再選択を促すことが可能である。
【０２３８】
また、本実施例では、図１６の手順にて、ＲＡ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅを用いたが、ＲＮＣ１７１でＳＧＳＮ選択を行うためのものであることから、例えばＰＤＰ  Ｃｏｎｔｅｘｔ  Ａｃｔｉｖａｔｉｏｎ等Ｉｕ  Ｃｏｎｎｅｃｔｉｏｎを再確立する、その他のＰｒｏｃｅｄｕｒｅを用いても実現可能である。
【０２３９】
以上説明したように、本実施例においては、一般ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けて次回ＳＧＳＮ選択時に特定ＳＧＳＮを指定した上で、Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮに接続させることができる。
【０２４０】
＜実施例１１＞
実施例１１として、ＥＰＣにおいて、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）を跨いだハンドオーバの例を説明する。図１７は、実施例１１の構成（システム構成）を例示する図である。図１７を参照すると、ＵＥ２０１を備え、ＵＥ２０１と無線接続するＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）として、ハンドオーバ元のソースｅＮｏｄｅＢ（Ｓｏｕｒｃｅ  ｅＮｏｄｅＢ）２０２とハンドオーバ先のターゲットｅＮｏｄｅＢ（Ｔａｒｇｅｔ  ｅＮｏｄｅＢ）２０３を備えている。ＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）は、ソースＭＭＥ（Ｓｏｕｒｃｅ  ＭＭＥ）２０４、ターゲットＭＭＥ（Ｔａｒｇｅｔ  ＭＭＥ）２０５、ソースＳＧＷ（Ｓｏｕｒｃｅ  ＳＧＷ）２０６、ターゲットＳＧＷ（Ｔａｒｇｅｔ  ＳＧＷ）２０７、ＤＮＳサーバ２０９、ＨＳＳ２１１、ＰＧＷ２０８を備え、ＰＧＷ２０８からサービスネットワーク２１０に接続される。この例では、ハンドオーバのソースＭＭＥ２０４とターゲットＭＭＥ２０５は、ともに特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）である。図１８は、実施例１１の動作例（シーケンス動作）を説明するためのシーケンス図である。なお、図１８は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．５．１．２．２−１：  Ｓ１−ｂａｓｅｄ  ｈａｎｄｏｖｅｒに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．５．１．２．２の記載が参照される。以下、図１７及び図１８を参照して動作を説明する。
【０２４１】
ハンドオーバ元のソースｅＮｏｄｅＢ（Ｓｏｕｒｃｅ  ｅＮｏｄｅＢ）２０２が、ＵＥ２０１との接続において信号劣化を検出すると、Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄ（２）を、ソースＭＭＥ（Ｓｏｕｒｃｅ  ＭＭＥ）２０４に送信する。Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄ（２）には、Ｔａｒｇｅｔ  ＴＡＩ（Ｔｒａｃｋｉｎｇ  Ａｒｅａ  Ｉｄｅｎｔｉｔｙ）などの情報が含まれている。Ｓｏｕｒｃｅ  ＭＭＥ２０４は、前記情報から、ターゲットＭＭＥ（Ｔａｒｇｅｔ  ＭＭＥ）２０５への、ＭＭＥ間ハンドオーバ（Ｉｎｔｅｒ  ＭＭＥ  ｈａｎｄｏｖｅｒ）の実行を判断する。
【０２４２】
この実施例では、Ｓｏｕｒｃｅ  ＭＭＥ２０４がＴａｒｇｅｔ  ＭＭＥ２０５を決定する際に、Ｓｏｕｒｃｅ  ＭＭＥ２０４が保持している特定ＭＭＥ接続要求情報を用いてＴａｒｇｅｔ  ＭＭＥ２０５を決定する。なお、Ｓｏｕｒｃｅ  ＭＭＥ２０４が保持する特定ＭＭＥ接続要求情報は、ＵＥ２０１から特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続するための特定ＭＭＥ接続要求情報を付与したＲＲＣ信号を受信したｅＮｏｄｅＢ２０２が該特定ＭＭＥ接続要求情報を例えばＳ１−ＡＰ信号にて特定ＭＭＥであるＳｏｕｒｃｅ  ＭＭＥ２０４に通知し、Ｓｏｕｒｃｅ  ＭＭＥ２０４で保持しているものである。
【０２４３】
Ｔａｒｇｅｔ  ＭＭＥ２０５（ハンドオーバ先のＭＭＥ）の決定において、Ｓｏｕｒｃｅ  ＭＭＥ２０４で保持している特定ＭＭＥ接続要求情報を元に、Ｓｏｕｒｃｅ  ＭＭＥ２０４で保持するローカルコンフィグレーションを用いて決定しても良い。なお、ローカルコンフィグレーションは、例えばオペレータによって設定され、装置（ＭＭＥ）で内部的に管理保持する情報（コンフィグレーション情報）である（例えばＭＴＣ加入者（ＭＴＣ端末）がハンドオーバする際に、ＭＴＣグループとハンドオーバ先の移動エリアに応じた情報等を含む）。例えば特定ＭＭＥ接続要求情報がＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）とした場合、ＡＰＮを元に、例えばＬＡＰＩ（Ｌｏｗ  Ａｃｃｅｓｓ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｉｏｎ）の数値に対応するローカルな情報（ローカルコンフィグレーション）で、ハンドオーバ先のＭＭＥの選択を行う。あるいは、Ｓｏｕｒｃｅ  ＭＭＥ２０４で保持するローカルコンフィグレーションを用いてＴａｒｇｅｔ  ＭＭＥ２０５を決定するようにしても良い。
【０２４４】
また、Ｓｏｕｒｃｅ  ＭＭＥ２０４は、Ｔａｒｇｅｔ  ＴＡＩ（Ｔｒａｃｋｉｎｇ  Ａｒｅａ  Ｉｄｅｎｔｉｔｙ）等の位置情報と共に、特定ＭＭＥ接続要求情報を設定し、ＤＮＳサーバ（ＤＮＳ  ｓｅｒｖｅｒ）２０９に、「ＤＮＳ  Ｑｕｅｒｙ」を行う事で、Ｔａｒｇｅｔ  ＭＭＥ２０５を決定しても良い。
【０２４５】
Ｓｏｕｒｃｅ  ＭＭＥ２０４がＴａｒｇｅｔ  ＭＭＥ２０５へのＩｎｔｅｒ  ＭＭＥ  ｈａｎｄｏｖｅｒの実行を決定すると、Ｓｏｕｒｃｅ  ＭＭＥ２０４はＴａｒｇｅｔ  ＭＭＥ２０５に対して、フォアワードリロケーション要求（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）（３）を送信する。その際、Ｓｏｕｒｃｅ  ＭＭＥ２０４は、フォアワードリロケーション要求（３）に、Ｓｏｕｒｃｅ  ＭＭＥ２０４が保持している特定ＭＭＥ接続要求情報を設定しても良い。
【０２４６】
Ｔａｒｇｅｔ  ＭＭＥ２０５は、更なるＩｎｔｅｒ  ＭＭＥ  ｈａｎｄｏｖｅｒを実行する際、Ｔａｒｇｅｔ  ＭＭＥ２０５で保持する特定ＭＭＥ接続要求情報を利用して特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）の選択が可能になる。
【０２４７】
これ以降のシーケンスについては、関連技術にしたがってＩｎｔｅｒ  ＭＭＥ  ｈａｎｄｏｖｅｒ処理が実施される。
【０２４８】
＜実施例１２＞
実施例１２として、ＵＭＴＳにおいて特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ)を跨いだＳＲＮＳ（Ｓｅｒｖｉｎｇ  Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｓｕｂｓｙｓｔｅｍ）  ｒｅｌｏｃａｔｉｏｎ（ハンドオーバー）の例を説明する。図１９、図２０は、実施例１２を説明するための図である。図２１は、実施例１２の動作例を説明するためのシーケンス図である。
【０２４９】
図１９を参照すると、ＵＥ３０１を備え、ＵＥ３０１と無線接続するＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）として、ハンドオーバ元のソースＲＮＣ（Ｓｏｕｒｃｅ  ＲＮＣ）３０２、ハンドオーバ先のターゲットＲＮＣ（Ｔａｒｇｅｔｅ  ＲＮＣ）３０３を備えている。ＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）は、ソースＳＧＳＮ（Ｓｏｕｒｃｅ  ＳＧＳＮ）３０４、ターゲットＳＧＳＮ（Ｔａｒｇｅｔ  ＳＧＳＮ）３０５、ソースＳＧＷ（Ｓｏｕｒｃｅ  ＳＧＷ）３０６、ターゲットＳＧＷ（Ｔａｒｇｅｔ  ＳＧＷ）３０７、ＤＮＳサーバ３０９、ＨＳＳ３１１、ＰＧＷ３０８を備え、ＰＧＷ３０８を介してサービスネットワーク３１０に接続される。この例では、ハンドオーバのソースＳＧＳＮ３０４とターゲットＳＧＳＮ３０５は、ともに特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）である。なお、図２１は、３ＧＰＰ  ＴＳ２３．０６０のＦｉｇｕｒｅ  ３９：ＳＲＮＳ  Ｒｅｌｏｃａｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は同図に従う。各シーケンスの詳細は、３ＧＰＰ  ＴＳ２３．０６０  ６．９．２．２．１の記載が参照される（ただし、３ＧＰＰ  ＴＳ２３．０６０のＦｉｇｕｒｅ  ３９では、端末はＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）とされているが、図２１ではＵＥである）。
【０２５０】
以下、図２０及び図２１を参照して動作を説明する。図１９は、ＣＮがＥＰＣで構成される場合であるが、この実施例１２の動作に関して特に差異が無い事より、本実施例の動作は、図１９、及び図２０で示される構成で有効である。図２０では、ＣＮにおいて、図１９のＣＮにおいて、ソースＳＧＷ（Ｓｏｕｒｃｅ  ＳＧＷ）３０６、ターゲットＳＧＷ（Ｔａｒｇｅｔ  ＳＧＷ）３０７がない点、図１９のＰＧＷ３０８の代わりに、ＧＧＳＮ４０８が配設されている点が相違している。
【０２５１】
Ｓｏｕｒｃｅ  ＲＮＣ４０２が、ＵＥ４０１との接続において例えば信号劣化を検出すると、Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄ（２）をＳｏｕｒｃｅ  ＳＧＳＮ４０４に送信する。Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄ（２）には、Ｔａｒｇｅｔ  ＩＤなどの情報が含まれている。Ｓｏｕｒｃｅ  ＳＧＳＮ４０４は、その情報からＴａｒｇｅｔ  ＳＧＳＮ４０５へのｉｎｔｅｒ  ＳＧＳＮ  ＳＲＮＳ（Ｓｅｒｖｉｎｇ  Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｓｕｂｓｙｓｔｅｍ）  ｒｅｌｏｃａｔｉｏｎの実行を判断する。
【０２５２】
この実施例では、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４がＴａｒｇｅｔ  ＳＧＳＮ４０５を決定する際に、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報を用いてＴａｒｇｅｔ  ＳＧＳＮ４０５を決定する。Ｓｏｕｒｃｅ  ＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報は、ＵＥ４０１から、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）に接続するための特定ＳＧＳＮ接続要求情報を付与したＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）信号を受信したＲＮＣ４０３が、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮであるＳｏｕｒｃｅ  ＳＧＳＮ４０４に通知し、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４で保持しているものである。Ｔａｒｇｅｔ  ＳＧＳＮ４０５の決定は、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４で保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定するようにしてもよい。あるいは、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４が保持するローカルコンフィグレーションを用いて決定しても良い。あるいは、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４は、Ｔａｒｇｅｔ  ＩＤなどの位置情報と共に特定ＳＧＳＮ接続要求情報を設定し、ＤＮＳ  ｓｅｒｖｅｒ４０９にＤＮＳ  Ｑｕｅｒｙする事で、Ｔａｒｇｅｔ  ＳＧＳＮ４０５を決定しても良い。
【０２５３】
Ｓｏｕｒｃｅ  ＳＧＳＮ４０４がＴａｒｇｅｔ  ＳＧＳＮ４０５へのｉｎｔｅｒ  ＳＧＳＮ  ＳＲＮＳ  ｒｅｌｏｃａｔｉｏｎの実行を決定すると、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４はＴａｒｇｅｔ  ＳＧＳＮ４０５に対して、Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ（３）を送信する。Ｓｏｕｒｃｅ  ＳＧＳＮ４０４は、この信号（Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）に、Ｓｏｕｒｃｅ  ＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報を設定しても良い。
【０２５４】
Ｔａｒｇｅｔ  ＳＧＳＮ４０５は、更なるｉｎｔｅｒ  ＳＧＳＮ  ＳＲＮＳ  ｒｅｌｏｃａｔｉｏｎを実行する際、特定ＳＧＳＮ接続要求情報を利用して特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）の選択が可能になる。
【０２５５】
これ以降のシーケンスについては、関連技術にしたがって、ｉｎｔｅｒ  ＳＧＳＮ  ＳＲＮＳ  ｒｅｌｏｃａｔｉｏｎ処理が実施される。
【０２５６】
＜実施例１３＞
実施例１３として、ＥＰＣにおいて特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）から特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）にハンドオーバする例を説明する。図２２は、実施例１３の構成を例示する図である。図２２を参照すると、ＵＥ５０１と、ＵＥ５０１に無線接続するＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）としてソースｅＮｏｄｅＢ（Ｓｏｕｒｃｅ  ｅＮｏｄｅＢ）５０２、ターゲットＲＮＣ（Ｔａｒｇｅｔｅ  ＲＮＣ）５０３を備えている。ＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）は、ソースＭＭＥ（Ｓｏｕｒｃｅ  ＭＭＥ）５０４、ターゲットＳＧＳＮ（Ｔａｒｇｅｔ  ＳＧＳＮ）５０５、ＳＧＷ５０６、ＤＮＳサーバ５０８、ＨＳＳ５１０、ＰＧＷ５０７を備え、ＰＧＷ５０７を介してサービスネットワーク５０９に接続される。図２３は、実施例１３の動作例を説明するためのシーケンス図である。なお、図２３は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．５．２．１．２−２：  Ｅ−ＵＴＲＡＮ  ｔｏ  ＵＴＲＡＮ  Ｉｕ  ｍｏｄｅ  Ｉｎｔｅｒ  ＲＡＴ  ＨＯ，ｐｒｅｐａｒａｔｉｏｎ  ｐｈａｓｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．５．２．１．２の記載が参照される。
【０２５７】
以下、図２２及び図２３を参照して動作を説明する。Ｓｏｕｒｃｅ  ｅＮｏｄｅＢ５０２が、ＵＥ５０１との接続において信号劣化を検出すると、Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄ（２）をＳｏｕｒｃｅ  ＭＭＥ５０４に送信する。Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄ（２）には、Ｔａｒｇｅｔ  ＴＡＩ（Ｔｒａｃｋｉｎｇ  ａｒｅａ  ＩＤ）などの情報が含まれており、Ｓｏｕｒｃｅ  ＭＭＥ５０４は、その情報からＴａｒｇｅｔ  ＳＧＳＮ５０５へのＩｎｔｅｒ  ＲＡＴ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｔｅｃｈｎｏｌｏｇｙ）  ｈａｎｄｏｖｅｒの実行を判断する。
【０２５８】
この実施例では、Ｓｏｕｒｃｅ  ＭＭＥ５０４がＴａｒｇｅｔ  ＳＧＳＮ  ５０５を決定する際に、Ｓｏｕｒｃｅ  ＭＭＥ５０４が保持している特定ＭＭＥ接続要求情報を用いてＴａｒｇｅｔ  ＳＧＳＮ５０５を決定する。Ｔａｒｇｅｔ  ＳＧＳＮ５０５の決定は、特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定しても良い。あるいは、Ｓｏｕｒｃｅ  ＭＭＥ５０４が保持するローカルコンフィグレーションを用いて決定しても良い。また、Ｓｏｕｒｃｅ  ＭＭＥ５０４は、Ｔａｒｇｅｔ  ＩＤなどの位置情報と共に特定ＭＭＥ接続要求情報を設定し、ＤＮＳ  ｓｅｒｖｅｒ５０８にＤＮＳ  Ｑｕｅｒｙする事で、Ｔａｒｇｅｔ  ＳＧＳＮ５０５を決定しても良い。
【０２５９】
Ｓｏｕｒｃｅ  ＭＭＥ５０４がＴａｒｇｅｔ  ＳＧＳＮ５０５へのＩｎｔｅｒ  ＲＡＴ  ｈａｎｄｏｖｅｒの実行を決定すると、Ｓｏｕｒｃｅ  ＭＭＥ５０４は、Ｔａｒｇｅｔ  ＳＧＳＮ５０５に対して、Ｆｏｒｗａｒｄ  Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ（３）を送信する。Ｓｏｕｒｃｅ  ＭＭＥ５０４は、この信号に、Ｓｏｕｒｃｅ  ＭＭＥ５０４が保持している特定ＭＭＥ接続要求情報を設定しても良い。Ｔａｒｇｅｔ  ＳＧＳＮ５０５は、更なるＩｎｔｅｒ  ＲＡＴ  ｈａｎｄｏｖｅｒを実行する際、特定ＭＭＥ接続要求情報を利用して、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）の選択が可能になる。
【０２６０】
これ以降のシーケンスについては、関連技術にしたがったＩｎｔｅｒ  ＲＡＴ  ｈａｎｄｏｖｅｒ処理が実施される。
【０２６１】
＜実施例１４＞
実施例１４として、ＥＰＣにおいて特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ）から特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ)にハンドオーバする例を説明する。実施例１４の構成は、図２２に示されるが、ハンドオーバの方向が逆になる。また、実施例１４の動作例を説明するためのシーケンスも、基本的に、図２３において、
ＳＧＳＮとＭＭＥ、及び、
ＲＮＣとｅＮｏｄｅＢ
の記述（動作シーケンス）が逆転する（逆方向のシーケンス動作となる）だけである。
【０２６２】
＜実施例１５＞
実施例１５として、ＥＰＣにおいてＴｒａｃｋｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ（ＴＡＵ）時に、ＵＥと特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）を接続させる例を説明する。実施例１５の構成は実施例１と同様である。図２４は、実施例１５の動作例を説明するためのシーケンス図である。なお、図２４は、３ＧＰＰ  ＴＳ２３．４０１のＦｉｇｕｒｅ  ５．３．３．１−１：  Ｔｒａｃｋｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  ｐｒｏｃｅｄｕｒｅ  ｗｉｔｈ  Ｓｅｒｖｉｎｇ  ＧＷ  ｃｈａｎｇｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１  ５．３．３の記載が参照される。以下、図１及び図２４を参照して動作を説明する。
【０２６３】
ＵＥ１がＴＡＵ  Ｒｅｑｕｅｓｔ（３）をＭＭＥに送信する為に、まず、ｅＮｏｄｅＢ１１とのＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）  Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を送信する。
【０２６４】
この時、ＵＥ１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号にＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。
【０２６５】
ＵＥ１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｑｕｅｓｔにてｅＮｏｄｅＢに、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥに接続可能であることを通知する  ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。
【０２６６】
ｅＮｏｄｅＢ１１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１がＣｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に接続するべきことを記憶し、その後のＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０２６７】
ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１がＴＡＵ  Ｒｅｑｕｅｓｔ（２）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの受信時に記憶した情報から、ＴＡＵ  Ｒｅｑｕｅｓｔ（３）を、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に転送する。ＴＡＵ  Ｒｅｑｕｅｓｔ（３）には、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信した特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続可能であることを通知するＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）が、ｅＮｏｄｅＢ１１によって設定され、Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２に通知される。
【０２６８】
Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２では、ＴＡＵ  Ｒｅｑｕｅｓｔ（３）を受信した後、通常のＴＡＵ  Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ２２は、受信したＴＡＵ  Ｒｅｑｕｅｓｔ（３）に設定された、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信した特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）に接続可能であることを通知する  ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）を保持する。
【０２６９】
また、ＵＥ１は、一般ＭＭＥ２１、及び特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ）２２のどちらのＭＭＥに接続するべきかを、ｅＮｏｄｅＢ１１に指示する機能を具備する。この時、ＵＥ１はコアネットワーク上の全てＭＭＥの情報を保持することは出来ないので、ｅＮｏｄｅＢ１１への指示は、ＭＭＥを一意に選択できる識別子ではなく、ＭＭＥ種別、若しくはサービス種別等の情報が用いられる。
【０２７０】
また、ｅＮｏｄｅＢ１１は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備している。
【０２７１】
ｅＮｏｄｅＢ１１において、ＭＭＥの選択は、前述のとおり、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ内のユーザＩＤ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ）、通信確立要因（Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅ）の新規Ｖａｌｕｅ、又は新規パラメータ、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
【０２７２】
以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてＣｕｓｔｏｍｉｚｅｄ  ＭＭＥを指定した上で、ＴＡＵ  Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥに位置登録させることができる。
【０２７３】
＜実施例１６＞
実施例１６として、ＵＭＴＳにおいてＲｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例１６の構成は実施例６と同様である。図２５は、実施例１６の動作例を説明するシーケンス図である。なお、図２５は、３ＧＰＰ  ＴＳ２３．０６０のＦｉｇｕｒｅ  ３６：  Ｉｕ  ｍｏｄｅ  ＲＡ  Ｕｐｄａｔｅ  ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．０６０  ６．９．２の記載が参照される（３ＧＰＰ  ＴＳ２３．０６０のＦｉｇｕｒｅ  ３６では、端末はＭＳとされているが、図２５では、ＵＥである）。以下、図２及び図２５を参照して動作を説明する。
【０２７４】
ＵＥ１０１がＲｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  ＲｅｑｕｅｓｔをＳＧＳＮに送信する為に、まずＲＮＣ１７１とのＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立の為、ＵＥ１０１は、まずＲＮＣ１７１にＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を送信する。
【０２７５】
この時、ＵＥ１０１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号に、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。
【０２７６】
ＲＮＣ１７１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１０１がＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に接続するべきことを記憶し、その後のＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅを継続する。
【０２７７】
ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１０１がＲｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。
【０２７８】
ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ信号の受信時に記憶した情報から、Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ信号を、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に転送する。Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔには、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔにて受信した、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は、新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））がＲＮＣ１７１によって設定されＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２に通知される。
【０２７９】
Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２では、Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔを受信した後、通常のＲｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２は、受信したＲｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔに設定された、Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を保持する。
【０２８０】
また、ＵＥ１０１は、一般ＳＧＳＮ１２１、及びＣｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ１２２のどちらのＳＧＳＮに接続するべきかをＲＮＣ１７１に指示する機能を具備するが、この時、ＵＥ１０１は、コアネットワーク上の全てＳＧＳＮの情報を保持することは出来ないので、ＲＮＣ１７１への指示は、ＳＧＳＮを一意に選択できる識別子ではなく、ＳＧＳＮ種別若しくはサービス種別等の情報である。
【０２８１】
また、ＲＮＣ１７１は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
【０２８２】
以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅを継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮに位置登録させることができる。
【０２８３】
以下、上記した実施形態、実施例において、コアネットワーク（ＣＮ）ノードを選択するいくつかの事例について説明する。
【０２８４】
ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイス（Ｍ２Ｍデバイス）を特定ＣＮノード（ＭＴＣデバイス向けに効率化したノード）に接続させる。
【０２８５】
ＭＢＭＳ利用ユーザを特定ＣＮノード（ＭＢＭＳ対応ＣＮノード）に接続させる。
【０２８６】
その他、新規サービスを小規模スタートさせるために、特定ＣＮノードのみでサービス提供する。
【０２８７】
特定のＵＥを、ＭＭＥとＳＧＷをコロケート（ｃｏｌｌｏｃａｔｅ）したノードに接続させる。特に制限されないが、例えば少量のデータトラヒックを、ＳＭＳ（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）に載せ換えてＵＥに送信する場合、ＭＭＥとＳＧＷをコロケート（ｃｏｌｌｏｃａｔｅ）していると、ＳＭＳ変換処理の実装が容易化する。
【０２８８】
また、端末種別（ＣＳＦＢ（ＣＳ  Ｆａｌｌｂａｃｋ）端末とＶｏＬＴＥ端末等）でＭＭＥを振り分ける。ＣＳＦＢ（ＣＳ  Ｆａｌｌｂａｃｋ）は、ＬＴＥ接続中に、ＣＳ（Ｃｉｒｃｕｉｔ  Ｓｗｉｔｃｈｅｄ）サービス発着信があると、３Ｇ（又は２Ｇ）に無線を切り替える機能である。ＶｏＬＴＥ（Ｖｏｉｃｅ  ｏｖｅｒ  ＬＴＥ）は、ＬＴＥ上で音声（等ＣＳで提供していた）サービスを提供する機能である。なお、ＣＳＦＢ端末は、ＭＳＣとのインターワークが必要である。ＶｏＬＴＥ端末はＩＭＳとのインターワークが必要である。ＣＳＦＢで、先にアタッチしているＭＳＣに、コロケート（ｃｏｌｌｏｃａｔｅ）したＭＭＥを選択させる。
【０２８９】
なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【符号の説明】
【０２９０】
１  ＵＥ
１１  ｅＮｏｄｅＢ
２１  一般ＭＭＥ
２２  Ｃｕｓｔｏｍｉｚｅｄ  ＭＭＥ
３１  ＨＳＳ
４１  Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  ＧＷ）
５０  ＨＳＳ
５１  Ｐ−ＧＷ（ＰＤＮ  ＧＷ）
６１  サービスネットワーク
１０１  ＵＥ（ＭＳ）
１１１  ＮｏｄｅＢ
１２１  一般ＳＧＳＮ
１２２  Ｃｕｓｔｏｍｉｚｅｄ  ＳＧＳＮ
１３１  ＨＬＲ
１４１  ＧＧＳＮ
１６１  サービスネットワーク
１７１  ＲＮＣ
２０１  ＵＥ
２０２  Ｓｏｕｒｃｅ  ｅＮｏｄｅＢ
２０３  Ｔａｒｇｅｔ  ｅＮｏｄｅＢ
２０４  Ｓｏｕｒｃｅ  ＭＭＥ
２０５  Ｔａｒｇｅｔ  ＭＭＥ
２０６  Ｓｏｕｒｃｅ  ＳＧＷ
２０７  Ｔａｒｇｅｔ  ＳＧＷ
２０８  ＰＧＷ（ＰＤＮ  ＧＷ）
２０９  ＤＮＳ  ｓｅｒｖｅｒ
２１０  サービスネットワーク
２１１  ＨＳＳ
３０１  ＵＥ
３０２  Ｓｏｕｒｃｅ  ＲＮＣ
３０３  Ｔａｒｇｅｔ  ＲＮＣ
３０４  Ｓｏｕｒｃｅ  ＳＧＳＮ
３０５  Ｔａｒｇｅｔ  ＳＧＳＮ
３０６  Ｓｏｕｒｃｅ  ＳＧＷ
３０７  Ｔａｒｇｅｔ  ＳＧＷ
３０８  ＰＧＷ（ＰＤＮ  ＧＷ）
３０９  ＤＮＳ  ｓｅｒｖｅｒ
３１０  サービスネットワーク
３１１  ＨＳＳ
４０１  ＵＥ
４０２  Ｓｏｕｒｃｅ  ＲＮＣ
４０３  Ｔａｒｇｅｔ  ＲＮＣ
４０４  Ｓｏｕｒｃｅ  ＳＧＳＮ
４０５  Ｔａｒｇｅｔ  ＳＧＳＮ
４０８  ＧＧＳＮ
４０９  ＤＮＳ  ｓｅｒｖｅｒ
４１０  サービスネットワーク
４１１  ＨＳＳ
５０１  ＵＥ
５０２  Ｓｏｕｒｃｅ  ｅＮｏｄｅＢ
５０３  Ｔａｒｇｅｔ  ＲＮＣ
５０４  Ｓｏｕｒｃｅ  ＭＭＥ
５０５  Ｔａｒｇｅｔ  ＳＧＳＮ
５０６  ＳＧＷ
５０７  ＰＧＷ（ＰＤＮ  ＧＷ）
５０８  ＤＮＳ  ｓｅｒｖｅｒ
５０９  サービスネットワーク
【要約】
【課題】コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供する。
【解決手段】ローアクセスプライオリティ(Low Access Priority)の端末が該端末からのRRCコネクション要求がローアクセスプライオリティであることを示す情報であるLAPIをソース基地局に提供し、さらに前記ソース基地局を介してソースMMEにLAPIを通知して保持させ、ソースMMEは端末がハンドオーバする場合にソース基地局からHandover Requiredを受信し保持されたLAPIに基づき前記端末に専用のターゲットMMEを選択しForward Relocation Requestを送信する。
【選択図】図１７【図１】
0005862830.tif 000002
【図２】
0005862830.tif 000003
【図３】
0005862830.tif 000004
【図４】
0005862830.tif 000005
【図５】
0005862830.tif 000006
【図６】
0005862830.tif 000007
【図７】
0005862830.tif 000008
【図８】
0005862830.tif 000009
【図９】
0005862830.tif 000010
【図１０】
0005862830.tif 000011
【図１１】
0005862830.tif 000012
【図１２】
0005862830.tif 000013
【図１３】
0005862830.tif 000014
【図１４】
0005862830.tif 000015
【図１５】
0005862830.tif 000016
【図１６】
0005862830.tif 000017
【図１７】
0005862830.tif 000018
【図１８】
0005862830.tif 000019
【図１９】
0005862830.tif 000020
【図２０】
0005862830.tif 000021
【図２１】
0005862830.tif 000022
【図２２】
0005862830.tif 000023
【図２３】
0005862830.tif 000024
【図２４】
0005862830.tif 000025
【図２５】
0005862830.tif 000026