ES2244668T3 - COMMUNICATION INTERFACE BETWEEN PCS AND AUXILIARY PLATFORMS IN A RI NETWORK. - Google Patents

Abstract

This invention relates to user access device to intelligent services of an intelligent network (IN) comprising a service control point ( 2 ) that communicates with at least one group of physical entities ( 4, 6, 8 ) designed to provide at least one initial service element, and with several auxiliary platforms ( 10 <SUB>i</SUB>) designed to provide users with additional service elements for completing the initial service element. According to the invention, the device also comprises a communication interface ( 12 ) that allows an auxiliary platform ( 10 <SUB>i</SUB>) to send the service control point ( 2 ) service element execution queries in real time, and receive the data for executing these additional services from this service control point ( 2 ) as a response.

Description

Communication interface between PCS and platforms auxiliaries in an RI network.

The present invention relates to a device and to a user's access procedure to an RI service (network smart), which includes a service command point that communicates with at least one group of physical entities destined to ensure at least a first element of the service, and with a plurality of auxiliary platforms intended to supply the user additional service elements that complete the first service item.

The document "Service Creation for Advanced Intelligent Network Utilizing Intelligent Peripherals ", by S.D. Silberstang, discloses such a device and method.

Smart grids respond to IUT-T recommendations of the Q.120 series, Q.121x, Q.122x and Q.123x, and were born by virtue of the need for provide access to services that appeal to various applications such as, for example, a vocal service, a service electronic messaging, a treatment service transactions, etc., centralizing the command of these services. Usually, applications are associated to perform a new service using the architecture arranged in the layer of application.

In order to allow infrastructure existing in the communication network take into account the functionalities of the new service, intelligent networks use the following standardized functional entities:

- FCS services command function (SCF, Service Control Function, in English), whose physical entity corresponding in the architecture of the RI network is a point of PCS (Service Control Point) command;

- FCS service switching function, (SSF, Service Switching Function, in English), whose physical entity corresponding is a CAS service access switch (SSP, Service Switching Point, in English);

- FDS service data function, (SDF, Service Data Function, in English), whose physical entity corresponding is a BDS service database (SDP, Service Data Point);

