Method and apparatus for media independent handover

(54) Title: INDEPENDENT MEDIA DELIVERY METHOD AND APPARATUS (30) Unionist Priority: 18/01/2007 us 60 / 885,505 (73) Holder (s): Interdigital Technology Corporation (72) Inventor (s): Mahmoud Watfa, Shamim Akbar Rahman, Ulises Olvera-Hernandéz (74) Attorney (s): Advocacia Pietro Ariboni S / C (86) International Request: pct US2008000713 of 17/01/2008 (87) International Publication: wo 2008/088891 of 24/07 / 2008 (57) Abstract: delivery method and apparatus INDEPENDENTLY OF MEDIA. A delivery method and apparatus is described. An Internet Protocol (IP) multimedia subsystem (IMS) client registers with an IMS network and establishes a media independent delivery (MIH) session with an MIH application server using a login protocol (SIP) ). The IMS client establishes an IP-based service session (such as voice over IP (VolP)) with a communication partner using a SIP. MIH messages are exchanged for delivery to the MIH application server via IP. After delivery, the session is resumed. An in-service call session control (S-CSCF) function triggers the MIH application server based on a set of MIH services and a unique identifier included in an INVITATION request. The IMS client can send a REFERENCE request to the MIH application server after delivery to resume the session. Alternatively, the IMS client can send a NEW INVITATION request to the MIH application server and the communication partner.

<img file="BRPI0806208A2_D0001.tif" />

1/17

I 0 ^ 0 - ο&gt; Λ &lt;? ⁴ ^ 03 CQ HoG Ιο

Delivery method and apparatus independent of means.

FIELD OF THE INVENTION

The present invention relates to an independent delivery of media between heterogeneous wireless networks.

BACKGROUND

Internet Protocol (IP) Multimedia Subsystem (IMS) is a new generation network formation architecture (NGN) standardized for the provision of fixed and mobile multimedia services. IMS uses a login protocol (SIP) and is conducted over IP. IMS can be used for many different services (such as instant messaging, video streaming, voice over IP (VolP) and any other IP based service).

The purpose of IMS is to provide all services, current and future, provided over the Internet. One of the methods used to provide these services is through an IMS application server. The IMS application server is a network entity that hosts and runs one or more IP services. An application server is triggered to provide a service through a call-in-service session control function (S-CSCF) which is a central node in the IMS signaling plan.

The IEEE 802.21 standard defines mechanisms and procedures that assist in the execution and administration of deliveries between systems. Based on IEEE 802.21, three main services can be accessed through mobility management applications to assist in the administration of delivery and discovery operations and system selection. These services include an event service, an information service and a command service. These services do not depend on each other and, as a result, can be provided independently.

Currently, there are no interfaces or mechanisms that describe how IEEE 802.21 services can interact with the existing mobility delivery and management functionality already defined in the relevant third generation partnership project (3GPP) or similar wireless standard specifications. There are no procedures or functionality to integrate IEEE 802.21 services within 3GPP or other wireless standards, unless existing delivery procedures and mobility management mechanisms are modified. Therefore, an MIH application server that is capable of integrating MIH services into a 3GPP or other networks based on wireless standards is required.

SUMMARY OF THE INVENTION

A delivery method and apparatus are described. An IMS client registers with an IMS network and establishes an MIH session with an MIH application server using a SIP. The IMS client

2/17 establishes a session for IP-based service (such as VolP) with a communication partner using a SIP. MIH messages are exchanged for delivery to the MIH application server via IP. After delivery, the session is resumed. An S-CSCF triggers the MIH application server based on a set of “MIH services” and a unique identifier included in an INVITATION request. The IMS client can send a REFERENCE request to the MIH application server after delivery to resume the session. Alternatively, the IMS client can send a NEW INVITATION request to the MIH application server and the communication partner.

BRIEF DESCRIPTION OF THE FIGURES

A more detailed understanding can be obtained from the following description, provided as an example and to be understood together with the attached figures, in which:

Figure 1 is a block diagram of an MIH application server;

Figures 2A to 2D are an example of a call flow for delivery according to an embodiment;

Figures 3A to 3D are an example of a call flow for delivery according to another embodiment;

- Figure 4 is an example of an INVITATION request message;

- Figure 5 is an example of a REFERENCE request message;

- Figure 6 is an example of a NEW INVITATION request message for an IMS client;

