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

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method and system for establishing or handling a connection between first and second network elements connected to different networks like GPRS/UTMS and IP based networks. <P>SOLUTION: A connection between two or more network elements is established by at least one third network element like SGSN or GGSN disposed in one network. When information regarding the establishment of connection is received, that third network element transmits a request to a fourth network element that is a call state control function (CSCF), policy control function (PCF) or call processing server (CPS). This request requires a permission for establishing the connection of a requested form or the fourth network element redirects a response designating the permission for establishing the connection. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a method and system for establishing a connection between two or more network elements. The connection is, for example, a VoIP (Voice over Internet Protocol) call. Connections also include, for example, IP telephone layers or networks that carry calls and GPRS / UMTS based networks.

  In general, one or more intermediate network elements, such as support nodes, are required to establish and handle appropriate connections between network elements such as user equipment, eg, a mobile terminal, another user terminal, and a database. included. One or more connection parameters are used to define connection characteristics such as PDP (packet data protocol) context information, requested or provided quality of service (QoS), and billing related information such as billing rates.

  In particular, if the connection includes two or more networks of different types, for example networks using different transmission protocols, for example GPRS / UMTS-based networks and IP-based networks, the connection is properly established and the connection parameters There is a problem setting

  The present invention provides a method and system that can establish a connection in an effective manner, for example, between network elements located in different networks, as defined in the claims.

  In order to ensure the correct handling of the connection, requests and responses related to connection parameters, such as authorization to establish a connection (or connection type such as PDP type), or QoS (Quality of Service) are provided. Can be properly established or processed for billing purposes, for example, by exchanging between and the fourth network element.

The third network element is a support node, preferably a gateway support node, while the fourth network element is a CSCF, PCF or CPS. The fourth network element may be part of or comprise an IP telephone layer.
According to one aspect of the invention, communication occurs between PS (packet switched) domains (eg, GGSN or SGSN) and between IM subsystems (CSCF).

  According to one preferred embodiment of the invention, a fourth network element, such as an IP telephone layer, is allowed to control at least one connection parameter, e.g. PDP (packet data protocol) context activation or modification. It is allowed to restrict. For example, a conversation PDP context, ie, a connection that allows a conversation between a calling party and a called party, attempts to cause a first network element, eg, a mobile terminal, to place a call to the second network element. It can only be activated. For 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 sends an authorization request to a fourth network such as CSCF, PCF or CPS. Check if the PDP context activation or change is acceptable.

  This solution provides a number of effects. First, a fourth network element, such as a CSCF, learns from its request the address of a third network element, such as a GGSN, and therefore knows where to send the response back. Otherwise, when the fourth network element is configured to send information to the third network element before being addressed by the third network element, the fourth network element is responsible for handling the connection. Problems arise when there is no information about the address of the third network element.

  Even when a first network element, for example a mobile terminal, attempts to establish a call-like connection, information should be sent directly to the fourth network element, the first network element subsequently connects In charge of handling, the address information of the third network element is not yet available, and therefore this address information cannot be transmitted to the fourth network element. Furthermore, if a message such as an authorization message is first sent from the fourth network element to the third network element, the third network element stores information regarding call handling parameters such as a PDP context that is not yet active. Must. The third network element must then activate the timer and remove the authorization information after the timer expires if for some reason the PDP context activation should not be performed.

Furthermore, the solution proposed by the present invention also works for roaming subscribers, thus providing an additional effect.
In general, according to one aspect, the present invention provides a solution to limit, for example, PDP context activation or modification based on calls carried via that PDP context.
According to one preferred embodiment of the invention, a common identifier for networks or layers functioning under different protocols, eg GPRS / UMTS and IP telephony layers, and control means or functions such as CSCF and PCF. Is given. This common identifier is used to map the PDP context to the call. This common identifier is, for example, a call identifier such as Call_Id already provided in a SIP (Session Initiation Protocol) message.

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

  According to yet another preferred embodiment of the present invention, a first network such as a mobile core network (e.g. SGSN and GGSN) and an IPT (IP-based telephone) core network e.g. another network such as CPS. A mechanism is provided for combining connection parameters, such as generated billing information. This embodiment gives the possibility to charge the quality of service (QoS) level used for telephone calls.

  According to this aspect of the invention, combining the call-related charging information and QoS reservation in one network (eg, an IPT network where the IPT QoS reservation is sent in, eg, a SIP INVITE message) and A mechanism is provided to control the relevance between QoS reservations (eg, PDP context QoS context activation) in other networks (eg, mobile packet core networks). For example, a supplied identifier such as Call_Id is checked for billing purposes, and the requested QoS level relevance or request is also checked in both protocol messages (eg, SIP: INVITE) and PDP context activation messages. .

