Dynamic selection of interworking functions in a communication system
Abstract
THE INVENTION PROVIDES TECHNIQUES FOR THE SELECTION, ON A DYNAMIC BASE, OF A NETWORK INTERCONNECTION FUNCTION (IWF) THAT CAN MODIFY A COMMUNICATIONS PROTOCOL IN A PARTICULAR FORMAT REQUIRED FOR THE TERMINAL EQUIPMENT SET UP IN A COMMUNICATIONS SYSTEM. THE FUNCTION (IWF) CAN BE SELECTED TO ENSURE COMPATIBILITY BETWEEN THE TRANSMISSION BANDWIDTH, CODIFICATION AND OTHER PARAMETERS OF A CALL, AND THE CORRESPONDING PARAMETERS OF YOUR DESTINATION TERMINAL IN THE SYSTEM. AN IWF IN ACCORDANCE WITH THE INVENTION MAY BE USED TO ALLOW A USER TO JOIN DIFFERENT TERMINALS THAT HAVE DIFFERENT CAPABILITIES THROUGH THE DURATION OF A CALLED GIVEN. THE IWF CAN ALSO BE USED TO INSERT ADDITIONAL DATA, RECOVERED FROM A CENTRAL DATABASE, IN A REVERSE PART OF THE CALL DIRECTED FROM THE DESTINATION TERMINAL TO THE ORIGIN TERMINAL. THE INVENTION MAY BE USED SO TO ENSURE THAT THE BANDWIDTH ESTABLISHED BETWEEN THE DESTINATION TERMINAL AND THE ORIGIN TERMINAL IS SUBSTANTIALLY SYNTHRICAL BIDIRECTIONALLY.

