Patent Description:
Wireless mobile devices or user equipments (UEs) may communicate with each other via cellular networks using radio access technologies such as the 3GPP Long-Term Evolution ("LTE") standard, 3GPP LTE Advanced Release <NUM> (March <NUM>) (the "LTE-A Standard"), the IEEE <NUM> standard, IEEE Std. <NUM>-<NUM>, published May <NUM>, <NUM> ("WiMAX"), as well as any other wireless protocols that are designated as <NUM>, <NUM>, <NUM>, and beyond. User equipments (UEs) can be configured to connect to one or more cellular networks and one or more non-cellular networks, such as wireless local area networks (WLANs).

<CIT> relates to an apparatus that includes a Mobile Termination (MT) that offers functions related to communication with a network, a Terminal Equipment (TE) that offers services to a user of the apparatus, and a Terminal Adaptor (TA) that allows communication between the MT and the TE using Attention (AT) commands. A packet domain event reporting command (+CGEREP) is one type of AT command that enables or disables sending of result codes from the MT to the TE in case certain events occur in the MT for a packet domain or in the network. One such type of event is a Packet Data Protocol (PDP) context activation, for which the MT sends to the TE a result code that includes an integer type parameter to indicate the reason why a context activation request with PDP type IPv4v6 was not granted, and a context id parameter to indicate the capability of Mobile Termination for autonomously requesting a second address bearer, and the result of the second address bearer activation.

<CIT> relates to a method for a User Equipment (UE). The method includes responsive, at least in part, to an ATtention (AT) command for touch-sensitive display action, emulating or reporting a meta-navigation gesture for a touch-sensitive input including a display area and a non-display area.

<NPL>, specifies a profile of AT commands and recommends that this profile be used for controlling Mobile Termination (MT) functions and GSM/UMTS network services from a Terminal Equipment (TE) through Terminal Adaptor (TA).

Advantageous embodiments are subject to the dependent claims.

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments can incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments can be included in, or substituted for, those of other embodiments.

In some embodiments, mobile devices or other devices described herein can be part of a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, a wearable mobile computing device (e.g., a mobile computing device included in a wearable housing), an instant messaging device, a digital camera, an access point, a television, a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or another device that can receive and/or transmit information wirelessly. In some embodiments, the mobile device or other device can be a user equipment (UE) or an evolved node-B (eNodeB) configured to operate in accordance with 3GPP standards (e.g., the <NUM> GPP Long Term Evolution ("LTE") Advanced Release <NUM> (March <NUM>) (the "LTE-A Standard")). In some embodiments, the mobile device or other device can be configured to operate according to other protocols or standards, including IEEE <NUM><NUM> or other IEEE and 3GPP standards. In some embodiments, the mobile device or other device can include one or more of a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements. The display can be a liquid crystal display (LCD) screen including a touch screen.

<FIG> illustrates an architecture of a wireless network with various components of the network in accordance with some embodiments. A system <NUM> is shown to include a user equipment (UE) <NUM> and a UE <NUM>. The UEs <NUM> and <NUM> are illustrated as smartphones (i.e., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but can also include personal digital assistants (PDAs), pagers, laptop computers, desktop computers, a machine-to-machine (M2M) device, an internet of things (IoT) device, etc..

The UEs <NUM> and <NUM> are configured to access a radio access network (RAN) <NUM> via connections <NUM> and <NUM>, respectively, each of which comprises a physical communications interface or layer; in this embodiment, the connections <NUM> and <NUM> are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, etc..

The RAN <NUM> can include one or more access points that enable the connections <NUM> and <NUM>. These access points (described in further detail below) can be referred to as access nodes, base stations (BSs), NodeBs, evolved NodeBs (eNodeBs), etc., and can comprise ground stations (i.e., terrestrial access points) or satellite access points. The RAN <NUM> is shown to be communicatively coupled to a core network <NUM>. The core network <NUM> can be used to enable a packet-switched data exchange with the Internet <NUM> in addition to bridging circuit-switched calls between the UEs <NUM> and <NUM>. In some embodiments, the RAN <NUM> can comprise an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial RAN (E-UTRAN <NUM>), and the core network <NUM> can comprise an Evolved Packet Core (EPC) network.

The UE <NUM> is shown to be configured to access an access point (AP) <NUM> via a connection <NUM>. The connection <NUM> can comprise a local wireless connection, such as a connection consistent with IEEE <NUM>, wherein the AP <NUM> would comprise a wireless fidelity (WiFi) router. In this example, the AP <NUM> is shown to be connected to the Internet <NUM> without connecting to the core network <NUM>.

The Internet <NUM> is shown to be communicatively coupled to an application server <NUM>. The application server <NUM> can be implemented as a plurality of structurally separate servers, or can be included in a single server. The application server <NUM> is shown as connected to both the Internet <NUM> and the core network <NUM>; in other embodiments, the core network <NUM> connects to the application server <NUM> via the Internet <NUM>. The application server <NUM> can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, Push-to-Talk (PTT) sessions, group communication sessions, social networking services, etc.) for UEs that can connect to the application server <NUM> via the core network <NUM> and/or the Internet <NUM>. The application server <NUM> can also be configured as a cloud services provider (CSP) for cellular Internet of Things (CIoT) UEs, as described in further detail below.

