EP1145499A4

EP1145499A4 - A system and method for intelligent network services

Info

Publication number: EP1145499A4
Application number: EP99967857A
Authority: EP
Inventors: Francis Patrick Kleinitz; Norman William Mcleod; Russell Clarke Williams
Original assignee: Telstra Corp Ltd
Current assignee: Telstra Corp Ltd
Priority date: 1998-12-23
Filing date: 1999-12-23
Publication date: 2004-11-10
Also published as: CN1197298C; CN1335006A; AUPP791798A0; WO2000039960A1; EP1145499A1; NZ512758A; CA2356273A1

Abstract

A network system having a network switch for processing characteristic data associated with a communications call to determine if Intelligent Network (IN) service data is required to establish the call, and a network service data gateway for receiving the characteristic data from the network switch when the service data is required. The gateway is adapted to process at least part of the characteristic data to determine a network location to access in order to obtain the service data, and a communication protocol for connecting to the network location. The gateway is also adapted to receive the service data and pass the service data to the switch to establish the call. The system has a Home IN and Visitor IN architecture.

Description

A SYSTEM AND METHOD FOR INTELLIGENT NETWORK SERVICES

The present invention relates to a call processing method and a network system, which are particularly, but not exclusively, useful in executing Intelligent Network (IN) services which may be provided across a number of different telecommunications networks.

IN services, such as call forwarding, call diversion and messaging services, are provided in fixed telecommunication networks by a traditional structure which has dedicated IN computer logic for each network and which is common across all switching nodes of the network to service those nodes. The nodes, normally located in exchanges of the network, act as Service Switching Points (SSPs) which can be triggered on a characteristic of an incoming or outgoing call to send data associated with the call to a Service Control Point (SCP) of the computer logic to process an IN service. The SCP determines how the service is to be processed and may need to access data at a Service Data Point (SDP) of the logic in order to execute the service. The SCP then feeds the required information back to the SSP to complete execution of the service and direct the call handled by the SSP appropriately. The IN computer logic is normally held in one central location for its respective network, and all IN services need to be processed at that central location. Mobile telecommunications networks, such as GSM, AMPS and CDMA networks are also able to execute IN services respectively, such as messaging services. The mobile networks however do not rely on discrete and separate IN computer logic for each network, but instead rely on computer logic which is built into the components of each network, such as the Base Station Controllers (BSC) and the Mobile Switching Centres (MSC). All of the networks execute their own respective communication protocols to access IN service data and execute IN services.

It is desired to provide a method or system which enables IN services to be delivered efficiently across a number of telecommunications networks, and which alleviates the restrictions imposed by the existing network specific architectures and processes described above, or which at least provides a useful alternative. In accordance with the present invention there is provided a call processing method, including: processing characteristic data associated with a communications call at a network switch to determine if intelligent network (IN) service data is required to establish said call; passing said characteristic data to a network service data gateway when said service data is required; processing at least part of said characteristic data by said gateway to determine a network location to access in order to obtain said service data, and a communication protocol for connecting to said network location; and obtaining said service data and passing said service data to said switch to establish said call.

The present invention also provides a network system having: a network switch for processing characteristic data associated with a communications call to determine if Intelligent Network (IN) service data is required to establish said call; a network service data gateway for receiving said characteristic data from said network switch when said service data is required, said gateway being adapted to process at least part of the characteristic data to determine a network location to access in order to obtain said service data, and a communication protocol for connecting to said network location; and wherein said gateway is adapted to receive said service data and pass the service data to said switch to establish said call.

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a schematic diagram of a preferred embodiment of a network system;

Figure 2 is a schematic diagram of part of the network system providing voice messaging services;

Figure 3 is a block diagram of part of the network system providing IN terminating services; Figure 4 is a block diagram of the network system;

Figure 5 is a block diagram of part of the network system performing mobile terminated SMS policing;

Figure 6 is a block diagram of the network system performing mobile originated SMS policing; and

Figure 7 is a block diagram of part of the network system providing local switching access for a private network.