- Figure 7 is an example of a NEW INVITATION request message destined for an MIH application server; and, 25 - Figure 8 is a change in the registration status of the IMS client.

DETAILED DESCRIPTION

When indicated below, the terminology “wireless transmission and reception unit (WTRU)” includes, but is not limited to, user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cell phone, personal digital assistant (PDA), computer or any other type of user device capable of operating in a wireless environment.

It should be noted that achievements with reference to VolP services will be explained as an example and the achievements are applicable to any other service (such as instant messaging, video streaming or any other IP-based service) that involves the establishing a session.

Figure 1 is a block diagram of an MIH 100 application server. The MIH 100 application server includes an MIH function entity (MIHF) 105, an interworking function interface (IWF) 110, an

3/17 SIP interface 115, a delivery and mobility policy function entity (MHPF) 120, an upper layer transport unit (such as based on IP) 125 and an L2 transport unit (such as based on in IEEE 802.xx) 130. The MIH 100 application server facilitates seamless integration of IP functions to and from an IMS client (such as a WTRU) over any IMS-capable network across the unit. top layer transport 125. The MIH 100 application server facilitates seamless integration of IEEE 802.xx functions to and from the IMS client through an 802.xx access network via the L2 130 transport unit. The MIH application server 100 also supports SIP signaling and interfaces with an S-CSCF on the IMS network through the SIP 115 interface.

The MIHF entity 105 receives MIH messages (ie, MIH information and events) via the upper layer transport unit 125 (such as by means of IP) and / or the transport unit L2 130 (such as the

IEEE 802.xx). The MIHF entity 105 sends the MIH message (i.e., MIH command, information and events) via the upper layer transport unit 125 or the transport unit L2 130 in response to the MIH messages. The MIHF 105 entity may also emit events that signal to the MHPF 120 entity (such as changing the current state of the link layer technology that sustains the session) or to the IWF 110 entity (indicating, for example, the successful completion of a delivery).

The IWF 110 interface translates the SIP messages received via the SIP interface 115 into MIH messages and vice versa. The IWF 110 interface receives events from the MIHF 105 entity, SIP signaling from the SIP 115 interface and commands from the MHPF 120 entity and translates them into MIH or SIP signaling.

The MHPF entity 120 dynamically determines the specific behavior and mapping of SIP messages to MIH messages and vice versa. The MHPF 120 entity controls deliveries across heterogeneous networks. The MHPF entity 120 receives SIP delivery and signaling events and issues SIP call control delivery and signaling commands.

The SIP 115 interface receives commands from the MHPF 120 entity for session control purposes and can also receive events from the MIHF 120 entity via the IWF 110 interface. The SIP 115 interface issues SIP signaling for control purposes. session and call.

Figures 2A to 2D are an example of a call flow 200 for delivery as an embodiment. Next, it is considered that an IMS 160 client is initially connected to a cellular access network 150 and performs a

4/17 delivery to a wireless local area network (WLAN) access network 155. It should be noted that the opposite scenario is also possible and delivery can be implemented between any types of wireless networks. The IMS 160 client (such as WTRU) registers with an IMS network (i.e., S-CSCF 145), after the discovery of a proxy call session control function (P-CSCF) 140 (step 202). An IMS client service policy entity 164 initiates an MIH session (step 204). The IMS 160 client's SIP 162 stack sends an INVITATION request to P-CSCF 140 (step 206). P-CSCF 140 forwards the INVITATION request to S-CSCF 145 (step 208). The S-CSCFC 145 downloads an IMS 160 client profile and starts an MIH application server based on filtering criteria (step 210), which will be explained in detail below.

The MIH 100 application server works in a SIP user agent mode. The SIP interface 115 of the MIH 100 application server obtains a unique identifier and an IP address from the IMS 160 client included in the INVITATION request and passes them to the MHPF 120 entity (step 212). The MHPF entity 120 creates a union for the IMS 160 client and indicates a termination of union for the SIP interface 115 (step 214). The union can include an IMS 160 client unique identifier (such as MIHF identity (ID)), an IMS 160 client current IP address and a registration state and registration timer associated with the registration state, which will be explained in detail below.

The SIP 115 interface transmits an OK 200 message to the IMS 160 client via S-CSCF 145 and P-CSCF 140 (step 216). The IMS 160 client sends an acknowledgment (ACK) to the MIH 100 application server (step 217). An MIH session is then established and the IMS 160 client and the MIH 100 application server can exchange MIH messages directly via 'IP.