- Function specialized resource FRS, (SRF, Specialized Ressource Function, whose physical entity corresponding is an intelligent peripheral PI (Intelligent Peripheral);

- FGS service management function, (SMF, Service Management Function, in English), whose physical entity corresponding is a Service Management Point (SMP, Service Management Point, in English).

In known RI services, an interface of user who uses an important part of the command function of FCS services, is taken into consideration by the command point of PCS services. This user interface ensures:

- the set of actions used by the service to inform a user, and invite him to determine his options;

- the set of device actions that collect user options;

- the implementation and chaining of these actions, such as invitations and collection of the option;

- the chaining of these actions with others actions of the service call processing.

Figure 1 schematically illustrates a known device for accessing an RI service in which a point service command 2 communicates with a database of services 4, an access switch 6 to which it is connected the user's telephone line 7, a service management point 8, and a plurality of auxiliary platforms 10_ {i}. A auxiliary platform 10_ {i} which can be either a peripheral intelligent that has specific resources to allow the adaptation of service commands to user demand, or either a value-added server such as, for example, a messaging, a service management point that informs the user about its consumption, or any other server. The auxiliary platform it can also be another service command point when two Smart networks are chained to the same call.

The resources of an intelligent peripheral can be announcers, word synthesis organs, organs of word recognition, necessary organs for the realization of a teleconference, tone generators, word synthesis tests, or protocol converters, etc.

When the auxiliary platform is a peripheral intelligent, two cases can occur:

- or the service command point 2 fully manages the services command functions, by example, in an à la carte service where the command point of services 2 manages the launch of the introduction phase of the card and code figures, the launch of the authentication based on the figures entered, the verification of card rights, the launch of the introduction phase of the requested number, the verification of rights the card has to call this number, the call to the number, as well as the chain in a following call;

- or the service command point 2 delegate to certain smart peripherals sub-tasks, more or less numerous as used the smart peripheral in "step by step" mode or in "script" mode ("script").

In the "step by step" mode, the peripheral smart is completely run by the command point of service 2 that, in a first command, orders you, for example, transmit a particular message to a user, and in another command, Collect user option.

In "script" mode, the peripheral intelligent has a certain latitude to chain certain sub-tasks of the user interface, such as, for example, the issuance of an invitation message, the collection of the user's option, and the issuance of another message from invitation.

In both cases, the smart peripheral perform the requested task and realize the command point of services 2, never chaining from itself the tasks that you They are delegates. On the other hand, the smart peripheral does not chain never the user interface phases with other service phases RI It is only used as an attached resource of the command module of services 2 to ensure specialized functions, often vowels.

This centralization of the command function of FCS services at command point services 2, does not allow a Fast evolution of the user interface. Indeed, the part of the functionalities of the user interface hosted by the point of services command 2, and that consists of parameterizing, launching and chain the tasks demanded to the smart peripheral, it often based on a monolithic logical application that It covers the whole of the call handling. Therefore, any modification of the functionalities of the interface of user needs an intervention on the command module of services 2, at the level of data transmitted to the peripheral intelligent for the execution of the tasks delegated to it, to level of the chain of phases, and on the intelligent peripheral in order to modify sub-tasks and the type of expected data from the services command module 2. This gives as a result a lack of flexibility in the evolution of service depending on the need to perform non-testing regression after a modification has been made in the logical application of the service command point 2. This prolongs development / validation cycles

In addition, when the auxiliary platform is a value-added server, there are no recommendations from the IUT-T or international standards governing the exchanges In addition, operators have specifications own, sometimes slightly different from the rules.

When the auxiliary platform is a second point service command, there is no exchange mode for information between the two service command points that manage different services in the two smart networks different.

This results in a heterogeneity of the communication interfaces between the different platforms auxiliaries and the service command module, which has as effect need storage in the living memory of the point of services command 2 of several different logical applications that they make the latter more complex, and slow down the evolution of services.

The object of the invention consists in provide a new distribution of the command functions of services between the services command point and the platforms auxiliary, in which the user interface of the RI service is moved to external platforms that are machines specialized able to chain the set of stages of the user interface, all without tax interfaces with the other computers in the smart grid.

Another object of the invention is to suppress the heterogeneity of the interfaces between the command module of services, and the different auxiliary platforms, in order to allow the evolution of services without modification of the functions dedicated to the service command point.

According to the invention, the access device includes a communication interface that allows a platform auxiliary send, in real time, to the service command point, execution requests for service items, and receive as response, from said service command point, data that allow the execution of additional services.

According to the invention, for a given service, the requests sent to the service command point present the same format, whatever the auxiliary broadcasting platform, and the data sent by the service command point to the Auxiliary broadcasting platform have the same format.

According to the invention, the first element of service requested by the auxiliary platform at the command point of services, consists of either a user authentication, or already either in an access authorization, or in a call from a number.

Thanks to the invention, the command point of PCS service is downloaded from service management additional, which is displaced to auxiliary platforms. From this way, the development of a new service variant does not implies modification at the service command point if this evolution affects only the user interface or additional services. The developments of service variants are they are also facilitated, since they are more common about external platforms that over the services command point.

On the other hand, the cycle times of the service developments are reduced to the extent that it is not It is necessary to run non-regression tests on the aspects, network, control, pricing, ..., of the RI service, since these they are still in charge of the PCS, and since they are only the auxiliary platforms which evolve with the interface of user or with additional services.

In addition, the generic nature of requests for the communication interface according to the invention, allows to take in consideration, and in particular solve, the problem of inter-operation of network services intelligent in case the auxiliary platform is a PCS of another RI service.

The access procedure of a user to RI service includes the following stages:

- real-time shipping, by platform auxiliary to the service command point of at least one request for execution of a first service element dedicated to service command point;

- sending by the service command point to the auxiliary platform issuing the request, of data that allow the execution by the latter of additional services.

Other features and advantages of the invention, they will be revealed with the description that will be made in the following, taken as a non-limiting example, with reference to the attached drawings, in which:

Figure 1 schematically illustrates and partially, the connections between functional entities of a network intelligent of the prior art;

Figure 2 schematically illustrates and partially, the connections between the functional entities of a intelligent network according to the invention;

Figure 3 schematically illustrates a first communication mode between an auxiliary platform and a point of service command according to the invention;

Figure 4 schematically illustrates a second communication mode between an auxiliary platform and a point of service command according to the invention;

Figures 5 to 12 and 15 and 16, represent tables which illustrate the formats of the data exchanged between a point of command services and an auxiliary platform in an application particular according to the invention, and

Figures 13 and 14 illustrate the chain of two services with the use of the procedure according to the invention.

Figure 1, described above, illustrates a access device to an RI service in which a command point services 2 communicates with a database of services 4, a access switch 6 to which telephone line 7 has been connected of a user, a service management point 8 and a plurality of auxiliary platforms 10. An auxiliary platform designates interchangeably an intelligent peripheral 10_ {1}, 10_ {2}, a 10_ {3} value-added server such as a voicemail, a interactive vocal server or a second command point of RI services.

According to an essential characteristic of the invention, illustrated by Figure 2, an interface of communication 12, arranged between the service command point 2 and auxiliary platforms 10_ {i}, allows a platform auxiliary 10_ {i} send in real time to the command point of services 2, a request for execution of a first element of service. This first service element may be the User authentication, access authorization, or call from a number Service command point 2 executes this first service item, and forwards data, in response to the request issued, to allow the auxiliary platform 10_ {i} issuer execute the additional services that are dedicated to it. The auxiliary platform then transmits to the PCS other requests for execution by the latter of service elements They are dedicated to you.

The transmission of requests can be made, either through a direct connection, as illustrated in Figure 3, through the TCP / IP protocol (Transmission Communication Protocol / Internet Protocol, or the SS7 protocol (Signaling System No. 7, in English), or through a connection by relay, as illustrated in Figure 4, through the same path than the associated word circuit. In this case, because the requests transit in the signaling of the word path, the platform can easily link between requests applications and vocal communication. This is not the case in a direct connection, because two links are used, the first to carry requests via the IP (Internet Protocol) network, or by the SS7 network, and the second to carry the word signals. Be it has the need, for the auxiliary platform 10_ {i} and the Service command point 2, to synchronize the two links. He mechanism that allows this synchronization is based on the use of a reference, and has been illustrated in Figure 3 in the case of a IP connection This mechanism is the same for a direct connection through the SS7 protocol.

With reference to Figure 3, the sequencing of The TCP / IP connection with the use of the reference is as follows:

I. a vocal call is launched by the point of service command 2, through access switch 6, towards a 10_ {i} platform. A "R" reference is placed in the signaling that establishes this call, Low signaling National RNIS User System (SSURN), for example. This reference "R" is the reference for the future exchange session of application requests auxiliary platform / command point services 2;

II. the vocal call arrives at the platform that supports in the signaling of the word path, the reference "R" request exchange session with the point of service command 2;

III. the platform transmits over the TCP / IP link an Initialization request that contains the reference "R";

IV. by reference R, the command point of services 2 makes the link between the ongoing call to the platform 10, by word of mouth, and the request of Initialization, and responds to the Initialization request transmitting to the platform 10_ {i}, via the TCP / IP link, the response to this Initialization request; this answer contains also the reference "R", so that the platform 10_ {i} can identify which vocal call this reply;

V. platform 10_ {i} transmits others application requests, by the TCP / IP link, according to the service that She uses, for example, an authentication request.

Whatever the request issued by the TCP / IP link, contains the reference "R"; the answer transmitted by the PCS over the TCP / IP link, it also contains This reference "R". Thus, during the entire exchange session of requests via the TCP / IP link, the 10_ {i} platform and the service command point 2 can approximate the session of ongoing requests to the vocal call.

In case of a relay link, sequencing is the same as in the case of the TCP / IP link, except that the reference is not useful, because the network signaling performs the natural link between requests and the word path to which the requests refer. The two flows follow, in Effect, the same channel.

Sequences I to V correspond to their equivalents in the TCP / IP mode illustrated in Figure 3.

To better highlight the parameters exchanged between the auxiliary platform 10_ {i} and the point of services command 2, a particular application will be described in which the intelligent service is a telecommunication service by card. Service command point 2 will be designated as which follows through the expression PCS-Card, and the 10_ {i} auxiliary platforms will be designated external servers by the expression SE.

In operation, the PCS-Card responds to the Initialization dialog request between the Card application and the application hosted by the platform auxiliary 10_ {i} sending an initialization response that presents the structure:

- R-Initialization_PCS = {Context_A, Context_B}

- Context_A = {CtxDial, CtxSrv, CtxDdr, CtxCard, CtxInfo}

- Context_B = {BufferSE}

Figure 5 represents a table explaining the CtxDial parameter that represents the data that identifies the dialogue.

The Version field allows you to manage two versions of the description of the requests simultaneously, a new N version and its previous N-1 version. This indicates the auxiliary platform 10_ {i} in which version will be transmitted until the end of the PCS-SE dialogue.

The service number in the application will be deducted from the IdSv service identifier by means of the auxiliary platform 10_ {i} if necessary.

If the PCS-Card connects to an auxiliary platform 10_ {i} to initiate a vocal dialogue on this, the code Resumption Code is absent.

If the PCS-Card is connected from new to an auxiliary platform 10_ {i} to take back and continue a vocal dialogue, the InputDialSE field is evaluated through:

Input DIALSE = 0 if the auxiliary platform 10_ {i} connects again followed by entering "*" by part of the petitioner during the callback. This case no will be taken into consideration for the services they use vocal recognition

Input DIALSE = 1 if the auxiliary platform 10_ {i} reconnects after a lack of response from the requested.

DialSE input = 2 if the auxiliary platform 10_ {i} reconnects after a requested reengagement (call chain).

Figure 6 represents a table explaining the CtxSrv parameter representing the service data on the called Card.

The NEnch parameter indicates the number of chains of calls made on the PCS-Card by the petitioner before connection to the auxiliary platform 10_ {i} or between the connections to different auxiliary platforms 10_ {i}. The number of call chains accumulates after the start of the called Card.

NRDeMax is the maximum number of renewals of Requested calls authorized by the PCS-Card.

Figure 7 represents a table explaining the CtxDdr parameter that represents the data on the calling line and The petitioner

TypeTerm, CgPCateg, NatDdr, NResDdr, PrefFD, se evaluate from Provide at the beginning of the call Card and by analyzing the requesting number.

Figure 8 represents a table illustrating the Ctx parameter Card representing a part of the data sent to the CA authentication center, and its response.

These parameters cannot be provided anymore that in case an introduction of the card-code and interrogation of the Center Authentication, have been carried out by the PCS-Card prior to connection to the auxiliary platform 10_ {i}.

Ipas is evaluated from the introduction of the Subscriber's card number or the answer forwarded by the CA authentication center in case of fast authentication.

All other fields can be known to from the values provided by the Authentication Center AC.

Note that the Code field representing the Subscriber's confidential code will not be transmitted to the platform auxiliary 10_ {i} more than in very exceptional cases, as per example in an application of an auxiliary platform 10_ {i} that Allow the subscriber to modify his confidential code.

Figure 9 represents a table explaining the CtxInfo parameter that represents complementary data.

The NumDde parameter will be useful if the platform auxiliary 10_ {i} is a voice messenger that offers a service of Deferred Call

The TransMV field is also intended for a auxiliary platform of voice messaging type, and allows to specify the cause of forwarding to this messaging, if applicable: no response, occupation, accumulation, ..., during the call of a requested.

MaxCom is the maximum communication duration authorized, calculated in seconds by the Rate Server (SdT) hosted at the service management point. This field cannot be known more than if an introduction of the requested number and a interrogation of the service management point 8, are carried out by the PCS-Card prior to the request of connection to the auxiliary platform 10_ {i}.

The Callback field is a string of 15 octets broken down as follows:

- octets 1 to 5: field DATE = start time of call processing, coded in BCD according to a format MMJJhhmmss;

- octets 6 to 7: CPAÍS field = country code of the PCS (code in BCD);

- octets 8 to 11: IDPCS field = identifier of the PCS (SGTQS code), encoded in ASCII without parity;

- octets 12 to 15: REFC field = reference circular, coded in hexadecimal.

The CaracServ field has a length of 16 octets maximum:

- octet 1: CARSRV field = parameters characteristic of the Smart Network services. Is coded over an octet as follows (with A being the smallest bit weight):

A = 1, prohibition of redirection (ex: Audiotel or Free Call). If not, A = 0.

B = 1, Call Completion ban (ex: the 12). If not, B = 0.

C = 1, AOCD (tele-rate requested). If not, C = 0.

D = 1, prohibition of storage without emission of the response signal. If not, D = 0.

E, F, G, H in reserve and initialized to 0.

octet 2: SVTR field = cross services, evaluated at 0Fh.

The Context_B field serves at the command point of services to pass data previously transmitted by The auxiliary platform.

This field is useful when the command point of services and the auxiliary platform resume a dialogue after an interruption, for example during a call chain. The service command point does not interpret this field that It contains the data of the auxiliary platform, such as indication of a recovery point in your service script. Note that with the recovery of the dialogue for chaining of called, the auxiliary platform can be a platform of the same type than previously used, but of a model different.

Every time the PCS-Card wishes definitely release the connection with the auxiliary platform 10_ {i}, previously issues a PCS Release request to the auxiliary platform This request is intended to allow the auxiliary platform 10_ {i} properly release its resources and be able to issue, in cases where necessary, an announcement to petitioner before the connection is cut by the PCS-Card. The PCS-Card It will always respond to the PCS Release response to the platform auxiliary 10_ {i}, or eventually the fall of the timing of no response to this request, before issuing the FREE operation for The auxiliary platform connection.

Figure 10 represents a table illustrating the parameter map sent to the auxiliary platform 10_ {i} in a Release PCS request to the auxiliary platform.

For certain causes of end of dialogue, the auxiliary platform 10_ {i} will not be able to issue voice messages to petitioner. For example, if the Release PCS request to the Auxiliary platform is sent following a request from Call from a number and the requested pick up, is imperative that the PCS-Card cut immediately the petitioner vocal circuit-auxiliary platform 10_ {i} (SPLIT) to establish the vocal circuit applicant-requested (JOIN). The list of CFDial codes thus distinguish cases in which the auxiliary platform 10_ {i} will have or not the vocal link with the petitioner until Sending your reply.

CFDial = 0 to 49: the auxiliary platform 10_ {i} does not have a vocal link with the petitioner.

CFDial = 50 to 255: The auxiliary platform 10_ {i} has the vocal link with the petitioner until it is sent of your response to the PCS Release request to the platform assistant; Thus, it may issue a message to the petitioner.

The CFDial codes ≥ 100 designate the errors detected by the application driver Card and returned to the application so that it ends the dialogue between the PCS-Card and the platform auxiliary 10_ {i} through a PCS Release to the platform assistant.

The PCS-Card continues its treatment based on its cause for termination of dialogue CFDial:

If CFDial = 0: response waiting treatment Of what is called.

If CFDial = 1: continuation treatment of communication with the call.

The reception of the response of the platform Auxiliary is treated and treated in the corresponding states.

For the other CFDial values, the PCS-Card awaits the indication of the platform auxiliary 10_ {i} before causing a termination treatment call. If the indication of the auxiliary platform 10_ {i} does not has been received, the PCS-Card also produces a call termination treatment. In all cases, the reception of the response of the auxiliary platform 10_ {i} allows to PCS-Card definitively release the connection of the auxiliary platform 10_ {i} and evaluate the part of communication of the service offered by the latter, where appropriate Closing, and send a communication detail.

Sending the initialization response by part of the PCS-Cards, is followed by a succession of application requests transmitted to PCS-Cards by the auxiliary platform. These described below.

       \ newpage
    

Well understood, the applicative treatments of PCS-Card with the reception of the requests of the auxiliary platform, are given as indicative for the application Card using the command interface according to the invention.

In case the request is a request from authentication, an auxiliary platform 10_ {i} requests the authentication of a code card to the Center Card Authentication through PCS-Card. The acquisition of the figures of the code card, is completely dedicated to the auxiliary platform 10_ {i}, which performs the tasks following:

- invitation to compose or vocalize the numbers;

- repetitions in case of no catch or no vocalization by the user;

- possible format or length controls, ...

Note that to interrogate another Center of Authentication of Card applications, will eventually be an evolution of this request or the specification of other authentication requests, since the data types hosted by these centers may differ from one application to other.

Figure 11 represents a table that explains the parameters received from the auxiliary platform 10_ {i} for this authentication request

Various types of authentication are possible in the PCS-Card. The PCS-Card identify thanks to the sequence format card-code used by the user:

format 1: slow authentication: "i figures" (i = 9 digits of the card + 4 digits of the code);

format 2: slow authentication after the passage of put in DTMF: "# + i figures" or "* + i figures" (i = 13);

format 3: fast authentication: "j figures" (j = 4 code figures only);

format 4: fast authentication after the passage of put in DTMF: "# + j figures" or "* + j figures" (j = 4);

format 5: intense authentication: "\ alm {2} + k figures "or" * # + k figures "(k = 19 at most).

Two possibilities are offered to the platforms auxiliary 10_ {i}:

- Or the auxiliary platform 10_ {i} does not know the notions of slow, intense or fast authentication in whose case sends a sequence to the PCS-Card unique code card corresponding to the gross information used or vocalized by the user, and concatenated on a single string (Saisie_CC), even though the acquisition takes place in several stages on the platform auxiliary 10_ {i}. The TypAuth field is also absent in the petition.

- Or the auxiliary platform 10_ {i} has knowledge of the four types of authentication and is trained to propose them to the user or to identify them during the introduction / vocalization of the user, in which case, the platform auxiliary 10_ {i} sends to the PCS-Card the number of concatenated card and code number (Saisie_CC), without identify them "*", "#", "\ alm {2}" or "* #", but accompanied by the type of authentication recognized by the 10_ {i} TypAuth auxiliary platform:

TypAuth = 0: slow authentication (format 1 or 2)

TypAuth = 1: fast authentication (format 3 or 4)

TypAuth = 2: intense authentication (format 5).

In both cases, the PCS-Card does not receive the completion delimiter if the input is received in DTMF mode on the auxiliary platform 10_ {i}.

Figure 12 represents a table illustrating the parameters returned by the PCS-Card in Response to this authentication request.

The Return Code parameter is common in all responses to requests from the auxiliary platform towards the PCS-Card. It is composed:

- from a number field that is 0 or systematically If the request has been treated successfully, and a positive value associated to the error found, if not;

- of an Announcement field: this contains the number of OSV announcement that the PCS would play in case of error, corresponding to the mode without command interface. This is an optional field;

- from a Final Call field: positioned at NO, this eventually allows the auxiliary platform 10_ {i}, continue your vocal dialogue if the error is not blocking for your treatment, and repeat the request or chain a new one (for example: the CRES of the authentication center indicates that the code is non-concordant). Positioned in YES, indicates the auxiliary platform that the PCS-Card will not be able to no case continue the call. The auxiliary platform 10_ {i} you must warn the user of the error, and send a request "Release Auxiliary platform towards the PCS "(example: no response from authentication center without acceptance of rejection exception).

The Ipas card number is transmitted systematically to the auxiliary platform 10_ {i}, whether it has carried out as if not, the analysis of the sequence Saisie_CC.

The Code field (confidential code of the user), will not be transmitted to the auxiliary platform 10_ {i} anymore that in very exceptional cases (example: platform application auxiliary 10_ {i} that allows the user to modify their code confidential).

The parameters Ilas, Tsc, Cco, Catc, Scom, Imi and Cptx are a new copy of the parameters restored by the Center Authentication If the Card has not reached the Cptx and Imi limit, They will not be present.

NbAuthMax and CptAuth provide the possibility to the 10_ {i} auxiliary platform to modulate your ads introduction of card-code (first, nth or last announcement), or propose a help from a given level of failed attempts.

Authorized_chaining, Call_urgent_without_credit and Exception_rejection, are deducted by the PCS-Response type card from the center of CA authentication and call context. These are transmitted to the auxiliary platform 10_ {i} to eventually allow guide the treatment of your vocal coding.

When the request sent by the platform auxiliary 10_ {i} is a request for authorization and valuation of service, the term service of the request designates both a number internal service to the auxiliary platform 10_ {i}, as a requested number assembled by the auxiliary platform 10_ {i}, or as a demanded number assembled by the PCS.

The request for authorization and recovery of service, is sent by the auxiliary platform 10_ {i} to assess the cost of the service consulted above, authorize the user to consult the next chosen service, and where appropriate, Open a new DC communication detail for this service. He Treatment of the request by the PCS-Card It includes three parts:

- Communication assessment treatment previous (calculation of duration, cost, issuance of a DC, decrease of the eventual limit of the card);

- Authorization treatment on the service next (number analysis, authorization / eventual translation to the CA, request for credit to the SdT);

- Rate Application treatment Next service (opening of your DC).

The input parameters of the request (Valo, Aut, ApTar) will indicate which treatments will be carried out by the PCS-Card before sending the CodeReturn.

Figure 13 illustrates an example in which a subscriber chains two internal services SV1 and SV2 on the same 10_ {i} free access auxiliary platform, which includes the following stages:

a) connection to the auxiliary platform 10_ {i} of Free access. No communication detail (DC) is open in free access case;

b) (Valo, Aut, ApTar) = (0,1,1). Application authorization on service 1 and opening of the detail of DC1 communication;

