WO1998036583A1

WO1998036583A1 - Management of feature interactions in telecommunications networks

Info

Publication number: WO1998036583A1
Application number: PCT/GB1998/000431
Authority: WO
Inventors: Michael John Crowther
Original assignee: British Telecommunications Public Limited Company
Priority date: 1997-02-14
Filing date: 1998-02-12
Publication date: 1998-08-20
Also published as: EP1025712A1; AU6221598A

Abstract

In a telecommunications network, different service platforms include feature interaction controllers. In operation, a feature interaction controller in one platform transmits to the feature interaction controller in another platform data which relates to a service feature which is active on the transmitting platform. The feature interaction controller at the second platform then uses the data from the first platform to detect and control non-local interaction behaviours. For example, the feature interaction controller may inhibit the operation of a given service feature at the second platform if it would conflict in operation with one or more services which are active on the other platform.

Description

MANAGEMENT OF FEATURE INTERACTIONS IN TELECOMMUNICATIONS NETWORKS

The present invention relates to telecommunications networks, and in particular to the management of service interaction on telecommunications networks.

BACKGROUND TO THE INVENTION

In modern telecommunications networks, service platforms, such as network switches, are required to support a wide range of services in addition to basic telephony. As a result, service feature interaction has become an increasing problem. In general, different services have been developed independently without regard to the manner in which they may interact if two or more services are involved in a single call . Unforeseen interaction problems can reduce the perceived quality of the service to users, lead to reduced revenue for the network operators, and can increase development costs and timescales because of the need to specify correct feature interworking and to overcome existing interaction problems.

To address this problem, attempts have been made to equip service platforms with mechanisms for resolving interaction problems during the course of a call. For example, in System X exchanges manufactured by GPT Ltd a call chain software architecture makes it possible to define an order of precedence for different service features which may be invoked during a call. The switch can then make a decision to block one or other of the service features, based on this order of precedence, when a conflict arises. Another approach is adopted in the ITU standard IN (intelligent network) architecture. Here a Feature Interaction Manager (FIM) is included in the SSF (service switching function) at the exchange. However, while such approaches make it possible to handle some interaction problems, others remain intractable, and so service interaction problems have remained a major constraint on the design of new services. SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provided method of operating a telecommunications network which includes a plurality of interconnected service platforms, and in which a plurality of the said service platforms each include a respective feature interaction controller, the method including: a) transmitting, from a feature interaction controller in a first service platform to a feature interaction controller in a second service platform, service feature data which relates to a service feature which is active at the first service platform, which service feature data identifies one or more other service features which have known interworking properties in relation to the said service feature, b) in the feature interaction controller at the second service platform, processing the said service feature data and detecting thereby any conflicts between the service features active at the first service platform and other service features which are active at the second service platform; and c) when any conflict is detected in step (b), modifying the operation of service features at the second platform and/or at the first platform in the course of a call which is processed by the both the first and second service platforms.

