KR20060067982A - Method and system for establishing a connection between network elements - Google Patents

Abstract

The invention provides a method and system for establishing or handling a connection between a first and a second network element connected to different networks such as GPRS/UMTS and IP-based networks. The connection is established by means of at least one third network element such as a SGSN or GGSN arranged in one of the networks. The third network element is adapted to send, when receiving information on an establishment of a connection, a request to a fourth network element which may be a Call State Control Function (CSCF), a Policy Control Function (PCF), or a Call Processing Server (CPS). The request requests permission for establishing a requested type of connection, or requests a check of a connection parameter, and specifies the first and/or second network element and/or the connection or connection type to be established. The fourth network element returns a response specifying a permission for establishing a connection or connection type, or specifying a connection parameter.

Description

METHOD AND SYSTEM FOR ESTABLISHING A CONNECTION BETWEEN NETWORK ELEMENTS}

1 illustrates the basic structure and message flow in accordance with one embodiment of a method and system according to the present invention;

2 illustrates another embodiment of a method and system according to the present invention;

3 shows another embodiment of a method and system according to the invention;

4 illustrates another embodiment of a method and system according to the present invention;

5 illustrates another embodiment of a method and system according to the present invention;

6 illustrates a variant of the embodiment shown in FIG. 2; And

7 shows another embodiment of a method and system according to the present invention.

The present invention relates to a method and system for establishing a connection between two or more network elements. The connection may be, for example, a Voice Over Internet Protocol (VoIP) call. The connection may for example involve an IP telephony layer or network and a GPRS / UMTS based network carrying the call.

In general, one or more intermediate network elements, such as support nodes, are involved to properly set up and coordinate connections between network elements such as user devices, for example mobile terminals, and other user terminals or databases. . One or more connection parameters are used to define connection characteristics such as packet data protocol (PDP) context information, request or provided quality of service (QoS), charging related information such as charging tariffs, and the like.

In particular, if the connection involves two or more networks of different types, such as networks using different transport protocols, for example GPRS / UMTS-based networks and IP-based networks, the connection is appropriate. Problem may occur in setting the connection parameters and setting the connection parameters appropriately.

The present invention provides a method and system capable of properly establishing a connection between, for example, network elements configured in different networks, in an advantageous manner as defined in the appended claims.

The connection is a request between third and fourth network elements associated with a connection parameter such as permission or quality of service (QoS), for example for establishing a connection (or connection type such as PDP type) for billing purposes. And by exchanging responses, it can be set up or processed appropriately, enabling accurate adjustment of the connection.

The third network element may be a support node, preferably a gateway support node, and the fourth network element may be CSCF or PCF or CPS. The fourth network element may be part of an IP telephony layer or may provide an IP telephony layer.

According to one of the aspects of the present invention, communication occurs between a PS (Packet Switch) domain (eg, GGSN or SGSN) and between an IM subsystem (CSCF).

According to one of the preferred embodiments of the present invention, a fourth network element, such as an IP telephony layer, is configured to control at least one connection parameter, for example, to limit PDP (Packet Data Protocol) context activation or modification. Is allowed. For example, an interactive PDP context, ie a connection that enables a conversation between a caller and a callee, can only be activated when the first network element, eg the mobile terminal, tries to call the second network element. As an example, when the connection parameter is a PDP context and activation or modification of the PDP context is requested, a third network element, such as GGSN, may be CSCF or PCF or CPS to check whether the activation or modification of the PDP context can be accepted. Allow request may be sent to a fourth network, such as:

This approach offers several advantages. First, a fourth network element, such as CSCF, knows the address of a third network element, eg, GGSN, from the request, and therefore knows where to return the response. Otherwise, if the fourth network element is designed to transmit information to the third network element before being addressed by the third network element, the third network element responsible for coordinating the connection; Problems can arise when you do not have information about the addresses of network elements.

The first network element is subsequently responsible for coordinating the connection, even if the first network element, for example, needs to send information directly to the fourth network element when the mobile terminal attempts to establish a connection such as a call. Since it does not yet have information on the address of the third network element, this address information cannot be transmitted to the fourth network element. In addition, when a message, such as an authorize message, is sent from the fourth network element to the third network element, the third network element is informed about call coordination parameters such as PDP contexts that are not yet activated. Should be saved. The third network element should then activate a timer if the PDP context activation should not be performed for some reason and remove the authentication information after the timer expires.

In addition, the solution presented in accordance with the present invention provides additional advantages by acting to roam subscribers.

In general, according to one aspect, the present invention provides a solution for limiting PDP context activation or modification, for example based on a call to be executed in the PDP context.

