Technique for providing announcements in mobile-originated calls

ES 2 302 799 T3

DESCRIPTION

Technique for serving announcements on mobile originated calls.

Context technique

The present invention relates to mobile networks and more particularly, the present invention relates to a technique for providing announcements for mobile originated calls in a mobile network employing an IP (Internet Protocol) transport mechanism. In general, wireless packet exchange networks provide communications for mobile terminals without requiring a physical connection to access the network. Both the General Packet Radio Service (GPRS) in the Global Mobile Communications System (GSM) and the Universal Mobile Telecommunications System (UMTS) have been developed to facilitate wireless communication networks with a section for packet exchange and another section for circuit exchange.

As noted on its website http://www.3gpp.org, the Third Generation Joint Project, usually known by its acronym 3GPP, is an organization whose partners have agreed to cooperate in the production of Specifications. Globally Applicable Technical Reports and Techniques for a 3 Mobile System^to Generation based on GSM core networks and on the radio access technology that these networks support (that is, Universal Terrestrial Radio Access (UTrA), both the Duplex Time Division (FDD) and the Duplex Frequency Division ( TDD)).

In addition, 3GPP partners have agreed to cooperate with the maintenance and development of a Global System for Mobile Communications (GSM) by creating Technical Specifications and Technical Reports that include the evolution or development of radio access technologies (for example, the General Packet Radio Service (GPRS) and the Enhanced Data for Global Evolution GSM (EdGe)).

Accordingly, 3GPP presents several Technical Specifications that are subsequently used by the telecommunications industry to produce mobile terminals and associated systems that have been standardized in such a way that a mobile terminal from one manufacturer can communicate with a mobile terminal or system from another manufacturer. These Technical Specifications are constantly revised in accordance with the agreements reached by the 3GPP partners to allow for changes and improvements in technology.

The Technical Specification TS 23.060, Version V3.3.0, was introduced in January 2001 by the 3GPP and defines the description of step 2 of the service for the packet domain, which includes GPRS in GSMA and UMTS.

A subscriber to a network can have one or more addresses (PDP). Each PDP address is described by one or more PDP contexts in the Mobile Station (MS), the serving GPRS Support Node (SGSN), and the Gateway GPRS Support Node. Each PDP context may have mapping and routing information to direct the transfer of data to and from its associated PDP address and a Traffic Flow Template (TFT) to review the transferred data.

Each PDP context can be selectively and independently activated, modified, and deactivated. The activation status of the PDP context indicates whether data transfer is enabled for a PDP address and a corresponding TFT. If all PDP contexts associated with the same PDP address are down or down, all data transfer for that PDP address is disabled. All PDP contexts of a subscriber are associated with the same Mobility Management (MM) context for the International Mobile Subscriber Identity (IMSI) of the subscriber in question. Establishing a PDP context means establishing a communication channel between the MM and the GGSN.

Fig. 1, presented for exemplary purposes only, shows the PDP context activation procedure between an MM and a GGSN in a UMTS system and corresponds to Fig. 62 of the aforementioned Technical Specification. The following description of the steps in Fig. 1 are also contained therein.

1) The MS sends a PDP Context Request activated message (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) to the SGNS. The MS may use the PDP Address to indicate whether or not it needs the use of a static PDP address or whether or not it needs the use of a dynamic PDP address. The MS may leave the PDP address empty to request a dynamic PDP address. The MS may use the Access Point Name to select a reference point for a given external network and / or to select a service. The Access Point Name is a logical name that refers to the external packet data network and / or the service to which the subscriber wishes to connect. The requested QoS indicates the desired QoS profile. The PDP Configuration Options can be used to request optional PDP parameters from the GGSN (see GSM 09.60). The PDP Configuration Options are sent transparently through the SGSN.

3) In UMTS, the RAB system is carried out through the RAB Assignment procedure, see the subsidiary clause “RAB Assignment Procedure”.

5) The SGSN validates the Request for the Activated PDP Context using the PDP Type (optional), the PDP Address (optional), and the Access Point Name (optional) provided by the MS subscription records and

