WO2007014510A1 - Commande de routage interdomaine - Google Patents

Commande de routage interdomaine Download PDF

Info

Publication number
WO2007014510A1
WO2007014510A1 PCT/CN2006/001673 CN2006001673W WO2007014510A1 WO 2007014510 A1 WO2007014510 A1 WO 2007014510A1 CN 2006001673 W CN2006001673 W CN 2006001673W WO 2007014510 A1 WO2007014510 A1 WO 2007014510A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
rpdp
domain
call
call state
Prior art date
Application number
PCT/CN2006/001673
Other languages
English (en)
French (fr)
Inventor
Dongming Zhu
Hai Zhang
Xiaoqin Duan
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37700652&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2007014510(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to CN200680011717XA priority Critical patent/CN101156395B/zh
Priority to EP06753141.8A priority patent/EP1892897B2/en
Publication of WO2007014510A1 publication Critical patent/WO2007014510A1/zh
Priority to US11/965,834 priority patent/US8170565B2/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • H04L45/308Route determination based on user's profile, e.g. premium users
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/18Selecting a network or a communication service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/12Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1225Details of core network interconnection arrangements
    • H04M7/123Details of core network interconnection arrangements where the packet-switched network is an Internet Protocol Multimedia System-type network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to routing control technologies, and more particularly to cross-domain routing control methods in communication systems. Background of the invention
  • 3G 3rd Generation
  • 3G technology greatly attracts the mobile consumer market due to its high bandwidth, multi-service, high quality, etc.
  • problems in 3G technology such as How to make full use of existing network resources while continuously introducing new network technologies, how to comprehensively utilize the characteristics and capabilities of different network technologies to provide users with better business experience, etc., which will limit the market further expansion to a certain extent. .
  • the mobile network is no longer limited to the circuit switching mode, and gradually evolves into a packet Internet Protocol (IP) switching network.
  • IP Internet Protocol
  • the core network of the Universal Mobile Telecommunications System (UMTS) is divided into Circuit Switched (CS).
  • CS Circuit Switched
  • PS Packet Switched
  • IMS IP Multimedia Subsystem
  • the CS domain is used to provide a connection for the circuit type service to the user, and the main functional entities include: a Mobile Switching Center (MSC), a Gateway Mobile Switching Center (GMSC), and a network interworking function entity. (InterWorking Function, IWF).
  • MSC Mobile Switching Center
  • GMSC Gateway Mobile Switching Center
  • IWF InterWorking Function
  • the MSC is used to complete the switching and signaling control functions of the circuit switched service.
  • the MSC can be divided into an MSC server (MSC Server) and a circuit domain media gateway under the control and bearer separation system.
  • CS Media Gateway CS-MGW
  • GMSC is used to complete the routing and addressing function of mobile users in a certain network, and can be set up or divided with MSC
  • IWF is closely related to MSC
  • Public Land Mobile PLMN
  • ISDN Integrated Service Digital Network
  • PSTN Public Switch Telecommunication Network
  • PDN Public Data Network
  • the conversion function, specific functions are defined according to the type of service and network.
  • the PS domain is used to provide a connection for a packet type service to a user.
  • the main functional entities are: a General Packet Radio Service Support Node (GSN;), which is used to complete packet transmission of a packet service user.
  • GSN General Packet Radio Service Support Node
  • the GSN is further divided into two types: a service GSN (SGSN) and a gateway GSN (Gateway GSN, GGSN).
  • the SGSN is used to provide a base station subsystem (BSS) and a wireless network.
  • BSS base station subsystem
  • BG edge gateway
  • HLR Home Location Register
  • Author Center Authentication Center
  • MSISDN International Mobile Subscriber Identity
  • MSI International Mobile Subscriber Identity
  • IMSI International Mobile Equipment Identity
  • WCDMA Wideband Code Division Multiple Access
  • the Session Initial Protocol is introduced as a service control protocol.
  • the SIP is simple, easy to expand, and the media combination is convenient. By separating the service control from the bearer control, a rich multimedia service is provided.
  • the main functional entities in the IMS include: Call Session Control Function (CSCF) that controls functions such as user registration and session control, and Application Server (AS) that provides various business logic control functions.
  • CSCF Call Session Control Function
  • AS Application Server
  • MGCF media gateway control function
  • IM-MGW IMS Media Gateway
  • Interrogating CSCF I-CSCF
  • I-CSCF Interrogating CSCF
  • the HSS in the IMS system is a superset of the HLR and is functionally compatible with the HLR. In a specific networking, the HLRs of the HSS and CS/PS domains are likely to be separate.
  • the IMS architecture defined by the 3GPP standard comprehensively solves the key operational problems such as roaming charging, quality of service (QoS), and security assurance required to provide multimedia services under IP bearers.
  • the architecture and ideas have been obtained. Industry recognized.
  • the third-generation mobile communication "Standardization Partner Project 2 (3GPP2 and the standard organization TISPAN responsible for the development of fixed-line next-generation network technology specifications) is based on the IMS model defined by 3GPP and is based on the IMS model.
  • the definition of the corresponding IP multimedia network architecture and business system that is, the IP multimedia system defined by the above different standards organizations has a consistent architecture.
  • 3GPP has also begun to communicate with UMTS for wireless local area network (WLAN) access.
  • WLAN wireless local area network
  • I-WLAN I-WLAN
  • fixed broadband access IMS I-WLAN
  • AIPN all-IP network
  • the user can access the IMS through a single multimode terminal or multiple types of terminals through different access technologies to obtain unified multimedia services, including packet voice (VoIP) services, according to their own subscription
  • 3GPP R7 proposes to solve the problem of routing between CS/IMS domains when users are called, through a work problem of researching CS domain calls and VoIP services between VoIP services accessed through WLANs, to solve the problem of routing between CS/IMS domains when users are called. The need for development.
  • the network is required to provide the ability to select and connect voice calls between multiple domains, such as: CS domain and PSTN circuit switched voice services for GSM, WCDMA or cdma 2000 systems, or VoIP services for various mobile or fixed packets access to IMS.
  • CS domain and PSTN circuit switched voice services for GSM, WCDMA or cdma 2000 systems
  • VoIP services for various mobile or fixed packets access to IMS.
  • This brings about a new cross-domain routing problem, namely: When the user acts as the called party, the incoming route selects different domain connections according to the routing policy and other conditions. The resolution of this cross-domain routing problem directly determines whether users can register and flexibly choose to use multi-domain voice services at the same time.
  • the following description mostly uses the CS/IMS domain of the WCDMA system as an example.
  • the cross-domain routing control requirement also exists in the GSM, cdma 2000 CS domain, Or between PSTN circuit-switched voice services and various VoIP services for mobile or fixed packet access to IMS.
  • the existing technical solution is: Introducing a Routing Policy Decision Point (RPDP) entity in a system including a CS/IMS domain, and in CS/IMS
  • the routing decision process of the domain is added to the routing decision query of the RPDP entity, and the RPDP entity completes the current routing decision according to the current routing decision information of the user in the CS/IMS domain and the preset current routing policy stored locally, and then completes the current routing decision.
  • the routing information determined according to the current routing decision is returned, and the routing control entity in the CS/IMS domain is controlled to complete the subsequent routing control of the current call/session.
  • RPDP Routing Policy Decision Point
  • the prior art solution can be divided into two typical implementation modes: a call control type interface and a non-call control type interface.
  • the routing control entity in the CS/IMS domain passes the call control
  • the system interface completes the routing decision query to the RPDP entity, for example: the GMSC in the CS domain of the GSM system or the WCDMA system uses the application part of the Customised Application for Mobile Network Enhanced Logic (CAMEL) service (CAMEL Application).
  • CAMEL Customised Application for Mobile Network Enhanced Logic
  • the Part, CAP interface is completed to the RPDP entity interaction as the Global System of Mobile Communication (GSM) GSM Service Control Function (GSM), or the MSC in the CS domain of the cdma2000 system passes the American National Standards Institute- 41 Mobile Application Protocol (ANSI-41 MAP) completes the interaction with the RPDP entity as the wireless intelligent network service control function, or the local switch in the PSTN network completes the interaction with the RPDP entity as the fixed intelligent network service control function through the intelligent network application procedure, or
  • the S-CSCF in the IMS domain completes the RPDP entity interaction as the AS through the IP multimedia subsystem service control interface (ISC), completes the current routing decision query, and implements route control according to the current decision.
  • GSM Global System of Mobile Communication
  • GSM GSM Service Control Function
  • ANSI-41 MAP American National Standards Institute- 41 Mobile Application Protocol
  • the S-CSCF in the IMS domain completes the RPDP entity interaction as the AS through the IP multimedia subsystem service control interface (ISC), complete
  • the routing control entity in the CS/IMS domain completes the routing decision query to the RPDP entity through the non-call control interface, for example: as a signaling transfer point
  • the RPDP entity of the Signaling Transfer Point intercepts the routing information query message of the GMSC to the HLR in the CS domain of the GSM, WCDMA or cdma2000 system; or the HLR of the CS domain in the GSM, WCDMA or cdma2000 system receives the routing information query message of the GMSC Then, the new interface is used to initiate a query to the newly added RPDP entity. After the HSS in the IMS domain receives the routing information query message of the I-CSCF, the new interface initiates a query to the newly added RPDP entity to complete the current routing decision. Query and implement routing control based on current decisions.
  • STP Signaling Transfer Point
  • the routing decision information related to the current CS/IMS domain of the user according to the RPDP entity is determined by the interaction with the HLR HSS, such as the RPDP entity to the HLR/HSS during the decision.
  • the query is obtained or stored locally in the RPDP entity, and is actively updated by the HLR/HSS to the RPDP entity when the related information changes. Since the HLR/HSS does not know the current call state of the user in the CS/IMS domain, the existing The routing state in the technology does not take into account the user's current call state in both domains. In other words, it is not considered when the user is registered in both domains at the same time. In this case, how to select a route can avoid the problem that the user can access the call of both domains at the same time and can only answer one of the calls.
  • the current service can handle multiple calls or have subsequent calls, for example:
  • CS domain in order to process subsequent calls in the call, corresponding supplementary services, such as calling, are defined. Waiting and call hold, multi-party call, and busy forwarding, etc., can solve the problem that if the current user is calling, if there is another incoming call.
  • IMS although the above services are not specifically defined like the CS domain, services similar to those described above are provided, and the subsequent calls of the class can be handled.
  • the cross-domain routing control process does not combine the current call state of the user for routing, and does not provide an effective mechanism to prevent subsequent calls from entering different domains and causing the two domains to simultaneously call. In the abnormal situation.
  • the intelligent network architectures in PSTN, GSM, WCDMA, and cdma 2000 are basically the same, and the IP multimedia systems defined by different standards organizations also have a consistent architecture, that is, The ⁇ supporting various mobile or fixed packet access has a consistent architecture. Therefore, the existing cross-domain routing control scheme and the problems in the above analysis and the need to solve the problem are also in the above various scenarios. akin. Summary of the invention
  • the main object of the present invention is to provide an inter-domain routing control method capable of controlling cross-domain routing in a call state of a user in different domains.
  • An inter-domain routing control method in which a routing policy decision point RPDP entity for storing routing policy information is set in a system including at least a circuit switching network and an IMS domain, the method further includes:
  • the routing decision query entity queries the RPDP entity for the current routing decision
  • the RPDP entity determines a routing decision according to a current routing policy, routing decision related information, and a current call state of the user in the circuit switched network and/or the IMS domain.
  • the RPDP entity returns, to the routing decision query entity, routing related information determined according to the determined routing decision, and the routing decision query entity completes cross-domain routing control.
  • the method further comprises: the PDP entity determining whether the user is registered in the circuit switched network and the MS domain at the same time.
  • Step B further includes:
  • the RPDP entity acquires a call state of the user currently in the circuit switched network and/or the IMS domain;
  • the RPDP entity selects to route the incoming call request to a circuit switched network or an IMS domain according to the acquired call state.
  • the RPDP entity further determines a routing decision according to the current routing policy and routing decision related information.
  • the system adopts a call control type interface-based mode.
  • the RPDP entity obtains the call state of the current circuit switching network and the IMS domain and maintains the call state information locally, and further includes :
  • the RPDP entity monitors, by using the call control type interface, a state of the user-related call request and a processing procedure thereof;
  • the RPDP entity is more involved in the establishment, and/or connection, and release of user-related calls. New locally saved call status information.
  • the obtaining of the step B1 is: the RPDP entity maintains locally and obtains updated call state information by interacting with the informed network entity, and further includes:
  • the informed network entity notifies the RPDP entity of the change of the call state
  • the RPDP entity updates the call state information saved locally according to a notification from the informed network entity.
  • the notification of the step b21 is: the informed network entity notifies the RPDP entity of the change of the call state by using the SIP subscription and the notification mechanism of the IMS domain, and specifically includes:
  • the RPDP entity subscribes the notification of the call state related event to the informed network entity through a SIP subscription message, and negotiates a subscription validity period;
  • the informed network entity sends a call status change event to the RPDP entity through the SIP notification message when the call status changes.
  • the notification of the step b21 is: the informed network entity notifying the RPDP entity of the change of the call state by using the SIP publishing mechanism of the IMS domain, specifically:
  • the informed network entity issues the call state change event to the RPDP entity by using a SIP state release message when the call state changes.
  • the RPDP entity updates the locally maintained call state information and returns an acknowledgement.
  • the notification of the step b21 is: the informed network entity notifies the RPDP entity of the change of the call state by using a subscription and notification mechanism implemented by the unstructured supplementary service data service or the short message service, which specifically includes:
  • the RPDP entity subscribes the notification of the call state related event to the informed network entity by sending an unstructured supplementary service data request or a short message.
  • the informed network entity reports the call state change event to the RPDP entity by sending an unstructured supplementary service data request or a short message when the call state changes.
  • the notification in step b21 is: the informed network entity passes the unstructured supplementary service data service Or the issuing mechanism of the short message service implementation notifying the RPDP entity of the change of the call state, specifically:
  • the informing network entity issues the call state change event to the RPDP entity by sending an unstructured supplementary service data request or a short message when the call state changes;
  • the RPDP entity updates the call state information that is locally maintained.
  • the obtaining of the step B1 is: the RPDP entity obtains call state information by querying the informed network entity in real time, and further includes:
  • the RPDP entity queries the informed network entity when it needs to obtain a call state.
  • the informed network entity returns current call state information to the RPDP entity.
  • the query in step b31 is: the RPDP entity queries the informed network entity to query the call status through a one-time SIP subscription and notification mechanism of the IMS domain, and includes the following steps:
  • the RPDP entity sends a primary SIP subscription message to the informed network entity when a call state needs to be obtained;
  • the informed network entity After receiving the subscription, the informed network entity returns the current call status information to the RPDP entity through the SIP notification message.
  • the query in step b31 is: the RPDP entity queries the informed network entity for the call state through the unstructured supplementary service data service or the short message service, and includes the following steps:
  • the RPDP entity needs to obtain the call state, send an unstructured supplementary service data message or a short message to the informed network entity, and query the informed network entity for call state information; yl l, the informed network After receiving the message, the entity returns the current call state information to the RPDP entity through the unstructured supplementary service data message or the short message.
  • the informed network entity is an application server that monitors a call state
  • the method further includes: the informed network entity receiving the incoming call request message, and modifying the received incoming call request message according to the current call state information, and then continuing to deliver the modified incoming call request message ;
  • Step A is: the routing decision query entity forwards the learned network to the RPDP entity.
  • the modified incoming call request message queries the current routing decision;
  • the obtaining of the step B1 is as follows: the RPDP obtains the call state information according to the modified incoming call request message of the informed network entity, and the step B1 further includes:
  • the RPDP entity receives the modified incoming call request message of the informed network entity, and obtains current call state information from the RPDP entity.
  • the RPDP entity and the informed network entity are located in the same physical entity, and the RPDP entity obtains the call state information from the informed network entity through the internal interface.
  • the RPDP entity only obtains the call state of the circuit switched network and one domain in the IMS domain, and the step B2 selects to route the incoming call request to the circuit switched network or the IMS domain according to the call state, specifically: determining the user in the domain a call state, if it is an occupied and/or a camp-on state, selecting a subsequent route in the domain, and if it is in an idle state, preferentially selecting a subsequent route in another domain; or, the RPDP entity obtains the circuit switched network And the call status of the two domains in the IMS domain, the step B2, according to the call state selection, routing the incoming call request to the circuit switched network or the IMS domain, specifically: determining whether the user is idle in the circuit switched network and the IMS domain. If yes, the priority is selected to select one of the domains for subsequent routing. Otherwise, the domain in which the user is in the occupied and/or camped state is selected for subsequent routing.
  • the RPDP entity is independent of the logical entity of the circuit switched network and the logical entity of the IMS domain, the method further comprising: setting a synchronization mechanism of the call state information between two mutually independent logical entities.
  • the RPDP entity is in the same physical entity as the logical entity of the circuit switched network and the logical entity in the IMS domain, and the synchronization mechanism of the call state information is implemented by using an internal interface; or the RPDP entity is in the
  • the synchronization entity of the circuit switched network and the logical entity in the IMS domain are in different physical entities, and the synchronization mechanism of the call state information is implemented by SIP, the customized application part of the mobile network enhancement logic, the wireless intelligent network protocol, The intelligent network application procedure, the unstructured supplementary service data, and the short message are implemented by any one of the signaling interactions.
  • the implementation of the call state information synchronization mechanism specifically includes the following steps: When any one of the synchronization parties obtains the call state change information of the user, the other party is notified, and the other party updates the locally saved call state information according to the received notification; or, when either of the synchronization parties needs to know When the user's call status information is used, the other party is queried for the call status information of the user, and the other party returns the call status information of the user after receiving the query.
  • the informed network entity is: an application server that monitors a call state, a presence server, a service control function entity that monitors a call state, or a user terminal device itself.
  • the circuit switching network includes, but is not limited to, a GSM system, a WCDMA system CS domain, a cdma 2000 system CS domain, and a PST network.
  • the method of the present invention has the following advantages and features:
  • the present invention provides respective solutions by using a call control type interface, and both are implemented by existing message mechanisms such as USSD, Short Message Service (SMS), SIP, etc., so that the present invention can be existing Convenient upgrades or improvements based on technology not only maintain good compatibility with existing technologies, but also reduce the technical cost of the invention.
  • the RPDP entity can learn the call status by itself and maintain it locally; or the informed network entity can first transmit the call status information to the call request message through its own incoming call request message. RPDP entity.
  • a method that can be applied to both a call control-based interface and a non-call control-based interface is also proposed, that is, a method for an RPDP entity to obtain a call state by interacting with an informed network entity for updating or instant query, wherein the method for interactive update
  • the CS domain can be implemented by a subscription and notification mechanism based on Unstructured Supplementary Services Data (USSD) or short message, or a publishing mechanism based on USSD or short message implementation; the method of interactive update is in the IMS domain. , can be achieved through SIP subscription and notification mechanism, or SIP publishing mechanism.
  • the method of instant query can also be based on the CS domain.
  • the USSD message or short message is implemented in the IMS domain by SIP messages.
  • the present invention performs domain selection routing only when one or only two call states of the domain are known, and selects the domain in which the call is occupied to perform subsequent routing, that is, the technology of the present invention.
  • the scheme implements cross-domain routing control by considering the current call state of the user, which not only avoids the abnormal situation of simultaneous access to the call in different domains, but also utilizes the existing supplementary services of the respective domains for subsequent service processing, thereby adapting to the user terminal only
  • An audio I/O module cannot simultaneously perform voice calls in the CS/IMS domain and can continue to provide processing requirements for existing service features related to subsequent call processing in the CS/IMS domain.
  • the present invention uses an internal interface or an external SIP/CAP USSD/SMS interface to implement a synchronization mechanism between the two to ensure inter-RPDP entities in different domains.
  • the latest call state information is shared to ensure that the call state-based routing can be accurately implemented, and the reliability of the RPDP entity cross-domain routing control is improved.
  • the present invention further improves the existing cross-domain routing control scheme, improves the user experience, and further promotes the application and development of CS, WLAN, and IMS networks.
  • FIG. 1 is a flowchart of an implementation of an embodiment of a cross-domain routing control method of the present invention
  • FIG. 2 is a flow chart of cross-domain routing control signaling interaction for obtaining current call state information of a user based on a local monitoring call state machine according to an embodiment of the present invention
  • FIG. 3 is a flow chart of cross-domain routing control signaling interaction of obtaining current call state information of a user based on an event subscription and notification mechanism according to an embodiment of the present invention
  • FIG. 4 is a flow chart of inter-domain routing control signaling interaction of obtaining current call state information of a user based on a state release mechanism according to an embodiment of the present invention
  • FIG. 5 is a flow chart of cross-domain routing control signaling interaction for obtaining current call state information of a user based on an instant query mechanism according to an embodiment of the present invention.
  • FIG. 6 is a cross-domain road for transmitting current call state information of a user based on a modified message according to an embodiment of the present invention. Flowchart by control signaling interaction. The present invention will be further described in detail below with reference to the accompanying drawings.
  • the main idea of the cross-domain routing control method proposed by the present invention is: when performing cross-domain routing on a new incoming call request, first obtain the call state of the user in the two domains, and the RPDP entity according to the known call state information Try to select the current occupied domain to perform subsequent routing for the new incoming call request, so as to avoid the situation that two different domains are called in at the same time, and can continue the existing supplementary service for the same domain subsequent call to the new incoming call. Request for offer.
  • the USSD is a supplementary service introduced in the GSM PH2 phase. Both the terminal and the network can initiate USSD operations. Like the short message, the USSD operation can also be sent in the call, but unlike the short message: USSD is real-time connection oriented. That is, in a USSD session, the wireless connection is maintained, a transparent pipe is provided, there is no store-and-forward, and multiple consecutive USSD operations are supported during a USSD session.
  • the route of the USSD operation is determined according to the service code in the message.
  • the entity in the USSD application parses the service data in the message and processes and responds according to the service logic. Through the USSD, the carrier can customize the local user requirements. The corresponding business. WCDMA System The CS domain inherits the USSD business.
  • the CS domain and the PSTN network of the cdma 2000 system do not support the USSD service.
  • the CS domain and the PSTN network of the GSM, WCDMA system, and the CDMA system can support short message services.
  • the SIP event subscription and notification mechanism of the IMS domain is a SIP extension mechanism.
  • a SIP user agent can initiate a subscription to a specific event to other SIP user agents, and a user who receives the subscription request returns a response, and the party is in the request and The negotiation of the validity period of the subscription is completed in the interaction of the response, after that, The user who receives the subscription request processes the subscription request according to a certain policy, such as whether authorization is required, etc. After authorization, the user who receives the subscription request initiates a subscription when the status of the event changes during the validity period determined by the negotiation.
  • the user sends a corresponding event notification; during the validity period, the user who initiated the subscription can extend or terminate the subscription by re-initiating the subscription request, otherwise, when the negotiated validity period is reached, the secondary subscription is automatically terminated.
  • the SIP state issuance mechanism is another extension of the active release definition to complete the state, by which the client is allowed to publish its own event state to the state publishing agent, and the state agent acts as an aggregator of these states and according to the subscription situation. Subscribers send corresponding event notifications.
  • SIP is used as its end-to-end session control protocol. Therefore, the above SIP subscription and notification mechanism and SIP publishing mechanism are also supported.
  • the present invention is based on a routing policy defined for the user, whether the user is reachable in different domains, And information such as the current call state of the user in each domain.
  • the enhanced cross-domain routing control method is used to select the connection route of the incoming call request.
  • the enhanced cross-domain routing control method is based on the prior art solution to further process the routing decision according to the current call state of the user in the CS/IMS domain, so as to adapt the user terminal to only one audio I/O module.
  • the key techniques of the method of the present invention are: how to obtain the call state information of the user, and how to decide which domain to perform subsequent routing based on the known call state.
  • the present invention provides a method for self-monitoring to obtain a call state or modifying a message delivery state by other network entities according to the prior art call control type interface.
  • the local maintenance proposed by the present invention is used to update with other network entities.
  • instant query method for obtaining call status then based on call class control interface and non The case of the call control class interface can be applied.
  • the interaction or query between the RPDP entity and other informed network entities can be implemented in the CS domain or the IMS domain by using a related mechanism of the USSD message or the short message or the SIP message.
  • the present invention provides a method of selecting one of the most likely or already occupied domains as a connection routing domain of a new incoming call request.
  • the present invention also considers how the RPDP entity can synchronize the current call state information of the user between the two in the case of the CS/IMS domain as an independent logical entity, using the internal interface of the same physical entity, or Synchronization is achieved by external interaction methods between different physical entities.
  • the short message service can be supported by either the GSM, the WCDMA system CS domain or the cdma 2000 system CS domain or the PSTN network; Whether it is 3GPP or 3GPP2 or TISPAN defined IP multimedia subsystem, SIP is used as its end-to-end session control protocol. Therefore, the above SIP subscription and notification mechanism and SIP publishing mechanism are also supported.
  • the third generation mobile communication system includes a CS domain and an IMS domain, and the user can register in two domains at the same time, and can use voice services in two domains.
  • an RPDP entity can be introduced in the system. And adding a routing decision query to the RPDP entity in the CS/IMS domain routing control process, and the RPDP entity completes the current routing according to the current routing decision information of the user in the CS/IMS domain and the current routing policy preset in the local storage. The decision then returns the routing information determined according to the current routing decision, and controls the routing control entity in the CS/IMS domain to complete the subsequent routing control of the current call/session.
  • the RPDP entity not only considers the current routing policy and other related information when making routing decisions, but also combines the call state of the user in the CS/IMS domain.
  • the entity that completes the routing decision query is called a routing decision query entity.
  • the main steps of the entire cross-domain routing control process in the method of the present invention are divided into query, judgment and return.
  • the key step is to judge the decision. Because the decision needs to be made in conjunction with the current call state of the user, the step of determining the decision is further refined.
  • the process of the entire cross-domain routing control is divided into six steps, and the cross-domain routing controls one.
  • the implementation flow chart of the embodiment is shown in Figure 1:
  • Step 101 When the incoming call depends on the route, the routing decision query entity queries the RPDP entity for the current routing decision.
  • Step 102 After receiving the routing decision query request, the RPDP entity determines whether the user is registered in the CS domain and the IMS domain at the same time. If yes, the current call state of the user in the two domains needs to be considered, and the process proceeds to step 103. Otherwise, only the route is considered. Strategy, etc., directly proceeds to step 105. In actual implementations, this step is optional.
  • Step 103 The RPDP entity acquires the current call state of the user in the CS domain and the IMS domain, and then proceeds to step 104.
  • the RPDP entity needs to consider the user to select the call connection domain in the current call state of the two domains, it is necessary to first obtain the call state of the user in the two domains by means of corresponding means.
  • Step 104 The RPDP entity selects to route the incoming call request to the CS domain or the IMS domain according to the obtained call state.
  • the principle of selection is to connect subsequent calls as far as possible to the domain of the existing call.
  • Step 105 The RPDP entity further determines the path according to the current routing policy and routing decision related information. By decision. This step is a step of the routing decision of the RPDP entity. It can be seen that if the current call state of the user in the two domains needs to be considered, the routing decision of this step needs to be further performed based on the result of the domain selection in step 104. For example: Step 104 selects the CS domain, then this step is to perform subsequent routing in the CS domain; or step 104 preferentially selects the CS domain, then this step needs to integrate other conditions to determine the selected domain routing. In this way, the RPDP entity is determined according to the current routing policy and routing decision related information, and combined with the current call state of the user in the CS/IMS domain, the routing decision is determined.
  • Step 106 The RPDP entity returns the determined routing decision and routing related information to the routing decision query entity, so that the routing decision query entity completes the cross-domain routing control.
  • the most critical steps are: How the RPDP entity obtains the call state information of the user currently in different domains, and how the RPDP entity performs domain selection based on the known call state.
  • four schemes for obtaining the current call state information of the user are given. The three schemes are divided into several implementation manners according to different domains and different manners used. For the selection of the domain, detailed guidelines will be given to cover the call status of any one or both of the domains.
  • the detailed criteria for the selection of the domain selection are explained.
  • the detailed criteria for performing the domain selection determination based on the known call state information may be:
  • the RPDP entity When the RPDP entity only obtains the call state of a domain in the CS domain or the IMS domain, it determines the call state of the user in the domain. If it is the occupied/preempted state, it selects the subsequent route in the domain. If it is idle, It is preferred to make subsequent routes in another domain. This is because if only the domain's call state is known, if the domain determines that it has been occupied/preempted, it means that the domain must have a call, so the new call must be placed. The connection is routed to the domain; if the domain is idle, then only another domain may have a call, so the new incoming call request is routed to another domain, so that the abnormal situation that the two domains are simultaneously inbound cannot be guaranteed.
  • the RPDP entity When the RPDP entity can obtain the call state of the CS domain and the IMS domain at the same time, it is determined whether the user is idle in the CS domain and the IMS domain. If yes, the equal priority arbitrarily selects one of the domains for subsequent routing. Otherwise, select the domain in which the user is in the occupied/preempted state for subsequent routing. This is because in the state where both domains are idle, the new incoming call request does not appear in any domain connection. In the case of the above two incoming calls, the RPDP entity makes a decision according to the routing policy, and if one of the domains is occupied/preempted, the RPDP entity preferentially selects the new incoming call to connect to the domain. Of course, there is no theoretical situation in which both domains are occupied/preempted by incoming calls.
  • the call status can be obtained by the scheme of the RPDP entity self-monitoring and local maintenance, or And adopting a scheme in which another informing network entity modifies the incoming call request message through itself and then transmits the call state information to the RPDP entity; and for the mode adopting the non-call control type interface, the interactive update with other informed network entities is adopted. Or, the inquiring network entity can instantly query the two schemes to obtain the call state.
  • both schemes are also applicable to the mode using the call control class interface.
  • the RPDP entity can obtain call state information by self-monitoring and local maintenance. That is to say, on the basis of the embodiment shown in Fig. 1, the RPDP entity in step 103 obtains the call state by self-monitoring and maintains the obtained call state information locally.
  • the specific steps can be divided into two steps: When the communication system implements the routing decision query through the call control type interface, the RPDP entity first monitors the status of the user-related call request and the processing procedure through the call control type interface, and then the RPDP entity according to the user-related call The locally saved call state information is updated by establishing, and/or turning on, and releasing the situation.
  • the RPDP entity can monitor the status of the entire call/session process of the call/session that triggers the routing decision control to the node through the original mechanism of the corresponding call control class interface. For example: In the cs domain, when the call control type interface is a CAP interface between the VMSC/GMSC and the SCP, the RPDP entity acting as the gsmSCF configures the basic call state of the call answer and/or call release to the VMSC/GMSC as the gsmSSF. The event detection point implements the monitoring of the entire process of the call controlled by the CS domain routing decision.
  • the RPDP entity acting as the AS is controlled by the Proxy mode. Keep the domain name added to the Record-Route header field, or keep it in the session path in a back-to-back user agent (B2BUA) mode to implement the entire process of the session controlled by the IMS domain routing decision. monitor.
  • the RPDP entity updates the locally saved user CS domain and/or IMS domain call state when the CS domain and/or IMS domain calls are established, and/or connected, and released.
  • the call forwarding status message may be modified by the other informed network entity to transmit the call status information to the RPDP entity; that is, in the embodiment shown in FIG.
  • the routing decision query request received by the RPDP entity in step 102 is actually an incoming call request message that has been modified in advance by the informed network entity, and the RPDP entity obtains call state information according to the incoming call request message.
  • the specific steps can be divided into two steps: In the communication system that implements the cross-domain routing control, the incoming call request message passes through an application server that monitors the call state before reaching the RPDP entity, and the application server that is the informed network entity continues to transmit the application. Before the incoming call request message, the incoming call request message is modified according to the current call state information, so that when the RPDP entity finally receives the modified message of the informed network entity as the routing decision query request, Get current call status information.
  • the call control type interface on which the routing decision query is based is an ISC interface between the S-CSCF and the AS in the IMS domain.
  • the S-CSCF actually triggers the processed service request to the corresponding AS according to the prioritized initial filtering criteria in the user subscription information, so that when an incoming call request is processed, If the priority of the initial filtering criterion corresponding to the AS that monitors the call state is higher than the priority of the initial filtering criterion corresponding to the AS of the RPDP entity, the incoming call request message will be sent to the monitored call state first.
  • the AS can modify the call state according to the call state before continuing to deliver the message, so that the RPDP entity can obtain the current call when finally receiving the modified message of the informed network entity as the routing decision query request. status information.
  • the following is an interactive update method that is applicable to both the call control-based interface mode and the non-call control-based interface mode, that is, the call is updated by interacting with other informed network entities.
  • Method of state information the so-called informed network entity refers to other network entities that understand the user's call state information, such as: a presence server, other application servers that monitor call status, or a CAMEL service control function entity, the user equipment itself, and the like.
  • the informed network entity notifies the RPDP entity of the change of the call state; the RPDP entity saves locally and updates according to the notification from the informed network entity. Call status information.
  • the interaction is performed after the user completes the IMS registration, and if the CS-based mechanism is used, the user completes the registration/location of the CS domain. The interaction is performed after the update.
  • the so-called interactive update process is: The RPDP entity locally saves the call state of the user in the CS/IMS domain.
  • the informed network entity that knows the current call state sends a corresponding state change notification to the RPDP entity, and the RPDP entity
  • the received status change notification updates the call status of the locally saved user in the CS/IMS domain.
  • the following four ways are given for the CS domain and the IMS domain: In the IMS domain, the SIP subscription and notification mechanism or the SIP publishing mechanism may be adopted; in the CS domain, the following may be adopted.
  • the first means for implementing the interactive update is the SIP subscription and notification mechanism.
  • the IMS domain-based SIP subscription and notification mechanism is used by the RPDP entity to subscribe to the related event in advance to the informed network entity that knows the current call state.
  • the specific steps include:
  • Step a The RPDP entity sends a SIP subscription message to the informed network entity that knows the current call state, and subscribes to the call state related event, and the informed network entity that knows the current call state returns the confirmation after accepting the subscription, and subscribes here.
  • the negotiation of the validity period of the subscription is completed in the process;
  • Step a2 when the informed network entity that knows the current call state finds that the call status of the user in the CS/IMS domain changes, the status change event is reported to the RPDP entity, and the RPDP entity returns an acknowledgement;
  • Step a3 Before the expiration of the negotiated subscription expiration date, the RPDP entity may send a new subscription message to the informed network entity that knows the current call state to perform subscription refresh according to the need.
  • the network entity accepts the subscription refresh and returns an acknowledgment, and completes the renegotiation and initiation of the subscription validity period during the subscription refresh process.
  • the so-called RPDP entity can perform subscription refresh as needed, which can be: determining that the user has not logged off from the IMS domain, or considering the user registration status, and only considering the cross-domain routing control logic of the RPDP entity itself.
  • the second means for implementing the interactive update is the SIP status release mechanism, which performs the interactive update of the call state information based on the SIP state release mechanism of the MS domain, that is, the informed network entity that knows the current call state according to the local configuration, and discovers that the user is in the CS.
  • the status change event is advertised to the RPDP entity through SIP PUBLISH.
  • the RPDP entity records the status, returns an acknowledgment, and the RPDP entity updates the locally maintained call status information.
  • the third method for implementing the interactive update is the USSD/SMS subscription and notification mechanism.
  • the CS domain USSD/SMS application completes the subscription and notification of related events. The specific steps include:
  • Step bl The RPDP entity sends an USSD message/SMS to the informed network entity that knows the current call state, and subscribes to the call state related event;
  • Step b2 When the informing network entity finds that the call state of the user in the CS domain and/or the IMS domain changes, the USSD/SMS reports the status change event to the RPDP entity, and the RPDP entity maintains the update user call state information locally.
  • the fourth way to implement the interactive update is the USSD/SMS status release mechanism.
  • the USSD/SMS status release mechanism is similar to the SIP status release mechanism, except that it is implemented in the CS domain based on the USSD/SMS application.
  • the informed network entity that knows the current call state according to the local configuration, advertises the state change event to the RPDP entity through the USSD/SMS when the call state of the user is changed in the CS/IMS domain, and the RPDP entity updates the call state information of the local maintenance guard. And return confirmation.
  • CS domain There are also two ways to implement instant query, CS domain and IMS domain, namely: SIP - secondary subscription and USSD / SMS query.
  • the IMS-based SIP-sub-subscription and notification mechanism includes: The RPDP entity sends a SIP subscription message to the informed network entity that knows the current call state when the current call state of the user needs to be obtained, and subscribes to the call state-related event, and the informed network entity The confirmation is returned after accepting the subscription, and the current status information is then returned.
  • the informed network entity does not actively notify the RPDP entity when the call state changes, and the RPDP entity does not need to save the maintenance locally.
  • the query of the related event is completed based on the CS domain USSD/SMS application, including: the RPDP entity sends a USSD/SMS message to the informed network entity that knows the current call state when the current call state of the user needs to be obtained, and performs a call state query, and the informed network entity subsequently
  • the current status information is reported to the RPDP entity by the USSD/SMS.
  • the informed network entity does not actively notify the RPDP entity when the call state changes, and the RPDP entity does not need to save the maintenance locally.
  • the RPDP entity and the informed network entity may be located in the same physical entity, and the RPDP entity obtains call state information from the informed network entity through the internal interface.
  • the present invention also considers that if the RPDP entity is implemented by the mutually independent logical entities in the CS domain and the IMS domain, in this case, the two entities need to synchronize the user call state information, which is implemented in FIG.
  • the logical entity of the RPDP entity in the CS domain and the logical entity in the IMS domain are independent of each other, a synchronization mechanism of the call state information is set between the two.
  • the two logical entities of the RPDP entity in the CS domain and the IMS domain may be combined in one physical entity or two physical entities. Therefore, when two logical entities are implemented in the same physical entity, The interface between the logical entities is an internal interface, and the synchronization mechanism of the call state information is implemented through the internal interface; when the two logical entities are implemented in two different physical entities, respectively, SIP, CAP, wireless intelligent network protocol, The above interaction is performed by any one of the intelligent network application procedures, USSD, SMS, or other custom manner.
  • the implementation means of the synchronization mechanism it can be divided into two methods: change time notification and use time inquiry.
  • the notification at the time of change means that when either of the synchronization parties obtains the user state change information, the other party is notified, and the other party updates the user state information based on the notification.
  • the so-called query in use means that when any one of the synchronization parties needs to know the user status information, the other party is queried to update the user status information, and the other party returns the user status information after receiving the query.
  • Fig. 2 is a general flow chart showing an inter-domain routing control scheme for obtaining current call state information of a user by locally monitoring a call state in a mode based on a call control type interface.
  • the GMSC After receiving the call setup request, the GMSC queries the HLR to which the called user belongs to the routing information.
  • the HLR returns the CAMEL subscription information of the called party according to the user subscription, and the GMSC triggers the CAMEL service on the called side according to the CAMEL subscription information of the called party, and passes the CAP.
  • the interface initiates a query for routing decisions to the RPDP entity that is the gsmSCF.
  • the specific protocols for interaction between the GMSC and the HLR and the intelligent network service control function in the GSM, WCDMA system CS domain and cdma2000 system CS domain are different, But the process and ability are the same.
  • the user's intelligent service is not triggered by the GMSC but triggered by the local switch of the user, but the service control process and capability of interacting with the fixed intelligent network service control function are also consistent.
  • the following only describes the CS domain of the WCDMA system as an example, and other situations are not described herein.
  • the RPDP entity interacts with the HLR/HSS to query the current registration status of the user in the CS/IMS domain. After learning that the user is currently registered in the CS/IMS domain, the RPDP entity further determines the current state of the call of the locally saved user in the two domains. It should be noted here that: In this embodiment, an optional pre-determination process for determining the registration status of the user in the two domains is adopted, because the user is actually impossible to be occupied in the domain that has not been registered yet, Adding this optional judgment can be regarded as an optimized implementation of the inventive scheme.
  • the RPDP entity determines the current routing decision based on the current routing policy.
  • the RPDP entity returns to the GMSC via the connection message to carry the CS/IMS domain interworking gateway MGCF.
  • the RPDP entity sends a request to the GMSC to report the basic call model event message (RRBE) to configure the call failure, the caller abandonment, the call answering, and the call release basic call model event detection point.
  • RRBE basic call model event message
  • the call response is optional, and the call state of the user in the IMS domain is set to preemption in combination with the routing decision made. If the call answer is not configured, it is directly set to occupy.
  • the GMSC routes the call to the CS/IMS domain interworking gateway MGCF according to the redirection number, and the MGCF continues to perform subsequent routing control in the IMS domain.
  • the GMSC reports a call answering event to the RPDP entity that is the gsmSCF when receiving the returning call response.
  • the RPDP entity sets the call state of the user in the IMS domain to be occupied.
  • the GMSC or the S-CSCF receives a new call/session establishment request, and initiates a query of the current routing decision to the RPDP entity in its original mode.
  • the GMSC is the triggering mode of the CAMEL service on the called side, the RPDP entity acts as the gsmSCF; the S-CSCF is the triggered mode of the called side of the IMS domain, and the RPDP entity acts as the AS; further, the CS domain and the IMS domain of the two independent logical entities
  • the RPDP entity needs to synchronize the above call state information through the internal or external interface between them.
  • the RPDP entity interacts with the HLR HSS to query the current registration status of the user in the CS/IMS domain. After the CS/MS domain is registered, the user is further determined that the locally saved user is currently in the call state of the two domains. Since the call state of the user is set to be occupied by the IMS domain, the RPDP entity determines that the current routing decision is to route in the IMS domain. And return the corresponding indication and routing information to the GMSC/S-CSCF.
  • the GMSC/S-CSCF performs subsequent routing to the IMS domain according to the received indication and information.
  • the call/session rejection is taken as an example of the call/session rejection of the new incoming call/session processing based on the subsequent call processing in the IMS domain call.
  • /S-CSCF returns to the calling side, respectively, that the call refuses to end the processing of the new incoming call/session.
  • the subsequent user completes the release of the previous call (Call 1) in the IMS domain.
  • the GMSC reports the call release event as the RPDP entity of the gsmSCF.
  • the RPDP entity sets the call state of the user in the IMS domain to idle. And instructing the GMSC to continue the process of releasing the call, and the GMSC continues to complete the call release.
  • the RPDP entity that is the gsmSCF sends a request to the GMSC as the gsmSSF to report a basic call model event message (RRBE), and configures a related basic call model event detection point to monitor user related entries.
  • RRBE basic call model event message
  • the processing status of the call status In order to monitor the outgoing state of the user in the CS domain, the VMSC that is currently the user of the gsmSSF is required to initiate a call control link to the RPDP entity that is the gsmSCF according to the user subscription data, and is used as the gsmSCF.
  • the RPDP entity delivers the basic call model event detection points related to the RRBE configuration to the VMSC as the gsmSSF, including call failure, caller abandonment, call answering (optional), and call release, and the VMSC as the gsmSSF is configured according to the configuration.
  • the corresponding processing phase of the call is reported to the RPDP entity that is the gsmSCF, and the RPDP entity performs the corresponding status update operation. Since it is also based on the existing capabilities of CAMEL, it will not be described later.
  • the process is basically the same; the difference is: For incoming and outgoing calls, the S-CSCF allocated for the user triggers the call according to the user subscription data. Establish a call control connection to the RPDP entity that is the AS, and then control it in the Proxy mode by the RPDP entity acting as the AS and add its own domain name to the Record-Route header field. The way, or in the B 2 BUA mode, keeps itself in the session path, thus monitoring the entire session process of the IMS domain.
  • FIG. 3 is a general flowchart of an inter-domain routing control scheme for obtaining current call state information of a user by performing interactive update with an informed network entity in a mode based on a call control type interface, wherein the user terminal is used as an informed network.
  • Entity, and, interactive updates are implemented using state event subscriptions and notification mechanisms.
  • the S-CSCF After the user is registered in the IMS domain, the S-CSCF returns a registration response to the user, and then initiates a third-party registration with the RPDP entity that is the AS according to the initial filtering criteria in the user subscription data, and returns the registration success response as the RPDP entity of the AS.
  • a subscription of a call state related event is initiated to the user terminal, where the initial subscription validity period is carried; the user terminal returns a subscription event subscription response and carries the final confirmed subscription validity period to complete the negotiation of the subscription validity period, and then sends an event subscription success notification.
  • the subsequent user initiates/receives a session in the IMS domain or the CS domain, and the user terminal sends a status change event notification to the RPDP entity that is the AS according to the previous subscription.
  • the user initiates/receives a session in the IMS domain as an example, and the RPDP entity This sets the call state of the user in the IMS domain to occupied.
  • the GMSC or S-CSCF receives a new call/session establishment request, and initiates a query of the current routing decision to the RPDP entity in its original mode.
  • the GMSC is the triggering mode of the CAMEL service on the called side, the RPDP entity acts as the gsmSCF; the S-CSCF is the triggered mode of the called side of the IMS domain, and the RPDP entity acts as the AS; further, the CS domain and the IMS domain of the two independent logical entities
  • the RPDP entity needs to synchronize the above call state information through an internal interface or an external interface therebetween.
  • the RPDP entity interacts with the HLR/HSS to query the current registration status of the user in the CS/IMS domain. After learning that the user is currently registered in the CS/IMS, the RPDP entity further determines that the locally saved user is currently in the two domains. Call status, since the user call status has been set to IMS occupancy, the RPDP entity determines that the current routing decision is to route in the IMS domain and returns corresponding indication and routing information to the GMSC/S-CSCF.
  • the GMSC/S-CSCF performs subsequent routing to the IMS domain according to the indication and information.
  • the subsequent call processing in the IMS domain call is a call/session rejection for the new incoming call/session processing result, and the GMSC/S-CSCF respectively Returning the call to the calling side refuses to end the processing of the new incoming call/session.
  • the subsequent user releases the previous call in the IMS domain, and the user terminal sends a status change event notification to the RPDP entity as the AS in the previous subscription, and the RPDP entity sets the call state of the user in the IMS domain to idle accordingly.
  • SIP subscription notification mode is adopted here> and the user subscribes and initiates the subscription to the third party of the AS to subscribe to the corresponding event, and other links initiate the subscription. If the user has already registered, the AS receives the operator instruction. Initiating is also effective. In addition, the manner in which the AS subscribes to the user terminal is adopted, and the AS can also perform other network entities that understand the call state of the user, such as the presence server, other gsmSCFs or ASs that monitor the entire call process of the user in the CS domain and/or the IMS domain. subscription.
  • the SIP change notification mode is used to implement the status change event notification, and the notification of the status change event can also be implemented by using the SIP status release mode, or by using the subscription notification or status release mechanism implemented by the CS domain-based USSD/SMS.
  • the main difference between the SIP-based USSD/SMS implementation of the subscription notification or status advertisement mechanism and the SIP-based implementation is:
  • the RPDP entity and the network entity responsible for the status change notification/publishing provide the USSD/SMS application to interact with the USSD/SMS in the CS domain.
  • the processing logic is basically the same.
  • FIG. 4 is a general flowchart of an inter-domain routing control scheme for obtaining current call state information of a user by performing an interactive update with an informed network entity in a mode based on a non-call control type interface, wherein the interactive update is a state release
  • the mechanism is implemented.
  • the implementation scheme of the cross-domain routing control based on the state change notification local maintenance call state is also adopted, which is different from FIG. 3: the state change notification is implemented by using the SIP state release mechanism, and the user terminal completes the E iS registration and the call state. When a change occurs, it is based on the previous settings.
  • the RPDP entity of the AS advertises the current call state.
  • the difference from FIG. 2 and FIG. 3 is that:
  • the second mode based on the non-call control interface is used to implement the routing decision query, and the cross-domain routing control is implemented, that is, the CS is intercepted by the RPDP entity as the STP.
  • the routing information of the GMSC to the HLR in the domain is queried, and then the current routing decision query is completed and the routing control is implemented according to the current decision.
  • the user terminal After the user completes the registration in the IMS domain, the user terminal advertises the current state (idle) to the RPDP entity that is the AS according to the configuration, and the RPDP entity returns a call state advertisement response, and sets the call state of the user in the IMS domain to idle according to the configuration;
  • the user initiates/receives a session in the IMS domain, and the user terminal advertises the current state change to the RPDP entity that is the AS according to the configuration.
  • the RPDP entity returns a call state change release response, and accordingly sets the call state of the user in the IMS domain to occupy.
  • the GMSC receives a new call setup request, and queries the called user's home HLR to query the routing information, and the STP RPDP entity intercepts the routing information query message, and then according to the user's registration status in the two domains and the user's call in the IMS domain.
  • the state determines that the current routing decision is to route in the IMS domain, and directly returns the corresponding indication and routing information to the GMSC, and the GMSC performs subsequent routing to the IMS domain according to the indication and the information, as shown in FIG. 3, based on the IMS domain call.
  • the call processing is a call rejection for this new arrival call processing result, and the GMSC returns to the calling side that the call refuses to end the processing of the new arrival call.
  • the subsequent user releases the previous call (call 1) in the IMS domain, and then advertises the current state change to the RPDP entity that is the AS according to the configuration.
  • the RPDP entity returns the call state change release response, and accordingly, the call state of the user in the IMS domain. Set to idle.
  • the user terminal is used to issue a call state to an RPDP entity that is an AS, and may also be used by other network entities that understand the user's call state, such as a presence server, and other monitoring users in the CS domain and/or the IMS domain.
  • the gsmSCF or AS, etc. issues the call state to the RPDP entity that is the AS.
  • the SIP status release mode is used to implement the status change event notification, and the status change event notification can also be implemented by using the SIP subscription notification mode, or by using a CS domain based
  • the CSSD-based USSD/SMS implements the subscription notification or status advertisement mechanism and the SIP-based subscription notification or status release mechanism.
  • the main area exchanges the corresponding subscriptions and notifications with the USSD/SMS interaction of the CS domain instead of the SIP message interaction on the IMS.
  • the status is released, and its processing logic is basically the same.
  • FIG. 3 and FIG. 4 respectively show the cross-domain of the current call state information of the user by querying with the informed network entity in the mode based on the call control type interface and the non-call control type interface.
  • Route control scheme It can be seen from the above description that the process of obtaining the current call state information of the user is actually obtained by interactively updating with the informed network entity, and is independent of the interface type between the RPDP entity itself and the routing decision query entity, and therefore, by performing with the informed network entity.
  • the scheme of interactively updating to obtain the current call state information of the user and different implementation methods thereof are actually applicable to the mode of implementing cross-domain routing control based on the call control type interface and the mode of implementing cross-domain routing control based on the non-call control type interface.
  • Figure 5 shows the overall flow chart of the cross-domain routing control scheme for obtaining the current call state information of the user by instant query to the informed network entity.
  • the difference from the embodiment shown in FIG. 4 is: an implementation scheme for performing cross-domain routing control by using an instant query call state, and providing the query to the user terminal based on the SIP on the IMS domain and the USSD/SMS on the CS domain. .
  • the difference from the previous figures is only the acquisition of the call state, and is applicable to the cross-domain routing control scheme based on the call control type interface or the non-call control type interface. And, for the subsequent call / session processing.
  • the embodiment shown in FIG. 5 adopts the implementation of the non-call control type interface in the CS domain, and the processing procedure thereof is the same as that in FIG. 4; the implementation of the call control class interface in the IMS domain is the same as that in FIG. 2 and FIG. 3.
  • the GMSC or S-CSCF receives the call/session establishment request. Before this, the user has initiated/received a session in the IMS domain, and the status is occupied. The difference from FIG. 4 is: When the IMS status changes to occupied, the user does not Notification or release of status changes.
  • the GMSC or the S-CSCF initiates a query for the current routing decision to the RPDP entity in its original manner; the GMSC queries the HLR for routing information and The STP RPDP entity intercepts the routing information query message; the S-CSCF is the IMS domain called side service triggering mode, and the RPDP entity acts as the AS; in this instant query mode, the CS domain and the IMS as two independent logical entities The RPDP entities of the domain can be queried independently of each other, and there is no need to synchronize the above call state information through the internal or external interface therebetween.
  • the RPDP entity interacts with the HLR/HSS to query the current registration status of the user in the CS/IMS domain. After the user is informed that the user is currently registered in the CS/IMS domain, the SIP-subsidiary subscription notification mode or USSD/SMS mode is further applied.
  • the terminal performs the current call state query, and according to the result obtained by the query (such as the IMS domain occupation), the RPDP entity determines that the current routing decision is to route in the IMS domain and return corresponding indication and routing information to the GMSC/S-CSCF.
  • the GMSC/S-CSCF performs subsequent route to the IMS domain according to the indication and the information, where the call/session rejection is performed on the new call/session processing result based on the subsequent call processing in the IMS domain call, and the GMSC/S-CSCF respectively
  • the calling side return call refuses to end the processing of the new incoming call/session.
  • the status becomes idle. Unlike the above diagram, the notification or release of the status change is not performed at this time.
  • the method for querying the current call state to the user terminal is adopted.
  • the RPDP entity can also refer to other network entities that understand the call state of the user, such as a presence server, other monitoring users in the CS domain, and/or The gsmSCF or AS of the entire call process in the IMS domain queries the current call status.
  • the S-CSCF receives the call/session establishment request.
  • the user has initiated/received a session in the IMS domain, and records the user status in an application server that monitors the call status.
  • the IMS domain is occupied.
  • the application server that is an informed network entity does not notify or advertise the state change to the RPDP entity, and the RPDP entity does not need to locally save the call state information of the user.
  • the S-CSCF actually triggers the processed service request to the corresponding AS according to the priority filtering criteria sequence in the user subscription information.
  • the priority of the initial filtering criterion corresponding to the AS that monitors the call state is higher than the priority of the initial filtering criterion corresponding to the AS of the RPDP entity.
  • the subsequent incoming call/session establishment request message will be sent by the S-CSCF to the AS in the monitoring call state, and after the AS completes its own controlled business logic processing, it also needs to be recorded according to the recorded
  • the current call state of the user modifies the call/session establishment request message, and then continues to deliver the call/session establishment request message to the S-CSCF according to the original processing for subsequent processing;
  • the above modification may be to add or rewrite a specific existing or existing extended SIP header field by the AS, such as the Location header field defined by drafl-ietf-sip-location-conveyance; or Yes, add a newly defined SIP header field to carry, or fill in the corresponding information in the SIP message body to carry.
  • the S-CSCF subsequently forwards the modified call/session establishment request message to the AS as the RPDP entity for routing decision query according to the lower priority initial filtering criterion matching result, it is different from the embodiment shown in FIG.
  • the PDP entity no longer needs to query the informed network entity for call state information, but obtains the current call state information directly from the modified message of the informed network entity as the routing decision query request.
  • the RPDP entity determines that the current routing decision is to route in the IMS domain, and returns corresponding indication and routing information to the S-CSCF.
  • the S-CSCF performs subsequent routing to the IMS domain according to the indication and the information, where the subsequent call processing in the IMS domain call is a call/session rejection for the new incoming call/session processing result, and the S-CSCF returns to the calling side respectively.
  • the call refuses to end the processing of the new incoming call/session.
  • the call state becomes idle.
  • the application server that monitors the call state as the informed network entity does not notify or release the status change to the RPDP entity.
  • the GSM system, the WCDMA system CS domain, the cdma 2000 system CS domain, and the PSTN network are all networks for providing circuit-switched services
  • the GSM system, the WCDMA system CS domain, the cdma 2000 system CS domain, and the PSTN network can be collectively referred to.
  • the IMS domain may include various standards such as 3GPP, 3GPP2, and TISPAN, unless otherwise specified.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种跨域路由控制方法 技术领域
本发明涉及路由控制技术, 特别涉及通信系统中的跨域路由控制方法。 发明背景
随着通信技术的突飞猛进, 人们对于个人通信的期望和要求也越来越高, 因此移动运营商需要特别关注用户界面、 业务质量等直接影响用户使用移动业 务的效果的方面。 第三代(3rd Generation, 3G )移动通信系统以其高带宽、 多 业务、 高质量等特点极大地吸引着移动消费市场, 但 3G技术中还存在一些影 响移动运营事务发展的问题没有解决, 比如在不断引入新的网络技术的同时如 何充分利用已有的网络资源, 如何综合利用不同网络技术的特点和能力为用户 提供更好的业务感受等等, 这将在一定程度上限制市场的进一步扩大。
在目前标准定义的 3G网络架构中, 移动网不再局限于电路交换的方式, 逐渐向分组网际协议 ( Internet Protocol, IP ) 交换网络演变。 从第三代移动通 信合作伙伴项目 ( 3rd Generation Partnership Project, 3 GPP ) 的 R5阶段开始, 通用移动电信系统 ( Universal Mobile Telecommunications System, UMTS ) 的 核心网被划分为电路交换域 (Circuit Switched, CS )、 分组交换域 (Packet Switched, PS )以及 IP多媒体子系统( IP Multimedia Subsystem, IMS )三个子 系统。
其中, CS域用于向用户提供电路型业务的连接, 主要包括的功能实体有: 移动交换中心( Mobile Switching Center, MSC )、 网关移动交换中心(Gateway Mobile Switching Center, GMSC )和网络互通功能实体( InterWorking Function, IWF )。 MSC用于完成电路交换型业务的交换和信令控制功能, MSC在控制与 承载分离的体系下又可以分为 MSC服务器(MSC Server )和电路域媒体网关 ( CS Media Gateway, CS-MGW ); GMSC用于在某一网络中完成移动用户的 路由寻址功能, 可与 MSC合设或分设; IWF与 MSC紧密相关, 完成公共陆地 移动网 ( Public Land Mobile Network, PLMN )与综合业务数据网 (Integrated Service Digital Network, ISDN )、公共交换通信网( Public Switch Telecommunication Network, PSTN ), 公共数据网 ( Public Data Network, PDN )等网络间 的互通, 主要实现信令转换功能, 具体功能根据业务和网络种类不同规定。
PS域用于向用户提供分组型业务的连接, 主要包括的功能实体是: 通用无 线分组服务支持节点( General Packet Radio Service Support Node, GSN;), 用于 完成分组业务用户的分组包传送。 GSN又分为服务 GSN ( Service GSN, SGSN ) 和网关 GSN ( Gateway GSN, GGSN ) 两种, 其中, SGSN用于提供核心网与 无线接入系统基站子系统(Base Station Subsystem, BSS )、 无线网络控制器
( adio Network Controller, RNC )的连接, 完成分组型数据业务的移动性管 理、 会话管理等功能, 管理移动台 ( Mobile Station, MS )在移动网络内的移动 和通信业务; 而 GGSN作为移动通信系统与其它公用数据网之间的接口, 同时 还具有查询位置信息的功能。 SGSN、 GGSN均提供计费信息。 另外, 在网络 边缘还设有边缘网关(Boarder Gateway, BG ), 用于完成两 GPRS网络间的互 通, 保证网络互通的安全性。
此外,还有一些 CS域、 PS域共用的功能实体,比如:归属位置寄存器(Home Location Register, HLR ) /鉴权中心( Authentication Center, AuC ), 其中, HLR 完成对用户签约数据和位置信息的管理, 如: 对移动台国际 ISDN 号码
( MSISDN ) , 国际移动用户标识 ( 1MSI , International Mobile Subscriber Identity )、 签约的电信业务和补充业务及其业务的适用范围、 MSC/VLR号、 SGSN号码等的管理; AuC则存储用户的鉴权算法和密钥。 其他还包括处理拜 访用户各种数据信息的拜访位置寄存器(Visit Location Register, VLR )、 存储 用户设备标识( International Mobile Equipment Identity, IMEI )信息的设备标识 寄存器(Equipment Identity Register, EER ) 以及短消息中心网关 MSC等等。 IMS 是 3GPP R5 阶段增加的宽带码分多址 (Wideband Code Division Multiple Access, WCDMA )网络中叠加在已有分组域之上的一个子系统, 采用 分组域作为上层控制信令和媒体传输的承载通道, 引入会话初始协议 ( Session Initial Protocol, SIP )作为业务控制协议, 利用 SIP简单、 易扩展、媒体组合方 便的特点, 通过将业务控制与承载控制分离, 提供丰富的多媒体业务。 IMS中 主要的功能实体包括: 控制用户注册、 会话控制等功能的呼叫会话控制功能实 体( Call Session Control Function, CSCF )、 提供各种业务逻辑控制功能的应用 服务器(Application Server, AS )、 集中管理用户签约数据的归属用户服务器
( Home Subscriber Server, HSS )以及用于实现与电路交换网互通的媒体网关 控制功能( Media Gateway Control Function, MGCF ) /IMS媒体网关功能( IMS Media Gateway, IM-MGW )。 用户通过当前所在地代理节点一代理呼叫会话控 制功能(Proxy CSCF, P-CSCF )接入 IMS , 而会话和业务触发控制以及与 AS 的业务控制交互则由该用户注册地的归属域服务节点- -服务呼叫^舌控制功能
( Service CSCF, S-CSCF ) 完成, 另一种查询节点一查询呼叫会话控制功能
( Interrogating CSCF, I-CSCF )则用于 IMS域的入口查询及网络拓朴隐藏功能。 IMS系统中的 HSS是 HLR的超集,功能上能够兼容 HLR,在具体组网中, HSS 与 CS/PS域的 HLR很可能是分设的。
由 3GPP标准所定义的 IMS架构全面解决了 IP承载下提供多媒体业务所需 解决的漫游计费、 服务质量(Quality of Service, QoS )、 安全保障等关键的可 运营问题, 其架构和思路已获得业界公认。 负责制定 cdma 2000系统技术规范 的第三代移动通 "标准化伙伴项目 2 ( 3GPP2 以及负责制定固网下一代网络 技术规范的标准組织 TISPAN均以 3GPP所定义的 IMS模型为基础,参照该 IMS 模型进行了相应 IP多媒体网络架构和业务体系的定义,也就是说, 由上述不同 标准组织定义的 IP多媒体系统有着一致的体系架构。
同时, 3GPP也已开始了针对无线局域网 (WLAN )接入与 UMTS 互通
( I-WLAN )、 固定宽带接入 IMS以及面向多种接入技术的全 IP网 ( AIPN )等 课题研究。 用户可以根据自己签约通过单一的多模终端、 或多种类型不同的终 端经由不同接入技术的接入网接入 IMS, 以获得统一的多媒体业务, 包括分组 语音(VoIP )业务; 其中, 3GPP R7通过一个研究 CS域呼叫与通过 WLAN接 入 IMS提供的 VoIP业务间业务连续性问题的工作课题, 提出了解决在用户作 为被叫时 CS/IMS域间的路由选择问题, 以适应网络及业务发展的需求。
在多域可用的新应用环境下, 为了拓宽用户业务的可选择性和多样性, 改 善运营商移动业务市场, 要求网络能够提供在多个域间选择接续语音通话的能 力, 比如: 能够选择使用 GSM、 WCDMA或 cdma 2000系统的 CS域及 PSTN 电路交换话音业务, 或各种移动或固定分组接入 IMS的 VoIP业务。 这就带来 了新的跨域路由问题, 即: 用户作为被呼叫方时, 呼入路由如何根据路由策略 等条件来选择不同域接续。 这一跨域路由问题的解决直接决定了用户是否能够 同时注册并灵活选择使用多域语音业务。
由于问题首先是在 3GPP中提出的, 以下描述多以 WCDMA系统 CS/IMS 域为例进行说明, 但是, 才 据以上说明, 实际上, 跨域路由控制需求同样存在 于 GSM、 cdma 2000 CS域、或 PSTN电路交换话音业务以及各种移动或固定分 组接入 IMS的 VoIP业务之间。
为了解决上述 CS/IMS域间的跨域路由问题, 现有的技术方案是: 在包括 CS/IMS域的系统中引入路由策略决策点( Routing Policy Decision Point, RPDP ) 实体,并在 CS/IMS域的路由控制过程中增加对该 RPDP实体的路由决策查询, 由该 RPDP实体根据用户在 CS/IMS域的当前路由决策相关信息、 以及本地存 储的预先设置的当前路由策略完成当前路由决策, 然后根据当前路由决策返回 据此决定的路由信息, 并控制 CS/IMS域中的路由控制实体完成当次呼叫 /会话 的后续路由控制。
现有技术方案根据用于实现路由决策查询的接口类型, 可以分为呼叫控制 类接口和非呼叫控制类接口两种典型实现模式。
在基于呼叫控制类接口的模式下, CS/IMS域中路由控制实体通过呼叫控 制类接口完成到 RPDP实体的路由决策查询, 比如: GSM系统或 WCDMA系 统 CS域中的 GMSC通过移动网增强逻辑客户化应用 ( Customised Application for Mobile network Enhanced Logic , CAMEL ) 业务的应用部分 ( CAMEL Application Part, CAP )接口完成到作为全球移动通信系统 (Global System of Mobile Communication, GSM ) 业务控制功能( GSM Service Control Function, gsmSCF )的 RPDP实体交互, 或者 cdma2000系统 CS域中 GMSC通过美国国 家标准化协会 -41移动应用协议 ( ANSI-41 MAP ) 完成与作为无线智能网业务 控制功能的 RPDP实体交互, 或者 PSTN网络中本地交换机通过智能网应用规 程完成与作为固定智能网业务控制功能的 RPDP 实体交互, 或者 IMS域中的 S-CSCF 通过 IMS 业务控制接口 (IP multimedia subsystem Service Control interface, ISC ) 完成到作为 AS的 RPDP实体交互, 完成当前路由决策查询并 根据当前决策实现路由控制。
在基于非呼叫控制类接口的模式下, CS/IMS 域中路由控制实体通过非呼 叫控制类接口完成到 RPDP 实体的路由决策查询, 比如: 作为信令转接点
( Signaling Transfer Point, STP )的 RPDP实体拦截 GSM、 WCDMA或 cdma2000 系统 CS域中的 GMSC到 HLR的路由信息查询消息; 或者 GSM、 WCDMA或 cdma2000系统 CS域中的 HLR收到 GMSC的路由信息查询消息后, 以新增接 口发起到新增 RPDP实体的查询; 或者 IMS域中的 HSS收到 I-CSCF的路由信 息查询消息后, 以新增接口发起到新增 RPDP实体的查询, 完成当前路由决策 查询并根据当前决策实现路由控制。
但是, 在上述两种模式中, RPDP 实体进行路由决策时所根据的用户当前 在 CS/IMS域的路由决策相关信息都是与 HLR HSS交互获得的,如在决策时由 RPDP实体向 HLR/HSS查询获得,或是在 RPDP实体本地保存,并由 HLR/HSS 在相关信息发生变化时主动向 RPDP实体更新, 由于 HLR/HSS并不了解用户 当前在 CS/IMS域的呼叫状态, 因此, 现有技术中进行路由决策时并未考虑用 户当前在两个域的呼叫状态。 也就是说, 没有考虑当用户同时在两个域注册的 情况下, 如何选择路由才能避免用户同时接入两个域的呼叫而只能接听其中一 个呼叫的问题。
在实际应用中, 由于用户终端上的音频输入输出模块(语音通道)只有一 个, 而且, 一般来说用户在同一时刻也只会接听一个呼叫, 因此虽然用户终端 有可能具备可以同时接入 CS/IMS域并建立呼叫 /会话的能力, 但事实上是无法 在 CS域和 IMS同时进行语音通话的。 这就需要在呼入路由时避免两个域的呼 入均接入到用户而用户只能接听一个呼叫的异常情况。
根据现有技术的条件, 在同一个域中当前业务能够处理多个呼叫或者有后 续呼叫的情况, 比如: 在 CS域中, 为了处理呼叫中的后续呼叫, 定义了相应 的补充业务, 如呼叫等待和呼叫保持、 多方通话、 以及遇忙前转等处理方法, 可以解决当前用户正在通话时如果再有呼入的情况。 在 IMS 中, 虽然没有象 CS域一样具体定义上述业务,但也提供了与上述业务类似特征的业务,可以处 理该类后续呼叫的情况。 但当用户同时在两个域注册, 且用户当前在其中一个 域通话, 而后续呼叫来自另外一个域时, 那么就无法再利用现有的一个域中的 后续业务处理方法来解决该问题。造成这种情况的主要原因在于:现有技术中, 在跨域路由控制过程中没有结合用户当前呼叫状态进行路由选择, 没有提供有 效的机制来避免后续呼叫进入不同域而导致两个域同时呼入的异常情况。
因此, 在解决两个域能够同时向用户提供通话业务之后, 还需要避免出现 当某用户在一个域进行通话时, 通过另一个域呼入到该用户的异常情况, 也就 是说, 如何将后续通话路由到与当前通话相同的域中, 从而利用现有技术中对 后续业务的已有处理机制, 如利用 CS域的补充业务等, 是有待解决的问题。
由于 GSM、 WCDMA或 cdma 2000 CS域有着类似的网络架构, PSTN、 GSM, WCDMA以及 cdma 2000中智能网架构基本相同, 并且, 不同标准组织 定义的 IP多媒体系统同样有着一致的体系架构,也就是说, 支持各种移动或固 定分组接入的 ΙΜδ有着一致的体系架构, 因此, 现有的跨域路由控制方案及以 上分析中存在的问题和解决该问题的需求在以上各种场景中也都是类似的。 发明内容
有鉴于此, 本发明的主要目的在于提供一种跨域路由控制方法, 能够 居 用户在不同域的呼叫状态对跨域路由进行控制。
一种跨域路由控制方法,在至少包含电路交换网络和 IMS域的系统中设置 用于保存路由策略信息的路由策略决策点 RPDP实体, 该方法还包括:
A、 当呼入请求路由时, 路由决策查询实体向所述 RPDP实体查询当前路 由决策;
B、 所述 RPDP实体根据当前路由策略、 路由决策相关信息、 以及用户当 前在所述电路交换网络和 /或 IMS域的呼叫状态, 确定路由决策;
C、 所述 RPDP 实体向所述路由决策查询实体返回根据所确定的路由决策 确定的路由相关信息, 由所述路由决策查询实体完成跨域路由控制。
步骤 B之前, 该方法进一步包括: 所述 PDP实体判断用户是否同时在所 述电路交换网络和 MS域注册。
步骤 B进一步包括:
Bl、 所述 RPDP实体获取用户当前在电路交换网络和 /或 IMS域的呼叫状 态;
B2、所述 RPDP实体根据所获取的呼叫状态选择将所述呼入请求路由到电 路交换网络或 IMS域;
B3、 根据步骤 B2的选择结果, 所述 RPDP实体进一步根据所述当前路由 策略及路由决策相关信息确定路由决策。
所述系统采用基于呼叫控制类接口的模式, 则步骤 Bl†, 所述 RPDP实 体通过自行监控获取用户当前在电路交换网络和 IMS域的呼叫状态并在本地 维护获得的呼叫状态信息, 且进一步包括:
bl 1、所述 RPDP实体通过所述呼叫控制类接口监控所述用户相关呼叫请求 的状态及其处理过程;
Μ2、 所迷 RPDP实体在用户相关呼叫的建立、 和 /或接通、 以及释放时更 新本地保存的呼叫状态信息。
其中, 步骤 B1所迷获取为: 所述 RPDP实体在本地维护并通过与知情网 络实体交互来获得更新的呼叫状态信息, 且进一步包括:
b21、在所述呼叫状态信息发生变化时,所述知情网络实体将所述呼叫状态 的变化通知所述 RPDP实体;
b22、所述 RPDP实体根据来自所述知情网络实体的通知来更新在本地保存 的所述呼叫状态信息。
步骤 b21所述通知为: 所迷知情网络实体通过所述 IMS域的 SIP订阅与通 知机制将所述呼叫状态的变化通知所述 RPDP实体, 具体包括:
xl 1、所述 RPDP实体通过 SIP订阅消息向所述知情网络实体订阅所述呼叫 状态相关事件的通知, 并协商订阅有效期;
xl2、在所协商的订阅有效期内,所述知情网络实体在所述呼叫状态发生变 化时, 通过 SIP通知消息向所述 RPDP实体上寺艮该呼叫状态变化事件。
步骤 b21所述通知为: 所述知情网络实体通过所述 IMS域的 SIP发布机制 将所述呼叫状态的变化通知 RPDP实体, 具体包括:
x21、所述知情网络实体在所述呼叫状态发生变化时,通过 SIP状态发布消 息向所述 RPDP实体发布所述呼叫状态变化事件;
x22、 所述 RPDP实体更新本地维护的所述呼叫状态信息, 并返回确认。 步驟 b21所述通知为: 所述知情网络实体通过非结构的补充业务数据业务 或短消息业务实现的订阅与通知机制将所述呼叫状态的变化通知所述 RPDP实 体, 具体包括:
x31、所述 RPDP实体通过发送非结构的补充业务数据请求或短消息向所述 知情网络实体订阅所述呼叫状态相关事件的通知;
x32、所述知情网络实体在所述呼叫状态发生变化时,通过发送非结构的补 充业务数据请求或短消息向所述 RPDP实体上报该呼叫状态变化事件。
步骤 b21所述通知为: 所述知情网络实体通过非结构的补充业务数据业务 或短消息业务实现的发布机制将所述呼叫状态的变化通知所述 RPDP实体, 具 体包括:
x4K所述知情网络实体在所述呼叫状态发生变化时,通过发送非结构的补 充业务数据请求或短消息向所迷 RPDP实体发布该呼叫状态变化事件;
χ42、 所述 RPDP实体更新本地维护的所述呼叫状态信息。
步骤 B1所述获取为: 所迷 RPDP实体通过即时查询知情网络实体来获得 呼叫状态信息, 且进一步包括:
b31、 所述 RPDP实体在需要获得呼叫状态时向所述知情网络实体查询; b32、 所迷知情网络实体返回当前的呼叫状态信息给所述 RPDP实体。 步骤 b31所述查询为: 所述 RPDP实体通过所述 IMS域的一次性 SIP订阅 与通知机制向所述知情网络实体查询所述呼叫状态 , 包含以下步骤:
y 11、所述 RPDP实体在需要获得呼叫状态时向所述知情网絡实体发送一次 性 SIP订阅消息;
yl2、所述知情网络实体在收到订阅后,通过 SIP通知消息返回当前的呼叫 状态信息给所述 RPDP实体。
步骤 b31所述查询为: 所迷 RPDP实体通过非结构的补充业务数据业务或 短消息业务向所述知情网络实体查询呼叫状态, 包含以下步骤:
y21、所述 RPDP实体在需要获得所述呼叫状态时向所述知情网络实体发送 非结构的补充业务数据消息或短消息,向所述知情网络实体查询呼叫状态信息; yl l、所述知情网络实体在收到消息后,通过非结构的补充业务数据消息或 短消息返回当前的呼叫状态信息给所述 RPDP实体。
上述方案中, 所述知情网络实体为监控呼叫状态的应用服务器;
步骤 A之前, 该方法进一步包括: 所述知情网络实体接收所述呼入请求消 息, 并根据当前的呼叫状态信息对所接收的呼入请求消息进行修改, 然后继续 传递修改后的呼入请求消息;
则步骤 A为: 路由决策查询实体向所述 RPDP实体转发经所述知情网络实 体修改后的呼入请求消息, 查询当前路由决策;
步驟 B1所迷获取为: 所述 RPDP根据所述知情网络实体修改后的呼入请 求消息, 获得呼叫状态信息, 且步骤 B1进一步包括:
b41、所述 RPDP实体接收到所述知情网络实体修改后的呼入请求消息,从 中获得当前的呼叫状态信息。
所述 RPDP实体和所述知情网络实体位于同一物理实体, RPDP实体通过 内部接口从知情网络实体获取所述呼叫状态信息。
所述 RPDP实体仅获得所迷电路交换网络和 IMS域中一个域的呼叫状态, 步骤 B2所述根据呼叫状态选择将呼入请求路由到电路交换网络或 IMS域具体 为: 判断用户在该域的呼叫状态, 如果是占用和 /或预占状态, 则选择在该域进 行后续路由, 如果是空闲状态, 则优先选择在另一个域进行后续路由; 或者, 所述 RPDP实体获得所述电路交换网络和 IMS域两个域的呼叫状态, 步驟 B2 所述根据呼叫状态选择将呼入请求路由到电路交换网络或 IMS域具体为:判断 用户在所述电路交换网络和 IMS域中是否均为空闲状态, 如果是, 则等优先级 选择其中一个域进行后续路由, 否则, 则选择用户处于占用和 /或预占状态的域 进行后续路由。
所述 RPDP实体在所述电路交换网络的逻辑实体和在所述 IMS域的逻辑实 体相互独立, 该方法进一步包括: 在两个相互独立的逻辑实体之间设置所述呼 叫状态信息的同步机制。
所述 RPDP实体在所述电路交换网络的逻辑实体和在所述 IMS域的逻辑实 体在同一物理实体内, 则所述呼叫状态信息的同步机制通过内部接口实现; 或 者,所述 RPDP实体在所述电路交换网络的遝辑实体和在所述 IMS域的逻辑实 体在不同物理实体内, 则所述呼叫状态信息的同步机制通过 SIP、 移动网增强 逻辑的客户化应用部分、 无线智能网协议、 智能网应用规程、 非结构的补充业 务数据、 短消息中的任意一种信令交互实现。
所述呼叫状态信息同步机制的实现具体包含以下步骤: 当同步双方中的任意一方获得所述用户的呼叫状态变化信息时, 通知另一 方, 另一方根据收到的通知更新本地保存的所述呼叫状态信息; 或者, 当同步 双方中的任意一方需要获知所述用户的呼叫状态信息时, 向另一方查询所述用 户的呼叫状态信息, 另一方收到查询后返回所述用户的呼叫状态信息。
上述方案中, 所述知情网络实体为: 监控呼叫状态的应用服务器、 呈现服 务器、 监控呼叫状态的业务控制功能实体、 或用户终端设备本身。 所述电路交 换网络包括但不限于: GSM系统、 WCDMA系统 CS域、 cdma 2000系统 CS 域、 PST 网络。
通过比较可见, 本发明的技术方案与现有技术的主要区别在于: 在接续路 由呼入清求时, 考虑用户在不同域的当前呼叫状态, 在其中一个域被呼叫占用 时, 选择将新的呼叫在同一个域进行后续路由处理, 从而避免在不同域同时接 入呼叫的异常情况, 而且可以继续将各个域现有的针对后续业务处理的补充业 务提供给用户。 进一步的, 本发明的方法具有以下的优点和特点:
1 )本发明通过针对是否采用呼叫控制类接口的情况分别提供相应的解决方 案, 且均采用现有的比如 USSD、 短消息业务( SMS )、 SIP等消息机制实现, 使得本发明能在现有技术基础上方便的升级或改进 , 不但保持了对现有技术很 好的兼容, 而且降低了发明的技术成本。 - 本发明中, 对于现有的呼叫控制类接口, RPDP 实体可以通过自行监控获 知呼叫状态并在本地维护; 或者由知情网络实体通过修改首先经过自身的呼入 请求消息, 将呼叫状态信息传递给 RPDP实体。 另外, 还提出了可以同时适用 于基于呼叫控制类接口和基于非呼叫控制类接口的方法, 即: RPDP 实体通过 与知情网络实体交互更新或即时查询获知呼叫状态的方法, 其中, 交互更新的 方法在 CS域可以通过基于非结构化补充业务数据 ( Unstructured Supplementary Services Data, USSD )或短消息实现的订阅与通知机制、 或基于 USSD或短消 息实现的发布机制来实现; 交互更新的方法在 IMS域, 则可以通过 SIP订阅与 通知机制、 或 SIP发布机制来实现。 而即时查询的方法在 CS域同样可以基于 USSD消息或短消息实现, 在 IMS域由 SIP消息实现。
2 )本发明分别在仅获知一个、或同时获知两个域的呼叫状态的情况下, 进 行选域路由, 尽量选择巳有呼叫被占用的那个域进行后续路由, 也就是说, 本 发明的技术方案通过考虑用户当前的呼叫状态实现跨域路由控制, 不但可以避 免在不同域同时接入呼叫的异常情况, 而且可以利用各个域的针对后续业务处 理的现有补充业务, 从而适应用户终端因只有一个音频 I/O模块不能同时在 CS/IMS域进行语音通话的情况,并且能继续提供在 CS/IMS域现有的针对呼叫 中后续呼叫处理相关的业务特征的处理需求。
3 )对于 CS域和 IMS域具有相互独立的 RPDP实体的情况,本发明采用内 部接口或外部的 SIP/CAP USSD/SMS等接口, 实现两者之间的同步机制, 保证 不同域的 RPDP实体间共享最新的呼叫状态信息, 保证基于呼叫状态的路由能 够准确实行, 提高了 RPDP实体跨域路由控制的可靠性。
4 )本发明进一步完善了现有的跨域路由控制方案,改善了用户的业务感受, 进一步促进了 CS、 WLAN及 IMS网络的应用与发展。 附图简要说明
图 1是本发明跨域路由控制方法一个实施例的实现流程图;
图 2是本发明实施例中基于本地监控呼叫状态机获得用户当前呼叫状态信 息的跨域路由控制信令交互流程图;
图 3是本发明实施例中基于事件订阅与通知机制获得用户当前呼叫状态信 息的跨域路由控制信令交互流程图;
图 4是本发明实施例中基于状态发布机制获得用户当前呼叫状态信息的跨 域路由控制信令交互流程图;
图 5是本发明实施例中基于即时查询机制获得用户当前呼叫状态信息的跨 域路由控制信令交互流程图。
图 6是本发明实施例中基于修改消息传递用户当前呼叫状态信息的跨域路 由控制信令交互流程图。 实施本发明的方式 为使本发明的目的、 技术方案和优点更加清楚, 下面将结合附图对本发明 作进一步地详细描述。
本发明所提出的跨域路由控制方法的主要思想是: 在对新呼入请求进行跨 域路由时, 先获取用户当前在两个域的呼叫状态, 并由 RPDP实体根据巳知呼 叫状态信息来尽量选择当前已占用的域对新呼入请求进行后续路由, 从而避免 两个不同域呼入同时接通的情况, 且能将现有的针对同一个域后续呼叫的补充 业务继续向新呼入请求提供。
这里, 首先介绍一下本发明中应用的几种现有机制, 即: CS域的 USSD/ SMS, IMS域的 SIP事件订阅与通知机制以及状态发布机制。
其中, USSD是一种 GSM PH2阶段引入的补充业务,终端和网络都能发起 USSD操作, 与短消息一样, USSD操作也可以在呼叫中发送, 但不同于短消 息的是: USSD是实时面向连接的, 也就是说, 在一个 USSD会话中, 一直保 持无线连接,提供透明管道, 没有存储转发, 并且, 在一次 USSD会话过程中, 支持多个连续的 USSD操作。 USSD操作的路由根据消息中的业务码 ( Service Code )决定, 提供 USSD应用的实体解析消息中的业务数据, 并根据业务逻辑 做出处理和响应; 通过 USSD, 运营商能够自行制定符合本地用户需求的相应 业务。 WCDMA系统 CS域继承了所迷 USSD业务。
需要说明的是: 在 cdma 2000系统的 CS域和 PSTN网络,并不支持 USSD 业务, 不过, 无论是 GSM、 WCDMA系统 CS域还是 cdma 2000系统的 CS域 和 PSTN网络, 都可以支持短消息业务。
IMS域的 SIP事件订阅与通知机制是一种 SIP扩展机制, 通过该扩展, 一 个 SIP用户代理可以向其他 SIP用户代理发起特定事件的订阅, 接到订阅请求 的用户返回应答, 欢方在请求和应答的交互中完成订阅有效期的协商, 之后, 接到订阅请求的用户按照一定的策略处理该订阅请求, 如是否需要授权等, 通 过授权后, 接到订阅请求的用户在协商确定的有效期内, 在有关该事件的状态 发生变化时向发起订阅的用户发送相应的事件通知; 在有效期内, 发起订阅的 用户可以通过重新发起订阅请求延长或终止订阅, 否则, 在到达所协商的有效 期时, 当次订阅自动终止。 通过发送有效期为 0的订阅请求, 可以实现仅被通 知当前状态的单次通知的订阅, 即当前状态的查询。
SIP状态发布机制是为了完成状态的主动发布定义的另一个扩展, 通过该 扩展, 允许客户端向状态发布代理发布其自身的事件状态, 而状态代理则充当 这些状态的汇聚者并根据订阅情况向订阅者发送相应的事件通知。
无论是 3GPP还是 3GPP2或者 TISPAN定义的 IP多媒体子系统, 均采用 SIP作为其端到端的会话控制协议, 因此, 也都支持上述的 SIP订阅与通知机 制以及 SIP发布机制。
在当前通信系统多域共存的语音业务应用环境中, 当用户选择使用不同接 入技术的终端接入 CS/IMS域时, 本发明根据为用户制定的路由策略、 用户在 不同域是否可及、 以及用户在各域的当前呼叫状态等信息, 在有 CS/IMS域呼 入请求到达该用户时,以增强跨域路由控制方法来选定该呼入请求的接续路由。 所述增强跨域路由控制方法是在现有技术方案的基础上增加了进一步根据用户 当前在 CS/IMS域的呼叫状态进行路由决策的处理, 以适应用户终端因只有一 个音频 I/O模块而不能同时在 CS域和 IMS域进行语音通话的情况, 以及继续 提供在 CS域和 IMS域已经具备的针对呼叫中的后续呼叫处理相关的业务特征 的处理需求。
本发明方法的关键技术在于: 如何获得用户的呼叫状态信息, 以及如何根 据已知的呼叫状态来选择决定哪个域进行后续路由。 本发明针对现有技术的基 于呼叫控制类接口的情况提出自行监控获得呼叫状态、 或由其它网络实体修改 消息传递呼叫状态的方法; 另外, 采用本发明提出的本地维护并与其它网络实 体交互更新、 或即时查询获得呼叫状态的方法, 则在基于呼叫类控制接口和非 呼叫控制类接口的情况都能适用。 其中, RPDP 实体与其它知情网络实体的交 互或查询, 在 CS域或 IMS域可以分別采用 USSD消息或短消息或 SIP消息的 相关机制来实现。 进一步的, 对于能够获得一个或两个域的呼叫状态信息的不 同情况, 本发明给出了尽量选择其中一个最有可能或已经被占用的域作为新呼 入请求的接续路由域的方法。除此之外,本发明还考虑了 RPDP实体在 CS/IMS 域作为独立逻辑实体的情况下, 如何实现两者之间对于用户当前呼叫状态信息 的同步更新, 用同一物理实体的内部接口、 或不同物理实体间的外部交互方法 实现同步。
如前所述, 一方面, 虽然跨域路由控制需求首先是在 3GPP中提出的, 但 实际上,该需求同样存在于 cdma 2000 CS域或 PSTN电路交换话音业务以及各 种移动或固定分组接入 IMS的 VoIP业务之间。 同时, 由于 GSM、 WCDMA或 cdma 2000 CS域有着类似的网络架构, PSTN、 GSM、 WCDMA以及 cdma 2000 中智能网架构基本相同, 并且, 不同标准组织定义的 IP多媒体系统同样有着一 致的体系架构, 也即支持各种移动或固定分組接入的 IMS 有着一致的体系架 构, 因此, 现有的跨域路由控制方案以及目前没有结合当前呼叫状态信息进行 跨域路由决策的问题, 和解决该问题的需求在以上各种场景中也都是类似的。 另一方面, 虽然在 cdma 2000系统的 CS域和 PSTN网络并不支持 USSD业务, 但无论是 GSM、 WCDMA系统 CS域还是 cdma 2000系统 CS域或 PSTN网络, 都可以支持短消息业务; 并且, 无论是 3GPP还是 3GPP2或者 TISPAN定义的 IP多媒体子系统, 均采用 SIP作为其端到端的会话控制协议, 因此, 也都支持 上述的 SIP 订阅与通知机制以及 SIP 发布机制。 所以, 虽然以下主要基于 WCDMA系统进行描述, 但本领域的技术人员可以理解, 本发明方案同样适用 于解决 GSM、 cdma 2000 CS域或 PSTN电路交换话音业务以及各种移动或固定 分組接入 IMS的 VoIP业务之间跨域路由控制问题。
第三代移动通信系统包含 CS域和 IMS域, 用户可以同时在两个域注册, 可以在两个域使用话音业务。作为现有技术, 可以在该系统中引入 RPDP实体, 并在 CS/IMS域路由控制过程中增加对该 RPDP 实体的路由决策查询, 由该 RPDP实体根据用户在 CS/IMS域的当前路由决策相关信息、 以及预先设置本 地存储的当前路由策略完成当前路由决策, 然后根据当前路由决策返回据此决 定的路由信息, 并控制 CS/IMS域中的路由控制实体完成当次呼叫 /会话的后续 路由控制。 在本发明中, RPDP 实体在进行路由决策时, 不仅考虑到当前路由 策略和其它相关信息, 还要结合用户在 CS/IMS域的呼叫状态。 其中, 完成路 由决策查询的实体称为路由决策查询实体。
本发明方法中整个跨域路由控制过程的主要步驟分为查询、 判断和返回, 其中关键步驟在于判断决策, 由于需要结合用户当前呼叫状态进行决策, 因此, 所述判断决策这一步进一步被细化为: 获取状态、 选域和决策三个子步骤, 再 可选的结合判断用户是否在两个域都注册的潜在条件, 整个跨域路由控制的流 程分为六个步骤, 该跨域路由控制一个实施例的实现流程图如图 1所示:
步骤 101: 当呼入倚求路由时, 路由决策查询实体向 RPDP实体查询当前 路由决策。
步骤 102: RPDP实体收到路由决策查询请求后判断用户是否同时在 CS域 和 IMS域注册, 如果是, 则需要考虑用户在两个域的当前呼叫状态, 进入步骤 103, 否则, 只需考虑路由策略等, 直接进入步骤 105。 在实际实现中, 该步驟 是可选的。
步驟 103: RPDP实体获取用户当前在 CS域和 IMS域的呼叫状态,然后进 入步骤 104。 这里, 由于 RPDP实体要考虑用户在两个域的当前呼叫状态进行 呼叫接续域的选择, 因此需要先通过相应手段获取用户当前在两个域的呼叫状 态。
步骤 104: RPDP实体根据获取的呼叫状态选择将呼入请求路由到 CS域或 IMS域。 这里, 选择的原则是将后续呼叫尽量接续到已有呼叫的域中。
步骤 103的获取用户当前呼叫状态和本步骤的选域过程是本发明的关键。 步骤 105: RPDP实体进一步根据当前路由策略及路由决策相关信息确定路 由决策。 本步骤是 RPDP实体进行路由决策的步驟, 可以看出, 如果需要考虑 用户在两个域的当前呼叫状态, 则需要基于步骤 104中选域的结果进一步进行 本步骤的路由决策。 比如: 步骤 104选择 CS域, 则本步骤就要在 CS域进行后 续路由; 或者步骤 104优先选择 CS域, 则本步骤就需要综合其它条件进行判 断选域路由。 这样, 就实现了 RPDP实体根据当前路由策略及路由决策相关信 息, 并结合用户当前在 CS/IMS域的呼叫状态, 确定路由决策。
步骤 106: RPDP实体向路由决策查询实体返回所确定的路由决策及路由相 关信息, 供路由决策查询实体完成跨域路由控制。
在上述流程中, 最关键的步骤是: RPDP 实体如何获取用户当前在不同域 的呼叫状态信息、 以及 RPDP实体如何根据已知呼叫状态进行选域判断。 下面 将给出四种获取用户当前呼叫状态信息的方案, 其中三种方案根据所应用的域 不同、 所使用的方式不同又分为若干种实现方式。 而对于选域判断则将给出详 细的准则, 菝盖已知其中任何一个域或全部两个域的呼叫状态的情况。
首先, 说明选域判断的详细准则, 在图 1所示的实施例中, 步骤 104根据 已知呼叫状态信息进行选域判断的详细准则可以是:
当 RPDP实体仅获得 CS域或 IMS域中一个域的呼叫状态时, 判断用户在 该域的呼叫状态, 如果是占用 /预占状态, 则选择在该域进行后续路由, 如果是 空闲状态, 则优先选择在另一个域进行后续路由, 这是因为在只知道一个域的 呼叫状态的情况下, 如果这个域确定已经占用 /预占的话,说明这个域肯定有呼 叫, 因此必须将新呼入倚求接续路由到该域; 如果这个域空闲, 那么只有另一 个域有可能有呼叫, 因此将新呼入请求接续路由到另一个域, 从而可以保证不 出现两个域同时呼入的异常情况。
当 RPDP实体同时能够获得 CS域和 IMS域两个域的呼叫状态时, 判断用 户在 CS域和 IMS域中是否均为空闲状态, 如果是, 则相等优先级任意选择其 中一个域进行后续路由,否则,选择用户处于占用 /预占状态的域进行后续路由。 这是因为在两个域均空闲的状态下, 新呼入请求无论在哪个域接续都不会出现 上述两个呼入的情况, 因此不做选择, 让 RPDP实体根据路由策略进行决策, 而如果其中有一个域出现占用 /预占的情况,则 RPDP实体要优先选择新呼入接 续到该域。 当然,.这里理论上不会出现两个域都被来话占用 /预占的情况。
接下来, 将按照获取状态的四种实现方案和每种方案的不同实现方式进行 分析。先根据前述是否使用呼叫控制类接口的两种模式,给出不同的实现方案: 对于采用呼叫控制类接口的模式, 可以采用筒单的由 RPDP实体自行监控 并本地维护的方案获取呼叫状态, 或者, 采用由其它知情网络实体修改先经过 自身的呼入请求消息, 再将呼叫状态信息传递给 RPDP实体的方案; 而对于采 用非呼叫控制类接口的模式, 则采用与其它知情网络实体进行交互更新, 或者 向知情网络实体即时查询这两种方案获取呼叫状态, 当然, 这两种方案同时也 都适用于使用呼叫控制类接口的模式。
下面几个实施例将具体给出这四种实现方案的技术细节。
首先, 在基于呼叫控制类接口的模式下, 可以由 RPDP实体采用自行监控 和本地维护的方法获得呼叫状态信息。也就是说,在图 1所示实施例的基础上, 步骤 103中的 RPDP实体通过自行监控来获得呼叫状态并在本地维护获得的呼 叫状态信息。 具体步驟可分为两步: 当通信系统通过呼叫控制类接口实现路由 决策查询时, RPDP 实体先通过呼叫控制类接口监控用户相关呼叫请求的状态 及其处理过程, 然后 RPDP实体根据用户相关呼叫的建立、 和 /或接通、 以及释 放情况更新本地保存的呼叫状态信息。
RPDP 实体可以通过相应呼叫控制类接口原有机制, 实现对触发到该节点 进行路由决策控制的呼叫 /会话的整个呼叫 /会话过程的状态监控。 比如: 在 cs 域中, 所述呼叫控制类接口为 VMSC/GMSC与 SCP间的 CAP接口时, 作为 gsmSCF的 RPDP实体通过向作为 gsmSSF的 VMSC/GMSC配置呼叫应答和 / 或呼叫释放的基本呼叫状态事件检测点, 实现对经过 CS域路由决策控制的呼 叫的整个过程的监控。 而在 IMS域中, 所述呼叫控制类接口为 IMS域中的 S-CSCF与 AS间的 ISC接口时, 作为 AS的 RPDP实体通过以 Proxy模式控制 并将自己的域名添加到 Record-Route 头域的方式、 或以背靠背用户代理 ( B2BUA )模式进行控制的方式将自己保留在会话路径中, 实现对经过 IMS 域路由决策控制的会话的整个过程的监控。同时, RPDP实体在 CS域和 /或 IMS 域呼叫建立、 和 /或接通、 以及释放时, 更新本地保存的用户 CS域和 /或 IMS 域呼叫状态。
其次, 在基于呼叫控制类接口的模式下, 还可以由其它知情网络实体修改 先经过自身的呼入请求消息, 从而将呼叫状态信息传递给 RPDP实体; 也就是 说, 在图 1所示实施例的 出上, 步骤 102中 RPDP实体所接收到的路由决策 查询请求实际上是已经预先经过知情网络实体修改的呼入请求消息, RPDP 实 体根据该呼入请求消息获得呼叫状态信息。 具体步驟可分为两步: 在实现跨域 路由控制的通信系统中呼入请求消息在到达 RPDP实体前先经过一个监控呼叫 状态的应用服务器, 则作为知情网络实体的该应用服务器在继续传递所述呼入 请求消息前, 根据当前的呼叫状态信息对所述呼入请求消息进行修改, 这样, 当 RPDP实体最 矣收到作为路由决策查询请求的所述知情网络实体修改后的 消息时, 从中获得当前的呼叫状态信息。
这一方案实际上应用于 IMS中,这时, 所述路由决策查询所基于的呼叫控 制类接口为 IMS域中的 S-CSCF与 AS间的 ISC接口。在现有 IMS中, S-CSCF 实际上是依据用户签约信息中的按优先级排列的初始过滤准则顺序将所处理的 业务请求触发到对应的 AS的, 这样, 在处理一个呼入请求时, 如果一个监控 呼叫状态的 AS所对应的初始过滤准则的优先级高于作为 RPDP实体的 AS所 对应的初始过滤准则的优先级, 则该呼入请求消息将会先被送到该监控呼叫状 态的 AS, 则该 AS就可以在将消息继续传递前根据呼叫状态进行修改,从而使 得 RPDP实体在最终接收到作为路由决策查询请求的所述知情网络实体修改后 的消息时 , 可以从中获得当前的呼叫状态信息。
下面给出一种同时适用于基于呼叫控制类接口模式和基于非呼叫控制类接 口模式的交互更新方法, 即采用与其它知情网络实体进行交互更新获得呼叫状 态信息的方法。 这里, 所谓知情网络实体是指其它了解用户呼叫状态信息的网 络实体, 比如: 呈现(Presence )服务器、 其他监控呼叫状态的应用服务器或 CAMEL业务控制功能实体、 用户设备本身等。 在图 1所示实施例的基础上, 步糠 103中: 在呼叫状态发生变化时, 知情网络实体将该呼叫状态的变化通知 RPDP实体; RPDP实体在本地保存并根据来自知情网络实体的通知更新呼叫状 态信息。 在知情网络实体是用户设备本身的情况下, 如果采用基于 IMS的机制 实现,则在用户完成 IMS注册后进行所述交互,如果采用基于 CS的机制完成, 则在用户完成 CS域的注册 /位置更新后进行所述交互。
所谓交互更新过程是: RPDP实体在本地保存用户在 CS/IMS域的呼叫状 态, 在呼叫状态发生变化时, 由了解当前呼叫状态的知情网络实体向 RPDP实 体发送相应的状态变化通知, RPDP 实体根据收到的状态变化通知更新本地保 存的用户在 CS/IMS域的呼叫状态。 至于如何实现所述的交互更新, 以下分别 给出针对 CS域和 IMS域的四种方式: 在 IMS域下, 可以采用 SIP订阅与通知 机制, 或者 SIP发布机制; 在 CS域下, 则可以采用基于 USSD/SMS应用实现 的订阅与通知机制, 或者基于 USSD/SMS应用实现的发布机制。
第一种实现交互更新的手段是 SIP订阅与通知机制 ,基于 IMS域的 SIP订 阅与通知机制, 由 RPDP实体预先向所述了解当前呼叫状态的知情网络实体进 行相关事件的订阅, 具体步骤包括:
步骤 al . RPDP实体向所述了解当前呼叫状态的知情网络实体发送 SIP订阅 消息, 进行呼叫状态相关事件的订阅, 所述了解当前呼叫状态的知情网络实体 接受该订阅后返回确认, 并在此订阅过程中完成订阅有效期的协商;
步骤 a2.在订阅有效期内, 当所述了解当前呼叫状态的知情网络实体发现 用户在 CS/IMS域呼叫状态发生变化时,就向 RPDP实体上报该状态变化事件, RPDP实体返回确认;
步骤 a3.在所协商的订阅有效期到期前, RPDP实体可以根据需要向所述 了解当前呼叫状态的知情网络实体发送新的订阅消息进行订阅刷新, 所述知情 网络实体接受该订阅刷新后返回确认, 并在此订阅刷新过程中完成订阅有效期 的重新协商与启动。 这里, 所谓 RPDP实体可以根据需要进行订阅刷新, 可以 是:判断用户仍然没有从 IMS域注销,或者不考虑用户注册状态,仅考虑 RPDP 实体自身的跨域路由控制逻辑需要。
第二种实现交互更新的手段是 SIP状态发布机制,基于 MS域的 SIP状态 发布机制完成呼叫状态信息的交互更新, 即, 由了解当前呼叫状态的知情网络 实体根据本地配置, 在发现用户在 CS域和 /或 IMS域呼叫状态发生变化时, 通 过 SIP PUBLISH向 RPDP实体发布该状态变化事件, RPDP实体记录该状态, 返回确认, RPDP实体更新本地维护的呼叫状态信息。
第三种实现交互更新的手段是 USSD/SMS订阅与通知机制, 基于 CS域 USSD/SMS应用完成相关事件的订阅和通知, 具体步骤包括:
步骤 bl. RPDP实体向了解当前呼叫状态的知情网络实体发送 USSD消息 /SMS , 进行呼叫状态相关事件的订阅;
步骤 b2. 当所述知情网络实体发现用户在 CS域和 /或 IMS域呼叫状态发生 变化时, 以 USSD/SMS向 RPDP实体上报该状态变化事件, RPDP实体在本地 维护更新用户呼叫状态信息。
第四种实现交互更新的手段是 USSD/SMS状态发布机制, USSD/SMS状态 发布机制与 SIP状态发布机制类似, 只是这里是在 CS域基于 USSD/SMS应用 实现。了解当前呼叫状态的知情网络实体根据本地配置,在发现用户在 CS/IMS 域呼叫状态发生变化时, 通过 USSD/SMS向 RPDP实体发布该状态变化事件, RPDP实体更新本地维.护的呼叫状态信息, 并返回确认。
熟悉本领域的技术人员可以理解, 上面列出四种在 CS域或 IMS 域实现 RPDP 实体与其它知情网络实体进行交互更新的手段, 可以用其它可行的交互 更新机制代替, 同样能实现发明目的而不影响本发明的实盾和范围。
最后, 给出另外一种同时适用于基于呼叫控制类接口模式和基于非呼叫控 制类接口模式的方法, 即: 与交互更新并列的即时查询方法。 在图 1所示实施 例的基 上, PDP 实体在需要获知用户当前呼叫状态信息时, 即时向其它知 情网絡实体查询获得呼叫状态信息, 即: RPDP 实体不在本地保存用户在 CS/IMS 域的呼叫状态, 而是在需要获得呼叫状态时, 向知情网络实体查询, 知情网络实体返回当前的呼叫状态信息给 RPDP实体。
实现即时查询也有 CS 域和 IMS 域的两种手段, 即: SIP —次性订阅和 USSD/SMS查询。
基于 IMS域的 SIP—次性订阅与通知机制, 包括: RPDP实体在需要获得 用户当前呼叫状态时向了解当前呼叫状态的知情网络实体发送 SIP订阅消息, 进行呼叫状态相关事件的订阅, 知情网络实体接受该订阅后返回确认, 并在随 后返回当前状态信息。 这里, 知情网络实体在呼叫状态变化时并不主动通知 RPDP实体, RPDP实体也并不需要在本地保存维护。
基于 CS域 USSD/SMS应用完成相关事件的查询, 包括: RPDP实体在需 要获得用户当前呼叫状态时向了解当前呼叫状态的知情网络实体发送 USSD/SMS 消息, 进行呼叫状态的查询, 知情网络实体随后以 USSD/SMS 向 RPDP 实体上报当前状态信息。 同样的, 知情网络实体在呼叫状态变化时并不 主动通知 RPDP实体, RPDP实体也并不需要在本地保存维护。
熟悉本领域的技术人员可以理解, 上述两种在 CS域或 IMS域实现 RPDP 实体向其它知情网络实体即时查询用户当前呼叫状态的手段, 可以用其它可行 的查询机制代替, 同样能实现发明目的而不影响本发明的实质和范围。
在上述 RPDP实体获取用户在不同域的呼叫状态的各种实现方案中, 所述 RPDP实体和知情网络实体可以位于同一物理实体中, 则 RPDP实体通过内部 接口从知情网络实体获取呼叫状态信息。
至此, 上文已给出本发明增强跨域路由控制方法的具体实现流程, 并给出 了关键步驟如获取呼叫状态、选域准则等的具体实现手段及其技术细节。此外, 本发明还考虑如果 RPDP实体在 CS域和 IMS域由相互独立的逻辑实体分别实 现的情况, 这样的话, 两个实体需要同步用户呼叫状态信息, 在图 1所示实施 例的基 上, 当 RPDP实体在 CS域的逻辑实体和在 IMS域的逻辑实体相互独 立时, 两者之间设置呼叫状态信息的同步机制。
进一步的, RPDP实体在 CS域和在 IMS域的两个逻辑实体可以合设在一 个物理实体中, 也可以分为两个物理实体, 因此, 对于两个逻辑实体在同一物 理实体实现时, 两个逻辑实体之间的接口为内部接口, 呼叫状 ^态信息的同步机 制通过内部接口实现; 当两个逻辑实体分别在两个不同的物理实体实现时, 采 用 SIP、 CAP、 无线智能网协议、 智能网应用规程、 USSD、 SMS中的任意一种 信令, 或其他自定义方式进行上述交互。
此外, 按照同步机制的实现手段不同, 还可以分为变化时通知和使用时查 询两种方式。 其中, 所谓变化时通知, 就是当同步双方中的任意一方获得用户 状态变化信息时, 通知另一方, 另一方根据该通知更新用户状态信息。 所谓使 用时查询, 就是当同步双方中的任意一方需要获知用户状态信息时, 向另一方 查询更新用户状态信息, 另一方收到查询后返回用户状态信息。
熟悉本领域的技术人员可以理解, 上面所列出的两种接口实现方式和两种 同步机制实现方式, 可以用其它可行的接口和同步机制代替, 比如当两个逻辑 实体在同一物理实体实现时, 可以采用读写共享数据区的方式获得同步的呼叫 状态信息, 同样能实现发明目的而不影响本发明的实质和范围。
综上所述, 下面结合附图给出采用各种接口、 各种交互机制, 进行增强跨 域路由控制的信令交互的整体流程图。
图 2示出的是在基于呼叫控制类接口的模式下, 用本地监控呼叫状态获得 用户当前呼叫状态信息的跨域路由控制方案的总体流程图。
GMSC收到呼叫建立请求后,向被叫用户归属的 HLR查询路由信息, HLR 根据用户签约返回用户被叫侧 CAMEL签约信息, GMSC根据该被叫侧 CAMEL 签约信息触发被叫侧 CAMEL业务,通过 CAP接口向作为 gsmSCF的 RPDP实 体发起路由决策的查询。这里, 虽然在 GSM、 WCDMA系统 CS域和 cdma2000 系统 CS域中 GMSC与 HLR以及智能网业务控制功能间交互的具体协议不同, 但其过程及能力是一致的。 在 PSTN网络中, 虽然没有路由查询过程, 用户的 智能业务也不是由 GMSC触发而是由用户所在本地交换机触发的,但与固定智 能网业务控制功能交互的业务控制过程及能力也是一致的。 以下仅以 WCDMA 系统 CS域为例进行说明, 不再赘述其它情况。
RPDP实体与 HLR/HSS交互查询用户当前在 CS/IMS域的注册状态, 当获 知用户当前在 CS/IMS域都已注册后, 进一步判断本地保存的用户当前在两个 域的呼叫状态。 这里需要说明的是: 在本实施例中, 采用了可选的先行判断用 户在两个域的注册状态的处理, 这是因为用户实际上是不可能在其尚未注册的 域被占用的, 因此, 增加这一可选判断可视为本发明方案的一种优化实现。
由于用户呼叫状态初始设置为空闲, RPDP 实体根据当前路由策略确定当 前路由决策。 这里, 以决策在 IMS 域接续为例, RPDP 实体通过连接消息向 GMSC返回携带指向 CS/IMS域互通网关 MGCF的?文发号码; 在此之前, 为了 监控整个呼叫过程, RPDP实体向 GMSC下发请求报告基本呼叫模型事件消息 ( RRBE )配置呼叫失败、 主叫放弃、 呼叫应答及呼叫释放基本呼叫模型事件 检测点, 其中呼叫应答为可选的, 并且结合所做的路由决策, 将用户在 IMS域 的呼叫状态设置为预占, 若未配置呼叫应答, 则直接设置为占用。
GMSC根据改发号码将呼叫路由至所述 CS/IMS域互通网关 MGCF, 由 MGCF继续完成后续在 IMS域的路由控制。 当配置呼叫应答检测点时, GMSC 在收到返回的呼叫应答时向作为 gsmSCF 的 RPDP 实体上报呼叫应答事件, RPDP实体设置用户在 IMS域的呼叫状态为占用。
之后 , GMSC或 S-CSCF收到新的呼叫 /会话建立请求, 通过各自原有方式 向 RPDP实体发起当前路由决策的查询。 GMSC为被叫侧 CAMEL业务触发方 式, RPDP实体作为 gsmSCF; S-CSCF则是 IMS域被叫侧业务触发方式, RPDP 实体作为 AS; 进一步的, 作为两个独立逻辑实体的 CS域和 IMS域的 RPDP 实体需要通过其间的内部或外部接口进行上述呼叫状态信息的同步。
RPDP实体与 HLR HSS交互查询用户当前在 CS/IMS域的注册状态, 当获 知用户当前在 CS/MS域都已注册后, 进一步判断本地保存的用户当前在两个 域的呼叫状态, 由于用户呼叫状态已设置为 IMS域占用, RPDP实体确定当前 路由决策为在 IMS域路由并向 GMSC/S-CSCF返回相应的指示及路由信息。
GMSC/S-CSCF根据收到的指示及信息进行后续到 IMS域的路由, 这里, 以基于 IMS域呼叫中后续呼叫处理对这一新到呼叫 /会话处理结果为呼叫 /会话 拒绝为例, GMSC/S-CSCF分别向主叫侧返回呼叫拒绝结束该新到呼叫 /会话的 处理。
后续用户在 IMS域完成前一呼叫 (呼叫 1 )的释放, GMSC收到呼叫释放 消息后 ^作为 gsmSCF的 RPDP实体上报呼叫释放事件, RPDP实体据此将用 户在 IMS域的呼叫状态设置为空闲, 并指示 GMSC继续完成呼叫释放的处理, GMSC继续完成呼叫释放。
需要说明的是, 本实施例体现的是: 作为 gsmSCF 的 RPDP 实体向作为 gsmSSF的 GMSC下发请求报告基本呼叫模型事件消息(RRBE ), 配置相关的 基本呼叫模型事件检测点, 以监控用户相关入呼状态的处理情况。 为了监控用 户在 CS域的呼出状态, 还需要在用户发起呼叫时, 由作为 gsmSSF的用户当 前所在的 VMSC根据用户签约数据向作为 gsmSCF的 RPDP实体进行智能业务 触发建立呼叫控制链接, 并由作为 gsmSCF的 RPDP实体向作为 gsmSSF 的 VMSC下发 RRBE配置相关的基本呼叫模型事件检测点, 包括呼叫失败、 主叫 放弃、 呼叫应答(可选)以及呼叫释放, 则作为 gsmSSF的 VMSC根据该配置 在所述呼叫的相应处理阶段向作为 gsmSCF的 RPDP实体上报, RPDP实体进 行相应的状态更新操作。 由于同样基于 CAMEL现有的能力实现, 后续不再赘 述。
此外, 当此处第一个呼叫在 IMS域进行路由决策查询时, 过程基本相同; 所不同的是: 针对呼入和呼出呼叫, 均由为用户分配的 S-CSCF根据用户签约 数据将呼叫触发至作为 AS的 RPDP实体建立呼叫控制连接, 然后由作为 AS 的 RPDP实体通过以 Proxy模式控制并将自己的域名添加到 Record-Route头域 的方式、 或是以 B2BUA模式进行控制的方式, 将自己保留在会话路径中, 从 而实现对 IMS域整个会话过程的监控。
图 3示出的是在基于呼叫控制类接口的模式下, 通过与知情网络实体进行 交互更新来获得用户当前呼叫状态信息的跨域路由控制方案的总体流程图, 其 中, 由用户终端作为知情网络实体, 并且, 交互更新是采用状态事件订阅与通 知机制实现的。
与图 2不同的是: 这里采用基于交互更新和本地维护呼叫状态进行跨域路 由控制的实现, 而交互更新则采用 SIP订阅通知机制实现。 用户在 IMS域注册 时, 由作为 AS的 RPDP实体根据收到的第三方注册请求向用户终端进行相应 事件的订阅。 由于同样是基于呼叫控制类接口的模式, 这里 CS/IMS域对于后 续呼叫 /会话的处理与图 2相同。
用户在 IMS域进行注册, S-CSCF向用户返回注册成功的响应后, 根据用 户签约数据中的初始过滤准则向作为 AS的 RPDP实体发起第三方注册, 作为 AS的 RPDP实体返回注册成功响应, 随后向用户终端发起呼叫状态相关事件 的订阅, 其中携带初始订阅有效期; 用户终端返回订阅事件订阅响应并携带最 终确认的订阅有效期以完成订阅有效期的协商, 随后发送事件订阅成功通知。 后续用户在 IMS域或 CS域发起 /接收一个会话,用户终端根据先前的订阅向作 为 AS的 RPDP实体发送状态变化事件通知,这里以用户在 IMS域发起 /接收一 个会话为例, 则 RPDP实体据此将用户在 IMS域的呼叫状态设置为占用。
之后, GMSC或 S-CSCF收到新的呼叫 /会话建立请求, 通过各自原有方式 向 RPDP实体发起当前路由决策的查询。 GMSC为被叫侧 CAMEL业务触发方 式, RPDP实体作为 gsmSCF; S-CSCF则是 IMS域被叫侧业务触发方式, RPDP 实体作为 AS; 进一步的, 作为两个独立逻辑实体的 CS域和 IMS域的 RPDP 实体需要通过其间的内部接口、 或外部接口进行上述呼叫状态信息的同步。
RPDP实体与 HLR/HSS交互查询用户当前在 CS/IMS域的注册状态, 当获 知用户当前在 CS/IMS都巳注册后, 进一步判断本地保存的用户当前在两个域 的呼叫状态, 由于用户呼叫状态已设置为 IMS占用, RPDP实体确定当前路由 决策为在 IMS域路由, 并向 GMSC/S-CSCF返回相应的指示及路由信息。
GMSC/S-CSCF根据该指示及信息进行后续到 IMS域的路由, 这里, 基于 IMS 域呼叫中后续呼叫处理对这一新到呼叫 /会话处理结果为呼叫 /会话拒绝, GMSC/S-CSCF分别向主叫侧返回呼叫拒绝结束该新到呼叫 /会话的处理。
后续用户在 IMS域完成前一呼叫的释放,用户终端 居先前的订阅向作为 AS的 RPDP实体发送状态变化事件通知, RPDP实体据此将用户在 IMS域的 呼叫状态设置为空闲。
需要说明的是: 这里采用了 SIP订阅通知模式 > 并且采用用户注册并发起 向 AS的第三方注册的时机点进行相应事件的订阅, 其他环节发起订阅, 如用 户已注册, AS收到操作员指示发起, 也同样有效。 另外, 这里采用了 AS向用 户终端订阅的方式, AS也可向其他了解用户呼叫状态的网络实体,如 Presence 服务器、 其他监控用户在 CS域和 /或 IMS域整个呼叫过程的 gsmSCF或 AS等 进行订阅。
这里, 采用 SIP订阅通知模式实现状态变化事件通知, 状态变化事件的通 知还可以采用 SIP状态发布模式实现, 或者采用基于 CS域的 USSD/SMS实现 的订阅通知或状态发布机制实现。 基于 CS域的 USSD/SMS实现订阅通知或状 态发布机制与基于 SIP的实现的主要区别是: RPDP实体与负责状态变化通知 / 发布的网络实体提供 USSD/SMS应用,以 CS域的 USSD/SMS交互而不是 IMS 上的 SIP消息交互承载相应的订阅与通知以及状态发布,其处理逻辑基本一致。
图 4示出的是在基于非呼叫控制类接口的模式下, 通过与知情网络实体进 行交互更新来获得用户当前呼叫状态信息的跨域路由控制方案的总体流程图, 其中交互更新是采用状态发布机制实现的。
这里, 同样采用基于状态变化通知本地维护呼叫状态进行跨域路由控制的 实现方案, 与图 3不同的是: 状态变化通知采用 SIP状态发布机制实现, 由用 户终端在完成 E iS 注册后以及呼叫状态发生变化时, 根据预先的设置向作为 AS的 RPDP实体发布当前的呼叫状态。
同时, 与图 2、 图 3的不同之处还在于: 在 CS域采用了基于非呼叫控制类 接口完成路由决策查询的第二种模式实现跨域路由控制, 即由作为 STP 的 RPDP实体拦截 CS域中的 GMSC到 HLR的路由信息查询消息,进而完成当前 路由决策查询并根据当前决策实现路由控制。
用户完成在 IMS域的注册后, 用户终端根据配置向作为 AS的 RPDP实体 发布当前状态(空闲), RPDP实体返回呼叫状态发布响应,并据此将用户在 IMS 域的呼叫状态设置为空闲; 后续用户在 IMS域发起 /接收一个会话, 用户终端 根据配置再次向作为 AS的 RPDP实体发布当前状态变化, RPDP实体返回呼 叫状态变化发布响应, 并据此将用户在 IMS域的呼叫状态设置为占用。
之后, GMSC收到新的呼叫建立请求, 向被叫用户归属 HLR查询路由信 息, 作为 STP的 RPDP实体拦截该路由信息查询消息, 进而根据用户在两个域 的注册状态以及用户在 IMS域的呼叫状态, 确定当前路由决策为在 IMS域路 由,并直接向 GMSC返回相应的指示及路由信息, GMSC根据该指示及信息进 行后续到 IMS域的路由, 与图 3—样, 基于 IMS域呼叫中后续呼叫处理对这 一新到呼叫处理结果为呼叫拒绝, GMSC向主叫侧返回呼叫拒绝结束该新到呼 叫的处理。
后续用户在 IMS域完成前一呼叫 (呼叫 1 )的释放, 根据配置再次向作为 AS的 RPDP实体发布当前状态变化, RPDP实体返回呼叫状态变化发布响应, 并据此将用户在 IMS域的呼叫状态设置为空闲。
需要说明的是: 这里, 采用用户终端向作为 AS的 RPDP实体发布呼叫状 态, 也可由其他了解用户呼叫状态的网络实体, 如 Presence服务器、 其他监控 用户在 CS域和 /或 IMS域整个呼叫过程的 gsmSCF或 AS等,向作为 AS的 RPDP 实体发布呼叫状态。
此外, 这里采用的是 SIP状态发布模式实现状态变化事件通知, 状态变化 事件的通知同样可以采用 SIP订阅通知模式实现, 或者采用基于 CS 域的 USSD/SMS实现的订阅通知或状态发布机制实现。 基于 CS域的 USSD/SMS实 现订阅通知或状态发布机制与基于 SIP实现的订阅通知或状态发布机制主要区 以 CS域的 USSD/SMS交互而不是 IMS上的 SIP消息交互承载相应的订阅与通 知以及状态发布, 其处理逻辑基本一致。
此外, 图 3和图 4所示两个实施例分别给出了基于呼叫控制类接口和基于 非呼叫控制类接口的模式下, 通过与知情网络实体进行查询来获得用户当前呼 叫状态信息的跨域路由控制方案。 由上述说明可以看出, 实际上通过与知情网 络实体进行交互更新来获得用户当前呼叫状态信息的处理, 与 RPDP实体自身 和路由决策查询实体间的接口类型无关, 因此, 通过与知情网络实体进行交互 更新来获得用户当前呼叫状态信息的方案及其不同的实现方法, 实际上同时适 用于基于呼叫控制类接口实现跨域路由控制的模式和基于非呼叫控制类接口实 现跨域路由控制的模式。
图 5所示的是通过向知情网络实体即时查询, 来获得用户当前呼叫状态信 息的跨域路由控制方案的总体流程图。
与图 4所示实施例不同的是: 这里采用即时查询呼叫状态进行跨域路由控 制的实现方案,并提供了基于 IMS域上 SIP和基于 CS域上 USSD/SMS的方式 向用户终端完成该查询。
这里, 与前面各图的区別仅在于呼叫状态的获取, 适用于基于呼叫控制类 接口或非呼叫控制类接口的跨域路由控制方案。 并且, 针对后续呼叫 /会话的处 理。 图 5所示实施例在 CS域采用非呼叫控制类接口的实现,其处理过程与图 4 相同; 在 IMS域采用呼叫控制类接口的实现, 其处理过程与图 2、 图 3相同。
GMSC或 S-CSCF收到呼叫 /会话建立请求,在此之前,用户已在 IMS域发 起 /接收一个会话, 状态为占用, 与图 4不同的是: 用户在 IMS状态更改为占 用时, 并不进行状态变化的通知或发布。 GMSC或 S-CSCF通过各自原有方式 向 RPDP实体发起当前路由决策的查询; GMSC向 HLR查询路由信息并由作 为 STP的 RPDP实体拦截该路由信息查询消息; S-CSCF则是 IMS域被叫侧业 务触发方式, RPDP实体作为 AS; 这种即时查询的方式下, 作为两个独立逻辑 实体的 CS域和 IMS域的 RPDP实体可以彼此独立查询, 并不需要通过其间的 内部或外部接口进行上述呼叫状态信息的同步。
RPDP实体与 HLR/HSS交互查询用户当前在 CS/IMS域的注册状态 , 当获 知用户当前在 CS/IMS域都已注册后, 进一步的, 以 SIP—次性订阅通知方式 或 USSD/SMS方式向终端进行当前呼叫状态的查询,根据查询获得的结果(如 IMS 域占用 ), RPDP 实体确定当前路由决策为在 IMS 域路由并向 GMSC/S-CSCF返回相应的指示及路由信息。
GMSC/S-CSCF根据该指示及信息进行后续到 IMS域的路由,这里基于 IMS 域呼叫中后续呼叫处理对这一新到呼叫 /会话处理结果为呼叫 /会话拒绝 , GMSC/S-CSCF分别向主叫侧返回呼叫拒绝结束该新到呼叫 /会话的处理。
后续用户在 IMS域完成前一呼叫 (呼叫 1 ) 的释放, 状态变为空闲, 与上 面的图不同的是, 此时并不进行状态变化的通知或发布。
需要说明的是: 这里采用向用户终端进行当前呼叫状态的查询方式, 基于 同样的机制 , RPDP实体也可向其他了解用户呼叫状态的网络实体,如 Presence 服务器、其他监控用户在 CS域和 /或 IMS域整个呼叫过程的 gsmSCF或 AS等, 进行当前呼叫状态的查询。
最后, 结合图 6所示的跨域路由控制方案的总体流程图, 说明由其它知情 网络实体修改先经过自身的呼入请求消息, 从而将呼叫状态信息传递给 RPDP 实体的跨域路由控制方案。
这里, 与前面各图所示实施例的区别仍然在于呼叫状态的获取, 并且, 仅 适用于在 IMS域中基于呼叫控制类接口的跨域路由控制方案。 针对后续呼叫 / 会话的处理, 图 6的处理过程与图 2、 图 3、 图 5中 IMS域的处理部分相同。
如图 6所示, S-CSCF收到呼叫 /会话建立请求, 在此之前, 用户已在 IMS 域发起 /接收一个会话,在一个监控呼叫状态的应用服务器中记录该用户状态为 IMS域占用。 并且, 与图 4所示实施例不同, 作为知情网络实体的该应用服务 器并不向 RPDP实体进行状态变化的通知或发布, RPDP实体也无需在本地保 存用户的呼叫状态信息。
在现有 IMS域中, S-CSCF实际上是依据用户签约信息中的按优先级排列 的初始过滤准则顺序, 将所处理的业务请求触发到对应的 AS。 在本实施例中, 针对 S-CSCF收到的呼叫 /会话建立请求, 所述监控呼叫状态的 AS所对应的初 始过滤准则的优先级高于作为 RPDP实体的 AS对应的初始过滤准则的优先级, 因此, 该后续呼入的呼叫 /会话建立请求消息将会被 S-CSCF先送到该监控呼叫 状态的 AS, 该 AS完成其自己控制的业务逻辑处理后,还要 >据所记录的该用 户当前呼叫状态对呼叫 /会话建立请求消息进行修改,然后再按原有处理将呼叫 /会话建立请求消息继续传递给 S-CSCF, 以进行后续处理;
由于 SIP协议本身具有良好的可扩展性, 上述修改可以是由 AS增加或改 写特定的现有或现有扩展的 SIP头域, 如 drafl-ietf-sip-location-conveyance定义 的 Location头域; 或是, 增加新定义的 SIP头域来携带、 或者将相应信息填写 在 SIP消息体中来携带。
这样, 当 S-CSCF后续根据较低优先级的初始过滤准则匹配结果, 将经过 修改的呼叫 /会话建立请求消息转发至作为 RPDP实体的 AS进行路由决策查询 时, 与图 5所示实施例不同, 该 PDP实体不再需要向知情网络实体进行呼叫 状态信息的查询, 而是直接从作为路由决策查询请求的所述知情网络实体修改 后的消息中获得当前的呼叫状态信息。根据所获得的呼叫状态信息, 如 IMS域 占用, RPDP实体确定当前路由决策为在 IMS域路由, 并向 S-CSCF返回相应 的指示及路由信息。
S-CSCF根据该指示及信息进行后续到 IMS域的路由, 这里基于 IMS域呼 叫中后续呼叫处理对这一新到呼叫 /会话处理结果为呼叫 /会话拒绝, S-CSCF分 别向主叫侧返回呼叫拒绝结束该新到呼叫 /会话的处理。
后续用户在 IMS域完成前一呼叫 (呼叫 1 )的释放, 呼叫状态变为空闲, 与图 4所示实施例不同的是: 此时作为知情网络实体的监控呼叫状态的应用服 务器也并不向 RPDP实体进行状态变化的通知或发布。
由于 GSM系统、 WCDMA系统 CS域、 cdma 2000 系统 CS域以及 PSTN 网络都是用于提供电路交换型业务的网络, 因此,可以将 GSM系统、 WCDMA 系统 CS域、 cdma 2000系统 CS域以及 PSTN网络统称为电路交换网络; 同样 的, 由于由 3GPP、 3GPP2以及 TISPAN等各种标准组织定义的 IMS有着基本 一致的架构, 如果没有特别的说明, 则 IMS域可以包括由 3GPP、 3GPP2以及 TISPAN等各种标准组织定义的、 各种移动或固定分组接入的 IMS。
总之, 以上所述仅为本发明的较佳实施例而已, 并非用于限定本发明的保 护范围。