c) (Valo, Aut, ApTar) = (1,0,0). Rating of communication detail DC1;

d) (Valo, Aut, ApTar) = (0,1,1). Petition for authorization on service 2 and opening of the detail of DC2 communication;

e) (Valo, Aut, ApTar) = (1,0,0). Rating of DC2 communication detail.

Figure 14 illustrates an example in which a subscriber chains two internal services SV1 and SV2 on the same 10_ {i} auxiliary platform for access, payment, which includes following stages:

a) During connection to the auxiliary platform 10_ {i}, the PCS opens the communication detail DC0. The time of connection to the auxiliary platform 10_ {i} is counted from disengagement of the auxiliary platform 10_ {i}.

b) (Valo, Aut, ApTar) = (1,1,1). Rating of communication detail DC0, authorization request on the service 1 and opening of DC1.

c) (Valo, Aut, ApTar) = (1,1,1). Rating of communication detail DC1, authorization request for the return to the general menu (essentially to determine the credit remaining of a card with limit after consultation of the service 1), and opening of the DC2 communication detail.

d) (Valo, Aut, ApTar) = (1,1,1). Rating of DC2 communication detail, authorization request on the service 2 and opening of the DC3 communication detail.

e) (Valo, Aut, ApTar) = (1,1,1). Rating of DC3 communication detail, authorization request for the return to the general menu, and open the communication detail DC4