5 An intelligent network system 2, as shown in Figure 1 , is able to process IN service requests and, in particular, handle a range of mobile originating IN services, such as access to messaging services, as well as a range of terminating IN services. The system 2 includes a plurality of telecommunications networks 4 to 12 and private networks 14 or stations 16 which are able to communicate with an IN gateway 20 for the provision of IN service data. The 10 telecommunications networks including foreign networks 4, a local intelligent switching network 6, such as the PSTN, and mobile networks, such as a CDMA network 8, an AMPS network 10, and a GSM network 12. The gateway 20 can also communicate with Base Station Systems (BSS) of an office network 14 or a private home 16.

15 The gateway 20 of the system 2 has computer logic 22 which is configured to communicate with the networks 4 to 14 and the BSS 16 using the respective communication protocols for the networks 4 to 14 and the BSS 16, and is also able to respectively poll for IN service data requests from the networks 4 to 14 and the BSS 16. The system 2 provides a central "home" layer and a "visitor" layer by having a central Home Intelligent Network (HIN) 24 0 which maintains central IN service data and a plurality of Visitor Intelligent Networks (VLNs) 26 which are distributed amongst at least the local networks 6 to 14 and the BSSs 16 which the IN system 2 needs to serve. The VINs 26 each include the computer logic 22 and act as the gateway 20 for communicating with the networks 4 to 14 and the BSSs 16. The VIN logic 22 is able to communicate with the HIN 24, using INAP or TCP/IP, to obtain IN service data 5 information. For example, an IN service data request may be triggered in one of the switching nodes of the networks 4 to 12 in order to enable the node to process a call request. The IN service data request may have been triggered by the node on the basis of the called number, the called number and the calling number or categories of the A or B parties associated with the call. The service request is received by the VIN logic 22, which initially will refer to the HIN

30 24 concerning the requests. The HIN 24 maintains a customer database 28 which maintains simple look up tables for customers or subscribers and an IN service database 30 to process IN service data requests associated with more complex IN services, such as sophisticated call diversion and Virtual Private Networks (VPNs). The customer database 28 may provide service data such as which network the call relates to and an address within that network where further information on the B party can be obtained. The IN service database 30 may provide complete service data on how to establish the call together with billing information. The service data is fed back to the requesting node via the VIN logic 22 which stores a copy of the service data in a local cache for subsequent similar requests. Caching of the data by the VIN 26 allows a large number of local IN service data requests to be processed without referring to the HIN 24, therefore significantly saving on network resources. Therefore whilst the HIN 24 functions primarily as an SDP and the VIN 26 as an SCP, the HIN 24 also acts as an SCP and the VIN as an SDP, contrary to traditional IN architectures.

The IN system 2 provides, as described in more detail below, the following: (i) home and visitor based management of IN service data and control logic, (ii) customer independence from the terminating IN service, the terminating network and the final terminal. (iii) protocol independence from the terminating network,

(iv) private network access to public mobility data, (v) terminal network selection, (vi) policing of messages from other networks, such as international networks.

For traditional mobile networks, such as a GSM network 12, mobility related data follows a customer or subscriber as they change their servicing Mobile Service Centre (MSC) when moving from one part of the network to another. The IN system 2 in its home and visitor management of IN data maintains VINs 26 for respective regions or areas, but only transports IN data to the VINs 26 from the HIN 24 when an IN service is invoked. The data sent from the HIN 24 to a VIN 26 is cached locally in the VIN 26 for a predetermined period of time, such that if the IN service is invoked again within that period, the data can be provided locally from the VIN 26 to a local switch 32, without accessing the HIN. If customer data is changed in the HIN 24 all of the relevant VINs 26 containing a copy of the data are updated by the system 2. Data changes in the HIN 24 can be initiated by a subscriber using a VIN 26 or directed directly to the HIN 24. The predetermined period for data retention by a VIN 26 may be one or two days.