Claims

权利要求书
1、 一种跨域路由控制方法, 在至少包含电路交换网络和 IMS域的系统中 设置用于保存路由策略信息的路由策略决策点 RPDP实体, 其特征在于, 该方 法还包括:
A、 当呼入请求路由时, 路由决策查询实体向所述 RPDP实体查询当前路 由决策;
B、 所述 PDP实体根据当前路由策略、 路由决策相关信息、 以及用户当 前在所述电路交换网络和 /或 IMS域的呼叫状态, 确定路由决策;
C、 所述 RPDP实体向所述路由决策查询实体返回根据所确定的路由决策 确定的路由相关信息, 由所述路由决策查询实体完成跨域路由控制。
2、 根据权利要求 1所述的跨域路由控制方法, 其特征在于, 步骤 B之前, 该方法进一步包括: 所述 RPDP实体判断用户是否同时在所述电路交换网络和 IMS域注册。
3、 根据权利要求 1所述的跨域路由控制方法, 其特征在于, 步骤 B进一 步包括:
Bl、 所述 PDP实体获取用户当前在电路交换网络和 /或 IMS域的呼叫状 态;
B2、所述 RPDP实体根据所获取的呼叫状态选择将所述呼入请求路由到电 路交换网络或 IMS域;
B3、 根据步骤 B2的选择结果, 所述 RPDP实体进一步根据所述当前路由 策略及路由决策相关信息确定路由决策。
4、根据权利要求 3所述的跨域路由控制方法,其特征在于, 所述系统采用 基于呼叫控制类接口的模式, 则步驟 B1中, 所述 RPDP实体通过自行监控获 取用户当前在电路交换网络和 IMS域的呼叫状态并在本地维护获得的呼叫状 态信息, 且进一步包括: b 11、所述 RPDP实体通过所述呼叫控制类接口监控所迷用户相关呼叫请求 的状态及其处理过程;
bl2、 所述 RPDP实体在用户相关呼叫的建立、 和 /或接通、 以及释放时更 新本地保存的呼叫状态信息。
5、 根据权利要求 3所述的跨域路由控制方法, 其特征在于, 步驟 B1所述 获取为: 所述 RPDP实体在本地维护并通过与知情网络实体交互来获得更新的 呼叫状态信息, 且进一步包括:
b21、在所述呼叫状态信息发生变化时,所述知情网络实体将所述呼叫状态 的变化通知所述 RPDP实体;
b22、所述 RPDP实体 居来自所述知情网络实体的通知来更新在本地保存 的所述呼叫状态信息。
6、根据权利要求 5所述的跨域路由控制方法,其特征在于, 步驟 b21所述 通知为: 所述知情网络实体通过所述 IMS域的 SIP订阅与通知机制将所述呼叫 状态的变化通知所述 RPDP实体, 具体包括:
xl 1、所述 RPDP实体通过 SIP订阅消息向所述知情网络实体订阅所述呼叫 状态相关事件的通知, 并协商订阅有效期;
xl2、在所协商的订阅有效期内,所述知情网络实体在所述呼叫状态发生变 化时, 通过 SIP通知消息向所述 RPDP实体上报该呼叫状态变化事件。
7、根据权利要求 5所述的跨域路由控制方法,其特征在于, 步骤 b21所述 通知为: 所述知情网络实体通过所述 IMS域的 SIP发布机制将所述呼叫状态的 变化通知 RPDP实体, 具体包括:
x21、所述知情网络实体在所述呼叫状态发生变化时,通过 SIP状态发布消 息向所述 RPDP实体发布所述呼叫状态变化事件;
x22、 所述 RPDP实体更新本地维护的所述呼叫状态信息, 并返回确认。
8、根据权利要求 5所述的跨域路由控制方法,其特征在于, 步骤 b21所述 通知为: 所述知情网络实体通过非结构的补充业务数据业务或短消息业务实现 的订阅与通知机制将所述呼叫状态的变化通知所述 RPDP实体, 具体包括: x31、所述 RPDP实体通过发送非结构的补充业务数据请求或短消息向所述 知情网络实体订阅所述呼叫状态相关事件的通知;
x32 所述知情网络实体在所述呼叫状态发生变化时,通过发送非结构的补 充业务数据请求或短消息向所述 PDP实体上报该呼叫状态变化事件。
9、根据权利要求 5所述的跨域路由控制方法,其特征在于, 步驟 b21所述 通知为: 所述知情网络实体通过非结构的补充业务数据业务或短消息业务实现 的发布机制将所述呼叫状态的变化通知所述 RPDP实体, 具体包括:
x41、所述知情网络实体在所述呼叫状态发生变化时,通过发送非结构的补 充业务数据请求或短消息向所述 RPDP实体发布该呼叫状态变化事件;
x42、 所述 RPDP实体更新本地维护的所述呼叫状态信息。
10、 根据权利要求 3所述的跨域路由控制方法, 其特征在于, 步骤 B1所 述获取为: 所述 RPDP实体通过即时查询知情网络实体来获得呼叫状态信息, 且进一步包括:
b31、 所述 RPDP实体在需要获得呼叫状态时向所述知情网络实体查询; b32、 所述知情网络实体返回当前的呼叫状态信息给所述 RPDP实体。
11、 居权利要求 10所述的跨域路由控制方法, 其特征在于, 步骤 b31 所述查询为: 所述 RPDP实体通过所述 IMS域的一次性 SIP订阅与通知机制向 所述知情网络实体查询所述呼叫状态, 包含以下步骤:
y 11、所述 RPDP实体在需要获得呼叫状态时向所述知情网络实体发送一次 性 SIP订阅消息;
yl2、所述知情网络实体在收到订阅后,通过 SIP通知消息返回当前的呼叫 状态信息给所述 RPDP实体。
12、 根据权利要求 10所述的跨域路由控制方法, 其特征在于, 步骤 b31 所述查询为: 所述 RPDP实体通过非结构的补充业务数据业务或短消息业务向 所述知情网络实体查询呼叫状态, 包含以下步骤: y21、所述 RPDP实体在需要获得所述呼叫状态时向所述知情网络实体发送 非结构的补充业务数据消息或短消息,向所述知情网络实体查询呼叫状态信息; yll、所述知情网络实体在收到消息后,通过非结构的补充业务数据消息或 短消息返回当前的呼叫状态信息给所述 RPDP实体。
13、 根据权利要求 3所述的跨域路由控制方法, 其特征在于, 所述知情网 络实体为监控呼叫状态的应用服务器;
步骤 A之前, 该方法进一步包括: 所述知情网络实体接收所述呼入请求消 息, 并根据当前的呼叫状态信息对所接收的呼入请求消息进行修改, 然后继续 传递修改后的呼入请求消息;
则步骤 A为:路由决策查询实体向所述 RPDP实体转发经所述知情网络实 体修改后的呼入请求消息, 查询当前路由决策;
步骤 B1所迷获取为: 所述 RPDP根据所述知情网络实体修改后的呼入请 求消息, 获得呼叫状态信息, 且步骤 B1进一步包括:
b41、所述 RPDP实体接收到所述知情网络实体修改后的呼入请求消息,从 中获得当前的呼叫状态信息。
14、 根据权利要求 5至 12任一项所述的跨域路由控制方法, 其特征在于, 所述 RPDP实体和所述知情网络实体位于同一物理实体, RPDP实体通过内部 接口从知情网络实体获取所述呼叫状态信息。
15、 根据权利要求 3至 13任一项所述的跨域路由控制方法, 其特征在于, 所述 RPDP实体仅获得所述电路交换网络和 IMS域中一个域的呼叫状态, 步骤 B2所述根据呼叫状态选择将呼入请求路由到电路交换网络或 IMS域具体 为: 判断用户在该域的呼叫状态, 如果是占用和 /或预占状态, 则选择在该域进 行后续路由, 如果是空闲状态, 则优先选择在另一个域进行后续路由;
或者,
所述 RPDP实体获得所述电路交换网络和 IMS域两个域的呼叫状态,步骤 B2所述根据呼叫状态选择将呼入请求路由到电路交换网络或 IMS域具体为: 判断用户在所述电路交换网络和 IMS域中是否均为空闲状态, 如果是, 则等优 先级选择其中一个域进行后续路由, 否则, 则选择用户处于占用和 /或预占状态 的域进行后续路由。
16、 根据权利要求 3至 13任一项所述的跨域路由控制方法, 其特征在于, 所述 RPDP实体在所述电路交换网络的逻辑实体和在所述 IMS域的逻辑实体相 互独立, 该方^进一步包括: 在两个相互独立的逻辑实体之间设置所述呼叫状 态信息的同步机制。
17、 根据权利要求 16所述的跨域路由控制方法, 其特征在于,
所述 RPDP实体在所述电路交换网络的逻辑实体和在所述 IMS域的逻辑实 体在同一物理实体内, 则所述呼叫状态信息的同步机制通过内部接口实现; 或者,
所述 RPDP实体在所述电路交换网络的逻辑实体和在所述 IMS域的逻辑实 体在不同物理实体内, 则所述呼叫状态信息的同步机制通过 SIP、 移动网增强 逻辑的客户化应用部分、 无线智能网协议、 智能网应用规程、 非结构的补充业 务数据、 短消息中的任意一种信令交互实现。
18、根据权利要求 16所述的跨域路由控制方法, 其特征在于, 所述呼叫状 态信息同步机制的实现具体包含以下步骤:
当同步双方中的任意一方获得所述用户的呼叫状态变化信息时, 通知另一 方, 另一方根据收到的通知更新本地保存的所述呼叫状态信息;
或者,
当同步双方中的任意一方需要获知所述用户的呼叫状态信息时, 向另一方 查询所述用户的呼叫状态信息, 另一方收到查询后返回所述用户的呼叫状态信
'¾·。
19、 根据权利要求 5至 12任一项所述的跨域路由控制方法, 其特征在于, 所述知情网络实体为: 监控呼叫状态的应用服务器、 呈现服务器、 监控呼叫状 态的业务控制功能实体、 或用户终端设备本身。
20、 根据权利要求 1至 13任一项所述的跨域路由控制方法, 其特征在于, 所迷电路交换网络包括但不限于: GSM系统、 WCDMA系统 CS域、 cdma 2000 系统 CS域、 PSTN网络。
PCT/CN2006/001673 2005-08-04 2006-07-14 Commande de routage interdomaine WO2007014510A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN200680011717XA CN101156395B (zh) 2005-08-04 2006-07-14 一种跨域路由控制方法
EP06753141.8A EP1892897B2 (en) 2005-08-04 2006-07-14 A cross-domain routing control method
US11/965,834 US8170565B2 (en) 2005-08-04 2007-12-28 Method and apparatus of domain selection for routing control

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200510028494.5 2005-08-04
CNB2005100284945A CN100505899C (zh) 2005-08-04 2005-08-04 第三代移动通信系统的跨域路由控制方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/965,834 Continuation US8170565B2 (en) 2005-08-04 2007-12-28 Method and apparatus of domain selection for routing control

Publications (1)

Publication Number Publication Date
WO2007014510A1 true WO2007014510A1 (fr) 2007-02-08

Family

ID=37700652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/001673 WO2007014510A1 (fr) 2005-08-04 2006-07-14 Commande de routage interdomaine

Country Status (4)

Country Link
US (1) US8170565B2 (zh)
EP (1) EP1892897B2 (zh)
CN (2) CN100505899C (zh)
WO (1) WO2007014510A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009056063A1 (fr) * 2007-10-26 2009-05-07 Huawei Technologies Co., Ltd. Procédé, dispositif et système de demande d'informations dans une architecture pcc
WO2016078290A1 (zh) * 2014-11-17 2016-05-26 中兴通讯股份有限公司 路由短消息的方法及装置、计算机存储介质

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7613835B2 (en) * 2003-09-08 2009-11-03 Sony Corporation Generic API for synchronization
US7925790B2 (en) * 2003-09-17 2011-04-12 Sony Corporation Middleware filter agent between server and PDA
US8046019B2 (en) * 2006-08-04 2011-10-25 Futurewei Technologies, Inc. Method and system for optimal allocation of uplink transmission power in communication networks
US20080056236A1 (en) * 2006-08-31 2008-03-06 Deborah Lewandowski Barclay Unified IMS supplementary services signaling across circuit and packet domains
US8325654B2 (en) 2006-12-28 2012-12-04 Futurewei Technologies, Inc. Integrated scheduling and power control for the uplink of an OFDMA network
EP2094026B1 (en) * 2007-02-15 2017-11-15 Huawei Technologies Co., Ltd. Method, system and device for domain switching
US7995562B2 (en) * 2007-02-26 2011-08-09 Research In Motion Limited System and method to trigger a mobile device in different domains based on unsuccessful initialization or handover
US9055517B2 (en) * 2007-02-26 2015-06-09 Blackberry Limited System and method of user-directed dynamic domain selection
CN101287276B (zh) * 2007-04-13 2011-08-24 华为技术有限公司 一种呼叫处理方法及系统
US20090040951A1 (en) * 2007-08-10 2009-02-12 Research In Motion Limited Systems and Methods for Defining Multi-Domain Wireless Device Behavior for Two or More Calls
CN101933311A (zh) * 2008-01-30 2010-12-29 爱立信电话股份有限公司 促进ims中的预订服务
KR20140046076A (ko) 2008-03-21 2014-04-17 인터디지탈 패튼 홀딩스, 인크 패킷 교환 도메인으로부터 회선 교환 도메인으로의 폴백 방법 및 장치
CN101646205B (zh) * 2008-08-05 2014-07-09 华为技术有限公司 移动网络高速接入公网的节点、方法及系统
JP5004899B2 (ja) * 2008-08-11 2012-08-22 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法、交換局及び移動局
CN101674221A (zh) * 2008-09-09 2010-03-17 中国移动通信集团公司 静态路由生成方法、终端路由实现方法及装置
WO2010045960A1 (en) * 2008-10-21 2010-04-29 Telefonaktiebolaget Lm Ericsson (Publ) Handling set up of a session in a gsm-ims overlay network
CN101742475B (zh) * 2008-11-12 2012-01-11 华为技术有限公司 订阅和通知的方法、装置和系统
JP2010130396A (ja) * 2008-11-28 2010-06-10 Hitachi Ltd 管理装置
CN101631389B (zh) * 2009-07-28 2012-02-29 中兴通讯股份有限公司 Ip多媒体子系统异常提示音媒体播放方法及系统
KR101650608B1 (ko) 2009-10-30 2016-08-23 인터디지탈 패튼 홀딩스, 인크 무선 통신을 위한 시그널링
CN106027579A (zh) * 2010-01-04 2016-10-12 上海贝尔股份有限公司 一种提供域间服务的方法和设备
CN102271050B (zh) * 2010-06-04 2014-04-30 华为技术有限公司 一种IPv6网络中网络设备自动配置的方法、网络设备和系统
CN102469012B (zh) * 2010-11-12 2016-03-30 中兴通讯股份有限公司 路由查询装置及方法
US9509547B2 (en) 2010-12-07 2016-11-29 Telefonaktiebolaget Lm Ericsson (Publ) Selection of service domain in IMS centralised services
CN102868667B (zh) * 2011-07-07 2015-10-07 中国移动通信集团公司 业务优先级的标识方法、装置和系统
JP5740229B2 (ja) * 2011-07-08 2015-06-24 株式会社Nttドコモ 移動通信方法及び呼セッション制御サーバ装置
US9179273B2 (en) * 2011-12-06 2015-11-03 Samsung Electronics Co., Ltd. Apparatus and method for delivering short message service efficiently in wireless communication system
US9456400B2 (en) 2012-04-02 2016-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Best effort call routing preference setting
DE102012012389A1 (de) * 2012-06-21 2013-01-24 Daimler Ag Vorrichtung und Verfahren zum Steuern einer Zugangsberechtigung und/oder Fahrberechtigung für ein Fahrzeug
CN105992159B (zh) * 2015-02-27 2019-04-05 北京信威通信技术股份有限公司 实现漫游用户呼叫状态订阅的方法和系统
EP3275141B1 (en) 2015-03-25 2018-11-21 British Telecommunications public limited company Mobile telecommunications routing
CN105049222B (zh) * 2015-04-20 2018-12-18 中国电信股份有限公司 用于实现传输网络跨域管理的方法、装置和系统
ES2803226T3 (es) * 2015-11-27 2021-01-25 Vodafone Ip Licensing Ltd Encaminamiento de llamadas de voz de sistema de telecomunicaciones
US11044360B1 (en) * 2015-12-17 2021-06-22 8X8, Inc. Dynamic direction of incoming calls
US10938914B2 (en) * 2016-01-18 2021-03-02 Avaya Inc. Inter domain instant messaging bridge
US10348902B1 (en) 2016-06-23 2019-07-09 8X8, Inc. Template-based management of telecommunications services
US11671533B1 (en) 2016-06-23 2023-06-06 8X8, Inc. Programming/data sets via a data-communications server
US10404759B1 (en) 2016-06-23 2019-09-03 8×8, Inc. Client-specific control of shared telecommunications services
US10165114B1 (en) 2016-06-23 2018-12-25 8X8, Inc. Intelligent call handling and routing
US11412084B1 (en) 2016-06-23 2022-08-09 8X8, Inc. Customization of alerts using telecommunications services
US11044365B1 (en) 2016-06-23 2021-06-22 8X8, Inc. Multi-level programming/data sets with decoupling VoIP communications interface
US11647087B1 (en) 2016-06-23 2023-05-09 8X8, Inc. Intelligent call handling and routing
CN106911713B (zh) * 2017-03-31 2021-01-15 宇龙计算机通信科技(深圳)有限公司 Ims注册方法、s-cscf及终端
US10425531B1 (en) 2017-06-23 2019-09-24 8X8, Inc. Customized communication lists for data communications systems using high-level programming
US10447861B1 (en) 2017-06-23 2019-10-15 8X8, Inc. Intelligent call handling and routing based on numbering plan area code
US10951484B1 (en) 2017-06-23 2021-03-16 8X8, Inc. Customized call model generation and analytics using a high-level programming interface
EP3777267A1 (en) 2018-03-28 2021-02-17 British Telecommunications public limited company Roaming route optimization
CN113595906B (zh) * 2021-07-26 2022-10-21 烽火通信科技股份有限公司 一种基于策略收敛的路由订阅方法与系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1349330A (zh) * 2000-10-18 2002-05-15 日本电气株式会社 域间路由选择系统
US20040208175A1 (en) * 2003-04-17 2004-10-21 Mccabe Alan J. Linking autonomous systems with dual premise routing domains
US6823395B1 (en) * 1999-09-14 2004-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Arrangement and method relating to routing in a network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100536419C (zh) 1999-02-23 2009-09-02 阿尔卡塔尔互联网运行公司 交换机及在其中仿真单个交换机内多个路由器的方法
US7027433B2 (en) * 2001-06-20 2006-04-11 Nokia Corporation Routing a call between different types of networks
US7263610B2 (en) * 2002-07-30 2007-08-28 Imagictv, Inc. Secure multicast flow
CN1172481C (zh) 2002-08-22 2004-10-20 陈鸣 互连网端到端性能监测方法及其系统
CN100454882C (zh) 2003-12-19 2009-01-21 华为技术有限公司 多isp局域网的出口选择方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823395B1 (en) * 1999-09-14 2004-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Arrangement and method relating to routing in a network
CN1349330A (zh) * 2000-10-18 2002-05-15 日本电气株式会社 域间路由选择系统
US20040208175A1 (en) * 2003-04-17 2004-10-21 Mccabe Alan J. Linking autonomous systems with dual premise routing domains

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BASIC L: "Routing solution for VoIP calls in large-scale IP MM networks", ELECTROTECHNICAL CONFERENCE, 2004

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009056063A1 (fr) * 2007-10-26 2009-05-07 Huawei Technologies Co., Ltd. Procédé, dispositif et système de demande d'informations dans une architecture pcc
CN101420338B (zh) * 2007-10-26 2012-07-04 华为技术有限公司 Pcc架构中的信息查询方法、装置及系统
WO2016078290A1 (zh) * 2014-11-17 2016-05-26 中兴通讯股份有限公司 路由短消息的方法及装置、计算机存储介质
CN105682058A (zh) * 2014-11-17 2016-06-15 中兴通讯股份有限公司 一种路由短消息的方法及装置
US10070281B2 (en) 2014-11-17 2018-09-04 Zte Corporation Method and apparatus for routing short message, and computer storage medium
CN105682058B (zh) * 2014-11-17 2020-02-28 中兴通讯股份有限公司 一种路由短消息的方法及装置