According to one of the preferred embodiments of the present invention, for example, in the GPRS / UMTS layer and the IP telephony layer, as well as in networks or layers operating according to different protocols in control means or functions such as CSCF or PCF. Common identifiers are provided. This common identifier can be used to map the PDP context to the call. The common identifier may be, for example, a call identifier such as Call_Id already provided in Session Initiation Protocol (SIP) messages.

Alternatively, the common identifier may also be an identifier located in one of the layers, for example the GPRS / UMTS layer. For example, the common identifier in this case may be NSAPI. In this case, this common identifier is preferably sent to the fourth network element, for example the CSCF, in a protocol message such as an SIP INVITE message. The common identifier (eg NSAPI) may then be transmitted from the third network element (eg GGSN) to the fourth network element (eg PCF) as well as a fifth network element (eg For example, it may be transmitted from the CSCF to the fourth network element. The fourth network element then maps a request (sent by the third network element) and an authentication (sent by the fifth network element, such as CSCF), based on the common identifier, for example NSAPI.

According to another preferred embodiment of the present invention, charging occurs in a first network, such as a mobile core network (e.g., SGSN and GGSN) and in another network, such as an IPT (IP based telephony) core network, e.g., CPS. Mechanisms for combining connection parameters such as information are provided. According to this embodiment, the possibility for charging the QoS (Quality of Service) level used in telephony calls is provided.

According to this aspect of the present invention, a network (e.g., an IPT network in which an IPT QoS reservation is transmitted in an invitation message of SIP, for example) may be combined and combined with call related charging information. A mechanism is provided to control the association between QoS reservations (eg, PDP context QoS context activation) of a mobile packet core network. By way of example, the passed identifier, such as Call_Id, is checked for billing purposes, and the requested QoS level association or request is also checked in both the protocol message (eg SIP: Invite) and the PDP context activation message (s).

New parameters may be introduced in the PDP context activation to inform a third network element, such as GGSN, about a fourth network element, such as a serving CSCF or an integrated CSCF / PCF or CPS. Thus, the third network element is informed of the address of the fourth network element to which a QoS check request is to be sent.

Another optional feature that can be controlled by the end user is the possibility of requesting a QoS check by the terminal (eg, the first network element) in a protocol message such as SIP: Invite.

According to this aspect of the invention, it is possible to prepare a charging record based on the provided QoS.

1 illustrates a first embodiment of a method or system according to the present invention. This embodiment provides for CSCF-allowed PDP context activation or modification. User equipment (UE) 1 is a first network element, which may be a mobile station. The SGSN 2 provides a service providing node (service providing GPRS support node) which provides the user device 1 when coordinating a connection with another network element (second network element), such as a terminal on the called side, which is not shown in FIG. ). The GGSN (Gateway GPRS Support Node) 3 indicates a gateway node that coordinates the connection with another network to which the called party's terminal can be attached. The call state control function (CSCF) 4 indicates a fourth network element that determines whether to allow PDP context activation or modification.

When the user device 1 wants to call another terminal, for example, a terminal configured in an IP based network, the user device 1 sends a message such as an invitation message of a SIP (session initiation protocol) to the CSCF 4. Send it. Then, after receiving a response notifying from the CSCF 4 of the acceptance of the call request, the user device 1 transmits a PDP context activation (or modification) request to the SGSN 2. In response to this PDP context activation (or modification) request, the SGSN 2 sends a PDP context creation (or update) request to the GGSN 3.

In response to the request from SGSN 2, the GGSN 3 does not immediately perform the creation or update of the PDP contexts, but first sends a permission request to CSCF 4. In the embodiment of Fig. 1, the GGSN 3 sends this grant request to the CSCF 4 to check whether PDP context activation / modification can be accepted. In a modified embodiment, the grant request may also be sent to a policy control function (PCF), which may indicate additional optional network elements or integrate with CSCF.

The GGSN 3 includes an IMSI / MSISDN (and possibly PDP address) in the grant request to identify the mobile station that is the user device 10. When the GGSN 3 is present in a traffic flow template (TFT), in the grant request, the GGSN 3 may additionally transmit not only the QoS (Quality of Service) values requested, but also the address (B side address) of the called party. have. If the IMSI / MSISDN (and possibly PDP address) is not sufficient to identify the user device 1 or the call, additional information such as NSAPI can be used and sent to the GGSN 3. In this case, the user device 1 preferably sends the information NSAPI of the PDP context to the CSCF in a call setup message, e.g. SIP: invite message. The CSCF 4 (or alternatively or additionally provided PCF) then checks whether the NSAPI for the call contained in the call establishment message is equal to the NSAPI for the PDP context sent from the GGSN 3 in the grant request. By doing so, the CSCF 4 (or PCF) can authenticate the correct PDP context. If a separate PCF is to be provided, the CSCF 4 sends the NSAPI to the PCF. Likewise, in this case, the GGSN 3 sends a grant request including NSAPI to the respective PCF.