The core network <NUM> is further shown to be communicatively coupled to an Internet Protocol (IP) Multimedia Subsystem (IMS) <NUM>. The IMS <NUM> comprises an integrated network of telecommunications carriers that can enable the use of IP for packet communications, such as traditional telephony, fax, e-mail, internet access, Voice over IP (VoIP), instant messaging (IM), videoconference sessions and video on demand (VoD), etc..

<FIG> illustrates an architecture of components of an LTE network in accordance with some embodiments. In this example, a (sub)system <NUM> comprises an Evolved Packet System (EPS) on an LTE network, and thus includes an E-UTRAN <NUM> and an EPC network <NUM> communicatively coupled via an S1 interface <NUM>. In this illustration, only a portion of the components of the E-UTRAN <NUM> and the EPC network <NUM> are shown. Some of the elements described below may be referred to as "modules" or "logic. " As referred to herein, "modules" or "logic" may describe hardware (such as a circuit), software (such as a program driver), or a combination thereof (such as a programmed microprocessing unit).

The E-UTRAN <NUM> includes eNodeBs <NUM> (which can operate as base stations) for communicating with one or more UEs (e.g., the UE <NUM>). The eNodeBs <NUM> are shown in this example to include macro eNodeBs and low-power (LP) eNodeBs. Any of the eNodeBs <NUM> can terminate the air interface protocol and can be the first point of contact for the UE <NUM>. In some embodiments, any of the eNodeBs <NUM> can fulfill various logical functions for the E-UTRAN <NUM> including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. eNodeBs in EPS/LTE networks, such as the eNodeBs <NUM>, do not utilize a separate controller (i.e., an RNC) to communicate with the EPC network <NUM>; in other embodiments utilizing other specification protocols, RANs can include an RNC to enable communication between BSs and core networks <NUM>.

In accordance with some embodiments, the UE <NUM> can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with any of the eNodeBs <NUM> over a multicarrier communication channel in accordance with various communication techniques, such as an Orthogonal Frequency-Division Multiple Access (OFDMA) communication technique or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique, although the scope of the embodiments is not limited in this respect.

In accordance with some embodiments, the UE <NUM> can be configured to determine a synchronization reference time based on reception of one or more signals from any of the eNodeBs <NUM>. The UE <NUM> can also be configured to support device-to-device (D2D) or proximity-based services (ProSE) communication with other UEs using OFDMA, SC-FDMA, or other multiple access schemes.

The S1 interface <NUM> is the interface that separates the E-UTRAN <NUM> and the EPC network <NUM>. It is split into two parts: the S1-U, which carries traffic data between the eNodeBs <NUM> and a serving gateway (S-GW) <NUM>, and the S1-MME, which is a signaling interface between the eNodeBs <NUM> and one or more mobility management entities (MMEs) <NUM>. An X2 interface is the interface between the eNodeBs <NUM>. The X2 interface can comprise two parts (not shown): the X2-C and X2-U. The X2-C is the control plane interface between the eNodeBs <NUM>, while the X2-U is the user plane interface between the eNodeBs <NUM>.