The present inventor has found that a crucial aspect of feature interaction relates to non-local interactions when for example, a feature which is provided at an originating exchange for a call clashes with a feature present on the destination exchange. The present invention uses signalling between different platforms to share data on active service features, and processes all the relevant data, including data from other platforms, to ensure effective control of any potential interaction problems. The data exchanged by the platforms is termed by the inventor "Feature Interworking Indicators" (Fll) . By contr ast with conventional systems, the Fll or service feature data transmitted from one platform to another identifies other service features which have known interworking properties, allowing speedy identification and resolution of any clashes- The invention functions independently of the type of service platform involved. The service platforms may include, for example, customer premises equipment (CPE) - e.g. a personal computer having a telephony interface, core network switches including digital main switching units (DMSU's) or digital local exchanges (DLE's), and service control points (SCP's) .

Preferably the service feature data includes a feature instance reference which uniquely identifies a specific instance of a service feature.

During the course of a call, several instances of a service feature may be invoked, and the potential interaction problems may vary depending on the context in which the feature is invoked This preferred aspect of the invention allows the second platform to track and manage individual instances of a service feature, and makes possible correlation with possible later references to the same service feature.

Preferably the service feature data includes a feature precedence indicator for the service feature.

The proposed Feature Interaction Manager (FIM) for IN CS. 1 (capability set

1 ) relies upon service feature precedence to resolve interaction conflicts. This aspect of the invention, by including precedence indicators in the transmitted service feature data, makes it possible to extend the use of the FIM to handling non-local conflicts as well as local problems.

Preferably the service feature data includes persistence data. Persistence data indicates whether a service feature may be active later in a call.

Preferably in step (a) the first platform transmits service feature data both for features which are already active at the first platform, and for pending features which may be invoked depending upon the result of step (b). Preferably in this case the service feature data includes an active/pending indicator.

This aspect of the invention maximises the flexibility of the interaction management process by allowing the first platform to signal data on features it intends to invoke provided that there is no interaction problem at the second platform.

Preferably the service feature data identifies nominated partner features and/or nominated rival features.

Partner features are other features which the relevant service feature is known to interwork successfully with. Conversely, rival features are other features which are known to conflict with the relevant feature. By identifying these explicitly the first platform can speed identification and resolution of conflicts at the second platform. Moreover, this approach allows the resolution of conflicts between features in circumstances where merely assigning precedence values is not sufficient to overcome the problem. Other options which may be included in the service feature data include a service feature reference giving access to interworking information which is stored elsewhere in the network. The data may also include information about the past history of a feature. Preferably the initial service feature data is transmitted from the first platform to the second platform before the second platform has started running any service feature in the relevant call context.

Preferably the second service platform transmits service feature data to the first service platform and both the first and second platforms process service feature data to detect any conflicts.

In the preferred implementation of the invention, service feature data is transmitted in both directions between the platforms and may, for example, be transmitted backwards from a downstream platform towards an originating exchange, for example when new information about active features arises during the course of a call. The feature interaction management process can then be fully distributed between the platforms.

The preferred features identified above may also advantageously be implemented independently of the first aspect, in otherwise conventional systems, and the invention also encompasses such use of these features.

According to a second aspect of the present invention there is provided a service platform for use in a telecommunications system, the service platform including: a) service logic for implementing a service feature function b) a feature interaction controller arranged to process service feature data and to detect any conflicts between service features, and c) a service feature data interface which is connected to the feature interaction controller and which is arranged to be connected to the telecommunications network to receive, via the network, service feature data for a service feature which is active or pending at a second service platform which is remote from the said service platform, which service feature data identifies one or more other service features which have known interworking properties in relation to the said service feature.

According to a third aspect of the present invention, there is provided a method of operating a service platform in a telecommunications network, the method comprising: a)storιng, for a service feature, service feature data which identify one or more other service features which have known interworking properties in relation to the said service feature, b)when a new service feature is to be invoked at the service platform, and when at least one existing service feature is already active or pending at the service platform, reading the service feature data for one of the said new service feature and the existing service feature c)comparιng the identity of the other of the new service feature and the existing service feature with the service features which are identified in the said service feature data, d)modιfyιng the operation of the said service platform depending on the presence or absence of the said identity in the said service feature data

The use of service feature data which identifies other service features which have known interworking properties facilitates rapid identification and resolution of any interworking problems. Although it is preferred that this should be carried out in accordance with the non-local interaction control of the first aspect of the invention, it is not limited to use in this way, and may be used in the context of otherwise conventional local interaction control processes.

According to a fourth aspect of the present invention, there is provided a telecommunications system comprising: a) a telecommunications network; b) a first service platform which is connected to the telecommunications network and which includes: first service logic for implementing a service feature function, a first feature interaction controller arranged to process service feature data and to detect any conflicts between service features, and a first service feature data interface which is connected to the feature interaction controller and is arranged to output service feature data onto the network; c) a second service platform which is connected to the telecommunications network and which includes: second service logic for implementing a service feature function, a second service feature data interface which is connected to the network, and a second feature interaction controller which is connected to the second service feature data interface and which is arranged to process both locally originating service feature data and service feature data which is received from the first service platform via the network and via the second service feature data interface and to detect thereby any conflict between service features.

The invention further encompasses other methods, platforms, systems and networks as defined in the claims below DESCRIPTION OF THE DRAWINGS

Methods and systems embodying the present invention will now be described in further detail, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a schematic of a network embodying the present invention

Figure 2 is a schematic showing the architecture of a switch for use in the network of Figure 1 :