New parameters are introduced in the PDP context activation to inform a third network element such as GGSN about a serving CSCF, or an integrated CSCF / PCF, or a fourth network element such as CPS. Therefore, the third network element is notified of the address of the fourth network element to which the QoS check request should be transmitted.
Yet another optional feature that can be controlled by the end user is that a QoS check can be requested by a terminal (eg, the first network element) in a protocol message such as SIP: INVITE.
This feature of the invention makes it possible to create a billing record based on a given QoS.

  FIG. 1 shows a first embodiment of a method or system according to the invention. This embodiment provides CSDP authorized PDP context activation or modification. User equipment (UE) 1 is a first network element which is a mobile station. The SGSN 2 provides a serving node (serving GPRS support node) that serves the user equipment 1 when handling a connection to another network element (second network element) such as a called party's terminal not shown in FIG. Represent. GGSN (Gateway GPRS Support Node) 3 represents a gateway node for handling connections to another network to which the called party's terminal is attached. The call state control function (CSCF) 4 represents a fourth network element that determines permission for PDP context activation or modification.

  For example, when the user apparatus 1 attempts to place a call to a terminal located in another network such as an IP base network, the user apparatus 1 transmits a message such as a SIP (Session Initiation Protocol) INVITE message to the CSCF 4. Thereafter, preferably after receiving a response from the CSCF 4 notifying the acceptance of the call request, the user equipment 1 sends a PDP context activate (or change) request to the SGSN 2. The SGSN 2 sends a PDP context creation (or update) request to the GGSN 3 in response to the PDP context activate (or change) request.

  In response to this request from SGSN2, GGSN3 does not immediately create or update the PDP context, but first sends an authorization request to CSCF4. In the embodiment of FIG. 1, GGSN 3 sends this authorization request to CSCF 4 to check if it can accept the PDP context activation / change. In a variant, the authorization request is also sent to the policy control function PCF, which may represent additional optional network elements or may be integrated into the CSCF.

  The GGSN 3 includes the IMSI / MSISDN (and possibly the PDP address) in the authorization request to identify the mobile station or user equipment 1. Furthermore, the GGSN 3 can send the requested QoS (Quality of Service) value and the called party's address (B party address) in an authorization request if it is present in the traffic flow template TFT. If the IMSI / MSISDN (and possibly PDP address) is not sufficient to identify user equipment 1 or the call, additional information such as NSAPI can be used and sent to GGSN3. In this case, it is preferable that the user apparatus 1 transmits the information NSAPI of the PDP context to the CSCF in a call setting message, for example, a SIP: INVITE message. CSCF 4 (or a PCF provided separately or additionally) then checks that the NSAPI for the call included in the call setup message is equal to the NSAPI for the PDP context sent from GGSN 3 in the authorization request, Therefore, CSCF 4 (or PCF) can authorize the correct PDP context. When an individual PCF is provided, the CSCF 4 transmits NSAPI to the PCF. Similarly, in this case, the GGSN 3 transmits a permission request including NSAPI to the individual PCF.

  After executing the above check in response to the permission request, the CSCF 4 (or PCF) transmits a permission response to the GGSN 3. This authorization response includes the IMSI / MSISDN for identifying the call or user equipment 1 where the PDP context is to be created or updated, and preferably further includes information such as “call characteristics”. This call characteristics information includes accepted QoS values, accepted B party information (preferably the called party's IP address and port number), and an indication of whether the call is a normal call or an emergency call. Is preferred.

GGSN3 sets the QoS value to the value received from CSCF4 (or PCF). The GGSN 3 can set the allocation / retention priority to the maximum value when the call is an emergency call. Furthermore, the GGSN 3 can set the traffic flow template TFT based on the B party information.
If the call is an emergency call and the PDP context is used for this emergency call, send this information from GGSN3 to SGSN2, and SGSN2 forwards this information to the (mobile) user equipment 1 This is notified to the user device 1.

In order to send an authorization request, GGSN 3 must know the address of CSCF 4 for communication. In one embodiment of the present invention, the CSCF address is added as a new parameter to the PDP context activate (or change) request and PDP context creation (or update) request messages. In another embodiment, GGSN3 is implemented to derive the CSCF address from the TFT of the signaling PDP context.
Furthermore, the address of CSCF 4 may be notified to GGSN 3 by some other method.
When another network element such as PCF is provided to determine authorization, the address of this network element (such as PCF) may be configured for GGSN3 (per access point) and CSCF4.

  Furthermore, according to another feature of the present invention, permission from the CSCF (or PCF) is granted PDP context activation (or if the above-mentioned functions (authorization request and authorization response) are also provided to roaming subscribers. A new parameter is added to the subscriber information in the subscriber database (such as the home location register HLR) indicating whether it is necessary for the change. This new parameter is specific to the PDP context.

  Returning to FIG. 1, after receiving the authorization response, the GGSN 3 sets the PDP context and further information as needed based on the information contained in the authorization response, eg, the accepted QoS value, etc. . Furthermore, GGSN3 returns a PDP context creation (or update) response to SGSN2. In response, the SGSN 2 sends a PDP context activate (or change) response to the user equipment 1. In doing so, a call is established and executed in a known manner.

FIG. 2 illustrates another embodiment (method and / or system) of the present invention in which a policy control function (PCF) is provided. The PCF has interfaces to the GGSN and CSCF. The PCF can be used for communication between the IP phone layer, ie the proxy CSCF, and the GPRS / UMTS layer (GGSN). For example, a call can affect a PDP context that is activated for the call.
FIG. 2 shows an example of communication and message flow that occurs via the PCF between the GPRS / UMTS layer, or GGSN, and the IP telephone layer, or CSCF. The IP phone layer is allowed to restrict PDP context activation (or modification).

  In FIG. 2, call-based authorization for PDP context activation / modification is performed. In the case shown here, a PDP context activation is given in the case of a mobile outgoing (MO) call, ie a call originating from the mobile station (MS) 21, and the called party (recipient) is assigned to the network element 27 (user equipment , Database, etc.). For PDP context activation, permission from the PCF 25 is required. Only parameters required for communication between the proxy CSCF 26 and the PCF 25 and communication between the GGSN 24 and the PCF 25 are shown and described below.

  In general, according to the embodiment shown in FIG. 2, the GPRS / UMTS layer (ie, the third generation (3G) GGSN 24), the IP phone layer, eg, the CSCF 26, and the PCF 25, are used to map the PDP context to a call. A common identifier is given. When the MS 21 has a large number of calls going on simultaneously, the subscriber identifier, eg IMSI, is not sufficient. In such a case, the common identifier used in FIG. 2 is the call identifier Call_Id already present in the SIP message. The call originator, in the example shown here, the mobile station 21 assigns Call_Id in a known manner, for example from the SIP protocol, and this identifier Call_Id uniquely identifies the call.

  In a preferred embodiment such as that shown in FIG. 2, a 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. Furthermore, this common identifier is preferably sent from the mobile station 21 to the proxy CSCF 26 in a call initiation message such as SIP: INVITE. Furthermore, this common identifier is transmitted from the CSCF 26 to the PCF 25 and further transmitted from the GGSN 24 to the PCF 25. The PCF 25 then maps the request sent by the GGSN 24 and the authorization sent by the CSCF 26 based on a common identifier (eg, Call_Id) and calls authorization and / or connection parameters, eg, QoS to be used. Judging.

  In a variant, the identifier assigned to the GPRS / UMTS layer, eg GGSN 24, is used as a common identifier. For example, NSAPI is used as such a common identifier. In this case, according to one embodiment of the invention, the NSAPI is sent from the MS 21 to the CSCF 26 in an INVITE message or other call setup message. Furthermore, NSAPI is transmitted from GGSN 24 to PCF 25 and from CSCF 26 to PCF 25. In this case, the PCF 25 maps the request transmitted by the GGSN 24 and the authorization transmitted by the CSCF 26 based on NSAPI.

  The operator configures the access point specific information to the GGSN to indicate whether communication with the PCF is required and what kind of PDP context, for example only when the QoS class indicates conversation or voice transmission. Can be directed. Also, the PCF 25 address is configured for the GGSN 24 and CSCF 26 so that the GGSN 24 and CSCF 26 can communicate with the same PCF 25.

  In another embodiment, when a PCF address is not configured for each network element, such as elements 24 and 26, new parameters such as, for example, a PCF address, such as HLR and / or UMS (User Mobile Server) It can be included in the subscriber information in the subscriber database. SGSN 23 receives the PCF 25 address from a subscriber database, eg, HLR, and sends it to GGSN 24. When receiving the PCF 25 address, the GGSN 24 knows which PCF 25 to contact. The CSCF can receive the same PCF 25 address from UMS and contact the same PCF 25.

  Whether or not communication with the PCF 25 is necessary is specific to the home operator. For roaming subscribers, a new parameter is added to the contract information in the subscriber databases HLR and UMS, for example, the information “required PCF interaction” indicating whether communication with the PCF 25 is required. . The “required PCF interaction” in the HLR may be contract specific or PDP context specific. SGSN 23 receives the information “Required PCF Interaction” from the HLR and sends it to GGSN 24. Upon receiving this information “required PCF interaction”, the GGSN 24 knows whether it needs to communicate with the PCF when establishing a connection or changing the connection. The CSCF 26 receives the information “required PCF interaction” from the UMS and knows from there whether communication with the PCF 25 is required.

Therefore, according to this aspect of the invention, the three new ideas are incorporated separately or together.
(A) A common identifier is given to map the PDP context to the call;
(B) New parameters for HLR and UMS, i.e. PCF address, are given; and / or (c) New HLR and UMS parameters, such as "Required PCF interaction", are given.

The PS (packet switched) domain interaction with the policy control function (PCF) 25 will be described based on the embodiment of FIG. With reference to the step numbers shown in FIG. 2, the steps performed when establishing a connection are described in detail below.
In step 1, the mobile station 21 sends an INVITE message to the proxy CSCF 26, which includes a subscriber identity “Subscriber Id” and a call identifier “Call_Id”. Proxy CSCF 26 forwards this message to called party 27.

In step 2, proxy CSCF 26 receives an affirmative confirmation from called party terminal 27, eg, 183w / SDP defined in SIP. The proxy CSCF 26 forwards this confirmation to the mobile station (caller) 21.
In step 3, after receiving a positive confirmation from called party terminal 27, proxy CSCF 26 sends an authorization message (including subscriber Id, call identifier Call_Id, negotiated QoS, called party carrier address) to PCF 25. . The subscriber Id is, for example, the IMSI, MSISDN, or IP address (that is, the PDP address in the GPRS / UMTS layer) of the caller 21. Call_Id is needed and used to map the call to the correct PDP context in PCF 25. The negotiated QoS includes the QoS parameters negotiated for the call. For emergency calls, proxy CSCF 26 sets the QoS parameter assignment / retention priority to the maximum value. The called party carrier address is used in the GPRS / UMTS layer to set the TFT (traffic flow template) for the PDP context.

In step 4, the PCF 25 confirms the authorization message in step 3 by returning an authorization confirmation (subscriber Id, Call_Id) message to the proxy CSCF 26.
In step 5, the MS 21 activates the PDP context (eg, secondary PDP context) for the call by sending a (secondary) PDP Context Activate Request (PDP Address, Call_Id, Requested QoS) message to the SGSN 23. To request.

In step 6, a radio access bearer setup procedure is executed.
In step 7, the SGSN 24 sends a PDP context creation request (subscriber Id, Call_Id, negotiated QoS) message to the GGSN 24.
In step 8, the GGSN 24 requests permission for PDP context activation by sending an authorization request (Request Id, Subscriber Id, Call_Id, QoS Negotiated) message to the PCF 25. The first request message (step 8) forms a request state in the PCF 25.
In step 9, the PCF 25 responds by sending a decision (request Id, negotiated QoS, callee carrier address) message to the GGSN 24. The GGSN 24 sets the TFT for the PDP context based on the called party transport address.

In step 10, the GGSN 24 reports that it has acted based on the judgment by sending a status report message (request Id) to the PCF 25.
In steps 11 and 12, the PDP context activation is reported in a known manner.
In FIG. 2, messages 8 (request), 9 (determination) and 10 (status report) are COPS messages.
FIG. 2 shows the case of PDP context activation. If the PDP context is to be changed, steps 8 to 10 and the further steps shown in FIG. 2 are the same.

  Whether permission for PDP context activation is requested from the PCF 25 is operator specific. In order to provide this function to roaming subscribers as well, new parameters such as “Requested PCF Interaction” are included in the contract information in the HLR. The SGSN must receive the “requested PCF interaction” from the HLR and send it to the GGSN 24 in a PDP context activation / modification. Upon receipt of the “requested PCF interaction”, the GGSN 24 knows if communication with the PCF 25 is required when creating or modifying the PDP context.

GGSN 3, 24, 33 (FIGS. 3-5) will send the address of CSCF 4, 26 (or CPS 34 of FIGS. 3-5) to
By analyzing the proxy CSCF address from the proxy CSCF domain name (preferred option)
From the new parameter “CSCF address” sent by the MS in the (secondary) PDP context activation message,
From TFT of signaling PDP context,
I can know.

The parameters to be sent by the GGSN to find the correct call or connection in the PCF (CPS: PCF is a logical element, ie it is a stand-alone element or located in either the CSCF or GGSN) are It is as follows.
MS IP address (= PDP address) and MS port number (= TFT destination port number) (preferred option);
Peer IP address (= TFT source address) and peer port number (= TFT source port number).

  3-5 illustrate yet another embodiment of the present invention that provides 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. Further necessary elements for providing a mobile network are not shown since they will be apparent to those skilled in the art. The IPT core network is represented by a call processing server (CPS) 34. Further elements of the IPT network are not shown since they will be apparent to those skilled in the art.

The illustrated embodiment can provide QoS level billing used for telephone calls or other types of connections. For example, telephone calls require real-time (RT) traffic and are typically other such as e-mail transmission (which is carried using a lower QoS level and is therefore charged at a lower rate) Requires a higher QoS level than this type of communication.
The embodiments shown in FIGS. 3-5 combine call-related charging information, and IPT QoS reservation (eg, requested by the call origination terminal in a SIP: INVITE message) and mobile packet core network PDP context QoS (PDP context activation). Provides a mechanism for controlling the relevance or consistency between

3 to 5 show a mobile terminal (MT) 31 attached to a mobile network, an SGSN 32, a GGSN 33 (SGSN 32 and GGSN 33 form part of the mobile network to which MT 31 is attached), a call processing server (CPS). ) Shows message transmission to and from 34 The CPS 34 includes a call state control function (CSCF) as shown in FIGS. 1 and 2, and the display of the block 34 is also “CSCF”.
The embodiment shown in FIG. 3 is described in detail below.

  When the mobile terminal 31 is trying to establish a connection to another network element, such as the called party's telecommunications device, the mobile terminal 31 may use a session initiation protocol “ A call establishment request such as an “INVITE” message is generated. This INVITE message is transmitted from MT 31 to CPS 34 and includes information elements “Call_Id” and “SDP: QoS”. SDP means a serving profile database. “Call_Id”, for example, synthesizes a link of charging data such as a CDR (Billing Data Record) generated by a support node such as GSN (GPRS Support Node) and CSCF (or CPS) or otherwise from there Represents a common identifier provided to be profitable. This common identifier, eg, “Call_Id”, is distributed in the connection establishment phase (eg, call establishment phase) to the support node and the CSCF (or CPS). This technique can uniquely recognize connections or calls to be established in all such processing elements, such as GGSN and CPS, without requiring a direct interface between these elements. This method and structure provide a mechanism for combining QoS data and / or checking QoS validity in different network types that provide full IP connectivity between end terminals such as IP phones.

  In the next step 2, the mobile terminal 31 sends a PDP context activation request to the SGSN 32, which not only contains the normal information such as bearer type and codec, but also includes the parameter “Call_ID”. This parameter “Call_ID” and further necessary known information elements are then transmitted from the SGSN 32 to the GGSN 33, which is also notified of the common identifier “Call_ID” resulting from 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 further information such as bearer type and codec.

  As the next step 4, the CPS 34 (or the CSCF included in the CPS 34) performs a check of the connection to be established, identified by the common identifier “Call_ID”, and the requested QoS parameter is set to call signaling (SIP / SDP) and bearer (PDP context) are valid. The CSCF (CPS 34) performs this check to control the validity of the requested QoS parameters before accepting (or proceeding with) the call establishment, and for QoS given to other types of calls or connections. Make billing possible, or make it possible to fulfill other purposes. The CPS 34 generates OK or NO OK as a result of this check (Call_ID, SDP: QoS, bearer format, codec), and returns a response indicating the check result (OK / NO OK) to the GGSN 33 (step 5). The GGSN 33 uses the information received in step 5 to accept the call-related PDP context activation (if the check result is positive “OK”) or reject (if the check result is negative “N OK”). ), And then send a response back to the SGSN 32 to notify it of acceptance or rejection of the PDP context activation (or modification). When the SGSN 32 receives the accept or reject response, it performs known steps and sends the corresponding information to the mobile terminal 31.