ES 2 302 799 T3 to the PDP context. The validation criteria, APN selection criteria and APN to GGSN mapping are described in Annex A.

If no GGSN address can be derived or if the SGSN has determined that the PDP Context Activated Request is invalid according to the rules described in Annex A, then the SGSN rejects the PDP context activation request.

If a GGSN address can be derived, the SGSN creates a TEID for the requested PDP context. If the MS requests a dynamic address, then the SGSN allows a GGSN to assign the dynamic address. The SGSN may restrict the requested QoS attributes due to its capabilities, current load, and subscribed or subscribed QoS profile.

The SGSN sends a Request to Create a PDP Context message (PDP Type, PDP Address, Access Point Name, Negotiated QoS, TEID, NSAPI, MSISDN, Selection Mode, Load Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, PDP Configuration Options) to the affected GGSN. The Access Point Name must be the APN Network identifier of the APN selected according to the procedure described in Annex A. The PDP address can be empty if a dynamic address is requested. The GGSN can use an Access Point Name to find an external network and can optionally activate the service for this APN. The Selection Mode indicates whether an APN subscriber has been selected, or a non-subscriber APN sent by MS or a non-subscriber APN chosen by SGSN has been selected. The Selection Mode is established in accordance with Annex A. The GGSN may employ the Selection Mode when deciding whether to accept or reject the activation of the PDP context. For example, if an APN requires a subscription, in this case the GGSN is configured to accept only the activation of the PDP context that requests a subscribed APN as indicated by the SGSN with the Selection Mode. The Load Characteristics indicate what type of load corresponds to the PDP Context. The SGSN may copy the Load Characteristics from the Subscribed Load Characteristics if it receives them from the HLR. The SGSN must include Trace Reference, Trace Type, Trigger Id, and OMC Identity if the GGSN trace is activated. The SGSN must copy the Trace Reference, Trace Type, Trigger Id, and OMC Identity from the trace information received from the HRL or OMC.

The GGSN creates a new entry for its PDP context table and generates a Load Id. The new entry allows the GGSN to route through PDP PDUs between the SGSN network and the external PDP network, and start loading. The GGSN may also restrict the Negotiated QoS due to its disabilities or its current load. The GGSN then returns the PDP Context Creative Response message (TEID, PDP Address, PDP Configuration Options, QoS Negotiated, Load Id, Cause) to the SGSN. A PDP Address is included in case the GGSN assigned a PDP address. If the GGSN has been configured by the operator to use External PDP Address Assignment for the requested APN, then the PDP address must be negotiated by the MS with the external PDN after the PDP Context Activation procedure has been completed. The GGSN can transmit, modify and control these negotiations as long as the PDP context is in the ACTIVE state and can use the SGSN Initiated PDP Context Modification procedure to transfer the PDP address currently in use to the SGSN and MS. The PDP Configuration Options contain optional PDP parameters that the GGSN can transmit to the MS. These optional PDP parameters can be requested by the MS in the PDP Active Context Request message, or they can be sent without having to be requested by the GGSN. PDP Configuration Options are sent transparently through the SGSN. The PDP Context Creation messages are sent over the backbone.

If the Negotiated QoS received from the SGSN is incompatible with the PDP context that is inactivated, in this case the GGSN rejects the PDP Context creation request message. The supported QoS profiles are configured by the GGSN operator.

7) The SNSG inserts the NSAPI together with the GGSN address in its PDP context. If the MS has requested a dynamic address, the PDP address received from the GGSN is inserted into the PDP context. The SGSN selects the Radio Priority and the Id Packet Flow based on the Negotiated QoS, and returns to the Active PDP Context Acceptance message (PDP Type, PDP Address, TI, Negotiated QoS, Radio Priority, Id Packet Flow , PDP Configuration Options) to the MS. Now, the SGSN is able to establish the PDP PDUs route between the GGSN and the MS, to start the upload.