f) (Valo, Aut, ApTar) = (1,0,0). Rating of DC4 communication detail.

Note that the time reference is always The PCS-Card clock. The beginnings and end of service inquiries must be memorized by the PCS. The auxiliary platform 10_ {i} must thus formulate its request for authorization and valuation of service depending on the nature of the service (internal service to the auxiliary platform 10_ {i}, called assembled by means of the auxiliary platform 10_ {i}, or call assembled via PCS-Card), and Tell the PCS when to increase the hours. The parameters of Affected input are the triplet (Valo, Aut, ApTar) and the indicator Immediate_tariff_application.

In the case of an internal platform service auxiliary 10_ {i} (particular vocal menu of the auxiliary platform 10_ {i}), the auxiliary platform 10_ {i} must assess your request of authorization and service valuation with (Valo, Aut, ApTar) = (x, 1,1) and Immediate_tariff_Application = YES. The PCS memorizes the time Start of service consultation until after opening of the DC communication detail. The end of the service query It is indicated by a second request with (Valo, Aut, ApTar) = (1, x, x).

In the event that the service is a call assembled by the auxiliary platform 10_ {i}, the platform auxiliary 10_ {i} must evaluate a first authorization request and service valuation with (Valo, Aut, ApTar) = (x, 1,0). The auxiliary platform 10_ {i} assembles the call. When the one who has called pick-up, sends a card to the PCS-Card second request for authorization and service assessment with (Valo, Aut, ApTar) = (0,0,1) and Immediate_tariff_App = YES When the user hangs up again, the auxiliary platform 10_ {i} send a third request with (Valo, Aut, ApTar) = (1, x, x) to indicate the end of the conversation at PCS-Card.