With cellular networks, low-power cells can be used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with very dense phone usage, such as train stations. As used herein, the term "LP eNodeB" refers to any suitable relatively low-power eNodeB <NUM> for implementing a narrower cell (i.e., narrower than a macro cell) such as a femtocell, a picocell, or a micro cell at the edge of the network. Femtocell eNodeBs are typically provided by a mobile network operator to its residential or enterprise customers. A femtocell is typically the size of a residential gateway or smaller, and generally connects to the user's broadband line. Once plugged in, the femtocell connects to the mobile operator's mobile network and provides extra coverage in a range of typically <NUM> to <NUM> meters for residential femtocells. Thus, an LP eNodeB might be a femtocell eNodeB since it is coupled through a packet data network gateway (P-GW) <NUM>. Similarly, a picocell is a wireless communication system typically covering a small area, such as in-building (offices, shopping malls, train stations, etc.) or, more recently, in-aircraft. A picocell eNodeB can generally connect through the X2 link to another eNodeB <NUM> such as a macro eNodeB through its base station controller (BSC) functionality. Thus, an LP eNodeB can be implemented with a picocell eNodeB since it is coupled to a macro eNodeB via an X2 interface. Picocell eNodeBs or other LP eNodeBs can incorporate some or all functionality of a macro eNodeB. In some cases, a picocell eNodeB can be referred to as an access point base station (AP BS) or enterprise femtocell.

The UE <NUM> performs cell selection upon power-up and cell reselections throughout its operation. The UE <NUM> searches for a cell provided by the E-UTRAN <NUM> (e.g., a macro cell or a picocell). During the cell reselection process, the UE <NUM> can measure reference signal strength for each neighboring cell (e.g., Reference Signal Received Power/Reference Signal Received Quality (RSRP/RSRQ)) and select a cell based on this measurement (e.g., select a cell with the highest RSRP value). After the UE <NUM> selects a cell, it can verify the accessibility of the cell by reading the master information block (MIB). If the UE <NUM> fails to read the MIB of the selected cell, it can discard the selected cell and repeat the above process until a suitable cell is discovered.

A radio resource control (RRC) state indicates whether an RRC layer of the UE <NUM> is logically connected to an RRC layer of the E-UTRAN <NUM>. After the UE <NUM> is communicatively coupled to a cell, its RRC state is RRC_IDLE. When the UE <NUM> has data packets to transmit or receive, its RRC state becomes RRC_CONNECTED. The UE <NUM>, when in an RRC_IDLE state, can associate itself to different cells.

In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the eNodeBs <NUM> to the UE <NUM>, while uplink transmission from the UE <NUM> to any of the eNodeBs <NUM> can utilize similar techniques. Each resource block comprises a collection of resource elements; in the frequency domain, this represents the smallest quantity of resources that currently can be allocated.

The physical downlink shared channel (PDSCH) carries user data and higher-layer signaling to the UE <NUM>. The physical downlink control channel (PDCCH) carries information about the transport format and resource allocations related to the PDSCH channel, among other things. It also informs the UE <NUM> about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE <NUM> within a cell) is performed at any of the eNodeBs <NUM> based on channel quality information fed back from the UE <NUM> to any of the eNodeBs <NUM>, and then the downlink resource assignment information is sent to the UE <NUM> on the control channel (PDCCH) used for (assigned to) the UE <NUM>.

The PDCCH uses control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols are first organized into quadruplets, which are then permuted using a sub-block inter-leaver for rate matching. Each PDCCH is transmitted using one or more of these CCEs, where each CCE corresponds to nine sets of four physical resource elements known as resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols are mapped to each REG.

The EPC network <NUM> includes the MMEs <NUM>, the S-GW <NUM>, the P-GW <NUM>, and a home subscriber server (HSS) <NUM>. The MMEs <NUM> are similar in function to the control plane of legacy serving general packet radio service (GPRS) support nodes (SGSN). The MMEs <NUM> manage mobility aspects in access such as gateway selection and tracking area list management. The HSS <NUM> comprises a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The EPC network <NUM> may comprise one or several HSSs <NUM>, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS <NUM> can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc..

The S-GW <NUM> terminates the interface toward the E-UTRAN <NUM>, and routes data packets between the E-UTRAN <NUM> and the EPC network <NUM>. In addition, it can be a local mobility anchor point for inter-eNodeB handovers and also can provide an anchor for inter-3GPP mobility. Other responsibilities can include lawful intercept, charging, and some policy enforcement.

The S-GW <NUM>, the MMEs <NUM>, and the HSS <NUM> can be implemented in one physical node or separate physical nodes. The P-GW <NUM> terminates an SGi interface (not illustrated) toward the packet data network (PDN). The P-GW <NUM> routes data packets between the EPC network <NUM> and external networks (e.g., the Internet <NUM>), and can be a key node for policy enforcement and charging data collection. The P-GW <NUM> and S-GW <NUM> can be implemented in one physical node or separated physical nodes. In this embodiment, the EPC network <NUM> is shown to be communicatively coupled to the application server <NUM>, wherein packet data can be exchanged via the P-GW <NUM>.

