WO2011146599A2 - Policy control and charging support for wimax voice services - Google Patents

Abstract

Systems and methods for integrating control and charging functions with Worldwide Interoperability for Microwave Access Voice Service (WVS) include a WVS server, a policy distribution module, and an enforcement function module. The WVS server receives a Session Initiation Protocol (SIP) request, wherein, optionally, service information is embedded in a Session Description Protocol (SDP) offer associated with the SIP request. The WVS server initiates a policy control and charging session by sending service related information to a policy distribution/decision function module. The policy distribution/decision module receives the service related information and then authorizes policy charging and control (PCC) rules. The policy distribution/decision module then sends the PCC rules to an enforcement function module. According to the PCC rules, the enforcement function module establishes/modifies an internet protocol (IP) bearer with a target mobile station.

Description

S P E C I F I C A T I O N

POLICY CONTROL AND CHARGING SUPPORT FOR WIMAX VOICE SERVICES

PRIORITY

[001] Priority is claimed to U.S. Provisional Patent Application No.

61/345,847, filed May 18, 2010, U.S. Provisional Patent Application No. 61/346,720, filed May 20, 2010, U.S. Provisional Patent Application No. 61/357,682, filed June 23, 2010, and U.S. Provisional Patent Application No. 61/364,213, filed July 14, 2010, the disclosures of which are incorporated herein by reference in their entirety.

FIELD OF THE INVENTION [002] The field of the present invention is Worldwide Interoperability for Microwave Access (WiMAX) systems, and more specifically, WiMAX Policy Charging and Control functions.

BACKGROUND

[003] WiMAX is a 4^th generation broadband wireless technology that enables the next generation of high capacity mobile multi-media services. WiMAX Forum is currently developing generic WiMAX Voice Service features to support Session Initiation Protocol (SlP)-based Voice over Internet Protocol (VoIP) services over the WiMAX infrastructure, to support WiMAX generic VoIP services, and to interwork with legacy voice, e.g. Public Switched Telephone Network (PSTN) and other existing VoIP infrastructure services. [004] WiMAX Policy Charging and Control (PCC) support has already been accepted by WiMAX Forum to be within the scope of WiMAX Voice Services (VWS) system architecture as described in Figure 1. However, the exact technical details on how to incorporate WiMAX PCC functions into the VWS have not been proposed. Accordingly, there is a need to describe how to incorporate the existing WiMAX Policy Charging and Control (PCC) functions into the new feature, WiMAX Voice Services (VWS), to manage the Quality of Service (QoS) and bearer control functions, as well as for the accounting support.

SUMMARY OF THE INVENTION

[005] Aspects of the present invention are directed towards system and methods for integrating control and charging functions with Worldwide Interoperability for Microwave Access Voice Service (VWS).

[006] In a first aspect of the present invention, a VWS server receives a Session Initiation Protocol (SIP) request, wherein, optionally, service information is embedded in a Session Description Protocol (SDP) offer associated with the SIP request. The VWS server initiates a policy control and charging session by sending service related information to a policy distribution/decision function module. The policy distribution/decision module receives the service related information and then authorizes policy charging and control (PCC) rules. The policy distribution/decision module then sends the PCC rules to an enforcement function module. According to the PCC rules, the enforcement function module establishes/modifies an internet protocol (IP) bearer with a target mobile station.

[007] Additional aspects and advantages of the improvements will appear from the description of the preferred embodiment. BRIEF DESCRIPTION OF THE DRAWINGS

[008] Embodiments of the invention will now be further described in the following more detailed description of the specification when read with reference to the accompanying drawing in which:

[009] Figure 1 is a block diagram illustrating a prior art WiMAX WVS

Architecture incorporating the WiMAX PCC functions.

1010] Figure 2 is a signaling diagram illustrating a WVS server to trigger the PCC IP-CAN Session establishment or modification and to trigger a WiMAX dynamic service flow creation,

[011] Figure 3 is a signaling diagram illustrating a PCC Accounting

Start/Interim Update which is triggered by the WVS IP-CAN Session establishment and modification.

[012] Figure 4 is a signaling diagram illustrating a WVS server which triggers the PCC IP-CAN Session termination or modification and triggers the WiMAX dynamic service flow deletion.

[013] Figure 5 is a signaling diagram illustrating a PCC Accounting

Stop/Interim which is triggered by the WVS IP-CAN Session termination and modification.

[014] Figure 6 is a signaling diagram illustrating a first WVS call setup between WiMAX mobile stations, in which a WiMAX generic VoIP call set up is initiated by the local WiMAX network.

[015] Figure 7 is a signaling diagram illustrating a second WVS call setup between WiMAX mobile stations, in which a WiMAX generic VoIP call set up is initiated by the remove WiMAX network. [016] Figure 8 is a signaling diagram illustrating a mobile station-

Initiated WVS call setup with a legacy PSTN originated by the local WiMAX network,

[017] Figure 9 is a signaling diagram illustrating a mobile station- initiated WVS call setup with the legacy PSTN originated by the legacy PSTN.

[018] Figure 10 is a signaling diagram illustrating a mobile station initiated WVS call release between WiMAX mobile stations and WiMAX generic VoIP call release.

[019] Figure 1 1 is a signaling diagram illustrating a mobile station initiated WVS call release between WiMAX mobile stations.

[020] Figure 12 is a signaling diagram illustrating mobile station- initiated WVS call release with the legacy PSTN.

[021] Figure 13 is a signaling diagram illustrating mobile station- terminated WVS call release with the legacy PSTN

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[022] Figure 2 is a signaling diagram of a WVS Server Triggered PCC

Internet Protocol-Connectivity Access Network (IP-CAN) Session and Dynamic Service Flow Creation/Modification, which includes a Policy Charging Enforcement Function (A-PCEF), a Policy Decision Function/Policy and Charging Rules Function (PDF/PCRF), a WVS server, an Authentication, Authorization, and Accounting/Subscription Profile Repository (AAA/SPR), and an Offline Charging System (OFCS).

[023] In Step 1 , a WVS server receives an incoming call set up request with optional service information embedded in a session description protocol (SDP) offer. The WVS server could also retrieve the service information locally. The WVS server generates an Application Function Charging Identifier (AF-Charging Identifier) in this step. This identifier can be used to identify which charging record collected by the A-PCEF belongs to which specific session (i.e. identify that the charging record belongs to a specific user). In Step 2, based on the service needs (e.g. according to the codec the mobile station uses), the WVS server initiates a PCC Receive (Rx) session Establishment/Modification Request to the PDF/PCRF including the service information. The WVS server, preferably, places the AF-Charging- Identifier in the PCC Rx Session Establishment/Modification Request, and then sends it to the PCRD/PDF.

[024] In Step 3, if the PDF/PCRF does not have the subscriber's subscription related information, it requests the AAA/SPR server to retrieve the information related to the subscriber's IP-CAN session. The PDF/PCRF provides the subscriber ID to the AAA SPR server. The PDF/PCRF requests notifications from the AAA/SPR server on changes in the subscription information.

[025] In Step 4, the PDF/PCRF receives and stores the subscription related information containing the information about allowed services and

PCC rules information for the given subscriber's IP-CAN session.

[026] In Step 5, the PDF/PCRF makes an authorization and policy decision including whether a bearer-control mode can also be the charging mode.

[027] In Step 6, the PDF/PCRF forwards relevant information to the A-

PCEF in the Access Service Network (ASN) to establish a new IP-CAN session or to modify an existence IP-CAN session. This step is also known as the Policy and Charging Rules Provision.

