JP2008113465A - Service and capability negotiation in network using single numbering scheme - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a mechanism by which a service supported by the network can easily be provided. <P>SOLUTION: The invention proposes a method of controlling a network to which a communication device is connected, comprising a step of obtaining (S22) connection capability information from the network and a step of allowing (S23) the connection capability information to indicate a plurality of services supported by the network and evaluate a connection service based on the obtained connection capability information. The method includes the steps of obtaining the connection capability information in receiving a call and receiving (S22) a setup message including the connection capability information of the network from the communication device. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a method for controlling a network to which a communication device is connected, and a communication device configured correspondingly.

  Mobile stations require a large amount of information regarding the network used and the capabilities of the called or calling party. This information can usually be obtained in call setup signaling. However, this is not always the case. If the information is missing, the service and bearer level compatibility is not reached in the call setup and the call fails. This problem will be described in detail below.

  A mobile network may support a multi-numbering mechanism, a single numbering mechanism (SNS), or both (see 3GPP TS 29.007). Commercial networks started with a multi-numbering mechanism at the beginning of the GSM era, after which many operators introduced a single numbering mechanism despite the problems described (and solved) below.

  In the multi-numbering mechanism, the user has a separate MSISDN number for each service used for mobile incoming calls. Service information is stored in the home location register (HLR) or home subscriber server (HSS) for each MSISDN number. This information is used to set up a mobile incoming call when no clear service information is received from the caller in the incoming setup request. See 3GPP TS 29.007.

  In a single numbering mechanism, the user has only one MSISDN number common to all services. When no clear service information is received from the caller in an incoming setup request, the network sends a setup without a service definition to the mobile station (MS). The MS must determine the service to use for the call. There is a risk that the mobile network or intermediate network or caller cannot support the service or channel configuration indicated by the MS (see 3GPP TS 27.001, version 4.1.0).

  Thus, when the MS responds with a service definition that cannot be supported by the network (eg, a multi-slot / HSCSD channel configuration), the call fails. As a result, on the security side, the basic 9.6 kbit / s service must always be used to guarantee a successful call. However, 9.6 kbit / s is too slow for many applications.

  Alternatively, the MS may respond at the same data rate. However, the MS does not know whether the ITC (information transfer capability) of the original call setup is UDI / RDI, 3.1 kHz, or speech. As a result, even if the data rate itself is correct, the call may fail because other parties can use, for example, a modem or other UDI / RDI protocols, for example.

  Thus, in summary, the present invention concerns the problem of obscure service information received in incoming setup requests. In such a case, the network transmits a setting without a service definition to the mobile station (MS). The MS must determine the service to use for the call. However, there is a risk that the mobile network or intermediate network or caller cannot support the service or channel configuration indicated by the MS.

  The problems associated with mobile incoming calls have been described above. However, there is a similar problem in the case of mobile transmission, which will be described below.

  For example, when the user is roaming the visited network, the user does not know the visited network's capabilities and therefore cannot configure the MS to make a successful data call to the home intranet. (Although a well-educated user makes several attempts at different settings, the proposed method can also avoid such complications.) Therefore, in this case, the user wants to use Either try to use the service and expect that the service is supported, or you can set up a basic service call, for example, at a data rate of 9.6 kbit / s.

  Both of these solutions are disadvantageous because in the first one the call may fail and in the second one the full performance of the MS is not available. Therefore, the current situation is not acceptable.

  Therefore, the underlying object of the present invention is to provide a mechanism that can easily provide services supported by a network.

  The purpose of the present invention is to control a network to which a communication device is connected, and to obtain a connection capability information from the network and evaluate a connection service based on the obtained connection capability information. Achieved.

  Further, the above object is also provided by a communication device connected to a network, the communication device configured to obtain connection capability information from the network and evaluate a connection service based on the obtained connection capability information. Achieved.

  Therefore, according to the present invention, the communication device can obtain the connection capability and evaluate the connection service correspondingly. That is, the connection service is evaluated for services available on the network, and the requested connection service is changed or adapted accordingly. Thus, the communication device only establishes a connection service supported by the network.

  Therefore, since the communication device knows the connection capability in the network or the like, failures related to the network capability are eliminated. Thus, failures associated with ITC (information transfer capability) are also eliminated.

  The connection capability information includes network capability information and / or information related to the capabilities of the far-end party. Further, the connection capability information includes information regarding the capability of the intermediate network between the network to which the communication device is connected and the far-end party.

  The connection capability information is obtained when a call is started. Alternatively, connection capability information may be obtained when terminating a call. The connection capability information is also obtained when registering in the network, and the obtained information is stored in the communication device. Furthermore, connection capability information is also obtained during the configuration procedure, in which the user or operator is invited to manually configure the communication device with the connection capability information.

  Further, the connection capability is obtained from the network through a message service, and the obtained information is stored in the communication device. The message service is SMS (short message service) or USSD (unconfigured supplemental data).

  In addition, the connection service requested by the user of the communication device is obtained in the evaluation phase so that it is checked whether the connection service is supported by the network, and if necessary, the requested service is: It is changed based on the obtained connection capability information. That is, when the communication device detects that the network does not support the connection service requested by the user, the communication device overrides the service.

  In order to obtain the connection capability information, a setting message including connection information from the network is received by the communication device. That is, the network actively notifies the communication device about its capabilities in the setup message.

  In the evaluation phase, a connection service is determined based on the obtained connection capability information, and information about the determined connection service is generated. Information about the determined connection service is sent to the far end party in a message. With this information, the far end party and other such network control elements are informed about supported connection services.

  The communication device is a mobile communication device and the network is a mobile communication network. That is, the present invention can be most effectively applied to a mobile network, especially when the mobile station roams the visited network because the mobile station does not notice the capability of the visited network.

  However, the communication device may be a fixed communication device and the network may be a fixed communication network. Here, the fixed communication device can be easily connected to another fixed network without having to newly configure the communication device (eg after removal in a foreign country), so the present invention is also effective in this case.

  Furthermore, the present invention is a method for controlling a connection and a network between a communication device and a far-end party, detecting information on supported connection services generated by the communication device, and a network control element A method is also proposed comprising the steps of detecting connection related information with the far end party and evaluating whether the detected information and connection related information match each other.

  Alternatively, the present invention is a network control element for controlling a connection between a network and a communication device and a far-end party, and further detects information about a supported connection service generated by the communication device. A network control element configured to detect connection-related information between the network control element and the far-end party and to evaluate whether the detected information and the connection-related information match each other is also proposed.

  Thereby, it can be ensured whether the communication device connected to the network control element supports the feature of the present invention, that is, the negotiation of the connection service. If incorrect information is provided, it can easily be determined that the communication device does not support this feature or that defect information has been generated.

  Information regarding supported connection services generated by the communication device is overridden if the information does not match. That is, when the communication device does not support the features of the present invention or generates defect information, this information is canceled and call establishment based on known techniques is performed. Thus, the method of the present invention provides backward compatibility because communication devices that do not generate information about supported connection services are also supported.

  The network control element is an interworking function (IWF) located in the visited network or between the home network of the communication device and the visited network.