An example of Originating IN Service (OINS) management by the system 2 is processing of a voice message service request, as shown in Figure 2, where a customer in Perth dials 101 to access any stored messages. The call request is received by a switch 32 located in Perth which on processing the called number sends an IN service data request to a VIN 26 located in Perth. The service data request includes the calling and called numbers so the customer can be identified. If the relevant IN service data is not cached within the VIN 26, the VIN contacts the HIN 24 to obtain the hidden address for the customer's mailbox. This address is then cached in the VIN 26 and passed back to the switch 32 with data instructing the switch 32 to direct the call to the voice message service database 36. The switch 32 establishes the call to the database 36 and passes the hidden address to the database 36 to enable the customer to access his/her mailbox. On flying to Melbourne, the IN service data which enables the customer to access his/her mailbox in the database 36 is only transferred to the VIN 26 in Melbourne when the customer makes a call to the mailbox by dialling 101. The VIN 26 in Melbourne will then execute the same service to obtain the mailbox data, which it then retains in its local cache for subsequent mailbox requests.

For Terminating IN Service (TINS) management, the network system 2 in processing a request to establish a call is able to forward appropriate terminating IN script, as described below, from the HIN 24 to a VIN 26, and then provide the terminating script to a local switch 32 or 34 which is used to establish the call. The script may forward the call to another network, implement a mobile technology specific operation or invoke a particular IN service at the terminating end. The mobile specific operation may be obtaining a "Roaming" number or executing a "Call Screening" function when a user is roaming overseas.

The network system 2 provides network and terminal independence for a customer because the data which is held for each customer by the HIN 24 is accessible by all of the telecommunication networks 4 to 14 and BSSs 16 using the HIN/VLN architecture. The data maintained by the HIN 24 for each customer includes data on what network the customer belongs to, the type of technology associated with the network, where further data on the customer can be obtained, such as the location of a Home Location Register (HLR) and what terminal identity, i.e. terminal number, to use. Data on additional IN services associated with the customer may also be included, which may require more than one network to be contacted before a call to the customer can be established. Customers associated with different networks can have priorities assigned to the networks for establishing a call to the customer. The HIN data may also specify an appropriate messaging service to be contacted if a customer cannot be located on one or more networks.

For example, a customer may have a mobile terminal 40 allocated a terminating number 0418 123 456, and whilst the customer has the terminal 40 switched on in Brisbane, as shown in Figure 3, location data is copied into a Visitor Location Register (VLR) 44 of the MSC 42 in Brisbane and the GSM HLR database 46, in accordance with standard GSM network procedures. A caller 48 on the PSTN 50 in Perth placing a call to the customer dials the customer's number which is passed to the switch 32 in Perth for processing. The switch 32 contacts the VIN 26 in Perth using the ATUP, ISUP or LNAP protocols and asks the VIN to forward IN service data to it so it can establish the call. The VIN 26 contacts the HIN 24 using INAP to obtain data on the customer on the basis of the terminating number. Using the number, the HIN 24 accesses data to determine on which network 4 to 14 the customer resides and where the VIN 26 can access further data on the customer's location. For a GSM customer, the HIN 24 provides data back to the VIN 26 specifying the address for the GSM HLR 46 the VIN 26 needs to contact and also advising the VIN 26 that it needs to use the MAP protocol to communicate with the HLR 46. The VIN 26 then contacts the HLR 46 to obtain the location of the customer, and in particular a GSM roam number which can be used to route the call to the customer. This data is then forwarded to the switch 32 by the VIN 26. The switch 32 then uses the roam number to route the call from the caller 48 to the MSC 42 and onto the terminal 40. Similar processing occurs if a caller 52 on a mobile network in Melbourne places a call to the terminal 40, with the call being processed and established by the VIN 26 and the switch 34 in Melbourne. The architecture of the network system is particularly advantageous as it provides one gateway 20 for use in terminating all mobile network calls for different networks 8 to 12, without requiring reference or reliance on gateways which are specific to each mobile network 8, 10 or 12. Once calls to the terminal 40 are completed, the VINs 26 retain their local cache data specifying that the terminal 40 is a GSM terminal, the HLR 46 which needs to be contacted for a roam number and the protocol, MAP, which needs to be used.

The network system 2 provides technology independent processing of IN services by having a generic IN service front end in the VIN 26, which uses standard protocols such as

