Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
RAN-BASED PAGING OPTIMIZATIONS
Document Type and Number:
WIPO Patent Application WO/2018/031802
Kind Code:
A1
Abstract:
Disclosed are a RAN-based paging mechanism and optimizations of how UE context information is to be retrieved from an anchor (i.e., old eNB) to support the RAN-based paging mechanism. An X2AP-based, RAN-originated paging mechanism for paging eNBs and cells within a given area is described. DRX enhancements and resolution of mismatching states are also described.

Inventors:
BANGOLAE SANGEETHA (US)
MARTINEZ TARRADELL MARTA (US)
PALAT SUDEEP (GB)
SIROTKIN ALEXANDER (IL)
Application Number:
PCT/US2017/046340
Publication Date:
February 15, 2018
Filing Date:
August 10, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INTEL IP CORP (US)
International Classes:
H04W68/08; H04W68/04; H04W92/20
Foreign References:
US20140302880A12014-10-09
US20140155109A12014-06-05
Other References:
NOKIA ET AL: "Paging for light connection", vol. RAN WG3, no. Nanjing, China; 20160523 - 20160527, 22 May 2016 (2016-05-22), XP051106150, Retrieved from the Internet [retrieved on 20160522]
INTEL CORPORATION: "RAN based paging mechanism", vol. RAN WG3, no. Bangalore, India; 20160411 - 20160415, 2 April 2016 (2016-04-02), XP051083110, Retrieved from the Internet [retrieved on 20160402]
INTEL CORPORATION: "Standalone NR: Discussion on mobility framework", vol. RAN WG2, no. Nanjing, China; 20160523 - 20160527, 22 May 2016 (2016-05-22), XP051105032, Retrieved from the Internet [retrieved on 20160522]
INTEL CORPORATION: "Benefits of RAN based paging", vol. RAN WG3, no. Nanjing, China; 20160523 - 20160527, 22 May 2016 (2016-05-22), XP051105890, Retrieved from the Internet [retrieved on 20160522]
KYOCERA: "Details of paging enhancements and Light Connection", vol. RAN WG2, no. Nanjing, China; 20160523 - 20160527, 22 May 2016 (2016-05-22), XP051105374, Retrieved from the Internet [retrieved on 20160522]
INTEL: "Support of Light Connection", vol. RAN WG3, no. Sophia Antipolis, France; 20161010 - 20161014, 1 October 2016 (2016-10-01), XP051163091, Retrieved from the Internet [retrieved on 20161001]
HUAWEI: "RAN initiated paging", vol. RAN WG3, no. Gothenburg, Sweden; 20160822 - 20160826, 21 August 2016 (2016-08-21), XP051127555, Retrieved from the Internet [retrieved on 20160821]
Attorney, Agent or Firm:
TEEL, Robert R. (US)
Download PDF:
Claims:
CLAIMS

1 . An apparatus for an evolved Node B (eNB), comprising:

a memory interface configured to receive information representing a list of radio access network (RAN) nodes to page during RAN-based paging of a lightly connected user equipment (UE); and

one or more processors configured to:

process data arriving for the lightly connected UE; and

generate, in response to the data arriving and based on the list of RAN nodes, an X2 application protocol (X2AP) message for the RAN-based paging of the lightly connected UE.

2. The apparatus of claim 1 , in which the one or more processors are further configured to process UE mobility history information so as to generate the list of RAN nodes to page during the RAN-based paging of the lightly connected UE.

3. The apparatus of claim 1 , in which the one or more processors are further configured to process a tracking area identity (TAI) list to generate the list of RAN nodes to page during the RAN-based paging of the lightly connected UE.

4. The apparatus of any preceding claim, in which the list is a first list for an initial paging attempt, and the one or more processors are configured to generate a second list, different from the first list, for a subsequent paging attempt.

5. The apparatus of claim 1 or 3, in which the one or more processors are further configured to generate the list by selecting a subset of a tracking area.

6. The apparatus of any of claims 1-3, in which the X2AP message includes a UE identity index.

7. The apparatus of any of claims 1-3, in which the X2AP message includes RAN paging discontinuous reception (DRX) information.

8. The apparatus of any of claims 1-3, in which the X2AP message includes a paging priority information element defining a priority for a flow of the UE.

9. The apparatus of any of claims 1-3, in which the one or more processors are further configured to initiate a timer to control timing of paging messages.

10. The apparatus of any of claims 1-3, in which the one or more processors count a number of paging attempts.

1 1 . An apparatus for an evolved Node B (eNB) configured to act as an anchor eNB for radio access network (RAN)-based paging of a user equipment (UE) served by a serving eNB that is different from the anchor eNB, comprising: a memory interface configured to receive information representing a UE context of the UE; and

one or more processors configured to:

process a first message from the serving eNB, the first message requesting the UE context; and

in response to the first message, generate a second message for the serving eNB, the second message including the information representing the UE context.

12. The apparatus of claim 1 1 , in which the first message includes downlink (DL) data forwarding information.

13. The apparatus of claim 1 1 or 12, in which the second message includes an indication of downlink data available for forwarding.

14. The apparatus of claim 1 1 or 12, in which the one or more processors are further configured to process a third message from the serving eNB, the third message providing downlink (DL) data forwarding information.

15. The apparatus of claim 1 1 or 12, in which at least one of the first and second messages includes E-UTRAN Radio Access Bearers (E-RABs) information.

16. An apparatus for a user equipment (UE), comprising:

a memory interface configured to receive information representing an indication to enter a lightly connected state; and

one or more processors configured to process the indication and thereby enter lightly connected state for awaiting a radio access network (RAN)-initiated paging message.

17. The apparatus of claim 16, in which the indication is an explicit indication carried in a message from an evolved Node B (eNB).

18. The apparatus of claim 16 or 17, in which the indication is provided in a radio resource control (RRC) message.

19. The apparatus of claim 16, in which the indication is an indirect indication implied by a radio access network (RAN)-based paging discontinuous reception (DRX) cycle configuration.

20. The apparatus of claim 16, in which the indication is provided by a suspend indication.

21 . A machine readable medium for an evolved Node B (eNB), the machine readable medium having stored thereon instructions and information representing a light connection state of a user equipment (UE), the instructions, when executed, cause one or more processor to:

process an S1 application protocol (S1AP) release request message indicating a mobility management entity (MME) is transitioning the UE from a connected state to an idle state; and

generate an update to the light connection state and a corresponding S1AP release response for the MME.

22. The machine readable medium of claim 21 , in which the one or more processors are further configured to generate a core network (CN)-initiated paging message for the UE in response to the light connection state stored by the eNB being different from an actual connection state of the UE.

23. The machine readable medium of claim 21 or 22, in which the one or more processors are further configured to generate a radio resource control (RRC) paging message to the UE so as to release its light connection.

Description:
RAN-BASED PAGING OPTIMIZATIONS