The present invention will be easily understood from the description with reference to the accompanying drawings.
FIG. 1 shows an outline of a network system to which the present invention can be applied. Assume that a mobile station (MS) is roaming the visited network 1. This visited network is controlled by the Mobile Service Switching Center (MSC), which is the visited MSC (VMSC) from the MS perspective. Another network 2 (which is the MS's home network, but not necessarily) is connected to the network 1 via an interworking function (IWF). Note that instead of the MSC, an MSS (MSC server) may be used, which in this case is the visited MSS (VMMS). The IWF may be integrated into the VMSC.

  According to the embodiments described below, the MS actively collects information about capabilities such as the visited network to which it is connected (and its home network and / or far end party, if necessary) Or such information is provided.

  Hereinafter, as the first embodiment, an information acquisition procedure will be described for a case where the MS actively collects information. That is, according to the first embodiment, the mobile station collects information about the network capabilities and far end parties it is roaming and using. This information is stored in the MS (Mobile Terminal (MT) itself or Subscriber Identification Module (SIM)) for later use. Alternatively, information related to network capabilities can be configured at the MS, eg manually by a user or automatically by an operator or network.

Next, some examples of how the MS obtains information on network capabilities and the like will be described.
When a user initiates or receives a call at the MS, the MS observes which services and bearers are available in the network and monitors the details of the call setup parameters (e.g. Gather information on the server's capabilities at the address. The MS may provide information for each visited network (eg, based on the mobile country code and mobile network code) and / or for each calling party (based on an identification such as the MSISDN number or IP address of the calling party) ( For example, stored in the mobile terminal itself or in the SIM (subscriber identity module).

That is, the MS actively collects the requested information from the network.
Alternatively, network and calling party (eg, server) capabilities and information can be configured at the MS, eg, by a user or operator.

In this case, the necessary information can also be obtained by other methods (eg, operator home page on the Internet, handbook, etc.), and the user (or even the operator) can configure the MS accordingly.
Alternatively, the network may supply capability information to the MS, for example by SMS or other available transport means (eg USSD or e-mail), for example when registering with the network, and automatically by the MS itself. It can also be configured / stored.

That is, in this case, the MS can obtain necessary information by a certain transport means and can automatically configure itself based on the information.
In the following, information regarding network capabilities and the like will be described in detail.
Information collected by the MS includes, for example:
1) CS bearer supported by the mobile network. For example, in GSM:
-HSCSD / multi-slot configuration-TCH / F14.4 channel code-Data compression-ECSD channel code (TCH / F28.8, TCH / F32, TCH / F43.2)

2) Connection elements supported by the mobile network:
-Transport-Non-transport 3) Information transfer capability supported by network or call party:
-UDI / RDI
-3.1 kHz
-Speech 4) For example, protocol support:
-ITU-TV. 120 protocol-ITU-TV. 110 Protocol-Frame Tunnel Mode (FTM)
5) Asynchronous / synchronous capabilities supported by the network:
-Asynchronous-Synchronous 6) Multimedia