In the event that the service is a call assembled by the PCS-Card: the platform auxiliary 10_ {i} must evaluate a first authorization request and service valuation with (Valo, Aut, ApTar) = (x, 1,0). He PCS-Card relieves the start and start moments conversation ending on the ANM / CON and REL signals, without indication of the auxiliary platform 10_ {i}.

Figure 15 represents a table illustrating the parameters received from the auxiliary platform 10_ {i} for this request for authorization and service valuation.

The ModoTax1 field is evaluated by the platform auxiliary 10_ {i} according to the value of the ModeTax2 parameter of the request for authorization and assessment of previous service.

As an example, a subscriber who owns a card with limit, choose to consult a payment service offered by the auxiliary platform 10_ {i}. This one sends to PCS-Card a request for authorization and service evaluation parameterized with (Valo, Aut, ApTar) = (absent, present, present). The PCS-Card carries out an SdT interrogation during the course of the treatment of request to know the mode of appraisal of the service, and what communicate to the auxiliary platform 10_ {i} in its response (ModeTax2). The auxiliary platform 10_ {i} may or may not use this value in its treatment, it memorizes it until the end of the service consultation by the user. Once the query has finished, the auxiliary platform 10_ {i} sends to PCS-Card a request for authorization and service evaluation parameterized with (Valo, Aut, ApTar) = (present, absent, absent) evoking in the field ModeTax1 the type of service pricing. There is no ambiguity for the PCS-Card on the valuation mode of the service.