After indicating the end of MIH sessions for service policy entity 164 in step 218, service policy entity 164 triggers MIHF entity 166 to send remote MIH messages to the MIH 100 application server. The MIHF entity 166 on the IMS 160 client can perform a capacity discovery procedure with the MIHF entity 125 on the MIH 100 application server (steps 220, 222). The MIHF 166 entity may also perform an MIH registration procedure to register specific services (steps 224, 226). The MIHF entity 125 can perform an event subscription procedure with the MIHF entity 166 (steps 228, 230). The MIH messages exchanged in steps 220 to 230 can be transmitted over IP and can be transmitted using IPsec for secure transport. MIHF entity 125 forwards remote MIH messages received from the IMS 160 client to the MHPF entity

5/17

120. This causes status updates for the IMS 160 client. The MHPF entity 120 also triggers the MIHF entity 125 to send remote MIH messages. The transport of MIH messages via IP can be carried out as described in Commonly assigned US Patent Application No. 60 / 801,786, filed on May 19, 2006, which is incorporated by reference as if fully described.

The IMS 160 client sends an INVITATION request to an IMS 170 client (ie, a communication partner) to establish a VolP session (steps 232 to 236). It should be noted that VolP is an example and any other service session can be established. If the IMS 170 client accepts the invitation, the IMS 170 client sends an OK 200 signal to the IMC 160 client (step 238). The IMS 160 client then sends an ACK to the IMS 170 client (step 239). A VolP session between the IMS 160 client and the IMS 170 client is then established (step 240).

The IMS 160 client detects that a signal strength over the cellular interface is degrading. MIHF entity 166 sends a signal strength report to MIHF entity 125 of the MIH 100 application server (step 242). MIHF entity 125 sends information from neighboring lists to MIHF entity 166 (step 244). Service policy entity 164 turns over an IMS 160 client's WLAN interface and detects a link based on neighbor list information and MIHF entity 166 sends an indication that a WLAN link has been detected (step 246). MIHF entity 125 sends a command to MIHF entity 166 to perform delivery to the WLAN (step 248). Service policy entity 164 completes a delivery to the WLAN and obtains a new IP address (using, for example, a dynamic host configuration protocol (DHCP)) and the MIHF entity 166 indicates the delivery result of the network from cell phone to WLAN to MIHF 125 entity (step 250). The MlIH messages exchanged in steps 242 to 250 can be transmitted via IP and can be transmitted using IPsec for secure transport. The MIHF entity 125 forwards the remote MIH messages from the IMS client 160 to the MHPF entity 120.

Service policy entity 164 triggers the update of the MIH 100 application server and IMS 170 client (step 252). The IMS 160 client sends a REFERENCE request to the MIH 100 application server (step 254). The REFERENCE request can be defined in the SIP REFERENCE method of RFC 3535 or the suppression of the implicit signature of the SIP REFERENCE method, as per RFC 4488. The MIH 100 application server's SIP 115 interface removes the new IP address and unique source identifier in the request

6/17

REFERENCE and sends them to the MHPF 120 entity, which updates the union for the IMS 160 client (step 256). The MIH application server 100 sends an OK 200 signal to the IMS client 160. The SIP stack 162 indicates update from the MIH application server to service policy entity 164 (steps 258, 260).

The MIH 100 application server sends an INVITATION request to the IMS 170 client as requested in the REFERENCE request (step 262). The IMS 170 client sends an OK 200 signal to the MIH 100 application server and the MIH 100 application server sends an ACK to the IMS 170 client (steps 264, 266). The VolP session between the IMS 160 client and the IMS 170 client is resumed using a new IMS 160 client IP address (step 268). The new IMS registration is then performed with the IMS network (steps 270, 272, 274).