Of course, this list is not exhaustive, and other additional information items can be added.
The abbreviations used above are briefly described below. HSCSD (High Speed Circuit Exchange Data), RDI (Limited Digital Information), TCH (Traffic Channel), TCH / F (Full Rate Traffic Channel), UDI (Unlimited Digital Information).

The MS can use the stored information when, for example, receiving a call in a single numbering environment, and the intermediate network (s) can send clear service information from the caller to the MS. Can be sent.
In this case, the MS determines which service to use based on the current 3GPP specification (see TS 29.007 and 27.001) and sends the service definition to the network in the BCIE (Bearer Capability Information Element) . In the current state of the art, the MS can only estimate which service to use (see 3GPP TS 27.001, version 4.1.0). The requested bearer may not be supported in the visited network, which means that the call is unsuccessful. Alternatively, on the security side, the MS may require a basic 9.6 kbit / s bearer, even if the network can support HSCSD bearers, even in high speed environments. This means that the user can get only a low-speed service even when operating with.

  However, according to an embodiment of the present invention, the MS collects network and call party capability information. Thus, the MS can respond with service and bearer requests that match the available capabilities of the operating environment. For example, if the MS is normally configured to be used in a network that supports HSCSD, the user does not need to change with settings that attempt to find a supported configuration, and the MS Automatically lowers its requested service level to match the capabilities of the network being played (not necessarily supporting HSCSD). In fact, the retraction from HSCSD to non-HSCSD calls currently does not work in networks that do not support HSCSD, and calls are released when an HSCSD call is requested (3GPP TS 27.001, version 4.1.0). See).

The above procedure is shown in the flowchart of FIG. This procedure starts when a call is placed.
In step S11, the service requested by the user is obtained. For example, this is HSCSD, as it is usually supported by the MS, as described above.