Alternatively, the CPS 34 (or CSCF) may send a response directly to the mobile terminal 31 (step 6) and return a response to the call establishment request in step 1. For example, a SIP response “OK / NOK” is transmitted in step 6.
Therefore, an additional message sequence is provided between the CSCF (or CPS) and the GGSN 33 to determine how to proceed on the connection to be established.
The CPS (CSCF) 34 also receives additional parameters in addition to “Call_ID”, and these additional parameters can also be used as a basis for judgment.
The mechanism shown in FIG. 3 and described above is not limited to QoS and billing perspectives, but may be related to other types of checks and evaluations. Further, the decisions made by the CPS (CSCF) 34 may be advisory and need not be only in binary “OK / No OK” format.

  As shown in FIGS. 3 to 5, the GGSN 33 transmits a check request to the CPS (CSCF) 34 as step 3. Therefore, the GGSN 33 needs information regarding the address or name of the CPS (CSCF). If the GGSN 33 does not know the serving CSCF (CPS 34) from which the mobile terminal 31 is registered by the SIP registration mechanism and has transmitted the INVITE message, the address or name of the serving CSCF (CPS) 34 must be notified to the GGSN 33. I must. The embodiment of FIG. 4 shows a solution to this problem.

In addition to the above-described structure and function of the embodiment of FIG. 3, the embodiment of FIG. 4 adds new parameters to the PDP context activation request to inform the GGSN 33 of the address or name of the serving CSCF (or CPS) 34, For example, “S-CSCF_logicalname” is given, so the GGSN 33 knows where to send the “QoS” check request.
The embodiment of FIG. 4 is based on the structure described above with reference to FIG. The above description also applies to the message sequence shown in FIG. 4 and the steps performed.

  The mobile terminal 31 is notified of the CPS (or CSCF) 34 with which it was registered, and in the message sent to the SGSN 32 and further sent to the GGSN 33 in step 2, the address of the S-CSCF (serving CSCF in CPS 34) Configured to contain information about names. This new parameter indicating the address or name of the serving CSCF is indicated in FIG. 4 by the parameter “S-CSCF_logicalname” sent in the PDP context activation request. With this additional information “S-CSCF_logicalname”, the GGSN 33 is now informed of the correct CSCF (CPS) address or name and sends a check request to the CPS (CSCF) 34 indicated by this parameter ( Step 3). The other steps shown in FIG. 4 are the same as the steps of FIG. 3 described above.