- ModeTax1 is worth 0 (normal cost), 1 (cost global), 2 (free), or 3 (ITX pricing).

- ModeTax1 is absent if Valo = 0.

The Number field accepts all formats Possible: national, relocated short or long, special, International, summarized or private.

The AnnCredito field = 1 allows the platform auxiliary 10_ {i} ask the latter that the credit announcement be issued exceptionally by the PCS-Card in Organ mode Vocal Server (OSV).

The Number and AnnCredito fields are absent when Aut is absent.

The Immediate_tariff_Application field is absent when ApTar is absent.

In the event that the request auxiliary platform towards PCS-Cards is a call request from a number, also takes into account the case of a request for routing to an operator post following an error of introduction, or following a no-introduction of the user. The auxiliary platform 10_ {i} may or may not have made the call request of a number is preceded by a request from authorization-service assessment on this number For example:

- for an ordinary requested number, the auxiliary platform 10_ {i} will have made a request for authorization-service assessment on the number of the requested one, in order to verify at least that the number is authorized for routing;

- for a number of access to the posts of operators: the numbers are already available in the data of exploitation of the PCS-Card in network format. The they are routable and are used in the CREATE operation without Supplementary analysis of the PCS-Card.

Once the return of called, the auxiliary platform 10_ {i} is released definitely. A reconnection with the auxiliary platform 10_ {i} It will be done in the following three cases:

- when the petitioner wishes to interrupt the establishment of a call in progress;

- with the fall of the timing of non-response of the requested;

- or eventually, after the conversation, to propose a call chain.

The PCS-Card will indicate to the auxiliary platform 10_ {i} that the recovery point of the vocal coding is "star input", "no response from requested "or" call chaining "through the value of the InputDialSe field of Context_A of the response of initialization

Figure 16 represents a table illustrating the parameters received from the auxiliary platform 10_ {i}.

The NumDde field is optional, and with the following operation:

- NumDde is absent if the auxiliary platform 10_ {i} has previously issued an authorization request / service valuation. The PCS-Card has memorized and the defendant's network number (in the format of the operation CREATE), and its nature (national, international, ...) after having analyzed the field Number of the authorization / assessment request of service;

- NumDde is absent if the auxiliary platform 10_ {i} makes a call request to a workstation operator. The Operator_Call field is YES in that case;

- NumDde is directly a national network number routable if the auxiliary platform 10_ {i} wishes to perform the establishment of a communication to a requested number without authorization / prior assessment of the service.

The Redial field SE = 0 indicates the PCS-Card you must contact the auxiliary platform 10_ {i} after you re-hang the one that It has been called. If the Recall field is worth 1, the platform auxiliary 10_ {i} is not called again, and the chains of eventual calls will be proposed in the mode without interface of command.