In step S12, network capability information and the like are obtained. While performing this phase, the MS actively requests the network to send the necessary information to the MS or accesses the memory of the MS where this information was previously stored.
Thereafter, in step S13, the requested service is evaluated with respect to the obtained network and / or far end capability information. That is, it checks whether the requested service is supported by the network, supported by the intermediate network and / or supported by the caller. If necessary, the service is changed accordingly. For example, if a high rate speech connection is not supported, the connection is changed to a corresponding low rate speech connection. Otherwise (eg, in the above example for HSCSD), the MS indicates to the user that the requested service is not supported and suggests the choice of another service. In the positive case, i.e. when the requested service is supported by the network, no services are changed at this stage. Information about supported services is written to the BCIE (bearer capability information element) in step S14.

Thereafter, the procedure ends and normal communication is performed.
In the following, some examples of the above negotiation of requested services will be described.
Example 1:
-The MS supports multimedia. The MS has already made a call in the network that is currently roaming and has found that the network supports CS multimedia (synchronization bearer, multimedia signaling). TCH / F 14.4 channel coding and multi-slot configuration. (Alternatively, network capabilities per network are pre-configured in MS (MT (Mobile Terminal) or SIM (Subscriber Identity Module)).

-The MS receives a call setup without a service indication. The MS responds with a BCIE requesting a 28.8 kbit / s multimedia call with a modem (ie ITC = 3.1 kHz) and a 2 * TCH / F 14.4 channel configuration.
– If the called party actually requests a multimedia call, the call is set up as a multimedia call. If the called party requests a speech call, the call moves back to speech (see 3GPP TS 29.007, 24.008 and 27.001).

Example 2:
-The MS just makes a call to the intranet access server, which calls back after the identity check. The MS may receive a TCH / F14.4, multi-slot, non-transparent connection, UDI and V.2 during a call just made to the access server or during a previous call in the network. It has been found to support 120 protocols. (Alternatively, network capabilities per network may be pre-configured in the MS (MT or SIM).)
-The callback setup message by the server does not include the service definition. MS is non-transparent in 2 * TCH / F14.4 channel configuration, 28.8 kbit / s, UDI / V. Respond with a BCIE requesting a 120 multi-slot call.

Example 3:
-The MS has already received the call in the network it is currently roaming and the network supports TCH / F14.4, multi-slot, non-transparent connection, ITC = 3.1 kHz (modem), but UDI Finds no support. (Alternatively, network capabilities per network may be pre-configured in the MS (MT or SIM).)

-The user makes a call to the home network and the default settings are non-transparent, 56 kbit / s, UDI / V.3 in 3 * TCH / F14.4 channel configuration. 120, multi-slot.
-The MS automatically returns the setting to non-transparent, 3.1 kHz autoboarding (modem) with 2 * TCH / F14.4 channel configuration to match the capabilities of the visited network.

Example 4:
-The MS has already made a call to a server (one of the access servers that the user uses more or less regularly) that supports ITC = 3.1 kHz (ie modem), but does not support UDI I have found that. (Alternatively, server capabilities per identification / address may be pre-configured in the MS (MT or SIM).)

The user makes a call to the server and the default setting is, for example, non-transparent, 56 kbit / s, UDI / V.3 in 3 * TCH / F14.4 channel configuration. 120, multi-slot.
-The MS automatically reverts the settings to non-transparent, 3.1 kHz autoboarding (modem) with 2 * TCH / F14.4 channel configuration to match the server's capabilities.

A more detailed example of implementing the present invention is described below.
Currently, the MS has information about the actual name of the network. A network is identified by its mobile country code (MCC) and mobile network code (MNC). For example, MCC 244 and MNC 5 identify the network as a Finnish radio ringer operator network. This information can be extended to include (collected) information about the capabilities of the network.

Here, in the case of a mobile outgoing (MO) call, the MS accesses this information and compares the network capability information with the user request service. The MS modifies the requested service as needed to suit network capabilities.
If network capability information is not available, a call is made based on the user request and the result of the call is stored for further use.

  If the network is updated to make available new services, the collected information (per network or per network) should be used to prevent the MS from refusing to use the requested service because it was not supported. There is preferably a possibility / mechanism to clear (all at once). Alternatively, it is also preferred that the feature can be turned off. If a feature is turned off, information collection can be turned on / off separately. This is also useful when a user asks about the capabilities of the network from the MS, i.e. when reading the collected information.

  In the case of a mobile incoming (MT) call, the user needs information on how to receive an MT SNS (single numbering mechanism) call, ie fax, video, data. When an MT call is received that does not have BCIE parameters in the “setup” message, the MS looks up the rest of the parameters from the collected information.

  Thus, according to the first embodiment, the service capabilities of the network and the called party are collected by the MS during the connected call or by receiving this information at the network initiated provision. This information can also be configured at the MS by the user or operator. This information is stored in the MS and can be used when initiating or receiving a call without the network capability information obtained at call setup.

  Hereinafter, a second embodiment in which information is transmitted to the MS when a mobile incoming call is established will be described. Basically, only differences from the first embodiment will be described below. In particular, note that the same connection capability information (network capability information, information about the far end party, etc.) is the same.

  According to the second embodiment, the mobile network indicates to the MS via configuration signaling the capability and available parts of the intermediate network (s) and caller characteristics. For example, if the MS supports multimedia and receives a call setup indicating “ITC = UDI, TCH / F32 support, multislot”, the MS will receive a full 64 kbit / s ITC = UDI multimedia. Respond with BCIE.

This will be described in detail below.
Again, assuming that the MS is served by an MSC (Mobile Services Switching Center) or MSS (MSC Server), these are the visited MSC or MSS (abbreviated as VMSC or VMSS) from the MS perspective. It is.
The procedure performed is shown in the signaling flow diagram of FIG.
This procedure is such that the VMSC or VMSS receives a setup message (eg, IAM (Initial Address Message)) from the core / external network without sufficient service definition (step S21) and a single numbering mechanism (SNS ) Is used when used.

  In step S22, the VMSC sends to the MS the data call related capabilities of itself and the associated wireless network (if the VMSC knows) and the ITC / TRM received from the caller. This information is preferably sent in an existing message (such as a “setup” message). For example, this information may be an extension or reserved field ("Network Call Control Capability") of an existing element, as described in 3GPP TS 24.008, Subclause 9.3.23.1 and 10.5.4.29. Included). This ensures backward compatibility with mobile stations that do not support the new features proposed here. This is because, for example, when sending a special message, an MS that does not support the features according to the present invention may cause confusion.