Figures 3a and 3b illustrate the format of network signalling suitable for carrying feature interaction indicators (Fll), Figure 4 is a diagram showing a first example of Fll information flows between platforms

Figure 5 is a flow diagram showing the operation of a feature interaction controller in a first embodiment; and

Figure 6 is a flow diagram showing the operation of a feature interaction controller in a second embodiment. DESCRIPTION OF EXAMPLES

A telecommunications network includes a first service platform 1 and a second service platform 2. In the present example, each service platform is a digital local exchange (DLE) which is connected to the core UK telecommunications network The service platforms use a call chain software architecture, as described in detail in the paper by H. M. Blair, "Attacking product complexιty:broadband call control for Vision O.N.E " , XIV International Switching Symposium, 1 992. Functions which are implemented by the service platforms are carried out using software modules known as "segments" . Different segments communicate with each other via a standard signalling interface. The functioning of the different segments is coordinated by a user segment. The user segment detects when a user has a feature provisioned. The user segment then invokes an instance of the or each feature segment required to implement the relevant service features. Feature segments are linked into different positions in the chain depending on how they work with other features. Each feature segment can absorb or pass downstream events which come from the access segment. The user segments each include a respective feature interaction controller (FIC) . As described in further detail below, the FIC blocks the invocation of features which would conflict with features which already part of a call chain. Each FIC accesses service feature data which is stored in a respective local database. In addition, each FIC receives and transmits feature interworking indicators (Fll) via a signalling interface 3,4 to the other FIC. It should be noted that although the Fll channel is shown as being logically distinct from the ISUP network signalling channel, in practice the network signalling and the Fll channel may share common physical circuits and transport protocols.

Figure 2 shows the physical architecture of a switch which is suitable for use in implementing the present invention. In this example, the switch is based on a design developed by Siemens AG and described in the paper "Control Architecture for ATM based Switching Systems" , Nick Skaperda , IEEE GlobeCom'92. This switch use an ATM switching network 21 . A subscriber line unit (SLU) 22 connects both narrowband and broadband subscriber terminals to the switching network. An ATM overlay network 23 is connected via an Access Unit 24 and an STM (Synchronous Transfer Mode) network 25 is connected via an Interworking Unit (IWU) 26. The switch logic is implemented by a number of general processing elements (GP) 27 and a control processor (CP) which are connected to the switching network via an ATM multiplexer 28. The user segment, including the FIC, is implemented on one of the general processing elements 27, or on a cluster of such processing elements. In the present example the general processing elements are, for example, DEC Alpha processors running the UNIX operating system. Each software module or segment is implemented as an independently scheduled process provided by the UNIX operating system. UNIX also provides for inter-process communication. The use of a portable operating system such as UNIX effectively makes the call control processes and the feature interaction control features independent of the underlying processor architecture, and makes it straightforward to implement these processes on different platforms. In operation, the information flows on the Fll channel allow the first service platform to provide the other service platform with interworking information relating to the service instances which are local to the transmitting service platform. The FIC in the receiving service platform then uses this information in order to control the operation of any of its own services which are operating in the same call context as the transmitting service platform. In particular it may cancel or delay the operation of service features which would give rise to a conflict with features on the originating platform. The Fll information may be used to choose a service variant that can interwork successfully with the existing feature context. Alternatively, or in addition, the originating service platform transmits Fll relating to service features which have not yet been invoked, but which will be invoked if the receiving service platform surrenders its opportunity to invoke its services.

In a first implementation of the present invention, the Fll data includes the following elements: a)CALL CONTEXT. This includes a call reference or some other identifying reference such as a Transaction Identity. This data is used to associate the Fll with any other service instances which may be relevant. The call reference may be included implicitly in an existing call control signalling message, b) FEATURE PRECEDENCE. Feature Precedence is defined in ITU Rec. Q1 21 4 (Madrid Jan 1 995) section 4.2.4. Its use has previously been proposed for local resolution of interworking problems. Whenever two or more service features are in conflict, then the feature with the higher precedence is invoked, and the feature which has lower precedence is not invoked. Resolution of conflicts using Feature Precedence is carried out by a Feature Interaction Manager (FIM) . In the present example, the FIC includes the functionality of an FIM as defined in the above ITU standard. The FIC processes Feature Precedence data for both local and remote service features.

