Determination of an establishment cause for transmitting in case of a circuit-switched fallback procedure
Abstract
A method implemented by a wireless device (10) for switching to switched circuits CS from a first network (12) that does not provide services of the CS domain of switched circuits, comprising the method: receiving from the first network (12) a location message ( 72) for switching to switched circuits to a network of switched circuits (14, 74, 78); determine a type of channel suitable for a service indicated by the information in the location message (72); transmit a request message (76) to initiate the establishment of a switched circuit radio connection, identifying the information message ( 76) the appropriate type of channel; and, use the service in the circuit switched network (14, 74, 78).

Term
3.1 yearsto projected expiry
Projected expiry 9 November 2029, counted from filing; an application has no term until it is granted.
- Priority and filed
- Published
- Today
- Projected expiry
10 claims: 6 independent, 4 dependent
- 1REIVINDICACIONES 1. Un método implementado por un dispositivo inalámbrico (10) para cambiar a circuitos conmutados CS desde una primera red (12) que no proporciona servicios del dominio de CS de circuitos conmutados, comprendiendo el método:recibir desde la primera red (12) un mensaje de localización (72) para cambio a circuitos conmutados a una red de circuitos conmutados (14, 74, 78);determinar un tipo de canal adecuado para un servicio indicado por la información en el mensaje de localización (72);transmitir un mensaje de solicitud (76) para iniciar el establecimiento de una conexión de radio de circuitos conmutados, identificando el mensaje de información (76) el tipo de canal adecuado;y, utilizar el servicio en la red de circuitos conmutados (14, 74, 78).
- 2El método de la reivindicación 1, en el que el servicio es uno de una primera categoría de servicios, incluyendo la primera categoría de servicios llamadas de conversación de CS y servicios de CS que requieren un canal de tráfico o recursos de conversación, una segunda categoría de servicios, incluyendo la segunda categoría de servicios solicitudes de ubicación terminadas en un teléfono móvil o una tercera categoría de servicios, incluyendo la tercera categoría de servicios servicios suplementarios.
- 3El método de la reivindicación 2, en el que, si el servicio está en la primera categoría de servicios, el tipo de canal adecuado para el servicio es al menos uno de un canal de tráfico de velocidad media TCH/H (Traffic CHannel/Half, en inglés) o un canal de tráfico de velocidad máxima TCH/F (Traffic CHannel/Full, en inglés).
- 4El método de la reivindicación 2, en el que, si el servicio está en al menos una de las categorías segunda o tercera de servicios, el tipo de canal adecuado para el servicio es un canal de control dedicado SDCCH (Standalone Dedicated Control CHannel, en inglés) independiente.
- 5El método de la reivindicación 1 ó la reivindicación 2, en el que, cuando el servicio es indefinido, se determina que el tipo de canal adecuado para el servicio es un canal por defecto.
- 6El método de las reivindicaciones precedentes, en el que determinar comprende:detectar al menos uno de un elemento de información de código de SS de servicio suplementario, un elemento indicador de LCS de servicio de ubicación, y un elemento de información de identidad de cliente de LCS dentro del mensaje de localización (72);y en el que cuando el mensaje de localización (72) incluye el elemento de información de código de SS, el tipo de canal adecuado para el servicio es seleccionado para un servicio suplementario independiente de llamada;y cuando el mensaje de localización (72) incluye al menos un elemento de información indicador de LCS y el elemento de información de identidad de cliente de LCS, el tipo de canal adecuado para el servicio es seleccionado para una solicitud de ubicación terminada en un teléfono móvil.
- 7El método de cualquiera de las reivindicaciones precedentes, en el que el mensaje de localización (72) incluye unMENSAJE DE NOTIFICACIÓN DE SERVICIO DE CS.
- 8El método de cualquiera de las reivindicaciones precedentes, en el que el mensaje de localización (72) incluye un mensaje de localización de protocolo de RRC de E-UTRAN recibido después de un procedimiento preliminar implementado utilizando una interfaz de S1.
- 9Un dispositivo de comunicación mediante telefonía móvil (10) adaptado para llevar a cabo el método de cualquiera de las reivindicaciones 1 a 8.
- 10Un medio legible por ordenador que comprende un código ejecutable en un ordenador para llevar a cabo el método de cualquiera de las reivindicaciones 1 a 8.
Independent claims10
184 paragraphs, as filed
Determination of a type of channel to be requested in case of a switched circuit change procedure.
BACKGROUND This description generally refers to systems and methods for communications between a wireless device or a user agent (UA) and a network and, more particularly, to systems and methods for coordinating communication resources between devices Wireless and networks that include switched circuit networks.
As used herein, the term "user agent" or UA (User Agent, in English) may refer to wireless devices such as mobile phones, personal digital assistants (PDAs - Personal Digital Assitants, in English), computers manual or portable lap holding, and similar devices, including mobile phone stations (MS - Mobile Stations, in English) or user equipment (EU - User Equipment, in English) that have telecommunications capabilities. In some embodiments, a UA may refer to a wireless mobile telephone device. The term "UA" may also refer to devices that have similar capabilities but are not generally transportable, such as desktops, boxes above the television or network nodes.
A UA can operate in a wireless communication network that provides high speed data and / or voice communications. Wireless communication networks may implement switched circuit communication protocols (CS - Circuit Switched, in English) and / or packet switched (PS - Packet Switched, in English) to provide various services. For example, the UA may operate in accordance with one or more of an Enhanced Universal Terrestrial Radio Access Network (E-UTRAN) - Enhanced Universal Terrestrial Radio Access Network (UTRAN - Universal) Terrestrial Radio Access Network, in English, Global System for Mobile Telephony (GSM) network, Evolution - Optimized Data (EV-DO - Evolution-Data Optimizad, in English), Digital Enhanced Wireless Telecommunications (DECT - Digital Enhanced Cordless Telecommunications, in English), AMPS Digital (IS-136 / TDMA), Integrated Digital Enhanced Network (iDEN - Integrated Digital Enhanced Network, in English), Telecommunications System Universal Mobile Telephony (UMTS - Universal Mobile Telecommunications System, in English), Enhanced Data Rates for GSM Evolution (EDGE), GPRS / EDGE Radio Access Network (GERAN - Gprs / Edge Radio Access Network, in English) and General Packet Radio Service technology (GPRS). Other wireless networks in which UAs can operate include but are not limited to Multiple Code Division Access (CDMA), cdma2000, cdma2000 1xRTT, cdma2000 HRPD, WLAN (for example IEEE 802.11) and WRAN (for example IEEE 802.22). UAs can also operate in fixed network environments such as, for example, Digital Subscriber Line (xDSL - xDigital Subscriber Line) environments, cable networks of Cable Data Service Interface Specification (DOCSIS - Data Over Cable Service Interface Specification, in English, Wireless Personal Area Networks (PAN), Bluetooth, ZigBee, Metropolitan Area Networks (MAN - Metropolitan Area Networks, in English) Wireless (for example, WiMAX, IEEE 802.20, IEEE 802.22 Ethernet) or optical networks. Some UAs may be capable of multimode operation, where they can operate in more than one access network technology either in a single access network at a time or in some devices that use multiple access technologies simultaneously.
In wireless telecommunications systems, the transmission equipment at a base station transmits signals in a geographical region known as a cell. As technology has evolved, more advanced equipment has been introduced that can provide services that were not previously possible. These advanced equipment could include, for example, an Node B (eNB) of evolved universal terrestrial radio access network (E-UTRAN - Evolved Universal Terrestrial Radio Access Network, in English) instead of a base station or other systems and devices that are more highly evolved than equivalent equipment in a traditional wireless telecommunications system. Such advanced or next-generation equipment may be referred to herein as Long Term Evolution (LTE) equipment, and a packet-based network using such equipment may be referred to as an evolved packet system (EPS - Evolved Packet System, in English). As used herein, the term "access device" shall refer to any component, such as a traditional base station, eNB, or other LTE access device, which may provide a UA with access to other components in A telecommunications system.
The different networks described above provide different services to the connected UAs. Some networks, for example, provide only PS services and cannot provide CS voice or other CS domain services. Thus, a UA can be configured to connect to multiple types of networks to access services from both the PS and CS domain. For example, if a UA is connected to a first network cell that does not provide CS domain service, the UA can be configured to implement a change to CS procedure, which can be referred to herein as "change to CS", to connect to an accessible network such as a GERAN or a Universal Terrestrial Radio Access Network (UTRAN - Universal Terrestrial Radio Access Network, in English) to access voice or other CS domain services provided by those networks, as described in document TS 23.272 of the 3GPP. Thus, the procedure for switching to CS allows a UA connected to a network that uses a first radio access technology (RAT - Radio Access Technology, in English) and provides only services from the PS domain, connect to another network that provides CS domain services. The change to CS can be used when, at the start of the voice call, the UA was associated with a cell in a network that only provides PS domain service. The UA that initiates the voice call may be idle or connected (for example, active) in the cell of the network that only provides services from the PS domain. In the event that the UA is at rest, it can be said that it is in the cell and may be monitoring the location channel for that cell to locate messages for sessions or calls terminated on a mobile phone.
In the event that the UA is connected, it may be communicating with the cell and transferring data for a service in the PS domain.
Returning to Fig. 1, an example of the process of switching to CS is illustrated by means of which a UA 10 moves from a cell in the E-UTRAN network to a GERAN or UTRAN 14 cell to access domain services from CS to initiate a voice call. As will be described, to facilitate the change to CS, the UA 10 may be configured to communicate with both PS and CS based networks. For example, UA 10 can support combined procedures for connection to EPS / International Mobile Telephone Subscriber Identity (IMSI) and update of Tracking Area to register with a Mobility Management Entity ( MME - Mobility Management Entity, in English to access PS domain services (for example, through an E-UTRAN access network, UTRAN or GERAN) and to register with a Mobile Telephone Switching Center (MSC) to access CS domain services (for example, through the UTRAN or GERAN access network or other network that supports CS domain services). The combined procedures also allow the MSC and the MME to create an association between them so that everyone is aware that UA 10 is simultaneously registered in both the MSC and the MME and that, therefore, UA 10 is registered both in the PS and CS networks.
Fig. 2 is a data flow diagram illustrating an example data flow for a change to CS procedure terminated in a mobile phone where the UA 10 in connected mode is redirected to the GERAN or the UTRAN. In Fig. 1, UA 10 is initially connected to the E-UTRAN cell 12. Because the E-UTRAN 12 cell does not provide CS domain services, UA 10 implements a change to CS to communicate with the GERAN or UTRAN 14 cell to access CS domain services provided by them. .
As an example, a network-assisted cell change (NACC) relating to a voice call originating from a mobile phone will be described. In reference to Figs. 1 and 2, the example process begins when an MSC 16 sends a location for CS 18 to an MME 20, which in turn requests the MME 20 to send a service notification location 22 of CS to UA 10. In the Fig. 1 communications from the E-UTRAN 12 cell are indicated by arrow 23 and communications from UA 10 to the E-UTRAN 12 cell are indicated by arrow 25. In response to service notification location 22 of CS, UA 10 sends an Extended service request 24 to eNB 26 of the E-UTRAN 12 cell. However, the E-UTRAN cell is not configured to provide CS domain services. Thus, the MME 20 sends an application protocol message S1 (S1-AP-S1-Application Protocol, in English) with an indicator 30 of switching to CS to eNB 26.
To streamline the sample data stream, Fig. 2 indicates some data streams through boxes, such as the optional measurement report 32 that can be provided by the UA 10 to indicate information, such as signal strength and others of the neighboring cells to which it can be assigned. That is, when a change is made to CS, UA 10 may be in the best position to determine which cell or cells are candidate cells to which or to which to change. In this way, UA 10 can detect which cells are very close or have a particularly strong received signal strength or quality (or other parameters of that type), and therefore, with what cells would UA 10 probably have a correct connection afterwards. of the process of change to CS. Accordingly, during the process of switching to CS, the UA 10 can carry out a measurement step to detect and identify the cells accessible to the UA 10. In other words, before switching to a cell that provides CS domain service, UA 10 can search for available candidate network cells through a measurement process.
The eNodeB (eNB) can activate an inter-RAT cell change order, optionally with the NACC signal 34 that is sent to UA 10; alternatively, a connection release with redirection is signaled. The eNB 26 indicates, in accordance with S1-AP, a request for context release 38 from the UA to the MME 20. Next, the context release of the S1 40 UA, an update of the location area (LA), a combined routing area update (RA - Routing Area, in English) / LA, takes place. an update of the RA or an update of the LA and an update of the RA 42 in the new GERAN or UTRAN cell. If the target RAT is GERAN, a suspension of PS services may occur if the new cell or the UA does not support simultaneous CS and PS services. In this case, a suspension message 44 is sent from the UA 10 to a base station system (BSS), which is then communicated from the BSS 46 to a GPRS Support Node of Service (SGSN - Serving Gprs (General packet Radio Service, in English) Support Node, in English) 48. A suspension request / response 50 is then communicated between the SGSN 48 and the MME 20 and an update of the bearer or carriers 52 between the MME 20 and a service gateway (S-GW - Serving) takes place
<dl><dt>-</dt><dd>Gateway, in English) 54. </dd></dl>
UA 10 signals a location response 56 to the BSS / RNS 46, which in turn sends this location response to the MSC 16. If the change to CS entails a change of the MSC 16, additional steps may be carried out, as indicated in box 58, such as communicating a connection rejection 60 from MSC 16 to BSS / RNS 46, communicating a connection release 62 from BSS / RNS 46 to UA 10, and an LA update or combined RA / update LA 64. Finally, a call establishment procedure of CS 66 takes place, so that, as indicated in Fig. 1, the UA 10 can pass, as indicated by arrow 68, to communicate with the E-UTRAN cell 12 to communicate, as indicated by arrow 70, with the GERAN or UTRAN 14 cell on a CS channel.
When the change to CS is implemented, the delay can be a problem. If the UA 10 is initially in the E-UTRAN 12 cell and you want to access CS voice services in the GERAN or UTRAN 14 cell, a change to CS process can be executed. Although the procedure for establishing a radio resource control connection (RRC) of the changeover process to CS can be relatively short (for example, approximately 150 ms is a target time for the system design E-UTRA), the measurement steps and a stage to select the target cell for CS voice services can potentially take a significant amount of time. In this way, the change to CS can be delayed, resulting in delays in the establishment of the CS voice services, possibly delaying the establishment of a connection for the user or negatively affecting other services that the UA 10 accesses. .
In addition to this possibility for a user to experience a noticeable delay in services, the change to CS may result in inefficient or inappropriate uses of network resources. For example, when a UA is located in a GERAN network or in a UTRAN for a call that ends on a mobile phone, some information is communicated by the network in the location message. That is, the location message may provide an indication of a service for which the UA is located, or an indication of the type of radio channel appropriate to support the service. Similarly, in the case of a call originating from a mobile phone (MO - Mobile Oriented, in English), the UA is indicating to the network a cause of establishment that is reflected in the service or in the type of channel requested. Thus, the network can reasonably assign appropriate channels for the desired communication.
However, such information is not available on the corresponding E-UTRAN interfaces used when the change to CS procedure is initiated, or is available but is not evaluated to request / assign the radio channels in the GERAN, the UTRAN or the E-UTRAN. Consequently, the network may decide to allocate non-optimal resources, such as a signaling channel for the service of a voice call, which may affect the performance of the change to CS, or a traffic channel to provide service to a signaling procedure. , causing a loss of the radio resource.
Thus, the systems and methods that solve the problems listed above and allow the establishment and use of optimal resources for switching to CS would provide a useful improvement in the art.
The present description provides a system and method for switching to Switched Circuits (CS - Circuit Switched, in English) and, specifically, to minimize the delay, optimize the allocation of the radio resource and improve the reliability of the change to CS.
The invention relates to a method for switching to CS according to claim 1, to a mobile telephone communication device according to claim 9 and to a computer-readable medium according to claim 10.
BRIEF DESCRIPTION OF THE DRAWINGS In the accompanying drawings, equal reference numbers represent equal parts or operations.
Fig. 1 is an illustration of an example change to CS process in which a UE moves from an E-UTRAN cell to a GERAN or UTRAN cell to access CS domain services for initiate a voice call;
Fig. 2 is a data flow diagram illustrating an example data flow for a CS switching procedure that ends in a Mobile Phone where a connected mode UA is redirected to the GERAN or the UTRAN without PS Transfer ; Fig. 3 is a data flow diagram illustrating a call initiation ending in a Mobile Phone in a GERAN network where the UA is in idle mode; Fig. 4 it is a data flow diagram illustrating a call initiation that ends in an example Mobile Phone in a UTRAN network where the UA is in idle mode; Fig. 5 is a data flow diagram illustrating a CS switching procedure that originates in a Mobile Phone with Switching Packet Transfer initiated in an E-UTRAN network, Fig. 6 it is an illustration of a data flow to implement a change to CS that ends in a Mobile Phone where the information related to a service is passed to the UA in idle mode within a location message; Fig. 7 shows a block diagram of the user equipment (UE - User Equipment); Fig. 8 illustrates a software environment that can be implemented by a processor of a user equipment; and Fig. 9 illustrates an example of a system that includes a suitable procedural component to implement a method to provide continuity for sessions that are moving from one network to another.
DETAILED DESCRIPTION The different aspects of the description are now described with reference to the attached drawings, in which equal numbers refer to the same or corresponding elements in this document.
As used herein, the terms "component", "system" and others are intended to refer to an entity related to a hardware computer, a combination of hardware and software, software or running software. For example, a component can be, but is not limited to, a process that runs on a processor, a processor, an object, an executable, a thread of execution, a program and / or a computer. By way of illustration, both an application that runs on a computer and a computer can be a component. One or more components may or may reside within a process and / or thread of execution and a component may be located in a computer and / or distributed between two or more computers.
The term "example" is used herein with the meaning of serving as an example, instance or illustration. Any aspect or design described herein as "exemplary" should not necessarily be interpreted as preferred or advantageous in other aspects or designs.
In addition, the subject described can be implemented as a system, method, apparatus or article of manufacture using standard programming and / or engineering techniques to produce software, firmware, hardware or any combination thereof to control a device based on a computer. or in a processor to implement the aspects detailed in this memory. The term "article of manufacture" (or alternatively, "computer program product") as used herein is intended to encompass a computer program accessible from any device, media or computer-readable media. For example, computer-readable media may include, but are not limited to magnetic storage devices (for example, hard disk, flexible disk, magnetic tapes and others), optical discs (e.g., compact disc (CD-Compact Disk, in English), digital versatile disc (DVD - Digital Versatile Disk, in English) and others, smart cards and fast memory devices (for example, card, skewer and others). Additionally, it will be apparent that a carrier wave can be used to transport computer-readable electronic data, such as those used to transmit and receive email or to access a network such as the Internet or a local area network (LAN - Local Area Network , in English). Of course, those skilled in the art will recognize that many modifications can be made to this configuration.
As indicated above, there is a possibility that the change to CS causes the allocation of non-optimal resources such as a signaling channel to provide service to a voice call, which can create situations that affect the performance of the change to CS , or a traffic channel to provide service to a signaling procedure, causing a loss of radio resources. For example, going back to Fig. 3, in the case of the initiation of a call ending in a mobile phone in the GERAN, the UA 10 is typically provided with the indication "Channel Need" in a location message 72 sent by the GERAN 74 network, which it is information that indicates the most suitable radio channel to support the service for which the UA is located, for example, the signaling channel Independent Dedicated Control Channel (SDCCH - Stand-Alone Dedicated Channel, in English), the traffic channel (TCH - Traffic Channel, in English) / complete (F - Full, in English). The UA 10 then sends an appropriate channel request 76 to the GERAN 74 network taking into account the "Location indication" of the "Channel Need" element received in the location message 72 and in the capacity of the UA 10 ( maximum speed only, dual speed, SDCCH only), which allows the BSS to provide the most desirable channel. For example, Table 1 below lists the channel request messages when they respond to a location for establishing the RR connection.
<dl><dt>MS Capacity Location Indication </dt><dd>Max speed only Dual Speed SDCCH only </dd></dl>
<dl><dt>Any channel </dt><dd>100xxxxx 100xxxxx 100xxxxx </dd></dl>
<dl><dt>SDCCH </dt><dd>0001xxxx 0001xxxx 0001xxxx </dd></dl>
<dl><dt>TCH / F </dt><dd>100xxxxx 0010xxxx 0001xxxx </dd></dl>
<dl><dt>TCH / H or TCH & F </dt><dd>100xxxxx 0011xxxx 0001xxxx </dd></dl>
Table 1
However, in the case of locating a UA in the E-UTRAN for the change to CS termination session, the location (CS service notification) sent by MME 20, as described with respect to Fig. 2, the UA 10 in connected mode in the source network (packets only) does not contain any "Location Indication" information. This location notification may include information about the service for which the mobile telephone station is located (for example Supplementary Service code, location service indicator (LCS - LoCationService)). In the event that the location has been made to reach the UA 10 in idle mode, (see, for example, Fig. 6), the location messages sent on the S1 interface and on the radio interface do not even contain any indication of the service for which the mobile telephone station is located. In addition, the GERAN RR protocol does not specify how the UA should build the Channel Request when it responds to the location when it is activated by the change to CS procedure. This means that the existing channel request procedure defined for the GERAN is not applicable in that way for the change to CS (lack of “Location Indication” to determine the correct and optimal information in the channel request message that can be sent in the target network.
As a result, a change to CS to the GERAN could lead to inconsistent UA implementations, for example, requesting an inappropriate type of channel to the service being activated, resulting in the loss of allocated resources or in a set-up time. longer. In particular, the request and initial assignment of an SDCCH in the case of a voice call establishment will delay the establishment of the voice route compared to the case in which a traffic channel (TCH - Traffic CHannel) ) is requested and assigned only in signaling mode (higher latency of the SDCCH compared to the TCH, more time for TCH allocation in talk mode if an SDCCH has been allocated compared to a channel mode modification procedure while still being on the same TCH channel). In other scenarios, the request and initial assignment of a TCH in signaling-only mode would waste radio resource if the service, for example, location service or supplementary service, can be supported in an SDCCH.
Returning to another problem identified as an example, Fig. 4 illustrates a CS call ending in a mobile phone in the UTRAN 78 network, with the UA 10 in idle mode. In this case, the UA 10 is typically provided with a "location cause" information in the location message sent by the UTRAN 78 network, which is information that indicates the type of service for which the UA is located, for example , Termination Conversation Call, High Termination Priority Signaling, Low Termination Priority Signaling, as indicated by “location for type 1” 80. This information is sent by the RRC protocol in UA 10 to the upper layers, which in turn request the establishment of the RRC connection and map the cause of RRC establishment to the received location cause, which will be included in the RRC 82 Connection Request sent to the UTRAN 78 network.
However, in the case of the location of a UA in E-UTRAN for a change-to-CS termination session, the location (CS service notification) sent by the MME to the UA in connected mode in the source network, only Packages (for example, PS) do not contain any "cause of location" information. This location notification may include information about the service for which the mobile telephone station is located.
In the event that the location is performed by reaching the UA in idle mode, the location message sent on the S1 interface and on the radio interface does not contain any indication of the service for which the UA is located. In addition, the upper layers do not specify what information should be passed to the RRC protocol for inclusion in the RRC Connection Request in response to a location that takes place in the E-UTRAN in the case of the CS change procedure. Again, in UTRAN, this could lead to inconsistent UA implementations and result in resource allocation or yields below optimal.
In the case of a call originating from a mobile phone in the GERAN or the UTRAN, the UA includes in the channel request / RRC Connection Request sent to the network some additional information, such as type of channel, cause of the establishment and others, allowing the network to assign an appropriate resource depending on the service requested. Turning now to Fig. 5, which is a variation of Fig. two but showing a data flow for a call originating from a mobile phone subject to change to CS, the data flow includes operation 24 to handle a service request from UA 10 to the network. The service type information element is included in the Extended Service Request message sent to the network. The information elements of the type of service are as shown in Table 2:
Service type value (octet 1) Service type value
<dl><dt>Bits </dt><dd /></dl>
<dl><dt>4 </dt><dd> 3 2 1 </dd></dl>
<dl><dt>0 </dt><dd /><dt>0 </dt><dd /><dt>0 </dt><dd /><dt>0 </dt><dd>Change to CS of origin in mobile phone or 1xchange to CS </dd></dl>
<dl><dt>0 </dt><dd /><dt>0 </dt><dd /><dt>0 </dt><dd>1 Change to CS termination on mobile phone or 1xchange to CS </dd></dl>
<dl><dt>0 </dt><dd /><dt>0 </dt><dd>1 0 Emergency call of change to CS of origin in mobile phone or 1x call of </dd></dl>
<dl><dt>emergency switch to CS </dt><dd /></dl>
All other values are reserved.
Table 2
However, this information element does not provide any information to the source network about the requested CS service, which, thus, does not allow the network to adequately size the resources that should be allocated according to the requested service and determine conditions optimal for transmitting the UA to the target CS network, for example, depending on the available channels and the load information, in the case that inter-RAT transfer or cell change order are supported.
In general, the present system and methods have been developed to reduce the delay and improve the reliability of a process of switching to CS. The change to CS can be implemented to move from an E-UTRAN to a GERAN, specifically, or, more generally, from a first network that does not provide CS domain services to a second network that provides CS domain service . For example, the change to CS can be implemented to allow the change from networks of the type of E-UTRAN to networks of the type of GERAN, UTRAN or CDMA2000. To this end, the present system and method facilitates the change to CS by allowing a UA to identify the most appropriate resources to provide the requested service and then request those resources when it is passed to a CS network during a change to CS. In an implementation of the present system, in UA it is configured to analyze the available location information received from the network to determine the most appropriate communication channel or radio resource to request an optimal CS switching performance.
To initiate the change to CS, a UA may first receive a location message from a source PS network (for example, an E-UTRAN network). The location message instructs the UA to implement a change to CS to a CS network (for example, a traffic network) to access a service. If the corresponding service can be determined using the information carried in the location message, the UA is configured to send a channel request message requesting a suitable channel type for that service in the CS network. In this way, based on one or more pieces of information contained in the location message, the UA is configured to request particular channel types when implementing a change to CS.
For example, when the location message is for a conversation call or for any call that requires a traffic channel, the UA can be configured to request a "TCH / H or TCH / F", or a "TCH" channel /F". Alternatively, when the location message is for activating a supplementary service independent of the call, or a location service, for example, the UA may request an SDCCH. In these examples, the selection of a “TCCH / H or TCH / F” channel may not require any particular preference for the selection of a medium speed (H - Half) or maximum speed (F - Full, in English). The network can determine a maximum or medium speed channel autonomously, depending on local conditions (network load status, quality of service preferences (QoS), etc.) . The selection of a TCH / F channel, however, can influence the network's decision about whether to select a channel of maximum or average speed.
In some circumstances, the location message will contain insufficient information for the US to determine the service for which the UA has been located. In that case, the UA can be configured to construct and send a channel information that reflects a type of channel "by default", for example using the value "any Channel" or some other indicator that identifies the channel by default.
Accordingly, in an example implementation of the present system, in the case of a CHANNEL REQUEST activated by a procedure of change to CS, such as that described in document TS 23.272 of the 3GPP, the content of the message of REQUEST FOR CHANNEL can be determined depending on the information that can be obtained from the location notification received in the radio access technology (RAT - Radio Access Technology, in English) from source about the service for which the mobile phone station is located. If no specific information can be obtained from the location notification, the content of the CHANNEL REQUEST message can be set for a Location indication value indicating "Any Channel". For example, the content of the CHANNEL REQUEST message can be encoded according to Table 3, the "Location Indication" entry being selected according to the above description to indicate the corresponding service.
<dl><dt>Indication of Location of MS Capacity (note 3) </dt><dd>Max speed only Dual Speed (note 5) SDCCH only </dd></dl>
<dl><dt>Any channel </dt><dd>100xxxxx 100xxxxx 100xxxxx </dd></dl>
<dl><dt>SDCCH</dt><dd> 0001xxxx 0001xxxx 0001xxxx </dd></dl>
<dl><dt>TCH / F </dt><dd>100xxxxx 0010xxxx 0001xxxx </dd></dl>
<dl><dt>TCH / H or TCH & F </dt><dd>100xxxxx 0011xxxx 0001xxxx </dd></dl>
Table 3
Alternatively, the UA can be configured to select a "TCH / H or TCH / F" channel, depending on whether a fast establishment or a radio resource saving is preferred (the preference can be stored as user preferences, or determined only by the network operator policy, for example), or some other factor that may require a particular default channel.
Depending on the implementation of the system, the UA can be configured with an explicit mapping between the service indicated by the location message and a type of channel to be requested during the change. In other cases, however, after determining the service indicated in the location message, the UA can determine the type of channel to be requested independently based on other information available to the UA. If there is no explicit mapping, and the UA can independently determine the type of channel to be requested, the UA may have more flexibility and can rely on other parts of available information when it identifies the type of channel to be requested. In contrast, an explicit mapping can exclude different interpolations and ensure consistency in the channel selected by a UA in response to a particular location message.
In an example of the present system, several information elements present in a CS Service Notification message transmitted between the MME and the UA can be inspected to determine the service for which the UA is located and can therefore allow that the UA request the most appropriate type of channel to provide that service. The calling line (CLI - Calling LIne, in English), the Supplementary Service Code, the LCS indicator and the LCS client identity channel elements, for example, can be included within a CS Service Notification Message and its presence or absence may be indicative of the service being selected. In general, the CLI contains the calling line identification for the termination call on the mobile phone in the CS domain that activated the location through the SGs. The SS Code information element contains information about the supplementary service transaction in the CS domain that activated the location through the SGs. The LCS indicator indicates that the location was activated by terminating the LCS request in the CS domain. The LCS client identity contains information regarding the requestor of the termination LCS request in the CS domain. Each of the information elements is sent by the network if they are originally received through SGs.
Table 4 illustrates a CS SERVICE NOTIFICATION message content.
<dl><dt>IEI </dt><dd>Information Element Type / Reference Presence Format Length </dd></dl>
<dl><dt>Protocol discriminator </dt><dd>Protocol discriminator 9.2 M V 1/2 </dd></dl>
<dl><dt>Type of security header </dt><dd>Type of security header 9.3.1 M V 1/2 </dd></dl>
<dl><dt>CS service notification message identity </dt><dd>Message Type 9.8 M V 1 </dd></dl>
<dl><dt>Location Identity </dt><dd>Location Identity 9.9.3.25A M V 1 </dd></dl>
<dl><dt>60</dt><dd> CLI CLI 9.9.3.38 OR TLV 3-14 </dd></dl>
<dl><dt>61 </dt><dd>SS code SS code 9.9.3.39 OR TV two </dd></dl>
<dl><dt>62 </dt><dd>LCS indicator LCS Indicator 9.9.3.40 OR TV two </dd></dl>
<dl><dt>63 </dt><dd>LCS customer identity LCS customer identity 9.9.3.41 OR TLV 3-257 </dd></dl>
Table 4
These information elements may originally be received from the MSC / Visitor Location Register (VLR) in a SGsAP LOCATION REQUEST message and transferred in the CS SERVICE NOTIFICATION message. The presence or absence of the information elements in the SGsAP LOCATION REQUEST message is governed by several sets of rules and is indicative of the type of service for which the change to CS has been requested. For example, if the location is due to an SS procedure Independent of the Call initiated on the network as defined in the
document TS 24.010 of the 3GPP, the VLR includes the SS code in the SGsAP LOCATION REQUEST message as defined in document TS 29.002 of the 3GPP. If, however, the location is due to a Location Request Completed on a Mobile Phone as defined in document TS 24.030 of the 3GPP, the VLR may include the LCS client identity and the LCS indicator as defined in the TS document
29.002 of the 3GPP in the SGSAP LOCATION REQUEST. In accordance with these rules, the different information elements are included in the SGsAP LOCATION REQUEST and are transmitted to the UA in the content of the CS SERVICE NOTIFICATION message. In this way, the presence or absence of one or more of these information elements allows the UA to make a determination about the service for which the UA has been located.
Table 5 illustrates an example SGsAP LOCATION REQUEST message content.
<dl><dt>Information element </dt><dd>Type / Reference Presence Format Length </dd></dl>
<dl><dt>Type of message </dt><dd>Message Type 9.2 M V 1 </dd></dl>
<dl><dt>IMSI </dt><dd>IMSI 9.4.6 M TLV 6-10 </dd></dl>
<dl><dt>VLR Name </dt><dd>VLR Name 9.4.22 M TLV 3-n </dd></dl>
<dl><dt>Service indicator </dt><dd>Service indicator 9.4.17 M TLV 3 </dd></dl>
<dl><dt>TMSI</dt><dd> TMSI 9.4.20 OR TLV 6 </dd></dl>
<dl><dt>CLI </dt><dd>CLI 9.4.1 OR TLV 3-14 </dd></dl>
<dl><dt>Location Area Identifier </dt><dd>Location Area Identifier 9.4.11 OR TLV 7 </dd></dl>
<dl><dt>CN Global Id </dt><dd>CN Global Id 9.4.4 OR TLV 7 </dd></dl>
<dl><dt>SS code </dt><dd>SS code 9.4.19 OR TLV 3 </dd></dl>
<dl><dt>LCS indicator </dt><dd>LCS Indicator 9.4.10 OR TLV 3 </dd></dl>
<dl><dt>LCS customer identity </dt><dd>LCS client identity 9.4.9 OR TLV 3-n </dd></dl>
<dl><dt>Channel needed </dt><dd>Channel needed 9.4.23 OR TLV 3 </dd></dl>
<dl><dt>EMLPP priority </dt><dd>EMLPP Priority 9.4.24 OR TLV 3 </dd></dl>
Table 5
As shown in Table 5, the SS code is included if the location is due an SS procedure Independent of the Call initiated on the network (see document TS 24.010 of the 3GPP). The LCS indicator is included if the location is due to a Termination Location Request on a Mobile Phone (see document TS 24.030 of the 3GPP). The identity of the LCS client is included if the location is due to a Termination Location Request on a Mobile Phone (see document TS 24.030 of the 3GPP). The information element necessary for the channel is included if the VLR intends to indicate which channel the UA should use.
The UA may also be configured to inspect additional information to determine the services indicated by a particular location request. Additional information may include other elements of information that may be added in the future, including those identified below.
The present system may also be configured to include information relating to a service available in the MME in location messages used to locate a UA in idle mode. For example, information related to a service may include information elements of the "SS code", LCS indicator "and" LCS client identity "described above. Information regarding a service can be communicated to the MME by the MSC / VLR about the SGs interface in the SGsAP LOCATION REQUEST message. In some cases, these information elements are already present in the CS Service Notification message used to locate a UA in connected mode and can therefore be added to the S1 Interface Location message by the MME and the RRC Radio Interface Location message on the E-UTRAN using the E-UTRAN RRC protocol. The additional information presented in the location messages can then be used when the UA is located in idle mode in addition to the case in which the UA is located in connected mode.
Table 6 illustrates a location message of an S1 interface that is modified to include the SS Code, the LCS indicator and LCS client identity information elements.
<dl><dt>IE Group Name </dt><dd>Presence Interval IE type and reference Semantic Description Criticality Assigned Criticality </dd></dl>
<dl><dt>Type of message </dt><dd>M 9.2.1.1 YES Ignore</dd></dl>
<dl><dt>EU Identity Index Value </dt><dd>M 9.2.3.10 YES Ignore </dd></dl>
<dl><dt>EU Location Identity </dt><dd>M 9.2.3.13 YES Ignore </dd></dl>
<dl><dt>Location DRX </dt><dd>OR 9.2.1.16 YES Ignore </dd></dl>
<dl><dt>CN domain </dt><dd>M 9.2.3.22 YES Ignore </dd></dl>
<dl><dt>List of IAIs </dt><dd>M YES Ignore</dd></dl>
<dl><dt>> TAI list item </dt><dd>1 to <maxnoofTAISs> EACH Ignore </dd></dl>
<dl><dt>>> TAI </dt><dd>M 9.2.3.16 -</dd></dl>
<dl><dt>CSG ID List </dt><dd>1 to <maxnoofCSGId> GLOBAL Ignore </dd></dl>
<dl><dt>> CSG Id </dt><dd>M 9.2.1.62 </dd></dl>
<dl><dt>SS code </dt><dd>OR 9.2.xy -</dd></dl>
<dl><dt>LCS indicator </dt><dd>OR 9.2.xy -</dd></dl>
<dl><dt>LCS customer identity </dt><dd>OR 9.2.xy -</dd></dl>
Table 6
Table 7 illustrates an E-UTRAN RRC protocol location message that is modified to include the SS Code, the LCS Indicator and the LCS client identity information elements.
Table 7
Referring to Table 7, the ss code (ss-Code, in English) conveys information regarding a supplementary service request initiated on the network. The Ics Indicator (Ics-Indicator) indicates that the origin of the message is due to an LCS request and the type of this request. The coding of the Ics Indicator is given by the value part of the information element of the LCS indicator in TS 24.301. The Ics Client Identity (Ics-Client-Identity, in English) carries information related to the client of an LCS request. The coding of the LCS client identity is given in subsection 17.7.13 of document TS 29.002 of the 3GPP.
Fig. 6 is an illustration of a message flow for implementing a change to CS in which relative information is passed to UA 10 within a location message. In stages 100, 102 and 104 a call terminated in a UA arrives at the MSC / VLR 140. In step 106, a SGsAP Location Request message is transmitted to the MME 20. The SGsAP Location request may include one or more information elements indicative of the type of service requested. In steps 108 and 110 the MME 20 sends a location message to UA 10. The Location message is modified to include one or more of the information elements described above. The presence or absence of one or more of the information elements allows the UA to identify the type of service for which the location message has been sent. As a result, in step 112 the UA may request an appropriate resource for the service. In step 114, in response to the service request, the MME 20 sends an initial UA context setting message. In step 116, 118 and 120, a PS transfer or, alternatively, a cell change assisted by a base station, or a RRC release with redirection, possibly followed by an update of the location area are completed. In step 122 the location response is transmitted to the RNC / BSC 142 from UA 10 and the location response is issued to the MSC / VLR 140 in step 124. If the MSC has not changed, the CS connection is established. in step 126 and the process of switching to CS is completed. If the MSC has changed, however, in step 128 the MSC / VLR 140 transmits a connection rejection to the RNC / BSC 142. In response, the RNC / BSC 142 transmits a signaling connection release to the UA 10 in step 130. At that point, an update of the location area and a retry of the roaming is initiated against the attempted change to CS in the stage. 132.
Alternatively, to facilitate the change to CS, an information element with Channel Need, when known to the MME, can be added to Location messages sent to a UA to locate the UA in idle mode or connected. For example, an information element with Channel Need may be added to the CS Service Notification NAS message (described above) transmitted between the MME and the UA, the S1 Interface Location message described above or the protocol of RRC radio interface described above. In some cases, the data used to be included in the information element with Channel Need is communicated to the MME through the MSC / VLR about the SGs interface in the SGsAP LOCATION REQUEST message, as described above. The information with Channel Need, when it exists within a location message, allows the UA to efficiently create an appropriate channel request message when the UA responds to the location of change to CS in the GERAN, since the same information it would exist in the GERAN location message (if it has been transmitted by the MSC / VLR).
To enable the UA located in the E-UTRAN for a Termination CS call on a Mobile Phone with change to send an appropriate establishment cause when responding on a UTRAN network, new mapping entries can be introduced. This would allow the UA to communicate to the network the appropriate establishment causes that reflect the service for which the UA is located, if the corresponding service can be evaluated from the information conveyed in the location message. In that case, the UA, when responding in the UTRAN to a location received in the source packet network (for example the E-UTRAN), may include the cause of mapping establishment communicated by the upper layers in the Request message RRC Connection.
As an example, the cause of establishment may be determined as follows: The cause of establishment may be "Termination conversation call" when the location received is for a conversation call
or for any other conversation CS call, or "High Priority Signaling of Termination" when the location received is to activate a separate call-independent supplementary service, or a location service.
If the service for which the UA is located cannot be evaluated based on the information available on the network, the 10 UA can use “Termination - unknown flow” as the cause of the establishment.
Table 8 illustrates an example mapping of the CS NAS procedure to an establishment cause.
<dl><dt>CS NAS procedure </dt><dd>RRC Establishment Cause (according to 3GPP TS 25.331 [23c] </dd></dl>
<dl><dt>Source CS conversation call </dt><dd>Call of Conversation of Origin </dd></dl>
<dl><dt>Source CS data call </dt><dd>Call of Conversation of Origin </dd></dl>
<dl><dt>CS emergency call </dt><dd>Emergency call </dd></dl>
<dl><dt>Call Re-establishment </dt><dd /><dt>Call Re-establishment </dt><dd /></dl>
<dl><dt>Location Update </dt><dd>Registry </dd></dl>
<dl><dt>IMSI separation </dt><dd>Separation </dd></dl>
<dl><dt>MO SMS via domain </dt><dd>Low Priority Origin Signaling </dd></dl>
<dl><dt>Supplementary services </dt><dd>High Priority Origin Signaling </dd></dl>
<dl><dt>Switching circuit localization response </dt><dd>Make equal to the value of the location cause used in receiving the location in the RRC layer </dd></dl>
<dl><dt>SS Part of Location Services </dt><dd>High Priority Origin Signaling </dd></dl>
<dl><dt>Response to location of switched circuits in case of change to Termination CS: </dt><dd /></dl>
<dl><dt>- CS termination conversation / data call </dt><dd>Termination Conversation Call </dd></dl>
<dl><dt>- Supplementary Services </dt><dd>High Priority Termination Signaling </dd></dl>
<dl><dt>- Location Services </dt><dd>High Priority Termination Signaling </dd></dl>
<dl><dt>- Undetermined </dt><dd>Termination - unknown cause </dd></dl>
Table 8
fifteen Several information elements, when they exist in a CS Service Notification message between the MME and the UA, can provide an indication of the service for which the mobile phone is located, including the "SS Code" information elements, the "LCS indicator" and the "LCS customer identity". The different elements of information can be received from the MSC / VLR in a message REQUEST OF
twenty SGsAP LOCATION as described above. The presence or absence of one of the different information elements may or may therefore allow the UA to make a determination about the service for which the UA is located. Any other information that the UA could access or be rejected by the UA from messages received from the network or from other sources can be used to determine the service for which the UA has been located. This may include new information elements.
25 added in the future, including those described above.
When you initiate a Call of Origin on a Mobile Phone (MO), the UA can be configured to provide additional information to the PS network describing the requested CS service for which the change to CS can be activated . In an implementation, the UA includes additional information in the message
30 Extended Service Request transmitted to the MME of the PS network describing the CS service that is requested. Similarly, additional information can be included in messages for the INITIAL CONTEXT RESET REQUEST, or the UA CONTEXT MODIFICATION REQUEST transmitted from the MME to the eNodeB using the S1 interface (see document TS 36.413 of the 3GPP).
35 Table 9 and Table 10 illustrate a modified Extended Service Request message that includes additional information describing the CS service requested by a UA that initiates an MO call that results in a change to CS.
<dl><dt>IEI </dt><dd>Information Element Type / Reference Presence Format Length </dd></dl>
<dl><dt>Protocol discriminator </dt><dd>Protocol discriminator 9.2 M V 1/2 </dd></dl>
<dl><dt>Type of security header </dt><dd>Type of security header 9.3.1 M V 1/2 </dd></dl>
<dl><dt>Extended service request message identity </dt><dd>Message Type 9.8 M V 1 </dd></dl>
<dl><dt>Type of service </dt><dd>Type of Service 9.9.3.27 M V 1/2 </dd></dl>
<dl><dt>NAS key set identifier </dt><dd>NAS Key Set Identifier 9.9.3.21 M V 1/2 </dd></dl>
<dl><dt>M-TMSI </dt><dd>Mobile phone identity 9.9.2.3 M LV 6 </dd></dl>
<dl><dt>B-</dt><dd>CSFB response CSFB response 9.9.3.5 C TV 1 </dd></dl>
<dl><dt>C-</dt><dd>Cause of extended service request 9.9.x extended service request cause C TV 1 </dd></dl>
Table 9
As shown in Table 9 and Table 10, the Extended Service Request message shown in Table 9 includes an additional item called "Cause of Extended Service Request". The detail of the extended service request cause information element is shown in Table 10. The extended service request cause element is configured to store an identifier value in octet 1 that describes the requested CS service. For example, the identifier can be used to refer to CS services such as Call of Conversation of Origin, Signaling of High Priority of Origin or Signaling of Low Priority of Origin. Table 11 illustrates an example configuration of octet 1 of the extended service request cause information element.
Extended service request cause value (octet 1) Bits
<dl><dt>3 </dt><dd> 2 1 </dd></dl>
<dl><dt>0 </dt><dd /><dt>0 </dt><dd /><dt>0 </dt><dd>Call of Conversation of Origin </dd></dl>
<dl><dt>0 </dt><dd /><dt>0 </dt><dd>1 High Priority Origin Signaling </dd></dl>
<dl><dt>0 </dt><dd>1 0 Low Priority Origin Signaling </dd></dl>
All other values are reserved.
Table 11
In some cases, the existing Service type information element present in the Extended Service Request messages can be modified and used to identify the CS service being requested. Alternatively, additional information elements indicating the source service, such as the "SS Code"
or the "LCS Indicator" defined by the Service Notification message may be included in the message when the UA initiates a Call of Origin on a Mobile Phone. In another example, the CS service information may be included in the RCR Connection Request message (see document TS 36.331 of the 3GPP) that can be used to switch to the UA from standby mode to the connected mode when initiating a Origin call in a Mobile Phone subject to change to CS.
Fig. 7 shows an example block diagram of UA 10. Although a variety of known components of UAs 10 are shown, in one embodiment a subset of the listed components and / or additional unlisted components may be included in the UA 10. The UA 10 includes a processor such as a Digital Signal Processor (DSP) 802 and an 804 memory. As shown, UA 10 may also include an antenna and a front end unit 806, a radio frequency (RF) transceiver
- Radio Frequency, 808 and an analog baseband processing unit 810. In various configurations, the UA 10 may include additional optional components as illustrated in Fig. 7. Additional components may include, for example, a microphone 812, an ear speaker 814, a helmet port 816, an input / output interface 818, a removable memory card 820, a universal serial bus port (USB - Universal Serial Bus, in English 822, a short-range wireless communication subsystem 824, an alert 826, a numeric keypad 828, a liquid crystal display (Liquid Crystal Display), which may include a touch-sensitive surface 830, an LCD controller 832, a camera of coupled charging device (CCD - Charge Coupled Device, in English), a camera controller 836 and a global positioning system sensor (GPS - Global Positioning System, in English) 838. In one embodiment, UA 10 may include another type of display that does not provide a touch-sensitive screen. In one embodiment, the DSP 802 can communicate directly with the memory 804 without passing through the input / output interface 818.
The DSP 802 or some other form of controller or central processing unit operates to control the different components of UA 10 according to embedded software or firmware stored in memory 804 or stored in a memory contained within the DSP 802 itself. In addition to the embedded software or firmware, the DSP 802 can run other applications stored in memory 804 or that are available through information-carrying means such as portable data storage media such as the 820 removable memory card or through wired or wireless network communications. The application software may comprise a compiled set of instructions readable by a machine that configure the DSP 802 to provide the desired functionality, or the application software may be high-level software instructions to be processed by an interpreter or compiler to configure indirectly the DSP
802.
The antenna and the front end unit 806 can be provided to convert between the wireless signals and the electrical signals, allowing the UA 10 to send and receive information from a cellular network or some other available wireless communications network or from a corresponding UA 10. In one embodiment, the antenna and front end unit 806 may include antennas to support beam-forming and / or multi-input multiple output operations (MIMO). As is known to those skilled in the art, MIMO operations can provide spatial diversity that can be used to solve difficult channel conditions and / or increase channel performance. The antenna and front end unit 806 may include antenna tuning components and / or impedance matching components, RF power amplifiers and / or low noise amplifiers.
The RF transceiver 808 provides frequency deviation, converting received RF signals to baseband and converting baseband transmission signals to RD. In some descriptions it can be understood that a radio transceiver or an RF transceiver includes other signal processing functionality such as modulation / demodulation, coding / decoding, interleaving / deinterleaving, diffusion / concentration, fast reverse Fourier transform (IFFT - Inverse Fast Fourier Transforming, in English / Fast Fourier Transforming (FFT), assignment / elimination of cyclic prefix and other signal processing functions. For the purpose of clarity, the description here separates the description of this signal processing from the RF and / or radio stage and conceptually assigns the signal processing to the analog baseband processing unit 810 and / or the DSP 802 or other central processing unit. In some embodiments, the RF transceiver 808, antenna and front end portions 806, and the analog baseband processing unit 810 can be combined into one or more processing units and / or integrated circuits specific to an application. (ASICs - Application Specific Integrated Circuits, in English). The analog baseband processing unit 810 can provide various analog processing of inputs and outputs, for example, analog processing of inputs from microphone 812 and headphones 810 and outputs to headset 814 and headphones 816.
The DSP 802 can perform modulation / demodulation, coding / decoding, interleaving / deinterleaving, diffusion / concentration, inverse Fast Fourier Transforming (IFFT) / Fast Fourier Transforming (FFT - Fast Fourier Transforming) , in English), assignment / deletion of cyclic prefix and other signal processing functions associated with wireless communications. In one embodiment, for example in a code division multiple access (CDMA) application, for a transmission function the DSP 802 may perform modulation, coding, interleaving and broadcasting, and for a reception function the DSP 802 can carry out concentration, deinterleaving, decoding and demodulation. In another embodiment, for example in an orthogonal frequency division multiple access technology (OFDMA) application, for the transmission function of the DSP 802 you can perform modulation, coding, interleaving, Inverse Fast Fourier transform and cyclic prefixing and for a reception function the DSP 802 can carry out cyclic prefix elimination, Fast Fourier transform, deintercalado, decoding and demodulation. In other wireless technology applications, other signal processing functions and combinations of signal processing functions can be performed by the DSP 802. The DSP 802 can communicate with a wireless network via the band processing unit. 810 analog base.
Fig. 8 illustrates a software environment 902 that can be implemented by a UA processor or controller
10. The software environment 902 includes operating system activators 904 that are executed by the processor or controller of the UA 10 to provide a platform from which the rest of the software operates. The operating system activators 904 provide activators for the UA hardware with standardized interfaces that are accessible to the application software. The operating system activators 904 include application management services ("AMS" - "Application Management Services") 906 that transfer control between applications running on UA 10. Also shown in Fig. 8 are a navigation application Network 908, a 910 media execution application and Java 912 applet-type programs.
The UA 10 includes a processing component such as a DSP that is capable of executing instructions relative to the actions described above. Fig. 9 illustrates an example of a system 1000 that includes one or more of the components that provides the functionality of UA 10. System 1000 includes a processing component 1010 suitable for implementing one or more embodiments described herein. In addition to the 1010 processor (which can be referred to as a central processor unit (CPU - Central Processor Unit, or DSP), the system 1000 could include 1020 network connectivity devices, a random access memory (RAM). ) 1030, a read-only memory (ROM) 1040, a secondary store 1050 and 1060 input / output (I / O) devices. In some cases, some of these components may not be present or may be combined in various combinations with another or with other components not shown. Any action described herein as taken by processor 1010 could be taken by processor 1010 alone or by processor 1010 together with one or more components shown or not shown in the drawing.
The processor 1010 executes instructions, codes, computer programs, or routines that it could access from network connectivity devices 1020, RAM 1030, ROM 1040, or secondary store 1050 (which could include several disk-based systems, such as disk hard, floppy disk or optical disk). Although only one 1010 processor is shown, there may be multiple processors. Thus, although the instructions can be explained as executed by a processor, the instructions can be executed simultaneously, in series
or if not by one or by multiple processors. The 1010 processor can be implemented as one or more CPU microprocessors.
The network connectivity devices 1020 may include one or more transceiver components 1025 capable of transmitting and / or receiving data wirelessly in the form of electromagnetic waves, such as radio frequency signals or microwave frequency signals. The transceiver component 1025 could include separate reception and transmission units or a single transceiver. Information transmitted or received by transceiver 1025 may include data that has been processed by processor 1010 or instructions that must be executed by processor 1010. Such information may be received from and sent from a network in the form, for example, of a Computer base band signal or signal made on the carrier wave. The data can be ordered according to different sequences as it may be desirable either to process or to generate the data or to transmit or receive the data. The baseband signal, the signal embedded in the carrier wave, or other types of signals currently used or developed in the following may be referred to as a transmission medium and can be generated according to several methods well known to a person skilled in the art .
RAM 1030 could be used to store volatile data and perhaps to store instructions that are executed by processor 1010. ROM 1040 is a volatile memory device that typically has a lower memory capacity than the memory capacity of secondary storage 1050. ROM 1040 could be used to store instructions and perhaps data that is read during the execution of the instructions.
Access to both RAM 1030 and ROM 1040 is typically faster than secondary storage 1050.
1060 I / O devices can include liquid crystal displays (LCDs), touch screen displays, keyboards, numeric keypads, switches, markers, mice, tracking balls, voice recognizers, readers card, paper tape readers, printers, video monitors or other well-known input / output devices. Also, the transceiver 1025 could be considered as a component of the I / O devices 1060 instead of or in addition to being a component of the network connectivity devices 1020. Some or all of the I / O devices 1060 can be substantially similar to several representative components in the previously described drawing of UA 10, such as device 702 and input 704.
Although several embodiments have been provided in the present description, it will be apparent that the systems and methods described can be performed in many other specific ways. The present examples should be considered as illustrative and not restrictive. For example, the different elements or components may be combined or integrated into other systems or certain features may be omitted or not implemented.
Also, techniques, systems, subsystems and methods described and illustrated as discrete or separate can be combined or integrated with other systems, modules, techniques or methods. Other elements shown or explained as coupled or directly coupled or communicating with each other may be indirectly coupled or communicated through some interface, or otherwise. Other examples of changes, substitutions and alterations are established by a person skilled in the art.
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
25 members in 10 offices
Members25
| Document | Office | Kind | |
|---|---|---|---|
| EP2320698A1 | European Patent Office (EPO) | A1 | |
| CA2779737A1 | Canada | A1 | |
| US2011110302A1 | United States of America | A1 | |
| WO2011054089A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2012014345A1 | United States of America | A1 | |
| EP2320698B1 | European Patent Office (EPO) | B1 | |
| CN102598845A | China | A | |
| KR20120085857A | Republic of Korea | A | |
| EP2506632A1 | European Patent Office (EPO) | A1 | |
| ES2390813T3This record | Spain | T3 | |
| JP2013510471A | Japan | A | |
| HK1173600A | Hong Kong, China | A | |
| HK1173600A1 | Hong Kong, China | A1 | |
| JP5520386B2 | Japan | B2 | |
| KR101445460B1 | Republic of Korea | B1 | |
| US8929310B2 | United States of America | B2 | |
| CN102598845B | China | B | |
| US2015071252A1 | United States of America | A1 | |
| BR112012010965A2 | Brazil | A2 | |
| EP2506632B1 | European Patent Office (EPO) | B1 | |
| US9532274B2 | United States of America | B2 | |
| CA2779737C | Canada | C | |
| US2017195923A1 | United States of America | A1 | |
| US10172045B2 | United States of America | B2 | |
| BR112012010965B1 | Brazil | B1 |
Numbers
- Publication
- 2390813
- Application
- 9306075
Titles2
- Spanish
- Determinación de un tipo de canal para ser solicitado en caso de un procedimiento de cambio de circuito conmutado
- English
- Determination of a type of channel to be requested in case of a switched circuit change procedure
Classification
- CPC, 7
- H04W36/0022
- H04W36/14
- H04W68/12
- H04W72/21
- H04W68/02
- H04W88/06
- H04W68/005
- IPC, 1
- H04W36 00