However, of course, the use of other signaling messages and elements (eg, class marks) is also conceivable when the features described here are mandatory for all MSs.
In step S23, the MS evaluates the received information. That is, an MS that receives a configuration with network capability and ITC / TRM information can use the multi-slot configuration and TCH / F 14.4 from the network capability information, for example, in the visited network, or TCH / F 28. .8, TCH / F 43.2, or TCH / F32 channel, and whether it is a transparent (T) service, a non-transparent (NT) service, or its It is inferred whether both and the caller is requesting UDI / RDI (unlimited digital transmission / limited digital transmission), 3.1 kHz or a speech call.

In step S24, the MS responds with a BCIE (bearer capability information element) inferred from the above information and the associated configuration in the MS itself.
This element (ie information about the negotiated service) is used by the VMSC and IWF to set up the call. Optionally, in step S26, a failure check procedure is performed (after transferring the BCIE to the IWF in step S25), which is described below. The normal call establishment procedure is then continued without failure.

Several examples relating to the above evaluation of network capability information and the like will be described below.
Example 5:
-If the MS just makes a call to the intranet access server, the server calls back after the identity check, and the incoming call indicates "ITC = UDI, TCH / F14.4 support, multislot support" The MS sets up a non-transparent call with maximum data rate configuration and UDI protocol with TCH / F 14.4 supported by itself (eg 2 * 14.4 = 28.8 kbit / s).

Example 6:
-The MS supports multimedia. The MS receives a call setup indicating “ITC = UDI, TCH / F32 support, multislot”. The MS responds with a full 64 kbit / s ITC = UDI multimedia BCIE.