In a second, alternative implementation the Fll data includes: a)CALL CONTEXT - as defined above. b) LOCAL SERVICE INSTANCE. This reference allows correlation with any later operations which refer to the same feature instance. c) PERSISTENCE INDICATOR. If the feature is completed there will be no more Flls for this feature. If the feature is not completed then there may be further Flls which indicate the results of event trigger processing. d) ACTIVE/PENDING INDICATOR. Active indicates that the information refers to a feature which is already active in the feature context. Pending indicates that the information refers to a feature which would run if the receiving service platform were to surrender its opportunity to invoke conflicting service features. In a third, alternative implementation, the Fll data includes: a) CALL CONTEXT - as defined above. b) SERVICE FEATURE REFERENCE F. This reference may be used to access interworking data which is stored locally at the platform, or is stored elsewhere in the network. c) NOMINATED PARTNER FEATURES. This identifies other features with which service feature F is known to interwork successfully. These other service features may be named individually, or ALL features may be designated as partner features. d) NOMINATED RIVAL FEATURES. This identifies other features with which service feature F is known to interfere, or which interfere with service feature F.

These other service features may be named individually, or ALL features may be designated as rival features.

In operation, an initial Fll is sent from an originating service platform to a receiving service platform before the receiving service platform has started running any services in the relevant feature context. This Fll is interpreted by the receiving service platform as meaning that the feature has started running in the originating service platform. The initial Fll may appropriately be included in the first call progress/service control signalling message which relates to the feature context. During processing of a particular call event, a service platform can source an Fll from the time it detects that a feature instance F will be run until the time that it passes control to another service platform. The Fll sourced from the originating service platform, or any Fll received from another service platform, are sent to any other service platforms which are known to be involved in the same feature context as F. Flls may be sent backwards in the direction of the call originator. The Fll may be sent immediately upon detection of a particular feature instance at the transmitting service platform, or may be transmitted at a later time when an association with a further service platform is set up.

In each of the implementations described above, the Fll is incorporated within ISUP (ISDN User Part) and INAP (Intelligent Network Application Part) signalling. In ISUP signalling, the ISUP remote operations parameter is used. This parameter, defined in ITU draft Q.763 section 3.48 is an optional parameter of many ISUP messages. Figure 3 shows the standard format of an ISUP message. This includes a mandatory fixed part 31 , a mandatory variable part 32 and an optional part 33. The remote operations parameter is included in the optional part 33. Figure 3b shows the format of the parameter. The initial octet of this parameter is set to 0001 0001 to indicate that the parameter relates to the remote operations protocol. The remainder of the parameter contains one or more components as defined in Q.763 section 3.48 of the ITU standard. Fll information is carried by an invoke component which carries a Featurelnteractionlndication operation. This operation is formally defined in Appendix A.1 below.

In CS.1 (capability set 1 ) INAP signalling, many operations can include a Servicelnteractionlndicators field, as defined in ITU Q.1 21 9 section 2.1 .3. In order to implement Fll signalling, the content of this field is defined as in FeaturelnteractionlndicationArg shown in Appendix A.2 below.

Figure 4 illustrates information flows between platforms, showing the C7 signalling messages, the values of the Feature Interaction Indications (Fll) which are carried by those messages and the actions which are taken by the call control software in the switching systems. In this example, the exchange of Fll data enables a service, Personal Numbering (PN), which is based at an originating SSP to interwork correctly with another service, Diversion Immediate, which is based at a terminating exchange 43. Signalling between the originating SSP 41 and an SCP 42 uses C7 Intelligent Network Application Part (INAP) . Signalling between originating and terminating local exchanges uses C7 ISDN user part (ISUP) . In the Figure, transit exchanges have been omitted for clarity. In this example, explicit precedence data is used, as in the first implementation discussed above. The first actions related to interaction management are taken by the SCP. It inserts an Fll parameter into the first call progress signalling message m l which it sends to the SSP after invoking the PN service feature. The C7 INAP Connect message m2 then carries a Serviceinteractionlndications field with the following value (defined using ASN.1 value notation) :