<FIG> illustrates example components of a UE device <NUM> in accordance with some embodiments. In some embodiments, the UE device <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, radio frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM> and one or more antennas <NUM>, coupled together at least as shown. In some embodiments, the UE device <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface.

The baseband circuitry <NUM> may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a second generation (<NUM>) baseband processor 304a, third generation (<NUM>) baseband processor 304b, fourth generation (<NUM>) baseband processor 304c, and/or other baseband processor(s) 304d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (<NUM>), <NUM>, etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 304a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include fast-Fourier transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include convolution, tail-biting convolution, turbo, Viterbi, and/or low density parity check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include elements of a protocol stack such as, for example, elements of an EUTRAN protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or RRC elements. A central processing unit (CPU) 304e of the baseband circuitry <NUM> may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry <NUM> may include one or more audio digital signal processor(s) (DSP) 304f. The audio DSP(s) 304f may be or include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry <NUM> may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board, in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together, such as, for example, on a system on a chip (SOC).

Embodiments in which the baseband circuitry <NUM> is configured to support radio communications of more than one wireless protocol may be referred to as multimode baseband circuitry <NUM>.

In various embodiments, the RF circuitry <NUM> may include switches, filters, amplifiers, etc., to facilitate the communication with the wireless network.

In some embodiments, the RF circuitry <NUM> may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry <NUM> may include mixer circuitry 306a, amplifier circuitry 306b and filter circuitry 306c. The transmit signal path of the RF circuitry <NUM> may include filter circuitry 306c and mixer circuitry 306a. RF circuitry <NUM> may also include synthesizer circuitry 306d for synthesizing a frequency for use by the mixer circuitry 306a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 306a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 306d. The amplifier circuitry 306b may be configured to amplify the down-converted signals and the filter circuitry 306c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals. In some embodiments, mixer circuitry 306a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 306a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 306d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 306c. The filter circuitry 306c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may be configured for superheterodyne operation.

In some dual-mode embodiments, a separate radio integrated circuit (IC) circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 306d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 306d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 306d may be configured to synthesize an output frequency for use by the mixer circuitry 306a of the RF circuitry <NUM> based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 306d may be a fractional N/N+<NUM> synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO). Divider control input may be provided by either the baseband circuitry <NUM> or the applications processor <NUM>, depending on the desired output frequency.

Synthesizer circuitry 306d of the RF circuitry <NUM> may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 306d may be configured to generate a carrier frequency as the output frequency while, in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry <NUM> may include an IQ/polar converter.

The FEM circuitry <NUM> may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry <NUM> may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry <NUM>).

<FIG> is an illustration of a UE device as mobile termination (MT) and terminal equipment (TE) functional blocks in accordance with the present invention. A UE <NUM> is illustrated as including a TE <NUM> and an MT <NUM> communicatively coupled via a terminal adaptor (TA) <NUM>. In some embodiments, the TE <NUM> includes application circuitry (e.g., the application circuitry <NUM> of the UE <NUM> of <FIG>) and the MT <NUM> includes baseband circuitry (e.g., the baseband circuitry <NUM> of the UE <NUM> of <FIG>). One or more applications <NUM> may utilize one or more PDN connections, and can transmit data to the TE <NUM> indicating an application type (e.g., web browser, streaming application, etc.), quality of service (QoS) parameters of the application <NUM>, etc. The MT <NUM> may interact with one or more networks <NUM> via any of the components illustrated in <FIG> and/or <FIG> (e.g., components of the E- UTRAN <NUM> and the EPC <NUM> of <FIG>).

The abstract architecture of UE <NUM> can be physically implemented in various ways. In some embodiments, the TE <NUM>, the MT <NUM>, and the TA <NUM> are implemented as three separate entities. In some embodiments, the TA <NUM> is integrated under the MT <NUM> cover, and the TE <NUM> is implemented as a separate entity. In some embodiments, the TA <NUM> is integrated under the TE <NUM> cover, and the MT <NUM> is implemented as a separate entity. In some embodiments, the TA <NUM> and the MT <NUM> are integrated under the TE <NUM> cover as a single entity.

