JP2018037971A - 通信サービス提供システムおよび通信サービス提供方法 - Google Patents
通信サービス提供システムおよび通信サービス提供方法 Download PDFInfo
- Publication number
- JP2018037971A JP2018037971A JP2016171569A JP2016171569A JP2018037971A JP 2018037971 A JP2018037971 A JP 2018037971A JP 2016171569 A JP2016171569 A JP 2016171569A JP 2016171569 A JP2016171569 A JP 2016171569A JP 2018037971 A JP2018037971 A JP 2018037971A
- Authority
- JP
- Japan
- Prior art keywords
- function
- communication
- service
- service providing
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 134
- 238000000034 method Methods 0.000 title claims description 26
- 238000012545 processing Methods 0.000 claims abstract description 76
- 238000013523 data management Methods 0.000 claims abstract description 38
- 230000007704 transition Effects 0.000 claims abstract description 33
- 230000004044 response Effects 0.000 claims abstract description 10
- 230000008859 change Effects 0.000 claims description 15
- 230000008569 process Effects 0.000 claims description 13
- 238000012360 testing method Methods 0.000 description 8
- 238000006243 chemical reaction Methods 0.000 description 7
- 241001522296 Erithacus rubecula Species 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 239000000284 extract Substances 0.000 description 3
- 238000011084 recovery Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】通信サービスにおける新規サービスの追加に伴う作業負担を軽減する。【解決手段】通信サービス提供システム20は、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部220で保持し、データはデータ管理部230(NoSQLデータベース)で保持している。プロトコル処理部210は、ユーザ端末からの入力メッセージに応じて関数処理部220のサービス提供用関数を呼び出す。また、関数だけでは通信プロトコルの状態遷移を扱うことはできないため、プロトコル処理部210で状態遷移を行う。【選択図】図2
Description
本発明は、通信サービスの提供に関し、例えば、SIP(Session Initiation Protocol)を用いた通信サービスを提供する通信サービス提供システムおよび通信サービス提供方法に関する。
従来、SIPを用いた通信サービスを作成するためのプラットフォームとして、JSLEEやSIP Servletが提供されている(例えば、非特許文献1および非特許文献2参照)。
商用サービスを提供するSIPサーバでは、既存サービスに影響を与えずサービスを追加するファイル更新機能が提供されている。商用サービスを提供するSIPサーバは、高信頼性を提供するためにアクト・スタンバイの二重化構成を取ることが一般的である。二重化構成のSIPサーバのファイル更新機能では、アクト系で既存サービスを提供中にスタンバイ系に新サービスをデプロイし、スタンバイ系をアクト系に切り替えることで、既存サービスを中断することなく新サービスを提供する。
商用サービスを提供するSIPサーバでは、既存サービスに影響を与えずサービスを追加するファイル更新機能が提供されている。商用サービスを提供するSIPサーバは、高信頼性を提供するためにアクト・スタンバイの二重化構成を取ることが一般的である。二重化構成のSIPサーバのファイル更新機能では、アクト系で既存サービスを提供中にスタンバイ系に新サービスをデプロイし、スタンバイ系をアクト系に切り替えることで、既存サービスを中断することなく新サービスを提供する。
JSR 240: JAINTM SLEE (JSLEE) v1.1,[online],平成28年8月19日検索,インターネット〈URL:https://jcp.org/aboutJava/communityprocess/final/jsr240/index.html〉
JSR 359: SIP Servlet 2.0,[online],平成28年8月19日検索,インターネット〈URL:https://jcp.org/aboutJava/communityprocess/final/jsr359/index.html〉
従来技術に基づいたSIPサーバでは、新しいサービスを追加する際には、当該クラスのオブジェクトだけを変更するのではなく、アプリケーション全体を起動し直す必要がある。このため、上述のようなファイル更新機能を用いたファイル更新が必要となるが、通常、ファイル更新はサービスに対する影響の少ない深夜に実行されるため、頻繁に行うことが困難であり、サービスの追加を実行する時間帯が限られる。
また、従来技術に基づいたSIPサーバは、オブジェクト指向に基づいているため、新サービス提供のためにデータ構造の変更が必要になった場合には、既存サービスのデータ構造から新サービスのデータ構造に変換する処理を新サービスのメソッドに追加する必要がある。新サービスが問題なく提供された場合には問題は起きないが、新サービスで問題が発生し既存サービスに切り戻す場合には、新サービスのデータ構造に変更したデータを既存サービスのデータ構造に変換する必要がある。しかしながら、既存サービスのメソッドにはこの処理は定義されていないため、新サービスから既存サービスにデータの引き継いだ復旧を行うことができない。
本発明は、このような事情に鑑みてなされたものであり、通信サービス提供下において新規サービスの追加に伴う作業負担を軽減することを目的とする。
上述の目的を達成するため、請求項1に記載の発明は、ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムであって、前記通信サービスの提供に必要なサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する関数処理部と、前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信部と、前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記サービス提供用関数群から前記関数処理部に実行させる前記サービス提供用関数を選択する関数選択部と、前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記関数処理部に前記サービス提供用関数を実行させ、返答先ユーザ端末に送信する出力メッセージおよび前記プロトコル状態の遷移先を関数値として得る関数呼び出し部と、前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移部と、を備えることを特徴とする通信サービス提供システムとした。
また、請求項4に記載の発明は、ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムにおける通信サービス提供方法であって、前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信ステップと、前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記通信サービスの提供に必要なサービス提供用関数群から、関数呼び出しステップで実行するサービス提供用関数を選択する関数選択ステップと、前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記サービス提供用関数を実行し、返答先ユーザ端末に送信する出力メッセージおよび前記今回の通信の状態の遷移先を関数値として得る関数呼び出しステップと、前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移ステップと、を含むことを特徴とする通信サービス提供方法とした。
このように通信サービスにおける各処理をサービス提供用関数として定義することにより、オブジェクト指向に基づくシステムと比較して、新規サービスの追加やサービス内容の変更を容易に行うことができる。
より詳細には、C++やJava(登録商標)で作成されたシステムでは、実施中のサービスを継続しながら新規サービスの追加やサービス内容の変更を行うためには、特別なファイル更新機能をアプリケーションに作りこむ必要がある。
これに対して、関数は実行に必要な情報は引数として受け取るので、関数実行環境にデータを保持する必要がなく、関数実行毎に新しい関数実行環境を起動することが可能となる。新しい関数実行環境を起動する時点で最新の関数定義を参照するため、特別なファイル更新機能は不要であり、サービスの追加等を実行するタイミングを任意に設定することができる。
より詳細には、C++やJava(登録商標)で作成されたシステムでは、実施中のサービスを継続しながら新規サービスの追加やサービス内容の変更を行うためには、特別なファイル更新機能をアプリケーションに作りこむ必要がある。
これに対して、関数は実行に必要な情報は引数として受け取るので、関数実行環境にデータを保持する必要がなく、関数実行毎に新しい関数実行環境を起動することが可能となる。新しい関数実行環境を起動する時点で最新の関数定義を参照するため、特別なファイル更新機能は不要であり、サービスの追加等を実行するタイミングを任意に設定することができる。
また、請求項2に記載の発明は、前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を更に備え、前記関数処理部が実行する前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、前記関数処理部が実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、前記ラッパー関数は、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、ことを特徴とする通信サービス提供システムとした。
また、請求項5に記載の発明は、前記通信サービス提供システムは、前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を備え、前記関数呼び出しステップで実行される前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、前記関数呼び出しステップでは、実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記ラッパー関数が前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、ことを特徴とする通信サービス提供方法とした。
このようにすることで、データ構造のバージョンとアプリケーションのバージョンとが一致するか否かを意識することなくデータベースが利用可能となり、データとロジックとを分離して取り扱う上での利便性を向上させることができる。また、実行中のアプリケーションのバージョンの方がデータ構造のバージョンより古い場合にもロールバックが可能となり、例えば新規サービスに不具合が生じた場合などにも容易に対応することができる。
また、請求項3に記載の発明は、前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、前記メッセージ受信部は、前記プロトコル状態データベースに前記プロトコル状態を照会し、前記関数処理部は、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、前記状態遷移部は、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、ことを特徴とする通信サービス提供システムとした。
また、請求項6に記載の発明は、前記通信サービス提供システムは、前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、前記メッセージ受信ステップでは、前記プロトコル状態データベースに前記プロトコル状態を照会し、前記関数呼び出しステップでは、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、前記状態遷移ステップでは、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、ことを特徴とする通信サービス提供方法とした。
このように、通信サービスのサービス状態やプロトコル状態を記録しておくことにより、障害発生時にサービス状態やプロトコル状態を復旧することができる。
本発明によれば、通信サービス提供下において新規サービスの追加に伴う作業負担を軽減することができる。
以下、本発明を実施するための形態(以下、実施の形態とする)について説明する。
図1は、実施の形態にかかる通信サービス提供システム20を含むネットワーク構成例を示すブロック図である。また、図2は、プロトコル処理部210、関数処理部220およびデータ管理部230の詳細構成を示すブロック図である。
通信サービス提供システム20は、ユーザ端末(図1では発端末10および着端末30)に対して所定の通信プロトコル(本実施の形態ではSIP)を使用する通信サービスを提供する。通信サービス提供システム20の特徴は、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部220,221,222で保持し、データはデータ管理部230,231,232で保持している点にある。また、関数だけではSIPの状態遷移を扱うことはできないため、プロトコル処理部210,211,212で状態遷移を行う。
図1は、実施の形態にかかる通信サービス提供システム20を含むネットワーク構成例を示すブロック図である。また、図2は、プロトコル処理部210、関数処理部220およびデータ管理部230の詳細構成を示すブロック図である。
通信サービス提供システム20は、ユーザ端末(図1では発端末10および着端末30)に対して所定の通信プロトコル(本実施の形態ではSIP)を使用する通信サービスを提供する。通信サービス提供システム20の特徴は、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部220,221,222で保持し、データはデータ管理部230,231,232で保持している点にある。また、関数だけではSIPの状態遷移を扱うことはできないため、プロトコル処理部210,211,212で状態遷移を行う。
通信サービス提供システム20は、振り分け処理部200、プロトコル処理部210,211,212、関数処理部220,221,222およびデータ管理部230,231,232として機能する複数のサーバによって構成されている。各機能部は、1台のサーバによって構成されていてもよいし、仮想マシンやLinux(登録商標)コンテナ等の仮想化技術を使って、物理的な1台のサーバ上に複数の仮想サーバ(機能部)を配置してもよい。また、図1では、プロトコル処理部、関数処理部およびデータ管理部が各3つずつ設けられているが、それぞれの構成部の個数は任意である。
また、図1では図示の便宜上、プロトコル処理部210,211,212、関数処理部220,221,222、データ管理部230,231,232間の接続関係を省略しているが、これらの構成部は互いに接続が可能である。
また、図1では図示の便宜上、プロトコル処理部210,211,212、関数処理部220,221,222、データ管理部230,231,232間の接続関係を省略しているが、これらの構成部は互いに接続が可能である。
振り分け処理部200は、ユーザ端末(例えば発端末10)から送信されたメッセージを、複数台のプロトコル処理部210〜212に振り分ける。
なお、プロトコル処理部210〜212は長期保管が必要なデータを有していないため、入力メッセージの内容とプロトコル処理部210〜212との対応付けを行う必要はない。よって、入力メッセージの振り分けは、例えば単純なラウンドロビンやプロトコル処理部210〜212の負荷を考慮したラウンドロビン等の比較的単純なアルゴリズムで行うことが可能である。なお、通信サービス提供システム20内のプロトコル処理部が1台の場合には、振り分け処理部200は不要である。
なお、プロトコル処理部210〜212は長期保管が必要なデータを有していないため、入力メッセージの内容とプロトコル処理部210〜212との対応付けを行う必要はない。よって、入力メッセージの振り分けは、例えば単純なラウンドロビンやプロトコル処理部210〜212の負荷を考慮したラウンドロビン等の比較的単純なアルゴリズムで行うことが可能である。なお、通信サービス提供システム20内のプロトコル処理部が1台の場合には、振り分け処理部200は不要である。
プロトコル処理部210〜212は、入力メッセージの種類に応じて後述する関数処理部220〜222のサービス提供用関数を呼び出し、出力メッセージの送信と状態遷移を行う。
関数処理部220〜222は、通信サービスの提供に用いられるサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する。
データ管理部230〜232は、後述するプロトコル状態データベース2301およびサービス状態データベース2303(図3参照)を含む通信サービスの提供に用いられるデータベースを保持する。
関数処理部220〜222は、通信サービスの提供に用いられるサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する。
データ管理部230〜232は、後述するプロトコル状態データベース2301およびサービス状態データベース2303(図3参照)を含む通信サービスの提供に用いられるデータベースを保持する。
図2にプロトコル処理部210〜212、関数処理部220〜222、データ管理部230〜232の詳細構成を示す。なお、プロトコル処理部210〜212の構成は全て同じであるため、図2にはプロトコル処理部210のみを図示する。関数処理部220〜222、データ管理部230〜232についても同様に、関数処理部220、データ管理部230のみを図示する。
プロトコル処理部210は、メッセージ受信部2101、関数選択部2102、関数呼び出し部2103および状態遷移部2104を備える。
メッセージ受信部2101は、ユーザ端末からの入力メッセージの受信を待機し、入力メッセージを受信するとメッセージ電文を内部形式に復号し、当該入力メッセージに対応するプロトコル状態をプロトコル状態データベース2301から取得する。
ここで、プロトコル状態データベース2301は、後述するデータ管理部230に記憶されており、通信サービス提供システム20上の(通信サービスを用いた)個々の通信の通信プロトコル上の状態(ステート)を示すプロトコル状態を、当該通信の識別情報と対応付けて保持している。
メッセージ受信部2101は、ユーザ端末からの入力メッセージの受信を待機し、入力メッセージを受信するとメッセージ電文を内部形式に復号し、当該入力メッセージに対応するプロトコル状態をプロトコル状態データベース2301から取得する。
ここで、プロトコル状態データベース2301は、後述するデータ管理部230に記憶されており、通信サービス提供システム20上の(通信サービスを用いた)個々の通信の通信プロトコル上の状態(ステート)を示すプロトコル状態を、当該通信の識別情報と対応付けて保持している。
図3(a)にプロトコル状態データベース2301の一例を示す。プロトコル状態データベース2301は、個々の通信の識別情報であるSIPのCall−IDと、当該Call−IDで識別される通信のプロトコル状態(例えば「通信中(ESTABLISHED)」など)が対応付けて記録されている。
メッセージ受信部2101は、入力メッセージのヘッダ部から識別情報(Call−ID)を抽出し、当該識別情報に対応付けられているプロトコル状態をプロトコル状態データベース2301に照会する。
メッセージ受信部2101は、入力メッセージのヘッダ部から識別情報(Call−ID)を抽出し、当該識別情報に対応付けられているプロトコル状態をプロトコル状態データベース2301に照会する。
関数選択部2102は、入力メッセージの種類を判定し、入力メッセージの種類に応じて関数群から関数処理部220に実行させるサービス提供用関数を選択する。関数選択部2102は、入力メッセージのヘッダ部から当該入力メッセージの種類(例えばINVITE、REGISTERなど)を抽出し、データ管理部230に記憶されているメッセージ−関数対応データベース2302を参照して、当該種類に対応付けられているサービス提供用関数を特定する。
図3(b)にメッセージ−関数対応データベース2302の一例を示す。メッセージ−関数対応データベース2302は、例えばINVITE、REGISTERなどの入力メッセージの種類と、実行するサービス提供用関数名とが対応付けて記録されている。
関数呼び出し部2103は、入力メッセージに含まれるサービス提供用関数の実行に必要な情報およびメッセージ受信部2101で取得したプロトコル状態を変数として関数処理部220にサービス提供用関数を実行させ(関数を呼び出し)、返答先ユーザ端末に送信する出力メッセージおよびプロトコル状態の遷移先を関数値として得る。
なお、プロトコル処理部210〜212と同様に、関数処理部220〜222は長期保管が必要なデータを有していないため、単純なラウンドロビンや関数処理部220〜222の負荷を考慮したラウンドロビン等の比較的単純なアルゴリズムで呼び出し先の関数処理部220〜222を決定可能である。
なお、プロトコル処理部210〜212と同様に、関数処理部220〜222は長期保管が必要なデータを有していないため、単純なラウンドロビンや関数処理部220〜222の負荷を考慮したラウンドロビン等の比較的単純なアルゴリズムで呼び出し先の関数処理部220〜222を決定可能である。
状態遷移部2104は、返答先ユーザ端末に出力メッセージを送信するとともに、プロトコル状態データベースに記録されたプロトコル状態を遷移先の状態に更新する。すなわち、状態遷移部2104は、関数値として受け取った出力メッセージを送信先の端末送信することによりプロトコル状態を遷移先の状態に遷移させ、プロトコル状態データベース2301の今回の通信のCall−IDに対応するプロトコル状態を遷移先の状態へと更新する。
つぎに、関数処理部220について説明する。
上述のように、関数処理部220は、通信サービスの提供に必要なサービス提供用関数群を保持するとともに、プロトコル処理部210で指定されたサービス提供用関数を実行する。関数処理部220内のサービス提供用関数は、全体として通信サービスの提供に必要な所定のアプリケーションを構成している。すなわち、アプリケーションにおける種々の処理を個々のサービス提供用関数として定義している。また、関数処理部220は、後述するラッパー関数およびデータ構造変換関数を有している。ラッパー関数およびデータ構造変換関数の詳細については後述する。
図2では、関数処理部220に関数A2201、関数B2202、関数C2203が保持されているものとする。
関数処理部220には長期保管が必要なデータが含まれないため、アプリケーションの各処理はクラスのメソッドではなく関数として実装が可能となる。よって、新規サービスを提供する際は、新規サービス提供に必要な関数のみの更新が可能となる。
例えば、通信サービスに新たな機能を追加したい場合、新たな機能に対応するサービス提供用関数を通信サービス提供システム20内の全ての関数処理部220〜222に実装させ(図面で言えば、図2の関数処理部220内に新たに「関数D」を加え)、全てのデータ管理部230〜232のメッセージ−関数対応データベース2302を書き換えればよい。
上述のように、関数処理部220は、通信サービスの提供に必要なサービス提供用関数群を保持するとともに、プロトコル処理部210で指定されたサービス提供用関数を実行する。関数処理部220内のサービス提供用関数は、全体として通信サービスの提供に必要な所定のアプリケーションを構成している。すなわち、アプリケーションにおける種々の処理を個々のサービス提供用関数として定義している。また、関数処理部220は、後述するラッパー関数およびデータ構造変換関数を有している。ラッパー関数およびデータ構造変換関数の詳細については後述する。
図2では、関数処理部220に関数A2201、関数B2202、関数C2203が保持されているものとする。
関数処理部220には長期保管が必要なデータが含まれないため、アプリケーションの各処理はクラスのメソッドではなく関数として実装が可能となる。よって、新規サービスを提供する際は、新規サービス提供に必要な関数のみの更新が可能となる。
例えば、通信サービスに新たな機能を追加したい場合、新たな機能に対応するサービス提供用関数を通信サービス提供システム20内の全ての関数処理部220〜222に実装させ(図面で言えば、図2の関数処理部220内に新たに「関数D」を加え)、全てのデータ管理部230〜232のメッセージ−関数対応データベース2302を書き換えればよい。
より具体的に、通信サービスに転送サービスを機能追加する場合について説明する。
機能追加前は、INVITEメッセージに対して図4に示す基本呼INVITE関数が対応付けられている。一方、機能追加時には、各関数処理部220〜222に図5に示す付加サービスINVITE関数を実装するとともに、INVITEメッセージに対応付ける関数を付加サービスINVITE関数に変更する。すなわち、メッセージ−関数対応データベース2302において、INVITEメッセージに対応する関数を「基本呼INVITE関数」から「付加サービスINVITE関数」に書き換える。
図5に示す付加サービスINVITE関数は、加入者情報サーバ内の加入者情報データベース50(図1、図2参照)が保持する加入者データを参照し、転送サービスに加入している場合には、Toを転送先に変更して基本呼INVITE関数を呼び出し、加入していない場合にはそのまま基本呼INVITE関数を呼び出すものである。付加サービスINVITE関数は、加入者の契約情報に基づいた状態遷移を行うため、その実行時には図2の関数B2202のように加入者情報データベース50にアクセスする。
機能追加前は、INVITEメッセージに対して図4に示す基本呼INVITE関数が対応付けられている。一方、機能追加時には、各関数処理部220〜222に図5に示す付加サービスINVITE関数を実装するとともに、INVITEメッセージに対応付ける関数を付加サービスINVITE関数に変更する。すなわち、メッセージ−関数対応データベース2302において、INVITEメッセージに対応する関数を「基本呼INVITE関数」から「付加サービスINVITE関数」に書き換える。
図5に示す付加サービスINVITE関数は、加入者情報サーバ内の加入者情報データベース50(図1、図2参照)が保持する加入者データを参照し、転送サービスに加入している場合には、Toを転送先に変更して基本呼INVITE関数を呼び出し、加入していない場合にはそのまま基本呼INVITE関数を呼び出すものである。付加サービスINVITE関数は、加入者の契約情報に基づいた状態遷移を行うため、その実行時には図2の関数B2202のように加入者情報データベース50にアクセスする。
上記課題で述べたように、既存のSIPサーバでは、変更されたクラスだけを更新することができず、アプリケーション全体を更新する必要がある。これに対して、通信サービス提供システム20では、変更が必要な個所を関数として定義し、関数単位で追加を可能としている。よって、サービス追加に必要な関数のみの更新で新サービスの追加が可能となり、サービス追加を容易に行うことができる。
なお、更新単位を関数にするためには、オブジェクト指向を適用することはできない。関数だけでは状態遷移を扱うことはできないため、通信プロトコル(SIP)の処理(処理状態遷移)はプラットフォーム(プロトコル処理部210)で行っている。
なお、更新単位を関数にするためには、オブジェクト指向を適用することはできない。関数だけでは状態遷移を扱うことはできないため、通信プロトコル(SIP)の処理(処理状態遷移)はプラットフォーム(プロトコル処理部210)で行っている。
図2の説明に戻り、データ管理部230は、通信サービスの提供に用いられるデータベースを保持する。
上述したプロトコル処理部210および関数処理部220は、データを保持していないため、複数のサーバのいずれを選択してもよいが、データ管理部230〜232については、必要なデータを保持しているサーバを選択する必要がある(例えばある端末間のセッションのプロトコル状態を保持しているデータ管理部(サーバ)を選択する必要がある)。データベースのライブラリを用いることにより、プロトコル処理部210〜212や関数処理部220〜222は、データ管理部230〜232の構成を意識することなく必要なデータにアクセス可能となる。
なお、データベースは、それぞれのデータ管理部230〜232が保持するデータを同期する機能を有している。データベースによって同期する機能の詳細は異なるが、例えばNoSQLデータベースは一般的にデータの紛失を防ぐためデータを3重化(3台のサーバに同じデータを保存)している。NoSQLデータベースによっては、設定ファイル等で多重度の変更やデータ格納要求に対する応答のタイミングの変更(1台のサーバへの格納が完了した時点で応答か、3台全てのサーバへの格納が完了した時点で応答か、など)が可能である。
データ管理部230としては、例えばNoSQLデータベースを用いることができる。
上述したプロトコル処理部210および関数処理部220は、データを保持していないため、複数のサーバのいずれを選択してもよいが、データ管理部230〜232については、必要なデータを保持しているサーバを選択する必要がある(例えばある端末間のセッションのプロトコル状態を保持しているデータ管理部(サーバ)を選択する必要がある)。データベースのライブラリを用いることにより、プロトコル処理部210〜212や関数処理部220〜222は、データ管理部230〜232の構成を意識することなく必要なデータにアクセス可能となる。
なお、データベースは、それぞれのデータ管理部230〜232が保持するデータを同期する機能を有している。データベースによって同期する機能の詳細は異なるが、例えばNoSQLデータベースは一般的にデータの紛失を防ぐためデータを3重化(3台のサーバに同じデータを保存)している。NoSQLデータベースによっては、設定ファイル等で多重度の変更やデータ格納要求に対する応答のタイミングの変更(1台のサーバへの格納が完了した時点で応答か、3台全てのサーバへの格納が完了した時点で応答か、など)が可能である。
データ管理部230としては、例えばNoSQLデータベースを用いることができる。
データ管理部230の保持するデータベースとして、上述したプロトコル状態データベース2301およびメッセージ−関数対応データベース2302が挙げられる。
また、データ管理部230は、個々の通信に対応する通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベース2303を更に備える。サービス状態データベース2303に記録されたサービス状態は、障害時の復旧に必要となる。図3(c)にサービス状態データベース2303の一例を示す。
また、データ管理部230は、個々の通信に対応する通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベース2303を更に備える。サービス状態データベース2303に記録されたサービス状態は、障害時の復旧に必要となる。図3(c)にサービス状態データベース2303の一例を示す。
サービス状態データベース2303は、個々の通信の識別情報であるSIPのCall−IDと、当該Call−IDで識別される通信のサービス状態が対応付けて記録されている。例えば通信サービスがキャッチホンサービスである場合、通話中に新しい着信があった場合に、元々の通話先電話番号(図3(c)における「番号1」)、新しい着信の電話番号(図3(c)における「番号2」)、およびどちらの電話番号と通話中であるか(図3(c)における「相手先」)、の3種類のデータをサービス状態として保存する。
サービス状態データベース2303の更新は、関数処理部220〜222によって行われる。すなわち、関数処理部220においてサービス状態を変更する関数(例えば図2の関数C2203)を実行した場合、サービス状態データベース2303に記録された今回の通信に対応するサービス状態を、変更後のサービス状態に更新する。
サービス状態データベース2303の更新は、関数処理部220〜222によって行われる。すなわち、関数処理部220においてサービス状態を変更する関数(例えば図2の関数C2203)を実行した場合、サービス状態データベース2303に記録された今回の通信に対応するサービス状態を、変更後のサービス状態に更新する。
また、データ管理部230に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されている。関数処理部220が実行するサービス提供用関数が所定のデータベースにアクセスする際はラッパー関数を経由してアクセスする。ラッパー関数は、データベースアクセスの詳細を隠蔽するための関数である。ラッパー関数は、関数処理部220のサービス提供用関数によって構成されるアプリケーションのバージョンが上記所定のデータベースのデータ構造のバージョンと異なる場合には、データ構造をアプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す。アプリケーション更新時には、ラッパー関数から参照可能なアプリケーションのバージョンを関数定義とは独立したファイル等に定義しておく。ラッパー関数は、データベースに格納されたデータ構造のバージョンとアプリケーションのバージョンが整合しているかを確認し、整合していない場合にはデータ構造変換関数を呼び出す。データ構造変換関数は、データベースのデータ構造のバージョンと、アプリケーションのバージョンとの組み合わせ毎に定義される。
より詳細には、既存SIPサーバでは、Java(登録商標)やC++等のオブジェクトとしてデータが管理されていたため、機能追加時のデータ構造変更時にはアプリケーションがデータ構造の変更を行う必要があった。
一方、本実施の形態の通信サービス提供システム20では、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部220で保持し、データはデータ管理部230(NoSQLデータベース)で保持している。それぞれのデータベースには、データ構造のバージョンが追加されている。そして、サービス提供用関数からデータベースへのアクセスは、直接ではなく、ラッパー関数経由で行う。ラッパー関数が必要に応じてデータ構造変換関数を呼び出すため、アプリケーションを構成するサービス提供用関数ではデータ構造のバージョンを意識した処理を行う必要はない。
一方、本実施の形態の通信サービス提供システム20では、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部220で保持し、データはデータ管理部230(NoSQLデータベース)で保持している。それぞれのデータベースには、データ構造のバージョンが追加されている。そして、サービス提供用関数からデータベースへのアクセスは、直接ではなく、ラッパー関数経由で行う。ラッパー関数が必要に応じてデータ構造変換関数を呼び出すため、アプリケーションを構成するサービス提供用関数ではデータ構造のバージョンを意識した処理を行う必要はない。
また、既存SIPサーバでは、不具合等で元のデータ構造にロールバックしたい場合、変更済のデータと変更前のデータを判断して適切な処理を行うプログラムを作成する必要があった。
一方、本実施の形態の通信サービス提供システム20では、データ構造のロールバック時にも、アプリケーションのバージョンとデータ構造のバージョンとが異なる場合にデータ構造変換関数を呼び出すことになる。ただし、ロールバックの場合には、アプリケーションのバージョンよりもデータ構造のバージョンの方が新しいという点がバージョンアップの場合とは異なる。したがって、データ構造変換関数は、データ構造の新しいバージョンからアプリケーションのバージョンにデータ構造を変換することになる。
一方、本実施の形態の通信サービス提供システム20では、データ構造のロールバック時にも、アプリケーションのバージョンとデータ構造のバージョンとが異なる場合にデータ構造変換関数を呼び出すことになる。ただし、ロールバックの場合には、アプリケーションのバージョンよりもデータ構造のバージョンの方が新しいという点がバージョンアップの場合とは異なる。したがって、データ構造変換関数は、データ構造の新しいバージョンからアプリケーションのバージョンにデータ構造を変換することになる。
以上説明したように、実施の形態にかかる通信サービス提供システム20によれば、通信サービスにおける各処理をサービス提供用関数として定義することにより、オブジェクト指向に基づくシステムと比較して、新規サービスの追加やサービス内容の変更を容易に行うことができる。
すなわち、関数は実行に必要な情報は引数として受け取るので、関数実行環境にデータを保持する必要がなく、関数実行毎に新しい関数実行環境を起動することが可能となる。新しい関数実行環境を起動する時点で最新の関数定義を参照するため、特別なファイル更新機能は不要であり、サービスの追加等を実行するタイミングを任意に設定することができる。
また、サービス提供用関数からデータベースへのアクセスをラッパー関数経由で行うことによって、データ構造のバージョンとアプリケーションのバージョンとが一致するか否かを意識することなくデータベースが利用可能となり、データとロジックとを分離して取り扱う上での利便性を向上させることができる。また、実行中のアプリケーションのバージョンの方がデータ構造のバージョンより古い場合にもロールバックが可能となり、例えば新規サービスに不具合が生じた場合などにも容易に対応することができる。
すなわち、関数は実行に必要な情報は引数として受け取るので、関数実行環境にデータを保持する必要がなく、関数実行毎に新しい関数実行環境を起動することが可能となる。新しい関数実行環境を起動する時点で最新の関数定義を参照するため、特別なファイル更新機能は不要であり、サービスの追加等を実行するタイミングを任意に設定することができる。
また、サービス提供用関数からデータベースへのアクセスをラッパー関数経由で行うことによって、データ構造のバージョンとアプリケーションのバージョンとが一致するか否かを意識することなくデータベースが利用可能となり、データとロジックとを分離して取り扱う上での利便性を向上させることができる。また、実行中のアプリケーションのバージョンの方がデータ構造のバージョンより古い場合にもロールバックが可能となり、例えば新規サービスに不具合が生じた場合などにも容易に対応することができる。
なお、一般に、通信サービスに新規サービスを追加する際には、商用サービス提供環境(商用環境)とは別に、これとほぼ同規模の試験環境を構築する必要がある。ここで、本実施の形態の通信サービス提供システム20が用いるSIPでは、HTTPと異なりパスで商用環境と試験環境を分離することができない。このため、ポート番号で商用環境と試験環境を分離する。例えば、商用環境ではポート番号5060を使用し、試験環境ではポート番号15060を使用するなどである。
また、メッセージ−関数対応データベース2302においても、図6(a)に示すように、試験環境と商用環境で対応する関数を別々に管理する。また、関数を変更せずに試験環境では試験用データを、商用環境では商用データを、それぞれ参照・更新できるようにするため、図6(b)および図6(c)に示すように、環境毎にラッパー関数名と関数の対応表およびデータベース名とデータベースの対応表を作成し、実行時にそれぞれの名前解決を行う。
これにより、商用サービス環境で商用サービスに影響を与えずにサービスの試験を実施することができる。
また、メッセージ−関数対応データベース2302においても、図6(a)に示すように、試験環境と商用環境で対応する関数を別々に管理する。また、関数を変更せずに試験環境では試験用データを、商用環境では商用データを、それぞれ参照・更新できるようにするため、図6(b)および図6(c)に示すように、環境毎にラッパー関数名と関数の対応表およびデータベース名とデータベースの対応表を作成し、実行時にそれぞれの名前解決を行う。
これにより、商用サービス環境で商用サービスに影響を与えずにサービスの試験を実施することができる。
20 通信サービス提供システム
200 振り分け処理部
210,211,212 プロトコル処理部
2101 メッセージ受信部
2102 関数選択部
2103 関数呼び出し部
2104 状態遷移部
220,221,222 関数処理部
230,231,232 データ管理部
2301 プロトコル状態データベース
2302 メッセージ−関数対応データベース
2303 サービス状態データベース
10 発端末
30 着端末
50 加入者情報データベース
200 振り分け処理部
210,211,212 プロトコル処理部
2101 メッセージ受信部
2102 関数選択部
2103 関数呼び出し部
2104 状態遷移部
220,221,222 関数処理部
230,231,232 データ管理部
2301 プロトコル状態データベース
2302 メッセージ−関数対応データベース
2303 サービス状態データベース
10 発端末
30 着端末
50 加入者情報データベース
Claims (6)
- ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムであって、
前記通信サービスの提供に必要なサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する関数処理部と、
前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信部と、
前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記サービス提供用関数群から前記関数処理部に実行させる前記サービス提供用関数を選択する関数選択部と、
前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記関数処理部に前記サービス提供用関数を実行させ、返答先ユーザ端末に送信する出力メッセージおよび前記プロトコル状態の遷移先を関数値として得る関数呼び出し部と、
前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移部と、
を備えることを特徴とする通信サービス提供システム。 - 前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を更に備え、
前記関数処理部が実行する前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、
前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、
前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、
前記関数処理部が実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、
前記ラッパー関数は、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、
ことを特徴とする請求項1に記載の通信サービス提供システム。 - 前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、
前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、
前記メッセージ受信部は、前記プロトコル状態データベースに前記プロトコル状態を照会し、
前記関数処理部は、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、
前記状態遷移部は、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、
ことを特徴とする請求項1または請求項2に記載の通信サービス提供システム。 - ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムにおける通信サービス提供方法であって、
前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信ステップと、
前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記通信サービスの提供に必要なサービス提供用関数群から、関数呼び出しステップで実行するサービス提供用関数を選択する関数選択ステップと、
前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記サービス提供用関数を実行し、返答先ユーザ端末に送信する出力メッセージおよび前記今回の通信の状態の遷移先を関数値として得る関数呼び出しステップと、
前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移ステップと、
を含むことを特徴とする通信サービス提供方法。 - 前記通信サービス提供システムは、
前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を備え、
前記関数呼び出しステップで実行される前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、
前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、
前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、
前記関数呼び出しステップでは、実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記ラッパー関数が前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、
ことを特徴とする請求項4に記載の通信サービス提供方法。 - 前記通信サービス提供システムは、
前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、
前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、
前記メッセージ受信ステップでは、前記プロトコル状態データベースに前記プロトコル状態を照会し、
前記関数呼び出しステップでは、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、
前記状態遷移ステップでは、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、
ことを特徴とする請求項4または請求項5に記載の通信サービス提供方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016171569A JP6533502B2 (ja) | 2016-09-02 | 2016-09-02 | 通信サービス提供システムおよび通信サービス提供方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016171569A JP6533502B2 (ja) | 2016-09-02 | 2016-09-02 | 通信サービス提供システムおよび通信サービス提供方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2018037971A true JP2018037971A (ja) | 2018-03-08 |
JP6533502B2 JP6533502B2 (ja) | 2019-06-19 |
Family
ID=61567790
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016171569A Active JP6533502B2 (ja) | 2016-09-02 | 2016-09-02 | 通信サービス提供システムおよび通信サービス提供方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6533502B2 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111078483A (zh) * | 2019-12-31 | 2020-04-28 | 中国科学院长春光学精密机械与物理研究所 | 通信协议状态转换序列生成方法 |
JP2021520169A (ja) * | 2018-03-29 | 2021-08-12 | ディーエルティー グローバル インク. | 更新可能なスマートコントラクト |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011130374A (ja) * | 2009-12-21 | 2011-06-30 | Toshiba Corp | サービスネゴシエーション装置およびサービスネゴシエーションプログラム |
JP2016154294A (ja) * | 2015-02-20 | 2016-08-25 | 日本電気株式会社 | 通信装置、中継装置、通信方法及び通信プログラム |
-
2016
- 2016-09-02 JP JP2016171569A patent/JP6533502B2/ja active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011130374A (ja) * | 2009-12-21 | 2011-06-30 | Toshiba Corp | サービスネゴシエーション装置およびサービスネゴシエーションプログラム |
JP2016154294A (ja) * | 2015-02-20 | 2016-08-25 | 日本電気株式会社 | 通信装置、中継装置、通信方法及び通信プログラム |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021520169A (ja) * | 2018-03-29 | 2021-08-12 | ディーエルティー グローバル インク. | 更新可能なスマートコントラクト |
JP7429015B2 (ja) | 2018-03-29 | 2024-02-07 | ケーエヌエヌエックス コーポレーション | 更新可能なスマートコントラクト |
CN111078483A (zh) * | 2019-12-31 | 2020-04-28 | 中国科学院长春光学精密机械与物理研究所 | 通信协议状态转换序列生成方法 |
Also Published As
Publication number | Publication date |
---|---|
JP6533502B2 (ja) | 2019-06-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109639572B (zh) | 路由管理方法、装置及微服务*** | |
US9948549B2 (en) | Producing routing messages for voice over IP communications | |
US10880231B2 (en) | Systems and methods for determining routing information for a network request | |
US7212623B2 (en) | Method for telecommunications service-to-service asynchronous communications using a context cache | |
EP2795849B1 (en) | Method and apparatus for messaging in the cloud | |
US8850051B2 (en) | Methods, systems, and computer program products for transaction-based internet protocol (IP) telephony call processing | |
US9553901B2 (en) | VOIP service with streamlined call transfer options | |
JP2008131519A (ja) | コンタクト先情報登録方法、ネットワークシステム、ノードおよびコンタクト先情報登録プログラム | |
US20220100644A1 (en) | METHOD AND SYSTEM FOR AUTOMATED TESTING OF WEB SERVICE APIs | |
CN102651732B (zh) | 一种ims网络中的业务触发方法和*** | |
JP6533502B2 (ja) | 通信サービス提供システムおよび通信サービス提供方法 | |
JP5775488B2 (ja) | Enumキャッシュ装置およびenumキャッシュ装置のキャッシュ更新方法 | |
US8146069B2 (en) | Method and apparatus for performing non service affecting software upgrades in place | |
CN103595691A (zh) | Ims网络中一种基于规则的动态业务触发方法 | |
CN101163272B (zh) | 用于ims网络的基于应用服务器分组的业务触发方法 | |
JP5940990B2 (ja) | Apl−scm−feおよびアプリケーション連携方法 | |
CN110324425B (zh) | 混合云交易路由处理方法及装置 | |
JP2013153379A (ja) | アプリケーションサーバおよび発信地域導出方法 | |
CN113783826A (zh) | 一种微服务异常处理方法和装置 | |
CN113067848B (zh) | 一种通话记录同步方法、***及电子设备 | |
US8699680B2 (en) | Unscreened automatic number identification based on branch identifier | |
CN116962510A (zh) | 业务数据处理方法、装置、电子设备和计算机程序产品 | |
JP5272027B2 (ja) | 呼制御方法、および呼制御システム | |
CN118158628A (zh) | 数据处理方法、装置及设备 | |
CN109962899A (zh) | 触发虚拟专用移动网业务的方法、装置、设备和介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180905 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190521 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190524 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6533502 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |