Patent Application
20070183395
The invention relates generally to telecommunication networks, and more particularly to a telecommunications network that provide synchronization of subscriber data when subscribers roam in a circuit based core network as well as in a IP Multi Media Sub-system (IMS) network.
Wireless and wired communication systems are constantly evolving. System designers are continually developing greater numbers of features for both service providers as well as for the end users. In the area of wireless phone systems, cellular based phone systems have advanced tremendously in recent years. Wireless phone systems are available based on a variety of modulation techniques and are capable of using a number of allocated frequency bands. Some available modulation schemes include digital modulation schemes using Time Division Multiple Access (TDMA) or Code Division Multiple Access (CDMA). Some phones are also capable of VoIP (Voice over Internet Protocol).
VoIP is a term used in IP telephony for a set of facilities for managing the delivery of voice information using the Internet Protocol. In general, this means sending voice information in digital form in discrete packets rather than in the traditional circuit-committed protocols of the public switched telephone network. In addition to IP, VoIP uses the real-time protocol to help ensure that packets get delivered in a timely way.
In a network, where subscribers are allowed to roam in a circuit based core network as well as an (IP based) IP Multi Media Sub-system (IMS) network, the synchronization of subscriber data becomes complex. The call model is different as well as the management of subscriber profile in these different networks.
In the circuit based core network (ANSI-41 and UMTS), Home Location Register (HLR) keeps the subscriber profile. HLR acts as the profile repository and execute the logic related to the profile related services. One example is updating the supplementary services subscriber profile by the subscriber from the handset. The subscriber can enter “#66#” (an example, the code can be specific to technology, country or operators) from User Equipment (UE) to initiate the “Call Forwarding Activation”. This “Feature Code” reaches the HLR network. The HLR updates the profile and stores the new value.
In an IP based IMS a network, SIP is used as the call session management protocol. HSS acts as the subscriber profile repository. In an IMS network, the concept of subscriber profile is different from the service related profile. HSS profile provides the information about the services provisioned by the operator for a subscriber and where these services need to be executed. These service execution nodes are known as Application Servers. Application Server keeps the profile required for the execution of the supported services. When, for example, the subscriber enters “#66#” (an example from earlier circuit mode network), the profile is changed at the Application Server. For the subscriber which roams in different core networks, IMS and Circuit network, the synchronization of this profile is “must have” feature.
Thus there is a need in the art for an improved system that provides synchronization of subscriber data when subscribers roam in a circuit based core network as well as in a IP Multi Media Sub-system (IMS) network.
One implementation encompasses an apparatus. This apparatus may comprise: at least one circuit switching network; IMS network; and an enhanced home location register operatively coupled to each of the at least one circuit switching network and the IMS network, the enhanced home location register functioning as a home location register for the at least one circuit switching network, and functioning as HLR application server for the IMS network.
One implementation encompasses a method. This embodiment of the method may comprise: using an enhanced home location register, which is operatively coupled to each of at least one circuit switching network and an IMS network, as a home location register for the at least one circuit switching network, and as a HLR application server for the IMS network; accepting, by the enhanced home location register as an HLR application server, a SIP request for a subscriber profile change and internally sending the SIP request to update the subscriber HLR profile for use in the circuit switching network; and accepting, by the enhanced home location register as an HLR application server, a update request for a subscriber profile change and updating the subscriber profile for use in a packet data network by the enhanced home location register acting as a SIP node for the profile change in the packet data network.
Features of exemplary implementations will become apparent from the description, the claims, and the accompanying drawings in which:
In an embodiment of the present method and apparatus a SDHLR (Super Distributed Home Location Register, also referred to an enhanced home location register) acts as an HLR in a circuit network and as an IMS Application Server (also referred to as an HLR application server) in IMS network. The SDHLR as an application server will accept a SIP request for a profile change and may internally send the request to update the subscriber profile for the circuit mode i.e. HLR profile. The routing of the IMS network may be provisioned to support this. The routing mechanism may first send the profile change request to the SDHLR acting as an application server for the profile change in the IMS network (as well as the HLR for the same subscriber in the circuit network). Once this request is successfully executed by the SDHLR application server, the profile change request may be sent to the Telecom Application Server (TAS). This routing may be achieved with a provisioning of multi-precedence IFC (Initial Filter Criteria) in the Home Subscriber Server (HSS), in the IMS network.
The following anachronisms are used herein:
Call Forwarding—Busy (CFB)
Call Forwarding—Default (CFD)
Call Forwarding—No Answer (CFNA)
Call Forwarding—Unconditional (CFU)
Call Transfer (CT)
Call Waiting (CW)
Calling Number Identification Presentation (CNIP)
Calling Number Identification Restriction (CNIR)
Conference Calling (CC)
Do Not Disturb (DND)
Flexible Alerting (FA)
Message Waiting Notification (MWN)
Mobile Access Hunting (MAH)
Password Call Acceptance (PCA)
Preferred Language (PL)
Priority Access and Channel Assignment (PACA)
Remote Feature Control (RFC)
Selective Call Acceptance (SCA)
Subscriber PIN Access (SPINA)
Subscriber PIN Intercept (SPINI)
Three-Way Calling (3WC)
Voice Message Retrieval (VMR)
Voice Privacy (VP)
The IMS network may provide access to an IP multimedia subsystem. The HLR application server may store subscriber feature data from the home location register during transactions initiated on the IMS network. The HLR application server may also store subscriber feature data from the home location register during transactions initiated on the circuit switching network. Subscriber features may be stored in the home location register, and the subscriber features may comprise at least one of: CFB, CFD, CFNA, CFU, CW, CNIP CNIR, CC, DND, FA, MWN, MAH, PCA, P, PACA, RFC, SCA, SPINI, SPINA, TWC, VMR, and VP.
The subscriber features may be stored in the home location register, and the subscriber features may comprise at least one of: ringback tone information, incoming call screening information, and VPN. The HLR application server is identified in SIP calls for changing telephony subscriber feature calls.
In some of the following described methods, sometimes a SIP invite may be used, but since no session may be necessary for this SIP transaction, other SIP commands may be considered to be equivalent, for example, SIP message and SIP Info.
Furthermore, some of the following described methods use dialed feature strings. The dialed feature strings may be equivalently represented as keystroke sequences on the mobile terminal. For example, *72Grandmas# may be represented by Settings>Forwarding>Unconditional>On>Grandmas# as entered on the phone prompts. The equivalent information may be transported in a SIP message from either of the two dialing models.
a. The IFC for this subscriber includes forwarding INVITE with TO header containing the #66# string to the SDHLR app server. Additionally, but with lower precedence, the IFC indicates that the S-CSCF should forward INVITE messages that are mobile originations. These are configured to be sent to the Telephony Application Server. Other specific IFCs can be created. The IFCs allow access to both App servers (TAS and HLR AS).
b. #66# is dialed from the UE.
c. The SIP enabled UE sends SIP request with “TO” set to #66#, indicating that the subscriber wishes to activate the service.
d. The SIP Invite is forwarded (through the P-CSCF—not shown) to the S-CSCF. Assuming a current registration, with iFC as described in the above step, the S-CSCF identifies the origination as matching both the defined iFC. It will be sent to the SDHLR App Server, and after returning from that entity, to the TAS.
e. In this step we see the S-CSCF apply the highest precedence iFC and send the SIP Invite to the SDHLR App Server.
f. The HLR recognized a #66# string and changes data corresponding to the meaning of the feature assigned to #66#.
g. The success or failure is acknowledged.
h. To relay the call to the destination (or in this case to the next IFC in sequence) the SIP:INVITE is returned to the S-CSCF like it was received.
i. The S-CSCF receives the SIP invite, notices another IFC has not been routed, and routes the INVITE to the TAS.
j. TAS changes the feature info internally.
k. To relay the call to the destination (or in this case to the next IFC in sequence) the SIP:INVITE is returned to the S-CSCF like it was received.
l. The S-CSCF identifies no additional matching IFC and sends the SIP invite toward the destination.
a. The IFC for this subscriber includes forwarding INVITE with TO header containing the #66# string to the SDHLR app server. Additionally, but with lower precedence, the IFC indicates that the S-CSCF should forward INVITE messages that are mobile originations. These are configured to be sent to the Telephony Application Server.
b. #66# is dialed from the UE.
c. The ANSI-41 (CDMA) serving system receives dialed digits from the subscriber's mobile station (MS). The serving system detects a “#” character as the first dialed digit. This indicates that the dialed digits are a feature code string.
d. The serving system sends a FEATREQ message to the HLR, including the digits received from the subscriber.
e. The SDHLR recognizes a #66# string and sends the request to SDHLR IMS Application server CF for initiating the request for profile change in TAS (IMS network).
f. The SDHLR AS CF sends SIP request with “TO” set to #66#, indicating that the subscriber wishes to activate the service. The SIP Invite is forwarded to the S-CSCF. Assuming a current registration, with IFC as described in the above step, the S-CSCF identifies the origination as matching both the defined IFC. It will be sent to the SDHLR App Server, and after returning from that entity, to the TAS.
g. In this step we see the S-CSCF apply the highest precedence iFC and send the SIP Invite to the SDHLR App Server. The HLR recognizes a #66# string and from the request that this was initiated by SDHLR only, SDHLR will respond without updating the profile.
h. To relay the call to the destination (or in this case to the next IFC in sequence) the SIP:INVITE is returned to the S-CSCF like it was received.
i. The S-CSCF receives the SIP invite, notices another IFC has not been routed, and routes the INVITE to the TAS.
j. TAS changes the feature info internally.
k. The success or failure is acknowledged.
l. Upon the successful response at SDHLR AS CF (about the updating of profile at TAS), SDHLR will update the profile at HLR subscriber profile.
m. The HLR returns a featreq message to the serving system, indicating a successful feature control request.
n. The serving system sends a feature confirmation signal to the subscriber.
a. The IFC for this subscriber includes forwarding INVITE with TO header containing the #66# string to the SDHLR app server. Additionally, but with lower precedence, the IFC indicates that the S-CSCF should forward INVITE messages that are mobile originations. These are configured to be sent to the Telephony Application Server.
b. #66# is dialed from the UE.
c. The GSM serving system receives an ACTIVATE_SS message from the subscriber's mobile station (MS), indicating that the subscriber wishes to activate the CFU service.
d. The serving system sends an ACTIVATE_SS message to the HLR (SDHLR UMTS CF), constructed based on the information received in the ACTIVATE_SS message.
e. The SDHLR recognizes a #66# string and sends the request to SDHLR IMS Application server CF for initiating the request for profile change in TAS (IMS network).
f. The SDHLR AS sends SIP request with “TO” set to #66#, indicating that the subscriber wishes to activate the service. The SIP Invite is forwarded to the S-CSCF. Assuming a current registration, with iFC as described in the above step, the S-CSCF identifies the origination as matching both the defined iFC. It will be sent to the SDHLR App Server, and after returning from that entity, to the TAS.
g. In this step we see the S-CSCF apply the highest precedence iFC and send the SIP Invite to the SDHLR App Server. The HLR recognizes a #66# string and from the request that this was initiated by SDHLR only, SDHLR will respond without updating the profile.
h. To relay the call to the destination (or in this case to the next IFC in sequence) the SIP:INVITE is returned to the S-CSCF like it was received.
i. The S-CSCF receives the SIP invite, notices another IFC has not been routed, and routes the INVITE to the TAS.
j. TAS changes the feature info internally.
k. The success or failure is acknowledged.
l. Upon the successful response at SDHLR AS CF (about the updating of profile at TAS), SDHLR will update the profile at HLR subscriber profile.
m. HLR returns an activate_ssconfirmation message to the serving system, indicating a successful feature control request.
n. The serving system sends an activation response message to the subscriber
o. Because the request resulted in a change to the subscriber's service profile, the HLR (SDHLR) reports the change by sending an Insert Subscriber Data message to the IIF emulating the Serving MSC/VLR. The Serving MSC (S-MSC) returns an Insert Subscriber Data Ack message to the HLR.
The ASs 510, 512, 514 may be also operatively coupled to an HSS 522 and an S-CSCF 524 in the IMS network 506. The HSS 522 and the S-CSCF 524 may be operatively coupled to one another, and also operatively coupled to an I-CSCF 526. The S-CSCF 524 may also be operatively coupled to a MGW 538 that couples the IMS network 506 to the PSTN 520. S-CSCF 524 A P-CSCF 528 in a further IMS network 530 may be operatively coupled to the I-CSCF in the IMS network 506. The P-CSCF 528 may be operatively coupled to a backbone packet network 532 that is turn is coupled to a telephone station 536 via an access 534.
The steps or operations described herein are just exemplary. There may be many variations to these steps or operations without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.
Although exemplary implementations of the invention have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions, and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.