Also Published As

Publication number Publication date
CN100505899C (zh) 2009-06-24
US20080102844A1 (en) 2008-05-01
EP1892897B2 (en) 2017-06-14
CN1909681A (zh) 2007-02-07
CN101156395A (zh) 2008-04-02
EP1892897B1 (en) 2013-06-12
EP1892897A4 (en) 2008-08-20
CN101156395B (zh) 2011-03-30
US8170565B2 (en) 2012-05-01
EP1892897A1 (en) 2008-02-27

Similar Documents

Publication Publication Date Title
CN101156395B (zh) 一种跨域路由控制方法
CN100563235C (zh) 互通功能网元、csi终端与ims终端互通系统及其方法
KR101276002B1 (ko) Ims 등록 사용자를 위한 호 처리
JP4819904B2 (ja) 回線交換型アクセスを介するIMSサービスのプロビジョン(provision:提供)
EP3179675B1 (en) Inter-domain call routing
EP1770949A2 (en) Method and communication system for circuit switch users accessing IP multimedia subsystem
CA2637217C (en) Method and apparatus for providing ims services to circuit-switched controlled terminals
WO2006026901A1 (fr) Systeme de traitement de signal de service de domaine de paquet et procede utilisant ce systeme
WO2006131070A1 (fr) Procede de realisation d'un service vocal d'apres le declenchement du service, procede de commande de route et systeme associe
WO2006102850A1 (fr) Procede et systeme de mise en oeuvre d'une commande de chemin
WO2006063536A1 (fr) Procede et systeme pour maintenir la continuite d'une session
WO2007079688A9 (fr) Procede, appareil et systeme de mise en communication de l'utilisateur appele
WO2007147357A1 (fr) Procédé et système de transmission d'informations d'emplacement de terminaison d'abonné dans un sous-système multimédia ip
CN100525256C (zh) Sip多媒体系统中请求消息的传输方法及设备
WO2009039688A1 (en) Late call forwarding method in ip multimedia core network subsystem centralized service
WO2008086744A1 (fr) Procédé de mise en œuvre d'établissement d'appel, système et élément de réseau de contrôle d'appel
CN101102604B (zh) Ip多媒体子系统集中控制业务中用户关机前转的方法
CN101330455B (zh) Ip多媒体子系统集中业务用户不可及前转实现方法
JP5165075B2 (ja) Imsに登録されたユーザのための呼処理
CN101360270A (zh) Ip多媒体子系统集中业务用户关机前转的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200680011717.X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 11965834

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2006753141

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2006753141

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11965834

Country of ref document: US