Method and apparatus for media independent handover
21 claims: 4 independent, 17 dependent
- 1ハンドオーバを実施する方法であって、 インターネットプロトコル(IP)マルチメディアサブシステム(IMS) クライアントがIMS ネットワークに登録するステップと、 前記IMSクライアントが、 INVITE要求をサービス呼セッション制御機能(S-CSCF)に送ることによって、セッション開始プロトコル(SIP)を使用してMIHアプリケーションサーバとのメディア独立ハンドオーバ(MIH)セッションを確立するステップであって、前記INVITE要求は、文字列「MIH services」と、 前記 IMSクライアントの一意の識別子とを含む、ステップと、 前記IMSクライアントが、 SIPを使用して通信ピアとのIPベースサービスのセッションを確立するステップと、 前記IMSクライアントが、 ハンドオーバのためにIP上で前記MIHアプリケーションサーバとMIHメッセージを交換するステップと、 前記IMSクライアントが、 ハンドオーバを実施するステップと、 前記IMSクライアントが、 前記IPベースサービスのセッションを再開するためにRE-INVITE要求およびREFER要求のうちの1つを送るステップであって、前記RE-INVITE要求および前記REFER要求は、文字列「MIH services」と、前記IMSクライアントの前記一意の識別子とを含む、ステップと、 前記IPベースサービスのセッションを再開するステップと を含むことを特徴とする方法。
- 2前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバとの能力発見手順を実施するステップをさらに含むことを特徴とする請求項1に記載の方法。
- 3前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバとのMIH登録手順を実施するステップをさらに含むことを特徴とする請求項1に記載の方法。
- 4前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバとのイベントサブスクリプション手順を実施するステップをさらに含むことを特徴とする請求項1に記載の方法。
- 5前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバに信号強度レポートを送るステップと、 前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバから隣接リスト情報を受け取るステップと、 前記IMSクライアントが、前記隣接リスト情報に基づいてリンクを検出すステップと、 前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバに リンクが検出されたことの表示 を送るステップと、 前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバからハンドオーバコマンドを受け取るステップと、 前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバにハンドオーバ結果を送るステップと をさらに含むことを特徴とする請求項1に記載の方法。
- 6前記IMSクライアントが、 IP上で前記MIHアプリケーションサーバに登録取消し要求を送るステップと、 前記IMSクライアントが、 前記MIHセッションの終了を求めるBYE要求を前記MIHアプリケーションサーバに送るステップと をさらに含むことを特徴とする請求項1に記載の方法。
- 7ハンドオーバを実施する方法であって、 サービス呼セッション制御機能(S-CSCF)を介してインターネットプロトコル(IP)マルチメディアサブシステム(IMS)クライアントからINVITE要求を受け取るステップであって、前記INVITE要求は、文字列「MIH services」と、前記IMSクライアントの一意の識別子とを含む、ステップと、 前記IMSクライアントのバインディングを作成するステップと、 セッション開始プロトコル(SIP)を使用して前記IMSクライアントとのメディア独立ハンドオーバ(MIH)セッションを確立するステップと、 前記IMSクライアントにハンドオーバコマンドを送るステップと、 前記IMSクライアントからハンドオーバ結果を受け取るステップと、 前記IMSクライアントからRE-INVITE要求およびREFER要求のうちの1つを受け取るステップであって、前記RE-INVITE要求および前記REFER要求は、文字列「MIH services」と、IMSクライアントの一意の識別子とを含む、ステップと、 前記バインディングを更新するステップとを含むことを特徴とする方法。
- 8前記一意の識別子はMIH機能(MIHF)識別子であることを特徴とする請求項7に記載の方法。
- 9登録状態および登録タイマは、前記IMSクライアントの前記バインディングで維持されることを特徴とする請求項7に記載の方法。
- 10前記登録状態は、未登録状態、登録保留状態、登記済みアクティブ状態、登記済み非アクティブ状態、および登録取消し保留状態のうちの1つであることを特徴とする請求項9に記載の方法。
- 11ハンドオーバを実施するための無線送受信装置(WTRU)であって、 セッション開始プロトコル(SIP)を使用して通信ピアとのIPベースサービスのセッションを確立するように構成されたインターネットプロトコル(IP)マルチメディアサブシステム(IMS)アプリケーション層と、 ハンドオーバ後に前記IPベースサービスのセッションが再開されるように、SIPを使用してMIHアプリケーションサーバとのメディア独立ハンドオーバ(MIH)セッションを確立し、前記ハンドオーバを実施するように構成されたサービスポリシーエンティティと、 IP上で前記MIHアプリケーションサーバとMIHメッセージを交換するように構成されたMIH機能エンティティであって、前記MIHセッションは、INVITE要求をサービス呼セッション制御機能(S-CSCF)に送ることによって確立され、RE-INVITE要求およびREFER要求のうちの1つが、前記IPベースサービスのセッションを再開するためにハンドオーバ後に前記MIHアプリケーションサーバに送られ、前記INVITE要求、前記RE-INVITE要求、および前記REFER要求は、文字列「MIH services」と、IMSクライアントの一意の識別子とを含む、MIH機能エンティティと を含むことを特徴とするWTRU。
- 12前記一意の識別子はMIH機能(MIHF)識別子であることを特徴とする請求項11に記載のWTRU。
- 13前記MIH機能エンティティは、IP上で前記MIHアプリケーションサーバとの能力発見手順を実施するように構成されることを特徴とする請求項11に記載のWTRU。
- 14前記MIH機能エンティティは、IP上で前記MIHアプリケーションサーバとのMIH登録手順を実施するように構成されることを特徴とする請求項11に記載のWTRU。
- 15前記MIH機能エンティティは、IP上で前記MIHアプリケーションサーバとのイベントサブスクリプション手順を実施するように構成されることを特徴とする請求項11に記載のWTRU。
- 16前記MIH機能エンティティは、IP上で前記MIHアプリケーションサーバに信号強度レポートを送り、IP上で前記MIHアプリケーションサーバから隣接リスト情報を受け取り、IP上で前記MIHアプリケーションサーバに隣接セル信号強度レポートを送り、IP上で前記MIHアプリケーションサーバからハンドオーバコマンドを受け取り、IP上で前記MIHアプリケーションサーバにハンドオーバ結果を送るように構成されることを特徴とする請求項11に記載のWTRU。
- 17ハンドオーバをサポートするためのメディア独立ハンドオーバ(MIH)アプリケーションサーバ(MIH)であって、 サービス呼セッション制御機能(S-CSCF)を介してインターネットプロトコル(IP)マルチメディアサブシステム(IMS)クライアントからINVITE要求を受け取るためのセッション開始プロトコル(SIP)インターフェースであって、前記INVITE要求は、文字列「MIH services」と、IMSクライアントの一意の識別子とを含む、SIPインターフェースと、 前記IMSクライアントのバインディングを作成し、前記IMSクライアントとのMIHセッションを確立するためのモビリティ/ハンドオーバポリシー機能(MHPF)エンティティであって、前記IMSクライアントからのRE-INVITE要求およびREFER要求のうちの1つに基づいて前記バインディングを更新するように構成され、前記RE-INVITE要求および前記REFER要求は、文字列「MIH services」と、前記IMSクライアントの前記一意の識別子とを含む、MHPFエンティティと、 ハンドオーバのためにIP上で前記IMSクライアントとMIHメッセージを交換するためのMIH機能エンティティと を含むことを特徴とするMIHアプリケーションサーバ。
- 18前記MIH機能エンティティは、前記IMSクライアントにハンドオーバコマンドを送り、前記IMSクライアントからハンドオーバ結果を受け取るように構成されることを特徴とする請求項17に記載のMIHアプリケーションサーバ。
- 19前記一意の識別子はMIH機能(MIHF)識別子であることを特徴とする請求項17に記載のMIHアプリケーションサーバ。
- 20登録状態および登録タイマは、前記IMSクライアントの前記バインディングで維持されることを特徴とする請求項17に記載のMIHアプリケーションサーバ。
- 21前記登録状態は、未登録状態、登録保留状態、登記済みアクティブ状態、登記済み非アクティブ状態、および登録取消し保留状態のうちの1つであることを特徴とする請求項20に記載のMIHアプリケーションサーバ。
Independent claims21
128 paragraphs, as filed
The present invention relates to media independent handover between heterogeneous wireless networks.
The Internet Protocol (IP) multimedia subsystem (IMS) is a standardized next generation networking (NGN) architecture for providing mobile and fixed multimedia services. IMS uses the session initiation protocol (SIP) and runs over IP. IMS can be used for many different services, such as instant messaging, video streaming, voice over IP (VoIP) and any other IP-based service.
The goal of IMS is to provide all current and future services provided by the Internet. One of the methods used to provide these services is through the IMS application server. An IMS application server is a network entity that hosts and runs one or more IP services. The application server is triggered to provide service by the service call session control function (S-CSCF), which is the central node of the IMS signaling plane.
The IEEE 802.21 standard defines mechanisms and procedures that help perform and manage intersystem handovers. Under IEEE 802.21, three main services can be accessed by mobility management applications to aid in the management of handover operations and system discovery and selection. These services include event services, information services and command services. These services are independent of each other and, as a result, can be provided independently.
<p><patcit num="1"><text>U.S. Patent Application No. 60 / 801,786</text></patcit></p>
Currently, how the IEEE 802.21 service can interact with existing mobility management and handover functionality already defined in the relevant third generation partnership project (3GPP) or similar wireless standard specifications. There is no interface or mechanism to describe. There is no procedure or functionality to integrate the IEEE 802.21 service into 3GPP or other wireless standards unless the existing mobility management mechanism and handover procedure are modified. Therefore, there is a need for MIH application servers that can integrate MIH services within 3GPP or other wireless standard based networks.
<p> Methods and devices for performing handovers are disclosed. The IMS client registers with the IMS network and uses SIP to establish a MIH session with the MIH application server. IMS clients use SIP to establish IP-based service (eg, VoIP) sessions with communication peers. MIH messages are exchanged with the MIH application server over IP for handover. After the handover, the session is resumed. S-CSCF triggers the MIH application server based on the string "MIH services" and the unique identifier contained in the INVITE request. The IMS client may send a REFER request to the MIH application server after the handover to resume the session. Alternatively, the IMS client may send a RE-INVITE request to the MIH application server and communication peer.</p><p> A more detailed understanding is provided for illustration purposes and can be obtained from the following description, which is understood in conjunction with the accompanying drawings.</p>
<figref num="1">It is a block diagram of MIH application server.</figref><figref num="2A">It is an exemplary call flow of handover according to one embodiment.</figref><figref num="2B">It is an exemplary call flow of handover according to one embodiment.</figref><figref num="2C">It is an exemplary call flow of handover according to one embodiment.</figref><figref num="2D">It is an exemplary call flow of handover according to one embodiment.</figref><figref num="3A">It is an exemplary call flow of handover according to another embodiment.</figref><figref num="3B">It is an exemplary call flow of handover according to another embodiment.</figref><figref num="3C">It is an exemplary call flow of handover according to another embodiment.</figref><figref num="3D">It is an exemplary call flow of handover according to another embodiment.</figref><figref num="4">It is a figure which shows an exemplary INVITE request message.</figref><figref num="5">It is a figure which shows an exemplary REFER request message.</figref><figref num="6">It is a figure which shows the example RE-INVITE request message addressed to the IMS client.</figref><figref num="7">It is a figure which shows the example RE-INVITE request message addressed to the MIH application server.</figref><figref num="8">It is a figure which shows the registration state change of an IMS client.</figref>
When referred to below, the term "wireless transmit / receive unit (WTRU)" includes, but is not limited to, user equipment (UE), mobile stations, fixed or mobile subscriber equipment, pagers. Includes mobile phones, personal digital assistants (PDAs), computers, or any other type of user device that can operate in a wireless environment.
Although embodiments are described as an example with respect to VoIP services, the embodiments are applicable to any other service with session configuration (eg, instant messaging, video streaming, or any other IP-based service). Please note that.
FIG. 1 is a block diagram of the MIH application server 100. The MIH application server 100 includes a MIH function (MIHF) entity 105, an interworking function (IWF) interface 110, a SIP interface 115, and a mobility and handover policy function (MHPF). Includes entity 120, upper layer transport device (eg IP based) 125, and L2 transport device (eg IEEE 802.xx based) 130. The MIH application server 100 facilitates seamless integration of IP functions to and from IMS clients (eg, WTRU) on any IMS-enabled network via the upper layer transport device 125. The MIH application server 100 is an IEEE to and from an IMS client on an 802.xx access network via the L2 transport device 130. Facilitates seamless integration of 802.xx features. The MIH application server 100 also supports SIP signaling and interface with S-CSCF in the IMS network via SIP interface 115.
MIHF entity 105 receives MIH messages (ie MIH events and information) via upper layer transport device 125 (eg, on IP) and / or via L2 transport device 130 (eg IEEE 802.xx). .. In response to the MIH message, the MIHF entity 105 sends a MIH message (ie, MIH event, information and command) via the upper layer transport device 125 or the L2 transport device 130. MIHF entity 105 can also output event signaling to MHPF entity 120 (for example, changes in the current status of link-layer technology that supports sessions) or to IWF interface 110 (for example, indicating successful handover completion). ..
The IWF interface 110 translates SIP messages received via SIP interface 115 into MIH messages and vice versa. IWF interface 110 receives events from MIHF entity 105, SIP signaling from SIP interface 115, and commands from MHPF entity 120 and translates them into MIH or SIP signaling.
The MHPF entity 120 dynamically determines specific behavior and the mapping of SIP messages to MIH messages and vice versa. The MHPF entity 120 controls handover between heterogeneous networks. The MHPF entity 120 receives the handover event and SIP signaling, and outputs the handover command and SIP call control signaling.
SIP interface 115 can also receive commands from MHPF entity 120 for session control and also receive events from MIHF entity 120 via IWF interface 110. SIP interface 115 outputs SIP signaling for call / session control.
2A-2D are exemplary call flows 200 for handover according to one embodiment. In the following, it is assumed that the IMS client 160 is first connected to the cellular access network 150 and performs a handover to the wireless local area network (WLAN) access network 155. Note that the opposite scenario is possible and the handover may be performed between any type of wireless network. The IMS client 160 (eg, WTRU) discovers the proxy call session control function (P-CSCF) 140 and then registers with the IMS network (ie, S-CSCF 145) (step 202). Service policy entity 164 of IMS client 160 initiates a MIH session (step 204). The SIP stack 162 of the IMS client 160 sends an INVITE request to the P-CSCF 140 (step 206). P-CSCF 140 is S-CSCF Forward the INVITE request to 145 (step 208). The S-CSCF 145 downloads the profile of the IMS client 160 and triggers the MIH application server based on the filter criteria (step 210), which is described in detail below.
The MIH application server 100 operates in SIP user agent mode. The SIP interface 115 of the MIH application server 100 retrieves the unique identifier and IP address of the IMS client 160 included in the INVITE request and passes them to the MHPF entity 120 (step 212). MHPF entity 120 creates a binding for IMS client 160 and indicates binding completion to SIP interface 115 (step 214). The binding may include a unique identifier for the IMS client 160 (eg MIHF identifier (ID)), the current IP address of the IMS client 160, and the registration state and the registration timer associated with the registration state, which is detailed below. Explained in.
SIP interface 115 sends a 200 OK message to IMS client 160 via S-CSCF 145 and P-CSCF 140 (step 216). IMS client 160 sends an acknowledgment (ACK) to MIH application server 100 (step 217). The MIH session is then established and the IMS client 160 and MIH application server 100 may exchange MIH messages directly over IP.
After the MIH session completion is indicated to service policy entity 164 in step 218, service policy entity 164 triggers MIHF entity 166 to send a remote MIH message to MIH application server 100. MIHF entity 166 in IMS client 160 may perform capability discovery procedures with MIHF entity 125 in MIH application server 100 (steps 220, 222). MIHF entity 166 can also perform MIH registration procedures to register for a particular service (steps 224, 226). MIHF entity 125 may perform an event subscription procedure with MIHF entity 166 (steps 228, 230). The MIH messages exchanged in steps 220-230 may be sent over IP or using IPsec for secure transport. MIHF entity 125 forwards the remote MIH message received from IMS client 160 to MHPF entity 120. This causes a state update for IMS client 160. The MHPF entity 120 also triggers the MIHF entity 125 to send a remote MIH message. The transfer of MIH messages over IP may be carried out as disclosed in Patent Document 1 filed on May 19, 2006, which was assigned to the assignee of the present application. Incorporate as if fully described in the specification.
IMS client 160 sends an INVITE request to IMS client 170 (ie, the communication peer) to establish a VoIP session (steps 232-236). Note that VoIP is an example and any other service session can be established. If the IMS client 170 accepts the invitation, it sends a 200 OK signal to the IMC client 160 (step 238). The IMS client 160 then sends an ACK to the IMS client 170 (step 239). A VoIP session is then established between IMS client 160 and IMS client 170 (step 240).
The IMS client 160 detects that the signal strength on the cellular interface has deteriorated. MIHF entity 166 sends a signal strength report to MIHF entity 125 on MIH application server 100 (step 242). MIHF entity 125 sends adjacency list information to MIHF entity 166 (step 244). Service policy entity 164 turns on the WLAN interface of IMS client 160, discovers the link based on the adjacency list information, and MIHF entity 166 sends an indication that the WLAN link has been discovered (step 246). MIHF entity 125 sends a command to perform handover to the WLAN to MIHF entity 166 (step 248). Service policy entity 164 completes the handover to the WLAN (eg, dynamic host configuration (DHCP)). Obtaining a new IP address (using protocol)), MIHF entity 166 shows MIHF entity 125 the result of the handover from the cellular network to the WLAN (step 250). The MIH messages exchanged in steps 242 to 250 may be sent over IP or using IPsec for secure transport. MIHF entity 125 forwards remote MIH messages from IMS client 160 to MHPF entity 120.
Service policy entity 164 triggers an update for MIH application server 100 and IMS client 170 (step 252). IMS client 160 sends a REFER request to MIH application server 100 (step 254). A REFER request can be defined in the SIP REFER method of RFC 3535, or the suppression of SIP REFER method implicit subscriptions as found in RFC 4488. SIP interface 115 of MIH application server 100 retrieves the new IP address and unique identifier of the source in the REFER request and sends them to MHPF entity 120, which updates the binding of IMS client 160 ( Step 256). MIH application server 100 sends a 200 OK signal to IMS client 160. SIP stack 162 indicates MIH application server updates to service policy entity 164 (steps 258, 260).
MIH application server 100 sends an INVITE request to IMS client 170 as required by the REFER request (step 262). The IMS client 170 sends a 200 OK signal to the MIH application server 100, and the MIH application server 100 sends an ACK to the IMS client 170 (steps 264, 266). The VoIP session between IMS client 160 and IMS client 170 is restarted with the new IP address of IMS client 160 (step 268). IMS re-registration to the IMS network is then performed (steps 270, 272, 274).
If desired, IMS Client 160 may terminate the MIH session with MIH Application Server 100 by sending a BYE request defined by SIP. If service policy entity 164 decides to terminate the MIH session with the MIH application server, MIHF entity 166 sends a deregistration request to MIHF entity 125 (step 276). MIHF entity 125 sends an event unsubscription request to MIHF entity 166 (step 278). MIHF entity 166 sends an event unsubscription confirmation message to MIHF entity 125 (step 280). MIHF entity 125 sends a deregistration confirmation message to MIHF entity 166 (step 282). The MIH messages from steps 276 to 282 may be sent over IP or using IPsec for secure transport. MHPF entity 120 updates the registration record for IMS client 160. The service policy entity 164 triggers the end of the MIH session with the MIH application server at step 284, and the BYE request is sent to the MIH application server 100 at step 286. The MHPF entity 120 is instructed to end the MIH session (step 288). MHPF entity 120 indicates that the IMS client record update is complete and a 200 OK signal is sent to IMS client 160 (steps 290, 292). The MIH session is then terminated and the termination of the MIH session is indicated in service policy entity 164 (step 294).
3A-3D are exemplary call flows 300 for handover according to another embodiment. In the following, it is assumed that the IMS client 160 is first connected to the cellular access network 150 and performs a handover to the wireless local area network (WLAN) access network 155. Note that the opposite scenario is possible and the handover may be performed between any type of wireless network. The IMS client 160 (eg, WTRU) registers with the IMS network (ie, S-CSCF 145) after discovering the proxy call session control feature (P-CSCF) 140 (step 302). Service policy entity 164 of IMS client 160 initiates a MIH session (step 304). SIP stack 162 on IMS client 160 sends an INVITE request to P-CSCF 140 (step 306). The P-CSCF 140 forwards the INVITE request to the S-CSCF 145 (step 308). S-CSCF 145 downloads the profile of IMS client 160 and triggers the MIH application server based on the filter criteria (step 310), which is described in detail below.
The MIH application server 100 operates in SIP user agent mode. The SIP interface 115 of the MIH application server 100 retrieves the unique identifier and IP address of the IMS client 160 included in the INVITE request and passes them to the MHPF entity 120 (step 312). MHPF entity 120 creates a binding for IMS client 160 and signals SIP interface 115 that the binding is complete (step 314). The binding may include a unique identifier for the IMS client 160 (eg MIHF identifier (ID)), the current IP address of the IMS client 160, and the registration state and the registration timer associated with the registration state, which is detailed below. Explained in.
SIP interface 115 sends a 200 OK message to IMS client 160 via S-CSCF 145 and P-CSCF 140 (step 316). IMS client 160 sends an ACK to MIH application server 100 (step 317). The MIH session is then established and the IMS client 160 and MIH application server 100 may exchange MIH messages directly over IP.
After the MIH session completion is indicated to service policy entity 164 in step 318, service policy entity 164 triggers MIHF entity 166 to send a remote MIH message to MIH application server 100. MIHF entity 166 in IMS client 160 may perform a capability discovery procedure with MIHF entity 125 in MIH application server 100 (steps 320, 322). MIHF entity 166 can also perform MIH registration procedures to register for a particular service (steps 324, 326). MIHF entity 125 may perform an event subscription procedure with MIHF entity 166 (steps 328, 330). The MIH messages exchanged in steps 320-330 may be sent over IP or using IPsec for secure transport. MIHF entity 125 forwards the remote MIH message received from IMS client 160 to MHPF entity 120. This causes a state update for IMS client 160. The MHPF entity 120 also triggers the MIHF entity 125 to send a remote MIH message. The transfer of MIH messages over IP may be carried out as defined in Patent Document 1 filed May 19, 2006, assigned to the assignee of the present application.
IMS client 160 sends an INVITE request to IMS client 170 (ie, the communication peer) to establish a VoIP session (steps 332 to 336). Note that VoIP is an example and any other service session can be established. If the IMS client 170 accepts the invitation, it sends a 200 OK signal to the IMC client 160 (step 338). The IMS client 160 then sends an ACK to the IMS client 170 (step 339). A VoIP session is then established between IMS client 160 and IMS client 170 (step 340).
The IMS client 160 detects that the signal strength on the cellular interface has deteriorated. MIHF entity 166 sends a signal strength report to MIHF entity 125 on MIH application server 100 (step 342). MIHF entity 125 sends adjacency list information to MIHF entity 166 (step 344). Service policy entity 164 turns on the WLAN interface of IMS client 160, discovers the link based on the adjacency list information, and MIHF entity 166 sends an indication that the WLAN link has been discovered (step 346). MIHF entity 125 sends a command to perform handover to the WLAN to MIHF entity 166 (step 348). Service policy entity 164 completes the handover to the WLAN and obtains a new IP address (using DHCP, for example), and MIHF entity 166 shows the result of the handover from the cellular network to the WLAN to MIHF entity 125 (using DHCP). Step 350). The MIH messages exchanged in steps 342-350 may be sent over IP or using IPsec for secure transport. MIHF entity 125 forwards remote MIH messages from IMS client 160 to MHPF entity 120.
Service policy entity 164 triggers an update for MIH application server 100 and IMS client 170 (step 352). IMS client 160 sends a RE-INVITE request to IMS client 170 (step 354). IMS client 160 points to a new IP address and call identifier associated with an ongoing VoIP session. IMS client 170 accepts the RE-INVITE request and sends a 200 OK message to IMS client 160 (step 356). IMS client 160 sends an ACK to IMS client 170 (step 357).
The IMS client 160 then sends a RE-INVITE request to the MIH application server 100 (step 358). The SIP interface 115 of MIH application server 100 retrieves the new IP address and unique identifier of the source in the RE-INVITE request and sends them to MHPF entity 120, which updates the binding of IMS client 160. (Step 360). MHPF entity 120 indicates update completion to SIP interface 115 (step 362). MIH application server 100 to IMS client 160 200 Send an OK signal (step 364). IMS client 160 sends an ACK to MIH application server 100 (step 365). Completion updates for IMA client 170 and MIH application server 100 are shown in service policy entity 164 in step 366, and a VoIP session between IMS client 160 and IMS client 170 uses the new IP address of IMS client 160. Resumed (step 368). IMS re-registration with the IMS network is then performed (steps 370, 372, 374).
If desired, IMS Client 160 may terminate the MIH session with MIH Application Server 100 by sending a BYE request defined by SIP. If service policy entity 164 decides to terminate the MIH session with the MIH application server, MIHF entity 166 sends a deregistration request to MIHF entity 125 (step 376). MIHF entity 125 sends an event unsubscription request to MIHF entity 166 (step 378). MIHF entity 166 sends an event unsubscription confirmation message to MIHF entity 125 (step 380). MIHF entity 125 sends a deregistration confirmation message to MIHF entity 166 (step 382). The MIH messages in steps 376-382 may be sent over IP or using IPsec for secure transport. MHPF entity 120 updates the registration record for IMS client 160. Service policy entity 164 triggers the end of the MIH session with the MIH application server in step 384, and BYE requests are sent to the MIH application server 100 in step 386. The MHPF entity 120 is instructed to end the MIH session (step 288). MHPF entity 120 indicates that the IMS client record update is complete and a 200 OK signal is sent to IMS client 160 (steps 390, 392). The MIH session is then terminated and the termination of the MIH session is indicated in service policy entity 164 (step 394).
The S-CSCF 145 triggers the MIH application server after receiving an INVITE request from the IMS client 160. The INVITE request message body is constructed using the session description protocol (SDP). Multipurpose Internet mail extension (MIME) encoding may be used in the message body. The "s" header of the INVITE request message may contain the constant string "MIH Services" and a unique identifier for the IMS client 160. The unique identifier may be a MIHF ID.
S-CSCF is responsible for the presence of the request method, the destination SIP uniform resource identifier (URI), and a specific string in the body of the INVITE request message (ie the constant string "MIH Services" and a unique identifier). Trigger the MIH application server based on. The request method points to whether the request is an INVITE request message or a REFER request message. The SIP URI, in this case, refers to the URI of the MIH application server. For example, the URI can be ieee802.21@domain.com.
FIG. 4 is an exemplary INVITE request message 400. Message 400 includes an exemplary MIH application server public URI 402 and an s header 404 containing the string "MIH Services" and the unique ID of the IMS client (eg MIHF ID).
FIG. 5 is an exemplary REFER request message 500. Message 500 includes an exemplary public URI 502 of the MIH application server and an s header 504 containing the string "MIH Services" and the unique ID of the IMS client (eg MIHF ID). Message 500 also includes call ID 506 for an ongoing data session with another IMS client 170. The MIH application server 100 uses this when constructing an INVITE request to the IMS client 170.
Figure 6 is an exemplary RE-INVITE request message 600 addressed to the IMS client 170.
FIG. 7 is an exemplary RE-INVITE request message 700 addressed to the MIH application server 100. Message 700 includes an exemplary public URI 702 of the MIH application server and an s header 704 containing the string "MIH Services" and the unique ID of the IMS client (eg MIHF ID).
MIH application server 100 (ie, MHPF entity 120) creates a binding for IMS client 160. The binding includes the unique identifier of the IMS client (eg MIHF ID), the current IP address of the IMS client, and the registration status of the IMS client and the registration timer associated with the registration status. Five registration states (unregistered, MIH registration pending, MIH registered active, MIH registered inactive, and MIH deregistration pending) are defined, and the registration status is to change when the corresponding timer expires. Changes when a specific MIH / SIP message is received.
Figure 8 shows the change of registration status of the IMS client. In the unregistered state, the client has no record in the MIH application server. No timer is associated with the unregistered state.
Upon receiving the initial INVITE request, the status changes to MIH registration pending status. In the MIH registration pending state, the IMS client has created a session but has not performed MIH registration. MIH registration is the process of registering for a particular service negotiated. The MIH registration pending state is associated with timer A. MIH registration must complete within the timer A value, otherwise the MIH application server terminates the session (ie, unregistered). When the status of the IMS client changes to the unregistered state, all relevant user information is deleted. When MIH registration is performed with the timer A value, the state changes to the MIH registered active state.
MIH Registered In the active state, the IMS client has completed MIH registration and communicates with the MIH application server. The registered active state is associated with timer B. If communication is not performed before timer B ends, the state changes to MIH registered inactive state. When a MIH deregistration request is received, the status changes to MIH deregistration pending status.
MIH Registered In the inactive state, the IMS client has completed MIH registration but has not communicated with the MIH application server for a specific period of time. The MIH registered inactivity state is associated with timer C. If there is no communication with the MIH application server before timer C ends, the session ends (ie the state changes to the unregistered state). If a communication other than the registration cancellation request is received before the timer C ends, the status changes to the MIH registered active status. If the deregistration request is received before timer C expires, the state changes to MIH deregistration pending state.
In the MIH deregistration pending state, the IMS client is performing a MIH deregistration and is about to end the session. The deregistration pending state is associated with timer D. SIP BYE messages must be received by the MIH application server within the timer D value. Otherwise, the MIS application server performs a "manual" session termination (ie deletes all records on the IMS client).
Table 1 shows exemplary timer values.
<tables num="1"><img file="JP4875755B2_D0001.tif" /></tables>
Embodiment 1. How to perform a handover.
2. The method of Embodiment 1, which includes the step of registering with the IMS network.
3. The method of Embodiment 2, which includes the step of establishing a MIH session with the MIH application server using SIP.
4. The method according to any one of embodiments 2-3, which comprises the step of establishing an IP-based service session with a communication peer using SIP.
5. The method according to any one of embodiments 2 to 4, which includes a step of detecting the need for handover.
6. The method of Embodiment 5, which includes the step of exchanging MIH messages with the MIH application server over IP for handover.
7. The method of Embodiment 6, which includes the step of performing a handover and resuming the session of the IP-based service.
8. The method according to any one of embodiments 3 to 7, wherein the MIH session is established by sending an INVITE request to the S-CSCF that triggers the MIH application server.
9. The method of Embodiment 8 where the INVITE request contains the string "MIH services" and a unique identifier for the IMS client.
10. The method of embodiment 9 where the unique identifier is a MIHF identifier.
11. The method according to any one of embodiments 2-10, further comprising the step of performing a capability discovery procedure with the MIH application server over IP.
12. The method according to any one of embodiments 3 to 11, further comprising the step of performing the MIH registration procedure with the MIH application server on IP.
13. The method of Embodiment 12, further comprising the step of performing an event subscription procedure with the MIH application server over IP.
14. The method according to any one of embodiments 5-13, further comprising the step of sending a signal strength report to the MIH application server over IP.
15. The method of embodiment 14 comprising the step of receiving adjacency list information from the MIH application server over IP.
16. The method of embodiment 15 comprising the step of sending an adjacent cell signal strength report to the MIH application server over IP.
17. The method of embodiment 16 comprising receiving a handover command from the MIH application server over IP.
18. The method of embodiment 17, which includes the step of sending the handover result to the MIH application server over IP.
19. The REFER request is sent to the MIH application server after the handover using SIP, and the MIH application server sends an INVITE request to the communication peer to resume the session of the IP-based service. Or one of the methods described.
20. The method of embodiment 19 in which the REFER request comprises the string "MIH services" and a unique identifier for the IMS client.
21. The method of embodiment 20 where the unique identifier is a MIHF identifier.
22. The method according to any one of embodiments 7-18, wherein the RE-INVITE request is sent to the MIH application server and communication peer after the handover to resume the session of the IP-based service.
23. The method of embodiment 22 where the RE-INVITE request contains the string "MIH services" and a unique identifier for the IMS client.
24. The method of embodiment 23, where the unique identifier is a MIHF identifier.
25. The method according to any one of embodiments 7-24, further comprising the step of sending a deregistration request to the MIH application server over IP.
26. The method of Embodiment 25, which comprises the step of sending a BYE request for the end of the MIH session to the MIH application server.
27. How to perform a handover.
28. The method of embodiment 27, which comprises the step of receiving an INVITE request from an IMS client via S-CSCF.
29. The method of embodiment 28, which comprises the step of creating a binding for the IMS client.
30. The method of embodiment 29, which comprises the step of establishing a MIH session with an IMS client using SIP.
31. The method of embodiment 30, which comprises the step of exchanging MIH messages with IMS clients over IP for handover.
32. The method of embodiment 31, further comprising the step of sending a handover command to the IMS client.
33. The method of embodiment 32, which comprises the step of receiving the handover result from the IMS client.
34. The method of embodiment 33, further comprising the step of receiving a REFER request from an IMS client.
35. The method of embodiment 34, which includes the step of updating the binding.
36. The method of embodiment 35, which comprises the step of sending an INVITE request to the communication peer as required by the REFER request.
37. The method described in any one of embodiments 34-36, wherein the REFER request comprises the string "MIH services" and a unique identifier for the IMS client.
38. The method of embodiment 37, where the unique identifier is a MIHF identifier.
39. The method according to any one of embodiments 34-36, further comprising the step of receiving a RE-INVITE request from an IMS client.
40. The method of embodiment 39, which comprises the step of updating the binding.
41. The method described in any one of embodiments 39-40, wherein the RE-INVITE request comprises the string "MIH services" and a unique identifier for the IMS client.
42. The method of embodiment 41, where the unique identifier is a MIHF identifier.
43. The method of embodiment 36, wherein the INVITE request comprises the string "MIH services" and a unique identifier for the IMS client.
44. The method of embodiment 43, where the unique identifier is a MIHF identifier.
45. The method according to any one of embodiments 29-44, wherein the registration status and registration timer are maintained by the binding of the IMS client.
46. The method of embodiment 45, wherein the registration status is one of an unregistered status, a registration pending status, a registered active status, a registered inactive status, and a deregistration pending status.
47. WTRU to perform the handover.
48. WTRU of Embodiment 47, which includes an IMS application layer configured to use SIP to establish a session of IP-based services with a communication peer.
49. Of Embodiment 48, which includes a service policy entity configured to use SIP to establish a MIH session with the MIH application server and perform the handover so that the IP-based service session resumes after the handover. WTRU.
50. WTRU of Embodiment 49, which comprises a MIH functional entity configured to exchange MIH messages with a MIH application server over IP.
51. The WTRU according to any one of embodiments 49-50 established by sending an INVITE request to the S-CSCF that triggers the MIH application server.
52. The INVITE request is the WTRU of Embodiment 51 containing the string "MIH services" and a unique identifier for the IMS client.
53. The unique identifier is the MIHF identifier WTRU of embodiment 52.
54. The WTRU according to any one of embodiments 50-53, wherein the MIH functional entity is configured to perform a capability discovery procedure with the MIH application server over IP.
55. The WTRU according to any one of embodiments 50-54, wherein the MIH functional entity is configured to perform a MIH registration procedure with a MIH application server over IP.
56. The WTRU according to any one of embodiments 50-55, wherein the MIH functional entity is configured to perform an event subscription procedure with the MIH application server over IP.
57. The MIH functional entity sends a signal strength report to the MIH application server on the IP, receives adjacency list information from the MIH application server on the IP, sends an adjacency cell signal strength report to the MIH application server on the IP, and sends it on the IP. WTRU according to any one of embodiments 50 to 56 configured to receive a handover command from the MIH application server and send the handover result to the MIH application server on the IP.
58. Of the 49-57 embodiments, the REFER request requesting the MIH application server to send an INVITE request to the communication peer to resume the IP-based service session is sent to the MIH application server after handover using SIP. WTRU described in any one of.
59. The REFER request is the WTRU of embodiment 58 containing the string "MIH services" and a unique identifier for the IMS client.
60. The unique identifier is the MIHF identifier WTRU of embodiment 59.
61. The WTRU according to any one of embodiments 49-57, wherein the RE-INVITE request is sent to the MIH application server and communication peer after handover to resume the session of the IP-based service.
62. The RE-INVITE request is the WTRU of embodiment 61, which includes the string "MIH services" and a unique identifier for the IMS client.
63. The unique identifier is the MIHF identifier WTRU of embodiment 62.
64. MIH application server to support handover.
65. MIH application server of embodiment 64 that includes a SIP interface for receiving INVITE requests from IMS clients via S-CSCF.
66. The MIH application server of embodiment 65 that contains the MHPF entity for creating bindings for the IMS client and establishing a MIH session with the IMS client.
67. The MIH application server of embodiment 66 that includes MIH functional entities for exchanging MIH messages with IMS clients over IP for handover.
68. The MIH application server of embodiment 67, wherein the MIH functional entity is configured to send a handover command to the IMS client and receive the handover result from the IMS client.
69. The MIH application server according to any one of embodiments 66-68, wherein the MHPF entity is configured to update the binding based on a REFER request from an IMS client.
70. The REFER request is the MIH application server of embodiment 69 that contains the string "MIH services" and a unique identifier for the IMS client.
71. The unique identifier is the MIHF identifier MIH application server of embodiment 70.
72. The MIH application server according to any one of embodiments 66-68, wherein the MHPF entity is configured to update the binding based on a RE-INVITE request from an IMS client.
73. The RE-INVITE request is the MIH application server of embodiment 72 that contains the string "MIH services" and a unique identifier for the IMS client.
74. The unique identifier is the MIHF identifier MIH application server of embodiment 73.
75. The INVITE request is the MIH application server of embodiment 65, which contains the string "MIH services" and a unique identifier for the IMS client.
76. The unique identifier is the MIHF identifier MIH application server of embodiment 75.
77. The MIH application server according to any one of embodiments 66-76, wherein the registration status and registration timer are maintained by the binding of the IMS client.
78. The MIH application server of embodiment 77, wherein the registration status is one of the unregistered status, the registration pending status, the registered active status, the registered inactive status, and the deregistration pending status.
The features and elements have been described in specific combinations, but each feature or element may be used alone without other features and elements, or in various combinations with or without other features and elements. May be used in. The methods or flowcharts provided may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or processor. Examples of computer-readable storage media include magnetics such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage, internal hard disks and removable disks. Includes media, magnetic optical media, and optical media such as CD-ROM discs and digital versatile disks (DVDs).
Suitable processors include general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, and one or more microprocessors associated with a DSP core. , Controllers, microprocessors, application specific integrated circuits (ASICs), field programmable gate array (FPGA) circuits, any other type of integrated circuits (ICs) and / Or a state machine is included.
Implements a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or radio frequency transceiver for use with any host computer. Software-related processors may be used to do so. WTRU is a camera, video camera module, videophone, speakerphone, vibrating device, speaker, microphone, TV transceiver, hands-free headset, keyboard, Bluetooth® module, frequency modulated (FM) radio device, Liquid crystal display (LCD) display device, organic light-emitting (OLED) implemented in hardware and / or software, such as display devices, digital music players, media players, video game player modules, internet browsers, and / or any wireless local area network (WLAN) modules. May be used with modules.
15 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15
Every citation, both waysCites: the store holds 3 of 4
| Document | Relation | Office |
|---|---|---|
| WO2006125471A1 | Cites | World Intellectual Property Organization (WIPO) |
| WO2006082861A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP2003526275A | Cites | Japan |
| THIKRAIT AL MOSAWI,VTC-2006 FALL,IEEE,2006年 9月 1日 | Non-patent | – |
| 3GPP TS 24.229 V7.6.0,3GPP,2006年12月12日,P79-85 | Non-patent | – |
| IEEE P802.21/D03.00,2006年12月 1日,P.I-XVIII,1-251 | Non-patent | – |
19 members in 12 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 60885505 | United States of America | – | |
| 88550507 | United States of America | P | |
| 88550507 | United States of America | P | |
| 2008000713 | United States of America | W | |
| 2008000713 | United States of America | W | |
| 2007885505 | – | – | – |
| 2008000713 | – | – | – |
| US20070885505P | – | – | – |
| WO2008US00713 | – | – | – |
Members19
| Document | Office | Kind | |
|---|---|---|---|
| AU2008205486A1 | Australia | A1 | |
| CA2675843A1 | Canada | A1 | |
| US2008175253A1 | United States of America | A1 | |
| WO2008088891A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2008088891A3 | World Intellectual Property Organization (WIPO) | A3 | |
| MX2009007724A | Mexico | A | |
| MX2009007724A | Mexico | A | |
| KR20090110925A | Republic of Korea | A | |
| KR20090113294A | Republic of Korea | A | |
| EP2122989A2 | European Patent Office (EPO) | A2 | |
| CN101637001A | China | A | |
| IL199948A0 | Israel | A0 | |
| JP2010517369A | Japan | A | |
| AU2008205486B2 | Australia | B2 | |
| RU2009131318A | Russian Federation | A | |
| RU2420904C2 | Russian Federation | C2 | |
| BRPI0806208A2 | Brazil | A2 | |
| JP4875755B2This record | Japan | B2 | |
| US8134955B2 | United States of America | B2 |
10 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 |
Numbers
- Publication
- 4875755
- Publication, DOCDB
- 4875755
- Publication, EPODOC
- JP4875755B
- Application
- 2009546435
- Application, DOCDB
- 2009546435
- Application, EPODOC
- JP20090546435
Titles2
- Japanese
- メディア独立ハンドオーバのための方法および装置
- English
- Methods and equipment for media independent handover
Classification
- CPC, 9
- H04W36/005
- H04W36/0011
- H04W80/10
- H04L65/1016
- H04L65/1083
- H04L65/1095
- H04W36/144
- H04W36/00226
- H04W36/0066
- IPC, 4
- H04W36 14
- H04W36 30
- H04W36 38
- H04W80 10