If necessary, the IMS 160 client can end the MIH session with the MIH 100 application server by sending a GOODBYE request as defined via SIP. If service policy entity 164 decides to end the MIH session with the server of MIH applications, MIHF entity 166 sends a de-registration request to MIHF entity 125 (step 276). MIHF entity 125 sends an event subscription cancellation request to MIHF entity 166 (step 278). MIHF entity 166 sends a confirmation event unsubscribe message to MIHF entity 125 (step 280). MIHF entity 125 sends a confirmation unregister message to MIHF entity 166 (step 282). MIH messages in steps 276 to 282 can be sent over an IP and can be sent using IPsec for secure transport. The MHPF entity 120 updates the record for the IMS client 160. The service policy entity 164 triggers the termination of the MIH session with the application server in step 284 and a ADEUS request is sent to the MIH application server 100 in step 286. The MHPF 120 entity is indicated to end the MIH session (step 288). The MHPF entity 120 indicates that the IMS client registry update has finished and an OK 200 signal is sent to the IMS client 160 (steps 290, 292). The MIH session then ends and an end of the MIH session is indicated for service policy entity 164 (step 294).

Figures 3A to 3D are an example of call flow 300 for delivery according to another embodiment. Next, it is considered that an IMS 160 client is initially connected to a cellular access network 150 and delivers to a wireless local area network (WLAN) access network 155. It is observed that the opposite scenario also it is possible and delivery can be implemented between any type of wireless network. The IMS 160 client (such as WTRU) registers with an IMS network (ie S-CSCF 145), after the discovery of a control function

7/17 session of proxy calls (P-CSCF) 140 (step 302). An IMS 160 customer service policy entity 164 initiates an MIH session (step 304). The SIP stack 162 of the IMS 160 client sends an INVITATION request to the C-CSCF 140 (step 306). P-CSCF 140 forwards the INVITATION request to S-CSCF 145 (step 308). The S-CSCF 145 downloads an IMS 160 client profile and starts an MIH application server based on filtering criteria (step 310), which will be explained in detail below.

The MIH 100 application server works in a SIP user agent mode. The SIP 115 interface of the MIH 100 application server obtains a unique identifier and an IP address from the IMS 160 client included in the INVITATION request and passes them to the MHPF 120 entity (step 312). The MHPF entity 120 creates a union for the IMS 160 client and indicates the end of the union for the SIP 115 interface (step 314). The union can include a unique IMS 160 client identifier (such as MIHF ID), a current IMS 160 client IP address and a registration state and registration timer associated with the registration state, which will be explained in details below.

The SIP 115 interface transmits an OK 200 message to the IMS 160 client via S-CSCF 145 and P-CSCF 140 (step 316). The IMS 160 client sends an ACK to the MIH 100 application server (step 317). An MIH session is then established and the IMS 160 client and the MIH 100 application server can exchange MIH messages directly via IP.

After indicating the end of the MIH session for service policy entity 164 in step 318, service policy entity 164 triggers MIHF entity 166 to send remote MIH messages to the MIH 100 application server The MIHF entity 166 on the IMS 160 client can perform a capability discovery procedure with the MIHF entity 125 on the MIH application server (steps 320, 322). The MIHF 166 entity may also perform an MIH registration procedure for registering specific services (steps 324, 326). The MIHF entity 125 can perform an event subscription procedure with the MIHF entity 166 (steps 328, 330). The MIH messages exchanged in steps 320 to 330 can be transmitted over IP and can be transmitted using IPsec for secure transport. The MIIHF 125 entity routes remote MIH messages received from the IMS 160 client to the MHPF 120 entity. This causes status updates to the IMS 160 client. The MHPF 120 entity also triggers the MIHF 125 entity to send remote MIH messages. The transport of MIH messages over IP can be carried out as defined in US Patent Application No. 60 / 801,786 assigned in common, filed on May 19, 2006.

8/17

The IMS 160 client sends an INVITATION request to an IMS 170 client (ie, communication partner) to establish a VolP session (steps 332 to 336). It should be noted that VolP is an example and another service session can be established. If the IMS 170 client accepts the invitation, the IMS 170 client sends an OK 200 signal to the IMC 160 client (step 338). The IMS 160 client then sends an ACK to the IMS 170 client (step 339). A VolP session is then established between the IMS 160 client and the IMS 170 client (step 340).

The IMS 160 client detects that a signal strength over the cellular interface is degrading. MIHF entity 166 sends a signal strength report to MIHF entity 125 of the MIH 100 application server (step 342). MIHF entity 125 sends neighbor list information to MIHF entity 166 (step 344). The service policy entity 164 turns on a WI.AN interface of the IMS client 160 and detects a link based on the neighbor list information and the MIHF entity 166 sends an indication that a WLAN link has been detected (step 346). MIHF entity 125 sends a command to MIHF entity 166 to deliver to the WLAN (step 348). Service policy entity 164 completes a delivery to the WLAN and obtains a new IP address (such as using a DHCP) and the MIHF entity 166 indicates the result of delivering the cellular network to the WLAN to the MIHF entity 125 (step 350). MIH messages exchanged in steps 342 to 350 can be transmitted over IP and can be transmitted using IPsec for secure transport. The MIHF entity 125 forwards the MIH messages from the IMS client 160 to the MHPF entity 120.

