BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic block diagram of a wireless communication network in accordance with the present invention;
FIG. 2 is part of a first registration message used for identifying a network entity in a first embodiment of the method in accordance with the present invention;
FIG. 3 is part of a second registration message used for identifying a network entity in a second embodiment of the method in accordance with the present invention; and
FIG. 4 is a flow chart of an embodiment of the method in accordance with the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
By means of example only and without limitation, embodiments of the present invention will now be described with reference to a wireless communication network devised in the form of a WiMAX network.
FIG. 1 is a schematic block diagram of a WiMAX network 1 in accordance with an embodiment of the present invention. The WiMAX network 1 of FIG. 1 generally corresponds to the Network Working Group (NWG) Network Reference Model (NRM) and generally comprises a (mobile) subscriber station (end terminal, user equipment) 2, an Access Service Network (ASN) 3, and a Connectivity Service Network (CSN) 4. Throughout the present document, ASN 3 is also referred to as (WiMAX) access network, and CSN 4 is also referred to as (WiMAX/IMS) core network.
ASN 3 further comprises at least one base station 5 and an ASN Gateway (ASN-GW) 6, also referred to as Wireless Access Controller (WAC). WAC 6 further comprises a Service Flow Activation (SFA) module 7.
Within CSN 4, the WiMAX network 1 of FIG. 1 further comprises a Policy Decision Function (PDF) 8 and an Authentication-Authorisation-Accounting (AAA) module 9. In the embodiment shown, PDF 8 and AAA/AAA proxy 9 can be included in a common physical entity (housing) 10. Furthermore, CSN 4 comprises a Mobile IP (MIP) Home Agent (HA) 11.
User equipment 2 and ASN 3 are connected by means of a connection marked R1, wherein R1 refers to a corresponding reference point of the NRM. Likewise, ASN 3 and CSN 4 are connected by means of a connection marked R3, and base station 5 and WAC 6 within ASN 3 are connected by means of a connection marked R6.
The above-described network 1 is based on standard WiMAX architecture. However, in the context of the shown embodiment in accordance with the present invention WAC 6 further comprises means/modules 12, 13, a respective function of which will become apparent later.
During operation of the WiMAX network 1 of FIG. 1, user equipment 2 is mobile as indicated by means of arrows M, M′, such that it may leave/enter a coverage area (not shown) of ASN 3, i.e. base station 5 and WAC 6, to which said user equipment 2 is attached/registered. In order to ensure a required Quality-of-Service (QoS) to user equipment 2 a network initiated Quality-of-Service (QoS) request, e.g. an IP Multimedia Subsystem (IMS) request originating at the CSN 4, including corresponding QoS requirements is pushed from PDF 8 to SFA 7 in WAC 6. This indicated in FIG. 1 by means of arrow A. Said QoS requirements comprise QoS parameters which are used to differentiate telecommunication services based on measurable parameters evaluated or controlled via network monitoring, e.g. a required bit rate.
In order to continuously locate user equipment 2 in terms of a corresponding WAC 6/SFA 7, upon each mobility event of user equipment 2, i.e. whenever the latter connects to a new base station/WAC, a special form of MIP registration message is sent from said WAC, e.g. WAC 6, to Home Agent 11, as indicated by means of arrow B in FIG. 1. In the context of the present invention, said special MIP registration messages comprise an extension including at least one parameter indicating an identifier of SFA 7, i.e. that particular entity in the WAC to which the QoS requirements are to be sent.
Specific formats of said MIP registration message extensions will be described below with reference to appended FIGS. 2 and 3. Home agent 11 receives the MIP registration message (arrow B) and relays or forwards at least said extension and/or said parameter to PDF 8, either directly (solid arrow C in FIG. 1) or indirectly via AAA/AAA proxy 9 (dotted arrows D, D′ in FIG. 1).
In this way, PDF 8 “knows” to which SFA/WAC QoS requirements initiated, for instance, in connection with IMS requests are to be sent. Note that no additional interfaces besides the existing ones according to the NRM have to be defined between ASN-GW (WAC) and CSN-PDF for messages with user equipment mobility updates in the context of the present invention. Please note also that the above described inventive approach generally does not rely on a functional architecture wherein the CSN 4 has a PDF 8, in contrast to, for instance, legacy IP CSN. Since signalling of the SFA/WAC identifying parameter occurs internally within CSN 4, the present approach enables to reuse existing functionality as provided, e.g., in TISPAN-based networks. In this context, PDF 8 in FIG. 1 would have to be replaced by the corresponding legacy functionality.
In other words, the proposed solution is convergent at CSN level with fixed WiMAX architecture.
FIG. 2 is a first embodiment of an extension in the MIP registration message as used in an embodiment of the present invention. The message extension of FIG. 2 corresponds to a first of Mobile IP Vendor/Organisation Specific Extensions as specified in document RFC 3115 (http://rfc.net/rfc3115.txt). Thus, a basic idea underlying the present invention is to manage terminal location for QoS management by adding a vendor specific information element/extension to the MIP registration messages (cf. arrow B in FIG. 1). In an embodiment of the present invention the added MIP vendor specific information element corresponds to an IP address of the SFA entity 7 in the WAC 6, which manages network initiated QoS requests (cf. arrow A in FIG. 1).
Since Mobile IP Vendor/Organisation Specific Extensions as such are known to a person skilled in the art, the message extensions depicted in FIGS. 2 and 3 will not be discussed in great detail in the present document.
FIG. 2 is a Normal Vendor/Organisation Specific Extension (NVSE). Within the NVSE, the field “Vendor-NVSE-value . . . ” is reserved for a particular type of Vendor-NVSE extension, the administration of which is done by the vendor of the network equipment in question. In the present embodiment in accordance with the present invention the Vendor-NVSE-value field includes the WAC-SFA IP address. Furthermore, the field “Vendor-NVSE-type” in FIG. 2 indicates a particular type of vendor-NVSE-extension. The administration of the Vendor-NVSE-types, too, is done by the vendor. In the context of the present invention the Vendor-NVSE-type field may be assigned a particular value, e.g. “X”, in order to indicate that the present extension is to be used for the purpose of terminal location and is to be relayed to CSN-PDF accordingly.
FIG. 3 shows a Critical Vendor/Organisation Specific Extension (CVSE) according to cited document RFC 3115. Like the NVSE of FIG. 2, the CVSE also has a vendor type field and a vendor value field, which can be used for terminal location in the context of the present invention, as previously described.
As known to a person skilled in the art, the basic difference between the critical and normal extensions lies in the fact that in the case of a critical extension being encountered but not recognized a message comprising the extension must be silently discarded, whereas in the case of a normal extension being encountered but not recognized only the extension should be ignored while the rest of the corresponding message data must still be processed.
FIG. 4 is a flow chart illustrating an embodiment of the method in accordance with the present invention.
The method starts in step S100. In subsequent step S102 a mobility event of user equipment 2 (FIG. 1) takes place, i.e. user equipment 2 moves into an area of coverage by a new base station 5/ASN-GW 6.
Accordingly, in subsequent step S104 a corresponding Mobile IP registration request is issued by user equipment 2 for transmission to Home Agent 11 (FIG. 1) via ASN 3 (FIG. 1) serving as Foreign Agent.
In step S106, said Mobile IP registration request is received by receiving means 12 in WAC 6 (FIG. 1).
Note that steps S104 and S106 are optional; in step S102 a mobility event of user equipment 2 may directly trigger a Mobile IP registration request inside ASN 3.
As previously described with reference to FIGS. 2, 3, said parameter comprised in the Mobile IP registration request preferably is included into an equally standardised Mobile IP Vendor/Organisation Specific extension as detailed in RFC 3115 (step S108).
The Mobile IP registration request is then forwarded to Home Agent 11 in step S110, as indicated by means of arrow B in FIG. 1. It is passed on to including means 13 for including in said (standardised) Mobile IP registration request message at least one parameter indicating an identifier of SFA 7 in WAC 6 (FIG. 1).
Home Agent 11 receives the Mobile IP registration message and relays it to CSN-PDF 8 in step S112 in accordance with an entry in the vendor type field, as previously described with reference to FIGS. 2 and 3. Relaying to the PDF 8 in step S112 can occur either directly as indicated by means of arrow C in FIG. 1, or indirectly via AAA/AAA proxy 9, as indicated by means of arrows D, D′ in FIG. 1.
In subsequent step S114 a network initiated QoS request is issued, for instance an IMS-PDF request. Owing to the received terminal location information, said request is directed to the corresponding SFA entity 7 in WAC 6 managing network initiated QoS requests for the user equipment 2 in question (arrow A in FIG. 1; step S116).
Finally, in step S118 the ASN 3 communicates whether or not the required resources are available and can be allocated for that particular service.
The method terminates with step S120.
In this way, the proposed solution does not require definition of new interfaces between ASN-GW (WAC) and CSN-PDF for location messages in order to manage QoS. At the same time, compatibility with legacy wireless/WiMAX networks is ensured.
Patent Application
20070291685