RELATED APPLICATION

[0001] This application claims the benefit of United States Provisional Patent Application No. 62/373,744, filed August 1 1 , 2016, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0002] The present disclosure relates to radio access network (RAN)-based paging in 3rd Generation Partnership Project (3GPP) long term evolution (LTE) systems. In particular, the present disclosure relates to RAN-based paging lists; once a new Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) is identified through paging, retrieval of the UE context and downlink (DL) data forwarding information; X2 application protocol (X2AP) signaling between a previous (anchor) eNB and a current serving eNB; RAN-based paging discontinuous reception (DRX) techniques; and handling mismatches between an actual

connection state of a UE and the connection state as known to the core network.

BACKGROUND INFORMATION

[0003] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless mobile device.

Wireless communication system standards and protocols can include the 3GPP LTE; the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access (WiMAX); and the IEEE 802.1 1 standard for wireless local area networks (WLAN), which is commonly known to industry groups as Wi-Fi. In 3GPP RANs of LTE systems, the base station can include a RAN Node such as an eNB and/or Radio Network Controller (RNC) in an E-UTRAN, which communicate with a wireless communication device, known as UE. In fifth generation (5G) or new radio (NR) wireless RANs, RAN Nodes can include a 5G Node.

[0004] RANs use a radio access technology (RAT) to communicate between the RAN Node and UE. RANs can include global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and/or E-UTRAN, which provide access to communication services through a core network. Each of the RANs operates according to a specific 3GPP RAT. For example, the GERAN implements GSM and/or EDGE RAT, the UTRAN implements universal mobile telecommunication system (UMTS) RAT or other 3GPP RAT, and the E-UTRAN implements LTE RAT.

[0005] A core network can be connected to the UE through the RAN Node. The core network can include a serving gateway (SGW), a packet data network (PDN) gateway (PGW), an access network detection and selection function (ANDSF) server, an enhanced packet data gateway (ePDG) and/or a mobility management entity (MME).

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is an annotated block diagram of RAN-based paging.

[0007] FIG. 2 is a sequence diagram showing messages exchanged between new and old eNBs.

[0008] FIG. 3 is a table showing content of a RETRIEVE UE CONTEXT

REQUEST message.

[0009] FIG. 4 is a table showing content of a RETRIEVE UE CONTEXT

RESPONSE message.

[0010] FIGS. 5 and 6 are tables showing in greater detail information elements (lEs) of FIG. 3 used for DL packet forwarding.

[0011] FIG. 7 is a sequence diagram showing the X2AP PAGING provided from one eNB to another.

[0012] FIG. 8 is a table showing content of an X2AP PAGING message.

[0013] FIG. 9 is a table showing an IE related to a paging count over X2.

[0014] FIGS. 10 and 1 1 are tables showing UE history information lEs.

[0015] FIGS. 12 and 13 are tables showing last visited cell information.

[0016] FIG. 14 is a table showing an IE including paging specific UE radio capability information.

[0017] FIG. 15 is a table showing assistance data for coverage enhancement (CE) capable UEs.

[0018] FIG. 16 is a table showing enhanced DRX (eDRX) information.

[0019] FIG. 17 is a table showing an extended UE identity index value IE.

[0020] FIG. 18 is a sequence diagram showing a light connection indication from an eNB to a UE. [0021] FIGS. 19 and 20 are first and second sequence diagrams showing, respectively, first and second options for addressing mismatches between an actual connection state of a UE and the connection state as known to the core network.

[0022] FIG. 21 illustrates an architecture of a system of a network in accordance with some embodiments.

[0023] FIG. 22 illustrates example components of a device in accordance with some embodiments.

[0024] FIG. 23 illustrates example interfaces of baseband circuitry in accordance with some embodiments.

[0025] FIG. 24 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION OF EMBODIMENTS

[0026] Aspects and advantages of the disclosed techniques will be apparent from the following detailed description of embodiments, which proceeds with reference to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail.

Overview

[0027] LTE defines two radio resource control (RRC) operating states for a UE: RRC connected (i.e., RRC_Connected), for when there is data to exchange between the UE and the E-UTRAN; and RRC idle (i.e., RRCJdle), for when there is no data to exchange between the UE and the E-UTRAN.

[0028] In the RRC connected state, the UE and eNB maintain a UE context that specifies for the UE a current RAN configuration used for communication between the UE and the network. Thus, the UE context information maintains the E-UTRAN services for an active UE. In other words, a UE context is information an eNB associates to one active UE.

[0029] A UE context is established when the transition to active state for a UE is completed or in target eNB after completion of handover resource allocation during handover preparation. There is no particular IE specifying the content of a UE context, but there are references in 3GPP Technical Specification (TS) 36.413 (section 9.1.4.1 ) and TS 36.331 (multiple sections) about the UE context including the following information for a UE: identifier (ID), security capabilities, radio bearers, radio resource management (RRM) configuration, packet data convergence protocol (PDCP) configuration, and connection related configuration information. In some embodiments, the UE context includes state information, security information, UE capability information, and the identities of the UE-associated logical S1 -connection.

[0030] After the UE has no data to send, it is moved to the RRC idle state and the UE context in the RAN node is released. In the RRC idle state, the RAN node (i.e., eNB) does not have the UE's context, in which case the UE is paged through the MME using an S1AP paging message. Also, the UE cannot communicate with the network. But when the UE is in RRC idle and there is data to be exchanged between the UE and the network, the UE has to go into the RRC connected state. To go into the RRC connected state, a UE RAN context is established in the UE and in the eNB. This normally involves much signaling both in terms of number of messages and number of bytes exchanged.

[0031] The 3GPP standardization effort seeks to reduce signaling load during idle-to-active transitions. One approach entails storing the last-used UE (RAN) context in the eNB and UE, even when the UE is RRC idle. Then, when the UE goes into RRC connected, it could simply revive the stored context in the eNB and UE. This process is called "resume" in current LTE specifications. This resumption of the stored context involves fewer signaling messages and thereby reduces signaling overhead.

[0032] Moreover, because the UE is considered "suspended" when the UE is RRC idle but still has stored context available to the RAN node (eNB), the UE can be paged by a RAN node itself instead of the MME. This is called RAN-based paging, as shown by an LTE system 100 of FIG. 1 . [0033] In response to data 102 arriving for a UE 104 in a lightly connected mode, a serving (or so-called anchor) RAN node (i.e., eNB) 106 pages other RAN nodes 108 to determine where the UE 104 has moved. The RAN-based (or RAN-initiated) paging mechanism is controlled/triggered by the RAN node 106 that maintains a UE context for the UE 104 that is lightly connected and thereby still reachable for mobile terminated (MT) services via the RAN-initiated paging mechanism. Paging