Service policy entity 164 triggers the update of the MIH 100 application server and IMS 170 client (step 352). The IMS 160 client sends a NEW INVITATION request to the IMS 170 client (step 354). The IMS 160 client indicates the new IP address and the caller ID for the current VolP session. The IMS 170 client accepts the NEW INVITATION request and sends an OK 200 message to the IMS 160 client (step 356). The IMS 160 client sends an ACK to the IMS 170 client (step 357).

The IMS 160 client then sends a NEW INVITATION request to the MIH 100 application server (step 358). The MIH 100 application server's SIP 115 interface obtains the new IP address and unique source identifier in the NEW INVITATION request and sends them to the MHPF 120 entity, which updates the union for the IMS 160 client (step 360) . The MHPF entity 120 indicates the complete update of the SIP 115 interface (step 362). The MIH 100 application server sends an OK 200 signal to the IMS client

9/17

160 (step 364). The IMS 160 client sends an ACK to the MIH 100 application server (step 365). The update of the IMA 170 client and MIH 100 application server termination is indicated for service policy entity 164 in step 366 and the VolP session between the IMS 160 client and the IMS 170 client is resumed using the new IP address of the IMS 160 client (step 368). The new IMS registration is then performed with the IMS network (steps 370, 372, 374).

If necessary, the IMS 160 client can end the MIH session with the MIH 100 application server by sending a Goodbye request as defined by SIP. If service policy entity 164 decides to end the MIH session with the MIH application server, MIHF entity 166 sends a de-registration request to MIHF entity 125 (step 376). MIHF entity 125 sends an event subscription cancellation request to MIHF entity 166 (step 378). MIHF entity 166 sends a confirmation event unsubscribe message to MIHF entity 125 (step 380). MIHF entity 125 sends an acknowledgment withdrawal message to MIHF entity 166 (step 382). MIH messages in steps 376 to 382 can be sent over IP and can be sent using IPsec for secure transport. The MHPF entity 120 updates the record for the IMS client 160. The service policy entity 164 triggers the end of the MIH session with the MIH application server in step 384 and a ADEUS request is sent to the application server of MIH 100 in step 386. It is indicated for the entity of MHPF 120 that ends the MIH session (step 288). The MHPF entity 120 indicates that the IMS client record update has finished and an OK 200 signal is sent to the IMS client 160 (steps 390, 392). The MIH session ends and the MIH session ends for service policy entity 164 (step 394).

The S-CSCF 145 triggers the MIH application server after receiving the INVITE request from the IMS 160 client. The message body of the INVITE request is constructed using a session description protocol (SDP). The encryption of multi-purpose Internet mail extensions (MIME) can be used for the message body. In an “s” header of the INVITATION request message, a constant set of “MIH Services” and a unique identifier for the IMS 160 client can be included. The unique identifier can be an MIHF ID.

S-CSCF triggers the MIH application server based on the request method, a target SIP uniform resource identifier (URI) and an existence of the specific set (that is, the MIH Services constant set and the unique identifier ) in the INVITATION request message body. O

10/17 request method indicates whether the request is an INVITATION request message or a REFERENCE request message. The SIP URI designates the URI for the MIH application service in this case. The URI can be, for example, ieee802.21 @ domain.com.

Figure 4 is an example of an INVITATION 400 request message. Message 400 includes an example of a MIH 402 application server public URI and a 404 s header that includes the “MIH Services” set and a unique customer ID for IMS (such as MIHF ID).

Figure 5 is an example of a REFERENCE 500 request message. Message 500 includes an example of a MIH application server public URI 502 and an s 504 header that includes the set “MIH Services and a unique IMS client ID. (such as MIHF ID). Message 500 also includes a caller ID 506 of the data session in progress with the other IMS 170 client. The MIH 100 application server uses this in building the INVITE request to the IMS 170 client.

Figure 6 is an example of the NEW INVITATION 600 request message for an IMS 170 customer.