Term
Term ended
Projected expiry passed 16 February 2019, 7.6 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
15 claims: 2 independent, 13 dependent
- 1ES 2 296 367 T3 REIVINDICACIONES 1. Un método para procesar una llamada recibida en un conmutador (110) de un sistema (100) de comunicación, caracterizado el método por las etapas de:identificar un parámetro de la llamada;recuperar información previamente almacenada con respecto a un parámetro correspondiente de un terminal (122, 123, 125, 126 ó 127) de destino de la llamada, determinándose el terminal de destino basándose en una asociación establecida en el conmutador de manera dinámica entre el terminal de destino y al menos un otro terminal (122, 123, 125, 126 ó 127) del sistema;y procesar la llamada según al menos una función de interconexión seleccionada de un conjunto de funciones de interconexión implementadas en el conmutador, en el que la función de interconexión seleccionada está operativa para proporcionar compatibilidad entre el parámetro de la llamada y el parámetro correspondiente del terminal de destino.
- 2El método según la reivindicación 1, en el que la etapa de procesamiento incluye insertar un transcodificador que implementa la función de interconexión entre una entrada que recibe la llamada y el terminal de destino.
- 3El método según la reivindicación 1, en el que la llamada se mueve desde el terminal de destino hasta al menos un otro terminal del sistema durante la llamada, y la etapa de procesamiento incluye además la etapa de procesar la llamada utilizando una primera función de interconexión para proporcionar compatibilidad con el terminal de destino y una segunda función de interconexión para proporcionar compatibilidad con el otro terminal del sistema.
- 4El método según la reivindicación 1, en el que la etapa de procesamiento incluye la etapa de insertar datos adicionales, para la presentación de una manera perceptible para el usuario en un terminal fuente de la llamada, recuperándose los datos adicionales de una base de datos del conmutador, en una parte inversa de la llamada dirigida desde el terminal de destino hasta el terminal fuente de la llamada.
- 5El método según la reivindicación 1, en el que la llamada es una videollamada que incluye un flujo de transporte, y la etapa de procesamiento incluye además:extraer muestras de voz del flujo de transporte;transcodificar las muestras de voz para hacer coincidir uno o más parámetros del terminal de destino;y entregar las muestras de voz al terminal de destino.
- 6El método según la reivindicación 5, que incluye además la etapa de insertar datos de vídeo adicionales, recuperados de una base de datos del conmutador, en un flujo de transporte dirigido, en una parte inversa de la llamada, desde el terminal de destino hasta un terminal fuente de la llamada, de manera que el ancho de banda establecido entre el terminal de destino y el terminal fuente es sustancialmente simétrico de manera bidireccional.
- 7Un aparato para procesar una llamada en un conmutador (110) de un sistema (100) de comunicación, caracterizado por:un procesador (115) que implementa al menos una función de interconexión seleccionada de un conjunto de funciones de interconexión implementadas en el conmutador, en el que la función de interconexión seleccionada está operativa para proporcionar compatibilidad entre un parámetro de la llamada y un parámetro correspondiente de un terminal (122, 123, 125, 126 ó 127) de destino de la llamada, determinándose el terminal de destino basándose en una asociación establecida en el conmutador de manera dinámica entre el terminal de destino y al menos un otro terminal (122, 123, 125, 126 y 127) del sistema;y una memoria (116) para almacenar información con respecto al parámetro correspondiente del terminal de destino.
- 8Un aparato según la reivindicación 7, en el que el parámetro de la llamada es un tipo de servicio asociado con la llamada, o es un ancho de banda utilizado por la llamada, o es un flujo de transporte característico de la llamada, o es una técnica de codificación de voz utilizada en la llamada.
- 9El aparato según la reivindicación 7, en el que el procesador incluye un transcodificador que implementa la función de interconexión, en el que el transcodificador está insertado entre una entrada del conmutador que recibe la llamada y el terminal de destino.
- 10Un aparato según la reivindicación 9, en el que la llamada es una llamada de voz y el transcodificador es un transcodificador ADPCM a PCM para interconectar la llamada de voz. ES 2 296 367 T3
- 11El aparato según la reivindicación 7, en el que la llamada se mueve desde el terminal de destino hasta al menos un otro terminal del sistema durante la llamada, y el procesador está operativo además para procesar la llamada utilizando una primera función de interconexión para proporcionar compatibilidad con el terminal de destino y una segunda función de interconexión para proporcionar compatibilidad con el otro terminal del sistema.
- 12El aparato según la reivindicación 7, en el que el procesador está operativo además para insertar datos adicionales, recuperados de una base de datos del conmutador, en una parte inversa de la llamada dirigida desde el terminal de destino hasta un terminal fuente de la llamada.
- 13Un aparato según la reivindicación 12, en el que la llamada es una videollamada, el terminal de destino es un terminal sin capacidad para generar vídeo, y los datos adicionales son datos de vídeo recuperados de la base de datos e insertados en una señal entregada desde la terminal de destino a la estación fuente como parte de la parte inversa de la llamada.
- 14El aparato según la reivindicación 7, en el que la llamada es un videollamada que incluye un flujo de transporte, y el procesador está operativo además para extraer muestras de voz del flujo de transporte, para transcodificar las muestras de voz para hacer coincidir uno o más parámetros del terminal de destino, y para entregar las muestras de voz al terminal de destino.
- 15El aparato según la reivindicación 14, en el que el procesador está operativo además para insertar datos de vídeo adicionales, recuperados de una base de datos del conmutador, en un flujo de transporte que está dirigido, en una parte inversa de la llamada, desde el terminal de destino hasta un terminal fuente de la llamada, de manera que el ancho de banda establecido entre el terminal de destino y el terminal fuente es sustancialmente simétrico de manera bidireccional.
Independent claims15
131 paragraphs in 16 sections, as filed
ES 2 296 367 T3
DESCRIPTION
Dynamic selection of interconnection functions in a communication system.
Related requests
The present application is related to US Patent Nos. 6,295,456 and 6,195,545.
Field of the invention
The invention relates generally to communication systems, and more particularly to commercial communication systems in which calls and other incoming communications are directed via a switch to desksets, wireless mobile phones, or other types of terminals. user within the system.
Background of the invention
A typical business communication system includes a business switch that routes calls from one or more incoming trunk lines to multiple user terminals. User terminals can include, for example, wired desk phones, cordless desk phones, wireless mobile phones, and advanced terminals such as computers or video phones. A shared communication facility within such a system is generally represented both at the switch and at the corresponding terminals as a "Call Appearance" (CA, Call Appearance). When a CA is presented for a shared feature on multiple user terminals, and multiple users are allowed to access this feature, the CA is known as a “bridged appearance”. In existing systems, such bridged occurrences can generally only be defined at system administration time, for example, during an initial system setup and configuration or during a later system level reconfiguration. As a result, conventional bridged appearances remain static until the system is managed again. This conventional static architecture is generally considered the most suitable for wired terminals, where the expectation of operation is that the user associated with a given terminal will be at their desk, and will be the primary or exclusive user of that terminal.
Document EP 0744853 discloses the use of ISDN terminals.
However, in systems that support wireless terminals and other more advanced equipment, users will normally have more than one terminal available to them, and they may also be allowed to use the advanced equipment on request. For example, a given set of users may each have a wired desk phone, a simple mobile phone, and random request access to an advanced share such as a video phone. Unfortunately, the conventional static bridging techniques cited above cannot create a dynamic bridged appearance that exists, for example, both on a given user's mobile phone and an advanced share that is located near the mobile phone at a particular time. Therefore, conventional techniques do not generally provide the user with an option to answer an incoming call directed to the mobile phone at an advanced terminal located in the same location, unless the advanced terminal has bridged the mobile phone during the call. system administration. As a result, the user will often not be able to access the more sophisticated features of a nearby advanced terminal to accept calls directed to the mobile, or make calls as a known sender.
Summary of the invention
According to one aspect of the invention there is provided a method according to claim 1. According to a further aspect of the invention there is provided an apparatus according to claim 7.
This invention provides a system in which users can associate with a system terminal on demand by creating a bridged call appearance that exists, for example, in both a simple mobile phone and a complex terminal located in the same location such as a videophone. Therefore, the invention allows the creation of bridged call appearances on dynamic request. In an illustrative embodiment, a temporary association is established between a mobile terminal and at least one other terminal in the system. Although the mobile terminal "registers" in this way to the other terminal, the user of the mobile may request permission to use the functions of the other terminal to, for example, receive incoming calls or make outgoing calls. The temporal association can be established based on a determination of the proximity of the mobile terminal to the other terminal, such that the mobile registers with other complex and different system terminals as it moves between different cells of the system. Therefore, the temporal relationship between the mobile and a given other terminal can be terminated when the mobile is no longer close to that terminal. Proximity-based registration according to the invention may also be implemented in an embodiment in which the proximity of a given user to a terminal of the system is determined by detecting a signal transmitted by a beacon device carried by the user.
The dynamic binding and bridging of the invention can be implemented using state-based processing. In an example of this type of implementation, the mobile, at any given time, may be in one of a number of operational states, such as the following five states: (1) a null state in which there is no association
ES 2 296 367 T3 temporary between the mobile and any other terminal in the system; (2) a registered state in which the temporary association is established, but the mobile user has not obtained permission to access the functions of the other terminal; (3) a linked active state in which the temporary association exists and the user is actively accessing the functions of the other terminal to place an outgoing call; (4) a linked idle state in which the temporary association exists and the user has obtained permission to access the functions of the other terminal, but is not currently accessing the functions; and (5) a linked paging state in which the temporary association exists, the user has obtained permission to access the functions of the other terminal, and an incoming call directed to the mobile generates a paging indication at the other terminal.
Another embodiment of the invention provides techniques for dynamically selecting an Interworking Function (IWF) that can modify a communication protocol to the particular format required by the bridged terminal equipment. This allows a user to link different terminals that have different capabilities for the duration of a given call. For example, if the source terminal of the incoming call is a cordless desk phone using 32 kbps voice encryption and the destination terminal uses a 64 kbps DS0 line, the IWF may be an ADPCM to PCM transcoder. An IWF according to the invention can also be used to insert additional data, retrieved from a switch database, in a reverse part of the call directed from the destination terminal to the source terminal. For example, if the call is a video call, and the destination terminal is a terminal without the ability to generate video, the original data may be video data retrieved from the database and inserted into a signal delivered from the destination terminal to the source terminal. This aspect of the invention can be used to ensure that the bandwidth established between the destination terminal and the source terminal is substantially symmetric in a bidirectional manner.
Another aspect of the invention relates to superimposing the characteristics of a particular system terminal on another terminal to which the user is linked. For example, when a given user enters any of the linked states cited above, the previously stored permission data for that user can be overlaid on the linked terminal so that the user can make or receive all calls based on their usual restrictions, using the linked terminal. In an illustrative embodiment, a given system user may have multiple stored terminal profiles, one for each type of system terminal that that user can access. When the user becomes linked to a particular system terminal, the corresponding stored terminal profile of that user is overlaid on the linked terminal. For example, if the linked terminal is of the same type as a user-assigned terminal, the functional layout of the assigned terminal, including button assignments and softkey label arrangements, can be superimposed on the linked terminal such that the linked terminal overlaps. configured to function in a similar way to the assigned terminal.
These and other features and advantages of the present invention will be more apparent from the accompanying drawings and the following detailed description.
Brief description of the drawings
Figure 1 shows a part of an exemplary communication system configured according to the invention.
Figure 2 is a state diagram illustrating the operation of dynamic linking and bridging functions in the system of Figure 1.
Figures 3-12 are flowcharts illustrating in greater detail the operation of the state transitions shown in the state diagram of Figure 2.
Detailed description of the invention
The invention will now be illustrated in conjunction with an exemplary wireless communication system. Although particularly well suited for use in conjunction with a commercial telephone system, the invention is not limited to use with any particular type of system. The disclosed binding and bridging techniques can be used in any communication application where it is desirable to provide users with improved access to additional system terminals in an efficient manner. For example, the invention can be applied to handsets for use in personal communication services (PCS) and cellular systems, and to other types of communication devices. Therefore, the term "mobile" as used herein should be understood to include not only portable wireless handsets as in the illustrative embodiment but also other types of portable communication devices, including wireless personal computers. The term "line" as used herein is intended to include not only telephone lines but more generally any type of communication channel that provides calls or other communications for processing at one or more user terminals. The term "system administration" or "system administration time" generally refers to a reconfiguration of the system, which involves altering operating parameters for two or more system terminals, and is intended to include, for example, a setting and initial system configuration or a later system level reconfiguration. The term "dynamic" as applied to establishing an association between a first user terminal and at least one other terminal in the system generally refers to an association that is established at a time other than during system administration. A "temporary association" is intended to include
ES 2 296 367 T3 any association that is established dynamically as opposed to an association established during system administration.
FIG. 1 shows a portion of an exemplary communication system 100 in accordance with an illustrative embodiment of the invention. System 100 includes an enterprise switch 110 that receives a trunk line 114 as input. Trunk line 114 supplies incoming calls to switch 110 for processing. The switch 110 includes a Central Processing Unit (CPU) 115, a memory 116, at least one interconnect function (IWF) 117, and a system database 118. CPU 115 may be a microprocessor, Application Specific Integrated Circuit (ASIC), or other type of digital data processor, as well as various parts or combinations of such elements. Memory 116 can be Random Access Memory (RAM), Read Only Memory (ROM), or combinations of these and other types of electronic memory devices. The IWF 117 is used to provide dynamic bridging and bonding features that will be described in more detail later. The IWF 117 may be incorporated in other embodiments in other elements of the switch 110, such as the CPU 115 and memory 116. The system database 118 is used to store bridging and other administrative information regarding the configuration of the system 100.
Switch 110 further includes four port cards 120A, 120B, 120C, and 120D in this example. The port card 120A is coupled to a wireless base station 121 that communicates with a simple Wireless Terminal (WT) 122 designated as WT1 and with a more complex wireless terminal 123 designated as WT2. Terminal WT1 can be a simple mobile phone, and terminal WT2 can be a cordless desk phone. Port 120B is connected to a National Information Infrastructure (NII) wireless base station 124, which communicates with a Wireless Personal Computer (WPC) 125. The port card 120C is connected to a wired desk phone 126 (DS, Deskset). The 120D card is connected to an advanced terminal 127 (AT, Advanced Terminal), which can be, for example, a videophone operating according to the H.320 standard. It should be noted that switch 110 may include additional port cards, and may be connected to other types and arrangements of user terminals. The switch 110 is also connected to a manager terminal 128 that can be used to program the operation of the switch 110 during a system administration.
Figure 2 shows a state diagram illustrating dynamic linking and bridging functions that may be provided in the system 100 of Figure 1 in accordance with the invention. In this embodiment, it will be assumed that the state diagram shows the possible states for a mobile terminal of the system 100, such as the terminal WT1 or the WPC. The mobile terminal will also be referred to simply as a "mobile" in the following description. It will be apparent to those skilled in the art that state diagrams similar to that of Figure 2 can be generated for other types of terminals in the system. State diagram operations may be implemented, for example, in the form of one or more system software programs stored in memory 116 of switch 110 and executed by CPU 115. Such software will be referred to herein as "System software" or "switch software". The state diagram of Figure 2 in this embodiment includes the following five states; Void (210), Registered (220), Linked Inactive (230), Linked Active (240) and Linked Notice (250). A given mobile terminal begins in the Null state, and depending on user input and other system parameters and conditions, it may pass through one or more of the other states. Possible state transitions are shown with arrows connecting the states in the state diagram. Figures 3-12 below illustrate the state transitions in greater detail. Each of the state transitions is listed in Figure 2, and that number appears later in the heading of the corresponding transition description. Unless otherwise specified, the description in Figures 3-12 will be of an embodiment in which a mobile is linked to a desk phone. However, it should be understood that the invention is not limited to such embodiments, but may instead be used to provide dynamic linking between a mobile and any other type of communication terminal or terminals.
The state transitions in Figure 2 make use of the information in the following tables. These tables can be stored, for example, in the database 118 of the switch 110. In the tables, all items marked with a "*" are status information items that are dynamically populated during bind and bridging operations. All other items are static and are populated during system administration.
ES 2 296 367 T3
TABLE 1
User profile table
<td>ID of User (UID)</td><td>Number of directory (DN)</td><td>Guy Terminal</td><td>Assignments BID FID buttons</td><td>TID Local</td><td>TID of Desk Phone</td><td>Attributes (eg, timer)</td>
<td>epf</td><td> (732)957-1234</td><td>WT</td><td>B1 CA B2 CA</td><td> 2</td><td> 5</td><td>Tl = 120</td>
<td>adb</td><td> (732)957-5678</td><td>WT</td><td>B1 CA B2 CA</td><td> 4</td><td> 5</td><td>Tl = 120</td>
<td>writing thorium</td><td> (732)957-9101</td><td> 7434</td><td>B1 LWC B2 CF</td><td> 5</td><td>NULL</td><td></td>
<td>epf</td><td>NULL</td><td>BT</td><td>Null</td><td> 2</td><td>NULL</td><td></td>
The User Profile Table lists information that characterizes the current system configuration for each user on the system. Each user is identified by a User Identifier (UID). A given UID is associated with a corresponding Directory Number (DN), a Terminal Type, Button Assignments, a Local Terminal Identifier (TID, Terminal Identifier), a Desk Phone TID, and various Attributes. The DN represents the primary number dialed by the callers to connect to the corresponding user. The Terminal Type specifies with what type of terminal (for example, mobile terminal (WT1), wireless desk phone (WT2), wireless personal computer (WPC), wired desk phone (such as a type of 7434 wired desk phone) from Lucent Technologies Inc.), etc.) is equipped by the user. The Button Assignments include a Button Identifier (BID) and the corresponding Function Identifier (FID) for each of a number of programmable buttons on the operator terminal. For example, the BID B1 for the UID “epf” in the User Profile Table is set for a call appearance function (CA), and the BID B2 for the UID “desktop” is set to provide a forwarding function. Call Forwarding (CF). The FID designation LWC (Leave-Word Calling) corresponds to a callback function. The Local TID identifies the terminal that is considered the "local" terminal for the user. This can be, for example, the desk phone in the user's office. The desk phone TID identifies a desk phone terminal to which a user is linked, and therefore varies as the user links to different terminals in the system. The Attributes can include, for example, a timer T1 that is specified in the system administration time and indicates how long the user can remain linked to a particular terminal without receiving or making a call on it.
TABLE 2
Permission table
<img file="ES2296367T3_D0001.tif" />
The Permission Table stores information that allows the system to authenticate users who are trying to access system functions. The Class of Restriction (COR) corresponds to a definition of a user authorization to make and receive calls. In the example above, the passwords are stored in the Password Authentication field for each of the “epf” and “adb” UIDs. The "desktop" UID does not require any user identification, that is, any user is allowed to make a call or perform functions from that terminal. Your Password Authentication field is therefore NULL in Table 2. All information in the Permissions Table is entered in the system administration.
ES 2 296 367 T3
TABLE 3
Terminal Profile Table
<td>TID</td><td>Terminal Type</td><td>Port ID *</td><td>Link Status *</td>
<td> 2</td><td>WT</td><td>Oxla</td><td>LINKED ASSETS</td>
<td> 4</td><td>WT</td><td>Oxlb</td><td>REGISTERED</td>
<td> 5</td><td> 7434</td><td>0x2a</td><td>LINKED ASSETS</td>
<td> 6</td><td>BT</td><td>0x2b</td><td>NULL</td>
The Terminal Profile Table stores information regarding Terminal Type, Port Identifier (Port ID), and Binding Status for each of a number of terminals. Terminals are identified by TID. The Port ID identifies, for example, the port card and the line on which the corresponding terminal communicates with the switch 110. The Binding Status entry specifies whether the terminal is in the Linked Active, Linked Inactive, Linked Notice, Registered, or Null state. For example, the terminal with TID 2 in Table 3 is a wireless terminal that is currently communicating on Port 0x1a and is in the 240 Active Linked state. Both the Port ID and the Binding Status change dynamically as different users bind to the terminal, while the Terminal Type for the terminal is set in the system administration.
TABLE 4
Port capacity table
<td>Port ID</td><td>Physical location (slot / port)</td><td>Cell ID (proximity)</td>
<td>Oxla</td><td> 5</td><td> 12</td>
<td>Oxlb</td><td> 6</td><td> 12</td>
<td>0x2a</td><td> 7</td><td> 12</td>
<td>0x2b</td><td> 8</td><td> 12</td>
The Port Capacity Table lists the Physical Location for each of the possible Port IDs in the system. The Physical Location can include, for example, slot and port identifiers for the corresponding Port IDs. A Cell Identifier (Cell ID) is also included for each of the Port IDs. The Cell ID specifies which cell in a system 100 radio subsystem includes the terminal that is communicating on the specified Port ID. For non-mobile terminals, the Cell ID can be filled in at system administration time, if applicable. The radio subsystem is used to implement "proximity-based" dynamic binding as will be described later in conjunction with Figures 3 and 4. Proximity-based binding allows a user with a simple mobile terminal to link to a more complex terminal that is located in the same proximity. The correspondence between Cell IDs / Port IDs and TIDs can change when, for example, mobile terminals move within the system.
TABLE 5
Link table
<td>UID *</td><td>TID Visitor *</td><td>On / Off Timer *</td>
<td>epf</td><td> 5</td><td>switched on</td>
<td></td><td></td><td></td>
The Binding Table specifies information regarding which users are linked to which terminals, as well as characteristics of the binding. In the above example, the user with UID “epf” is linked to the terminal with TID 5. The Timer for Binding, which as noted above can specify the amount of time that the user can remain linked to the terminal but idle, turns on . The entries in this table vary dynamically as different users link to different terminals in the system.
ES 2 296 367 T3
TABLE 6
Link group definition table
<td>Desk Phone TID</td><td>UID of Mobile phones</td><td>UID Registered *</td><td>Linked UID *</td>
<td> 5</td><td>epf, adb</td><td>epf, adb</td><td>epf</td>
The Link Groups Definition Table specifies the users that are registered and / or linked to a particular terminal in the system. The Mobile UID column represents a pre-managed list of mobile terminal users who are allowed to bind to a given desk phone TID. In the example shown in the table, users with the UIDs “epf” and “adb” are in the previously managed list and are allowed to bind to the desk phone terminal with TID 5. This document refers to the group of users who are registered to bind to a given terminal at a particular point in time as the "binding group" for the given terminal. Those users are listed in the Registered UID column for that terminal. In the example, users with the UIDs "epf" and "adb" are also registered to bind to the desk phone terminal with TID 5. One of the users in the bind group may currently be linked to the terminal on an outgoing call. This user is listed in the Linked UID column for that terminal. In general, only one user is allowed to link to a given terminal at a time, but multiple users can register to link to that terminal.
According to the invention, the binding groups can be created at system administration time, or by the user invoking a designated Feature Access Code (FAC), or by a combination of both of these techniques. At system administration time, the administrator can assign known individuals to groups, and then relate the groups to either designated terminals or designated terminal groups. This information may be stored in the system database 118 of switch 110 for use during normal system operation. Alternatively, certain users may be authorized to access the system database 118 during system operation and dynamically add or remove members to or from the Linkage Group Definition Table in the system database. These authorized users could be identified at the time of system administration, or they could be provided with an authorization code. Such a code entry would allow the user to access the system database to enter new group definitions, update existing group definitions, and establish or delete group relationships with system terminals.
TABLE 7
Terminal capacity table
<td>Kind of Terminal</td><td>Protocol Marking</td><td>Size of the Screen</td><td>Buttons features</td><td>Kind of Transport</td><td>Kind of Coding</td>
<td> 7400</td><td>DCP</td><td>2x16</td><td> 12</td><td>DSO</td><td>64K PCM</td>
<td>AT1</td><td>H. 320</td><td>NULL</td><td>NULL</td><td>6 x DSO</td><td></td>
<td>AT2</td><td>ATM</td><td>NULL</td><td>NULL</td><td>CBR / AAL1</td><td></td>
<td>WT</td><td>DECT</td><td></td><td></td><td>32K</td><td>ADPCM</td>
<td>BT</td><td>DECT</td><td>NULL</td><td>NULL</td><td>NULL</td><td>NULL</td>
The Terminal Capabilities Table includes information regarding the capabilities of various terminals in the system. This information includes, for example, the Signaling Protocol, Screen Size, Feature Buttons, Transport Type and Encryption Type for a given specified Terminal Type. For example, the table shows that the Advanced Terminal Type 2 (AT2) uses an Asynchronous Transfer Mode (ATM) Signaling Protocol and a limited bit rate (CBR) transport stream structure. Constrained Bit Rate) / ATM Adaptation Layer 1 (AAL1, ATM Adaptation Layer 1). All this information can be entered in the system administration.
ES 2 296 367 T3
TABLE 8
Table of types of encoding-performance
<td>Benefit ID</td><td>Call Type</td><td>Coding Type</td>
<td> 0001</td><td>Voice</td><td>PCM</td>
<td> 0001</td><td>Video</td><td>H.320</td>
<td> 0101</td><td>Voice</td><td>ADPCM</td>
The Table of encoding-feature types specifies the Call Type and the Encoding Type of each of a number of communication features supported by system 100. For example, the table indicates that the feature with Feature ID 0001 supports both PCM voice calls such as H.320 video calls. As this information is normally static, it can be entered in the system administration.
Register (1) and (10)
Figure 3 illustrates the following three different cases in which a given mobile can "register" with a desk phone terminal, that is, go from state 210 Null to state 220 Registered in figure 2: (i) user dials a registration feature access code (FAC) followed by a mobile desk phone Directory Number (DN); (ii) the user dials the registration FAC followed by the mobile's DN from the desk phone; or (iii) the mobile satisfies a proximity-based registration condition for the desk phone. In any of these cases, the mobile is registered to become part of the desk phone pairing group, so it becomes eligible to later "pair" with the desk phone. Processing for case (i) begins at step 302 of Figure 3 with the user entering the registration FAC followed by the DN of the desk phone on the mobile. In step 304 the system obtains the UID of the mobile and the TID of the specified desk phone. This involves a number of Query operations that are listed in 305. These and all the other Query operations in this description are written in the form Query (n, x, y), where n specifies the table number of one of the tables 1 through 8 above, x is a key in the specified table, and and identifies the information to be retrieved from the table. For example, the operation Query (3, Port ID, TID<sub>movU</sub>) causes the system to query the Terminal Profile Table (Table 3) using the Port ID of the mobile as a key to obtain the TID of the mobile. Since the DN of the desk phone is dialed from the mobile, the physical port this number arrives at can be used to identify the Port ID with which the mobile communicates. The mobile's TID is then used as a key in the User Profile Table (Table 1) to obtain the mobile's UID. The desk phone DN is used as a key in the User Profile Table to obtain the desk phone TID.
Processing for case (ii) begins with the user entering the registration FAC followed by the mobile's DN from the desk phone in step 306. In step 308, the system obtains the mobile's UID and the phone's TID. using the two Query operations specified in 309. The Query (3, Port ID, TID<sub>sciitoiio</sub>) causes the system to query the Terminal Profile Table (Table 3) using the Desk Phone Port ID as a key to get the desk phone TID. Since the mobile DN is dialed from the desk phone, the physical port this number reaches can be used to identify the Port ID that the desk phone communicates with. The mobile's DN is then used as a key in the User Profile Table (Table 1) to obtain the mobile's UID.
Processing for both cases (i) and (ii) continues at step 310 where a determination is made as to whether the mobile can register on the desk phone. In step 311, the Binding Group Definition Table (Table 6) is examined using the desk phone TID as a key to attempt to locate the mobile UID in the set of mobile UID entries associated with the mobile TID. desk phone. Step 312 checks if the UID of the mobile is listed with the TID of the desk phone in the Binding Group Definition Table and therefore is allowed to bind to that desk phone. If it is not allowed to bind the mobile's UID to the desk phone, the registration is considered to have failed as indicated in step 314, and the mobile remains in the Null state. If the mobile is allowed to be linked to the desk phone, the registration is considered to be completed, and the update operations are performed in step 316. The update operations are written using the same format described above in the Inquiry operations. For example, the Update (1, UID, TID<sub>sciitoiio</sub>) in step 316 specifies that the User Profile Table (Table 1) is updated to include the TID of the desk phone for the UID of the mobile. In the other update operations in step 316, the Link Group Definition Table (Table 6) is updated to indicate that the mobile UID is a registered UID for the desk phone TID, and the terminals (Table 3) is updated to include a Linked Status entry of REGISTERED for the mobile's TID. The state of the mobile is then Registered, and the mobile is a member of the linking group for the desk phone.
Case (iii) above is referred to as "proximity-based registration" and begins at step 320 with the Query operations listed at 321. When the mobile enters the coverage of a particular cell of the
ES 2 296 367 T3 system, the port ID of the mobile is used as a key in the Terminal Profile Table (Table 3) to obtain the TID of the mobile. The mobile's TID is used as a key in the User Profile Table (Table 1) to obtain the mobile's UID. The mobile UID is used as a key in the Tethering Group Definition Table (Table 6) to obtain a viable desk phone TID. That desk phone TID is used as a key in the Terminal Profile Table to obtain the associated Port ID of the desk phone. The Desk Phone Port ID is used as a key in the Port Capacity Table (Table 4) to determine the Cell ID of the cell closest to the specified Port ID. The Port ID of the mobile is also used as a key in the Port Capabilities Table to find the Cell ID associated with the Port ID of the mobile. Step 322 determines if the Cell IDs of the desk phone and the mobile phone match. If the two Cell IDs match, a proximity-based registration message is sent in step 324, the update operations of step 316 are performed, and the mobile enters the Registered state. If the two Cell IDs do not match, step 326 indicates that there will be no registration based on proximity, and the mobile returns to the Null state.
In the 220 Registered state, the User Profile Table and Permission Table data is available. Therefore, when a specific user goes through the state machine of Figure 2 to any of the Linked states, that user's permission data can be overlaid on the linked terminal so that the user can make or receive all calls. according to your usual restrictions, using the linked terminal. A given system user may have multiple stored terminal profiles, one for each type of terminal in the system that can be accessed by that user. Then, when the user becomes linked to a particular system terminal, the corresponding stored terminal profile of that user is overlaid on the linked terminal. If the linked terminal is of the same type as a user-assigned terminal, the functional layout of the assigned terminal, including button assignments and softkey label arrangements, can be overlaid on the linked terminal such that the linked terminal is configured to function. in a similar way to the assigned terminal. For example, the layout of a given desk phone assigned to the user may be overlaid on another otherwise unrelated desk phone of the same or similar type to which the user is bound.
Cancellation of registration (2)
Figure 4 illustrates the following three different cases in which a given mobile can "unregister" or go from the 220 Registered state to the 210 Null state of Figure 2: (i) the user dials a deregistration FAC followed by a desk phone DN from mobile; (ii) the user dials the registration cancellation FAC followed by the mobile DN from the desk phone; or (iii) the mobile satisfies a proximity-based deregistration condition for the desk phone. In each of these cases, the mobile is removed from the desk phone pairing group, and therefore can no longer be chosen to pair with that desk phone. Processing for case (i) begins at step 402 of FIG. 4 with the user entering the deregistration FAC followed by the DN of the mobile desk phone. In step 404 the system obtains the UID of the mobile and the TID of the specified desk phone, performing the Query operations listed in 405. The system examines the Terminal Profile Table (Table 3) using the Port ID of the mobile as a key to obtain the TID of the mobile. The mobile's TID is then used as a key in the User Profile Table (Table 1) to obtain the mobile's UID. The desk phone DN is used as a key in the User Profile Table to obtain the desk phone TID.
The processing for case (ii) begins with the user entering the deregistration FAC followed by the mobile's DN from the desk phone in step 406. In step 408, the system obtains the mobile's UID and TID from the desk phone using the two Inquiry operations specified in 409. The Inquiry (3, Port ID, TID<sub>desk</sub>) causes the system to query the Terminal Profile Table (Table 3), using the Desk Phone Port ID as a key, to obtain the Desk Phone TID. The DN of the mobile is then used as a key in the User Profile Table (Table 1) to obtain the UID of the mobile.
Case (iii) above is referred to as "proximity-based deregistration" and begins at step 420 with the Inquiry operations listed at 421. When the mobile goes out of coverage of a particular cell in the system, the ID of Mobile port is used as a key in the Terminal Profile Table (Table 3) to obtain the mobile TID. The mobile's TID is used as a key in the User Profile Table (Table 1) to obtain the mobile's UID. The mobile UID is used as a key in the Tethering Group Definition Table (Table 6) to obtain the TID of the associated desk phone. That desk phone TID is used as a key in the Terminal Profile Table to obtain the associated Port ID of the desk phone. The Desk Phone Port ID is used as a key in the Port Capacity Table (Table 4) to determine the Cell ID of the cell closest to the specified Port ID. The Port ID of the mobile is also used as a key in the Port Capabilities Table to find the Cell ID associated with the Port ID of the mobile. Step 422 determines if the Cell IDs of the mobile and the desk phone match. If the two Cell IDs do not match, a proximity-based deregistration message is sent at step 424, and the process proceeds to step 410. If the two Cell IDs match, step 426 indicates that there will be no cancellation. registration based on proximity, and the mobile returns to the Registered state.
Processing for each of the above cases (i), (ii) and (iii) continues at step 410 in which a determination is made as to whether the mobile is actually registered on the desk phone. At step 411, the
ES 2 296 367 T3
Link group definition table (Table 6) using the desk phone TID as a key to try to locate the mobile UID in the set of mobile UID entries registered in the desk phone TID. The User Profile Table (Table 1) is also examined using the mobile UID to determine if it is registered to the desk phone TID. Step 412 checks if the UID of the mobile is listed with the TID of the desk phone in the Binding Group Definition Table and if the TID of the desk phone is listed with the UID of the mobile in the User Profile Table. If any of these conditions fail, the UID of the mobile is not allowed to unregister the desk phone, the deregistration is considered to have failed as indicated in step 414, and the mobile remains in the Registered state . If both conditions pass in step 412, the deregistration is considered complete, and update operations are performed in step 416. The User Profile Table (Table 1) is updated to erase the desk phone TID for the mobile UID, the Linking Group Definition Table (Table 6) is updated to indicate that the mobile UID is no longer a registered UID for the desk phone TID, and the Terminal Profile Table (Table 3) is updated to include a Binding Status entry of NULL for the mobile TID. The state of the mobile then goes to NULL.
Proximity deactivation (3a, 3b, 3c)
Figure 5 illustrates the way in which a mobile transitions from state 230 Inactive Linked, state 240 Active Linked or state 250 Warning Linked, to state 210 Null of figure 2. These three transitions can arise as follows:
Inactive Linked -> Null (transition 3a). After completing a call while linked to another terminal, and waiting to make or receive another call while remaining linked to that terminal, the mobile withdraws from the proximity of the aforementioned radio subsystem.
Linked Asset -> Null (transition 3b). While active on a call and linked to another terminal, the mobile withdraws from the proximity of the radio subsystem.
Linked Notice -> Null (transition 3c). After an incoming call is established for the mobile and the desk phone is alerting with a simulated bridged appearance, the mobile is removed from the proximity of the radio subsystem.
For each of the transitions (3a), (3b) and (3c) described above and shown in Figure 2, the mobile receives an "out of proximity" indication from the radio subsystem as shown in step 500. This out of proximity indication may be generated according to step 420 of FIG. 4. After the out of proximity indication is received, step 510 checks if the mobile is paired. This involves performing the Query operations listed in 511. When the mobile receives the out of proximity indication, the corresponding message arrives on a physical Port ID over which the mobile communicates. The system uses this Port ID as a key in the Terminal Profile Table (Table 3) to obtain the mobile's TID. The system then uses the mobile's TID as a key in the Terminal Profile Table to obtain the mobile's Binding Status. If the mobile is linked, the Pairing Status will be one of the following states: Linked Active, Linked Inactive or Linked Notice. Step 512 determines whether the mobile's Binding State is one of these three valid bound states. If the Binding Status is not a valid linked status, step 514 indicates that the out of proximity indication be ignored since a proximity based deregistration was issued for a detached mobile. If the Binding State is one of the three valid binding states, then the mobile is unlinked and then unregistered, using the operations of step 516.
The unlinking process in step 516 first determines the desk phone to which the mobile is currently paired. The system uses the TID of the mobile as a key in the User Profile Table (Table 1) to obtain the TID of this desk phone. The system makes another query in the User Profile Table, using the mobile's TID as the key, and obtains the mobile's UID. To unlink the mobile, an update is made to the Validation Groups Definition Table (Table 6). The system uses the desk phone TID as a key in the Binding Group Definition Table and deletes the mobile UID as the bound UID. To unregister the mobile, another update is made to the Linkage Group Definition Table. The system uses the desk phone TID as a key in the Binding Group Definition Table and removes the mobile UID from the Registered UID list. These two updates to the Binding Group Definition Table correspond to the Update (6, TID<sub>desk</sub>, UID<sub>Linked</sub>/ UID<sub>reg</sub> = 0) in step 516. Next, to disassociate the desk phone from the mobile, an update is performed in the User Profile Table (Table 1) to delete the TID of the desk phone associated with the UID of the mobile. This update is done by using the mobile UID as a key in the User Profile Table and setting the entry in the desk phone TID field to NULL. The Linkage Table (Table 5), which keeps track of all current mobile users who are linked, is updated to suppress the mobile user who got out of proximity. The mobile UID is used as a key in the Binding Table, and all items associated with the mobile UID are deleted. This involves setting the Timer, Visitor TID, and UID fields to NULL. Finally, the mobile's TID is used as a key in the Terminal Profile Table (Table 3), and the Binding Status associated with the mobile's TID is set to NULL. Therefore, the mobile goes to state 210 Null.
ES 2 296 367 T3
FAC unlinked and timer expiration (4)
Figure 6 illustrates the way in which a mobile goes from state 230 Idle Linked to state 220 Registered in figure 2. This transition can occur in the following cases: (i) the user enters the Unlinking FAC followed by the phone DN from the desktop from the mobile, (ii) the user enters the Unlink FAC followed by the mobile DN from the desktop phone; or (iii) the timer for the mobile's UID to remain in a bound state expires. For all these three cases, the UID of the mobile and the TID of the desk phone are needed to perform the necessary system updates for the mobile to go to the Registered state.
The processing for case (i) begins when the user enters the Unlinking FAC from the mobile in step 600. The corresponding message arrives on a physical Port ID over which the mobile communicates. The system, in one of the Query operations 611 of step 610, uses this Port ID as a key in the Terminal Profile Table (Table 3) and extracts the mobile's TID. In order to determine the mobile's UID, the system makes a query in the User Profile Table (Table 1), using the mobile's TID as the key, and extracts the mobile's UID. In order to determine the TID of the desk phone, another query is made in the User Profile Table using the TID of the mobile as the key and the TID of the desk phone is extracted.
The process for case (ii) begins when the user enters the Unlinking FAC from the desk phone in step 612. The corresponding message arrives on a physical Port ID over which the desk phone communicates. The system, in one of the Query operations 615 in step 614, uses this port ID as a key in the User Profile Table (Table 3) and extracts the TID from the desk phone. In order to determine the UID of the mobile, the system performs a query in the Table of definition of linked groups (Table 6), using the TID of the desk phone as the key, and extracts the UID of the mobile as the UID linked to the desk phone.
Processing for case (iii) begins when the Timer expires in step 620. The Timer function in step 622 then supplies the UID of the mobile. In order to determine the TID of the desk phone, a query is made in step 623 in the Tethering Group Definition Table (Table 6) using the UID of the mobile (i.e. the bound UID) as the key, and the TID of the desk phone is extracted.
After obtaining the mobile UID and the desk phone TID in cases (i), (ii) or (iii) in the manner described above, the processing continues at step 624. First the mobile UID is unlinked from the desk phone by performing an update on the Linkage Group Definition Table (Table 6). Using the TID of the desk phone as the key in the Binding Group Definition Table, the associated bound UID is set to NULL. Next, the Binding Table (Table 5), which keeps track of all current mobile users who are linked, is updated to delete the mobile user. The mobile UID is used as a key in the Binding Table, and all items associated with the mobile UID are deleted. This involves setting the Timer, Visitor TID, and UID fields to NULL. Finally, the mobile's TID is used as a key in the Terminal Profile Table (Table 3), and the Binding Status associated with the mobile's TID is set to REGISTERED. Therefore, the mobile goes to the 220 Registered state.
Outgoing call setup (5)
Figure 7 illustrates the way in which a mobile transitions from state 230 Inactive Linked to state 240 Active Linked in figure 2. This transition starts in step 700 when a user places a call when his mobile is in the Inactive Linked state. . For this example, it will be assumed that the mobile is linked to a desk phone from which the call is made. This desk phone will also be referred to as the originating terminal. The system detects the call being made, and in step 702 updates the Terminal Profile Table (Table 3) to reflect the fact that the desk phone to which the mobile is linked is in the Linked state. The system at step 704 then executes a widely known feature selection routine and declares a specific network feature to be dedicated to the current call instance associated with the linked terminal. This generally involves selecting a feature that has a bandwidth equal to or greater than that required by the originating terminal. The system at step 706 uses the Feature ID of the selected feature as a key in the Encoding-Feature Type Table (Table 8) to determine the Encoding Type of the selected feature. The system then uses the source terminal's TID as a key in the Terminal Profile Table and extracts the Terminal Type. The Terminal Type is used as a key in the Terminal Capabilities Table (Table 7) to determine the Coding Type and Transport Type requirements of the originating terminal.
The system in step 708 executes an interconnection function (IWF) appropriate for the transport flow to align the bandwidth, the Coding Type and Transport Type of the originating terminal and the selected feature, if necessary. The IWF is "pushed" into the call path. For example, if the originating terminal is a cordless desk phone using 32 kbps speech encryption and the selected network feature is a 64 kbps DS0 line, the system at step 708 can insert an ADPCM to PCM transcoder to interconnect the voice call. Then, the system initiates call setup procedures in step 710. If it is determined in step 712 that the user has aborted the call, the system returns the originating terminal to the Bound Idle state, updating the state of that terminal in the Terminal Profile Table as shown.
ES 2 296 367 T3 indicates in step 714. If the user has not aborted the call, the mobile completes the transition to state 240 Active Linked.
Incoming call setup (6) and (12)
Figure 8 illustrates the way in which a mobile goes from state 220 Registered to state 250 Announcement Linked, which is the transition (6) in figure 2, or from state 230 Inactive Linked to state 250 Announcement Linked, which is the transition (12). The transition (6) occurs in the case of an incoming call to a mobile that has been successfully registered in a binding group. The transition (12) occurs in the case of an incoming call on a mobile that has been successfully linked to a linking group. For both transitions, it is assumed that the mobile has not been active on a call. The incoming call to the mobile has originated from the calling party which may be, for example, a voice-only telephone or an advanced terminal. The calling party initiates the incoming call by dialing the DN of the mobile.
In the exemplary process shown in Figure 8, the incoming call is directed to a registered mobile via the DN dialed by the calling party. The switch software implements the process steps of Figure 8 in order to route the call. Step 800 checks if the mobile has registered in the pairing group. This involves the Query operations shown in 802. The dialed DN is first used as a key in the User Profile Table (Table 1) to determine the associated UID of the mobile. The mobile UID is then used as a key in the User Profile Table to determine the TID of the associated desk phone. The desk phone TID is used as a key in the Link Group Definition Table (Table 6) to locate the registered UIDs for that desk phone. Step 804 determines if any of the registered UIDs match the mobile's UID. If there is no match, or if the registered UID entry for the desk phone TID is NULL, the addressed mobile is not bound to any binding group, and the switch continues routing the regular call to the mobile as shown. sample in step 806. The mobile then returns to the Registered state.
If there is a match between the registered UID for the desk phone and the UID for the mobile, the system, in step 808, checks if the desk phone is busy with an outgoing call. The desk phone TID is used in an 810 Lookup operation as a key in the User Profile Table (Table 3) to extract the Binding Status entry for the desk phone. Step 812 checks if the Binding Status entry for the desk phone is BINDING ACTIVE. If the Binding Status entry is ACTIVE LINKED, the desk phone is busy with another active call, so the incoming call is offered only to the mobile as shown in step 806, and the process returns to either the state. Inactive Linked or Registered status. If the Pairing Status entry for the desk phone is not ACTIVE LINKED, the desk phone is idle. Then, the mobile begins its transition to the Alert Linked state with update operations at step 814. The Bound UID of the desk phone is updated in the Pairing Group Definition Table (Table 6) to the UID of the mobile, the Pairing Status of the desk phone is updated in the Endpoint Profile Table (Table 3) to ACTIVE LINKED, and the Linked Idle Timer associated with the mobile UID and the desk phone TID in the Binding Table (Table 5) is canceled.
In step 816, an appropriate IWF is selected for the incoming call. The selection of an IWF makes use of information retrieved in the Query 817 operations. The Terminal Type of the desk phone is retrieved from the Terminal Profile Table (Table 3) using the TID of the desk phone as a key. The Terminal Type is then used as the key in the Terminal Capabilities Table (Table 7) to retrieve the Signaling Protocol, Transport Type, Encryption Type, and Screen Size for the desk phone. The 817 Query operations may include another Query operation, not shown in figure 8, that uses the mobile UID and the Terminal Type as keys in the User Profile Table (Table 1) to retrieve the information on Assignments of Buttons associated with the UID of the mobile. The incoming call is then offered to both the mobile and the desk phone, as indicated in step 820. Therefore, an appropriate "prompt" is generated for both the desk phone and the mobile phone. This completes the mobile's transition to the LINKED WARNING state.
Call Suppression (7)
Figure 9 shows how the mobile transitions from the Linked Active state 240 to the Linked Inactive state 230 of Figure 2 when the mobile is released from a call. The call drop procedure begins in step 900. As part of this procedure, the system releases the call from the mobile or desk phone. The system, in step 902, then determines the UID of the mobile. Inquiry operation 904 uses the Port ID of the terminal released from the call as a key in the Terminal Profile Table (Table 3) to retrieve the TID and Terminal Type of that terminal. Step 906 then determines if the resulting Terminal Type is a desk phone. If the resulting Terminal Type is not a desk phone, then the call must have been released from the mobile. The system, at step 908, then retrieves the mobile's UID from the User Profile Table (Table 1) using the mobile's TID as a key.
If it is determined in step 906 that the Terminal Type is a desk phone, step 910 uses the TID of the desk phone as a key in the Link Group Definition Table (Table 6) to retrieve
ES 2 296 367 T3 the Linked UID for the desk phone. In either case, step 912 determines whether the Linked UID for the desk phone is set to the UID of the mobile. If the Linked UID for the desk phone is set to the mobile UID, the process proceeds to step 920. If the Bound UID for the desk phone is not set, this is an error condition, and the Bound UID for the desk phone is set to the mobile UID in step 914 before the process proceeds to step 920. In step 920, the Bound Interactive Time timer is set in the Binding Table (Table 5) for the mobile UID entry. This completes the transition and the mobile goes into the Linked Idle state.
Linked FAC (8)
Figure 10 illustrates the following two cases in which a given mobile can go from the 220 Registered state to the 230 Idle Linked state of Figure 2: (i) the user dials a Binding FAC followed by a desk phone DN from the mobile; or (ii) the user dials the Linking FAC followed by the mobile DN from the desk phone to be linked. The processing for case (i) begins in step 1002 of figure 2 with the user entering the Binding FAC followed by the DN of the desk phone on the mobile. In step 1004 the system obtains the UID of the mobile and the TID of the specified desk phone, performing the Query operations listed in 1005. The system examines the Terminal Profile Table (Table 3) using the Port ID of the mobile as a key to obtain the TID of the mobile. The mobile's TID is then used as a key in the User Profile Table (Table 1) to obtain the mobile's UID. The desk phone DN is used as a key in the User Profile Table to obtain the desk phone TID.
Processing for case (ii) begins with the user entering the Binding FAC followed by the mobile's DN from the desk phone in step 1006. In step 1008, the system obtains the mobile's UID and the phone's TID. desktop using the two Query operations specified in 1009. The Query (3, Port ID, TID<sub>sciitoIio</sub>) causes the system to query the Terminal Profile Table (Table 3) using the Desk Phone Port ID as a key to get the desk phone TID. The mobile's DN is then used as a key in the User Profile Table (Table 1) to obtain the mobile's UID.
Processing for cases (i) and (ii) continues at step 1010 where a determination is made as to whether the mobile is actually registered with the desk phone. In step 1011, the Binding Group Definition Table (Table 6) is examined using the desk phone TID as a key to try to locate the mobile's UID in the set of UID entries registered in the phone's binding group. desktop. Entry 1012 checks if the mobile UID is listed with the desk phone TID in the Binding Group Definition Table. If the UID of the mobile does not match any of the UIDs registered for the desk phone, the binding request is denied in step 1014. This indicates either that the mobile is not registered in the DN of the desk phone supplied in step 1002, or that the desk phone does not have any mobiles registered in the binding group that matches the DN of the mobile supplied in the Step 1006. As a result, the mobile remains in the Registered state. If it is determined in step 1012 that the UID of the mobile matches a UID registered for the desk phone, the mobile is allowed to link to that desk phone, and update operations are performed in step 1016. The Tethering Group Definition Table (Table 6) is updated to indicate that the mobile UID is a Bound UID for the desk phone, the Endpoint Profile Table (Table 3) is updated to include the entry for the Status of Binding of LINKED to the mobile TID, and the Binding Table (Table 5) is updated to set the Visitor TID to the desk phone TID and to enable the Linked Idle Timer. The mobile state then goes to the Linked Idle state.
Incoming call unanswered (9)
Figure 11 illustrates how a given mobile can go from the status 250 Linked Announcement to the 220 Registered state of Figure 2. When the mobile is in the Linked Announcement state, both the linked desk phone of the pairing group and the mobile can answer the incoming call. At step 1102, an incoming call is not answered by either the linked desk phone or the mobile. Therefore, the call can be re-routed through the switch or canceled by the called party. Information such as desk phone TID, mobile TID, and mobile UID are available on the switch while the incoming call is re-routed or disconnected. Step 1104 re-sets the Pairing Status of the mobile and desk phone, updating the Pairing Status information in the Terminal Profile Table (Table 3) to NULL for the TID of the desk phone already REGISTERED for the TID. of the mobile. Step 1106 sets the Bound UID information for the desk phone TID in the Bind Group Definition Table (Table 6) to NULL. Step 1108 removes the entire mobile UID binding record from the Binding Table (Table 5) using the Update (5, UID) operation.<sub>mobile</sub>, remove). The mobile then returns to the Registered state as shown.
Incoming call answered at a complex terminal (11)
Figure 12 illustrates the manner in which a given mobile transitions from state 250 Announcement Linked to state 240 Active Linked in figure 2. In step 1200, an incoming call arrives on trunk line 114 intended for a particular terminal of system 100 The call may not be end-to-end symmetric since, for example, its width of
ES 2 296 367 T3 band, type of coding and / or type of service may not be consistent throughout the network. During the transition from the Alert Linked state to the Active Linked state, the system therefore checks the bandwidth and type of network encryption for the call, and checks the profile of the destination terminal for compatibility. This part of the process is implemented in steps 1202 and 1204 of Figure 12. In step 1202, the Feature ID associated with the destination terminal is used as a key in the Feature-Encryption Type Table (Table 8) to obtain the Encryption Type for the terminal. It will be assumed for the purposes of illustration that the destination terminal is a desk phone. The DN of the incoming call is used as a key in the User Profile Table (Table 1) to obtain the Terminal Type and TID of the desk phone. The desk phone TID is then used as a key in the Terminal Capabilities Table (Table 7) to obtain the Encryption Type for the desk phone.
A determination is then made in step 1204 whether the bandwidth, encryption type, and service type of the incoming call are "symmetric" with the corresponding parameters of the destination desk phone. If the call and desk phone parameters are not symmetrical, an IWF is selected in step 1206 to provide extraction / refill operations that are designed to resolve the asymmetry between the call parameters and the desk phone. If the call and desk phone parameters are symmetric, an IWF transcoder is selected in step 1208. In either case, step 1210 updates the Binding Status entry for the desk phone TID in the User Profile Table (Table 3) to LINKED ACTIVE. This completes the mobile's transition to Linked Active state.
In the simplest case of the operation of the process of Figure 12, the incoming call is end-to-end symmetric from its originating terminal to the destination terminal, and the IWF transcoder selected in step 1208 may be a NULL IWF. However, there can be many cases where such symmetry does not exist. For example, in the case of Transition (5) described above, both the bandwidth and the voice coding scheme of the call can be interconnected using an appropriate IWF transcoder designed to match the capabilities of the destination terminal to those of the fountain. Another such case is one where the incoming call is a multimedia call, but the destination terminal does not have multimedia support. In this case, the system determines that there is a service incompatibility (as well as a bandwidth and encryption incompatibility), and initiates IWF procedures to allow the call to be delivered to the destination terminal. As an example, suppose that an H.320 call arrives on the trunk line 114 of the network, intended for a user who is linked to the wireless desk phone WT2 of Figure 1. The system decodes the H.320 transport stream and extracts the speech samples. These speech samples are then transcoded to suit the capabilities of the WT2 terminal, and delivered to the user. As a possible additional feature related to this example, the IWF can be configured to provide preset video data in the reverse direction (i.e. outbound), such that the bandwidth established between the system terminal and the source of the H.320 call is symmetric in a bidirectional way. Since the desk phone WT2 itself cannot generate this preset video data for insertion in the reverse direction, the IWF can extract such video data from the system database 118 and insert it into the outbound transport stream.
It should be noted that during the cycle of a call, since the call can be bridged between the mobile and a more complex terminal, and such bridged appearances can be created by proximity to the complex terminal, the IWF selection steps may have to be executed multiple times. For example, suppose a user binds to a complex terminal at a particular location, and accepts a call at that location. During the call, the user, using the bridged call appearance on the mobile, passes the call to the mobile, and moves to a different area. Upon reaching the new location, the user is detected in the proximity of a new complex terminal. A new IWF can then be invoked when the user enters the Bound Active state on the new terminal.
In a possible alternative embodiment of the invention, a given user is provided with a device that is configured to signal user identification information (UID) for that user. Such a device could be implemented with an employee identification card carried by the user, or in the form of a small "button" that could be hooked on the user's clothing or worn as a pendant. In a wireless environment, such a device is generally referred to as a beacon. A system according to the invention can be configured to use the beacon to keep track of the user's location, such that a call received for the user is directed to the desk phone or other complex terminal that the system determines closest to the user at that point. particular moment. Although this type of proximity-based registration can be implemented in a similar way to that described above for mobile terminals, it will not include a bridging operation if the user-carried beacon device does not support transport channels or a user interface.
A beacon-directed call processing function can be activated by a user entering a feature access code (FAC) and / or pressing a feature button. Alternatively, it can be implemented in a fully automated way. In the feature-enabled implementation, the system tracks beacon signals only when instructed to do so by user commands. In the fully automatic implementation, the proximity relationships of the beacon to the terminal can be determined a priori, and used for all routing. The system could first check the user's location as defined by their corresponding beacon location before performing any beacon-directed call routing for that user. Tables 1, 3, 4, and 7 above include inputs related to a Beacon Terminal (BT) to implement a beacon-directed call processing function. For example, the User Profile Table (Table 1) indicates that the user who has the UID
ES 2 296 367 T3 "epf" is equipped with a beacon device. This embodiment of the invention can be used, for example, to route incoming calls to the user at the nearest system terminal, to allow the user to access functions of a stored user-defined terminal profile at the nearest system terminal. , as well as in other applications.
The above-described embodiments of the invention are intended to be illustrative only. These and numerous other alternative embodiments within the scope of the following claims will be apparent to those skilled in the art.
Contents16
13 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13
15 members in 7 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 19980031581 | United States of America | – | |
| 3158198 | United States of America | A | |
| 3158198 | United States of America | A | |
| 9930112731581 | – | – | – |
| US19980031581 | – | – | – |
Members15
| Document | Office | Kind | |
|---|---|---|---|
| CA2260502A1 | Canada | A1 | |
| EP0939561A2 | European Patent Office (EPO) | A2 | |
| KR19990072957A | Republic of Korea | A | |
| JPH11331386A | Japan | A | |
| EP0939561A3 | European Patent Office (EPO) | A3 | |
| KR100317010B1 | Republic of Korea | B1 | |
| US6359896B1 | United States of America | B1 | |
| CA2260502C | Canada | C | |
| JP2005176397A | Japan | A | |
| JP3950252B2 | Japan | B2 | |
| EP0939561B1 | European Patent Office (EPO) | B1 | |
| DE69936813D1 | Germany | D1 | |
| ES2296367T3This record | Spain | T3 | |
| DE69936813T2 | Germany | T2 | |
| JP4486511B2 | Japan | B2 |
Numbers
- Publication
- 2296367
- Publication, DOCDB
- 2296367
- Publication, EPODOC
- ES2296367T
- Application
- 99301127
- Application, DOCDB
- 99301127
- Application, EPODOC
- ES19990301127T
Titles2
- Spanish
- SELECCION DINAMICA DE FUNCIONES DE INTERCONEXION EN UN SISTEMA DE COMUNICACION.
- English
- DYNAMIC SELECTION OF INTERCONNECTION FUNCTIONS IN A COMMUNICATION SYSTEM.
Classification
- CPC, 17
- H04Q3/625
- H04Q2213/13034
- H04Q2213/1305
- H04Q2213/13095
- H04Q2213/13098
- H04Q2213/13103
- H04Q2213/13106
- H04Q2213/13196
- H04Q2213/13204
- H04Q2213/13213
- H04Q2213/13292
- H04Q2213/13337
- H04Q2213/13353
- H04W8/245
- Y10S370/913
- H04L69/08
- H04L9/40
- IPC, 7
- H04M3 42
- H04Q3 00
- H04L12 28
- H04L29 06
- H04M3 00
- H04Q3 62
- H04W8 24