<FIG> illustrates a flow diagram of a process for an MT <NUM> and a TE <NUM> of a UE <NUM> device to exchange information in accordance with some embodiments. Process and logical flow diagrams as illustrated herein provide examples of sequences of various process actions. Although the actions are shown in a particular sequence or order, unless otherwise specified, the order of the actions may be modified. Thus, the described and illustrated implementations should be understood only as examples, and the illustrated processes may be performed in a different order, and some actions may be performed in parallel. Additionally, one or more actions may be omitted in various embodiments; thus, not all actions are executed in every implementation. Other process flows are possible.

The one or more applications <NUM> may be executed via the UE <NUM> for utilizing PDNs. The one or more applications <NUM> may indicate a command for the TE <NUM> to control the MT <NUM> (shown as operation <NUM>). The TE <NUM> sends attention (AT) commands to the TA <NUM> (shown as operation <NUM>), which are then parsed as MT control commands (shown as operation <NUM>).

The AT commands can include, for example, general commands, call control commands, network service related commands, MT control and status commands, MT errors result codes, commands for packet domain, commands for voice group call service (VGCS) and voice broadcast service (VBS), and commands for the Universal Subscriber Identity Module (USIM) Application Toolkit.

The MT <NUM> may transmit and receive signal data to and from the one or more networks <NUM> (shown as operations <NUM> and <NUM>, respectively), including non-access stratum (NAS) messages for establishing PDN connections and maintaining PDN connections as the UE <NUM> moves. The MT <NUM> can send MT status messages to the TA <NUM> (shown as operation <NUM>), which the TA <NUM> sends to the TE <NUM> as responses to the AT commands (shown as operation <NUM>). Data from these responses may then be transmitted to the one or more applications <NUM> (shown as operation <NUM>).

Thus, AT commands provide a way for the TE <NUM> to control the MT <NUM>. The UE <NUM> may be coupled to a cellular network and/or a non-cellular network (e.g., a WLAN). When the UE <NUM> is initially coupled to a cellular network and then subsequently also connects to a non-cellular network, the UE <NUM> may perform traffic offloading - i.e., offloading a PDN connection to the non-cellular network. Cellular network components (e.g., the PGW <NUM> of <FIG>) may decide which PDN connection is to be offloaded to the non-cellular network, and provide this information to the MT <NUM> via one or more NAS messages.

In some embodiments, existing AT commands sent by the TE <NUM> and their associated responses sent by the MT <NUM> are modified so that they may indicate to the TE <NUM> which PDN connections can be offloaded to the non-cellular network.

<FIG> illustrate command/response tables for modified AT commands in accordance with some embodiments. As described below, these modified AT commands allow for a TE <NUM> to receive data indicating offload-ability characteristics for specific PDN connections, and also allow for a TE to independently query and determine WLAN offload characteristics of individual primary and secondary packet data protocol (PDP) contexts of a PDN connection. The command/response tables described below may be used in a variety of cellular communications protocols, such as 3GPP (LTE) protocols, legacy 3GPP UMTS Terrestrial Radio Access Network (UTRAN) network protocols, and so forth.

For the purposes of the illustrated command/response tables, the following syntactical definitions apply:.

underline Underlined defined subparameter value is the recommended default setting of this subparameter. In parameter type commands, this value should be used in factory settings which may be configured, for example, by ITU-T Recommendation V. <NUM>: "Serial asynchronous automatic dialing and control. " In action type commands, this value should be used when subparameter is not given.

<FIG> illustrates a command/response table <NUM> for the packet domain event reporting (+CGEREP) AT command. In this embodiment, the +CGREP command is updated to provide WLAN offload characteristics of a PDN connection, when the PDN connection is activated, deactivated or modified.

More specifically, with regard to the +CGREP command, set command enables or disables sending of unsolicited result codes, +CGEV : XXX from MT to TE in the case of certain events occurring in the Packet Domain MT or the network. <mode> controls the processing of unsolicited result codes specified within this command. <bfr> controls the effect on buffered codes when <mode> <NUM> or <NUM> is entered. If a setting is not supported by the MT, ERROR or +CME ERROR: is returned. Refer subclause <NUM> for possible <err> values may comprise, for example, values defined in subclause <NUM> of <NPL>.

Read command returns the current mode and buffer settings
Test command returns the modes and buffer settings supported by the MT as compound values.

Defined events are valid for GPRS/UMTS and LTE.