Figure 7 is an example of the NEW INVITATION 700 request message for an MIH 100 application server. Message 700 includes an example of a MIH 702 application server public URI and an s 704 header that includes the “Services MIH ID ”and a unique IMS client ID (such as MIHF ID).

The MIH 100 application server (that is, the MHPF entity 120) creates a union for an IMS 160 client. The union includes a unique identifier for the IMS client (such as MIHF ID), a current client IP address IMS client registration status and a registration timer associated with the registration state. Five registration states are defined (unregistered, pending MIH registration, registered and activated MIH, registered and inactive MIH and pending MIH registration cancellation) and the registration status is changed if the corresponding timer expires or if it is received an MIH / SIP message specifies instructing its change.

Figure 8 is a record of IMS client state changes. In the unregistered state, the client has no record on the MIH application server. No timer is associated with the unregistered state.

Upon receipt of an initial INVITATION request, the status changes to the pending MIH registration status. In the pending MIH registration state, the IMS client created a session but did not perform the MIH registration. MIH registration is a process for registering negotiated services

11/17 specific. The pending MIH registration status is associated with timer A. The MIH registration must end within a value of timer A; otherwise, the MIH application server ends the session (that is, unregistered state). If the IMS client state is changed to the unregistered state, all related user information is deleted. If the MIH registration is performed with timer value A, the state is changed to the registered and active MIH state.

In the registered and active MIH state, the IMS client terminates the MIH registration and communicates with the MIH application server. The registered and active state is associated with timer B. If there is no communication before the end of timer B, the state is changed to the registered and inactive MIH state. If an MIH deregistration request is received, the status changes to the pending MIH deregistration status.

In the registered and inactive MIH state, the IMS client terminated the MIH registration, but did not maintain communication with the MIH application server for a specific period of time. The registered and inactive MIH state is associated with timer C. The session ends if no communication with the MIH application server occurs before the end of timer C (that is, the state changes to the unregistered state). If communication other than a deregistration request is received prior to the end of timer C, the status is changed to the registered and active MIH state. If a deregistration request is received before the end of timer C, the status changes to the pending MIH deregistration status.

In the pending MIH deregistration state, the IMS client performed the deregistration of MIH and the session is about to end. The pending deregistration state is associated with timer D. A goodbye SIP message must be received by the MIH application server within a timer value D; otherwise, the MIS application server performs a manual session termination (that is, it removes all records from the IMS client).

Table 1 shows examples of timer values.

Table 1

<td>Registration status</td><td>Associated timer</td><td>Example value of timer</td>

<td>Not registered</td><td>none</td><td>none</td>

<td>Pending MIH registration</td><td>Timer A</td><td>10 seconds</td>

<td>MIH registered and active</td><td>Timer B</td><td>3000 seconds</td>

<td>MIH registered and inactive</td><td>Timer C</td><td>2000 seconds</td>

12/17

<td>Pending MIH registration cancellation</td><td>Timer C</td><td>10 seconds</td>

ACHIEVEMENTS

1. Method of making a delivery.

2. Method according to realization 1, which includes registration with an IMS network.

3. Method according to realization 2, which comprises the establishment of an MIH session with an MIH application server using a SIP.

4. Method according to any of the achievements 2 or 3, which includes the establishment of a session for IP-based service with a communication partner using a SIP.

5. Method according to any of the realizations 2 to 4, which includes the detection of a delivery need.

6. Method according to realization 5, which comprises the exchange of an MIH message for a delivery with the MIH application server via IP.

7. Method according to realization 6, which includes the delivery and resumption of the session for IP-based service.

8. Method according to any of the realizations 3 to 7, in which the MIH session is established by sending an INVITATION request to an S-CSCF, which triggers the MIH application server.

9. Method according to realization 8, in which the INVITATION request includes a set of “MIH services” and a unique identifier for an IMS client.

10. Method according to realization 9, in which the unique identifier is an MIHF identifier.

11. Method according to any of the achievements 2 to 10, which additionally includes the performance of a procedure for discovering capabilities with the MIH application server through IP.

12. Method according to any of the realizations 3 to 11, which additionally includes the accomplishment of an MIH registration procedure with the MIH application server through IP.

13. Method according to realization 12, which additionally includes the execution of an event subscription procedure with the MIH application server through IP.

14. Method according to any of the realizations 5 to 13, which additionally includes sending a signal strength report to the MIH application server via IP.