Similarly, Fig. 2, also presented for exemplary purposes only, shows the PDP Secondary Context Activation Procedure and corresponds to Fig. 64 of the aforementioned Technical Specification. The following description of the steps in Fig. 2 is also contained therein.

The PDP Secondary Context Activation Procedure can be used to activate a PDP context while reusing the PDP address and other PDP context information from an already active PDP context, but with a different QoS profile. The procedures for APN selection and PDP address negotiation are not executed. Each PDP context that shares the same PDP address and APN can be identified by a single TI and a single NSAPI.

ES 2 302 799 T3

The PDP Secondary Context Activation Procedure can be executed without providing a Traffic Flow Template (TFT) to the newly activated PDP context if all other active PDP contexts for this PDP address and APN already have an associated TFT. If a TFT cannot be provided. The TFT contains attributes that specify an IP compensation filter that is used to direct data packets received from the external interconnected packet data network to the newly activated PDP context.

1) The MS sends an Activated Secondary PDP Context Request message (TI linked, NSAPI, TI, QoS Requested, TFT) to the SGSN. The Linked TI indicates the TI value assigned to each of the PDP contexts already activated for this PDP address and APN. The requested QoS indicates the desired QoS profile. TFT is sent transparently via SGSN to the GGSN to allow packet classification for downlink data transfer. TI and NSAPI contain values ​​not used by another activated PDP context.

2) In UTMS, the RAB system is carried out using the RAB Assignment procedure.

3) The SGSN validates the Active Secondary PDP Context Request using the TI indicated by the Linked TI. The same GGSN address is used by the SGSN as for the PDP contexts already activated for that TI and PDP address.

The SGSN and the GGSN can restrict and negotiate the requested QoS as specified in the subclause "PDP Context Activation Procedure". The SGSN sends a PDP Context Creation Pericon message (QoS Negotiated, TEID, NSAI, Primary NSAPI, TFT) to the affected GGSN. The Primary NSAPI indicates the NSAPI value assigned to each of the PDP contexts already activated for this PDP address and APN. The TFT is included only if it is received in the PDP Activated Secondary Context Request message. The GGSN uses the same external network as that used by the PDP contexts already activated for that PDP address, generates a new entry in its PDP context table, and stores the TFT. The new entry allows the GGSN to establish PDP PDUs routes through different GTP tunnels between the SGSN and the external PDP network. The GGSN returns the PDP Context Creation Response message (TEID, QoS Negotiated, Cause) to the SGSN.

6) The SGSN selects a Radio Priority and Packet Flow Id based on Negotiated QoS, and returns to the PDP Activated Secondary Context Acceptance message (TI, Negotiated QoS, Radio Priority, Packet Flow Id) at the MS. Now, the SGSN is able to establish PDP PDUs routes between the GGSN and the MS via different GTP tunnels and possibly different LLC links.

Fig. 3, also presented for exemplary purposes only, shows the PDP context modification procedure initiated by SGSN and corresponds to Fig. 68 of the aforementioned Technical Specification. The following description of the steps in Fig. 3 is also contained therein.

An MS or a GGSN may request, an SGSN may decide, possibly activated by the HLR as explained in the subclause "Subscriber Data Insertion Procedure" or activated by the RAB Release procedure initiated by an RNC, or a MS and an SGSN may decide, after RNC-initiated release, to modify the parameters that were negotiated during an activation procedure for one or more PDP contexts. The following parameters can be modified:

- QoS (Quality of Service) Negotiated;

- Radio Priority;

- Packet Flow Id;

- PDP address (in case the modification procedure has been initiated by GGSN); Y

- TFT (in case the modification procedure has been initiated by MS).

The SGSN may request the modification of parameters by sending a PDP Context Modification Request message to the MS.

A GGSN can request the modification of parameters by sending a PDP Context Update Request message to the SGSN.

An MS may request the modification of parameters by sending a PDP Context Modification Request message to the SGSN.

An RNC may request a release by sending a Release Request message to the SGSN. Upon release, the MS and the SGSN may modify the PDP contexts according to the principles set forth in the subclause "RNC Initiated PDP Context Modification Procedure".

