Patent Application
20050007984
The present invention generally relates to internet multimedia subsystems, and more particularly to a method and architecture for accessing internet protocol multimedia subsystems (IMSs) in a wireless local area network.
The architecture for accessing an IMS in regular networks is very popular and is fairly well known in the art. Accessing an IMS in WLANs, however, is a different matter because certain modifications to the architecture of known WLANs are required. Such modifications have neither been addressed in known architecture, nor in standards that regulate and guide the use of an IMS in WLANs. Therefore, there is a need for a suitable architecture and method for accessing an IMS in WLANs as well as WWANs.
The following list of acronyms used in this specification assists in a better understanding of the invention:
The present invention provides a method and architecture for accessing an IMS over WLANs/WWANs generally, and more particularly over WLANs/WWANs viewed in light of existing related standards. More specifically, the invention provides new interfaces enabling IMS access over WLANs/WWANs, and an exemplary method and architecture for such an interface.
A more detailed understanding of the invention may be had from the following description of preferred embodiments, given by way of example and to be understood in conjunction with the accompanying drawings wherein like elements are designated by like numerals and wherein:
The present invention will be described with reference to the drawing figures wherein like numerals represent like elements throughout.
Hereafter, a user equipment (UE) includes but is not limited to a wireless transmit/receive unit (WTRU), mobile station, fixed or mobile subscriber unit, pager, or any other type of device capable of operating in a wireless environment. When referred to hereafter, a base station includes but is not limited to a Node-B, site controller, access point, or any other interfacing device in a wireless environment.
The present invention is directed to a method and architecture for accessing IMS services over a WLAN. The details of a connection point and an interface between the IMS subsystem (CSCF) and the PDG on the one hand, and the media gateway (MGW) and the PDG on the other are described. A methodology is set forth herein for accessing IMS to be incorporated into existing standard TS 23.234. More particularly, reference may be had to section 7.8 of the existing standard, directed to procedures for IMS access. The description that follows is generally directed to an architecture which is applicable to existing standards including 802.11 in a UMTS or CDMA 2000 setting, for example. However, the broad concept of the invention is applicable without limitation to other transmission systems as well.
Making reference to
In order to access IMS services over an interworked WLAN (I-WLAN) using a WLAN-UMTS network architecture model as shown in
More specifically,
WLAN access network 109 accesses a 3GPP visited network 113 by way of a WLAN BG 117, and/or optionally via a 3GPP AAA proxy server 120. Communications between WLAN access network 109 and WLAN access gateway 117 is by way of a Wn interface, denoting the tunneling of data through intermediate networks. The link between WLAN access network 109 and optional 3GPP AAA proxy server 120 is by way of a Wr/Wb interface, wherein Wr signifies wireless LAN authentication (information flow to 3GPP), and Wb refers to wireless LAN charging functions. WLAN BG 117 is also coupled to a PDG 119 which, in turn, accesses a packet data network (PDN) 138 over a Wi interface, denoting access to a PDN 138. 3GPP AAA proxy server 120 is coupled to a control gateway-call control function (C-Gw CCF) 122, over a Wf interface, denoting a charging gateway function.
A second PDG 124 is linked to WLAN BG 117 of 3GPP visited network 113 over a Wn interface which, as described above, signifies the tunneling of data through intermediate networks. PDG 124 is linked to a PDN 136 over the above-described Wi interface. PDN 136 may be the same network as PDN 138. PDG 124 is linked to a 3GPP AAA proxy server 126 over a Wm interface. 3GPP AAA proxy server 126 is linked to 3GPP AAA proxy server 120 of 3GPP visited network 113 over a Wr/Wb interface, described above. 3GPP AAA proxy server 126 is also linked to online charging system (OCS) 128, HSS 130, HLR 132, and C-Gw CCF 134. The link between OCS 128 and 3GPP AAA proxy server 126 is a Wo interface which implements online charging, whereas the link between HLR 132 and 3GPP AAA proxy server 126 uses a D′/Gr′ interface which provides authentication of the UE 105, and the link between HSS 130 and 3GPP AAA proxy server 126 utilizes a Wx interface for implementing authentication procedures.
The PDG is a node by which PDNs are connected to a 3GPP interworking WLAN. The location of the PDG is different for each specific service accessed WLAN. For some WLAN connections, no PDG is used. For some accessed services the PDG is in the home network and for some accessed services the PDG used is located in one of the visited networks.
The PDG contains routing information for WLAN-3GPP connected users; routes the packet data received from/sent to the PDN 140, shown in FIGS. 3 and 6, to/from the WLAN-3GPP connected user; performs address translation and mapping; performs encapsulation; and generates charging information related to user data traffic for offline and online charging purposes.
When receiving a short message Transfer Protocol Data Unit (TPDU) from the SMS-gateway MSC (GMSC) (i.e., the CSCF 121 shown in
If errors are detected by PDG 119, the PDG 119 returns the appropriate error information to the SMS-GMSC (i.e., the CSCF 121 shown in
When receiving a confirmation that the message is received by UE 105, PDG 119 relays the delivery confirmation to the SMS-GMSC (CSCF) (i.e., CSCF 121 shown in
When receiving a failure report of the short message transfer to the UE 105 PDG 119 returns the appropriate error information to the SMS-GMSC 121 (shown in
If the parameters are not correct, the PDG 119 returns the appropriate error information to the UE 105 in a failure report.
If no parameter errors are found, the PDG 119 transfers the short message TPDU to the SMS-GMSC (i.e., CSCF 121 shown in
When receiving the report of a short message from a short message service-interworking message service center (SMS-IWMCS), not shown for simplicity, the PDG relays the report to the UE 105.
The new reference point Wi is an interface between the IMS-Subsystem (CSCF) 121 and the PDG 119, as shown in
The Wi reference point is similar to the Gi reference point provided by the PS domain. Interworking with packet data networks is provided via the Wi reference point based on IP. Services offered by mobile terminals via reference point Wi are globally addressable through the operators' public addressing scheme or through the use of a private addressing scheme. When a 3GPP network, for example, is provided for an IP multi media (IM)-core network (CN), i.e., IM-CN subsystem, the reference point Wi provides a policy control interface.
After the UE has obtained IP connectivity through the WLAN network, at step S1, the UE performs the IM registration. The UE, at step S2, sends the SIP registration information flow to the PDG. The PDG, at step S3, examines the registration message to determine the target CSCF and forwards the registration message to the target CSCF, at step S4.
Upon receipt of the registration information flow, the CSCF, at step S5, checks the user profile in the HLR/HSS and, at step S6, sends Cx-Query information to the HSS (for subscriber identity, home domain name). The HSS determines if the user is already registered and, at step S7, a Cx-Query Response (Resp) is sent from the HLR/HSS to the CSCF. If, at step S6, the HSS determines that the Cx-Query is not successful, the Cx-Query Resp rejects the registration attempt.
At this stage, it is assumed that the authentication of the user has been completed, although it may have been determined at an earlier point in the information flow.
The CSCF (i.e., serving CSCF (S-CSCF)), at step S8, updates the user profile and sends a Cx-Put message (subscriber identity, S-CSCF name) to the HLR/HSS at step S9. The HSS, responsive to step S9, stores the S-CSCF name for that subscriber and, at step S10, the HSS sends a Cx-Put Resp message to the S-CSCF to acknowledge receipt of the Cx-Put message.
On receipt of the Cx-Put Resp message, the S-CSCF, at step S11, sends Cx-Pull information flow (subscriber identity) to the HSS which, at step S12, downloads the relevant information from the subscriber profile to the S-CSCF.
The S-CSCF, at step S13, stores the information for the indicated user. In addition to the names/addresses information, security information can also be sent for use within the S-CSCF.
The S-CSCF, at step S14, returns the SIP 200 OK information flow (serving network contact information (SNCI)) to the PDG.
The PDG, at step S15, sends information flow SIP 200 OK (SNCI) to the WLAN. The WLAN sends the SIP 200 OK message to the UE, at step S16.
The foregoing describes an exemplary method and architecture for accessing an IP multimedia subsystem (CSCF) over a WLAN. While this invention has been particularly shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention described hereinabove.
This application claims priority from U.S. Provisional Application No. 60/467,479 and filing date of May 2, 2003, which is incorporated by reference as if fully set forth herein.
| Number | Date | Country | |
|---|---|---|---|
| 60467479 | May 2003 | US |