[028] In Step 7, the A-PCEF installs the PCC rules, and optionally, installs the charging mode. The A-PCEF also performs an attribute translation of the AF-Charging-ldentifier received from the WVS server and maps it to the WiMAX service data flow identifier (SDFID) attribute. The A-PCEF generates an Access-Network-Charging-Identifier Value (ANCIDV), maps the ANCIDV to WiMAX PDFIDs (Packet Data Flow Identifiers), and eventually sends it to the WVS server in Steps 9 and 10. In Step 8, A-PCEF triggers the service flow establishment or modification procedures to establish the internet protocol (IP) bearer with the target mobile station (MS) according to the newly installed PCC rules. The A-PCEF will relay Quality of Service (QoS) policy and service flow level policies to serving service flow authorization (SFA) which will then coordinate with the anchor data path function (DPF) and serving service flow management (SFM) to proceed with the data path establish/modification procedures.

[029] In Step 9, once the service flow establishment or modification procedures are completed, the A-PCEF sends an acknowledgement of the IP- CAN session establishment or modification towards the PDF/PCRF.

[030] In Step 10, the PDF/PCRF responds to the WVS server with a

PCC Rx Session Establishment/Modification Acknowledgement message.

[031] In Step 1 1 , the WVS server sends charging related information via a charging message to the OFCS (Offline Charging System). More specifically, the WVS server sends the generated AF-Charging-ldentifier together with the ANCIDV which comes from the A-PCEF to the OFCS by a message (e.g. charging/accounting related message) used between the WVS server and the OFCS. The charging/accounting related message could be a DIAMETER based message (e.g. DIAMETER Accounting Request).

[032] Figure 3 is a signaling diagram illustrating a PCC Accounting request for Start/Interim Update for WVS IP-CAN Session Establishment/Modification. In Step 1 , the WVS IP-CAN session is established or modified.

[033] In Step 2, the WVS PCC Accounting Start/Interim Update is triggered by the completion of a service flow creation or modification during the WVS IP-CAN session establishment or modification respectively. In Step 3, the A-PCEF sends an accounting request to the AAA/SPR server. In Step 4, the AAA/SPR server sends this request to the OFCS. The AAA server can be RADIUS based or DIAMETER based. If the AAA server is RADIUS based, then the AAA Accounting Response refers to the Accounting Response Start Interim.

[034] In Step 5, the OFCS sends to the AAA/SPR server, a response to the accounting request. Upon the AAA/SPR server's acknowledgement of this response, the AAA server sends the response to the A-PCEF.

[035] Figure 4 is a signaling diagram illustrating a WVS server

Triggered PCC IP-CAN Session Modification together with the Service Flows Deletion/Modification during the WVS call release (i.e. VoIP call release)

[036] In Step 1 , the WVS server receives an incoming call release request to terminate a call between a calling party and called peers. In Step 2, the WVS server sends a PCC Rx Session Termination Request to the PDF/PCRF to remove the PCC rules. In Step 3, the PDF/PCRF identifies what policy and charging rules are affected. In Step 4, the PDF/PCRF forwards the relevant information to the A-PCEF in the Access Service Network (ASN) to: remove all the PCC rules previously installed for the IP- CAN session, deactivate all the PCC rules previously activated for the IP CAN session, and modify the affected IP-CAN session. This step is also known as the Policy and Charging Rules Provision.

[037] In Step 5, the A-PCEF removes all related policy and charging rules. In Step 6, the A-PCEF triggers service flow termination procedures to delete the affected service flow (SF). If the affected SF is a dynamic SF, then the A-PCEF will delete it. If the affected SF is a provisional SF, the A-PCEF will modify it.

[038] In Step 7, once the service flow deletion procedures are completed, the A-PCEF acknowledges the IP-CAN session termination and sends an acknowledgment signal to the PDF/PCRF.

[039] In Step 8, the PDF/PCRF sends a PCC Rx Session Termination

Acknowledgement message to the WVS server.

[040] In Step 9, the WVS server may send a message to the OFCS to remove the related AF-Charging-ldentifier and Access-Network-Charging- Identifier-Value, which are stored locally in the OFCS. The message is preferably a DIAMETER based message, for example, a DIAMETER Accounting Request.

[041] Figure 5 is a signaling diagram illustrating a PCC Accounting

Request for WVS IP-CAN Session Modification; and PCC accounting is described during the WVS call release (VoIP call setup). [042] In Step 1 , the VWS IP-CAN session is terminated or modified. In

Step 2, the VWS PCC Accounting Stop or Interim Update is triggered by the completion of a service flow deletion during the VWS IP-CAN Session Modification.

[043] In Step 3, the A-PCEF sends an Accounting

Request/Stop/Interim message to the AAA/SPR server. In Step 4, the AAA/SPR server sends this message to the OFCS server. In one aspect, the AAA SPR server is RADIUS based, and in another aspect, the AAA SPR server is DIAMETER based. If the AAA/SPR server is RADIUS based, the AAA Accounting Request refers to the Accounting Request Stop/Interim. When the OFCS receives the accounting stop message, it will delete the related AF-Charging-ldentifier and Access-Network-Charging-ldentifier-Value, which are stored locally in the OFCS.

[044] In Step 5, the OFCS sends an Accounting

Response/Stop/Interim response message to the AAA/SPR server. In Step 6, upon the AAA/SPR server's acknowledgement of this message, the AAA/SPR server sends the Accounting Response/Stop/Interim message to the A-PCEF. If the AAA/SPR server is RADIUS based, the AAA Accounting Response refers to the Accounting Response Stop/Interim. In Step 7, optionally, the PDF/PCRF sends a Cancel Subscriber Notification request to the AAA/SPR server, and the AAA/SPR sends a Cancel Subscriber Notification response to the PDF/PCRF.

[045] Optionally, Step 3 to Step 6 described with reference to Figure 5 are performed between Step 6 and Step 7 as described in reference to Figure 4. Accordingly, the OFCS does not remove the related AF-Charging-ldentifier and Access-Network-Charging-ldentifier- Value when receiving the AAA Accounting request. In this aspect, Step 9 of Figure 4 triggers the OFCS to remove the related AF-Charging-ldentifier and Access-Network-Charging- Identifier-Value.

[046] Also optionally, when the Accounting Interim Update is employed in Step 3 and Step 4, a Removal Indication can be carried in the accounting message. The Removal Indication is used to instruct the OFCS to remove the related AF-Charging-ldentifier and Access-Network-Charging- Identifier- Value by reason of the VWS Session Termination. In other words, when the VWS session is terminated, the A-PCEF sends an Accounting Interim Update to the AAA/SPR server, and further to the OFCS. This Accounting Interim Update message between the A-PECF and the AAA/SPR and/or between the AAA SPR server and the OFCS contains the Removal Indication.

[047] The VWS call setup is based on the SIP protocol. The related messages used in this section (e.g. Initial SDP offer message) could be matched to corresponding SIP messages. During the VWS call setup, the VWS server can guarantee that the SIP mobile stations have enough resources to set up a call. Generally, the resources reserved for the mobile stations are based on the codec that the mobile stations use for media flows. To ensure the mobile stations have sufficient resources, the resource reservation function (i.e. PCC function) is involved. The caller, mobile station 1 (MS1), and the callee, mobile station 2, (MS2) may belong to different network service providers. [048] Figure 6 is a signaling diagram illustrating a WVS call setup between WiMAX mobile stations (e.g. MS1 and MS2). In Step 1 , MS1 initiates a call setup between itself and MS2 by sending an SIP INVITE request (i.e. Initial SDP offer message), containing an initial SDP, to WVS Server 1 to which MS1 is registered. The initial SDP offer message may represent one or more media requests for a multi-media session, and if the resource for the media is not ready, the SDP offer message for this media is set to INACTIVE.

