MX2008009767A - Method for requesting domain transfer and terminal and server thereof - Google Patents

Method for requesting domain transfer and terminal and server thereof

Info

Publication number
MX2008009767A
MX2008009767A MXMX/A/2008/009767A MX2008009767A MX2008009767A MX 2008009767 A MX2008009767 A MX 2008009767A MX 2008009767 A MX2008009767 A MX 2008009767A MX 2008009767 A MX2008009767 A MX 2008009767A
Authority
MX
Mexico
Prior art keywords
domain transfer
message
domain
information
further characterized
Prior art date
Application number
MXMX/A/2008/009767A
Other languages
Spanish (es)
Inventor
Kyungae Yoon
Jaeseung Song
Hyunsook Kim
Miseon Ra
Hede Patrice
Original Assignee
Hyunsook Kim
Lg Electronics Inc
Hede Patrice
Miseon Ra
Jaeseung Song
Kyungae Yoon
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hyunsook Kim, Lg Electronics Inc, Hede Patrice, Miseon Ra, Jaeseung Song, Kyungae Yoon filed Critical Hyunsook Kim
Publication of MX2008009767A publication Critical patent/MX2008009767A/en

Links

Abstract

A method, terminal and server for controlling a domain transfer operation, are discussed. According to an embodiment, the server includes a receiver to receive a domain transfer request;a controller to evaluate the domain transfer request based on criteria information, to determine whether or not to generate a domain transfer request message based on the evaluation result, and to generate the domain transfer request message based on the determination result;and a transmitter to transmit the domain transfer request message to at least one terminal so as to selectively initiate a domain transfer for a call.

Description