examplel Sllvalue Serviceinteractionlndications :: = { -- Context ID is implied from local call references fiiElements { - SEQUENCE OF feature specific information ( 1 value)

{ - feature specific information for PN

{ precedence 5, - high precedence value }

} } }

The SSP functions of the originating local exchange now store this information for local feature interaction management purposes and for passing on to other service platforms involved in this call. The action requested by the SCP was to route the current call to a new destination number, which involves sending an ISUP Initial Address Message (IAM) rm3 to the local exchange serving that number. As this destination local exchange is now handling the current call, the Fll data received from the SCP is included in the IAM message.

The C7 ISUP Initial Address Message (IAM) m3 carries a Remote Operations parameter, the first octet encoded with the value "00010001 ' to indicate the remote operations protocol. The remaining octets carry a single Remote Operations Service Element (ROSE) component. The following is an example value for this component, defined using ASN.1 value notation:

examplel ComponentValue Component : : = { invoke { invokelD 1 , operationCode localValue 0, - Fll operation {

- context ID is implied from the local call reference fiiElements { - SEQUENCE OF feature specific — information (1 value)

{ - feature specific information for PN

{ precedence 5, - high precedence value

} }

}

On receiving the lAM, the terminating local exchange stores the Fll data for local feature interaction management purposes and for passing on to any other service platforms involved in the call.

On decoding the destination address of the received ISUP lAM message, the User Transaction Segment module of the exchange's call processing software determines that the destination line has the Diversion Immediate (Dl) service feature provisioned and examines local feature interaction data to determine whether there are service features active which would interact with this feature. This local data now includes the Fll data received from the originating local exchange, so the terminating local exchange is able to compare the precedence values associated with Personal numbering (value = 5) and the local Diversion Immediate service (value = 1 ) . As the value for PN is higher than Dl, the Dl service feature is not invoked and linked into the call chain, and the Personal numbering service is correctly delivered to its user.

Figure 5 is a flow diagram showing the steps carried out by the feature interaction controller in this example. In the initial state 5.1 , Diversion Immediate is provisioned at the destination exchange. In step 5.2 the lAM is received from the originating SCP. In step 5.3 the Fll data is read from the lAM. In this example the Fll data includes a feature precedence value for the Personal Numbering feature which is active at the originating SCP. In step 5.4, the Fll data is stored for further processing. In step 5.5, the feature interaction controller determines whether there is any conflict between the feature identified in the Fll data, and the Diversion Immediate feature. If there is not, then both Personal Numbering and Diversion Immediate are linked into the call chain (step 5.6). If, as is the case in the present example, there is a conflict, then the feature interaction controller reads the precedence values for the relevant features (step 5.7) . In step 5.8, the values are compared, and one only of the features is invoked and linked into the call chain, depending on the results of the comparison (steps 5.9, 5.10) .

In a second example, the services involved are again Personal Numbering and Diversion Immediate. This time, however, the Fll signalling and the feature interaction control processes use nominated rival features, as in the third implementation outlined above. As before, the SCP inserts an Fll parameter into the first call progress signalling message which it sends to the SSP after invoking the personal numbering (PN) service feature. The C7 INAP Connect message carries a "Serviceinteractionlndications" field with the following value (defined using ASN. 1 value notation) : example2Sllvalue Serviceinteractionlndications :: = { - Context ID is implied from local call references fiiElements { - SEQUENCE OF feature specific information ( 1 value)

{ -- feature specific information for PN

{ rivals { - SEQUENCE OF FeaturelD "Diversion Immediate",

"Diversion On Busy", "Diversion On No Reply" }- } }

} }

The SSP functions of the originating local exchange now store this information for local feature interaction management purposes and for passing on to other service platforms involved in this call. The action requested by the SCP was to route the current call to a new destination number, which involves sending an ISUP Initial Address Message (lAM) to the local exchange serving that number. As this destination local exchange is now handling the current call, the Fll data received from the SCP is included in the lAM message. The C7 ISUP Initial Address Message (lAM) carries a Remote Operations parameter, the first octet encoded with the value "0001 0001 'B to indicate the remote operations protocol. The remaining octets carry a single Remote Operations Service Element (ROSE) component. The following is an example value for this component, defined using ASN.1 value notation:

examplel ComponentValue Component :: = { invoke { invokelD 1 , operationCode IocalValue 0, - Fll operation { -- context ID is implied from the local call reference fiiElements { - SEQUENCE OF feature specific

- information (1 value) { - feature specific information for PN

{ rivals { -- SEQUENCE OF FeaturelD

"Diversion Immediate", "Diversion On Busy", "Diversion On No Reply"

On receiving the lAM, the terminating local exchange stores the Fll data for local feature interaction management purposes and for passing on to any other service platforms involved in the call. On decoding the destination address of the received ISUP lAM message, the User Transaction Segment module of the exchange's call processing software determines that the destination line has the Diversion Immediate (Dl) service feature provisioned and examines local feature interaction data to determine whether there are service features active which would interact with this feature. This local data now includes the Fll data received from the originating local exchange, so the terminating local exchange is able to compare each of the rival Featureldentifiers associated with the features active in the current call with the Featureldentifier of the provisioned feature Diversion Immediate. There is a match, so the Dl service feature is not invoked and linked into the call chain, and the Personal numbering service is correctly delivered to its user.

Figure 6 illustrates the operation of the Feature Interaction Controller at the terminating exchange in this example. Initially (step 6.1 ) Dl is provisioned at the exchange. In step 6.2, the lAM message is received from the originating SCP. In step 6.3, the Feature Interaction Controller reads the Fll data from the lAM. In this example the Fll data includes a list of nominated rival service features In step 6.4, the Fll data is stored for further processing In step 6.5, the Feature Interaction Controller carries out a search to determine if the provisioned feature, Dl, matches any of the rival features listed in the Fll data. If no match is found, then both PN and Dl might be invoked and linked in the call chain (step 6.6) . However, in the present example, Dl is found in the list of rival features Accordingly, the operation of the Dl feature is inhibited and only PN is invoked and linked in the call chain (step 6.7) .

APPENDIX

A.1 Featurelnteractionlndication :: = OPERATION {

ARGUMENT FeatureinteractionlndicationArg }

featurelnteractionlndication Featurelnteractionlndication :: = localValue 0 A.2

Featurelnteractionlndication Arg : : = SEQUENCE { contextID OCTET STRING (SIZE(ContextlDLength)) OPTIONAL,

- The context ID may be implied by local call references fiiElements Fll Elements

}

Fll Elements : : = SEQUENCE OF FeatureSpecificlnformation

FeatureSpecificlnformation :: = SEQUENCE { id FeaturelD OPTIONAL,

- the featurelD is only necessary if the operation doesn't contain sufficient - information for interaction management, but the information can be looked up

- locally, using the ID as a reference precedence Integer (1 ..MaxPrecedence) OPTIONAL,

- this information can be used for interaction management if a precedence

- value has been assigned to ail relevant features (may be the case in simple - networks, or where bilateral arrangements have been made by ail relevant

- operators and service providers) partners NominatedFeatures OPTIONAL, rivals NominatedFeatures OPTIONAL, persistence BOOLEAN OPTIONAL instancelD OCTET STRING

(SIZE(FeaturelnstancelDLength)) OPTIONAL,

- this will be required to correlate multiple Fll operations relating to a

- persistent feature. history SEQUENCE OF Historyltem OPTIONAL }

NominatedFeatures : : = SEQUENCE OF FeaturelD

- either one or both of partners and/or rivals fields can be used to manage

- interactions where there is no common agreed set of precedence values for — all relevant features. Partner features are known to work with the present

- feature, rival features are known to interact with it. FeaturelD : : = OCTET STRING (SIZE(FeaturelDLength))

- these may be locally defined by network operator/service provider, or the

— result of some standards activity

Historyltem :: = CLASS {

&ArgumentType OPTIONAL,

&ltemCode INTEGER UNIQUE

}

- Historyltem is defined as an ASN.1 information object class, as new classes of

- information will need to be added as new features are defined. An example instance - of Historyltem is given below:

personalNumberingHistory Historyltem : : = { &ArgumentType personalNumberingHistoryArg,

&ltemCode 1

}

personalNumberingHistoryArg : : = SEQUENCE { originalDialledNumber OCTET STRING (SIZE(minDigitsLength..maxDigitsLength))

}

Claims

1 . A method of operating a telecommunications network which includes a plurality of interconnected service platforms, and in which a plurality of the said service platforms each include a respective feature interaction controller, the method including: a) transmitting, from a feature interaction controller in a first service platform to a feature interaction controller in a second service platform, service feature data which relates to a service feature which is active at the first service platform, which service feature data identifies one or more other service features which have known interworking properties in relation to the said service feature, b) in the feature interaction controller at the second service platform, processing the said service feature data and detecting thereby any conflicts between the service features active at the first service platform and other service features which are active at the second service platform; and c) when any conflict is detected in step (b), modifying the operation of service features at the second platform and/or at the first platform in the course of a call which is processed by the both the first and second service platforms.

2. A method according to claim 1 , in which the service feature data includes a list of rival features which are known to conflict in operation with the said service feature.

3. A method according to claim 1 or 2, in which the service feature data includes a list of partner features which are known to interwork successfully with the said service feature.

4. A method according to any one of the preceding claims, in which the service feature data includes a feature instance reference which uniquely identifies a specific instance of a service feature.

5. A method of operating a telecommunications network which includes a plurality of interconnected service platforms, and in which a plurality of the said service platforms each include a respective feature interaction controller, the method including: a) transmitting, from a feature interaction controller in a first service platform to a feature interaction controller in a second service platform, service feature data which relates to a service feature which is active at the first service platform, which service feature data includes a feature instance reference which uniquely identifies a specific instance of a service feature; b) in the feature interaction controller at the second service platform, processing the said service feature data and detecting thereby any conflicts between the service features active at the first service platform and other service features which are active at the second service platform; and c) when any conflict is detected in step (b), modifying the operation of service features at the second platform and/or at the first platform in the course of a call which is processed by the both the first and second service platforms.

6. A method according to any one of preceding claims, in which the service feature data includes a feature precedence indicator for the service feature.

7. A method according to any one of the preceding claims, in which the service feature data includes persistence data.

8. A method of operating a telecommunications network which includes a plurality of interconnected service platforms, and in which a plurality of the said service platforms each include a respective feature interaction controller, the method including: a) transmitting, from a feature interaction controller in a first service platform to a feature interaction controller in a second service platform, service feature data which relates to a service feature which is active at the first service platform, which service feature data includes persistence data; b) in the feature interaction controller at the second service platform, processing the said service feature data and detecting thereby any conflicts between the service features active at the first service platform and other service features which are active at the second service platform; and c) when any conflict is detected in step (b), modifying the operation of service features at the second platform and/or at the first platform in the course of a call which is processed by the both the first and second service platforms.

9. A method according to any one of the preceding claims, in which in step (a) the first platform transmits service feature data both for features which are already active at the first platform, and for pending features which may be invoked depending upon the result of step (b) .

1 0. A method of operating a telecommunications network which includes a plurality of interconnected service platforms, and in which a plurality of the said service platforms each include a respective feature interaction controller, the method including: a) transmitting, from a feature interaction controller in a first service platform to a feature interaction controller in a second service platform, service feature data both for a feature which is already active at the first platform, and for a pending feature which may be invoked depending upon the result of step (b) . b) in the feature interaction controller at the second service platform, processing the said service feature data and detecting thereby any conflicts between the service features active at the first service platform and other service features which are active at the second service platform; and c) when any conflict is detected in step (b), modifying the operation of service features at the second platform and/or at the first platform in the course of a call which is processed by the both the first and second service platforms.