In response to the permission request and after performing the described check, the CSCF 4 (or PCF) sends an permission response to the GGSN 3. The grant response includes an IMSI / MSISDN that identifies the user device 1 or the call for which the PDP context is to be created or updated, and preferably further includes information such as “call characteristics”. The call characteristic information preferably includes indications indicating whether the call is a normal call or an emergency call, as well as accepted QoS values, accepted B side information (preferably called IP address and port number of the called side). .

The GGSN 3 sets QoS values to values received from the CSCF 4 (or PCF). The GGSN 3 may set the allocation / hold priority to the highest value when the call is an emergency call. In addition, the GGSN 3 may set a traffic flow template (TFT) according to the B side information.

If the call is an emergency call and the PDP context is used for this emergency call, this information is sent from the GGSN 3 to the SGSN 2 and the SGSN 2 sends this information to the (mobile) user device. By sending to (1), the user device 1 can then be notified immediately.

For the transmission of the grant request, the GGSN 3 must know the address of the CSCF 4 for communication. In one embodiment of the present invention, the CSCF address is added as a new parameter to the PDP context activation (or modification) request and the PDP context creation (or update) request message. In an alternative embodiment, the GGSN 3 is implemented to obtain the CSCF address from the TFT of the signaling PDP context.

In addition, the GGSN 3 may be informed in any other manner about the CSCF 4 address.

When another network element, such as PCF, is provided to determine permission, the address of this network element (such as PCF) can be configured in the GGSN 3 (per point of access) and the CSCF 4.

In addition, according to another possible aspect of the present invention, if the above described functionality (permission request and grant response) is also provided for roaming subscribers, grant from the CSCF (or PCF) in PDP context activation (or modification) A new parameter describing whether this is requested is added to the subscription information of the subscriber database (such as the home location register (HLR)). This new parameter may be PDP context specific.

Returning now to FIG. 1, after receipt of the grant response, the GGSN 3 sets the PDP context and other information as needed in accordance with the information contained in the grant response, such as an accepted QoS value. The GGSN 3 also returns a PDP context creation (or update) response to the SGSN 2. In response, the SGSN 2 sends a PDP context activation (or modification) response to the user device 1. The call is then set up and executed in a known manner.

2 illustrates another embodiment of the invention (method and / or system) with a policy control function (PCF). The PCF has an interface to CSCF as well as GGSN. The PCF may be used for communication between the IP telephony layer, ie the proxy CSCF and the GPRS / UMTS layer (GGSN). For example, a call can affect a PDP context, and the PDP context is activated for the call.

2 illustrates an embodiment for communication and message flow between the GPRS / UMTS layer, i.e., the GGSN and the IP telephony layer, i.e., the CSCF, through the PCF. The IP telephony layer is allowed to restrict (or modify) PDP context activation.

According to FIG. 2, call-based granting for PDP context activation / modification is performed. The case shown indicates activation of the PDP context in the case of a mobile originating (MO) call from a mobile station (MS) 21, the called side (caller) being the network element 27 (user device, database, etc.). Is indicated by. For the PDP context activation, permission is requested from the PCF 25. Only the parameters required for communication between the proxy CSCF 26 and the PCF 25 and between the GGSN 24 and the PCF 25 are illustrated and described below.

In general, according to the embodiment shown in Figure 2, the GPRS / UMTS layer (i.e., GGSN 24 of the third generation (3G)) and the IP telephony layer example are used to map a PDP context to a call. For example, a common identifier is provided to CSCF 26 and to PCF 25. The subscriber identifier, for example IMSI, is not sufficient when the MS 21 has multiple calls in progress. In this case, the common identifier used according to FIG. 2 is a call identifier (Call_Id) already present in the SIP message. The initiator of the call in this embodiment, the mobile station 21 assigns the Call_Id in a manner known from the SIP protocol, for example, where the identifier Call_Id specifically identifies the call.

According to a preferred embodiment as shown in FIG. 2, this common identifier, such as Call_Id, is transmitted from the MS 21 to the SGSN 23 and from the SGSN 23 to the GGSN 24. This common identifier is also preferably sent from the mobile station 21 to the proxy CSCF 26 in a call initiation message such as SIP: Invite. This common identifier is also sent from the CSCF 26 to the PCF 25 and also from the GGSN 24 to the PCF 25. The PCF 25 then maps the authentication sent by the CSCF 26 based on the request sent by the GGSN 24 and the common identifier (eg, Call_Id), and the QoS to be used. Determine the same call permission and / or connection parameters.