[049] In Step 2, WVS Server 1 responds to the SIP INVITE request with an SIP 100 (Trying) provisional response. According to the callee's OUI (i.e. MS2's outer user identifier) included in the SIP INVITE request, WVS Server 1 will first try to resolve the IPv4\IPv6 address of the WVS server with which MS2 is registered. If WVS Server 1 determines this IPV4/IPv6 address, the WVS Server 1 knows where MS2 is currently registered. Alternatively, If MS2's OUI is a public user identifier, WVS Server 1 will forward the SIP INVITE request directly to that WVS server. Under this case, step 3 is optional.

[050] In Step 3, according to the public identity info included in the SIP

INVITE request, WVS Server 1 contacts MS1 's AAA/SPR server (i.e. H- AAA1/SPR1 server) which serves MS1 using the same network service provider to validate whether MS2 is a subscriber of a legitimate target network. That is to say, a contact is made to ensure that the operator of this target network has a business relationship with the operator of MS1's home network service provider by sending MS2 a Validation Request message. WVS Server 1 can also use this message to request the H-AAA1/SPR1 server to retrieve the IPv4/IPv6 address of the WVS Server in the case where WVS Server 1 could not previously resolve this information (in Step 2). If the H-AAA1/SPR1 server validates MS2 successfully, it sends an MS2 Validation Response message with a positive confirmation to WVS Server 1. Otherwise, when WVS Server 1 receives the MS2 Validation Response message with a negative confirmation, WVS Server 1 abandons this call setup attempt. Additionally, MS1 's H-AAA/SPR server could respond with the IPv4/IPv6 address of the WVS Server where WVS Server 1 forwards the SIP INVITE request in the MS2 Validation Response to WVS Server 1 depending on the request from WVS Server 1. If analysis of the destination address determines that it belongs to a subscriber of a different operator, the H-AAA1/SPR 1 server includes a well-known entry point (e.g. WVS Server 2) in the destination operator's network. This Step 3 is carried out in the event that WVS Server 1 determines that the address of MS2 belongs to a different operator.

[051] In Step 4, once the IPv4\IPv6 address of WVS Server 2 is known, WVS Server 1 will forward the SIP INVITE request (i.e. Initial SDP Offer message) to WVS Server 2.

[052] In Step 5, WVS Server 2 responds to the SIP INVITE request with an SIP 100 (Trying) provisional response.

[053] In Step 6, if WVS Server 2 is not the WVS server with which

MS2 is currently registered, it contacts H-AAA2/SPR2 server (associated with WVS Server 2) using the same network service provider by sending a AAA Location Information Request to get the IPv4/IPv6 address of the WVS Server with which MS2 is currently registered (i.e. WVS Server 3). H-AAA2/SPR2 will return the IPv4/IPv6 address of the WVS Server 3 in an AAA Location Information Answer sent to WVS Server 2.

[054] In Step 7, WVS Server 2 forwards the SIP INVITE request to

WVS Server 3.

[055] In Step 8, WVS Server 3 responds to the SIP INVITE request with an SIP 100 (Trying) provisional response.

[056] In Step 9, according to registration information of MS2, WVS

Server 3 forwards the SIP INVITE request (i.e. Initial SDP Offer message) to S2.

[057] In Step 10, MS2 responds to the SIP INVITE request with an

SIP 100 (Trying) provisional response.

[058] In Step 1 1 , when MS2 receives an SIP Request from MS1 with an SDP offer, MS2 determines which media flows should be employed for the session and which codecs should be used for each of the media flows based on the proposed SDP offer by MS1. MS2 then sends an SIP 200 (OK) response to WVS Server 3.

[059] In Step 12, WVS Server 3 forwards the SIP 200 (OK) response to WVS Server 1 . Alternatively, the SIP 200 (OK) can be forwarded from WVS Server 3 to WVS Server 2, and subsequently from WVS Server 2 to WVS Server 1 .

[060] In Step 13, WVS Server 1 forwards the SIP 200 (OK) response to MS1.

[061] In Step 14, WVS Server 3 starts accounting (i.e. application layer accounting) for MS2. Optionally, this accounting can be triggered by WVS Server 3 receiving the SIP 200 (OK) in Step 1 1 and executed concurrently with Step 12.

[062] In Step 15, WVS Server 1 starts accounting (i.e. application layer accounting) for MS1 . This event can be triggered by WVS Server 1 receiving the SIP 200 (OK) in Step 12 and performed concurrently with Step 13

[063] In Step 16, MS1 starts the media flow for this session and responds to the SIP 200 (OK) response with an SIP ACK request sent to MS1 via WVS Server 1 and WVS Server 3. Like in Step 12, the SIP ACK can be forwarded from WVS Server 1 to WVS Server 2, then further forwarded from WVS Server 2 to WVS Server 3.

[064] In Step 17, WVS Server 1 communicates with the WiMAX network with which MS1 is attached to initiate WVS IP-CAN Session Establishment/Modification and Flows Creation/Modification (as described with reference to Figure 2) by using negotiated QoS and Policy parameters on an SIP level to allocate resources for MS1. This can be based on the codec chosen for each media flow. Once the SF creation/modification is completed, IP-CAN Accounting can be triggered as described with reference to Figure 3. This step can be triggered by WVS Server 1 receiving the SIP 200 (OK) message in Step 12, and executed concurrently with Step 13. Optionally, this step can be triggered by WVS Server 1 receiving the MS2 Validation Response in Step 3 (or receiving the SIP 100 message in Step 5), and can be executed concurrently with Step 4. In this case, and if MS1 provides more the one codec for a particular media flow, WVS Server 1 initiates WVS IP-CAN Session Establishment/Modification and Service Flows Creation/Modification based on the codec which requests the most resources. Additionally, if WVS Server 1 is able to determine the IPv4/IPv6 address of the WVS Server with which MS2 is registered, then Step 3 is not executed; and, in such case, the Step 17 also can be triggered by WVS Server 1 receiving the first SIP message (i.e. SIP INVITE) in Step 1 , and executed in parallel with Step 2. £065] In Step 18, WVS Server 3 communicates with the WiMAX network with which MS2 is attached to initiate WVS IP-CAN Session Establishment/Modification and Service Flows Creation/Modification (as described with reference to Figure 2) by using the negotiated QoS and Policy parameters on an SIP level to allocate resources for MS2. This can be based on the codec chosen for each media flow. Once the SF creation/modification is completed, the IP-CAN Accounting is triggered as described with reference to Figure 3. This step can be triggered by WVS Server 3 receiving the SIP 200 (OK) in Step 1 1 and executed in parallel with Step 12. Optionally this step can be triggered by WVS Server 3 receiving the SIP INVITE in Step 7 (or receiving the SIP 100 in Step 10), and executed concurrently with Step 9. In such a case, if MS1 provides more than one codec for a particular media flow, WVS Server 3 can initiate WVS IP-CAN session establishment/modification and service flows creation/modification based on the codec which that requires the most resources.

[066] In Step 19, the WVS session is successfully established between MS1 and MS2, and the users can talk, send faxes, or exchange other information. [067] Figure 7 is a signaling diagram illustrating a WS call setup between WiMAX mobile stations. Steps 1 through 10 of Figure 7 are identical to Steps 1 through 0 described above with respect to Figure 6.

[068] In Step 1 1 , MS2 determines a subset of the media flows proposed by MS1 that it supports, and responds with an SIP 183 (Session Progress) provisional response (i.e. Offer Response message) back to MS1. The SDP information, optionally, represents one or more media for a multimedia session. This response is sent to VWS Server 3.

[069] In Step 12, VWS Server 3 checks the SDP information provided by MS2 to see whether the codec chosen for each media flow is supported. VWS Server 3 then sends the SIP 183 (Session Progress) provisional response (Offer Response message) containing the SDP information provided by MS2 to VWS Server 2.