For network attachment, the following unsolicited result codes and the corresponding events are defined:.

For MT class, the following unsolicited result codes and the corresponding events are defined:.

For PDP context activation, the following unsolicited result codes and the corresponding events are defined:.

For PDP context deactivation, the following unsolicited result codes and the corresponding events are defined:.

For PDP context modification, the following unsolicited result codes and the corresponding events are defined:.

For other PDP context handling, the following unsolicited result codes and the corresponding events are defined:.

<FIG> illustrates a command/response table <NUM> for the PDP context read dynamic parameters (+CGCONTRDP) command. In this embodiment, the +CGCONTRDP command can be used to query WLAN offload characteristics of any active PDN connection associated with a primary PDP context. As discussed herein a PDP Context comprises a record of parameters, including information for establishing an end-to-end connection, such as PDP Type, PDP address type, QoS profile request (e.g., QoS parameters requested by user), QoS profile negotiated (e.g., QoS parameters negotiated by network), Authentication type (e.g., PAP or CHAP), and DNS type (e.g., Dynamic DNS or Static DNS).

More specifically, with regard to the + CGCONTRDP command, the execution command returns the relevant information <bearer_id>, <apn>, <local_addr and subnet_mask>, <gw_addr>, <DNS_prim_addr>, <DNS_sec_addr>, <P-CSCF_prim_addr>, <P-CSCF_sec_addr>,<IM_CN+Signalling_Flag>, <LIPA_indication>, <IPv4_MTU> and <WLAN _Offload> for an active non secondary PDP context with the context identifier <cid>.

The above fields may describe, for example, a bearer identification associated with the Primary PDP context, an access point name associated with the Primary PDP context, a local address and subnet mask associated with the Primary PDP context, a gateway address associated with the Primary PDP Context, primary or secondary domain name system (DNS) Server address associated with the primary context, primary or secondary proxy-call session control function (P-CSCF) Server address associated with the Primary PDP context, an IP Multimedia Core Network (IM_CN) flag associated with the Primary PDP context identifying the PDN connection as a multimedia PDN Connection, a local IP access (LIPA) indicator associated with the Primary PDP context, an IP maximum transmission unit (MTU) defining a maximum packet size for the primary PDP Context, or data indicating whether the PDN connection associated with a Primary PDP context can be offloaded from the cellular network to the non-cellular network.

If the MT indicates more than two IP addresses of P-CSCF servers or more than two IP addresses of DNS servers, multiple lines of information per <cid> will be returned.

If the MT has dual stack capabilities, at least one pair of lines with information is returned per <cid>. First one line with the IPv4 parameters followed by one line with the IPv6 parameters. If this MT with dual stack capabilities indicates more than two IP addresses of P-CSCF servers or more than two IP addresses of DNS servers, multiple of such pairs of lines are returned.

NOTE: If the MT doesn't have all the IP addresses to be included in a line, e.g. in case the UE received four IP addresses of DNS servers and two IP addresses of P-CSCF servers, the parameter value representing an IP address that cannot be populated is set to an empty string or an absent string.

If the parameter <cid> is omitted, the relevant information for all active non secondary PDP contexts is returned.

The test command returns a list of <cid>s associated with active non secondary contexts.

<FIG> illustrates a command/response table <NUM> for the secondary PDP context read dynamic parameters (+CGSCONTRDP) command. In this embodiment, the +CGSCONTRDP command can be used to query WLAN offload characteristics of an active PDN connection associated with any active secondary PDP context.

More specifically, with regard to the + CGSCONTRDP command, the execution command returns <p_cid>, <bearer_id>, <IM_CN_Signalling_Flag> and <WLAN _Offload> for an active secondary PDP context with the context identifier <cid>.

If the parameter <cid> is omitted, the <cid>, <p_cid>, <bearer_id>, <IM_CN_Signalling_Flag> and <WLAN_Offload> are returned for all active secondary PDP contexts.

In EPS, the Traffic Flow parameters are returned.

NOTE: Parameters for UE initiated and network initiated PDP contexts are returned.

The test command returns a list of <cid>s associated with active secondary PDP contexts.

Thus, in the embodiments discussed above, pre-existing AT Commands +CGEREP, +CGCONTRDP and +CGSCONTRDP are extended to provide WLAN offloading indications on a per PDN connection basis to a TE. Furthermore, the WLAN_Offload setting could be considered as being specific for each individual PDN connection. Adding WLAN_Offload setting as a new parameter allows having this setting apply to offloading of every single PDN connection. Furthermore this parameter allows to determine WLAN offload characteristics to specific Radio Access Technologies (RATs) such as UTRAN or EUTRAN.