In the modified embodiment, an identifier assigned to the GPRS / UMTS layer, for example the GGSN 24, is used as the common identifier. As an example, NSAPI is used as this common identifier. In this case, according to one embodiment of the present invention, the NSAPI is transmitted from the MS 21 to the CSCF 26 in an invitation message or another call setup message. NSAPI is also sent from the GGSN 24 to the PCF 25 and from the CSCF 26 to the PCF 25. In this case, the PCF 25 maps the authentication sent by the CSCF 26 based on the request sent by the GGSN 24 and the NSAPI.

The operator may, for example, configure the access point specific information with the GGSN to indicate whether communication with the PCF is requested and what kind of PDP context is only when the QoS class indicates interactive, ie voice transmission. . In addition, the PCF 25 address may be configured in the GGSN 24 and the CSCF 26 such that the GGSN 24 and the CSCF 26 may communicate with the same PCF 25.

In an alternative embodiment, when the PCF address is not configured per network element, such as elements 24 and 26, a new parameter, e.g., the PCF address may be a subscriber database such as HLR and / or a UMS (user mobility). Server) may be included in the subscription information. The SGSN 23 receives the PCF 25 address from the subscriber database, for example HLR, and sends this address to the GGSN 24. Upon receiving the PCF 25 address, the GGSN 24 knows where the PCF 25 will contact. The CSCF may contact the same PCF 25 by receiving the same PCF 25 address from the UMS.

Whether communication with the PCF 25 is requested may be home operator specific. For roaming of subscribers, a new parameter is added to the subscriber database (HLR) and the subscription information of the UMS that describe whether communication with the PCF 25 is requested, for example the information "requested PCF interaction". . The "requested PCF interaction" of the HLR may be subscription specific or PDP context specific. The SGSN 23 receives the information “requested PCF interaction” from the HLR and sends this information to the GGSN 24. Upon receiving the information "requested PCF interaction ", the GGSN 24 knows whether communication with the PCF is necessary when establishing a connection or modifying a connection or otherwise. The CSCF 26 receives the information " requested PCF interaction " from the UMS, from which it knows whether communication with the PCF 25 is requested.

Thus, according to this aspect of the invention, the following three new ideas are integrated alternatively or in combination:

(a) provide a common identifier to map the PDP context to the call;

(b) provide new parameters for HLR and UMS, namely PCF address; And / or

(c) provide new HLR and UMS parameters such as “requested PCF interaction”.

According to the embodiment of FIG. 2, PS (Packet Exchange) domain interaction with a policy control function (PCF) 25 is shown and described. With reference to the step numbers shown in Fig. 2, the steps performed when establishing a connection will be described in more detail below.

In step 1, the mobile station 21 sends an invitation message to the proxy CSCF 26, which includes the subscriber identification number "subscriber Id" and the call identifier "Call_Id". The proxy CSCF 26 sends this message to the callee 27.

In step 2, the proxy CSCF 26 receives a positive acknowledgment, eg 183w / SDP, defined in SIP from the called terminal 27. The proxy CSCF 26 sends this acknowledgment to the mobile station (caller) 21.