ES 2 302 799 T3

An RNC may request release of the radio access bearer. After RAB release the MS and SGSN may locally modify the corresponding PDP context according to the principles set out in the subclause "RAB Release Initiated PDP Local Context Modification Procedure".

A trace can be activated while the PDP context is active. To enable trace activation in a GGSN, the SGSN may send a PDP Context Update Request message to the GGSN. If the PDP context modification is carried out solely to activate a trace, then the SGSN may not send a PDP Context Modification Request message to the MS.

1) The SGSN can send a PDP Context Request message (TEID, NSAPI, Negotiated QoS, Trace Reference, Trace Type, Id Indicator, OMC Identity) to the GGSN. If the received Negotiated QoS is incompatible with the PDP context being modified, then the GGSN rejects the PDP Context Update Request. The supported QoS profiles are configured through the GGSN operator. The SGSN may include a Trace Reference, Trace Type, Identifier Id and OMC Identity in the message if the GGSN trace is activated while the PDP context is active. The SGSN can copy the Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC.

2) The GGSN may restrict Negotiated QoS due to its disabilities and current load. The GGSN stores the Negotiated QoS and returns a PDP Context Update Response message (TEID, Negotiated QoS, Cause).

3) The SGSN selects the Radio Priority and the Packet Flow Id over the Negotiated QoS, and can send a PDP Context Modification Request message (TI, Negotiated QoS, Radio Priority, Packet Flow Id) to the MS.

4) The MS supports it by returning a Modified PDP Context Acceptance message. If the MS does not accept the new Negotiated QoS, it will have to deactivate the PDP context with the MS Procedure Initiated by Deactivation of PDP Context.

5) In UMTS, the modification of the bearer to radio access can be carried out by the RAB Assignment Procedure.

6) If the BSS trace is activated while the PDP context is active, in this case the SGSN must send a Trace Appeal message (Trace Reference, Trace Type, Id Indicator, OMC Identity) to the BSS or UTRAN. The Trace Reference and Trace Type are copied from the trace information received from the HLR or OMC.

1) The SGSN can send a PDP Context Update Request message (TEID, NSAPI, Negotiated QoS, Trace Reference, Trace Type, Id Indicator, OMC Identity) to the GGSN. If the Negotiated QoS received from SGSN is incompatible with the PDP context being modified, in this case the GGSN rejects the PDP Context Update Request. The supported QoS profiles are configured through the GGSN operator. The SGSN may include a Trace Reference, Trace Type, Identifier Id and OMC Identity in the message if the GGSN trace is activated while the PDP context is active. The SGSN can copy the Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC.

2) The GGSN may restrict Negotiated QoS due to its disabilities and current load. The GGSN stores the Negotiated QoS and returns a PDP Context Update Response message (TEID, Negotiated QoS, Cause).

3) The SGSN selects the Radio Priority and the Packet Flow Id over the Negotiated QoS, and can send a PDP Context Modification Request message (TI, Negotiated QoS, Radio Priority, Packet Flow Id) to the MS.

4) The MS supports it by returning a Modified PDP Context Acceptance message. If the MS does not accept the new Negotiated QoS, it will have to deactivate the PDP context with the MS Procedure Initiated by Deactivation of PDP Context.

5) In UMTS, the modification of the bearer to radio access can be carried out by the RAB Assignment Procedure.

6) If the BSS trace is activated while the PDP context is active, in this case the SGSN must send a Trace Appeal message (Trace Reference, Trace Type, Id Indicator, OMC Identity) to the BSS or UTRAN. The Trace Reference and Trace Type are copied from the trace information received from the HLR or OMC.

Fig. 4, also presented for exemplary purposes only, illustrates the PDP Context procedure initiated by the GGSN and corresponds to Fig. 69 of the aforementioned Technical Specification. The following description of the steps in Fig. 4 are also contained therein.

ES 2 302 799 T3

1) The GGSN sends a PDP Context Update Request message (TEID, NSAPI, PDP Address, QoS Requested) to the SGSN. The Requested QoS indicates the desired QoS profile. The PDP address is optional.