messages 1 10 from the RAN node 106 are carried over an interface 1 12, which is called X2 in the LTE system 100 (but it could be another interface in 5G/NR systems), between RAN nodes 106 and 108. Accordingly, a resulting RRC paging message 1 14 provided to the UE 104 is facilitated by the X2AP paging 1 10 over the X2 interfaces 1 12 between eNBs 106 and 108, but could also be enabled via other routes, such as via S1 (not shown). When eNB1 sends paging messages over the Uu radio interface as well as over the X2 interface to other eNB(s), those other eNB(s) will also page this UE over their corresponding Uu radio interface.

[0034] A related issue for consideration in connection with RAN-based paging is how a UE can be reached in response to it moving away from its serving cell. When a lightly connected UE moves away from its serving cell, a RAN Paging Area (RPA) that provides for incurring minimal Uu interface signaling comprises a single cell or a group of cells potentially in different eNBs. Thus, the UE, while configured for a light connection, may move within the RPA without incurring any signaling. And an agreed UE ID is valid, unique, and recognized at least within this area. Whenever there is downlink data for the UE, it arrives at the last serving eNB of the UE for which an S1 interface is maintained. This would trigger an X2 message to carry paging to other eNBs within the RPA. Accordingly, whenever the UE moves to a new eNB (i.e., serving eNB 120, FIG. 1 ), the new eNB requests from the old eNB (i.e., eNB 106, FIG. 1 ) the context of the UE 104.

[0035] Example embodiments provide optimizations towards supporting the RAN- based paging mechanism and specific details of the mechanism itself. The following concepts of the example embodiments are more fully described below: specification of a RAN-based paging mechanism; optimizations of how UE context information is to be retrieved from an anchor (i.e., old eNB) to support the aforementioned RAN- based paging mechanism; description of an X2AP-based, RAN-originated paging mechanism for paging eNBs and cells within a given area; DRX enhancements; and resolution of mismatching states. More generally, the aspects discussed herein relate to building RAN-based paging solutions in connection with light connection techniques so as to reduce signaling overhead for LTE and future systems such as, for example, New Radio (NR) access technologies, 5G systems, and the like.

1 . Determining RAN Nodes to Page

[0036] As of 3GPP release (Rel.) 12, the technique in which the MME sends S1AP paging messages to the eNBs was such that the MME would page all the cells within a large tracking area for which the UE was registered. If the network

implemented any optimization on that technique, however, it was outside the scope of the 3GPP specification.

[0037] In Rel. 13, "assistance" data for paging was introduced such that the UE gathers its visited cell information (in both connected and idle mode) and forwards it to the eNB, and the eNB then sends the recommended cells and eNBs information (as part of UE CONTEXT RELEASE COMPLETE) to the MME. This information was intended to be used later for CN-based (i.e., MME) paging.

[0038] Instead of MME-based paging, the present disclosure describes RAN- based (i.e., RAN-initiated) paging in which eNBs carry out paging tasks so as to reduce signaling from an MME in a CN. An issue for RAN-based paging, however, is determining which cells or eNBs to contact in connection with paging for a lightly connected UE. Accordingly, the present disclosure describes the following

techniques, which may be specified as part of an X2AP paging mechanism

definition.

[0039] With reference to FIG. 1 , for an initial set of RAN-based paging attempts to locate the lightly connected UE 104, the eNB 106 may page cells or eNBs 108 included in a list 1 16 of recommended cells or eNBs. The list 1 16 is received by the eNB 106 in response to the UE 104 providing it as part of UE mobility history information specified in, for example, a UE IE (see e.g., FIG. 10 in which a UE sends the mobility history to the eNB based on 3GPP TS 36.331 section 5.6.1 1 ).

[0040] For a subsequent set of RAN-based paging attempts, the eNB 106 may repeat the initial set of attempts (e.g., using the list 1 16) or it may expand the number of cells or eNBs 108. For example, an expanded set of candidates are developed based on a tracking area identity (TAI) list that the UE 104 is configured with. In some embodiments, an MME provides the TAI list of the UE 104 to the eNB 106.

[0041] An issue with a tracking area (TA) is that it includes a relatively large number of candidates to page. To reduce that large number, the eNB 106 determines a subset of the tracking area called a RAN tracking area. The RAN tracking area is then used to form a RAN-based paging list. For example, the eNB 106 uses the tracking area code available within the UE mobility history IE, compares it to the TAI list from the MME, and prepares an optimized RAN-based paging list of tracking area codes for the subsequent set of RAN-based paging attempts.

[0042] In yet a further set of RAN-based paging attempts, the eNB may repeat the previous set of RAN-based paging attempts or it may page all of the TAs listed as part of the UE's registration.

2. Retrieval of UE Context and DL Data Forwarding Information

[0043] In general, messages for context retrieval are defined as part of the baseline specification on X2AP. More specifically, FIG. 2 shows a diagram 200 of a sequence of messages exchanged between the new eNB 120 and the old eNB 106. Initially, a RETRIEVE UE CONTEXT REQUEST message 210 is provided from the new eNB 120 to the old eNB 106 to request that the old eNB 106 transfer a UE context to the new eNB 120. Accordingly, the old eNB 106 responds with a

RETRIEVE UE CONTEXT RESPONSE message 220. Finally, the new eNB 120 responds with a DATA FORWARDING TUNNEL SETUP INFORMATION message 230 (or the like) to establish a DL data forwarding tunnel from the old eNB 106.

[0044] FIG. 3 shows the content of the RETRIEVE UE CONTEXT REQUEST message 210 in which a DL forwarding address is included in the message 210, according to one embodiment. For example, the message 210 includes DL Transport Layer Address information 310 and DL General Packet Radio Service (GPRS) Tunneling Protocol (GTP)-Tunnel End Identity (TEID) information 320. Thus if there is any downlink data with the old eNB 106, then it can be forwarded, based on information 310 and 320, to the new eNB 120 upon context exchange.

[0045] In another embodiment, DL data forwarding information could also be decided by the old eNB 106, e.g., when overriding the information shared by the new eNB 120 (i.e., understood as a negotiation) or for the case when the new eNB 120 does not provide this information. Thus, if the old eNB 106 has decided on these values, they would be indicated to the new eNB via the RETRIEVE UE CONTEXT RESPONSE message 220 (FIG. 4) or the like.