ATUP, ISUP or even INAP to communicate with a front end local exchange switch 32, such as an MSC, depending on the protocol used by the switch 32, as shown in Figure 4. The computer logic 22 of the VIN 26 translates the generic protocol service requests from the switch 32 into a back end technology specific transaction according to a customer's IN script which it obtains from the HIN databases 28 and 30 or which may already be stored in the VINs local cache 23. The IN script specifies the specific communication protocol to be used to obtain IN service data from technology specific network equipment 54. For example, the VIN logic 22 can communicate using IS41 with an HLR 56 of a CDMA network 8, MTUP to communicate with an HLR 58 of an AMPS network 10, and MAP or INAP to communicate with an HLR 46 of a GSM network 12. The VIN 22 may also need to use INAP, on instructions from the HIN 24 to contact an INAP based IN 60 to obtain specific call routing information or IN service data or to connect with an intelligent network peripheral. An IN service data request to the VIN 26 will normally be triggered within a switch 32 on processing a call based on the called number, the called number and the calling number, or categories or ranges associated with A or B parties or both for a call. The VIN 26 then processes the IN service data request so as to establish the service data required by the switch 32, which as discussed, may be obtained directly from the HIN 24 or may involve contacting different network technology specific equipment 54.

The network system 2 determines which network 4 to 12 should be used to originate a call when more than one network is available for a terminal. The occurs when the terminal is one of the following:

(a) a multimode terminal where both modes are available at all times, and is referred to as a parallel mode terminal.

(b) a multimode terminal where only one mode is available at any given time, and is referred to as a dual mode terminal.

(c) a single mode terminal which can access different network layers of a network. This covers radio layering which may be used when not all services are offered on all network layers.

(d) a single mode terminal which can access only one network but the network can be switched between private and public modes.

The network system 2 enables the appropriate operating mode for the terminals to be selected, either using terminal based selection, network prompted terminal selection or network selection, as described below.

Terminal based selection can be used in multimode terminals which can be set to select different networks depending on the type of call made, e.g. voice, fax, data or messaging service. For example, a dual mode terminal operating with a Cordless Base Unit (CBU) 16 can be connected to the CBU 16 or a mobile network 8, 10 or 12. The terminal would be set to send certain calls via the mobile network, such as fax and data calls, and other calls via the CBU. When the CBU is busy, the terminal can send calls via the mobile network 8, 10 or 12, and will be handled by the gateway 20, which may apply a discount call tariff if the gateway 20 can confirm the terminal is in the coverage area of the CBU, i.e. the terminal is "at home".

For network prompted terminal selection, the VIN 26 provides via the switch 32 instructions to a terminal regarding a choice of networks to use for originating a call. The VIN 26 provides messages detailing networks to be attempted in a priority based order.

For network selection, the VIN 26 retrieves service data in order to make a decision for a switch 32 and ultimately the terminal connected to it, as to which network should be used based on either the terminal identity, the requested service or the requested destination. For example, in a private wireless office environment, calls destined to the PSTN may be switched locally in the office, whereas public and private users requesting services only supported on the public mobile network, such as SMS, fax and data services, and private users requesting voice IN services only available on the public mobile network, such as voice message services, would all have their calls switched back through the public mobile network.

The network system 2 is also able to perform SMS policing and in particular can apply it to policing of international SMS traffic.

Policing of mobile terminated SMS traffic coming into a local network can protect local customers from unwanted SMS traffic originated by a foreign network 4. Policing is achieved by having all international MAP traffic destined to local network HLRs 46, 56 and 58 routed through a VIN 26, as shown in Figure 5. All SMS traffic except the MAP SMS Send Routing Information (SRI) message to the local HLR 46 is passed transparently. The SRI messages are screened by the VIN 26 to determine the originating global title address of the Short Message Service Centre (SMSC) and the destination mobile. SRI messages that are not on a bar list are passed to the appropriate HLR 46, and acknowledged with an SRI_ACK message as usual, whereas SRI messages that are barred are returned to the SMSC with a request rejected message SRI_NAK generated by the VIN 26.