1 1 . A method according to claim 9 or 1 0, in which the service feature data includes an active/pending indicator.

1 2. A method according to any one of the preceding claims, in which initial service feature data is transmitted from the first platform to the second platform before the second platform has started running any service feature in the relevant call context

1 3. A telecommunications system arranged to operate by a method according to any one of the preceding claims and comprising: a telecommunications network, a first service platform and a second service platform connected via the telecommunications network to the first service platform.

1 4. A telecommunications system comprising a)a telecommunications network b)a first service platform which is connected to the telecommunications network and which includes first service logic for implementing a service feature function a first feature interaction controller arranged to process service feature data and to detect any conflicts between service features, and a first service feature data interface which is connected to the feature interaction controller and is arranged to output service feature data onto the network c) a second service platform which is connected to the telecommunications network and which includes second service logic for implementing a service feature function a second service feature data interface which is connected to the network, and a second feature interaction controller which is connected to the second service feature data interface, which second feature interaction controller is responsive to service feature data which identifies one or more other service features which have known interworking properties in relation to the said service feature, and which second feature interaction controller is arranged to process both locally originating service feature data and service feature data which is received from the first service platform via the network and via the second service feature data interface, and to detect thereby any conflict between service features.

1 5. A service platform for use in a telecommunications network, the service platform including: a) service logic for implementing a service feature function b) a feature interaction controller arranged to process service feature data and to detect any conflicts between service features, and c) a service feature data interface which is connected to the feature interaction controller and which is arranged to be connected to the telecommunications network to receive, via the network, service feature data for a service feature which is active or pending at a second service platform which is remote from the said service platform, which service feature data identifies one or more other service features which have known interworking properties in relation to the said service feature.