[0046] In some embodiments, an indication for DL data forwarding is added to the RETRIEVE UE CONTEXT RESPONSE message 220. Specifically, a new IE bit 410 suggesting that downlink data is available at the old eNB 106 helps the new eNB 120 to be prepared to receive the data for the UE. Note that if the new eNB 120 were to receive new data before the old eNB 106 forwarded the old data, it might decide to buffer it or send it immediately. Also, the UE mobility history information IE 420 (derived from the UE's visited cell list), which is part of the S1 AP paging, can also be added as part of the RETRIEVE UE CONTEXT RESPONSE message 220. The old eNB 106 thus shares the UE mobility history information with the new eNB 120 so that the UE need not send the information over the air again. It also helps the new eNB 120 set any configuration parameters accordingly.

[0047] Furthermore, information similar to that of the HANDOVER COMMAND message may be added to the DL GTP-TEID IE 320 (FIG. 3) and the DL Transport Layer Address IE 310 (FIG. 3) so that the old eNB 106 performs the forwarding of downlink data using this information. If such TEID information is needed on a per- bearer basis, then there is another message exchange (e.g., message 230, FIG. 2) once the old eNB 106 has provided the response 220 including E-UTRAN Radio Access Bearers (E-RABs) information, e.g., the number of E-RABs that have data in them. At that point, the new eNB 120 may provide in the message 230 its TEID (or transport layer address) that the old eNB 106 can use for forwarding. If there was only one E-RAB, however, this further exchange of message 230 may be avoided entirely in some embodiments.

[0048] E-RABs information list 430 refers to the presence of a list of E-RABs 440 having E-RAB IDs 450 that had been configured for the UE at the previous cell. Each E-RAB ID is associated with an enumerated bit DL forwarding 460 to indicate whether the E-RAB ID is set up for DL forwarding or not.

[0049] The downlink data availability IE 410 is an alternative to this solution in which case there is simply a bit indication and no differentiation into E-RAB list. In other words, that the bit can be specific for each radio bearer or it may generically indicate whether at least some DL data is available.

[0050] FIGS. 5 and 6 show the enumerated bit DL forwarding 460 in expanded form. This IE indicates that a particular E-RAB is proposed for forwarding of downlink packets.

3. X2AP Paging Messages

[0051] As shown in FIG. 7, at the reception of the PAGING message 710, the eNB 120 performs paging, first in cells which belong to the recommended cells/eNBs list, and second in those cells which belong to tracking areas as indicated in the list of TAIs IE in a S1AP message from MME. The eNB 120 takes the closed subscriber group (CSG) ID list into consideration in designing the list of cells to page.

[0052] An X2AP paging message 710 is defined as shown in FIG. 7. The purpose of the paging procedure is to support RAN-initiated paging by enabling the last serving (anchor) to page other recommended cells/eNBs and later in the optimized TAI list while the UE is in lightly connected mode.

[0053] The UE identity index 810 is generally used by the MME as part of the S1AP paging message. The paging frame (PF) calculation is performed using this index. When the system frame number (SFN) in LTE wraps around every 10.24 seconds or 1024 subframes and distributes the paging messages, this calculation is utilized. For the X2AP paging message, this is provided as an example. However, the UE ID 810 may be any other network-assigned ID other than International Mobile Subscriber Identity (IMSI) as IMSI may not be available at the eNB readily, unless it is provided by the MME over S1 along with a System Architecture Evolution (S)- Temporary Mobile Subscriber Identity (TMSI) for paging UE ID.

[0054] The CN Domain IE 820 is transferred transparently to the UE.

[0055] The Paging DRX IE 830 may be included in the PAGING message 710, and the eNB shall use it according to 3GPP specifications.

[0056] The Paging Priority IE 840 may be included in the PAGING message, and if present the eNB may use it according to 3GPP specifications. The priority corresponds to the priority configured for the UE's flows.

[0057] For timers, the initiating eNB starts a timer (UE-specific) which is based on the network operator (also depending on configured number of paging attempts). The timer is canceled/stopped when the eNB receives the UE context retrieval request message on behalf of the UE. However, once the timer expires, the eNB originates another page.

[0058] A RAN-based paging reason 850 is also included. If the paging is meant for a massive Machine Type Communications (mMTC) type of application, which only uploads data to the network periodically by itself or upon receiving a page, an indicator can be sent for such UEs. As it is a generic request data, there could be no security issue associated with it as the UE would later be authenticated when it resumes. This is an advantage of the RAN-based paging mechanism in supporting the Internet of Things. [0059] It is to be noted that the paging message for the cells could be broadcast depending on how the interface is configured by the network.

[0060] FIG. 9 shows paging attempt information 900. The information is related to the paging count over X2 and can be defined similar to what has been defined over the S1 AP paging message. Additional X2AP messaging information is set forth in annotations of FIGS. 10-17. The information shown in these figures are part of an X2AP message (i.e., the various lEs), according to some embodiments.

4. Light Connection Indication to Support RAN-Based Paging Mechanism

[0061] As shown in a signaling diagram 1800 of FIG. 18, in order for an eNB 1810 to let a UE 1820 know that the UE 1820 is now in light connection, an explicit or implicit form of indication 1830 is shared over the air with the UE 1820. Thus, the indication enables the UE 1820 to enter a light connection 1840 while being prepared to respond to corresponding RAN-initiated paging. For example, if the UE 1820 was released without the indication 1830, it would enter idle mode and legacy or CN-initiated paging , i.e., perform paging occasion (PO)/paging frame (PF) calculations according to 3GPP idle mode procedures and wake up for paging messages triggered by an MME 1850 (e.g., on a DRX cycle of 320, 640, 1280, or 2560 ms). However, when the UE 1820 is configured through the indication 1830, it may prepare the PO/PF according to dedicated signaling-based RAN-initiated paging and potentially the RAN-based DRX cycle to support the RAN-based paging mechanism.

[0062] For simplicity, the signaling diagram 1800 uses the reference "Light-Conn- Indication" to indicate the signaling mechanism 1830 that indicates the UE 1820 should enter into the light connection 1840. However, additional details for this kind of indication could be defined in very diverse manners. Three example options on how to indicate the UE 1820 to enter into light connection (i.e., "Light-Conn- Indication") are as follows. First, a direct explicit indication, e.g., via new flag or information elements defined within existing messages, or via a new message all by itself is provided. Second, an indirect explicit indication, e.g., specific information, might be used to trigger the entrance into light connection. An alternative is to use the indication of a new RAN-based paging DRX cycle that is configured per UE via dedicated RRC. Third, an implicit indication, e.g., based on UE capabilities negotiation in combination with the Rel. 13 suspend indication, is another option. 5. Mismatching States

[0063] This section describes options for handling mismatches between a UE and a network when an MME releases the UE's connection while the UE is lightly connected. In legacy LTE, such a release implies that a UE's RRC and S1

connections are released: the UE access stratum (AS) context is released by the UE, its serving eNB, and also the S1 -U. This leads to buffering DL data in an S-GW and triggering CN-initiated paging rather than RAN-initiated paging. The following example options address this situation. Note that the options assume that a lightly connected UE is reachable via some form of RRC paging message or via downlink control information (DCI). The salient points to highlight are as follows.

[0064] FIG. 19 illustrates a sequence diagram 1900 showing messages and states of an MME 1910, a serving eNB 1920, and a UE 1930. Initial states 1935 of the three nodes are all internally consistent when the UE 1930 is lightly connected. At some point, the MME 1910 provides a message 1940 to request release of the UE 1930. The eNB 1920 responds 1950 and releases 1960 the UE 1930.

Accordingly, the UE 1930 need not transition 1974 from a configuration in which it expects RAN-initiated paging to a configuration in which it operates on CN-initiated paging, but the eNB 1980 updates its state 1982 to reflect this transition out of a lightly connected state. Likewise, the MME 1910 updates its state 1990. Subsequent paging 1994 is CN-initiated.

[0065] An advantage of this option is that no RRC signaling is used. A

disadvantage, however, is that the UE 1930 is not aware when it is released from light connection. Moreover, for this option, further concerns may arise if, e.g., the eNB 1920 releases the UE AS context and its resume ID, which might then be allocated to another eNB such that when the UE 1930 tries to resume its connection, a conflict arises. Alternatively, if the eNB 1920 retains the UE AS context and resume ID even after the UE 1930 is released, e.g., marking it as invalid or released, until the UE 1930 resumes (establishes) the connection, there remains a concern as to how to handle a situation when the UE 1930 is trying to resume the connection in a different eNB. Thus, another option is that the eNB 1920 and the MME 1910 treat the UE 1930 as RRC idle with a suspend indication, as shown in states 1982 and 1990.

[0066] FIG. 20 illustrates another sequence diagram 2000 showing messages and states of an MME 2010, a serving eNB 2020, and a UE 2030. Again, initial states 2035 of the three nodes are all internally consistent when the UE 2030 is lightly connected. At some point, the MME 2010 provides a message 2040 to request release of the UE 2030. The eNB 2020 responds 2050, but in this option it provides an RRC paging message 2060 to the lightly connected UE 2030. The message 2060 is intended to resume the suspended UE 2030 so that the UE 2030 will release 2070 its context and end its light connection. The context may be optionally stored 2080 by the eNB 2020 and the MME 2010. In other words, the UE 2030 is paged to trigger the resumption of the light connection in order to do a full release (or even to suspend the connection). The advantage with this approach is that the UE 2030, eNB 2020, and MME 2010 are aligned throughout the state transition. The disadvantage is that additional signaling is used to take the UE 2030 out of its light connection so as to release it. However, this disadvantage is rare because the MME 2010 triggering the release of the UE 2030 happens infrequently in practice. In other words, there is a tradeoff with over-the-air signaling generated compared to whether a UE should be aligned with the network on its state and behavior. But since the scenario when an MME triggers the release of a UE is rare, it is preferable in some embodiments to define an RRC mechanism when the network moves the UE out of light connection (e.g., CN-initiated paging is used instead of RAN-initiated paging).

6. Systems and Components

[0067] As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

[0068] FIG. 21 illustrates an architecture of a system 2100 of a network in accordance with some embodiments. The system 2100 is shown to include a user equipment (UE) 2101 and a UE 2102. The UEs 2101 and 2102 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

[0069] In some embodiments, any of the UEs 2101 and 2102 can comprise an Internet of Things (loT) UE, which can comprise a network access layer designed for low-power loT applications utilizing short-lived UE connections. An loT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or loT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network describes interconnecting loT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

[0070] The UEs 2101 and 2102 may be configured to connect, e.g.,

communicatively couple, with a radio access network (RAN) 21 10. The RAN 21 10 may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs 2101 and 2102 utilize connections 2103 and 2104, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 2103 and 2104 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, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.

[0071] In this embodiment, the UEs 2101 and 2102 may further directly exchange communication data via a ProSe interface 2105. The ProSe interface 2105 may alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery

Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0072] The UE 2102 is shown to be configured to access an access point (AP) 2106 via connection 2107. The connection 2107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.1 1 protocol, wherein the AP 2106 would comprise a wireless fidelity (WiFi®) router. In this example, the AP 2106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).