<FIG> illustrates a command/response table <NUM> for providing WLAN offload assistance information in accordance with some embodiments. The table <NUM> illustrates a WLAN Offload Assistance Data (+CWLANOLAD) AT command; set command enables or disables the sending of the following unsolicited result code from MT to TE whenever the WLAN offload assistance data changes at the MT. +CWLANOLADI: [,<threshRSCPLow>,<threshRSCPHigh>[,<thres hEcnoLow>,<threshEcnoHigh> [,<threshRSRPLow>,<threshRSR PHigh> [,<threshRSRQLow>,<threshRSRQHigh> [, <threshChUti lLow>,<threshChUtilHigh>[,<threshBackhRateDLLow>,<thre shBackhRateDLHigh>[,<threshBackhRateULLow>,<threshBack hRateULHigh>[,<threshBeaconRSSILow>,<threshBeaconRSSIH igh>[,<opi>[,<tSteering>[,<WLANIdentifierListLength>[, <ssid_1>,<bssid_1>,<hessid_1>][,. ][,<ssid_m>,<bssid_m> ,<hessid_m>]]]]]]]]]]]].

If a setting is not supported by the MT, ERROR or +CME ERROR: is returned.

Read command returns the current status of result code and the WLAN offload assistance data currently available at the MT.

Test command returns the values supported by MT as compound values.

<FIG> illustrates a command/response table <NUM> for providing WLAN Offload Cell Measurement information in accordance with some embodiments. The table <NUM> illustrates a WLAN Offload Cell Measurement (+CWLANOLCM) AT command; set command enables or disables the sending of the following unsolicited result code from MT to TE whenever the cell measurement parameters meet the criteria for WLAN offloading based on configured thresholds. +CWLANOLCMI: <rscp>,<ecno>,<rsrp>,<rsrq>.

Read command returns the current status of result code presentation and the measurements from the current primary serving cell at the MT.

<FIG> illustrates a block diagram of a UE <NUM> and an eNodeB <NUM>, in accordance with some embodiments. It should be noted that, in some embodiments, the eNodeB <NUM> can be a stationary (non-mobile) device. The UE <NUM> can include physical layer circuitry (PHY) <NUM> for transmitting and receiving signals to and from the eNodeB <NUM>, other eNodeBs, other UEs, or other devices using one or more antennas <NUM>, while the eNodeB <NUM> can include physical layer circuitry (PHY) <NUM> for transmitting and receiving signals to and from the UE <NUM>, other eNodeBs, other UEs, or other devices using one or more antennas <NUM>. The UE <NUM> can also include medium access control layer (MAC) circuitry <NUM> for controlling access to the wireless medium, while the eNodeB <NUM> can also include MAC circuitry <NUM> for controlling access to the wireless medium. The UE <NUM> can also include processing circuitry <NUM> and memory <NUM> arranged to perform the operations described herein, and the eNodeB <NUM> can also include processing circuitry <NUM> and memory <NUM> arranged to perform the operations described herein.

The antennas <NUM>, <NUM> can comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas, or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple-output (MIMO) embodiments, the antennas <NUM>, <NUM> can be effectively separated to benefit from spatial diversity and the different channel characteristics that can result.

Although the UE <NUM> and eNodeB <NUM> are each illustrated as having several separate functional elements, one or more of the functional elements can be combined and can be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements can comprise one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radiofrequency integrated circuits (RFICs), and combinations of various hardware and circuitry for performing at least the functions described herein. In some embodiments, the functional elements can refer to one or more processes operating on one or more processing elements.

Embodiments can be implemented in one or a combination of hardware, firmware, and software. Embodiments can also be implemented as instructions stored on a computer-readable storage device, which can be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device can include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device can include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and other storage devices and media. Some embodiments can include one or more processors and can be configured with instructions stored on a computer-readable storage device.