1 6. A service platform for use in a telecommunications network, the service platform including: a) service logic for implementing a service feature function b) a feature interaction controller arranged to process service feature data which and to detect any conflicts between service features, and c) a service feature data interface which is connected to the feature interaction controller and which is arranged to be connected to the telecommunications network to receive, via the network, service feature data for a service feature which is active or pending at a second service platform which is remote from the said service platform, which service feature data includes a feature instance reference which uniquely identifies a specific instance of a service feature.

1 7. A service platform for use in a telecommunications network, the service platform including: a) service logic for implementing a service feature function b) a feature interaction controller arranged to process service feature data which and to detect any conflicts between service features, and c) a service feature data interface which is connected to the feature interaction controller and which is arranged to be connected to the telecommunications network to receive, via the network, service feature data for a service feature which is active or pending at a second service platform which is remote from the said service platform, which service feature data includes persistence data.

1 8. A service platform for use in a telecommunications network, the service platform including: a) service logic for implementing a service feature function b) a feature interaction controller arranged to process service feature data and to detect any conflicts between service features, and c) a service feature data interface which is connected to the feature interaction controller and which is arranged to be connected to the telecommunications network to receive, via the network, service feature data both for a feature which is already active at the another platform, and for a pending feature which may be invoked at the other platfrom depending upon the result of feature interaction control processing by the feature interaction controller.