2) The SGSN may restrict the desired QoS profile due to its disabilities, current load, current QoS profile, and subscribed QoS profile. The SGSN selects the Radio Priority and Packet Flow Id based on Negotiated QoS, and sends a PDP Context Modification Request message (TI, PDP Address, Negotiated QoS, Radio Priority, Packet Flow Id ) to MS. The PDP address is optional.

3) The MS supports it by returning a Modified PDP Context Acceptance message. If the MS does not accept the new Negotiated QoS, it will have to deactivate the PDP context with the MS Procedure Initiated by Deactivation of PDP Context.

4) In UMTS, the modification of the bearer to radio access can be carried out by the RAB Assignment Procedure.

5) Upon receipt of the PDP Context Modification Acceptance message, or upon completion of the RAB modification procedure, the SGSN returns a PDP Context Update Response message (TEID, QoS Negotiated) to the GGSN. If the SGSN receives a PDP Context Deactivation Request message, it will have to follow the PDP Context Deactivation Procedure initiated by the MS.

Fig. 5, also presented for exemplary purposes only, shows the MS-initiated PDP context modification procedure and corresponds to Fig. 70 of the aforementioned Technical Specification. The following description of the steps in Fig. 5 is also contained therein.

1) The MS sends a PDP Context Modification Request message (TI, QoS Negotiated, TFT) to the SGSN. Either the Requested QoS, or TFT or both can be included. The Requested QoS indicates the desired QoS profile, while TFT indicates the TFT to be added or modified or removed from the PDP context.

2) The SGSN may restrict the desired QoS profile due to its disabilities, current load, current QoS profile, and subscribed QoS profile. The SGSN sends a PDP Context Update Request message (TEID, NSAPI, Negotiated QoS, TFT) to the GGSN. If the Negotiated QoS and / or TFT received from SGSN is incompatible with the PDP context being modified (for example, if TFT contains inconsistent packet filters), in this case the GGSN rejects the PDP Context Update Request. The supported QoS profiles are configured through the GGSN operator.

3) The GGSN may further restrict the Negotiated QoS due to its disabilities and current load. The GGSN stores the Negotiated QoS, stores, modifies or removes TFT from the PDP context as indicated in TFT, and returns a PDP Context Update Response (TEID, Negotiated QoS) message.

4) In UMTS, the modification of the bearer to radio access can be carried out by the RAB Assignment Procedure.

5) The SGSN selects the Radio Priority and Packet Flow Id over the Negotiated QoS, and can send a PDP Context Modification Request message (TI, Negotiated QoS, Radio Priority, Packet Flow Id) to the MS.

NOTE: If the SGSN does not accept the Requested QoS, in this case steps 2 and 3 of this procedure are skipped and the existing Negotiated QoS is returned to the MS in step 4.

Despite the numerous details provided in the aforementioned Technical Specification, many features associated with mobile networks have not been covered. That is, techniques for providing announcements on mobile originated calls have not yet been incorporated into the aforementioned technical specification and it is to these details that the present invention is directed.

Description of the invention

In the present invention, the signaling exchanged by the application layer in the MS is arranged according to the procedure / messages that need to be carried out by the transport levels in the MS and in the network in order to establish the IP multimedia calls.

When the application level in the MS sends a start message to establish an IP multimedia call, before or after sending said message over a radio interface, the MS carries out the appropriate procedures, depending on the type of access adopted, to establish the appropriate bearers on the radio interface and in the network in order to satisfy the call requirements specified by the application level in the initiating message.

The technique of the present invention is applied to the case of calls originated by mobiles, and consists in that the MS carries out the aforementioned transport level before or after sending the setup message or before sending a confirmation or acceptance message. call back to called party.

ES 2 302 799 T3

In the technique according to the present invention, for a call originated by a mobile that intends to be answered by means of an announcement, the MS is informed of the transport address of the node that will make the announcement and the MS at this time initiates a modifying procedure of the PDP context to establish a Traffic Flow Sample (TFT) according to the Transport Direction (TA) of the node.