[070] In Step 13, the media stream capabilities of the destination are returned along the signaling path in an SIP 183 (Session Progress) provisional response from VWS Server 2 to VWS Server 1.

[071] In Step 14, VWS Server 1 checks the SDP information provided by MS2 to see whether the codec chosen for each media flow is supported. Then VWS Server 1 sends an SIP 183 (Session Progress) provisional response (Offer Response message) containing the SDP information provided by MS2 to MS1.

[072] In Step 15, MS1 receives the SIP 183 (Session Progress) provisional response (Offer Response message). MS1 determines which media flows should be used for this session, and which codecs should be used for each of those media flows in this step. MS1 inspects the SDP information provided by MS2 and, if the SDP information includes more than one codec for one or more media streams, MS1 selects only one codec per media stream. MS1 sends an SIP PRACK (i.e. response confirmation message) to WVS Server 1. This response confirmation message optionally contains SDP information in which the media information could be a subset of the received SDP information (e.g. the SDP received in the beginning of this step can be included more than one codec for one or more media streams, and MS1 selects only one codec per media stream). The response confirmation message, alternatively, may not contain any SDP information.

[073] In Step 16, WVS Server 1 receives the response confirmation message. WVS Server 1 inspects the SDP information contained in the message. WVS Server 1 then communicates with the WiMAX network to which MS1 is attached to initiate WVS IP-CAN session establishment/modification and service flows creation/modification (as described with reference to Figure 2) by using the negotiated QoS and Policy parameters on an SIP level to allocate resource for MS1. This can be based on the codec chosen for each media flow. Once the SF creation/modification is completed, the accounting is triggered as described with reference to Figure 3. If the response confirmation message does not contain any SDP information, MS1 accepts the SDP information received in Step 13 without any change. In this case, WVS Server 1 stores the SDP information locally before it sends it to MS1 in Step 13.

[074] In Step 17, WVS Server 1 forwards the response confirmation message to WVS Server 3. [075] In Step 18, WVS Server 3 forwards the response confirmation message to MS2.

[076] In Step 19, MS2 responds to the response confirmation message request with an SIP 200 (OK) response (i.e. response ACK message) to WVS Server 3.

[077] In Step 20, WVS Server 3 receives the response ACK message.

Similar to Step 16, WVS Server 3 initiates WVS IP-CAN session establishment/modification and service flows creation/modification based on the codec chosen for each media flow. Once the SF creation/modification is completed, the accounting is triggered in the same fashion as described in reference in Figure 3. Optionally, this step (Step 20) can be performed between Step 17 and Step 18. For example, when WVS Server 3 receives the response confirmation message in Step 17, it initiates WVS IP-CAN session establishment/modification and service flows creation/modification, and then forwards the response confirmation message to MS2.

[078] Alternatively, Step 20 can be executed when WVS Server 3 receives an SIP 183 (Session Progress) message from MS2 in Step 1 1. For example, when WVS Server 3 receives this message and determines that MS2 has already determined the codecs applied for each media flow, WVS Server 3 could execute Step 20. And, in this case, Step 20 can be executed in parallel with Step 12. Similarly, Step 16 also can be executed when WVS Server 1 receives SIP 183 (Session Progress) in Step 13; and, in this case, Step 16 can be performed concurrently with Step 14.

[079] In Step 21 , WVS Server 3 forwards the SIP 200 (OK) response to WVS Server 1 . [080] In Step 22, WVS Server 1 forwards the SIP 200 (OK) response to MS1 . In one aspect, Step 16 is executed when WVS Server 1 receives the SIP 200 (OK) message from WVS Server 3 in Step 21 ; and in this case, Step 16 and Step 22 are executed in parallel. Step 20 and Step 21 also can be performed concurrently.

[081] In Step 23, MS1 considers whether the resource reservation is completed. MS1 should create SDP information which sets every media flow to active (send-recv, send-oniy or recv-only) mode. Then MS1 sends an SIP UPDATE message (resource reservation confirmation message) to WVS Server 1.

[082] In Step 24, WVS Server 1 forwards the resource reservation confirmation message to WVS Server 3.

[083] In Step 25, WVS Server 3 forwards the resource reservation confirmation message to MS2.

[084] In Step 26, MS2 receives the resource reservation confirmation message with all media in the SDP information set to active. MS2 also considers whether resource reservation is completed. MS2 optionally alters the user and sends the resource reservation confirmation message to WVS Server 3.

[085] In Step 27, WVS Server 3 forwards the resource reservation confirmation response to WVS Server 1 .

[086] In Step 28, WVS Server 1 forwards the resource reservation confirmation response to MS1. In one aspect, Step 16 is executed when WVS Server 1 receives the resource reservation confirmation response from WVS Server 3 in Step 27; and, in this case, Step 16 and Step 28 are performed concurrently. Optionally, Step 20 is executed when WVS Server 3 receives the resource reservation confirmation message from MS2 in Step 26; and, in this case, Step 20 and Step 27 are performed concurrently.

[087] In Step 29, if MS2 performs alerting, it signals this function to

MS1 by sending an SIP 180 (Ringing) provision response to MS1 via WVS Server 2 and WVS Server 1 .

[088] In Step 30, MS1 indicates to an originating user that MS2 is ringing. MS1 responds to MS2 by sending an SIP PRACK message via WVS Server 1 and WVS Server 2.

[089] In Step 31 , MS2 responds to the SIP PRACK message with an

SIP 200 (OK) response to MS1 via WVS Server 3 and WVS Server 1.

[090] In Step 32, when the user employing MS2 answers the phone,

MS2 sends an SIP 200 OK to MS1 via WVS Server 1 , WVS Server 2, and WVS Server 3.

[091] In Step 33 and Step 34, WVS Server 3 and WVS Server 1 start the accounting for MS2 and MS1 , respectively.

[092] In Step 35, MS1 starts the media flow for this session, and responds to the SIP 200 (OK) response with an SIP ACK request sent to MS1 via WVS Server 1 and WVS Server 3.

[093] In Step 36, the WVS session is established successfully between MS1 and MS2, and the users on them can talk, send faxes, or exchange other information.

[094] Figure 8 is a signaling diagram illustrating another call setup scenario between WiMAX mobile stations. This scenario describes resource reservation for MS1 and MS2 when WVS Server 1 and WVS Server 3 receive an SIP UPDATE message (resource reservation confirmation message). These steps are identical to Steps 1 -10 of Figure 6 combined with Steps 1 1 through 14 of Figure 7.

[095] In Step 15, MS1 receives an SIP 183 (Session Progress) provisional response (offer response message). MSI determines which media flows should be used for this session, and which codecs should be used for each of those media flows in this step. MS1 sends a response confirmation message to WVS Server 1 for the second round of SDP negotiations. MS1 inspects the SDP information provided by MS2; and the possible actions the MS1 can execute to generate new SDP information are listed as follows:

Case a: If the SDP information includes more than one codec for one or more media streams, MS1 selects only one codec per media stream.

Case b: If the SDP information includes more than one codec for one or more media streams, MS1 selects a subset of these codecs.

Case c: MS1 provides additional codecs for one or more media streams.

Case d: MS1 does not change anything. For example, the SDP information received includes exactly one codec per media stream. The response confirmation message optionally contains the newly generated SDP information, or, alternatively, does not contain any SDP information.

[096] In Step 16, WVS Server 1 forwards the response confirmation message to WVS Server 3. In Step 17, WVS Server 3 forwards the response confirmation message to MS2. In Step 18, MS2 responds to the response confirmation message with an SIP 200 (OK) response message (i.e. response Acknowledgement message) to WVS Server 3.