Furthermore, FIG. 5 shows an optional additional feature that can be controlled by the end user of the mobile terminal 31, ie a feature that allows the end user or call originator to request a “QoS check” in, for example, a SIP: INVITE message. Show.
The embodiment shown in FIG. 5 includes all the features of the embodiments of FIGS. 3 and 4 described above. Further, in FIG. 5, the connection establishment request transmitted from the mobile terminal 31 to the CPS (CSCF) 34 in Step 1 includes a new parameter, for example, “Require_ggsn_check”.

  The structure and method shown in FIG. 5 is in addition to the charging mechanism for charging data and QoS control described above with reference to FIGS. The embodiment shown in FIG. 5 can optionally be selected to perform or not perform check steps 3-5. When the parameter “Require_ggsn_check” is sent in a SIP INVITE message (or other suitable form of connection establishment request message) sent from the mobile terminal 31 to the CPS 34, the CPS (or CSCF included in the CPS) Prepare to check based on 4 and wait for check request message from GGSN 33 based on step 3. After receiving the check request in step 3, the CPS 34 performs the check of step 4 as described above, after which the step sequence continues as described above. When the parameter “Require_ggsn_check” is not set or does not exist in the connection establishment request in step 1, the CPS (CSCF) 34 does not perform the QoS check based on step 4 and does not require a check message from the GGSN 33. With this information provided by the new parameter “Require_ggsn_check”, the CSCF is informed whether a check procedure is required to proceed with call establishment. This new check request parameter can of course have an arbitrary name such as “Require_pdpcos_check” as long as the CSCF can understand it.

  This new parameter given on the basis of FIG. 5 and the optionality of performing a QoS check or other type of check (step 4) can be determined by the logical name or address of the CPS 34 based on step 2 of FIG. It can also be applied to the structure shown in FIG. In particular, the address of the CPS 34 where the MT 31 is registered is notified to the GGSN 33 by other means, for example, by transmitting a message from the CPS 34 to the GGSN 33.