Brief description of the drawings

Both the aforementioned and a better understanding of the present invention will become clearer and more evident from the following detailed description of exemplary embodiments and claims as long as they are read in connection with the accompanying drawings, all forming part of the description. of the invention. Although all of the foregoing and the following written and illustrated description are focused on describing exemplary embodiments of the invention, it should be clearly understood that this is by way of illustration and example only and that the invention is not limited thereto. The scope of the present invention is limited only by the terms of the appended claims.

The following is a brief description of the drawings, where:

Fig. 1 illustrates the steps in a PDP context activation procedure.

Fig. 2 illustrates the steps in a PDP secondary context activation procedure.

Figs. 3-5 illustrate the steps that respectively occur in an SGSN-initiated, GGSN-initiated and MS-initiated PDP context modification procedure.

Figs. 6 and 7 also show in detail the steps that are taken in a call setup procedure.

Fig. 8 illustrates an example of the steps taken in a technique for providing announcements on mobile originated calls in accordance with the present invention.

Most suitable mode to carry out the invention

Before beginning with a detailed description of the invention in question, it is important to mention the following in the proper order. Where appropriate, the same reference numerals and letters are used to designate identical, corresponding or similar components in the different figures of the drawings. Furthermore, and it is noted in the detailed description below, sizes / models / values ​​/ ranges of the examples can be given, although the present invention is not limited exclusively to them. Lastly, well-known elements may not be shown within the drawing figures in order to simplify illustration and description and not to confuse the invention.

In addition to the aforementioned Technical Specification, Technical Specification TS 23.228, Version V1.5.0, presented by 3GPP in March 2001, defines the step 2 service description for the IP Multimedia Subsystem (IM), which includes the elements necessary to support Multimedia (IM) IP services in UMTS.

Fig. 6, which corresponds to Fig. 5.7 of Technical Specification TS 23.228, illustrates in detail the following steps that are taken in a call establishment procedure:

1. UE (A) begins a Session Initiation procedure with UE (B) that includes an SDS proposal.

2. The user in UE (B) is pre-alerted (optional).

3. A pre-alarm indication can be sent to UE (A) (optional).

Four. The user in UE (B) at this time will interact and express their wishes regarding the actual session.

5. UE (B) generates accepted SDPs based on terminal positions, configured terminal profiles and optionally based on user wishes.

6. The accepted SDP is sent to UE (A) in the payload of a reliable SIP response.

7. The initial carrier creative procedure is carried out.

During this bearer creation step, the resources in the UE (A) and UE (B) access network are reserved together with the PDP context procedures. Bearer resources on external networks can also be reserved at this point.

8. The terminal in UE (B) starts ringing (optional).

ES 2 302 799 T3

9. The alert indication is sent to UE (A) (optional).

10. The user in UE (B) can interact and express his wishes regarding the actual session (optional).

eleven. UE (A) and UE (B) can carry out the bearer modification procedure at this point if the initial bearers reserved in step 7 and the wishes of the user in UE (B) are different. During this bearer modification step, the resources in the access network of UE (A) and UE (B) can be modified by means of a modification of the PDP context, and the resource reservation in the external network can also be modified.

12. The login procedure is recognized or supported.

Furthermore, Fig. 7 shows the steps taken in a call establishment procedure and corresponds to Fig. 5.15 of Section 5.6.2 of the second mentioned Technical Specification. The next steps are also described in it.

1. UE # 1 sends the SIP INVITE request, which contains an initial SDP, to the default P-CSCF via a CSCF discovery mechanism. The initial SDP can represent one or more media for a multimedia session.

2. P-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. In this case, it sends INVITE to the S-CNCF on the base network.

3. CSCF validates the service profile, and performs a required source service control for this subscriber. This includes an authorization of the SDP required based on the user's subscription for multimedia services.

Four. S-CSCF sends the request, as specified by the SS procedures.

5. The destination media stream capabilities return along the signal path, in terms of SS procedures.