[0073] The RAN 21 10 can include one or more access nodes that enable the connections 2103 and 2104. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNB), RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The RAN 21 10 may include one or more RAN nodes for providing macrocells, e.g., macro RAN node 21 1 1 , and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low power (LP) RAN node 21 12.

[0074] Any of the RAN nodes 21 1 1 and 21 12 can terminate the air interface protocol and can be the first point of contact for the UEs 2101 and 2102. In some embodiments, any of the RAN nodes 21 1 1 and 21 12 can fulfill various logical functions for the RAN 21 10 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.

[0075] In accordance with some embodiments, the UEs 2101 and 2102 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 21 1 1 and 21 12 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency- Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers. [0076] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 21 1 1 and 21 12 to the UEs 2101 and 2102, while uplink transmissions can utilize similar techniques. The grid can be a time- frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid

corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0077] The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs 2101 and 2102. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 2101 and 2102 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 2102 within a cell) may be performed at any of the RAN nodes 21 1 1 and 21 12 based on channel quality information fed back from any of the UEs 2101 and 2102. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 2101 and 2102.

[0078] The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1 , 2, 4, or 8).

[0079] Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

[0080] The RAN 21 10 is shown to be communicatively coupled to a core network (CN) 2120—via an S1 interface 21 13. In embodiments, the CN 2120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface 21 13 is split into two parts: the S1 -U interface 21 14, which carries traffic data between the RAN nodes 21 1 1 and 21 12 and a serving gateway (S-GW) 2122, and an S1 -mobility

management entity (MME) interface 21 15, which is a signaling interface between the RAN nodes 21 1 1 and 21 12 and MMEs 2121 .

[0081] In this embodiment, the CN 2120 comprises the MMEs 2121 , the S-GW 2122, a Packet Data Network (PDN) Gateway (P-GW) 2123, and a home subscriber server (HSS) 2124. The MMEs 2121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 2121 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 2124 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The CN 2120 may comprise one or several HSSs 2124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 2124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

[0082] The S-GW 2122 may terminate the S1 interface 21 13 towards the RAN 21 10, and routes data packets between the RAN 21 10 and the CN 2120. In addition, the S-GW 2122 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

[0083] The P-GW 2123 may terminate an SGi interface toward a PDN. The P-GW 2123 may route data packets between the CN 2120 (e.g., an EPC network) and external networks such as a network including the application server 2130

(alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 2125. Generally, an application server 2130 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW 2123 is shown to be communicatively coupled to an application server 2130 via an IP communications interface 2125. The application server 2130 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 2101 and 2102 via the CN 2120.

[0084] The P-GW 2123 may further be a node for policy enforcement and charging data collection. A Policy and Charging Enforcement Function (PCRF) 2126 is the policy and charging control element of the CN 2120. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP- CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 2126 may be communicatively coupled to the application server 2130 via the P-GW 2123. The application server 2130 may signal the PCRF 2126 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 2126 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 2130.

[0085] FIG. 22 illustrates example components of a device 2200 in accordance with some embodiments. In some embodiments, the device 2200 may include application circuitry 2202, baseband circuitry 2204, Radio Frequency (RF) circuitry 2206, front-end module (FEM) circuitry 2208, one or more antennas 2210, and power management circuitry (PMC) 2212 coupled together at least as shown. The components of the illustrated device 2200 may be included in a UE or a RAN node. In some embodiments, the device 2200 may include fewer elements (e.g., a RAN node may not utilize application circuitry 2202, and instead include a

processor/controller to process IP data received from an EPC). In some

embodiments, the device 2200 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

[0086] The application circuitry 2202 may include one or more application processors. For example, the application circuitry 2202 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 2200. In some embodiments, processors of application circuitry 2202 may process IP data packets received from an EPC.

[0087] The baseband circuitry 2204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 2204 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 2206 and to generate baseband signals for a transmit signal path of the RF circuitry 2206. Baseband processing circuity 2204 may interface with the application circuitry 2202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 2206. For example, in some embodiments, the baseband circuitry 2204 may include a third generation (3G) baseband processor 2204A, a fourth generation (4G) baseband processor 2204B, a fifth generation (5G) baseband processor 2204C, or other baseband processor(s) 2204D for other existing

generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 2204 (e.g., one or more of baseband processors 2204A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 2206. In other embodiments, some or all of the functionality of baseband processors 2204A-D may be included in modules stored in the memory 2204G and executed via a Central Processing Unit (CPU) 2204E. 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 2204 may include Fast- Fourier Transform (FFT), precoding, or constellation mapping/demapping

functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 2204 may include convolution, tail-biting convolution, turbo, Viterbi, 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.

[0088] In some embodiments, the baseband circuitry 2204 may include one or more audio digital signal processor(s) (DSP) 2204F. The audio DSP(s) 2204F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry 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 2204 and the application circuitry 2202 may be implemented together such as, for example, on a system on a chip (SOC).

[0089] In some embodiments, the baseband circuitry 2204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 2204 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), or a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 2204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0090] RF circuitry 2206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 2206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. The RF circuitry 2206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 2208 and provide baseband signals to the baseband circuitry 2204. RF circuitry 2206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 2204 and provide RF output signals to the FEM circuitry 2208 for transmission.

[0091] In some embodiments, the receive signal path of the RF circuitry 2206 may include mixer circuitry 2206A, amplifier circuitry 2206B and filter circuitry 2206C. In some embodiments, the transmit signal path of the RF circuitry 2206 may include filter circuitry 2206C and mixer circuitry 2206A. RF circuitry 2206 may also include synthesizer circuitry 2206D for synthesizing a frequency for use by the mixer circuitry 2206A of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 2206A of the receive signal path may be configured to down- convert RF signals received from the FEM circuitry 2208 based on the synthesized frequency provided by synthesizer circuitry 2206D. The amplifier circuitry 2206B may be configured to amplify the down-converted signals and the filter circuitry 2206C 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 2204 for further processing. In some embodiments, the output baseband signals may be zero- frequency baseband signals, although this is not a requirement. In some

embodiments, the mixer circuitry 2206A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0092] In some embodiments, the mixer circuitry 2206A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 2206D to generate RF output signals for the FEM circuitry 2208. The baseband signals may be provided by the baseband circuitry 2204 and may be filtered by the filter circuitry 2206C.

[0093] In some embodiments, the mixer circuitry 2206A of the receive signal path and the mixer circuitry 2206A of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 2206A of the receive signal path and the mixer circuitry 2206A 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 2206A of the receive signal path and the mixer circuitry 2206A may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 2206A of the receive signal path and the mixer circuitry 2206A of the transmit signal path may be configured for super-heterodyne operation.

[0094] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 2206 may include analog- to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 2204 may include a digital baseband interface to communicate with the RF circuitry 2206.

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

[0096] In some embodiments, the synthesizer circuitry 2206D may be a

fractional-N synthesizer or a fractional N/N+1 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 2206D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0097] The synthesizer circuitry 2206D may be configured to synthesize an output frequency for use by the mixer circuitry 2206A of the RF circuitry 2206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 2206D may be a fractional N/N+1 synthesizer.

[0098] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 2204 or the application circuitry 2202 (such as an applications processor) depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the application circuitry 2202.

[0099] Synthesizer circuitry 2206D of the RF circuitry 2206 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+1 (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.

[0100] In some embodiments, the synthesizer circuitry 2206D 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 2206 may include an IQ/polar converter.

[0101] FEM circuitry 2208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 2210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 2206 for further processing. The FEM circuitry 2208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 2206 for transmission by one or more of the one or more antennas 2210. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 2206, solely in the FEM circuitry 2208, or in both the RF circuitry 2206 and the FEM circuitry 2208.

[0102] In some embodiments, the FEM circuitry 2208 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 2208 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 2208 may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 2206). The transmit signal path of the FEM circuitry 2208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by the RF circuitry 2206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 2210).

[0103] In some embodiments, the PMC 2212 may manage power provided to the baseband circuitry 2204. In particular, the PMC 2212 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 2212 may often be included when the device 2200 is capable of being powered by a battery, for example, when the device 2200 is included in a UE. The PMC 2212 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0104] FIG. 22 shows the PMC 2212 coupled only with the baseband circuitry 2204. However, in other embodiments, the PMC 2212 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, the application circuitry 2202, the RF circuitry 2206, or the FEM circuitry 2208.

[0105] In some embodiments, the PMC 2212 may control, or otherwise be part of, various power saving mechanisms of the device 2200. For example, if the device 2200 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 2200 may power down for brief intervals of time and thus save power.

[0106] If there is no data traffic activity for an extended period of time, then the device 2200 may transition off to an RRCJdle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 2200 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 2200 may not receive data in this state, and in order to receive data, it transitions back to an RRC_Connected state.

[0107] An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[0108] Processors of the application circuitry 2202 and processors of the baseband circuitry 2204 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 2204, alone or in combination, may be used to execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 2202 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g.,

transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

[0109] FIG. 23 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 2204 of FIG. 22 may comprise processors 2204A-2204E and a memory 2204G utilized by said processors. Each of the processors 2204A-2204E may include a memory interface, 2304A-2304E, respectively, to send/receive data to/from the memory 2204G.

[0110] The baseband circuitry 2204 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 2312 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 2204), an application circuitry interface 2314 (e.g., an interface to send/receive data to/from the application circuitry 2202 of FIG. 22), an RF circuitry interface 2316 (e.g., an interface to send/receive data to/from RF circuitry 2206 of FIG. 22), a wireless hardware connectivity interface 2318 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components,

Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 2320 (e.g., an interface to send/receive power or control signals to/from the PMC 2212.

[0111] FIG. 24 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Specifically, FIG. 24 shows a diagrammatic representation of hardware resources 2400 including one or more processors (or processor cores) 2410, one or more memory/storage devices 2420, and one or more communication resources 2430, each of which may be communicatively coupled via a bus 2440. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 2402 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 2400.

[0112] The processors 2410 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 2412 and a processor 2414.

[0113] The memory/storage devices 2420 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 2420 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable

programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0114] The communication resources 2430 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 2404 or one or more databases 2406 via a network 2408. For example, the communication resources 2430 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular

communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication

components.

[0115] Instructions 2450 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 2410 to perform any one or more of the methodologies discussed herein. The instructions 2450 may reside, completely or partially, within at least one of the processors 2410 (e.g., within the processor's cache memory), the memory/storage devices 2420, or any suitable combination thereof. Furthermore, any portion of the instructions 2450 may be transferred to the hardware resources 2400 from any combination of the peripheral devices 2404 or the databases 2406. Accordingly, the memory of processors 2410, the memory/storage devices 2420, the peripheral devices 2404, and the databases 2406 are examples of computer-readable and machine-readable media.

7. Examples

[0116] Example 1 is an apparatus for an evolved Node B (eNB), comprising a memory interface and one or more processors. The memory interface configured to receive information representing a list of radio access network (RAN) nodes to page during RAN-based paging of a lightly connected user equipment (UE). The one or more processors configured to: process data arriving for the lightly connected UE; and generate, in response to the data arriving and based on the list of RAN nodes, an X2 application protocol (X2AP) message for the RAN-based paging of the lightly connected UE.

[0117] Example 2 is the apparatus of Example 1 , in which the one or more processors are further configured to process UE mobility history information so as to generate the list of RAN nodes to page during the RAN-based paging of the lightly connected UE.

[0118] Example 3 is the apparatus of Example 1 , in which the one or more processors are further configured to process a tracking area identity (TAI) list to generate the list of RAN nodes to page during the RAN-based paging of the lightly connected UE.

[0119] Example 4 is the apparatus of any preceding Example, in which the list is a first list for an initial paging attempt, and the one or more processors are configured to generate a second list, different from the first list, for a subsequent paging attempt.

[0120] Example 5 is the apparatus of Example 1 or 3, in which the one or more processors are further configured to generate the list by selecting a subset of a tracking area.

[0121] Example 6 is the apparatus of any of Examples 1-3, in which the X2AP message includes a UE identity index.

[0122] Example 7 is the apparatus of any of Examples 1-3, in which the X2AP message includes RAN paging discontinuous reception (DRX) information.

[0123] Example 8 is the apparatus of any of Examples 1-3, in which the X2AP message includes a paging priority information element defining a priority for a flow of the UE. [0124] Example 9 is the apparatus of any of Examples 1-3, in which the one or more processors are further configured to initiate a timer to control timing of paging messages.

[0125] Example 10 is the apparatus of any of Examples 1-3, in which the one or more processors count a number of paging attempts.

[0126] Example 1 1 is an apparatus for an evolved Node B (eNB) configured to act as an anchor eNB for radio access network (RAN)-based paging of a user equipment (UE) served by a serving eNB that is different from the anchor eNB. The evolved Node B (enB) comprising a memory interface and one or more processors. The memory interface configured to receive information representing a UE context of the UE. The one or more processors configured to: process a first message from the serving eNB, the first message requesting the UE context; and in response to the first message, generate a second message for the serving eNB, the second message including the information representing the UE context.

[0127] Example 12 is the apparatus of Example 1 1 , in which the first message includes downlink (DL) data forwarding information.

[0128] Example 13 is the apparatus of Example 1 1 or 12, in which the second message includes an indication of downlink data available for forwarding.

[0129] Example 14 is the apparatus of Example 1 1 or 12, in which the one or more processors are further configured to process a third message from the serving eNB, the third message providing downlink (DL) data forwarding information.

[0130] Example 15 is the apparatus of Example 1 1 or 12, in which at least one of the first and second messages includes E-UTRAN Radio Access Bearers (E-RABs) information.

[0131] Example 16 is an apparatus for a user equipment (UE), comprising a memory interface and one or more processors. The memory interface configured to receive information representing an indication to enter a lightly connected state. The one or more processors configured to process the indication and thereby enter lightly connected state for awaiting a radio access network (RAN)-initiated paging message.

[0132] Example 17 is the apparatus of Example 16, in which the indication is an explicit indication carried in a message from an evolved Node B (eNB).

[0133] Example 18 is the apparatus of Example 16 or 17, in which the indication is provided in a radio resource control (RRC) message. [0134] Example 19 is the apparatus of Example 16, in which the indication is an indirect indication implied by a radio access network (RAN)-based paging

discontinuous reception (DRX) cycle configuration.

[0135] Example 20 is the apparatus of Example 16, in which the indication is provided by a suspend indication.

[0136] Example 21 is a machine readable medium for an evolved Node B (eNB), the machine readable medium having stored thereon instructions and information representing a light connection state of a user equipment (UE), the instructions, when executed, cause one or more processor to: process an S1 application protocol (S1AP) release request message indicating a mobility management entity (MME) is transitioning the UE from a connected state to an idle state; and generate an update to the light connection state and a corresponding S1 AP release response for the MME.

[0137] Example 22 is the machine readable medium of Example 21 , in which the one or more processors are further configured to generate a core network (CN)- initiated paging message for the UE in response to the light connection state stored by the eNB being different from an actual connection state of the UE.

[0138] Example 23 is the machine readable medium of Example 21 or 22, in which the one or more processors are further configured to generate a radio resource control (RRC) paging message to the UE so as to release its light connection.

[0139] Example 24 is an apparatus for an evolved Node B (eNB), comprising a memory interface and one or more processors. The memory interface configured to receive information representing a UE light connection state. The one or more processors configured to: process an S1 application protocol (S1AP) release request message indicating a mobility management entity (MME) is transitioning the UE from a connected state to an idle state; and generate an update to the light connection state and a corresponding S1 AP release response for the MME.

[0140] Example 25 is the apparatus of Example 24, in which the one or more processors are further configured to generate a core network (CN)-imitated paging message for the UE in response to the UE light connection state stored by the eNB being different from an actual connection state of the UE. [0141] Example 26 is the apparatus of Example 25, in which the one or more processors are further configured to generate a radio resource control (RRC) paging message to the UE so as to release its light connection.

[0142] Example 27 is a method performed by an evolved Node B (eNB), comprising: receiving through a memory interface information representing a list of radio access network (RAN) nodes to page during RAN-based paging of a lightly connected user equipment (UE); and processing data arriving for the lightly connected UE; and generating, in response to the data arriving and based on the list of RAN nodes, an X2 application protocol (X2AP) message for the RAN-based paging of the lightly connected UE.

[0143] Example 28 is the method of Example 27, further comprising processing UE mobility history information so as to generate the list of RAN nodes to page during the RAN-based paging of the lightly connected UE.

[0144] Example 29 is the method of Example 27, further comprising processing a tracking area identity (TAI) list to generate the list of RAN nodes to page during the RAN-based paging of the lightly connected UE.

[0145] Example 30 is the method of any of Examples 27-29, in which the list is a first list for an initial paging attempt, and further comprising generating a second list, different from the first list, for a subsequent paging attempt.

[0146] Example 31 is the method of Example 27 or 29, further comprising generating the list by selecting a subset of a tracking area.

[0147] Example 32 is the method of any of Examples 27-29, in which the X2AP message includes a UE identity index.

[0148] Example 33 is the method of any of Examples 27-29, in which the X2AP message includes RAN paging discontinuous reception (DRX) information.

[0149] Example 34 is the method of any of Examples 27-29, in which the X2AP message includes a paging priority information element defining a priority for a flow of the UE.

[0150] Example 35 is the method of any of Examples 27-29, further comprising initiating a timer to control timing of paging messages.

[0151] Example 36 is the method of any of Examples 27-29, further comprising counting a number of paging attempts.

[0152] Example 37 is a method performed by an evolved Node B (eNB) configured to act as an anchor eNB for radio access network (RAN)-based paging of a user equipment (UE) served by a serving eNB that is different from the anchor eNB, comprising: receiving via a memory interface information representing a UE context of the UE; and processing a first message from the serving eNB, the first message requesting the UE context; and in response to the first message, generating a second message for the serving eNB, the second message including the information representing the UE context.

[0153] Example 38 is the method of Example 37, in which the first message includes downlink (DL) data forwarding information.

[0154] Example 39 is the method of Example 37 or 38, in which the second message includes an indication of downlink data available for forwarding.

[0155] Example 40 is the method of Example 37 or 38, further comprising processing a third message from the serving eNB, the third message providing downlink (DL) data forwarding information.

[0156] Example 41 is the method of Example 37 or 38, in which at least one of the first and second messages includes E-UTRAN Radio Access Bearers (E-RABs) information.

[0157] Example 42 is a method performed by a user equipment (UE), comprising: receiving through a memory interface information representing an indication to enter a lightly connected state; and processing the indication and thereby enter lightly connected state for awaiting a radio access network (RAN)-initiated paging message.

[0158] Example 43 is the method of Example 42, in which the indication is an explicit indication carried in a message from an evolved Node B (eNB).

[0159] Example 44 is the method of Example 42 or 43, in which the indication is provided in a radio resource control (RRC) message.

[0160] Example 45 is the method of Example 42, in which the indication is an indirect indication implied by a radio access network (RAN)-based paging

discontinuous reception (DRX) cycle configuration.

[0161] Example 46 is the method of Example 42, in which the indication is provided by a suspend indication.

[0162] Example 47 is a method performed by an evolved Node B (eNB), comprising: receiving through a memory interface information representing a UE light connection state; processing an S1 application protocol (S1AP) release request message indicating a mobility management entity (MME) is transitioning the UE from a connected state to an idle state; and generating an update to the light connection state and a corresponding S1 AP release response for the MME.

[0163] Example 48 is the method of Example 47, further comprising generating a core network (CN)-initiated paging message for the UE in response to the light connection state stored by the eNB being different from an actual connection state of the UE.

[0164] Example 49 is the method of Example 47 or 48, further comprising generating a radio resource control (RRC) paging message to the UE so as to release its light connection.

[0165] Example 50 is an apparatus comprising means to perform a method as exemplified in any in any of Examples 27-49.

[0166] Example 51 is a machine-readable storage including machine-readable instructions, when executed, to implement a method or realize an apparatus as exemplified in any preceding Example.

[0167] Example 52 is a machine readable medium including code, when executed, to cause a machine to perform the method as exemplified in any in any of Examples 27-49.

[0168] Example 53 may include a User Equipment (UE) configured to operate in a 3GPP network in accordance with stored context while being suspended with light connection with an Evolved Node-B (eNB), the UE comprising hardware processing circuitry configured to: suspend/hold its context information and other necessary connection configuration for re-use during next connection

[0169] Example 54 may include an evolved Node B (eNB) or a similar network node which can support communication using suspend and Resume signalling through storing of a UE contexts for the UE of example 53 and other necessary connection configuration.

[0170] Example 55 may include an example of example 54 and/or some other examples herein, wherein the eNB may send a paging message over X2 or similar interface to list of recommended cells of eNBs that the UE has visited in the recent history if available.

[0171] Example 56 may include an example of example 54 and/or some other examples herein, wherein eNB may update the tracking area list to an example of example 53 and/or some other examples herein. [0172] Example 57 may include an example of example 54 and/or some other examples herein, wherein at least the DL tunnel identifier information for receiving any downlink data from another example of example 54 and/or some other examples herein is added either as part of a new message or as part of an existing message over X2 or similar interface.

[0173] Example 58 may include an example of example 54 and/or some other examples herein, wherein at least the list of E-RABs that have pending data for an example of example 53 and/or some other examples herein is provided as part of RETRIEVE UE CONTEXT RESPONSE message.

[0174] Example 59 may include an example of example 54 and/or some other examples herein, wherein the actual contents of paging message sent to another example of example 54 and/or some other examples herein are defined including at least the RAN paging DRX cycle, RAN paging ID options, paging priority, potential small data request for the UE to send uplink data and other eMTC/NB-IOT related parameters.

[0175] Example 60 may include an example of example 54 and/or some other examples herein, wherein an explicit indication or configuration for light connection mode is provided to a UE, an example of example 53 and/or some other examples herein.

[0176] Example 61 may include an example of example 53 and/or some other examples herein, which provides the indication of light connection mode support through other set up or negotiation during UE capabilities or other means

[0177] Example 62 may include an example of example 53 and/or some other examples herein, wherein the transition between legacy Core network paging and RAN based paging are seamless and transparent to the UE of example 53 and/or some other examples herein.

[0178] Example 63 may include an example of example 54 and/or some other examples herein, wherein it resumes the connection of UE of example 53 and/or some other examples herein only to release it for graceful release into idle mode when a mismatch in states or modes is detected between the UE of example 53 and the core network.

[0179] Example 64 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 53-63, or any other method or process described herein. [0180] Example 65 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 53-63, or any other method or process described herein.

[0181] Example 66 may include an apparatus comprising logic, modules, and/or circuitry to perform one or more elements of a method described in or related to any of examples 53-63, or any other method or process described herein.

[0182] Example 67 may include a method, technique, or process as described in or related to any of examples 53-63, or portions or parts thereof.

[0183] Example 68 may include an apparatus comprising: one or more

processors and one or more computer readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 53-63, or portions thereof.

[0184] Example 69 may include a method of communicating in a wireless network as shown and described herein.

[0185] Example 70 may include a system for providing wireless communication as shown and described herein.

[0186] Example 71 may include a device for providing wireless communication as shown and described herein.

8. Concluding Remarks

[0187] The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. Skilled persons will appreciate that many changes may be made to the details of the above-described embodiments without departing from the underlying principles of the invention. The scope of the present invention should, therefore, be determined only by the following claims.