In accordance with embodiments, the UE <NUM> can operate in accordance with a D2D communication mode. The UE <NUM> can include processing circuitry <NUM> configured to determine a synchronization reference time based on reception of one or more signals from the eNodeB <NUM>. The hardware processing circuitry <NUM> can be further configured to, during a D2D communication session, transmit multi-time transmission interval bundle groups (MTBGs) of data symbols during a first group of data transmission intervals (DTIs) and refrain from transmission of data symbols during a second group of DTIs that is exclusive of the first group of DTIs. Starting times of the DTIs can be based, at least partly, on the synchronization reference time. The hardware processing circuitry <NUM> can be further configured to transmit, during an in-network communication session exclusive of the D2D communication session, data symbols according to a time transmission interval (TTI) reference time that is synchronized to the synchronization reference time.

In some scenarios, the UE <NUM>, operating in a cellular communication network, can begin to experience performance degradation for various reasons. As an example, user loading or throughput demands of the network <NUM> can become high. As another example, the UE <NUM> can move toward or beyond the edges of coverage cells. While operating in the network <NUM>, the UE <NUM> can actually be in communication with other UEs that are physically located in close proximity to the UE <NUM>, although the communication can take place through the network <NUM>.

<FIG> illustrates a block diagram illustrating components of a machine, according to some example embodiments, able to read instructions from a machine-readable medium and perform any one or more of the methodologies discussed herein, according to aspects of the disclosure. In particular, <FIG> illustrates an exemplary computer system <NUM> (which can comprise any of the network elements discussed above) within which software <NUM> for causing the machine to perform any one or more of the methodologies discussed herein can be executed. In alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The computer system <NUM> can function as any of the above described UEs or eNodeBs, and can be a personal computer (PC), a wearable mobile computing device, a tablet PC, a set-top box (STB), a PDA, a cellular telephone, a web appliance, a network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" can also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system <NUM> includes a processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory <NUM>, and a static memory <NUM>, which communicate with each other via a bus <NUM>. The computer system <NUM> can further include a video display unit <NUM> (e.g., an LCD or a cathode ray tube (CRT)). The computer system <NUM> also includes an alphanumeric input device <NUM> (e.g., a keyboard), a user interface navigation (or cursor control) device <NUM> (e.g., a mouse), a storage device <NUM>, a signal generation device <NUM> (e.g., a speaker), and a network interface device <NUM>.

The storage device <NUM> includes a non-transitory machine-readable medium <NUM> on which is stored one or more sets of data structures and software <NUM> embodying or utilized by any one or more of the methodologies or functions described herein. The software <NUM> can also reside, completely or at least partially, within the main memory <NUM> and/or within the processor <NUM> during execution thereof by the computer system <NUM>, with the main memory <NUM> and the processor <NUM> also constituting non-transitory machine-readable media <NUM>. The software <NUM> can also reside, completely or at least partially, within the static memory <NUM>.

While the non-transitory machine-readable medium <NUM> is shown, in an example embodiment, to be a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more data structures and software <NUM>. The term "machine-readable medium" can also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present embodiments, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions. The term "machine-readable medium" can accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media <NUM> include non-volatile memory, including by way of example semiconductor memory devices (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices); magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and compact disc read-only memory (CD-ROM) and digital versatile disc (or digital video disc) read-only memory (DVD-ROM) disks.

The software <NUM> can further be transmitted or received over a communications network <NUM> using a transmission medium. The software <NUM> can be transmitted using the network interface device <NUM> and any one of a number of well-known transfer protocols (e.g., HyperText Transfer Protocol (HTTP)). Examples of communication networks <NUM> include a local area network (LAN), a wide area network (WAN), the Internet <NUM>, mobile telephone networks, plain old telephone service (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term "transmission medium" can be taken to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software <NUM>.

Claim 1:
A user equipment, UE (<NUM>, <NUM>, <NUM>), comprising:
a mobile termination, MT (<NUM>), configured to transmit and receive messages from a cellular network; and
a terminal equipment, TE (<NUM>), configured to execute one or more applications to utilize one or more packet data network, PDN, connections of the cellular network or a wireless local area network, WLAN; and
characterized in that
the UE is configured to:
cause a terminal adaptor, TA (<NUM>), of the UE (<NUM>, <NUM>, <NUM>) to:
forward an attention, AT, command received from the TE (<NUM>) as an MT control command to the MT (<NUM>);
forward an MT (<NUM>) status message generated by the MT (<NUM>) as an AT command response to the TE (<NUM>); and
forward an unsolicited result code +CGEV generated by the MT (<NUM>) to the TE (<NUM>), indicating whether a specific PDN connection can be offloaded from the cellular network to the WLAN, when acceptability of offloading the specific PDN connection changes.