If the Recall field is worth 2, the platform auxiliary 10_ {i} is not called again, and no will be proposed Call chaining in mode without command interface.

Note that the PCS-Card does not performs no call chaining without interface command (PCS / OSV mode) if the nature of the auxiliary platform 10_ {i} is that of being able to be called by the PCS in interface mode of command after receipt of Provide-Instruction by the PCS, since in this case the auxiliary platform 10_ {i} carries the interface set of service user. In the case of the Figure, Recall should not never be equal to 1.

The Operator_Call field allows the PCS-Card carry out certain treatments supplementary, particular to the forwarding to the operator: search of the operator network number in the operating tables, issuance of An announcement to the operator after it picks up, ...

It should be noted that Context_B that contains useful information on the auxiliary platform 10_ {i}, to return to take your vocal coding must be transmitted systematically to the PCS-Card with the request of number call, since, on each call, the platform auxiliary 10_ {i} does not know if there will be type recovery points "star entry" or "no response from the requested".

On the contrary, the auxiliary platform 10_ {i} always indicate to the PCS if it wishes to be recontacted or not after an effective applicant-requested conversation, valuing the Recall field of the input parameters of the Call request for a number.

Claims (14)

1. A user's access device to the intelligent services of an intelligent network (IR) that includes a service command point (2) that communicates with at least one group of physical entities (4, 6, 8) intended to provide at least a first service element, and with a plurality of auxiliary platforms (10_ {i}) intended to provide the user with additional service elements that complete the first service element, a device characterized in that it also includes a communication interface ( 12) that allows an auxiliary platform (10_ {i}) to send in real time to the service command point (2), requests for execution of service elements, and receive as a response from said service command point (2) , data that allow the execution of said additional services. 2. Device according to claim 1, characterized in that, for a given service, the requests sent to the service command point (2) have the same format whatever the sending auxiliary platform (10_ {i}), and the data sent by the service command point (2) to the auxiliary platform (10_ {i}) they have the same format. 3. Device according to claim 1, characterized in that the first request for execution of service elements transmitted by the auxiliary platform is either a user authentication request, or a request for access authorization, or a call request of a number Device according to claim 2, characterized in that the requests are sent to the service command point (2) in direct mode according to the TCP / IP protocol. 5. Device according to claim 2, characterized in that the requests are sent to the service command point (2) in direct mode according to the SS7 protocol. Device according to claim 2, characterized in that the requests are sent to the service command point (2) in relay mode through the same channel as that of the voice signaling. Device according to claim 2, characterized in that the auxiliary platform (10_) is an intelligent peripheral. Device according to claim 2, characterized in that the auxiliary platform (10_ {i}) is a value-added server. Device according to claim 2, characterized in that the auxiliary platform (10_ {i}) is a service command point of a second intelligent network. Device according to claim 1, characterized in that the group of physical entities includes at least one service database (4), at least one access switch (6), and at least one service management point (8) or equivalent function, housed in the service command point (2). 11. Device according to claim 7, characterized in that the intelligent peripheral is a platform for interactions with the user that ensures the following additional service: a - information for the user during use of the service; b - invitation for the user to determine their options; c - collection of user options; d - initiation and chain of actions (a), (b) and (c); e - chain of actions (a), (b) and (c) with other actions that do not emerge from the platform, but are under-treated at the service command point (2) or in physical entities (4, 6, 8) through the command point of services (2), by means of the execution requests of service transmitted to the service command point (2). 12. A user's access procedure to the RI services of an intelligent network that includes a service command point (2) that communicates with at least one group of physical entities (4, 6, 8) intended to provide at least one first service element, and with a plurality of auxiliary platforms (10_ {i}) intended to provide the user with additional service elements that complete the first service element, said procedure being characterized in that it includes the following steps: - real-time shipping, through a auxiliary platform (10_ {i}) to the service command point (2), of at least one request for execution of service elements dedicated to the service command point (2);

         \ newpage
      

- sending by the command point of service (2), to the said auxiliary platform (10_ {i}), of the data that allow the execution by the latter of services additional. 13. Method according to claim 12, characterized in that, for a given service, the requests sent to the service command point (2) have the same format whatever the sending auxiliary platform (10_ {i}), and the data sent by the service command point (2) to the said auxiliary platform (10_ {i}) issuing the same format. 14. Method according to claim 12, characterized in that the first service element executable by the service command point (2) and requested by the auxiliary platform (10_ {i}) to the service command point (2) by means of a request includes either a stage of user authentication, or a stage of authorization of access to a service, or a stage of calling from a number.