15. Method according to realization 14, which includes receiving information from the list of neighbors of the MIH application server through IP.

16. Method according to realization 15, which includes sending a report of

13/17 neighbor cell signal strength to the MIH application server via IP.

17. Method according to realization 16, which comprises the receipt of a delivery command from the MIH application server through IP.

18. Method according to realization 17, which includes sending a delivery result to the MIH application server via IP.

19. Method according to any of the achievements 7 to 18, in which a request

REFERENCE is sent to the MIH application server after delivery using SIP and the MIH application server sends an INVITATION request to the communication partner to resume the IP-based service session.

20. Method according to realization 19, in which the REFERENCE request includes a set of “MIH services” and a unique identifier for an IMS client.

21. Method according to realization 20, in which the unique identifier is an MIHF identifier.

22. Method according to any of the accomplishments 7 to 18, in a NEW INVITATION request, it is sent to the MIH application server and the communication partner after delivery to resume the IP-based service session.

23. Method according to realization 22, in which the NEW INVITATION request includes a set of “MIH services” and a unique identifier for an IMS client.

24. Method according to realization 23, in which the unique identifier is an MIHF identifier.

25. Method according to any of the achievements 7 to 24, which additionally includes the sending of an unregister request to the MIH application server via IP.

26. Method according to realization 25, which includes sending a ADEUS request to the MIH application server to end the MIH session.

27. Method of making a delivery.

28. Method according to realization 27, which comprises the receipt of an INVITATION request from an IMS client through S-CSCF.

29. Method according to realization 28, which includes the creation of a union for the IMS client.

30. Method according to realization 29, which comprises the establishment of an MIH session with the IMS client using SIP.

31. Method according to realization 30, which comprises the exchange of a message of

MIH for delivery to the IMS client via IP.

32. Method according to realization 31, which additionally includes sending a delivery command to the IMS customer.

33. Method according to realization 32, which comprises the receipt of a delivery result from the IMS client.

14/17

34. Method according to realization 33, which additionally includes the receipt of a REFERENCE request from the IMS client.

35. Method according to realization 34, which includes updating the union.

36. Method according to achievement 35, which includes sending a request

INVITATION to a communication partner as requested in the REFERENCE request.

37. Method according to any of the achievements 34 to 36, in which the REFERENCE request includes a set of “MIH services” and a unique IMS identifier.

38. Method according to realization 37, in which the unique identifier is an MIHF identifier.

39. Method according to any of the achievements 34 to 36, which additionally includes the receipt of a NEW INVITATION request from the IMS client.

40. Method according to realization 39, which includes updating the union.

41. Method according to any of the realizations 39 or 40, in which the NEW INVITATION request includes a set of "MIH services" and a unique identifier of an IMS client.

42. Method according to realization 41, in which the unique identifier is an MIHF identifier.

43. Method according to realization 36, in which the INVITATION request includes a set of “MIH services” and a unique identifier for an IMS client.

44. Method according to realization 43, in which the unique identifier is an MIHF identifier.

45. Method according to any of the achievements 29 to 44, in which a registration state and a registration timer are kept in union for the IMS client.

46. Method according to realization 45, in which the registration status is one among an unregistered state, registration pending state, registered and active state, registered and inactive state and a pending unregistration state.

47. WTRU to carry out a delivery.

48. WTRU according to realization 47, which comprises an IMS application layer configured to establish an IP-based service session with a communication partner using a SIP.

49. WTRU as per realization 48, which comprises a service policy entity configured to establish an MIH session with an MIH application server using a SIP and perform a delivery so that the IP-based service session is resumed after delivery .

50. WTRU as per embodiment 49, which comprises an MIH function entity configured to exchange an MIH message with the MIH application server via IP.

15/17

51. WTRU according to any of the 49 or 50 achievements, in which the MIH session is established by sending an INVITATION request to an S-CSCF, which triggers the MIH application server.

52. WTRU according to realization 51, in which the INVITATION request includes a set of “MIH services” and a unique identifier for an IMS client.

53. WTRU as per realization 52, where the unique identifier is an MIHF identifier.

54. WTRU according to any of the realizations 50 to 53, in which the MIH role entity is configured to perform a capability discovery procedure with the MIH application server via IP.

55. WTRU according to any of the realizations 50 to 54, in which the MIH function entity is configured to perform an MIH registration procedure with the MIH application server via IP.