1 9. A telecommunications network incorporating a service platform according to any one of claims 1 5 to 1 8.

20. A telecommunications network comprising a plurality of interconnected service platforms, each of the said service platforms comprising a respective feature interaction controller, the network further comprising: a) means for transmitting, from a feature interaction controller in a first service platform to a feature interaction controller in a second service platform, service feature data which relates to a service feature which is active at the first service platform, which service feature data identifies one or more other service features which have known interworking properties in relation to the said service feature; b) in the feature interaction controller at the second service platform, means for processing the said service feature data and detecting thereby any conflicts between the service features active at the first service platform and other service features which are active at the second service platform; and c) means for modifying the operation of service features at the second platform and/or at the first platform in the course of a call which is processed by the both the first and second service platforms when any conflict is detected by the said means for processing.

21 . A method of operating a service platform in a telecommunications network, the method comprising: a)stor╬╣ng, for a service feature, service feature data which includes a list of partner features which are known to interwork successfully with the said service feature b)when a new service feature is to be invoked at the service platform, and when at least one existing service feature is already active or pending at the service platform, reading the service feature data for one of the said new service feature and the existing service feature c)compa╧Çng the identity of the other of the new service feature and the existing service feature with the service features which are identified in the said service feature data, d)mod╬╣fy╬╣ng the operation of the said service platform depending on the presence or absence of the said identity in the said service feature data.

22. A service platform for use in a telecommunications network, the platform comprising: a) means for storing, for a service feature, service feature data which includes a list of partner features which are known to interwork successfully with the said service feature; b) means for reading the service feature data for one of a new service feature and an existing service feature when the new service feature is to be invoked at the service platform, and when at least one existing service feature is already active or pending at the service platform; c) means for comparing the identity of the other of the new service feature and the existing service feature with the service features which are identified in the said service feature data; d) means for modifying the operation of the said service platform depending on the presence or absence of the said identity in the said service feature data.