The methods and mechanisms provided by the embodiments of the present invention allow requests and checks to be properly performed, check results processed, billing information generated, and billing records formed for established connections. , GGSN 3, 33 and / or CSCF / CPS 34 may be implemented as software.
Also, the methods and mechanisms provided for checking QoS parameters may be implemented separately from the generation of charging information.
The embodiments described above can further inhibit and control, for example, PDP context updates for PDP contexts assigned to voice calls until a check from CPS 34 is performed. This can be managed by performing another message exchange between the GGSN 33 and the CPS 34.

  FIG. 6 shows yet another embodiment (method and / or system) of the present invention that is a variation of the embodiment shown in FIG. According to FIG. 6, the PCF 25 (FIG. 2) is integrated with the proxy CSCF 26 (FIG. 2) and forms a single network element 25 '. This structure provides the benefit of avoiding external signaling between the PCF and the CSCF and thus omitting steps 3 and 4 of FIG. The authorization check based on these steps 3 and 4 of FIG. 2 is performed using the internal processing of the network element 25 'of FIG. Signaling between the PCF and CSCF is in this case just internal signaling (ie not too severely limited by standardization).

The further steps 1, 2 and 5 to 12 in FIG. 6 are the same as described above with reference to FIG.
Therefore, the PCF may be the individual logical entity 25 shown in FIG. 2, may be integrated into the CSCF as shown in FIG. 6, or may be integrated into the GGSN 24. .

  FIG. 7 illustrates another embodiment of the system and method according to the present invention for providing call-based PDP context activation / modification. FIG. 7 shows PDP context activation in the case of an MO call. Assume that at least one PDP context has been activated for a call. In the case of PDP context activation, permission is requested from the PCF. Authorization from the PCF is required to adjust the QoS of the PDP context to the QoS of the call. For the GGSN, it can be configured whether judgment from the PCF is required and what kind of PDP context. For example, the configuration information can define that a decision from the PCF is only needed for the PDP context of the conversation, but for other PDP contexts, the PDP context activation must proceed without PCF interaction. Only the parameters required for GGSN-PCF communication are described below. The steps shown in FIG. 7 will be described in detail below.