Example 7:
-The MS supports multimedia. The MS receives a call setup indicating “ITC = 3.1 kHz, TCH / F 14.4 support, multi-slot support”. The MS responds with a full 28.8 kbit / s ITC = 3.1 kHz multimedia BCIE. (If the caller requests a speech service anyway, a standard retreat from 3.1 kHz to speech is made.)

  Next, as a third embodiment of the present invention, what actions are performed when a MS selects the wrong service due to failure or because the actual MS does not support the features of the present invention will be described. That is, according to the third embodiment, the failure check procedure described above with reference to step S26 in FIG. 3 is executed.

  In particular, network control elements such as the Interworking Function (IWF) use automatic data rate detection and automatic protocol detection at the crossroads between the IWF and the caller to ensure that the MS has an incorrect fixed network data rate (FNUR). ) Or protocol (ie FNUR or protocol different from that used by the caller) is eliminated. In the illustrated embodiment, it is assumed that VMSC and IWF are separate entities. In this case, it is necessary to transfer the BCIE to the IWF in step S25. However, as described above, the IWF may be integrated into the VMSC. In this case, the IWF can directly access the BCIE and no transmission over the network is required.

The procedure executed in the case of such a failure is shown in the flowchart of FIG.
In step S31, the IWF detects the ITC value of the called MS, that is, the ITC value set by the MS. In step S32, the IWF detects the data rate and protocol between the IWF and the caller. In step S33, the IWF checks whether the detected ITC value of the MS matches the detected data rate and protocol. If they match, the IWF determines that the MS can support the features of the present invention and normal communication continues (step S34).

  However, if the values do not match, the IWF determines that the called MS does not support the service and network capability negotiation. That is, the MS responds with an incorrect information transfer capability (ITC) value, i.e., a value different from the value indicated by the caller.

  In this case, the interworking function (IWF) uses the ITC value received from the calling party, that is, overrides the ITC received from the called mobile station (step S35). The IWF then adapts the relevant parameters to match the changed ITC value, eg, if the ITC is changed from 3.1 kHz to UDI, the modem type is not required.

Note that the procedure according to the third embodiment does not need to be performed in the IWF and can be performed in any type of network control element.
In addition, cases may occur where the MS suggests a service that does not match the service used by the caller. In this case, the IWF rejects the call, but the MS correctly determines the service. However, with all the available information and methods described in the above embodiments, the probability of such a case is very low.

The above description and accompanying drawings merely illustrate the invention. Accordingly, the embodiments of the invention may be modified within the scope of the claims.
For example, the above embodiment has described the case where the mobile station roams in the visited network. However, the present invention is not limited to this case. That is, the network can be easily reconfigured by applying the negotiation procedure according to the present invention. For example, a new service or the like can be introduced. Also, the communication device for executing the negotiation procedure can easily use a new service in its own network without requiring manual configuration or the like.

  Furthermore, the above embodiment has described an example in which a mobile communication network is used. The present invention can be most effectively applied to mobile communication networks, but can also be applied to fixed communication networks. For example, a fixed telephone is transferred from one location to a new location, and at the new location is connected to a new fixed network that has different characteristics than the old network. This is the case when another operator operates a new network. In such cases, when the present invention is applied, there is no need to manually configure the fixed telephone to the network. In order to employ the features of the present invention, it is necessary that a corresponding message consisting of necessary connection capability information (such as network capability) is transmitted over a fixed network.

It is a figure which shows the structure of the network system which can apply embodiment of this invention. It is a flowchart of the call setting procedure by 1st Embodiment. It is a figure which shows the signaling flow of the call setup procedure by 2nd Embodiment. It is a flowchart of the failure procedure by 3rd Embodiment.

Explanation of symbols

1 visited network 2 another network MS mobile station MSC mobile service switching center IWF interworking function

Claims (34)