Incoming mobile originated SMS policing can protect local SMSCs from unwanted SMS traffic originated in foreign networks 4, as well as providing a mechanism for load sharing between the SMSCs 70 of the local network 12. The MAP Forward Short Message (FSM) messages generated by a mobile terminal 40 are passed via VIN 26 to SMSC 70 of a local network 12 to determine if the traffic is allowed to pass, and if so, to which final service centre address the traffic should be sent to. The decision to enable the traffic to proceed to the network 12 is based on analysis of the originating foreign network 4, the originating terminal address, and the destination SC address. Following the analysis, only customers of the local network 12 roaming overseas may be allowed to originate and send traffic to an SMSC 70, and the network system 2 can distribute the messages evenly to all SMSCs 70 of the local network 12. Messages passed are acknowledged with an FSCM_ACK signal back to the mobile from the SMSC 70 via a VIN 26, otherwise if a message is refused, the VIN 26 generates an FSCM_NAK signal for the mobile 40, as shown in Figure 6.

Similarly, outgoing mobile originated SMS destined for foreign networks can be policed to determine foreign networks 4 and the foreign SMSCs 72 which local customers are allowed access to from a carrier's network including the system 2. The VIN 26 may refuse to pass FSM traffic based on the identity of the terminal 40 originating the message, the destined network 4 or the destination SC address of the SMSC 72. Appropriate FSCM_ACK and FSCM_NAK signals will be passed back to a mobile terminal 40 via the local network 12.

Local switching access to mobility data is provided for a private network 14, as shown in Figure 7.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS:

1. A call processing method, including: processing characteristic data associated with a communications call at a network switch to determine if intelligent network (IN) service data is required to establish said call; passing said characteristic data to a network service data gateway when said service data is required; processing at least part of said characteristic data by said gateway to determine a network location to access in order to obtain said service data, and a communication protocol for connecting to said network location; and obtaining said service data and passing said service data to said switch to establish said call.

2. A call processing method as claimed in claim 1, including storing said service data in said gateway for subsequent requests for said service data.

3. A call processing method as claimed in claim 2, including deleting said service data from said gateway after a predetermined period of time.

4. A call processing method as claimed in claim 1 , wherein said network location is in a central IN service data database.

5. A call processing method as claimed in claim 1, wherein said network location is in a local mobile network.

6. A call processing method as claimed in claim 1, wherein said network location is in a foreign telecommunications network.

7. A call processing method as claimed in claim 1 , wherein said gateway is local to a user originating said call.

8. A call processing method as claimed in claim 1 , wherein said gateway includes Visitor IN (VIN) computer logic for obtaining and caching service data for users in the area of said gateway.

9. A call processing method as claimed in claim 8, wherein said network location is within Home IN (HIN) computer logic including a central IN service data database.

5

10. A call processing method as claimed in any one of the preceding claims, wherein said communication call includes a voice, data or messaging connection.

11. A network system having:

10 a network switch for processing characteristic data associated with a communications call to determine if Intelligent Network (IN) service data is required to establish said call; a network service data gateway for receiving said characteristic data from said network switch when said service data is required, said gateway being adapted to process at least part of the characteristic data to determine a network location to access in order to obtain said service 15 data, and a communication protocol for connecting to said network location; and wherein said gateway is adapted to receive said service data and pass the service data to said switch to establish said call.

12. A network system as claimed in claim 11 , wherein said gateway stores said service data 20 for subsequent requests for said service data.

13. A network system as claimed in claim 12, wherein said gateway deletes said service data after a predetermined period of time.

25 14. A network system as claimed in claim 11 , wherein said network location is in a central IN service data database.

15. A network system as claimed in claim 11 , wherein said network location is in a local mobile network.

30

16. A network system as claimed in claim 11 , wherein said network location is in a foreign telecommunications network.

17. A network system as claimed in claim 11, wherein said gateway is local to a user originating said call.

18. A network system as claimed in claim 11, wherein said gateway includes Visitor IN 5 (VIN) computer logic for obtaining and caching service data for users in the area of said gateway.

19. A network system as claimed in claim 18, wherein said network location is within Home IN (HIN) computer logic including a central IN service data database.

10

20. A network system as claimed in any one of the preceding claims, wherein said communication call includes a voice, data or messaging connection.

21. A network system as claimed in claim 11 , including a plurality of said gateway covering 15 respective areas.

22. A network system as claimed in claim 11, wherein said service data is public mobility data.

20 23. A network system as claimed in claim 11 , wherein said service data is terminal network selection data.

24. A network system as claimed in claim 11, wherein said gateway includes means for policing messages passed between networks.

25