[097] In Step 19, WVS Server 3 forwards the SIP 200 (OK) response message to WVS Server 1. In Step 20, WVS Server 1 forwards the SIP 200 (OK) to MS1. In this step, the second round of SDP negotiations concludes.

[098] In Step 21 , upon MS1 finding that all codecs for one or more media streams are determined, MS1 creates a new SDP containing the information of all media flows. MS1 considers whether the resource reservation is completed, and set every media flow in this SDP to active (send-recv, send-only or recv-only) mode. MS1 then sends an SIP UPDATE message (i.e. resource reservation confirmation message) to WVS Server 1.

[099] In Step 22, WVS Server 1 receives the SIP UPDATE message

(resource reservation confirmation message) and inspects the SDP information contained in the message. When WVS Server 1 finds that all the media streams are set to active mode, WVS Server 1 communicates with the WiMAX network to which MS1 has attached to the initial WVS IP-CAN session establishment/modification and service flows creation/modification (as described in reference to Figure 2) by using the negotiated QoS and Policy parameters on an SIP level to allocate resources for MS1. This can be based on the codec chosen for each media flow described in the SDP information. Once the SF creation/modification is completed, the accounting will be triggered as described with reference to Figure 3. If not all the media streams are set to active mode, then WVS Server 1 will not consider this SIP UPDATE message as a resource reservation confirmation message, thus giving the peers more opportunities to change their media and codecs. Step 22 can be performed concurrently with Step 23 (below).

[0100] In Step 23, WVS Server 1 forwards the SIP UPDATE message to WVS Server 3.

[0101] In Step 24, like Step 18, WVS Server 3 checks the SDP information in the SIP UPDATE message, and confirms that it is a resource reservation confirmation message (i.e. all media are set to active mode), then WVS Server 3 initials the WVS IP-CAN session establishment/modification and service flows creation/modification based on the codec chosen for each media flow. Once the SF creation/modification is completed, the accounting is triggered as described in connection with reference to Figure 3. Step 24 can be performed concurrently with Step 25 (below).

[0102] In Step 25, WVS Server 3 forwards the SIP UPDATE message to MS2.

[0103] In Step 26, MS2 receives the SIP UPDATE message with all media in SDP set to active. MS2 also considers whether resource reservation is completed. MS2, optionally, alters the user and sends SIP 200 OK (resource reservation confirmation) to WVS Server 3.

[0104] In Step 27, WVS Server 3 forwards the SIP 200 (OK) response to WVS Server 1 .

[0105] In Step 28, WVS Server 1 forwards the SIP 200 (OK) response to MS1.

[0106] Steps 29 through Step 36 are identical to Step 25 through Step 28 described in reference to Figure 7.

[0107] Between Steps 20 and 21 , if MS1 decides to change the SDP information, MS1 can send an SIP UPDATE with a new SDP offer freely as long as MS1 sets the corresponding media stream to inactive mode. Then both WVS Server 1 and WVS Server 3 will not consider this SIP UPDATE message as a resource reservation confirmation message, and will not initial the WVS IP-CAN establishment/modification and service flows creation/modification.

[0108] Following the WVS IP-CAN session establishment/modification, MS1 also can change the media by sending a new SDP offer using an SIP UPDATE request. Thereafter, when the negotiation is finished, WVS Server 1 receives another SIP UPDATE message which is considered as a resource reservation confirmation message, and then WVS Server 1 initials the WVS IP-CAN session establishment/modification procedure. Step 22 can be executed when WVS Server 1 receives the SIP 200 OK message from WVS Server 3 in Step 27. In this case, Step 22 and Step 28 can be performed concurrently. Step 24 can be performed when WVS Server 3 receives the SIP 200 OK message from MS2 in Step 26. In this case, Step 24 and Step 27 can be performed concurrently.

[0109] Figure 9 is a signaling diagram illustrating a mobile station initiated WVS call setup with Public Switched Telephone Network (PSTN). A Public Switched Telephone Network Session Initiated Protocol User Agent Server (PSTN SIP UAS) in Figures 9, 10, 12, and 13 refers to an SIP entry point to the PSTN. In Step 1 , the mobile station initiates a call set up request to a terminal in the PSTN domain, and sends an SIP INVITE request (i.e. initial SDP offer message) containing an initial SDP to the WVS Server to which it has been registered. Optionally, the initial SDP represents one or more media requests for a multi-media session and if the resource for the media is not ready, the SDP message for this media can now be set to INACTIVE.

[0110] In Step 2, the WVS server responds to the SIP INVITE request with an SIP 100 (Trying) provisional response.

[0111] In Step 3, upon the WVS server determining the IPv4/IPv6 address of the PSTN SIP UAS for the called peer, the WVS server will forward the SIP INVITE request to the PSTN SIP UAS for the called peer.

[0112] In Step 4, the PSTN SIP UAS responds to the SIP INVITE request with an SIP 100 (Trying) provisional response.

[0113] In Step 5, the media stream capabilities of the destination are returned along with the signaling path, in an SIP 183 (Session Progress) provisional response (i.e. Offer Response message), from the PSTN SIP UAS for the called peer to the WVS server.

[0114] In Step 6, the WVS server checks the SDP information provided by the PSTN SIP UAS for the called peer to see whether the codec chosen for each media flow is supported. Then the WVS server sends the SIP 183 (Session Progress) provisional response (Offer response message) containing the SDP information to the mobile station.

[0115] In Step 7, the mobile station receives the SIP 183 (Session Progress) provisional response (Offer response message). The mobile station determines which media flows should be used for this session, and which codecs should be used for each of those media flows in this step. The mobile station inspects the SDP information and if the SDP information includes more than one codec for one or more media streams, the mobile station then selects only one codec per media stream. The mobile station sends a response confirmation message to the WS Server. Optionally, this response confirmation message contains SDP information in which the media information can be a subset of the received SDP information (e.g. the SDP information received in the beginning of the step can include more than one codec for one or more media streams, and the mobile station selects only one codec per media stream). Alternatively, the response confirmation message does not contain any SDP inforamation This step is similar to Step 11 described with reference to Figure 7.

[0116] In Step 8, the VWS server receives the response confirmation message. The VWS server inspects the SDP information contained in the message. Then the VWS server communicates with the WiMAX network with which the mobile station is attached to initiate VWS IP-CAN session establishment/modification and service flows creation/modification (as shown in Figure 1) by using the negotiated QoS and Policy parameters on the SIP level to allocate resources for the mobile station. This can be based on the codec chosen for each media flow. Once the SF creation/modification is completed, the accounting will be triggered as described with reference to Figure 3. If the response confirmation message does not contain any SDP information, this means the mobile station accepts the SDP information received in Step 6 without any change. In such a case, the VWS server stores the SDP information locally before it sends it to the mobile station in Step 6. This step is like Step 16 described with reference to Figure 7.

[0117] In Step 9, the VWS server forwards the response confirmation message to PSTN SIP UAS for the called peer. [0118] In Step 10, the PSTN SIP UAS for the called peer forwards the SIP 200 (OK) response to the WVS server.

[0119] In Step 1 1 , the WVS server forwards the SIP 200 (OK) response to the mobile station. Step 8 can be executed when the WVS server receives the SIP 200 (OK) response from the PSTN SIP UAS in Step 10. In this case, Step 8 and Step 1 1 can be performed concurrently.

[0120] In Step 12, the mobile station considers whether the resource reservation is completed. The mobile station creates an SDP offer message in which every media flow is set to active (send-rcv, send-only, or rec-only) mode. Then, the mobile station sends an SIP UPDATE message (resource reservation confirmation message) to the WVS server.

[0121] In Step 13, the WVS server forwards the SIP UPDATE request to the SIP UAS for the called peer.