METHOD TO REQUEST TRANSFER OF DOMAIN AND TERMINAL AND SERVER OF THE SAME DESCRIPTIVE MEMORY The present application claims the priority benefits of the provisional application of E.U.A. No. 60 / 765,212 filed on February 6, 2006 and Korean patent applications Nos. 0-2006-0116575 and 10-2006-0135622 filed respectively on November 23, 2006 and December 27, 2006 in the Republic of Korea. The full content of these applications is fully incorporated herein by reference. The present invention relates to a Voice Call Continuity (VCC), and in particular, to request a domain transfer in the VCC. In general, a Voice Call Continuity (VCC) refers to a type of application, especially a local IMS application (IP Multimedia Subsystem) that is capable of transporting voice calls between a CS (Circuit Switched) domain and a IMS domain. The VCC provides functions for voice call origins, voice call terminations, a selection of domains and a transfer of domains from the CS domain to the IMS domain or vice versa. In this case, domain transfer refers to transferring access legs for voice calls to a user equipment (UE) (i.e., a terminal) from the CS domain to the IMS domain or vice versa during an active session. The access section denotes a call control section between a VCC UE and a domain transfer function (DTF) of a VCC application (server). Through the domain transfer procedures, a continuity of service is provided for one or more calls / voice sessions between the IMS domain and the CS domain while the VCC UE maintains one or more calls / voice sessions. Generally, a domain transfer for a certain call / voice session from the CS domain to the IMS domain or vice versa only starts when a DTF is placed in a signal path of the call / voice session configuration. For this, the placement of the DTF in the signal path of the call configuration / voice session is referred to as anchoring in IMS or anchoring. Figure 1 illustrates a general architecture of a network to provide a VCC service. As illustrated in Figure 1, a VCC UE 10 denotes all types of terminals that support the VCC service. The VCC UE can access the CS and PS domains (packet switching). That is, when the CS domain is accessed, the VCC UE uses an UE-CS (not shown) provided therein, while the VCC UE uses a UE-IMS (not shown) provided therein at the time of access the PS domain. A VCC application 30 is an application server to provide the VCC service, and is constituted by entities that perform a series of functions. The series of functions may include functions required to configure voice calls to the VCC UE, and functions required to switch a VCC UE access leg between the CS domain and the IMS domain while maintaining (performing) an active session at the same time . For example, the function series may be a domain transfer function 30a, a domain selection function 30d, a CS 30b adaptation function, and a CAMEL service application 30c. The detailed capabilities and operations for the function series are described in 3GPP TS 23.206 V1.2.0. Generally, the entities of the CS domain include a Visited Mobile Switching Center (VMSC), an Access Gateway MSC (GMSC), a gsmSCF, and the like. The entities of the IMS domain include a P-CSCF, an S-CSCF, an I-CSCF and a Media Access Gate Control Function (MGCF). Figure 2 is a signal flow diagram between each component of a network (e.g., the network shown in Figure 1) in a case where a domain transfer occurs between the IMS domain and the CS domain. In the following, the procedures for domain transfer in a VCC service according to a prior art will be explained with reference to Figure 2. As shown in figure 2, it is only a VCC UE that initiates a domain transfer in a VCC. That is, the VCC UE establishes a voice call (or session) on the CS domain or IMS domain with a network, and can then decide whether or not to initiate a domain transfer when moving (or transferring) from one domain to another domain. By doing this, the established voice call (referred to as "call in progress") may continue towards switching (ie, domain transfer) from the CS domain to the IMS domain or vice versa. Here, to initiate (perform) a domain transfer for the voice call of one domain (for example, IMS domain) to another domain (for example, CS domain) the VCC UE can initiate the domain transfer based on the previously stored information. Here, information previously stored in the VCC UE may include radio conditions of a CS network for access, operator policies, user preferences, and the like. The procedures (1) ~ (4) for initiating a domain transfer from a CS domain to an IMS domain, through the VCC UE, according to the prior art are the following: (1) the VCC UE may decide initiate a domain transfer for a voice call that has been originated and is in progress to the CS domain, especially an outgoing call. (2) When the VCC UE sends an INVITE message (INVITE) to a VCC application, a domain transfer function (DTF) in the VCC application establishes an IMS session leg for the voice call on the IMS domain. (3) After the IMS session span between the DTF and the IMS domain is established, the DTS routes the current session to the IMS domain. (4) After routing the current session to the IMS domain, a session section CS is released. In this way, the domain transfer for the voice call is initiated from the CS domain to the IMS domain through the procedures (1) - (4). For domain transfer in the VCC, only the VCC UE can initiate the domain transfer in the current VCC by taking into account certain criteria (for example, user preferences, operator policies, etc.) - Therefore, according to the prior art, there is no way for the network (eg VCC application) to initiate a domain transfer based on a current state of the network, a data load of a specific node, a QoS (Quality of Service) or the location of the VCC UE. In addition, the network may wish to reduce traffic or stop the flow of traffic in a specific domain over the course of a certain length of time for maintenance or updating of the network. In this case, according to the prior art, there is no method for the network to allow (or request) the VCC UE to initiate domain transfer for a current call in a specific domain (i.e., in the CS domain or IMS domain). Therefore, it is an object of the present invention to request, through a network (for example, VCC application) to a terminal (for example VCC UE) that initiates a domain transfer according to a state of the network or other reasons.
It is another object of the present invention to provide a method and device for requesting a domain transfer, which poses the limitations and disadvantages associated with the prior art. To achieve these and other objects in accordance with the present invention, according to one aspect of the present invention, there is provided a method for requesting that a domain transfer be initiated, comprising: evaluating the domain transfer request information received in a network server; transfer, through the network server, a domain transfer request message to the terminal based on the evaluation of the domain transfer request information; receive and evaluate the domain transfer request message through the terminal; and decide, through the terminal, if the domain transfer for a call is initiated based on the evaluated domain transfer request message. To achieve these and other objects of the present invention, according to another aspect of the present invention, there is provided a terminal (or UE) comprising: a receiver for receiving a domain transfer request message from a network server; a transmitter for sending a reply message with respect to the received domain transfer request message; and a VCC enabler to decide whether or not to initiate a domain transfer for an ongoing call by evaluating the domain transfer request message, and then initiate the domain transfer in accordance with the decision.
To achieve these and other objects of the present invention, according to another aspect of the present invention, a network server is provided which comprises: a receiver for receiving a domain transfer request information and also receiving a reply message transferred by a terminal; an evaluation unit for evaluating the domain transfer request information received when compared to previously stored conditions; a message generator for generating a domain transfer request message based on the evaluated domain transfer request information; and a transmitter for sending the generated domain transfer request message to the terminal. According to another aspect, the present invention provides a terminal for controlling a domain transfer operation, comprising: a receiver for receiving a message from a network server, the message includes information related to domain transfer and a controller to evaluate the information related to domain transfer and at least one of user preferences information and operator policy information, to determine if a domain transfer of a user is initiated. call based on the evaluation result, and selectively start the domain transfer based on the determination result. According to another aspect, the present invention provides a terminal for controlling a voice call continuity operation (VCC) comprising: a receiver for receiving a message from a network server, the message includes information related to domain transfer and a controller to evaluate the message that includes the information related to domain transfer, to determine if a domain transfer of a call is initiated based on the evaluation result, and selectively initiate the domain transfer based on the determination result . According to another aspect, the present invention provides a network device for controlling a domain transfer operation, comprising: a controller for analyzing the domain transfer request information based on criteria information, and generating a message for domain transfer request based on the result of the analysis; and a transmitter for transmitting the domain transfer request message to at least one terminal, for controlling the terminal and selectively initiating a domain transfer of an ongoing call. According to another aspect, the present invention provides a server for controlling a domain transfer operation, comprising: a receiver for receiving a domain transfer request; a controller to evaluate the domain transfer request based on criteria information, to determine whether or not a domain transfer request message is generated based on the evaluation result, and to generate the domain transfer request message based on the result of determination; and a transmitter for transmitting the domain transfer request message to at least one terminal to selectively initiate a domain transfer for a call. According to another aspect, the present invention provides a method for controlling a domain transfer operation comprising: determining, through a network server, whether or not to initiate a domain transfer of a call; generating, through the network server, a message based on the determination result, the message includes a request for a terminal for a domain transfer initiation of a call; and transmitting, through the network server, the message to at least one terminal. According to another aspect, the present invention provides a method for controlling a domain transfer operation, comprising: receiving, through a terminal, a domain transfer request message from a network server, the request message Domain transfer includes information related to domain transfer; evaluate, through the terminal, information related to domain transfer and at least one of user preferences information and operator policy information; determine, through the terminal, whether a domain transfer is initiated in an ongoing call based on the evaluation result; and selectively initiate, through the terminal, the domain transfer of the current call based on the determination result.
These and other objects of the present invention will be more readily apparent from the following detailed description. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are presented only by way of illustration, since various changes and modifications within the spirit and scope of the invention will be apparent to the experts. in the art from this detailed description. The present invention will be better understood from the following detailed description and the accompanying drawings, which are provided by way of illustration only, and therefore do not limit the present invention. Figure 1 is a network architecture for providing a VCC service in which the present invention can be implemented; Figure 2 is a flow diagram of signals between components of a network for domain transfer between an IMS domain and a CS domain according to a prior art; Figure 3 is a signal flow diagram between a UE and a VCC application to illustrate a method for generating and transmitting a domain transfer request according to an embodiment of the present invention; and Figure 4 is a block diagram of a terminal or UE according to an embodiment of the present invention.
The present invention applies to a Voice Call Continuity (VCC) in 3GPP (3rd Generation Partnership Project) but may apply to other communication fields. Substantially in the present invention, first, a network server (eg, a VCC application server) transfers to one or more UEs (ie, terminals) a message that includes information related to a domain transfer request (this information it is also referred to as information related to domain transfer). Information related to domain transfer may include, but is not limited to, one or more of the following: domain transfer level information (one level (or class) information of a domain transfer request), status information of the network (information on a state of the network or the like), evaluation information (information on an evaluation (or analysis) of a related domain transfer request through an external node or internal module of a network server or similar), etc. The message that includes information related to domain transfer may include other information, and may be a message for another purpose. Second, the UE receives the message that includes the information related to domain transfer of the network server, and decides whether to initiate (perform) or not the domain transfer with respect to a call (for example, a call in progress or any subsequent call) based on the information. The UE according to the present invention, decides whether or not to initiate the transfer of domain with respect to calls based on information related to domain transfer alone, or based on the information related to domain transfer with at least one of operator policies and user preferences. However, it is preferred to consider together the policies of the operator, user preferences that the UE itself has as well as information related to domain transfer received. In the following, preferred terms will be defined to describe the present invention. A UE according to the present invention can include all types of terminals that can be used for the VCC service. For example, the UE according to the present invention broadly includes mobile communication terminals (e.g., UE, mobile phones, cell phones, DMB phones, DVB-H phones, PDA, PTT, etc.), digital televisions, GPS navigation, portable gaming machines, MP3, other domestic appliances and the like. User preferences denote information (or parameter) to define information related to a domain selection (or domain transfer) that indicates which domain the UE user prefers to use for calls in progress (for example, incoming or outgoing calls) when the UE (or terminal) is available in both the CS domain and the IMS domain. Operator policies denote information related to network status or network management. The policy of the operator can be updated frequently depending on the state of the network or for the management of the network. The updated operator policy may include information to request a domain transfer for calls in progress (or later calls), or information of a preferred domain through the network for domain transfer. An ongoing call denotes a call in progress between a UE and a VCC application, which includes incoming or outgoing calls. The present invention applies to calls in progress, but is not limited to them and can be applied to subsequent calls. A "V3 interface" used in the present invention, preferably denotes an interface for a mutual information transfer between a UE and a VCC application. For example, interface V3 is shown as 20 in FIG. 1 as an example. The V3 interface can include a Ut interface, and an OMA DM (device management). That is, a transfer of information from the UE to the VCC application can be achieved by using the Ut interface, while a transfer of the VCC application information to the UE can be achieved by using the DM using a DM method. As another example, the interface method V3 may include an unstructured supplementary service data (USSD) method. The Ut interface, the DM method and the USSD method are known in the art. A protocol of the V3 interface can be exemplary an HTTP, which has an XML format.
In the following, the constructions and operations of the preferred embodiments of the present invention with respect to the accompanying drawings will be explained in detail. Figure 3 is a signal flow diagram between a UE 100 and a VCC application 300 for requesting a domain transfer for a call according to an embodiment of the present invention. This method can be implemented in the network architecture of Figure 1 or in another suitable architecture. For example, the UE 100 and the VCC application 200 of FIG. 3 may be respectively the UE 10 and the VCC application 30 of FIG. 1. Referring to FIG. 3, a call is currently in progress (i.e. course) between the UE 100 and the VCC 300 application in the CS domain or in the IMS domain (S1). Here, it is assumed in Figure 3 that the call in progress is in progress in the CS domain. The call in progress can denote a call which has been initiated in the CS domain, but it can also be a call that was initiated in the IMS domain and has been transferred to the CS domain. During the ongoing call in progress between the UE 100 and the VCC 300 application, the VCC 300 application (i.e., a type of network server) receives from an external node (eg, a node that controls the operator's policy, a node that controls mobility management, etc.) a request (or signal, information or the like) to request a transfer of domain from a current domain (for example, the CS domain) to another domain (for example, the IMS domain) ) with respect to a call placed by a specific user (ie, a user of the EU) (S2). As a variation, the VCC application 30 may receive this request from an internal module (for example, 30a, 30b, 30c, 30d, or another in Figure 1) of the VCC 300 application. The domain transfer request made by the network (for example, of the external node or internal module) in step S2 can be elaborated for several reasons, for example, maintenance of the network, traffic load of a specific node in the network, control related to the operator's policy, or Similary. The domain transfer request can be made specifically to request a (single) terminal which is using a certain VCC subscriber, or a certain group (for example, other VCC subscribers) of terminals, or it can be performed non-specifically for request multiple subscribers (for example, terminals used by multiple subscribers). In step S2, as mentioned above, the domain transfer request can not only be transmitted from the network (i.e., the external node) to the VCC 300 application, but can also be performed (triggered) based on a specific internal state of the VCC 300 application. For example, in order to regulate or maintain a traffic with respect to the VCC 300 application, or to perform the operator's policy related to the domain transfer, for example, a certain entity or module (for example, a domain transfer function module, a domain selection module, etc.), provided in the VCC 300 application can transmit a request for domain transfer to a processing unit (for example, a controller ) built in the VCC 300 application to process the domain transfer request signal. When the VCC 300 application receives the network transfer request (or signal) (e.g., the external node) or its internal component (e.g., a certain entity therein), the VCC 300 application performs an analysis or evaluation of the domain transfer request (S3). The information obtained from this evaluation can be referred to as evaluation information, which can be included in the message sent from the VCC application to the EU in S4 that will be discussed later. In step S3, for example, the VCC 300 application evaluates the domain transfer request under a previously defined condition, for example, state of fixation to the terminal radius, type of media of the call in progress, etc. (ie, it verifies whether the requested domain transfer is suitable for the ongoing call of the UE 300 from the VCC application side). Here, the previously defined condition denotes information related to the domain transfer, the information stored in a certain entity provided in the VCC application or a certain external entity. In other words, the VCC 300 application analyzes or evaluates whether or not to generate and / or transmit a message that includes information related to domain transfer to the UE in accordance with the domain transfer request. Here, the domain transfer request may be specific for a terminal that is using a certain subscriber or for terminals that are using a certain group of subscribers. Then in step S4, the message including the information related to domain transfer is sent from the VCC application 300 to one or more UE 100. The domain transfer request includes information of the level of domain transfer, and may also include , at least information on network status and evaluation information. The information related to domain transfer is discussed in more detail below. In step S3, when the VCC 300 application evaluates the domain transfer request, it decides (or evaluates) what level (or class) should be assigned to the domain transfer request and generates the domain transfer level information indicating the level of transfer of domain request. The levels of the domain transfer request, for example, can be classified into the first to third levels (or classes). Examples of these levels (domain transfer level information) may be the following, but the invention is not limited thereto: - A first level of domain transfer request, which is called "will be" (it has to be) , is to request that the domain transfer be (has to be) performed (for example, if not, the call will be disconnected in a short time); - A second level of domain transfer request, which is called "should be" (should preferably be), is to request that the domain transfer request must be made (for example, if not, the call will be at risk). be disconnected due to reduced resources, etc.); and - A third level of domain transfer request, which is termed "requested" (may be), is to request that the domain transfer be made through a UE selection based on a traffic load, for example (for load balancing, but up to the UE). These domain transfer request levels can be represented by using different values of a parameter to indicate the levels of the domain transfer request, using different parameters that correspond to different levels, using a type of indicator, or using other forms. Accordingly, the information related to domain transfer sent from the VCC application 300 to the UE (s) in step S4 includes domain transfer level information indicating a level of domain transfer request, which may be, for example, example, one from the first to the third level discussed above. As a variation, the message sent from the VCC application to UE (s) in step S4 may include a request to initiate a domain transfer, not including the prior domain transfer level information. In addition, one of different messages or dedicated messages corresponding respectively to different levels of the domain transfer request can be sent from the VCC application server to the UE (s). For example, there may be dedicated messages to indicate different levels of a domain transfer request. In addition, there may be other levels of the domain transfer request, for the domain transfer level information. As also mentioned above, the information related to domain transfer (S4) may include associated information regarding the domain transfer request made by the network that the VCC application has evaluated in step S3, and information related to the evaluation . That is, information related to domain transfer may include evaluation information. In addition, the information related to domain transfer may include other information (for example, network status information regarding the state of the network, etc.). Also the information related to domain transfer or the message that includes the information related to domain transfer may be included or combined with a message for another purpose, and / or may share the signaling space with other functionality. In step S4, the VCC application 300 transmits the message that includes the information related to domain transfer to the UE 100, which can occur through a reference point of the application server UE of VCC-VCC ie an interface V3 (for example, V3 interface 20), or using a unicast method. As a variation, the message that includes the information related to domain transfer can be simultaneously sent from the VCC application 300 to a plurality of UE, for example, through a multicast method or a broadcast method. After receiving the message including the information related to domain transfer from the VCC 300 application, the UE 100 (or each UE) evaluates (or analyzes) the information included in the message (S5). The UE 100 then sends a response message (e.g., message Ack) to the VCC application 300 in response to the received message (S6). Here, the response message may include information indicating the decision of the VCC application (and / or UE) with respect to the domain transfer request. For example, the decision of the domain transfer request may indicate an acceptance or rejection of the domain transfer request made by the VCC application. Step S6 can be performed between steps S4 and S5, and it can be an optional step. The UE 100 selectively performs (initiates) a call domain transfer (e.g. call in progress) by taking into account information related to the domain transfer request that has been evaluated in step S5 (S7). Here, when deciding whether or not to initiate the transfer of domain of the call, the UE can take into account, as a factor that affects the decision, the information related to the domain transfer request (ie the information related to domain transfer included in the message, as a first factor) together with other factors that the UE already has content. Examples of other factors may be, but are not limited to, user preferences as a second factor, and operator policy as a third factor. In addition, the priority (level) between these factors (for example, the first, second and third factors) to make the decision about the domain transfer can be defined according to the configuration of a user or the configuration of an operator. For example, if the first and third factors are in conflict with each other (for example, the first factor indicates that the domain transfer must be initiated, while the third factor indicates no), then the UE 100 may decide to follow the first factor according to the configuration. In an example, in step S5, the UE 100 can decide whether or not to initiate a domain transfer for the current call based on information related to domain transfer and at least one of operator policy and user preferences. Meanwhile, the reference point between the UE 100 and the VCC 300 application can be implemented by using interfaces or protocols that have been defined, and can also be implemented when defining new interfaces. For example, the reference point can be implemented by using an IMS-based signaling, or by combining other interfaces. In the previous example of Figure 3, the call is an ongoing call (for example, an outgoing or incoming call), but the invention applies the same to any subsequent call. For example, the UE 100 may receive the information related to domain transfer of the VCC application 300 in S4. Then, UE 100 can store this information and then evaluate it later for a domain transfer of any subsequent call, as desired. Next, constructions and operations of the UE 100 (ie, a terminal) and the VCC application 300 (i.e., VCC application server) according to one embodiment of the present invention. The UE 100 according to the present invention can include a primary hardware construction that is required to process a message that includes information related to domain transfer. For example, as shown in Figure 4, the UE 100 according to the present invention comprises a receiver 43 adapted to receive a domain transfer request message (or a message) that includes information (information related to domain transfer). ) related to the application domain transfer request, a transmitter 41 adapted to send (transmit) a response message (e.g., Ack message) with respect to the received domain transfer request message, a memory or unit of storage 42 for storing information related to received domain transfer and other information such as operator policy, user preferences, etc., and a VCC enabler 46 adapted to evaluate (or analyze) information related to domain transfer included in the domain transfer request message (and any other information as desired) to decide if the transfer The domain nsference of an ongoing call must or should not be initiated (performed), to add (or include) information obtained by means of the decision (for example, acceptance or rejection) to the response message, and to selectively attempt to initiate the transfer of domain according to the decision. Here, the VCC enable 46 can be a controller as a type of control unit to analyze the information related to domain transfer in order to attempt the initiation of the domain transfer. The UE 100 may also include other components such as a Ut 47 interface unit, a DM 48 unit, an input unit 44, and a display unit 45. All the components of the UE 100 are operatively coupled. As mentioned above, the operations and functions of each component of the UE including technical features of the present invention have been explained. In addition, other basic components of the UE for receiving a VCC service are obvious to those skilled in the art, and therefore its explanation is omitted. The VCC application 300 in accordance with the present invention comprises a receiver for receiving a domain transfer request (transfer request information) from a network (eg, an external node) due to a change in operator policy with respect to the domain transfer in accordance with the state of the network or for network maintenance or for some other reason, and receive a reply message (ie, message Ack) transferred from UE 100, an evaluation unit to evaluate (or analyze) the domain transfer request received to! compare it with previously stored conditions, a message generator to generate a message that includes information related to domain transfer based on the evaluated domain transfer request, and a transmitter to send the generated message to the UE 100. Here, because the message that includes the information related to domain transfer is generated by the evaluation unit and the message generator for the purpose of requesting domain transfer, the evaluation unit and the message generator can be implemented as a type of controller which is capable of performing the combined functions of both the evaluation unit and the message generator. The present invention has been explained with reference to modalities illustrated in the drawings, which, however, are merely exemplary. It will also be apparent to those skilled in the art that various modifications and variations may be made to the present invention without departing from the spirit or scope thereof. In this way, it is intended that the present invention encompass modifications and variations of this invention as long as they fall within the scope of the appended claims and their equivalents. As described above, the present invention is advantageous because it allows the network server (eg, the VCC application) to request domain transfer from the UE according to the state of the network or if necessary. In addition, the present invention allows the network server to provide the UE with the relevant information (information related to domain transfer) necessary for the UE to make an adequate informed decision about whether or not to initiate the domain transfer for its call. In addition, the present invention allows the network server to request the transfer of domain from the UE in accordance with the state of the network or for maintenance of the network. Accordingly, the UE does not initiate domain transfer for calls unnecessarily and can only initiate domain transfer when the network can perform / complete the domain transfer. As a result, the present invention can effectively prevent the deterioration of Quality of Service (QoS) or the waste of radio or signaling resources.

Claims (36)

NOVELTY OF THE INVENTION CLAIMS
1. - A terminal for controlling a domain transfer operation, comprising: a receiver for receiving a message from a network server, the message includes information related to domain transfer; and a controller for evaluating information related to domain transfer and at least one of user preference information and operator policy information, to determine whether to initiate a domain transfer of a call based on the evaluation result, and selectively start the domain transfer based on the determination result.
2. - The terminal according to claim 1, further characterized in that the call is a call in progress or any subsequent call that originates after receiving the message.
3. - The terminal according to claim 1, further characterized in that the information related to domain transfer includes domain transfer level information indicating a level of a domain transfer request.
4. The terminal according to claim 3, further characterized in that the level of the domain transfer request is one of the following: a first level indicating that the domain transfer has to be performed; a second level that indicates that the domain transfer should preferably be carried out; and a third level which indicates that the domain transfer can be performed.
5. - The terminal according to claim 3, further characterized in that the controller determines whether to initiate the domain transfer when evaluating the domain transfer level information, the user's preference information and the operator's policy information.
6. - The terminal according to claim 1, further characterized in that the receiver receives the message from the network server through a V3 interface, a unicast method, a broadcast method, or a multicast method.
7. - The terminal according to claim 3, further characterized in that the information related to domain transfer additionally includes at least one of network status information and evaluation information on an evaluation of a domain transfer request by part of the network server.
8. - The terminal according to claim 1, further characterized in that it additionally comprises: a transmitter for transmitting a response message from the network server in response to the message.
9. - The terminal according to claim 1, further characterized in that the receiver receives e! message as part of a message for another purpose.
10. - A terminal for controlling a voice call continuity operation (VCC), comprising: a receiver for receiving a message from a network server, the message includes information related to domain transfer, a controller for evaluating the message which includes information related to domain transfer to determine whether to initiate a domain transfer of a call based on the evaluation result, and to selectively initiate domain transfer based on the determination result.
11. - The terminal according to claim 10, further characterized in that the call is a call in progress or any subsequent call that originates after receiving the message.
12. The terminal according to claim 10, further characterized in that the information related to domain transfer includes a request for a domain transfer.
13. The terminal according to claim 10, further characterized in that the message additionally includes status information of the network and evaluation information on an evaluation of a domain transfer request made by a network server evaluator., and the controller determines whether to initiate the domain transfer when evaluating information related to domain transfer, network status information, and evaluation information.
14. - The terminal according to claim 10, further characterized in that the receiver receives the message as part of a message for another purpose.
15. - A network device for controlling a domain transfer operation, comprising: a controller for analyzing domain transfer request information based on criteria information and generating a domain transfer request message based on the The result of the analysis, and a transmitter for transmitting the domain transfer request message to at least one terminal, controlling the terminal and selectively initiating a domain transfer of an ongoing call.
16. - The network device according to claim 15, further characterized in that the network device is a voice call continuity application server (VCC).
17. - The network device according to claim 15, further characterized in that the domain transfer request message includes information related to domain transfer indicating one of the following: domain transfer has to be performed; the domain transfer should preferably be performed; and the domain transfer can be made.
18. - The network device according to claim 15, further characterized in that the transmitter transmits the domain transfer request message to a plurality of terminals simultaneously.
19.- The network device in accordance with the claim 15, further characterized in that the transmitter transmits the domain transfer request message to a plurality of terminals using a multicast method or a broadcast method.
20. - The network device according to claim 15, further characterized in that the transmitter transmits the domain transfer request message to a terminal through a V3 interface or a unicast method.
21. - A server for controlling a domain transfer operation, comprising: a receiver for receiving a domain transfer request; a controller to evaluate the domain transfer request based on criteria information, to determine whether or not to generate a domain transfer request message based on the evaluation result, and to generate the domain transfer request message with base on the result of determination; and a transmitter for transmitting the domain transfer request message to at least one terminal to selectively initiate a domain transfer for a call.
22. - The server according to claim 21, further characterized in that the receiver receives the request for domain transfer from an external node or an internal module of the server.
23. - The server according to claim 21, further characterized in that the domain transfer request message includes information related to domain transfer indicating one of the following: the domain transfer has to be performed; the domain transfer should preferably be performed; and the domain transfer can be made.
24. The server according to claim 21, further characterized in that the domain transfer request message additionally includes information on the status of the network and evaluation information on the evaluation of the domain transfer request made by the controller.
25. A method for controlling a domain transfer operation, comprising: determining, through a network server, whether or not a start of a domain transfer of a call is requested; generating, through the network server, a message based on the result of determination, the message includes a request to a terminal for a start of a domain transfer of a call; and transmitting, through the network server, the message to at least one terminal.
The method according to claim 25, further characterized in that the determination step includes: receiving a domain transfer request from an external node or an internal module of the network server; analyze the domain transfer request received based on criteria information; and decide if the start of the domain transfer will be requested based on the result analyzed.
27. The method according to claim 25, further characterized in that the message includes information related to domain transfer indicating one of the following: the domain transfer has to be performed; the domain transfer should preferably be performed; and the domain transfer can be made.
28. The method according to claim 27, further characterized in that the message additionally includes information on network status and evaluation information on the analysis performed in the analysis step.
29. The method according to claim 25, further characterized in that the transmission step transmits the message to a plurality of terminals using a multicast method or a diffusion method.
30. - The method according to claim 25, further characterized in that the transmission step transmits the message to a terminal via a V3 interface or a unicast method.
31. - A method for controlling a domain transfer operation, comprising: receiving, through a terminal, a domain transfer request message from a network server, the domain transfer request message includes related information with domain transfer; evaluate, through the terminal, information related to domain transfer and at least one of user preferences information and operator policy information; determine, through the terminal, whether a domain transfer of an ongoing call is initiated based on the evaluation result; and selectively initiate, through the terminal, the domain transfer of the current call based on the determination result.
32. The method according to claim 31, further characterized in that the information related to domain transfer includes domain transfer level information indicating a level of a domain transfer request. 33. - The method according to claim 32, further characterized in that the level of the domain transfer request is one of the following: a first level indicating that the domain transfer has to be performed; a second level that indicates that the domain transfer should preferably be carried out; and a third level which indicates that the domain transfer can be performed. 34. - The method according to claim 32, further characterized in that the controller determines whether to initiate the domain transfer when evaluating the domain transfer level information, the user's preference information and the operator's policy information. 35. - The method according to claim 31, further characterized in that the receiver receives the domain transfer message from the network server through a V3 interface or a unicast method. 36. - The method according to claim 31, further characterized in that the information related to domain transfer additionally includes at least one of status information of the network and evaluation information on an evaluation of a domain transfer request made by the network server.
MXMX/A/2008/009767A 2006-02-06 2008-07-29 Method for requesting domain transfer and terminal and server thereof MX2008009767A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US60/765,212 2006-02-06
KR1020060116575 2006-11-23
KR1020060135622 2006-12-27

Publications (1)

Publication Number Publication Date
MX2008009767A true MX2008009767A (en) 2008-10-03

Family

ID=

Similar Documents

Publication Publication Date Title
US8670413B2 (en) Method for requesting domain transfer and terminal and server thereof
US8953586B2 (en) Method for placing call in voice call continuity and terminal and server thereof
US7940783B2 (en) Method and terminal for restriction of domain transfer
US7912041B2 (en) Method for controlling VCC functions in VCC initiated by terminal and terminal and network server thereof
EP2078360B1 (en) Session transfer method and method for supporting session continuity
US20070217354A1 (en) System and method for controlling VCC functionality in a network environment including IMS
US8908634B2 (en) Method for controlling VCC functions initiated by network and terminal and network server thereof
JP2007251950A (en) System and method for controlling vcc function in network environment included with ims
MX2008009767A (en) Method for requesting domain transfer and terminal and server thereof
MX2008009766A (en) Method and terminal for restriction of domain transfer