In step (3), after receiving the positive acknowledgment from the called terminal 27, the proxy CSCF 26 sends to the PCF 25 (subscriber Id, call identifier Call_Id, negotiated QoS, Send an authentication message (including the called party's transport address). The subscriber Id may be, for example, IMSI, MSISDN or IP address of the caller 21 (ie PDP address in the GPRS / UMTS layer). The Call_Id is requested and used to map the call to the correct PDP context of the PCF 25. The negotiated QoS includes the negotiated QoS parameters for the call. In case of an emergency call, the proxy CSCF 26 will set the QoS parameter assignment / hold priority to the highest value. The callee shipping address is used in the GPRS / UMTS layer to establish a TFT (Traffic Flow Template) for the PDP context.

In step 4, the PCF 25 informs the proxy CSCF 26 that it has received the authentication message of step 3 by returning an authentication acknowledgment (subscriber Id, Call_Id) message.

In step (5), the MS 21 sends a (secondary) PDP context activation request (PDP address, Call_Id, requested QoS) message to the SGSN 23 (e.g., for a PDP context (e.g., Request to activate the secondary PDP context.

In step 6, a radio access bearer setup process is performed.

In step 7, the SGSN 23 sends a generated PDP context request (subscriber Id, Call_Id, negotiated QoS) message to the GGSN 24.

In step 8, the GGSN 24 requests permission to activate the PDP context by sending a grant request (Request Id, Subscriber Id, Call_Id, Negotiated QoS) message to the PCF 25. The first request message (step 8) generates a request status in the PCF 25.

In step 9, the PCF 25 responds by sending a decision (Request Id, Negotiated QoS, Called Carrier Address) message to the GGSN 24. The GGSN 24 sets the TFT for the PDP context according to the called party's transport address.

In step 10, the GGSN 24 may report to the PCF 25 that it has acted according to the determination by sending a status report message (Request Id).

In steps 11 and 12, the PDP context activation is reported in a known manner.

In Figure 2, the messages 8 (Request), 9 (Decision) and 10 (Status Report) are COPS messages.

2 illustrates the case of PDP context activation. Steps 8 to 10 and the other steps shown in FIG. 2 are the same when the PDP context is to be modified.

Whether permission from the PCF 25 to allow PDP context activation is requested may be operator specific. In addition, to provide this functionality for roaming subscribers, the subscription information of the HLR includes new parameters such as "requested PCF interaction". The SGSN will receive the "requested PCF interaction" from the HLR and send this "requested PCF interaction" to the GGSN 24 in PDP context activation / modification. Upon receiving the "requested PCF interaction", the GGSN 24 knows whether communication with the PCF 25 is requested when generating or modifying a PDP context.

The GGSNs 3, 24, 33 (FIGS. 3-5) are from the proxy CSCF domain name (preferred option); And from the new parameter "CSCF address" sent by the MS in the (secondary) PDP context activation message; And by determining the proxy CSCF address from the TFT of the signaling PDP context, the address of the CSCF 4, 26 (or CPS 34 of Figs. 3 to 5) can be known.

Parameters to be transmitted by the GGSN to find an appropriate call or connection in the PCF (CPS; PCF is a logical element; it may be a sole element or may be located in the CSCF or the GGSN) are:

MS IP address (= PDP address) and MS port number (= TFT destination port number) (preferred optional);

It may be a peer IP address (= TFT source address) and a peer port number (= TFT source port number).

3 through 5 illustrate other embodiments of the present invention that provide a method and mechanism for combining charging information generated by a mobile core network and an IPT core network. The mobile core network is represented by SGSN 32 and GGSN 33. Other necessary components for providing a mobile network are known to those skilled in the art and are not shown in the drawings. The IPT core network is represented by a call processing server (CPS) 34. Other components of the IPT network are known to those skilled in the art and are not shown in the figures.

The embodiments shown in the figures provide the possibility for charging the QoS level used for other types of telephony calls or connections. As an example, telephony calls require real-time (RT) traffic and usually require a higher QoS level than other types of communication, such as email transmissions (which are charged at lower rates by being sent using lower QoS levels). .

The embodiments shown in Figures 3 to 5 combine call-related charging information and, for example, IPT QoS reservation and mobile packet core network PDP context QoS (PDP context activation) (required by the calling originating terminal in a SIP: invite message). Provide a mechanism to control the association or correspondence between

3 to 5 show a mobile terminal (MT) 31, SGSN 32, GGSN 33 (SGSN 32 and GGSN 33 attached to a mobile network) of the mobile network to which the MT 31 is attached. Part of the message) and the call processing server (CPS) 34. The CPS 34 includes a call state control function (CSCF) as shown in FIGS. 1 and 2, whereby the name of the block 34 can also be "CSCF".

In the following, the embodiment shown in FIG. 3 will be described in more detail.

When the mobile terminal 31 wishes to establish a connection with another network element, such as a telecommunication device on the side from which the mobile terminal 31 is to be called, the mobile terminal 31 initiates a session, such as SIP, as indicated by step (1). Issue the actual setup request, such as the "invitation" message of the protocol. The invitation message is sent from the MT 31 to the CPS 34 and includes information elements ("Call_Id" and "SDP: QoS"). SDP stands for Serving Profile Database. “Call_Id” combines or otherwise CDRs with billing data, eg, CDRs (billing data records) generated by support nodes such as GSNs (GPRS support nodes) and CSCF (or CPS). Indicates a common identifier provided for benefiting from the link with them. This common identifier, for example "Call_Id", is distributed to the support nodes and the CSCF (or CPS) in the connection establishment phase (eg, call establishment phase). This technique can specifically identify the connection or call to be established to all the accompanying processing elements, such as GGSN and CPS, without requesting a direct interface between these components. This method and architecture provides a mechanism for combining charging data and / or checking QoS legitimacy, for example, in different network types providing all IP connections between end terminals, e.g., IP telephony. .

In the next step (2), the mobile terminal 31 sends a PDP context activation request to the SGSN 32, which further includes the parameter "Call_ID" as well as the usual information such as bearer type and codec. do. This parameter "Call_ID" and other necessary announcement information elements are immediately sent from the SGSN 32 to the GGSN 33 so that the GGSN 33 is informed about the common identifier "Call_ID" belonging to the connection to be established. In the next step (3), the GGSN 33 sends a check request to the CPS 34, which indicates the common identifier "Call_ID" and other information such as bearer type and codec.

In the next step (4), the CPS 34 (or CSCF included in the CPS 34) performs a check on the connection to be established identified by the common identifier "Call_ID", and the requested QoS parameters are called. Check for justification in both signaling (SIP / SDP) and bearer (PDP contexts). The CSCF (CPS 34) of the requested QoS parameters prior to accepting (or initiating) call setup to charge for QoS provided for other types of calls or connections, or for purposes other than charging. Perform this check to control the justification. The CPS 34 issues a good (OK) or a bad (NOT OK) as a result of this check (Call_ID, SDP: QoS, bearer type, codec), and checks the test result (good / bad) with the GGSN 33. (Step 5). The GGSN 33 accepts the information received in step 5 of accepting the call-related PDP context activation ("OK" if the test result is positive) or rejecting ("N OK" if the test result is negative). Return the response to the SGSN 32 to inform SGSN 32 of the acceptance or rejection of the PDP context activation (or modification). The SGSN 32 performs known steps upon receipt of an accept or reject response and transmits information corresponding to the mobile terminal 31.

The CPS 34 (or CSCF) may also send a response directly to the mobile terminal 31 to return a response to the call setup request of step (1) (step 6). As an example, in step 6 the response of the SIP "OK / NOK" may be sent.

Thus, an additional message sequence is provided between the CSCF (or CPS) and the GGSN 33 to determine how to initiate the connection to be established.

The CPS (CSCF) 34 also receives additional parameters in addition to "Call_ID" and makes decisions based on these additional parameters.

The mechanism shown in FIG. 3 described above may be related to other types of checks or evaluations, but not limited to QoS and charging aspects. Also, the decision made by the CPS (CSCF) 34 may be advisory and need not just be a binary "OK / NOT OK" type.

As shown in Figs. 3 to 5, as step 3, the GGSN 33 sends a check request to the CPS (CSCF) 34. Thus, the GGSN 33 needs information about the address or name of the CPS (CSCF). If the GGSN 33 does not know about the service providing CSCF (CPS 34) that the mobile terminal 31 registered by the SIP registration mechanism and sent the invitation message, the GGSN 33 is the service providing CSCF The address or name of the (CPS) 34 should be informed. The embodiment of Figure 4 presents a solution to this problem.

In addition to the structure and functionality of the embodiment of FIG. 3 discussed above, the embodiment of FIG. 4 may request a PDP context activation to notify GGSN 33 about the address or name of the service providing CSCF (or CPS) 34. By providing a new parameter, e.g., "S-CSCF_logical name", GGSN 33 knows where to send the "QoS check" request.

The embodiment of FIG. 4 is based on the structure shown in FIG. 3 described above. The above description also applies to the message sequences shown in FIG. 4 and the steps performed.

The mobile terminal 31 is informed about the CPS (or CSCF) 34 to which it is registered, and in step 2 the S-CSCF in a message sent to SGSN 32 and also to GGSN 33. (Information on the address or name of the service providing CSCF of the CPS 34). This new parameter representing the address or name of the serving CSCF is indicated in FIG. 4 by the parameter " S-CSCF_Logical Name " sent in the PDP context activation request. By this additional information " S-CSCF_Logical Name ", the GGSN 33 is now informed about the address or name of the correct CSCF (CPS) and requests a check to the CPS (CSCF) 34 indicated by this parameter. (Step (3)). The other steps shown in FIG. 4 are the same as in FIG. 3 described above.

5 also provides additional optional features that can be controlled by the end user of the mobile terminal 31 that allows the end user or call originating device to request, for example, a "QoS check" in the SIP: Invite message. do.

The embodiment according to FIG. 5 includes all the features of the embodiments of FIGS. 3 and 4 described above. In addition, according to FIG. 5, a new parameter, for example, "Require_ggsn_check" is included in the connection establishment request transmitted from the mobile terminal 31 to the CPS (CSCF) 34 in step (1).

The structure and method shown in FIG. 5 is an addition to the coupling mechanisms for charging data and QoS control as described and provided for FIGS. 3 and 4. The embodiment according to FIG. 5 allows the selection of a choice as to whether or not to perform the inspection steps 3 to 5 above. When the parameter "Require_ggsn_check" is set in the SIP invitation message (or other appropriate type of connection establishment request message) sent from the mobile terminal 31 to the CPS 34, the CPS (or CSCF included in the CPS) is Prepare to perform the inspection according to step (4), and wait for the inspection request message from GGSN 33 according to step (3). After receiving the inspection request in step 3, the CPS 34 performs the inspection of step 4 as described above and then continues as described above for the step sequence. When the parameter "Require_ggsn_check" is not set or does not exist in the connection establishment request of step (1), the CPS (CSCF) 34 does not perform a QoS check according to step (4) and does not perform any random check from the GGSN 33. Do not request a check message. By this information provided by the new parameter " Require_ggsn_check ", the CSCF is informed whether a check procedure is required to initiate call establishment. Of course the new check request parameter can have any arbitrary destination, such as "Require_pdpqos_check" if it is understood by the CSCF.

This new parameter provided according to FIG. 5 and the choice of whether or not to perform a QoS check or some other type of check is a logical name or address of the CPS 34 according to step 2 of FIG. 4. It is also applicable to a structure as shown in FIG. 3 which does not provide an indication of. In particular, it is applicable when the GGSN 33 is informed about the address of the CPS 34 with which the MT 31 is registered, for example by sending a message from the CPS 34 to the GGSN 33 by other means. Do.

The methods and mechanisms provided in accordance with embodiments of the present invention allow the GGSN (3, 33) to allow proper execution of inspection results processing and billing information generation as well as requests and inspections to provide charging records for established connections. And / or as software in CSCF / CPS 34.

The provided method and mechanism for checking QoS parameters may also be implemented separately from charging information generation.

 The illustrated embodiments also provide the possibility of controlling and suppressing, for example, PDP context updates for PDP contexts assigned to a voice call until a check from CPS 34 is performed. This can be handled by providing another message exchange between the GGSN 33 and the CPS 34.

FIG. 6 shows another embodiment of the invention (method and / or system) which is a variation of the embodiment shown in FIG. 2. According to FIG. 6, the PCF 25 (FIG. 2) is integrated with the proxy CSCF 26 (FIG. 2) to form a single network element 25 ′. This structure provides a gain that prevents any external signaling between the PCF and the CSCF, so that steps 3 and 4 of FIG. 2 can be omitted. The authentication check according to these steps 3, 4 of FIG. 2 is performed using internal processing within the network element 25 ′ of FIG. 6. The signaling between PCF and CSCF in this case is only internal signaling (ie it is not strictly limited by any standard).

The other steps 1, 2 and 5 to 12 of FIG. 6 are the same as those described above with respect to FIG. 2.

Thus, the PCF may be a separate logical entity 25 as shown in FIG. 2, may be integrated in the CSCF as shown in FIG. 6, or may also be integrated in the GGSN 24 as well.

7 illustrates another embodiment of a system and method in accordance with the present invention for providing call based PDP context activation / modification. 7 presents PDP context activation in the case of a MO call. It is believed that at least one PDP context is activated for the call. For the PDP context activation, permission is requested from the PCF. The permission from the PCF is requested to adjust the QoS of the PDP context to match the QoS of the call. Whether a decision is requested from the PCF and what kind of PDP contexts may be configured in the GGSN. By way of example, the configuration information may define whether a decision from the PCF is requested only for interactive PDP contexts, and for other PDP contexts, the PDP context activation will be initiated without PCF interaction. Only the parameters required for GGSN-PCF communication are shown and described below. In the following, the steps shown in FIG. 7 will be described in detail.

In step (1), the MS sends an invite (subscriber Id) message to the proxy CSCF. The proxy CSCF sends the message to the callee.

In step (2), the proxy CSCF receives a positive acknowledgment, for example 183 w / SDP. The proxy CSCF sends the acknowledgment to the caller.

In step (3), the MS activates the PDP context for the call by sending a secondary PDP context activation request (Requested QoS) message to the SGSN.

In step 4, a radio access bearer setup process is performed.

In step 5, the SGSN sends a PDP context creation request (PDP address, negotiated QoS) message to the GGSN.

In step 6, the GGSN requests permission to activate the PDP context by sending a request (Request Id, Subscriber Id, Negotiated QoS) message to the PCF. The subscriber Id is an identifier known in both the PS domain and the IM subsystem, for example the IP address of the MS.

In step 7, the PCF responds by sending a decision (Request Id, Negotiated QoS) message to the GGSN.

In steps 8-9, the PDP context activation is accepted by the parameters received from the PCF.

In step 10, the GGSN may report that it has successfully completed the determination by sending a status report (Request Id) message to the PCF.

The steps 6, 7 and 10 are the same as when the PDP context is modified.

Although the preferred embodiments have been shown and described above, the invention is not intended to be limited to the above description and the detailed description shown, but is intended to include all modifications, omissions and additions of the features described above and illustrated in the drawings.

By way of example, the present invention is not limited to communication between the GGSNs 3 and 24 and the PCF-CSCF (or CSCF / PCF). The same communication is possible by replacing the GGSNs 3 and 24 with the SGSNs 2 and 23, whereby SGSN-PCF-CSCF (or CSCF / PCF) communication is performed.

The present invention provides a method and system capable of properly establishing a connection between, for example, network elements configured in different networks, in an advantageous manner as defined in the appended claims.

Claims (19)

12. A method for establishing a connection in a two-layer communication network comprising a first communication network layer for establishing a communication channel with a terminal and a second communication network layer for establishing a session conducted in the communication channel, the method comprising: Establishing a session by the identifier; Establishing a communication channel by the identifier; Authenticating the communication channel by the session using the identifier. The method of claim 1 wherein the authentication step is: Initiating a request for authentication in a communication channel establishment by a network element (eg, GGSN) of the first communication network layer; And performing the authentication by a network element (eg, CSCF) of the second communication network layer. 3. The method of claim 1 or 2, wherein the first communication network layer is a GPRS / UMTS layer and the second communication network layer is an IP multimedia subsystem. The method of claim 1, wherein the terminal is a user device or a mobile station. A system for establishing a connection in a two-layer communication network comprising a first communication network layer for establishing a communication channel with a terminal and a second communication network layer for establishing a session conducted in the communication channel, Establish a session by the identifier; Establish a communication channel by the identifier; And authenticate the communication channel by the session using the identifier. The method of claim 5, wherein to perform the authentication: The network element of the first communication network layer initiates a request for authentication in a communication channel establishment, The network element of the second communication network layer performs the authentication. 7. The system of claim 5 or 6, wherein the first communication network layer is a GPRS / UMTS layer and the second communication network layer is an IP multimedia subsystem. 6. The system of claim 5, wherein the terminal is a user device or a mobile station. A support node used to establish or modify a connection to a first network element assigned to a user. The connection is established or modified for the call between the first network element and the second network element, and the connection is established by the support node, where the support node is responsible for a request to activate or modify the connection. Upon receiving the information, send a permission request to another network element, the permission request requesting permission to establish a connection of the requested type, the permission request being (i) the first network element and (ii) Specify at least one of the second network element and (iii) a connection or connection type to be established, and wherein the support node receives a response from the other network element specifying a permission to establish a connection or connection type. Featured support node. A support node used to establish or modify a connection to a first network element assigned to a user. The connection is established or modified for the call between the first network element and the second network element, and the connection is established by the support node, where the support node is responsible for a request to activate or modify the connection. Send a test request to another network element when receiving the information, the test request requests a test of a connection parameter, the test request specifies at least one of a connection and a connection type to be established, and the support node is connected or Receiving from said other network element a response specifying a test result for use in establishing a connection type. 11. The support node of claim 9 or 10, wherein the support node controls the establishment or modification of the connection in dependence on the response. The support node according to claim 9 or 10, wherein the support node is a gateway network element. The support node according to claim 9 or 10, wherein the support node is a gateway GPRS support node. A network entity used to establish or modify a connection to a first network element assigned to a user. The connection is established or modified for the call between the first network element and the second network element, wherein the connection is established by a third network element configured in one network, where the network entity receives the permission request and The permission request requests permission to establish a connection of the requested type, the permission request being (i) the first network element, (ii) the second network element, and (iii) the connection to be established. Or specify at least one of a connection type, the network entity returning a response specifying a permission to establish a connection or connection type. A network entity used to establish or modify a connection to a first network element assigned to a user. The connection is established or modified for the call between the first network element and the second network element, where the network entity receives a test request from another network element, the test request requests a test of a connection parameter and The inspection request specifies at least one of a connection and a connection type to be established, the network entity performs an inspection of the connection parameters, and the network entity specifies a test result for use in establishing a connection or connection type. And return the reply to the other network element. 16. The network entity of claim 14 or 15, wherein the network entity is one of a call state control function, a policy control function (PCF), and a call processing server (CPS). 15. The network entity of claim 14, wherein the permission request is a request for permission to activate or modify a PDP context for the first network element. 15. The network entity of claim 14, wherein the grant request comprises at least one of an IMSI / MSISDN, a PDP address, a requested QoS, and an address of the second network element. 15. The call characteristic of claim 14, wherein the response comprises a call characteristic comprising at least one of accepted QoS values, accepted information about the second network element, and an indication of whether the connection is a normal call or an emergency call. Representing a network entity.

Images