[0122] In Step 14, the PSTN SIP UAS forwards the SIP 200 (OK) response to the WVS Server.

[0123] In Step 15, the WVS Server forwards the SIP 200 (OK) response to the mobile station. Optionally, Step 8 can be performed when the WVS server receives the SIP 200 (OK) response from the PSTN SIP UAS in Step 14; and in this case, Step 8 and Step 15 can be performed concurrently.

[0124] In Step 16, the called peer can perform alerting. Taking this into consideration, the PSTN SIP UAS for the called peer forwards the SIP 180 ( Ringing) provisional response to the WVS Server, then further to the mobile station.

[0125] In Step 17, the mobile station indicates to the originating subscriber that the communication peer is ringing. It responds to the WVS server with the SIP 180 (Ringing) provisional response with an SIP PRACK request, then further to the PSTN SIP UAS for the called peer.

[0126] In Step 18, the PSTN SIP UAS for the called peer forwards the SIP 200 (OK) response to the VWS server, then to the mobile station.

[0127] In Step 19, when the called peer answers the phone, the PSTN SIP UAS for the called peer forwards the SIP 200 (OK) response to the VWS server, then further to the mobile station.

[0128] In Step 20, the VWS server starts the accounting for the mobile station.

[0129] In Step 21 , the mobile station starts the media flow for this session, and response to the SIP 200 (OK) response with an SIP ACK request sent to the PSTN SIP UAS for the called peer via the VWS server. In the scenario described above, the VWS IP-CAN session establishment/modification procedure is triggered by the resource confirmation message of Step 7. The procedure can also be triggered by the resource confirmation message (SIP UPDATE message) of Step 12. In this case, the principle is quite similar to the scenario described with reference to Figure 8. Then, the VWS session is successfully established between the mobile station and the called peer, and the users on them can start to talk, send faxes, or exchange other information.

[0130] Optionally, Step 1 can be performed when the VWS server receives an SIP 183 (session progress) message from the PSTN SIP UAS in Step 5. In this case, Steps 3, 6, and 8 can be performed concurrently.

[0131] Figure 10 is a signaling diagram illustrating a mobile station terminated VWS call setup with PSTN. In Step 1 , PSTN SIP UAS for the calling peer forwards an SIP INVITE request (i.e. Initial SDP Offer Message) to the WVS Server. The Initial SDP Offer message contains an initial SDP message which represents one or more media requests for a multi-media session and if the resource for the media is not ready, the SDP message for this media should be set to INACTIVE.

[0132] In Step 2, the WVS Server responds to the SIP INVITE request with an SIP 100 (Trying) provisional response. In Step 3, according to registration information of the mobile station, the WVS Server forwards the SIP INVITE request (initial SDP offer message) to the mobile station.

[0133] In Step 4, the mobile station responds to the SIP INVITE request with an SIP 100 (Trying) provisional response.

[0134] In Step 5, the mobile station determines the subset of the media flows proposed by the originating endpoint (i.e. SIP UAS for the calling peer) that it supports, and responds with an SIP 183 (Session Progress) provisional response (i.e. offer response message) back to the originator. The SDP message optionally represents one or more media for a multi-media session. This response is sent to the WVS server first.

[0135] In Step 6, the WVS server sends the SIP 183 (Session Progress) provisional response (offer response message) containing the SDP information provided by the mobile station to PSTN SIP UAS for the calling peer.

[0136] In Step 7, the WVS Server receives an SIP PRACK message (i.e. response confirmation message) from the PSTN SIP UAS for the calling peer. The PSTN SIP UAS determines which media flows should be used for this session, and which codecs should be used for each of those media flows in this step. The PSTN SIP UAS then puts this information in the SDP information contained in the SIP PRACK message.

[0 37] In Step 8, the WVS server forwards the SIP PRACK message to the mobile station.

[0138] In Step 9, the mobile station responds to the SIP PRACK request with an SIP 200 (OK) response (i.e. response Ack message) to the WVS server.

[0139] In Step 10, the WVS server receives the SIP 200 (OK) response. The WVS server communicates with the WiMAX network with which the mobile station was attached. This communication is performed to initialize a WVS IP-CAN session establishment/modification and service flows creation/modification (as described with reference to Figure 2) by using the negotiated QoS and Policy parameters on an SIP level to allocate resources for the mobile station based on the codec chosen for each media flow. Once the SF creation/modification is completed, the accounting will be triggered as described with reference to Figure 3. This step is like Step 6 in Figure 7.

[0140] In Step 1 1 , the WVS server forwards the SIP 200 (OK) response to PSTN SIP UAS for the calling peer. Step 10 and Step 11 can be performed concurrently. In Step 12, the WVS server receives the SIP UPDATE message from the SIP UAS for the calling peer.

[0141] In Step 13, the WVS server forwards the SIP UPDATE request to the mobile station.

[0142] In Step 14, the mobile station receives the SIP UPDATE request with all media in the SDP message set to active. The mobile station also considers whether resource reservation is completed. The mobile station, optionally, alters the user and sends the SIP 200 (OK) message to the VWS server. This step is similar to Step 22 in Figure 7.

[0143] In Step 15, the VWS Server forwards the SIP 200 (OK) response to the PSTN SIP UAS for the calling peer. Step 10 can be performed when the VWS server receives the SIP 200 (OK) message from the mobile station in Step 14; and in this case, Step 10 and Step 15 can be performed concurrently.

[0144] In Step 16, if the mobile station performs an alerting function, it signals this to the PSTN SIP UAS for the calling peer by sending an SIP 180 (Ringing) provisional response via the VWS server.

[0145] In Step 17, the VWS Server receives the SIP PRACK message as a response to an SIP 180 (Ringing) from the PSTN SIP UAS for the calling peer, and forwards it to the mobile station.

[0146] In Step 18, the mobile station responds to the SIP PRACK request with an SIP 200 (OK) response to the VWS server, then to the PSTN SIP UAS.

[0147] In Step 19, when the user employing the mobile station answers the phone, the mobile station sends an SIP (OK) to the VWS server, then further to the PSTN SIP UAS for the calling peer.

[0148] In Step 20, the VWS server starts the accounting for the mobile station.

[0149] In Step 21 , the media flow for this session begins, and the VWS server receives an SIP ACK response from the PSTN SIP UAS for the calling peer. The VWS server forwards the response to the mobile station. The VWS IP-CAN session establishment/modification procedure is triggered by the response confirmation message of Step 7. Additionally, it can be triggered by the resource reservation confirmation message of Step 12, or by the offer response message (SIP 183) of Step 5. The VWS IP-CAN session establishment/modification procedure can be triggered as soon as when the VWS server receives the SIP INVITE in Step 1. Lastly, the VWS session is successfully established between the mobile station and the calling peer, and the users on them can start to talk, send faxes, or exchange other information.

[0150] Figure 1 1 illustrates an embodiment of a mobile station initiated VWS call release between WiMAX mobile stations. In Steps 1-3, when the user using a first mobile station (MS1) hangs up the phone, MS1 sends an SIP BYE request to VWS Server 1. This request is forwarded to VWS Server 2, and finally forwarded to MS2.

[0151] In Steps 4-6, to acknowledge the SIP BYE request, MS2 replies with an SIP 200 (OK) response to VWS Server 2 and then it is forwarded to VWS Server 1 , and finally forwarded to MS1.

[0152] In Step 7, VWS Server 1 initiates VWS IP-CAN session termination/modification and service flows modification or deletion (as described in Figure 4) for MS1 . Once the SF modification is completed, the accounting (Accounting Stop or Interim Update) can be triggered as described with reference to Figure 5. VWS Server 1 also can perform Step 7 when it receives an SIP BYE message from MS1 in Step 1 , or when it receives an SIP 200 (OK) message from VWS Server 2 in Step 5. These steps can be performed concurrently.