Step 1: The MS sends an invite (subscriber Id) message to the proxy CSCF. The proxy CSCF forwards this message towards the called party.
Step 2: The proxy CSCF receives a positive confirmation, eg, 183w / SDP. The proxy CSCF forwards the confirmation to the caller.

Step 3: The MS activates the PDP context for the call by sending a Secondary PDP Context Activate Request (Requested QoS) message to the SGSN.
Step 4: A radio access bearer setting procedure is executed.
Step 5: The SGSN sends a PDP context creation request (PDP address, negotiated QoS) message to the GGSN.

Step 6: The GGSN requests permission for PDP context activation by sending a Request (Request Id, Subscriber Id, QoS Negotiated) message to the PCF. Subscriber Id is an identifier known to both the PS domain and the IM subsystem, eg, the IP address of the MS.
Step 7: The PCF responds by sending a decision (request Id, negotiated QoS) message to the GGSN.
Step 8-9: The PDP context activation is accepted with the parameters received from the PCF.
Step 10: The GGSN reports that the execution of the decision has been successfully completed by sending a status report (request Id) message to the PCF.
Steps 6, 7 and 10 are the same when the PDP context is changed.

While the preferred embodiment has been illustrated and described, the invention is not so limited and is intended to encompass all modifications, omissions and additions to the features illustrated and described above.
For example, the present invention is not limited to communication between GGSN (3, 24) and PCF-CSCF (or CSCF / PCF). The same communication can be performed by replacing the GGSN 3, 24 with the SGSN 2, 23 to produce SGSN-PCF-CSCF (or CSCF / PCF) communication.

FIG. 2 illustrates the basic structure and message flow according to one embodiment of the method and system of the present invention. FIG. 4 illustrates another embodiment of the system and method of the present invention. FIG. 6 illustrates yet another embodiment of the system and method of the present invention. FIG. 6 illustrates yet another embodiment of the system and method of the present invention. FIG. 6 illustrates yet another embodiment of the system and method of the present invention. It is a figure which shows the deformation | transformation of embodiment shown in FIG. FIG. 6 illustrates yet another embodiment of the system and method of the present invention.