A method for controlling a network to which a communication device is connected,
Obtaining connection capability information from the network (S22), the connection capability information indicates a plurality of services supported by the network,
Evaluating a connection service based on the obtained connection capability information (S23),
In a method including the steps
The step of obtaining connection capability information is performed when a call is received;
In the obtaining step, a setting message including connection capability information from the network is received by the communication device (S22),
A method involving that.   The method of claim 1, wherein the connection capability information includes network capability information.   The method of claim 1, wherein the connection capability information includes information regarding a far-end party capability.   The method of claim 1, wherein the connection capability information includes information regarding a capability of an intermediate network between a network to which a communication device is connected and a far end party.   The method of claim 1, wherein the step of obtaining connection capability information is performed when placing a call.   The method of claim 1, wherein the step of obtaining connection capability information is performed when registering with a network, and the obtained information is stored in a communication device.   The method of claim 1, wherein the step of obtaining connection capability information is performed by a network sending information to a communication device via a message service, and the obtained information is stored in the communication device.   The method of claim 1, wherein the step of obtaining connection capability information is performed in a configuration step in which a user or operator is invited to manually configure a communication device with connection capability information. Further comprising obtaining a connection service requested by the user (S11),
The evaluation step (S13)
Check if the connection service is supported by the network and, if necessary, change the requested service based on the obtained connection capability information;
6. The method of claim 5, comprising the steps of:   The method of claim 1, wherein in the evaluating step, a connection service is determined based on the obtained connection capability information, and information about the determined connection service is generated.   The method according to claim 10, wherein information on the determined connection service is sent to the far-end party in a message (S14).   The method of claim 1, wherein the method is performed in a communication device.   The method of claim 1, wherein the communication device is a mobile communication device and the network is a mobile communication network.   The method of claim 1, wherein the communication device is a fixed communication device and the network is a fixed communication network. In the evaluation stage, the communication device infers a requested service using connection capability information;
The method of claim 1, wherein the communication device responds to a setup message by the network with explicit service information defining the inferred service. In a device that is connected to a network, obtains connection capability information from the network, and evaluates a connection service based on the obtained connection capability information.
The device obtains connection capability information when terminating a call, receives a setup message including the connection capability information, obtains the connection capability information,
The connection capability information indicates a plurality of services supported by the network;
A device characterized by that.   The apparatus of claim 16, wherein the connection capability information includes network capability information.   The apparatus of claim 16, wherein the connection capability information includes information regarding a far-end party capability.   The apparatus according to claim 16, wherein the connection capability information includes information regarding a capability of an intermediate network between a network to which a communication device is connected and a far-end party.   The device of claim 16, wherein the communication device gains connection capability when making a call.   The device according to claim 16, wherein the communication device obtains connection capability from a network via a message service, and the obtained information is stored in the communication device.   The apparatus according to claim 16, wherein the communication apparatus obtains a connection capability when registering with the network and stores the obtained information.   The apparatus of claim 16, wherein the communication device obtains connection capability by inviting a user or operator to manually configure the communication device with connection capability information.   The device further obtains the connection service requested by the user of the communication device, checks whether the connection service is supported by the network during the evaluation of the connection service, and if necessary, the requested service 21. The apparatus according to claim 20, wherein the device is changed based on the obtained connection capability information.   The apparatus of claim 16, wherein the apparatus determines a connection service based on the obtained connection capability information and generates information regarding the determined connection service during the evaluation.   The apparatus of claim 16, wherein the apparatus transmits information regarding the modified connection service in a message to the far end party.   The device according to claim 16, wherein the device is a mobile communication device and the network is a mobile communication network.   The apparatus of claim 16, wherein the apparatus is a fixed communication device and the network is a fixed communication network. The device is
Use connection capacity information to infer the requested service,
Responding to the configuration message by the network with clear service information defining the inferred service;
The apparatus of claim 16. A method of controlling a connection between a network and a communication device and a far end party, wherein the communication device is called by the far end party.
Detecting information on supported connection services generated by the communication device (S31);
Detecting connection related information between the network control element performing the method and the far-end party (S32);
Evaluating whether the detected information and the connection-related information match each other (S33),
A method including the steps of   The method according to claim 30, further comprising the step of overriding (S35) information on the supported connection service generated by the communication device if the two pieces of information do not match.   A network control element for controlling a connection between a network and a communication device and a far end party, wherein the communication device is called by the far end party, further generated by the communication device Detecting information on supported connection services to be detected, detecting connection related information between the network control element and the far-end party, and evaluating whether the detected information and the connection related information match each other. Network control element configured to.   The network control element according to claim 32, wherein the network element further overrides information regarding a supported connection service generated by the communication device if both pieces of information do not match.   The network control element according to claim 32, wherein the network control element is an interworking function (IWF).

Images