[0153] In Step 8, VWS Server 2 initiates VWS IP-CAN session termination/modification and service flows modification or deletion (as described in Figure 4) for MS2. Once the SF modification or deletion is completed, the accounting (Accounting Stop or Interim Update) can be triggered as described in Figure 5: WVS Server 2 also can perform Step 8 when it receives an SIP BYE message from WVS Server 1 in Step 2, or when it receives an SIP 200 (OK) message from MS2 in Step 4. These steps can be performed concurrently.

[0154] Optionally, WVS Server 1 can also trigger accounting stop interaction between WVS Server 1 and the AAA/SPR server for MS1. Similarly, WVS Server 2 can also trigger the accounting stop interaction between WVS Server 2 and the AAA/SPR Server for MS2. The AAA SPR Server illustrated in Figure 1 1 can be two or more separated entities (e.g. one is for MS1 - AAA1/SPR1 , and another is for MS2 - AAA2/SPR2.

[0155] Figure 12 illustrates an embodiment of a mobile station initiated WVS call release with a PSTN. In Steps 1-2, when a user employing an MS hangs up the phone, the MS sends an SIP BYE request to a WVS server and then it is forwarded to the PSTN SIP UAS for a called peer in the PSTN domain.

[0156] In Steps 3-4, to acknowledge the SIP BYE request, the PSTN SIP UAS for the called peer replies with an SIP 200 (OK) response to the WVS server, which in turn is forwarded to the MS.

[0157] In Step 5, the WVS server initiates a WVS IP-CAN session termination/modification and service flows modification or deletion (as described in Figure 4) for the MS. Once the SF modification or deletion is completed, the accounting (Accounting Stop or Interim Update) will be triggered as described in Figure 5. The WVS server also can perform Step 5 when it receives an SIP BYE message from the MS in Step 1 , or when it receives an SIP 200 (OK) from the PSTN SIP UAS for the called peer in Step 3. These steps can be performed concurrently. The WVS server can also trigger the accounting stop interaction between the WVS server and the AAA Server for the MS.

[0158] Figure 13 is a signaling diagram illustrating a mobile station terminated WVS call release with PSTN. In Steps 1-2, a PSTN SIP UAS for the calling peer sends an SIP BYE request to a WVS server, and the WVS server forwards this request to the mobile station.

[0159] In Steps 3-4, to acknowledge the SIP BYE request, the mobile station replies with an SIP 200 (OK) response to the WVS server and then forwards it to the PSTN SIP UAS for the calling peer.

[0160] In Step 5, the WVS server initiates WVS IP-CAN session termination/modification and service flows modification or deletion (as described with reference to Figure 4) for the mobile station. Once the SF modification or deletion is completed, the accounting (Accounting Stop or Interim Update) is triggered as described with reference to Figure 5. The WVS server can perform Step 5 when it receives an SIP BYE message from the PSTN SIP UAS for the calling peer in Step 1 , or when it receives an SIP 200 (OK) message from the mobile station in Step 3; and these steps can be performed concurrently. The WVS server also can trigger the accounting stop interaction between the WVS server and the AAA/SPR server for the mobile station.

[0161] While embodiments of this invention have been shown and described, it will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the following claims.

Claims

CLAIMS What is claimed is:

1 . A method for integrating control and charging functions with Worldwide Interoperability for Microwave Access Voice Service (VWS), the method comprising:

receiving, at a VWS server, a Session Initiation Protocol (SIP) request , wherein optional service information is embedded in a Session Description Protocol (SDP) offer associated with the SIP request;

initiating, by the VWS server, a policy control and charging session for the SIP request by sending service related information to a policy distribution/decision function module, wherein the service related information includes policy charging and control (PCC) rules for a subscriber;

authorizing, by the policy distribution/decision function module, policy charging and control (PCC) rules; and

establishing or modifying, by an enforcement function module, an internet protocol (IP) bearer with a target mobile station according to the PCC rules received from the policy distribution/decision function module.

2. The method of claim 1 , further comprising:

sending, by the enforcement function module, an Authentication, Authorization, and Accounting (AAA) accounting start request to an AAA server; ahd

sending, by the AAA server, the AAA accounting start request to an offline charging server.

3. The method of claim 2, further comprising: in response to completion of a service flow creation or modification, triggering the AAA accounting start request.

4. The method of claim 1 , further comprising:

receiving, at the VWS server, a SIP BYE message from the target mobile station;

sending, by the VWS server, a session termination request to the policy distribution/decision function module;

forwarding the session termination request from the policy

distribution/decision function module to the enforcement function module; removing, by the enforcement function module, the PCC rules; and triggering a service flow termination/modification procedure.

5. The method of claim 4, further comprising:

sending an accounting stop request from the enforcement function module to an AAA server; and

forwarding, by the AAA server, the accounting stop request to an offline charging server.

6. The method of claim 1 wherein receiving the SIP request comprises receiving an SIP OK 200 message prior to an SIP 180 message being sent from the target mobile station to a first mobile station, wherein the first mobile station initiates a call set up request with the target mobile station.

7. The method of claim 6, further comprising:

sending, by the WS server, the SIP INVITE message to the target mobile station, the target mobile station using a network service provider (NSP) or a publicly switched telephone network (PSTN) network .

8. A method for resolving an address of a Worldwide Interoperability for Microwave Access Voice Service (WVS) server associated with a target mobile station, the method comprising:

receiving, by a first WVS server, an SIP INVITE request from a first mobile station; and

sending, by the first WVS server, a call validation request to a first Authentication, Authorization, and Accounting (AAA) server of a same network service provider (NSP) of the first mobile station to validate whether a second mobile station is a subscriber of a legitimate target network whose operator has an interoperability agreement with the NSP; and

sending, by the first AAA server, a call validation response with a confirmation to the first WVS server, the response including an internet protocol (IP)v4/v6 address of a second WVS server;

forwarding, by the first WVS server, the SIP INVITE request to the second WVS server;

sending, by the second WVS server, the SIP INVITE request to the target mobile station; and

if the target mobile station is not registered with the second WVS server:

sending, by the second WVS server, a location information request to a second AAA server to obtain an IPv4\v6 address of a third WVS Server, wherein the target mobile station is currently registered with the third WVS server; sending, by the second AAA server, a location information answer to the second WVS server, the location information answer including the IPv4/v6 address of the third WVS server; and

sending, by the third WVS server, the SIP INVITE request to the target mobile station.

9. The method of claim 8, further comprising:

according to a public identifier of the target mobile station included in the SIP INVITE request, resolving the IPv4\v6 address of a WVS server, wherein the target mobile station is registered with the WVS server.

10. The method of claim 8, wherein the first WVS Server uses a call validation request to request the IPv4\v6 address of a WVS Server, wherein the target mobile station is registered with the WVS Server.

1 1 . The method of claim 8, further comprising:

if the second AAA server validates the target mobile station

successfully, sending, by the second AAA server, a call validation response with a confirmation to the first WVS server.

12. The method of claim 8, further comprising:

if the second AAA server does not successfully validate the target mobile station:

sending, by the second AAA server, a call validation response with a negative confirmation to the first WVS server;

abandoning, by the first WVS server, a call setup attempt and triggers a SIP BYE; and

triggering a SIP BYE message.

13. The method of claim 8, further comprising;

sending, by the first AAA server, a call validation response to the first WVS server, the call validation response having a known entry point, wherein a destination address of the call validation response belongs to a subscriber of a different operator.

14. A system for integrating control and charging functions with Worldwide Interoperability for Microwave Access Voice Service (WVS), the system comprising:

a WVS server configured to:

receive a Session Initiation Protocol (SIP) request, wherein optional service information is embedded in a Session Description Protocol (SDP) offer associated with the SIP request;

initiate a policy control and charging session for the SIP request by sending service related information, the service related information including policy charging and control (PCC) rules for a subscriber;

a policy distribution function module configured to:

receive the subscription related information; and authorize the policy control and charging session; and an enforcement function module configured to:

establish or modify an internet protocol (IP) bearer with a target mobile station according to the PCC rules received from the policy distribution function module..

15. The system of claim 14, wherein the enforcement function module is further configured to: send an Authentication, Authorization, and Accounting (AAA) start request to an AAA server; and send the AAA accounting start request to an offline charging server.

16. The system of claim 15, wherein the enforcement module is further configured to: in response to completion of service flow creation or modification, triggering the AAA accounting start request.

17. The system of claim 14, wherein the enforcement function module is configured to: remove the PCC rules; and trigger a service flow termination procedure.

18. The system of claim 14, wherein the WVS Server is further configured to: receive a SIP BYE message; and send a session termination request to the policy distribution function module, wherein the policy distribution function module forwards the session termination request to the enforcement function module.

19. The system of claim 14, wherein the Authentication, Authorization, and Accounting (AAA) server is further configured to: receive an accounting stop request from the enforcement function module; and forward the accounting stop request to an offline charging server.

20. The system of claim 14 wherein receiving the SIP request comprises receiving an SIP OK 200 message prior to a SIP 180 message being sent from the target mobile station to a first mobile station, wherein the first mobile station initiates a call set up request with the target mobile station.

21. The system of claim 14, wherein the WVS Server is further configured to:

send, by the WVS server, the SIP INVITE message to the target mobile station using a network service provider (NSP) or a publicly switched telephone network (PSTN) network.

22. A system for resolving an address of a Worldwide Interoperability for Microwave Access Voice Service (WVS) server associated with a target mobile station in the WVS, the system comprising:

a first WVS server configured to:

receive an SIP INVITE request from a first mobile station; and

send a call validation request to validate whether the second mobile station is a subscriber of a legitimate target network whose operator has interoperability agreement with a network service provider (NSP);

a first Authentication, Authorization, and Accounting (AAA) server configured to send a call validation response with a confirmation to the first WVS server, and the response including an internet protocol (IP)v4/v6 address of the second WVS server where the first WVS server forwards the SIP INVITE request; a second WVS server configured to:

receive the SIP INVITE request from the first AAA server;

send the SIP INVITE request to the target mobile station; and if the target mobile station is not registered with the second WVS server, the second WVS server is further configured to:

send a location information request to the second AAA server to obtain an IPv4/v6 address of a third WVS server, wherein the target mobile station is registered with the third WVS server, and wherein the second AAA server sends a location information answer to the second WVS server, the location information server including the IPv4/v6 address of the third WVS server, and wherein the third WVS server sends the SIP INVITE to the target mobile station.

23. The system of claim 22, wherein, according to a public identifier of the target mobile station included in the SIP INVITE request, the first WVS server is further configured to resolve the IPv4/v6 address of a WVS server, wherein the target mobile station is registered with the WVS server.

24. The system of claim 22, wherein the first WVS server is further configured to use a call validation request to request the IPv4\v6 address of a WVS Server , wherein the target mobile station is registered with the WVS server.

25. The system of claim 22, wherein, if the second AAA server does not successfully validate the target mobile station: the second AAA server is further configured to send a call validation response to the first WVS server, the call validation response including a positive confirmation.

26. The system of claim 22, wherein, if the target mobile is not validated successfully, the second AAA server is further configured to send a negative confirmation to the first WVS server, wherein the WVS server abandons a call setup attempt and triggers an SIP BYE.

27. The system of claim 22, wherein the first AAA server is further configured to send a call validation response to the first WVS server, the response having a known entry point, wherein a destination address belongs to a subscriber of a different operator.

28. A system for integrating control and charging functions with Worldwide Interoperability for Microwave Access Voice Service (WVS), the system comprising:

means for receiving a Session Initiation Protocol (SIP) request, wherein optional service information is embedded in a Session Description Protocol (SDP) offer associated with the SIP request;

means for initiating a policy control and charging session for the SIP request by sending service related information to a policy distribution/decision function module, wherein the service related information includes policy charging and control (PCC) rules for a subscriber;

means for authorizing policy charging and control (PCC) rules; and means for establishing or means for modifying an internet protocol (IP) bearer with a target mobile station according to the PCC rules received from the policy distribution/decision function module.

29. The system of claim 28 further comprising:

means for sending an Authentication, Authorization, and Accounting (AAA) accounting start request to an AAA server; and

means for sending the AAA accounting start request to an offline charging server.

30. The system of claim 29, further comprising:

in response to completion of a service flow creation or modification, means for triggering the AAA accounting start request.

31. The system of claim 28, further comprising:

means for receiving a SIP BYE message from the target mobile station; means for sending a session termination request to the policy distribution/decision function module;

means for forwarding the session termination request from the policy distribution/decision function module to an enforcement function module;

means for removing the PCC rules; and

means for triggering a service flow termination/modification procedure.

32. The system of claim 31 , further comprising:

means for sending an accounting stop request from the enforcement function module to an AAA server; and

means for forwarding the accounting stop request to an offline charging server.

33. The system of claim 28 wherein the means for receiving the SIP request comprises receiving an SIP OK 200 message prior to an SIP 180 message being sent from the target mobile station to a first mobile station, wherein the first mobile station initiates a call set up request with the target mobile station.

34. The system of claim 33, further comprising:

means for sending the SIP INVITE message to the target mobile station, the target mobile station using a network service provider (NSP) or a publicly switched telephone network (PSTN) network .

35. A system for resolving an address of a Worldwide Interoperability for Microwave Access Voice Service (WVS) server associated with a target mobile station, the system comprising:

means for receiving an SIP INVITE request from a first mobile station; and

means for sending a call validation request to a first Authentication, Authorization, and Accounting (AAA) server of a same network service provider (NSP) of the first mobile station to validate whether a second mobile station is a subscriber of a legitimate target network whose operator has an interoperability agreement with the NSP; and

means for sending a call validation response with a confirmation to a first WVS server, the response including an internet protocol (IP)v4/v6 address of a second WVS server;

means for forwarding the SIP INVITE request to the second WVS server; means for sending the SIP INVITE request to the target mobile station; and

if the target mobile station is not registered with the second WVS server:

means for sending a location information request to a second AAA server to obtain an IPv4\v6 address of a third WVS Server, wherein the target mobile station is currently registered with the third WVS server;

means for sending a location information answer to the second WVS server, the location information answer including the IPv4/v6 address of the third WVS server; and

means for sending the SIP INVITE request to the target mobile station.

36. The system of claim 35, further comprising:

according to a public identifier of the target mobile station included in the SIP INVITE request, means for resolving the IPv4\v6 address of a WVS server, wherein the target mobile station is registered with a WVS server.

37. The system of claim 35, wherein the first WVS Server uses a call validation request to request the IPv4\v6 address of a WVS Server, wherein the target mobile station is registered with the WVS Server.

38. The system of claim 35, further comprising:

if the second AAA server validates the target mobile station

successfully: means for sending a call validation response with a confirmation to the first WVS server.

39. The system of claim 35, further comprising:

if the second AAA server does not successfully validate the target mobile station:

means for sending a call validation response with a negative confirmation to the first WVS server;

means for abandoning a call setup attempt and triggers a SIP BYE; and

means for triggering a SIP BYE message.

40. The system of claim 35, further comprising;

means for sending a call validation response to the first WVS server, the call validation response having a known entry point, wherein a destination address of the call validation response belongs to a subscriber of a different operator.