Claims (71)

  In a method for establishing or changing a connection to a first network element assigned to a user, the connection is established or changed for a call between the first network element and a second network element; The connection is established by a third network element located in the network, the first network element generates a request to activate or change the connection, and the third network element activates the connection. Or, when receiving information about the request to change, sends a permission request to the fourth network element requesting permission to establish a connection of the requested type, the permission request being sent from the first network element Specify at least one of the second network element, the connection to be established or the connection type The fourth network element sends back a response specifying permission to establish a connection or connection type to the third network element, and that the establishment or modification of the connection is controlled based on this response. Feature method.   In a method for establishing a connection to a first network element assigned to a user, the connection is established by a third network element located in the network element, wherein the connection is established between the first network element and a second network. Established or modified for a call to and from the element, the first network element generates a request to activate the connection, and the third network element is information about the request to activate the connection. Is sent to the fourth network element requesting a check of connection parameters, the check request specifying at least one of the connection or connection type to be established, The network element performs the above check and sends a response specifying the check result above. Returned to the network element, the establishment of the connection, a method characterized in that it is controlled on the basis of this response.   The method according to claim 1 or 2, wherein the third network element is a gateway network element and a gateway GPRS support node.   The method according to claim 1 or 2, wherein the fourth network element is a call state control function (CSCF).   The method according to claim 1 or 2, wherein the fourth network element is a policy control function (PCF).   The method according to claim 1 or 2, wherein the fourth network element is a call processing server (CPS).   The method according to claim 1 or 2, wherein at least part of the fourth network element is implemented as part of the third network element.   The method of claim 1, wherein the authorization request is a request for authorization to activate or change a PDP context for the first network element.   The method of claim 1, wherein the authorization request includes at least one of an IMSI / MSISDN, a PDP address, a requested QoS, or an address of the second network element.   The method according to claim 2, wherein the check request is a request for checking at least one connection parameter.   The response is an indication of call characteristics, preferably an accepted QoS value, and / or accepted information about the second network element, and / or whether the connection is a normal call or an emergency call. The method of claim 1, wherein:   The first network element addresses a fifth network element when attempting to establish a call, and the fifth network element sends an authorization message characterizing at least one call parameter to the fourth network element. The method according to 1 or 2.   13. The method of claim 12, wherein the call parameter is at least one of IMSI, MSISDN, the IP address of the first network element, negotiated QoS, and called party transport address.   The method according to claim 12, wherein the fourth network element transmits an authorization confirmation message to the fifth network element.   12. The method of claim 11, wherein the fourth network element forms its response to the third network element based on the content of the authorization message.   The contract information stored for the first network element is a request from the third network element to the fourth network element when establishing a connection between the first network element and the third network element. The method of claim 1 including parameters defining the need for transmission.   The parameter is transmitted to the third network element when establishing a connection between the first network element and the second network element, and the third network element determines whether the third network element is based on the content of the parameter. 17. The method of claim 16, wherein the need to send a request to four network elements is determined.   When the parameter indicates that there is no need to send a request from the third network element to the fourth network element, the third network element does not send such a request and the first network 18. A method according to claim 17, comprising establishing a connection between an element and the third network element.   The network identifier according to claim 1 or 2, wherein a common identifier for identifying a network element that requires establishment to another network element or for identifying a call is provided in both an IP-based network and a GPRS or UMTS-based network. the method of.   A common identifier for mapping a connection to a call is provided and used when the third network element establishes a connection between the first network element and the third network element. 3. A method according to claim 1 or 2 transmitted to an element.   The method according to claim 19 or 20, wherein the common identifier is at least one of IMSI / MSISDN, MS IP address, MS port number, peer IP address, and peer port number.   The address of the fourth network element is included in the contract information stored for the first network element, and the address is used when establishing a connection between the first network element and the third network element. The method according to claim 1 or 2, wherein the method is transmitted to the third network element.   13. A method according to claim 1, 2 or 12, wherein the address of the fourth network element is configured for the third network element and for the fifth network element.   The method according to claim 2, wherein a billing record for billing the connection is provided in consideration of a result of the connection parameter check.   3. The connection parameter as claimed in claim 2, wherein the connection parameter indicates a requested or accepted QoS, QoS information given to both signaling and user traffic is checked, and a charging record is given considering the check result. the method of.   26. The method of claim 25, wherein the QoS check is performed in response to a check request.   The connection parameter is a call characteristic, preferably an accepted QoS value, and / or information about the second network element, and / or an indication indicating whether the connection is a normal call or an emergency call. Item 3. The method according to Item 2.   3. The connection according to claim 1 or 2, wherein the connection includes a GPRS / UMTS base network and an IP base network, and QoS values given to both networks for the connection are checked and compared to obtain charging related information. Method.   The method according to claim 1 or 2, wherein a check request for checking charging related parameters is transmitted from the first network element to the fourth or another network element when transmitting a call establishment request.   In a system for establishing or changing a connection to a first network element assigned to a user, the connection is established or changed for a call between the first network element and a second network element; The connection is established by a third network element located in the network, the first network element generates a request to activate or change the connection, and the third network element activates the connection. Or, when receiving information about the request to change, sends a permission request to the fourth network element requesting permission to establish a connection of the requested type, the permission request being sent from the first network element At least one of the second network element, the connection to be established or the connection type And the fourth network element returns a response specifying the permission to establish a connection or connection type to the third network element, and the establishment or change of the connection is controlled based on this response. A system characterized by that.   In a system for establishing a connection to a first network element assigned to a user, the connection is established by a third network element located in the network element, and the connection is established between the first network element and a second network. Established or modified for a call to and from the element, the first network element generates a request to activate the connection, and the third network element is information about the request to activate the connection. Is sent to the fourth network element requesting a check of connection parameters, the check request specifying at least one of the connection or connection type to be established, The network element performs the above check and adds a response specifying the check result. Returned to the third network element, the establishment of the connection, a system characterized in that it is controlled on the basis of this response.   32. The system according to claim 30 or 31, wherein the third network element is a gateway network element and a gateway GPRS support node.   32. A system according to claim 30 or 31, wherein the fourth network element is a call state control function (CSCF).   The system according to claim 30 or 31, wherein the fourth network element is a policy control function (PCF).   32. A system according to claim 30 or 31, wherein the fourth network element is a call processing server (CPS).   32. A system according to claim 30 or 31, wherein at least a part of the fourth network element is implemented as part of the third network element.   The system of claim 30, wherein the authorization request is a request for authorization to activate or change a PDP context for a first network element.   The system of claim 30, wherein the authorization request includes at least one of an IMSI / MSISDN, a PDP address, a requested QoS, or an address of the second network element.   32. The system of claim 31, wherein the check request is a request that requests a check of at least one connection parameter.   The response is an indication of call characteristics, preferably an accepted QoS value, and / or accepted information about the second network element, and / or whether the connection is a normal call or an emergency call. 32. The system of claim 30, wherein:   The first network element addresses a fifth network element when attempting to establish a call, and the fifth network element sends an authorization message characterizing at least one call parameter to the fourth network element. The system according to 30 or 31.   42. The system of claim 41, wherein the call parameter is at least one of IMSI, MSISDN, the IP address of the first network element, negotiated QoS, and called party transport address.   42. The system of claim 41, wherein the fourth network element transmits an authorization confirmation message to the fifth network element.   41. The system of claim 40, wherein the fourth network element forms its response to the third network element based on the content of the authorization message.   The contract information stored for the first network element is a request from the third network element to the fourth network element when establishing a connection between the first network element and the third network element. 32. The system of claim 30, including parameters that define the need for transmission.   The parameter is transmitted to the third network element when establishing a connection between the first network element and the second network element, and the third network element determines whether the third network element is based on the content of the parameter. 46. The system of claim 45, determining the need to send a request to four network elements.   When the parameter indicates that there is no need to send a request from the third network element to the fourth network element, the third network element does not send such a request and the first network 47. The system of claim 46, wherein the system establishes a connection between an element and the third network element.   32. A claim 30 or 31 wherein a common identifier for identifying a network element requiring establishment to another network element or for identifying a call is provided in both an IP-based network and a GPRS or UMTS-based network. System.   A common identifier for mapping a connection to a call is provided and used when the third network element establishes a connection between the first network element and the third network element. 32. A system according to claim 30 or 31 transmitted to an element.   50. The system of claim 48 or 49, wherein the common identifier is at least one of IMSI / MSISDN, MS IP address, MS port number, peer IP address, peer port number.   The address of the fourth network element is included in the contract information stored for the first network element, and the address is used when establishing a connection between the first network element and the third network element. 32. The system according to claim 30 or 31, wherein the system is transmitted to the third network element.   42. A system according to claim 30, 31 or 41, wherein the address of the fourth network element is configured for the third network element and for the fifth network element.   32. The system according to claim 31, wherein a billing record for billing the connection is given in consideration of a result of the connection parameter check.   32. The connection parameter according to claim 31, wherein the connection parameter indicates a requested or accepted QoS, the QoS information given to both signaling and user traffic is checked, and a charging record is given considering the check result. System.   55. The system of claim 54, wherein the QoS check is performed in response to a check request.   The connection parameter is a call characteristic, preferably an accepted QoS value, and / or information about the second network element, and / or an indication indicating whether the connection is a normal call or an emergency call. Item 32. The system according to Item 31.   32. The connection according to claim 30 or 31, wherein the connection comprises a GPRS / UMTS-based network and an IP-based network, and QoS values given to both networks for the connection are checked and compared to obtain charging related information. system.   32. A system according to claim 30 or 31, wherein a check request for checking billing related parameters is sent from the first network element to the fourth or another network element when sending a call establishment request.   A method for requesting permission to establish or change a connection between a first network element and a third network element assigned to a user, the connection comprising the first network element and a second network element. Activated or modified for a call to and from a network element, and the connection is activated in a manner as established by the third network element located in one of the networks, or When receiving information about the request to change, the third network element sends a permission request requesting permission to establish a connection of the requested type to the fourth network element, At least one of the first network element, the second network element, the connection or the connection type to be established And the third network element receives a return response that specifies permission to establish a connection or connection type from the fourth network element, and the establishment or change of the connection is controlled based on the response. A method characterized by that.   A method for requesting permission to establish or change a connection to a first network element assigned to a user, wherein the connection is for a call between the first network element and a second network element. Established and modified, and the connection is established in a manner such that it is established by a third network element located in the network, the authorization request requesting authorization to establish a connection of the requested type in the fourth network. Received by the element, the authorization request specifies at least one of the first network element, the second network element, a connection or connection type to be established, and a permission to establish a connection or connection type A response designating the connection from the fourth network element to the third network element and establishing or changing the connection Wherein the controlled based on the response.   A support node suitable for use in a method or system for establishing or changing a connection to a first network element assigned to a user, wherein the connection is between the first network element and a second network element. The connection is established or modified for a call of the user, and the connection is at a support node as established by the support node, when the support node element receives information about a request to activate or change the connection. Sending an authorization request requesting authorization to establish a connection of the requested type to another network element, the authorization request comprising the first network element, the second network element, the connection to be established or Specify at least one of the connection types, and the support node is connected or connected Support node, characterized in that the response specifying a permission for establishing is configured to receive from the further network element.   A support node suitable for use in a method or system for establishing or changing a connection to a first network element assigned to a user, wherein the connection is between the first network element and a second network element. The connection is established or modified for a call of the user, and the connection is at a support node as established by the support node, when the support node element receives information about a request to activate or change the connection. Sends a check request requesting a check of connection parameters to another network, the check request specifying at least one of a connection and a connection type to be established, and the support node is connected or connected The response specifying the check result used to establish the Support node, characterized in that it is configured to receive from the network element.   63. A support node according to claim 61 or 62 configured to control establishment or change of the connection based on the response.   64. A support node according to claim 62 or 63, which is a gateway network element.   64. The support node according to claim 62 or 63, which is a gateway GPRS support node.   A network entity suitable for use in a method or system for establishing or changing a connection to a first network element assigned to a user, wherein the connection is between the first network element and a second network element. In a network entity such that the connection is established by a third network element located in the network, the network entity for establishing a connection of the requested type Receiving an authorization request requesting authorization, wherein the authorization request specifies at least one of the first network element, the second network element, a connection to be established or a connection type; Specify permission to establish connection or connection type Network entity characterized in that it is configured to return a response.   A network entity suitable for use in a method or system for establishing or changing a connection to a first network element assigned to a user, wherein the connection is between the first network element and a second network element. In a network entity that is established or modified for another call, the network entity receives a check request from another network element requesting a check of connection parameters, and the check request is a connection to be established And at least one of the connection types, the network entity checks the connection parameters and sends a response specifying the check result used to establish the connection or connection type to the other network element. Configured to return Network entity, characterized in that is.   68. A network entity according to claim 66 or 67, wherein the network entity is a call state control function or a policy control function (PCF) or a call processing server (CPS).   67. The network entity according to claim 66, wherein the authorization request is a request for authorization to activate or change a PDP context for the first network element.   68. The network entity according to claim 66, wherein the authorization request includes at least one of an IMSI / MSISDN, a PDP address, a requested QoS, or an address of the second network element.   68. The response of claim 66, wherein the response indicates at least one of call characteristics, accepted information about the second network element, and an indication indicating whether the connection is a normal call or an emergency call. Network entity.

Images