56. WTRU according to any of the realizations 50 to 55, in which the MIH role entity is configured to perform an event subscription procedure with the MIH application server via IP.

57. WTRU according to any of the realizations 50 to 56, in which the MIH function entity is configured to send a signal strength report to the MIH application server via IP, receive neighbor list information from the application server from MIH over IP, send a signal strength report from neighboring cells to the MIH application server over IP, receive a delivery command from the MIH application server via P and send a delivery result to the MIH application server via IP.

58. WTRU according to any of the realizations 49 to 57, in which a REFERENCE request is sent to the MIH application server after delivery using a SIP that requests the MIH application server to send an INVITE request to the communication partner to resume the IP-based service session.

59. WTRU according to realization 58, in which the REFERENCE request includes a set of “MIH services” and a unique identifier for an IMS client.

60. WTRU as per realization 59, where the unique identifier is an MIHF identifier.

61. WTRU according to any of the realizations 49 to 57, in which a NEW INVITATION request is sent to the MIH application server and the communication partner after delivery to resume the IP-based service session.

62. WTRU according to realization 61, in which the NEW INVITATION request includes a set of “MIH services” and a unique identifier for an IMS client.

63. WTRU according to realization 62, where the unique identifier is an identifier

16/17 MIHF.

64. MIH application server to support delivery.

65. MIH application server as per 64, which comprises a SIP interface to receive an INVITE request from an IMS client via S-CSCF.

66. MIH application server as per 65, which comprises an MHPF entity to create a union for the IMS client and establish an MIH session with the IMS client.

67. MIH application server as per embodiment 66, which comprises an MIH function entity for exchanging an MIH message for a delivery with the IMS client via IP.

68. MIH application server as per realization 67, in which the MIH role entity is configured to send a delivery command to the IMS client and receive a delivery result from the IMS client.

69. MIH application server according to any of the realizations 66 to 68, where the MHPF entity is configured to update the union based on a REFERENCE request from the IMS client.

70. MIH application server as per implementation 69, in which the REFERENCE request includes a set of “MIH services” and a unique identifier for an IMS client.

71. MIH application server as per realization 70, where the unique identifier is an MIHF identifier.

72. MIH application server according to any of the realizations 66 to 68, where the MHPF entity is configured to update the union based on a request

NEW IMS client INVITATION.

73. MIH application server as per implementation 72, in which the NEW INVITATION request includes a set “MIH services and a unique identifier for an IMS client.

74. MIH application server as per realization 73, where the unique identifier 30 is an MIHF identifier.

75. MIH application server as per realization 65, where the request

INVITATION includes a set of “MIH services” and a unique identifier for an IMS client.

76. MIH application server as per realization 75, where the unique identifier 35 is an MIHF identifier.

77. MIH application server according to any of the realizations 66 to 76, in which a registration state and registration timer are kept in union for the IMS client.

17/17

78. MIH application server as per realization 77, in which the registration state is one of an unregistered state, registration pending state, registered and active state, registered and inactive state and pending unregistered state.

Although the characteristics and elements are described in specific combinations, each characteristic or element can be used alone, without the other characteristics and elements or in various combinations with or without other characteristics and elements. The methods or flowcharts provided can be implemented in a computer program, software or firmware in tangible realization on a computer-readable storage medium for execution by a general purpose computer or processor. Examples of computer-readable storage media include read-only memory (ROM), random access memory (RAM), registry, cache memory, semiconductor memory devices, magnetic media such as internal hard drives and removable disks, magnetotic media and optical media such as CD-ROM discs and digital versatile discs (DVDs).

Suitable processors include, for example, a general purpose processor, special purpose processor, conventional processor, digital signal processor (DSP), a series of microprocessors, one or more microprocessors in association with a DSP core, controller, microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Portal Sets (FPGAs), any other type of integrated circuit (IC) and / or state machine.

A processor in association with software can be used to implement a radio frequency transceiver for use in a wireless transmission and reception unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC) ) or any host computer. The WTRU can be used in conjunction with modules, implemented in hardware and / or software, such as a camera, video camera module, videophone, headset, vibrating device, speaker, microphone, television transceiver, headset handsfree headset, keyboard, Bluetooth® module, frequency modulated radio (FM) unit, liquid crystal display (LCD) unit, organic light-emitting diode (OLED) unit, digital music device, media player, video game module, Internet browser and / or any wireless local area network (WLAN) module.

1/4