6. S-CSCF sends the SDP message to P-CSF.

7. P-CSCF authorizes the necessary resources for this session.

8. P-CSCF sends the SDP message to the originating endpoint.

9. UE decides the final group of media streams for this session, and sends Final SDP to the P-CSCF.

10. P-CSCF sends this message to S-CSCF.

eleven. S-CSCF sends this message to the termination endpoint, as for the SS procedure.

12. After determining the final media stream in step # 9, UE initiates reservation procedures for the resources needed for this session.

13. When the resource reservation is complete, UE sends the "Resource Reservation Successful" message to the termination end point, via the signal path established by the INVITE message. The message is sent to P-CSCF first.

14. P-CSCF sends this message to S-CSCF.

fifteen. S-CSCF sends this message to the termination endpoint, as for the SS procedure.

16. The destination UE can optionally carry out an alert. In this case, it gives the appropriate signal to the originating party by means of an indicator tone or bell that represents the provisional answer.

This message is sent to the S-CSCF regarding the SS procedure.

17. S-CSCF sends this message to P-CSCF.

18. P-CSCF sends the ringing message to UE.

19. UE indicates to the source user that the destination is ringing.

twenty. When the destination party answers, the terminating endpoint sends a final SIP 200-OK response, as specified by the termination procedures and SS procedures, to the S-CSCF.

ES 2 302 799 T3

twenty-one. S-CSCF performs any required source service control by logon completion.

22. S-CSCF passes the 200-OK response back to P-CSCF, following the path of the INVITE request from step (2) above.

2. 3. P-CSCF indicates that the resources reserved for this session should be used at this time.

24. P-CSCF passes the 200-OK response back to UE.

25. UE starts the media stream (s) for this session.

26. UE responds to 200-OK with a Receive ACK message that is sent to P-CSCF.

27. P-CSCF sends the final ACK message to S-CSCF.

28. S-CSCF sends the final ACK message to the termination endpoint, as for the SS procedure. However, at other times it is necessary for the MS to receive a recorded announcement from the called party instead of connecting to the called party to conduct a conversation. In such circumstances, the recorded announcement leaves a node in a different direction from that of the called party and the technique according to the present invention facilitates the initiation of the PDP context modification procedure to establish a Traffic Flow Template (TFT ) according to the Transport Directorate (TA) of the node.

Referring to Fig. 8, which illustrates an example of a technique for providing announcements on mobile originated calls in accordance with the present invention, in step # 1 a setup message is sent from an MS to a station of the same type.

This setup message is intercepted by the network that has been instructed to send an announcement message in response to a call setup to the called party. The machine that will make the announcement, referred to in the figure of the drawing as Remote CSCF / REP, in step # 2, receives the establishment message with a connection message that includes its IP address and a Port number, which is, the Remote Equipment TA, in order to allow the MS to connect properly with it.

Subsequently, in steps # 3, # 4, # 5, # 6, and # 7, the MS activates a secondary PDP context that includes a TFT that allows the machine to send traffic to the MS. That is, TFT includes the Remote Equipment TA, that is, its IP address and a Port number).

In step # 8, the MS acknowledges acceptance of the PDP secondary context and in step # 9, the Remote Equipment makes the announcement to the MS.

Therefore, in accordance with the present invention, after an MS attempts to establish a call with a called party who wishes to answer with an announcement, the Remote Equipment machine designed by the called party to make such an announcement, provides its TA to the MS. The MS, in turn, activates a secondary PDP context with a Remote Equipment TFT to allow the Remote Equipment machine to send its advertisement to the MS.

This concludes the description of the exemplary embodiments.

Although the present invention has been described with reference to an illustrative embodiment thereof, it should be understood that numerous modifications and embodiments are conceivable by those skilled in the art as long as they are within the scope of the principles of this invention. . More particularly, reasonable variations and modifications are possible in the component parts and / or arrangements of the arrangement combining the object contained within the scope of the appended claims. In addition to variations and modifications in component parts and / or arrangements, alternative uses will be obvious to those skilled in the art.