WO2018057120A1 - Apparatuses for configuration of a light connection - Google Patents

Apparatuses for configuration of a light connection Download PDF

Info

Publication number
WO2018057120A1
WO2018057120A1 PCT/US2017/044658 US2017044658W WO2018057120A1 WO 2018057120 A1 WO2018057120 A1 WO 2018057120A1 US 2017044658 W US2017044658 W US 2017044658W WO 2018057120 A1 WO2018057120 A1 WO 2018057120A1
Authority
WO
WIPO (PCT)
Prior art keywords
rrc
message
mode
indication
context
Prior art date
Application number
PCT/US2017/044658
Other languages
French (fr)
Inventor
Sangeetha Bangolae
Marta Martinez TARRADELL
Sudeep Palat
Bharat Shrestha
Original Assignee
Intel IP Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel IP Corporation filed Critical Intel IP Corporation
Priority to CN201780054776.3A priority Critical patent/CN109691222B/en
Publication of WO2018057120A1 publication Critical patent/WO2018057120A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices

Definitions

  • the present disclosure relates to supporting light connection.
  • the present disclosure relates to changes in RRC to support light connection, defining a RAN-based paging area or notification area in RRC, and defining changes to the X2AP specification for supporting light connection.
  • 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 3rd
  • 3GPP long term evolution
  • IEEE Institute of Electrical and Electronics Engineers 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access
  • the base station can include a RAN Node such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) and/or Radio Network Controller (RNC) in an E-UTRAN, which communicate with a wireless communication device, known as user equipment (UE).
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • Node B also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB
  • RNC Radio Network Controller
  • UE user equipment
  • RAN Nodes can include a 5G Node.
  • 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.
  • GSM global system for mobile communications
  • EDGE enhanced data rates for GSM evolution
  • GERAN enhanced data rates for GSM evolution
  • UTRAN Universal Terrestrial Radio Access Network
  • E-UTRAN E-UTRAN
  • 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).
  • SGW serving gateway
  • PGW packet data network gateway
  • ANDSF access network detection and selection function
  • ePDG enhanced packet data gateway
  • MME mobility management entity
  • LTE defines two radio resource control (RRC) operating states for a UE. These are RRC_Connected (i.e., RRC_CONNECTED), for when there is data to exchange between the UE and the E-UTRAN, and RRCJdle (i.e., RRCJDLE), for when there is no data to exchange between the UE and the E-UTRAN.
  • RRC_Connected i.e., RRC_CONNECTED
  • RRCJdle i.e., RRCJDLE
  • FIG. 1 is a message diagram that illustrates an embodiment in which a UE is released based on a decision made by the anchor eNB.
  • FIG. 2 is a message diagram that illustrates an embodiment in which a UE is released based on a decision made by the eNB2.
  • FIG. 3 is a message diagram that illustrates an embodiment in which an anchor eNB suspends a UE that has moved to another eNB (i.e., eNB2).
  • FIG. 4 is a message diagram that illustrates an embodiment in which the UE context suspend is performed by a new eNB (e.g., eNB2).
  • FIG. 5 is a message diagram that illustrates an embodiment of a cell update procedure in which the UE is kept in light connection with the anchor eNB.
  • FIG. 6 is a message diagram that illustrates an embodiment of a cell update procedure in which the UE is kept in light connection with a new anchor eNB (e.g., eNB2) after an S1 path switch.
  • a new anchor eNB e.g., eNB2
  • FIG. 7 is a message diagram that illustrates an embodiment in which the UE has mobile-originated data to send and is resumed from light connected mode for data transfer.
  • FIG. 8 is a message diagram that illustrates an embodiment in which the network (e.g., S-GW) has mobile-terminated data for the UE and the UE is resumed from light connected mode for data transfer.
  • the network e.g., S-GW
  • FIG. 9 is a message diagram that illustrates an embodiment in which a paging message is communicated between a second eNB and a first eNB.
  • FIG. 10 is a flow diagram of a method for operating in a light connected mode.
  • FIG. 1 1 illustrates an architecture of a system of a network in accordance with some embodiments.
  • FIG. 12 illustrates example components of a device in accordance with some embodiments.
  • FIG. 13 illustrates example interfaces of baseband circuitry in accordance with some embodiments.
  • FIG. 14 is an illustration of a control plane protocol stack in accordance with some embodiments.
  • FIG. 15 is an illustration of a user plane protocol stack in accordance with some embodiments.
  • FIG. 16 illustrates components of a core network in accordance with some embodiments.
  • FIG. 17 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.
  • a machine-readable or computer-readable medium e.g., a non-transitory machine-readable storage medium
  • a UE has a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN) and operates in an RRC_Connected state. While in the RRC_Connected state, the UE decodes an RRC message that includes an indication to enter a lightly connected RRC mode. In response to the indication, the UE configures the lightly connected RRC mode. In the lightly connected RRC mode, the RRC connection is suspended (the access stratus (AS) context information associated with the RRC connection is saved, for example). In some embodiments, the lightly connected RRC mode is a substate within the RRC_Connected state. In other embodiments, the lightly connected RRC mode is a substate within the RRCJdle state.
  • RRC radio resource control
  • the lightly connected RRC mode is its own RRC state.
  • the lightly connected RRC mode mode is a substate in the RRCJdle state and the UE transitions to the RRCJdle state while in the lightly connected RRC mode (transitions to the lightly connected RRC mode substate within the RRCJdle state, for example).
  • a UE operates in an RRC state (e.g., a lightly connected RRC mode in the RRCJdle state or a lightly connected RRC mode in the RRC_Connected state) but maintains a light connection with an E-UTRAN.
  • the UE generates an RRC connection resume request message.
  • the RRC connection resume request includes a resume identity.
  • the UE decodes an RRC connection reject message that includes an indication that the UE should remain in the lightly connected RRC mode.
  • the UE maintains the stored resume identity and stored AS context information.
  • the UE operates in the RRC state while in the lightly connected RRC mode.
  • an eNB establishes an S1 -U interface with a serving gateway for a user equipment (UE) in an RRC_Connected state.
  • the eNB generates an RRC message for the UE to transition to an RRC state in a lighly connected RRC mode (transition to a lightly connected substate in the
  • the RRC message includes an indication for the UE to enter a lightly connected RRC mode.
  • the eNB maintains the S1 -U interface with the serving gateway for the UE while the UE is in the lightly connected RRC mode.
  • 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 3rd
  • 3GPP long term evolution
  • IEEE Institute of Electrical and Electronics Engineers 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access
  • the base station can include Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and/or Radio Network Controllers (RNCs) in an E-UTRAN, which communicate with a wireless communication device, known as user equipment (UE).
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • Node Bs also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs
  • RNCs Radio Network Controllers
  • the proposed solution provides advantages, which include supporting an RRC light connection mechanism by which the S1 signaling is kept while the UE is released into lightly connected mode.
  • the signaling to change to active mode is highly reduced in this manner compared to legacy idle (e.g., RRCJdle state) to active mode (e.g., RRC_Connected state) transition.
  • legacy idle e.g., RRCJdle state
  • active mode e.g., RRC_Connected state
  • a proposed solution is being considered as part of the 5G control plane where it is being discussed as a new state in RRC (instead of being a separate mode/state (e.g. , substate within either RRC_Connected or RRCJdle) as it is proposed herein).
  • the new state in RRC would be similar to lightly connected state in LTE so that a UE could move seamlessly between new radio (NR) (e.g. , 5G) and LTE in this state.
  • NR new radio
  • the paging area could include cells belonging to both NR and LTE.
  • the proposed solution includes specification (e.g. , 3GPP TS 36.331 , 3GPP TS 36.423) changes related to RRC and X2AP for supporting a light connection mechanism.
  • the proposed solution defines novel specification impacts in RRC to support light connection such as capability definition and connection release/reject indications, defines RAN-based Paging area or notification area in RRC (broadcast and dedicated signaling), and defines changes to X2AP specification for supporting light connection mode and different options when there is mobility across paging/notification areas.
  • a UE can be in either RRC_Connected or RRCJdle state.
  • RRC_Connected state the UE and the eNB have a UE RAN context that stores the current RAN configuration for the UE that is used for communication between the UE and the network.
  • the UE has no data to send, it can be moved to the
  • RRCJdle where the UE RAN context is released. In this state, the UE cannot communicate with the network.
  • the UE When the UE is in the RRCJdle state and there is data to be exchanged between the UE and network, it has to go into connected state. During this process, the UE RAN context in the eNB and UE is established. This normally involves a lot of signaling both in terms of number of messages and number of bytes that need to be exchanged.
  • 3GPP standards have developed a method for signaling load reduction during idle active transitions. This involves storing the last used UE RAN context in the eNB and UE even when the UE is RRCJdle. Then when the UE goes into RRC_Connected, it just needs to revive the stored context in the eNB and the UE; this process is called resume in current LTE. This resumption of the stored context only involves a couple of signaling messages and thereby saves a lot of signaling messages and bytes. The UE is considered Suspended when the UE is in RRCJdle state but has stored UE RAN context.
  • the RAN node e.g., eNB
  • the UE is paged through the MME using an S1 -AP paging message.
  • the RAN node retains the UE RAN context. Hence, the UE can be paged by the RAN node itself. This can be called a RAN-based paging mechanism.
  • the interface between RAN nodes needs to be present so that the serving or anchor RAN node can page another RAN node to determine where the UE may have moved.
  • this interface between RAN nodes is called the X2 interface (it could be another interface in 5G/NR, for example).
  • the interface between an eNB and the MME is called an S1 -MME interface and is used for signaling between the eNB and the MME.
  • the interface between an eNB and the S-GW is called the S1 -U interface and is used for signaling between the eNB and the S-GW.
  • this interface is torn down when the UE is idle (e.g., in RRCJdle state) or suspended.
  • this S1 (e.g., S1 -U) is kept active when the UE is released into light connection.
  • the standard (e.g., 3GPP TS 36.331 ) may be updated as set forth in the following pseudocode:
  • the suspension of the RRC connection is initiated by E-UTRAN.
  • the UE stores the UE AS context and the resumeldentity, and transitions to RRCJDLE state.
  • the RRC message to suspend the RRC connection is integrity protected and ciphered. Suspension can only be performed when at least 1 DRB is successfully established.
  • the suspend procedure is also used to enter lightly connected RRC mode.
  • the RRC connection reconfiguration can also be used to enter and/or configure lightly connected RRC mode if necessary.
  • RRC connection resume is permitted by E- UTRAN, and the UE needs to transit from RRCJDLE state to RRC_CONNECTED state.
  • RRC configures the UE according to the RRC connection resume procedure based on the stored UE AS context and any RRC configuration received from E-UTRAN.
  • the procedure re-activates security and re-establishes SRB(s) and DRB(s).
  • the request to resume the RRC connection includes the resumeldentity.
  • the request is not ciphered, but protected with a message authentication code.
  • E-UTRAN may resume the suspended RRC connection, reject the request to resume and instruct the UE to either keep or discard the stored context, or setup a new RRC connection.
  • the resumption procedure of a suspended RRC connection is also used to resume a lightly connected RRC.
  • the standard (e.g., 3GPP TS 36.331 ) may be updated as set forth in the following pseudocode:
  • E-UTRAN initiates the RRC connection release procedure to a UE in
  • the UE supports delay tolerant access or the UE is a NB-loT UE:
  • the above standard may be updated as set forth in the following pseudocode:
  • the UE supports delay tolerant access or the UE is a NB-loT UE:
  • the standard (e.g., 3GPP TS 36.331 ) may be updated as set forth in the following pseudocode: 5.3.12 UE actions upon leaving RRC_CONNECTED
  • the UE Upon leaving RRC_CONNECTED, the UE shall:
  • the UE AS Context including the current RRC configuration, the current security context, the PDCP state including ROHC state, C-RNTI used in the source PCell, the cellldentity and the physical cell identity of the source PCell;
  • one or more of the RRC messages that are defined in the standard may be updated.
  • the RRC connection reject message may be updated as set forth in the following Abstract Syntax Notation One (ASN1 ) code:
  • deprioritisationType-r1 1 ENUMERATED ⁇ frequency, e- utra ⁇
  • the RRCConnectionReject message includes an
  • RRCConnectionReject-v14xy-IE (information element).
  • the deprioritisationReq field indicates whether the current frequency or RAT is to be de-prioritized.
  • the UE shall be able to store a deprioritisation request for up to 8 frequencies (applicable when receiving another frequency-specific deprioritisation request before T325 expiry).
  • the deprioritisationTimerf e ⁇ d indicates the period for which either the current carrier frequency or E-UTRA is deprioritised.
  • Value minN corresponds to N minutes.
  • the extendedWaitTime field is a value in seconds for the wait time for Delay Tolerant access requests.
  • the waitTime field is a Wait time value in seconds.
  • the rrcSuspendlndication field indicates that the UE should remain suspended and not release its stored context.
  • the rrcLightConnectionlndication field indicates that the UE should remain lightly connected and not release its stored context.
  • the RRC connection release message may be updated as set forth in the following ASN1 code:
  • the RRC connection release message may be updated as set forth in the following ASN1 code:
  • RRCConnectionRelease-v1400-IEs :: SEQUENCE ⁇ ReleaseCause-r14 ENUMERATED ⁇ rrcLightlyConnected-v1400 ⁇ OPTIONAL,
  • light connection mode may be entered into (i.e., configured) through the use of an RRC connection release message. Additionally or alternatively, light connection mode may be entered into through the use of an RRC connection reconfiguration message.
  • an IE e.g., OtherConfig IE
  • the OtherConfig IE contains configuration information related to other configuration.
  • the OtherConfig IE may be updated as set forth in the following ASN1 code:
  • NghtConnectionConfig-r14 ObtainLocationConfig-r14
  • a UE that is in RRCJdle state, for example
  • the RAN node does not have a UE RAN context for the UE.
  • the RAN node retains the UE RAN context and can be paged by the RAN node itself. This enables new solutions for RAN-based paging.
  • the specification e.g., 3GPP TS 36.331
  • SystemlnformationBlockTypel -v1400 IE of a broadcast signal may be updated to enable a RAN-based paging mechanism as set forth in the following ASN1 code:
  • the SystemlnformationBlockTypel -v1400 IE includes a RANpagingAreaCode field and a RANPagingAreaCode IE.
  • the RANpagingAreaCode field refers to the RAN-based paging area identifier.
  • the RANPagingAreaCode IE is used to identify a RAN-based paging area within the scope of a PLMN/tracking area.
  • a PLMN/tracking area In some embodiments, a
  • RANPagingAreaCode IE may be defined as set forth in the following ASN1 code:
  • an RRC connection reconfiguration message may be updated to enable a RAN-based paging mechanism.
  • an RRC connection reconfiguration may be updated to enable a RAN-based paging area using dedicated signaling as set forth in the following ASN1 code:
  • the RANPagingArealnfo-r14 IE includes a maxCells-r14 field.
  • the RAN paging area defined above could also be defined as RAN Notification Area.
  • a RAN Notification Area may consist of a list of cells belonging to one or multiple RAN nodes or a list of RAN Paging Areas.
  • a UE may indicate whether it supports light connection.
  • the UE may indicate this capability in a UE-EUTRA- Capability IE.
  • the UE-EUTRA-Capability IE may be used to convey the E-UTRA UE Radio Access Capability Parameters, see TS 36.306, and the Feature Group Indicators for mandatory features (defined in Annexes B.1 and C.1 ) to the network.
  • the UE-EUTRA-Capability IE is transferred in E-UTRA or in another RAT.
  • a UE-EUTRA-Capability IE may be updated as set forth in the following ASN1 code:
  • the UE-EUTRA-Capability IE includes multiple UE-EUTRA- Capability field descriptions.
  • the UE-EUTRA-Capability IE includes a lightConnection field description.
  • the lightConnection field indicates the support of light connection (indicates that the UE supports light connection mode, for example).
  • support for light connection could also be provided by the UE as part of the device properties IE within 3GPP TS 36.306.
  • RRC-dedicated signaling such as an RRC Cell Update Request and/or an RRC Cell Update Response
  • RRC Cell Update Request and/or an RRC Cell Update Response are already defined. These message exchanges are used whenever UE moves across a paging area or a notification area to let the network know about its mobility. These messages are used when there is no data to transfer. In some cases, the response message could carry a suspend or a release indication to suspend or release the UE respectively. Both the RRC Cell Update Request message and the RRC Cell Update Response message are discussed in turn below.
  • the RRC Cell Update Request (e.g., a request for RRC Cell Update Request).
  • RRCCellUpdateRequest is used to perform an update procedure when the UE is crossing a paging area boundary of a light RRC connection or a RAN- configured tracking area.
  • the RRC Cell Update Request message uses signaling radio bearer SRB0, uses radio link control (RLC) service access point (SAP) in transparent mode (TM), uses the common control channel (CCCH) logical channel, and is a message between the UE and the E-UTRAN with a direction of UE to E-UTRAN.
  • RRC Cell Update Request message is proposed as set forth in the following ASN1 code: - AS N1 START
  • the RRCCellUpdateRequest message includes multiple
  • RRCConnectionResumeRequest or RRCCellUpdateRequest field descriptions.
  • the RRCConnectionResumeRequest field descriptions include a
  • resumeCause field description a resumeldentity field description
  • resumeldentity field description a resumeldentity field description
  • the resumeCause field provides the resume cause for the RRC connection resume request as provided by the upper layers.
  • the resumeldentity field is the UE identity to facilitate UE context retrieval at the eNB. In some embodiments, the
  • shortResumeMAC-l field is an authentication token to facilitate UE authentication at the eNB.
  • the proposed RRCCellUpdateRequest message is similar to the existing Rel-13 RRCConnectionResumeRequest message.
  • an indication using spare bit can be added to the existing message (e.g.,
  • the response to an RRCCellUpdateRequest message may be an RRC connection release (as described above, for example) or the following message (e.g., an RRCCellUpdateConfirm message), which involves configuration information for the light connection mode.
  • an RRCCellUpdateConfirm message e.g., an RRCCellUpdateConfirm message
  • RRCCellUpdateConfirm message is provided in the case of a successful cell update.
  • the RRCCellUpdateConfirm message may be used to respond to a Cell Update Request for the light RRC connection.
  • the RRCCellUpdateConfirm message may be used to respond to a Cell Update Request for the light RRC connection.
  • the RRCCellUpdateConfirm message may be used to respond to a Cell Update Request for the light RRC connection.
  • RRCCellUpdateConfirm message uses signaling radio bearer SRB1 , uses radio link control (RLC) service access point (SAP) in acknowledged mode (AM), uses the dedicated control channel (DCCH) logical channel, and is a message between the E- UTRAN and the UE with a direction of E-UTRAN to UE.
  • RLC radio link control
  • DCCH dedicated control channel
  • ASN1 code an RRCCellUpdateConfirm message is proposed as set forth in the following ASN1 code:
  • RRCCellUpdateConfirm-r14-IEs SEQUENCE ⁇ radioResourceConfigDedicated-r13 RadioResourceConfigDedicated
  • the RRCCellUpdateConfirm message includes multiple
  • RRCCellUpdateConfirm field descriptions include a drb-ContinueROHC field description and a ReleaseCause field description.
  • the drb- ContinueROHC field indicates whether to continue or reset the header compression protocol context for the DRBs configured with the header compression protocol. Presence of this field indicates that the header compression protocol context continues while absence indicates that the header compression protocol context is reset.
  • the ReleaseCause field indicates that the RRC connection is released after successful Cell Update.
  • the lEs shown within the RRCCellUpdateConfirm message are exemplary and one or more lEs may not be necessary as it is not necessary to configure DRB-related parameters for the UE that will be released into suspend or light connection or idle mode after the procedure. Furthermore, additional lEs may be added as necessary; an example of ReleaseCause has been added (as shown, for example). This is not an exhaustive list.
  • a response to an RRCCellUpdateConfirm message may be sent by the UE which will be similar to an RRCResumeComplete message which can be followed by RRCConnectionRelease message. Alternatively the
  • RRCCellUpdateConfirm may be sent by the network containing the information that it gets sent by RRCConnectionRelease message directly and including a new indication for the UE to differentiate the network indication to release the connection via the RRCCellUpdateConfirm message such as the cellUpdateReleaseCause as defined above.
  • one or more portions of the 3GPP TS 36.331 specification may be updated and/or modified to support a light connection mode. Additionally or alternatively, one or more portions of the 3GPP TS 36.423
  • the decision on whether the UE is released, suspended or lightly connected could be taken by a second eNB (e.g., eNB2) and/or an anchor eNB (e.g., eNB1 ). For this decision, corresponding indications could be included in the S1 -AP signaling exchanged between eNB2 and anchor eNB1 .
  • a second eNB e.g., eNB2
  • an anchor eNB e.g., eNB1
  • corresponding indications could be included in the S1 -AP signaling exchanged between eNB2 and anchor eNB1 .
  • FIGs. 1 -10 illustrate a communication system that includes a UE 102, a second eNB (i.e., eNB2) 104, an anchor eNB 106, a mobility management entity (MME) 108, and a serving gateway (S-GW) 1 10.
  • eNB2 a second eNB
  • MME mobility management entity
  • S-GW serving gateway
  • the UE 102 may wirelessly communicate with the eNB2 104 via a Uu interface
  • the eNB2 104 may communicate with the anchor eNB 106 via an X2 interface
  • the eNB2 104 and/or the anchor eNB 106 may communicate with the MME 108 via an S1 -MME interface, which uses an S1 -AP application layer interface
  • the eNB2 104 and/or the anchor eNB 106 may communicate with the S-GW 1 10 via an S1 -U interface
  • the MME 108 may communicate with the S-GW 1 10 via an S1 1 interface. It is appreciated that the discussed messages are interface-specific and are understood to be communicated using the appropriate interface. [0075] FIG.
  • FIG. 1 is a message diagram that illustrates an embodiment 100 in which the UE 102 is released based on a decision made by the anchor eNB 106.
  • the UE 102 transmits a first random access (RA) message (msg) (i.e., RA msg 1 ) 1 12 with an RA preamble to the eNB2 104 using a physical random access channel (PRACH).
  • RA random access
  • msg 1 i.e., RA msg 1
  • PRACH physical random access channel
  • the eNB2 104 transmits a second RA msg (i.e., RA msg 2) 1 14 to the UE 102.
  • the RA msg 2 1 14 may be a random access response (RAR) message.
  • RAR random access response
  • the UE 102 in the embodiment 100 is in a light connection mode. This means that the UE 102 has a stored UE RAN context and the anchor eNB 106 has a stored UE RAN context for the UE 102. While the UE 102 is in the light connection mode, the anchor eNB 106 maintains an S1 -U interface 1 16 with the S-GW 1 10 for the UE 102. In addition, while the UE 102 is in the light connection mode, the UE 102 maintains a stored Resume ID and a stored resumeMAC-l.
  • the stored UE RAN context and the maintained parameters (e.g., Resume ID, resumeMAC-l) and interfaces (e.g., the S1 -U interface 1 16) enable the UE 102 to resume its prior UE context with only a small amount of signaling.
  • the UE 102 transmits an RRC Cell Update Request 1 18 to the eNB2 104.
  • the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the eNB2 104 transmits a retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 may determine to release the UE 102 from light connection (e.g., light connection mode). In one example, this determination is made in response to receiving the retrieve UE context request 120. In another example, this decision may have been determined previous to the reception of the retrieve UE context request 120.
  • the anchor eNB 106 may transmit an S1 -AP: UE context release request 122 to the MME 108.
  • the MME 108 transmits a release access bearer request 124 to the S-GW 1 10.
  • the S- GW 1 10 transmits a release access bearer response 126 to the MME 108.
  • the MME 108 Upon receiving the release access bearer response 126, the MME 108 transmits an S1 - AP: UE context release command 128 to the anchor eNB 106.
  • the anchor eNB 106 transmits a retrieve UE context response with a release indication 130 to the eNB2 104.
  • the retrieve UE context response with the release indication 130 may contain the indication that the UE 102 is to be released to RRCJdle state.
  • the anchor eNB 106 transmits an S1 -AP: UE context release response 134 to the MME 108. Through this process, the S1 -U interface 1 16 that was previously maintained is released.
  • the eNB2 104 transmits an RRC connection release message 132 to the UE 102.
  • a UE RRC connection 136 is released. It is appreciated that this release of the UE RRC connection 136 includes a release of the UE RAN context at the UE 102 and the UE RAN context at the anchor eNB 106.
  • the anchor eNB 106 releases the S1 -U interface 1 16 and any other context information associated with the UE 102.
  • the UE 102 releases any parameters and context information associated with its prior RRC connection.
  • the UE 102 which began in a lightly connected mode, is released to RRCJdle state without light connection (i.e., the RRC connection is released). In the embodiment 100 this release was triggered by the anchor eNB 106.
  • FIG. 2 is a message diagram that illustrates an embodiment 200 in which the UE 102 is released based on a decision made by the eNB2 104. It is
  • FIG. 2 is similar to FIG. 1 , except that it is the eNB2 104 rather than the anchor eNB 106 that triggers the release of the UE 102.
  • the new eNB e.g., the eNB2 104
  • the UE RAN context it can initiate the release at any time using the UE CONTEXT RELEASE REQUEST as per 3GPP TS 36.413. In some embodiments, no specification change is necessary.
  • the UE 102 retrieves the UE RAN context from the anchor eBN 106 in response to the retrieve UE context request 120.
  • the anchor eNB 106 provides the UE RAN context to the eNB2 104 in a retrieve UE context response 202.
  • the eNB2 104 may determine to release the UE 102 to RRCJdle state without light connection.
  • the eNB2 104 transmits the S1 -AP: UE context release request 122 to the MME 108.
  • the MME 108 transmits the S1 -AP: UE context release command 128 to the eNB2 104 and the release access bearer request 124 to the S-GW 1 10.
  • the S-GW 1 10 transmits the release access bearer response 126 to the MME 108.
  • the eNB2 104 Upon receiving the S1 -AP: UE context release command 128, the eNB2 104 transmits the RRC connection release message 132 to the UE 102 and transmits the S1 -AP: UE context release response 134 to the MME 108.
  • the UE RRC connection 136 is released (the UE RAN context is released at both the UE 102 and at the eNB2 104, for example).
  • the S1 - U interface 1 16 that was previously maintained is also released.
  • the UE 102 which was in a light connection mode with a stored UE RAN context, is released in response to a decision made by the new eNB2 104.
  • FIG. 3 is a message diagram that illustrates an embodiment 300 in which the anchor eNB 106 suspends the UE 102 that has moved to another eNB (i.e., the eNB2 104). Similar to FIGs. 1 and 2, the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and the maintained S1 -U interface 1 16.
  • the UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104.
  • the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 may determine to suspend the UE 102. For example, the anchor eNB 106 may determine to suspend the UE 102 since it has moved to another eNB (e.g., the eNB2 104). In response to determining to suspend the UE 102, the anchor eNB 106 may transmit an S1 -AP: UE context suspend request 302 to the MME 108.
  • the anchor eNB 106 may transmit an S1 -AP: UE context suspend request 302 to the MME 108.
  • the MME 108 transmits the release access bearer request 124 to the S-GW 1 10.
  • the S-GW 1 10 transmits the release access bearer response 126 to the MME 108.
  • the MME 108 Upon receiving the release access bearer response 126, the MME 108 transmits an S1 -AP: UE context suspend request 304 to the anchor eNB 106.
  • the anchor eNB 106 transmits a retrieve UE context response with a suspend indication 306 to the eNB2 104.
  • the eNB2 104 transmits an RRC connection release with a suspend indication 308 or a cell update response with a suspend indication 308 to the UE 102.
  • the UE 102 is moved to a suspended mode 310.
  • the UE 102 which began in a lightly connected mode, is moved to the suspended mode 310 (while in RRCJdle state, for example).
  • the UE 102 is suspended by the anchor eNB 106.
  • the UE RAN context is moved from the anchor eNB 106 to the eNB2 104 and the MME 108 is made aware of context suspend req/response by the anchor eNB 106.
  • the retrieve UE context response with the suspend indication 306 should include whether the UE 102 is being kept in light connection or suspended.
  • the retrieve UE context response with the suspend indication (e.g., 306) is sent by the old eNB (e.g., the anchor eNB 106) to transfer the UE RAN context to the new eNB (e.g., the eNB2 104).
  • the retrieve UE context response with the suspend indication 306 is transmitted from the old eNB to the new eNB. Additional functional definitions and content associated with the retrieve UE context response with the suspend indication 306 are provided in Table 1 below.
  • FIG. 4 is a message diagram that illustrates an embodiment 400 in which the UE context suspend is performed by a new eNB (e.g., the eNB2 104).
  • FIG. 4 is similar to FIG. 3 except that the UE context suspend is performed by the new eNB instead of the old eNB.
  • the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
  • the UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104.
  • the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 may provide the UE RAN context to the eNB2 104 in the retrieve UE context response 202.
  • the eNB2 104 determines to suspend the UE RAN context.
  • the eNB2 104 transmits the S1 -AP: UE context suspend request 302 to the MME 108.
  • the MME 108 transmits the release access bearer request 124 to the S-GW 1 10.
  • the S-GW 1 10 transmits the release access bearer response 126 to the MME 108.
  • the release access bearer request 124 and the release access bearer response 126 serve to release the previously maintained S1 -U interface 1 16.
  • the MME 108 Upon receiving the release access bearer response 126, the MME 108 transmits the S1 -AP: UE context suspend request 304 to the eNB2 104.
  • the eNB2 104 transmits an RRC connection release message with a suspend indication 402 or a cell update response with a suspend indication 402.
  • the eNB2 104 transmits a UE context release message 404 to the anchor eNB 106 (indicating that the anchor eNB 106 can delete the UE RAN context, for example).
  • the UE context release message 404 the UE 102 is moved to the suspended mode 310.
  • the UE 102 which began in a lightly connected mode, is moved to the suspended mode 310 (while in RRCJdle state, for example).
  • the UE 102 is suspended by the eNB2 104, which becomes the new anchor.
  • the UE RAN context is transferred to the eNB2 104 (and the anchor eNB 106 deletes the UE RAN context, for example) and the MME 108 needs to be aware of context suspend request/response, and S1 context suspend is performed by the eNB2 104, which also acts as a path switch message. In this case, resume occurs from the eNB2 104 without further UE RAN context fetch necessary. Accordingly, no change to RETRIEVE UE CONTEXT REQ/RESP messages may be necessary.
  • the decision to suspend the UE 102 is made by the new eNB (e.g., the eNB2 104).
  • the UE context release message 404 is sent so that the anchor eNB 106 will not expect any more downlink data to be forwarded to the UE 102 if any is received during this process and can release the corresponding resources.
  • FIG. 5 is a message diagram that illustrates an embodiment 500 in which the UE 102 is kept in light connection with the anchor eNB 106 through a cell update procedure.
  • the UE 102 is kept in light connection and the UE context is kept in the anchor eNB 106.
  • the new eNB e.g., the eNB2 104
  • the anchor eNB 106 needs to be updated to be part of the paging area.
  • This decision is made by the anchor eNB 106 and is provided in a given response. This may be done using new X2 messages or existing RETRIEVE UE CONTEXT REQUEST/RESPONSE messages as shown in the embodiment 500. It is appreciated that in this case, an S1 -AP path switch is not performed (the S1 -U interface 1 16 is maintained between the anchor eNB 106 and the S-GW 1 10, for example).
  • the UE 102 is in light connection mode with the anchor eNB 106.
  • the UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104.
  • the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the RRC Cell Update Request 1 18 with the Resume ID w/resumeMAC-l, and
  • the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 Upon receiving the retrieve UE context request 120, the anchor eNB 106 transmits a retrieve UE context response message 502 to the eNB2 104.
  • the retrieve UE context response message 502 includes a paging area update optimization indication.
  • the eNB2 104 Upon receiving the retrieve UE context response message 502 with the paging area update optimization indication, the eNB2 104 transmits an RRC cell update response with new cell list 504 or RRC connection reconfiguration with new cell list 504 to the UE 102. In response to the message 504, the UE 102 transmits an RRC connection reconfiguration complete message 506. In the embodiment 500, messages 504 and 506 are performed to update the paging area cell list for the UE 102.
  • the eNB2 104 transmits an RRC connection release with light connection indication 508 to the UE 102.
  • the UE 102 is kept (i.e., stays) in light connected mode and the anchor node is not changed 510.
  • the anchor eNB 106 maintains the S1 -U interface 1 16.
  • FIG. 6 is a message diagram that illustrates an embodiment 600 of a cell update procedure in which the UE 102 is kept in light connection with a new anchor eNB (e.g., the eNB2 104) after an S1 path switch.
  • a new anchor eNB e.g., the eNB2 104
  • the UE 102 is kept in light connection and the UE RAN context is moved from the anchor eNB 106 to the eNB2 104, which becomes the new anchor (re-anchoring case wherein the context is relocated upon paging area update message from the UE 102 after moving to a different paging area, for example).
  • the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
  • the UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104.
  • the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 may provide the UE RAN context to the eNB2 104 in a retrieve UE context response 602.
  • the eNB2 104 determines to become the new anchor eNB and to switch the S1 path. In response to determining to becoming the new anchor eNB and to switching the S1 path, the eNB2 104 transmits an RRC cell update response with light connection indication 604 or an RRC connection release with light connection indication 604 to the UE 102. In addition, the eNB2 104 transmits an S1 -AP: path switch request 606 to the MME 108.
  • the MME 108 transmits a modify bearer request 608 to the S-GW 1 10.
  • the S-GW 1 10 transmits a modify bearer response 610 to the MME 108.
  • the modify bearer request 608 and the modify bearer response 610 serve to modify the path of the previously maintained S1 -U interface 1 16 so that the S1 -U interface (not shown) is between the eNB2 104 and the S-GW 1 10 instead of between the anchor eNB 106 and the S-GW 1 10.
  • the MME 108 Upon receiving the modify bearer response 610, transmits an S1 -AP: path switch response 612 to the eNB2 104.
  • the RRC cell update response with light connection indication 604 or the RRC connection release with light connection indication 604 keeps the UE 102 in a lightly connected mode 614.
  • the UE 102 is kept in the lightly connected mode 614 with the eNB2 104 as the new anchor eNB.
  • the eNB2 104 maintains the UE RAN context and maintains the modified S1 -U interface (not shown) for the UE 102.
  • the UE 102 which began in a lightly connected mode, is kept in the lightly connected mode 614 but with the eNB2 104 as a new anchor eNB.
  • the UE RAN context is transferred to the eNB2 104 (and the anchor eNB 106 deletes the UE RAN context, for example) and the S1 context is modified to correspond with the new anchor eNB.
  • FIG. 7 is a message diagram that illustrates an embodiment 700 in which the UE 102 has mobile-originated data to send and is resumed from light connected mode for data transfer.
  • the UE 102 may either be within the paging area or be outside the paging area.
  • the S1 path switch should be done and context should be retrieved to the current eNB so that the UE 102 can send its mobile-originated data.
  • the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
  • the UE 102 transmits an RRC connection resume request 702 to the eNB2 104.
  • the RRC connection resume request 702 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 transmits the retrieve UE context response 202 that includes the UE RAN context to the eNB2 104.
  • the eNB2 104 determines to become the new anchor eNB and to switch the S1 path. In response to determining to becoming the new anchor eNB and to switching the S1 path, the eNB2 104 transmits an RRC connection resume message 704 to the UE 102. In addition, the eNB2 104 transmits the S1 -AP: path switch request 606 to the MME 108.
  • the MME 108 transmits the modify bearer request 608 to the S-GW 1 10.
  • the S-GW 1 10 transmits the modify bearer response 610 to the MME 108.
  • the MME 108 Upon receiving the modify bearer response 610, the MME 108 transmits the S1 -AP: path switch response 612 to the eNB2 104. This process of modifying the path of the previously maintained S1 -U interface 1 16 results in the S1 -U interface being between the eNB2 104 and the S-GW 1 10.
  • the UE 102 in response to the RRC connection resume message 704 transmits an RRC connection resume complete message 706 to the eNB2 104, which establishes the RRC connection (to RRC_Connected state, for example) between the UE 102 and the eNB2 104.
  • the UE 102 in response to the RRC connection resume message 704 transmits an RRC connection resume complete message 706 to the eNB2 104, which establishes the RRC connection (to RRC_Connected state, for example) between the UE 102 and the eNB2 104.
  • the UE 102 may send its mobile- originated data (e.g., uplink (UL) data 708) via the S1 -U interface and may receive data (e.g., downlink (DL) data 710) via the S1 -U interface.
  • UL uplink
  • DL downlink
  • the UE 102 which began in a lightly connected mode, can efficiently (with minimal signaling, for example) resume its UE RAN context and send and/or receive data via the S1 -U interface.
  • FIG. 8 is a message diagram that illustrates an embodiment 800 in which the network (e.g., the S-GW 1 10) has mobile-terminated data for the UE 102 and the UE 102 is resumed from light connected mode for data transfer.
  • the UE 102 may either be within the paging area or be outside the paging area.
  • the S1 path switch should be done and context should be retrieved to the current eNB so that the UE 102 can receive its mobile-terminated data.
  • mobile-terminated access is enabled through X2 paging.
  • the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
  • the S-GW 1 10 transmits downlink data 802 to the anchor eNB 106.
  • the anchor eNB 106 may transmit an X2-AP: paging message 804 to one or more other eNBs (e.g., the eNB2 104).
  • the one or more other eNBs are eNBs that are associated with a paging area.
  • the one or more other eNBs are eNBs have some geographic nexus to the anchor eNB 106 but are outside of a paging area associated with the anchor eNB 106.
  • the eNB2 104 receives the X2-AP paging message 804 from the anchor eNB 106.
  • the X2-AP paging message 804 includes at least a portion of UE RAN context information so that non-anchor eNBs (e.g., the eNB2 104) can page the UE 102 using RRC paging techniques.
  • the eNB2 104 transmits an RRC paging message 806 to its coverage area.
  • the UE 102 transmits an RRC connection resume request 808 to the eNB2 104.
  • the RRC connection resume request 808 may include a Resume ID with a resumeMAC-l, and/or an establishment cause.
  • the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
  • the anchor eNB 106 transmits the retrieve UE context response 202 to the eNB2 104.
  • the retrieve UE context response 202 includes the UE RAN context for the UE 102.
  • the eNB2 104 transmits the RRC connection resume message 704 to the UE 102.
  • the UE 102 transmits the RRC connection resume complete message 706 to the eNB2 104.
  • the anchor eNB 106 transmits data 810 (e.g., forwards data 810) to the eNB2 104 that was received in downlink data 802. Since the eNB2 104 is the new anchor for the UE 102, the S1 path needs to be switched from the anchor eNB 106 to the eNB2 104. Accordingly, the eNB2 104 transmits the S1 -AP: path switch request 606 to the MME 108.
  • data 810 e.g., forwards data 810
  • the eNB2 104 is the new anchor for the UE 102
  • the S1 path needs to be switched from the anchor eNB 106 to the eNB2 104. Accordingly, the eNB2 104 transmits the S1 -AP: path switch request 606 to the MME 108.
  • the MME 108 transmits the modify bearer request 608 to the S-GW 1 10.
  • the S-GW 1 10 transmits the modify bearer response 610 to the MME 108.
  • the MME 108 Upon receiving the modify bearer response 610, the MME 108 transmits the S1 -AP: path switch response 612 to the eNB2 104.
  • This process of modifying the path of the previously maintained S1 -U interface 1 16 results in the S1 -U interface being between the eNB2 104 and the S-GW 1 10.
  • the eNB2 104 may transmit a UE release request 812 to the anchor eNB 106.
  • the UE release request 812 may be a UE context release request that indicates to the anchor eNB 106 that it can release the UE RAN context for the UE 102.
  • the UE 102 may receive data (e.g., downlink (DL) data 710) via the S1 -U interface.
  • the UE 102 may send data (e.g., uplink (UL) data 708, not shown) via the S1 -U interface.
  • DL downlink
  • UL uplink
  • the UE 102 which began in a lightly connected mode, can efficiently (with minimal signaling, for example) resume its UE RAN context and receive mobile-terminated data via the S1 -U interface.
  • the UE context is retrieved from an old eNB (e.g., the anchor eNB 106) and moved to a new eNB (e.g., the eNB2 104).
  • the old eNB transmits a retrieve UE context response (as defined in 3GPP TS 36.423, for example) (e.g., retrieve UE context response 130, 202, 306, 502, 602) to the new eNB.
  • the retrieve UE context response message is sent by the old eNB to transfer the UE context to the new eNB.
  • eDRX related parameters could be shared to the new eNB along with the UE context.
  • the direction of the retrieve UE context response message is from the old eNB to the new eNB. Additional functional definitions and content associated with the retrieve UE context response are provided in Table 2 below.
  • the RAN paging discontinuous reception (DRX) can be passed from one eNB to another while the UE RAN context is retrieved and the UE is moved to the new eNB.
  • the RAN Paging DRX IE contains the value of RAN-based DRX configured by the old eNB.
  • the RAN-based DRX configured by the old eNB is mandatory for all messages.
  • the value s0.02 corresponds to 0.02 seconds
  • s0.04 corresponds to 0.04 seconds and so on.
  • the RAN Paging DRX IE also contains optional eDRX parameters configured by the old eNB if applicable. Additional functional definitions and content associated with the RAN Paging DRX IE are provided in Table 3 below.
  • the extended DRX parameters indicate the offset of the narrowband internet of things (NB-IOT) channel number to the E-UTRA absolute radio frequency channel number (EARFCN). In some cases, the extended DRX parameters are also applicable to X2AP paging message.
  • NB-IOT narrowband internet of things
  • E-UTRA absolute radio frequency channel number E-UTRA absolute radio frequency channel number
  • X2AP paging may be modified to support MME load balancing.
  • a loadbaiancingTAUrequired IE may be included within a paging message so that the UE can perform RRC Resume with corresponding establishment cause and also not use corresponding parameters within the RRC Resume Complete message to perform tracking area update (TAU) (the registered MME should not be provided, for example).
  • TAU tracking area update
  • FIG. 9 is a message diagram that illustrates an embodiment 900 in which a paging message is 906 communicated between a second eNB 904 and a first eNB 902.
  • the paging message 906 may be communicated over the X2 interface via X2- AP.
  • the paging message 906 includes the
  • the first eNB 902 shall perform paging firstly in cells which belong to the recommended cells/eNBs list, and secondly those cells which belong to tracking areas as indicated in the List of TAIs IE in an S1 -AP message from MME.
  • the indication "load balancing TAU required" when set indicates that the UE shall perform TAU. This indication is set because the "anchor eNB" (e.g., the second eNB 904) received an S1 release request for the UE from MME.
  • the indication loadbalancingTAUrequired is set, the MME assumes the UE is ECM_CONNECTED and the S1 is still active.
  • the X2 paging is the only option to inform the UE.
  • FIG. 10 is a flow diagram of a method 1000 for operating in a light connected mode.
  • the method 1000 is performed by a device, such as a user equipment (UE) or the like.
  • the method 1000 may be performed by a processor (e.g., a baseband processor) within the device.
  • a processor e.g., a baseband processor
  • a UE operates in an RRC_Connected state.
  • an RRC message that includes an indication to enter a lightly connected mode is decoded.
  • the lightly connected mode may be referred to as a lightly connected RRC mode.
  • the lightly connected mode is configured. The RRC
  • connection is suspended in the lightly connected mode.
  • the UE transitions to an RRCJdle state while in the lightly connected mode.
  • the operations of the method 1000 may be performed by an application-specific processor, programmable application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like.
  • ASIC programmable application specific integrated circuit
  • FPGA field programmable gate array
  • FIG. 1 1 illustrates an architecture of a system 1 100 of a network in accordance with some embodiments.
  • the system 1 100 is shown to include a user equipment (UE) 1 101 and a UE 1 102.
  • the UEs 1 101 and 1 102 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.
  • PDAs Personal Data Assistants
  • the UEs 1 101 and 1 102 may be examples of the UE 102 discussed previously.
  • the UE 102 discussed above is an example of UEs 1 101 and/or 1 102.
  • any of the UEs 1 101 and 1 102 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
  • MTC mobile communications
  • PLMN public land mobile network
  • Proximity-Based Service ProSe
  • D2D device-to- device
  • 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.
  • the UEs 1 101 and 1 102 may be configured to connect, e.g.,
  • the RAN 1 1 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.
  • UMTS Evolved Universal Mobile Telecommunications System
  • E-UTRAN Evolved Universal Mobile Telecommunications System
  • NG RAN NextGen RAN
  • the UEs 1 101 and 1 102 utilize connections 1 103 and 1 104, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 1 103 and 1 104 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.
  • GSM Global System for Mobile Communications
  • CDMA code-division multiple access
  • PTT Push-to-Talk
  • POC PTT over Cellular
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • 5G fifth generation
  • NR
  • the UEs 1 101 and 1 102 may further directly exchange communication data via a ProSe interface 1 105.
  • the ProSe interface 1 105 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
  • PSDCH Physical Sidelink Broadcast Channel
  • PSBCH Physical Sidelink Broadcast Channel
  • the UE 1 102 is shown to be configured to access an access point (AP) 1 106 via a connection 1 107.
  • the connection 1 107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.1 1 protocol, wherein the AP 1 106 would comprise a wireless fidelity (WiFi®) router.
  • WiFi® wireless fidelity
  • the AP 1 106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).
  • the RAN 1 1 10 can include one or more access nodes that enable the connections 1 103 and 1 104.
  • These access nodes 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).
  • BSs base stations
  • eNBs evolved NodeBs
  • gNB next Generation NodeBs
  • 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 1 1 10 may include one or more RAN nodes for providing macrocells, e.g., a macro RAN node 1 1 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., a low power (LP) RAN node 1 1 12.
  • a macro RAN node 1 1 1 1 may include one or more RAN nodes for providing macrocells, e.g., a macro RAN node 1 1 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., a low power (LP) RAN node 1 1 12.
  • LP low power
  • any of the RAN nodes 1 1 1 1 and 1 1 12 can terminate the air interface protocol and can be the first point of contact for the UEs 1 101 and 1 102.
  • any of the RAN nodes 1 1 1 1 and 1 1 12 can fulfill various logical functions for the RAN 1 1 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.
  • RNC radio network controller
  • the eNB2 104 and the anchor eNB 106 discussed above are examples of RAN nodes 1 1 1 1 and/or 1 1 12.
  • the UEs 1 101 and 1 102 can be configured to communicate using Orthogonal Frequency-Division Multiplexing
  • OFDM Orthogonal Frequency- Division Multiple Access
  • SC-FDMA Single Carrier Frequency Division Multiple Access
  • the OFDM signals can comprise a plurality of orthogonal subcarriers.
  • a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 1 1 1 1 and 1 1 12 to the UEs 1 101 and 1 102, 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.
  • a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation.
  • 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.
  • the physical downlink shared channel may carry user data and higher-layer signaling to the UEs 1 101 and 1 102.
  • 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 1 101 and 1 102 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel.
  • downlink scheduling (assigning control and shared channel resource blocks to the UE 1 102 within a cell) may be performed at any of the RAN nodes 1 1 1 1 and 1 1 12 based on channel quality information fed back from any of the UEs 1 101 and 1 102.
  • the downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 1 101 and 1 102.
  • the PDCCH may use control channel elements (CCEs) to convey the control information.
  • CCEs control channel 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).
  • RAGs resource element groups
  • QPSK Quadrature Phase Shift Keying
  • the PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition.
  • DCI downlink control information
  • 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).
  • Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts.
  • 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.
  • EPCCH enhanced physical downlink control channel
  • ECCEs enhanced the control channel elements
  • each ECCE may correspond to nine sets of four physical resource elements known as enhanced resource element groups (EREGs).
  • EREGs enhanced resource element groups
  • An ECCE may have other numbers of EREGs in some situations.
  • the RAN 1 1 10 is shown to be communicatively coupled to a core network (CN) 1 120— via an S1 interface 1 1 13.
  • the CN 1 120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN.
  • EPC evolved packet core
  • NPC NextGen Packet Core
  • the S1 interface 1 1 13 is split into two parts: the S1 -U interface 1 1 14, which carries traffic data between the RAN nodes 1 1 1 1 and 1 1 12 and a serving gateway (S-GW) 1 122, and an S1 -mobility
  • the CN 1 120 comprises the MMEs 1 121 , the S-GW 1 122, a Packet Data Network (PDN) Gateway (P-GW) 1 123, and a home subscriber server (HSS) 1 124.
  • the MMEs 1 121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN).
  • the MMEs 1 121 may manage mobility aspects in access such as gateway selection and tracking area list management.
  • the HSS 1 124 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions.
  • the CN 1 120 may comprise one or several HSSs 1 124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc.
  • the HSS 1 124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • the MME 108 discussed above is an example of the MMEs 1 121 . In some
  • the S-GW 1 10 discussed above is an example of the S-GW 1 122.
  • the S-GW 1 122 may terminate the S1 interface 1 1 13 towards the RAN 1 1 10, and routes data packets between the RAN 1 1 10 and the CN 1 120.
  • the S-GW 1 122 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.
  • the P-GW 1 123 may terminate an SGi interface toward a PDN.
  • the P-GW 1 123 may route data packets between the CN 1 120 (e.g., an EPC network) and external networks such as a network including the application server 1 130
  • an application server 1 130 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.).
  • the P-GW 1 123 is shown to be communicatively coupled to an application server 1 130 via an IP communications interface 1 125.
  • the application server 1 130 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 1 101 and 1 102 via the CN 1 120.
  • VoIP Voice-over-Internet Protocol
  • the P-GW 1 123 may further be a node for policy enforcement and charging data collection.
  • a Policy and Charging Enforcement Function (PCRF) 1 126 is the policy and charging control element of the CN 1 120.
  • PCRF Policy and Charging Enforcement Function
  • HPLMN Home Public Land Mobile Network
  • IP- CAN Internet Protocol Connectivity Access Network
  • HPLMN Home Public Land Mobile Network
  • V-PCRF Visited PCRF
  • VPLMN Visited Public Land Mobile Network
  • the PCRF 1 126 may be communicatively coupled to the application server 1 130 via the P-GW 1 123.
  • the application server 1 130 may signal the PCRF 1 126 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters.
  • the PCRF 1 126 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 1 130.
  • PCEF Policy and Charging Enforcement Function
  • TFT traffic flow template
  • QCI QoS class of identifier
  • FIG. 12 illustrates example components of a device 1200 in accordance with some embodiments.
  • the device 1200 may include application circuitry 1202, baseband circuitry 1204, Radio Frequency (RF) circuitry 1206, front-end module (FEM) circuitry 1208, one or more antennas 1210, and power management circuitry (PMC) 1212 coupled together at least as shown.
  • the components of the illustrated device 1200 may be included in a UE or a RAN node.
  • the device 1200 may include fewer elements (e.g., a RAN node may not utilize application circuitry 1202, and instead include a
  • processor/controller to process IP data received from an EPC.
  • the device 1200 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface.
  • 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).
  • C-RAN Cloud-RAN
  • processors of application circuitry 1202 may process IP data packets received from an EPC.
  • the baseband circuitry 1204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
  • the baseband circuitry 1204 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1206 and to generate baseband signals for a transmit signal path of the RF circuitry 1206.
  • Baseband processing circuity 1204 may interface with the application circuitry 1202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1206.
  • the baseband circuitry 1204 may include a third generation (3G) baseband processor 1204A, a fourth generation (4G) baseband processor 1204B, a fifth generation (5G) baseband processor 1204C, or other baseband processor(s) 1204D 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 1204 e.g., one or more of baseband processors 1204A-D
  • baseband processors 1204A-D may be included in modules stored in the memory 1204G and executed via a Central Processing Unit (CPU) 1204E.
  • the radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc.
  • modulation/demodulation circuitry of the baseband circuitry 1204 may include Fast- Fourier Transform (FFT), precoding, or constellation mapping/demapping
  • FFT Fast- Fourier Transform
  • precoding precoding
  • constellation mapping/demapping mapping/demapping
  • encoding/decoding circuitry of the baseband circuitry 1204 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality.
  • LDPC Low Density Parity Check
  • the baseband circuitry 1204 may include one or more audio digital signal processor(s) (DSP) 1204F.
  • the audio DSP(s) 1204F 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.
  • some or all of the constituent components of the baseband circuitry 1204 and the application circuitry 1202 may be implemented together such as, for example, on a system on a chip (SOC).
  • SOC system on a chip
  • the baseband circuitry 1204 may provide for communication compatible with one or more radio technologies.
  • the baseband circuitry 1204 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).
  • EUTRAN evolved universal terrestrial radio access network
  • WMAN wireless metropolitan area networks
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • multi-mode baseband circuitry Embodiments in which the baseband circuitry 1204 is configured to support radio communications of more than one wireless protocol.
  • RF circuitry 1206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium.
  • the RF circuitry 1206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.
  • the RF circuitry 1206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1208 and provide baseband signals to the baseband circuitry 1204.
  • RF circuitry 1206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1204 and provide RF output signals to the FEM circuitry 1208 for transmission.
  • the receive signal path of the RF circuitry 1206 may include mixer circuitry 1206A, amplifier circuitry 1206B and filter circuitry 1206C.
  • the transmit signal path of the RF circuitry 1206 may include filter circuitry 1206C and mixer circuitry 1206A.
  • RF circuitry 1206 may also include synthesizer circuitry 1206D for synthesizing a frequency for use by the mixer circuitry 1206A of the receive signal path and the transmit signal path.
  • the mixer circuitry 1206A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1208 based on the synthesized frequency provided by synthesizer circuitry 1206D.
  • the amplifier circuitry 1206B may be configured to amplify the down-converted signals and the filter circuitry 1206C 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 1204 for further processing.
  • the output baseband signals may be zero-frequency baseband signals, although this is not a requirement.
  • the mixer circuitry 1206A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.
  • the mixer circuitry 1206A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1206D to generate RF output signals for the FEM circuitry 1208.
  • the baseband signals may be provided by the baseband circuitry 1204 and may be filtered by the filter circuitry 1206C.
  • the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively.
  • the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection).
  • the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A may be arranged for direct downconversion and direct upconversion, respectively.
  • the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may be configured for super-heterodyne operation.
  • 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.
  • the output baseband signals and the input baseband signals may be digital baseband signals.
  • the RF circuitry 1206 may include analog- to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1204 may include a digital baseband interface to communicate with the RF circuitry 1206.
  • ADC analog- to-digital converter
  • DAC digital-to-analog converter
  • 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.
  • the synthesizer circuitry 1206D may be a
  • synthesizer circuitry 1206D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.
  • the synthesizer circuitry 1206D may be configured to synthesize an output frequency for use by the mixer circuitry 1206A of the RF circuitry 1206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1206D may be a fractional N/N+1 synthesizer.
  • frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement.
  • VCO voltage controlled oscillator
  • Divider control input may be provided by either the baseband circuitry 1204 or the application circuitry 1202 (such as an applications processor) depending on the desired output frequency.
  • a divider control input e.g., N may be
  • Synthesizer circuitry 1206D of the RF circuitry 1206 may include a divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator.
  • the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA).
  • 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.
  • the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump, and a D-type flip-flop.
  • 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.
  • Nd is the number of delay elements in the delay line.
  • the synthesizer circuitry 1206D 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.
  • the output frequency may be a LO frequency (fLO).
  • the RF circuitry 1206 may include an IQ/polar converter.
  • FEM circuitry 1208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1206 for further processing.
  • the FEM circuitry 1208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1206 for transmission by one or more of the one or more antennas 1210.
  • the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1206, solely in the FEM circuitry 1208, or in both the RF circuitry 1206 and the FEM circuitry 1208.
  • the FEM circuitry 1208 may include a TX/RX switch to switch between transmit mode and receive mode operation.
  • the FEM circuitry 1208 may include a receive signal path and a transmit signal path.
  • the receive signal path of the FEM circuitry 1208 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 1206).
  • the transmit signal path of the FEM circuitry 1208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by the RF circuitry 1206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1210).
  • PA power amplifier
  • the PMC 1212 may manage power provided to the baseband circuitry 1204.
  • the PMC 1212 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.
  • the PMC 1212 may often be included when the device 1200 is capable of being powered by a battery, for example, when the device 1200 is included in a UE.
  • the PMC 1212 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.
  • FIG. 12 shows the PMC 1212 coupled only with the baseband circuitry 1204.
  • the PMC 1212 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 1202, the RF circuitry 1206, or the FEM circuitry 1208.
  • the PMC 1212 may control, or otherwise be part of, various power saving mechanisms of the device 1200. For example, if the device 1200 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 1200 may power down for brief intervals of time and thus save power.
  • DRX Discontinuous Reception Mode
  • the device 1200 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 1200 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 1200 may not receive data in this state, and in order to receive data, it transitions back to an RRC_Connected state.
  • 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.
  • Processors of the application circuitry 1202 and processors of the baseband circuitry 1204 may be used to execute elements of one or more instances of a protocol stack.
  • processors of the baseband circuitry 1204 alone or in combination, may be used to execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1202 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g.,
  • Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below.
  • 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.
  • Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.
  • FIG. 13 illustrates example interfaces of baseband circuitry in accordance with some embodiments.
  • the baseband circuitry 1204 of FIG. 12 may comprise processors 1204A-1204E and a memory 1204G utilized by said processors.
  • Each of the processors 1204A-1204E may include a memory interface, 1304A-1304E, respectively, to send/receive data to/from the memory 1204G.
  • the baseband circuitry 1204 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 1312 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1204), an application circuitry interface 1314 (e.g., an interface to send/receive data to/from the application circuitry 1202 of FIG. 12), an RF circuitry interface 1316 (e.g., an interface to send/receive data to/from RF circuitry 1206 of FIG. 12), a wireless hardware connectivity interface 1318 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components,
  • NFC Near Field Communication
  • Bluetooth® components e.g., Bluetooth® Low Energy
  • Wi-Fi® components e.g., Wi-Fi® components
  • power management interface 1320 e.g., an interface to send/receive power or control signals to/from the PMC 1212.
  • FIG. 14 is an illustration of a control plane protocol stack in accordance with some embodiments.
  • a control plane 1400 is shown as a communications protocol stack between the UE 1 101 (or alternatively, the UE 1 102), the RAN node 1 1 1 1 (or alternatively, the RAN node 1 1 12), and the MME 1 121 .
  • a PHY layer 1401 may transmit or receive information used by the MAC layer 1402 over one or more air interfaces.
  • the PHY layer 1401 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as an RRC layer 1405.
  • the PHY layer 1401 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.
  • FEC forward error correction
  • MIMO Multiple Input Multiple Output
  • the MAC layer 1402 may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, de-multiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.
  • An RLC layer 1403 may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM).
  • the RLC layer 1403 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers.
  • the RLC layer 1403 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.
  • a PDCP layer 1404 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).
  • security operations e.g., ciphering, deciphering, integrity protection, integrity verification, etc.
  • the main services and functions of the RRC layer 1405 may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting.
  • SIBs may comprise one or more information elements (lEs), which may each comprise individual data fields or data structures.
  • the UE 1 101 and the RAN node 1 1 1 1 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer 1401 , the MAC layer 1402, the RLC layer 1403, the PDCP layer 1404, and the RRC layer 1405.
  • a Uu interface e.g., an LTE-Uu interface
  • the non-access stratum (NAS) protocols 1406 form the highest stratum of the control plane between the UE 1 101 and the MME 1 121 .
  • the NAS protocols 1406 support the mobility of the UE 1 101 and the session management procedures to establish and maintain IP connectivity between the UE 1 101 and the P-GW 1 123.
  • the S1 Application Protocol (S1 -AP) layer 1415 may support the functions of the S1 interface and comprise Elementary Procedures (EPs).
  • An EP is a unit of interaction between the RAN node 1 1 1 1 and the CN 1 120.
  • the S1 -AP layer services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transfer.
  • E-RAB E-UTRAN Radio Access Bearer
  • RIM RAN Information Management
  • the Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as the stream control transmission protocol/internet protocol (SCTP/IP) layer) 1414 may ensure reliable delivery of signaling messages between the RAN node 1 1 1 1 and the MME 1 121 based, in part, on the IP protocol, supported by an IP layer 1413.
  • An L2 layer 1412 and an L1 layer 141 1 may refer to communication links (e.g., wired or wireless) used by the RAN node and the MME to exchange information.
  • the RAN node 1 1 1 1 and the MME 1 121 may utilize an S1 -MME interface to exchange control plane data via a protocol stack comprising the L1 layer 141 1 , the L2 layer 1412, the IP layer 1413, the SCTP layer 1414, and the S1 -AP layer 1415.
  • FIG. 15 is an illustration of a user plane protocol stack in accordance with some embodiments.
  • a user plane 1500 is shown as a
  • the user plane 1500 may utilize at least some of the same protocol layers as the control plane 1400.
  • the UE 1 101 and the RAN node 1 1 1 1 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange user plane data via a protocol stack comprising the PHY layer 1401 , the MAC layer 1402, the RLC layer 1403, and the PDCP layer 1404.
  • a Uu interface e.g., an LTE-Uu interface
  • the General Packet Radio Service (GPRS) Tunneling Protocol for the user plane (GTP-U) layer 1504 may be used for carrying user data within the GPRS core network and between the radio access network and the core network.
  • the user data transported can be packets in any of IPv4, IPv6, or PPP formats, for example.
  • the UDP and IP security (UDP/IP) layer 1503 may provide checksums for data integrity, port numbers for addressing different functions at the source and
  • the RAN node 1 1 1 1 and the S-GW 1 122 may utilize an S1 -U interface to exchange user plane data via a protocol stack comprising the L1 layer 141 1 , the L2 layer 1412, the UDP/IP layer 1503, and the GTP-U layer 1504.
  • the S-GW 1 122 and the P-GW 1 123 may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising the L1 layer 141 1 , the L2 layer 1412, the UDP/IP layer 1503, and the GTP-U layer 1504.
  • NAS protocols support the mobility of the UE 1 101 and the session management procedures to establish and maintain IP connectivity between the UE 1 101 and the P-GW 1 123.
  • FIG. 16 illustrates components of a core network in accordance with some embodiments.
  • the components of the CN 1 120 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non- transitory machine-readable storage medium).
  • NFV Network Functions Virtualization
  • a logical instantiation of the CN 1 120 may be referred to as a network slice 1601 .
  • a logical instantiation of a portion of the CN 1 120 may be referred to as a network sub-slice 1602 (e.g., the network sub-slice 1602 is shown to include the PGW 1 123 and the PCRF 1 126).
  • NFV architectures and infrastructures may be used to virtualize one or more network functions, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches.
  • NFV systems can be used to execute virtual or reconfigurable implementations of one or more EPC
  • FIG. 17 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.
  • FIG. 17 shows a diagrammatic representation of hardware resources 1700 including one or more processors (or processor cores) 1710, one or more memory/storage devices 1720, and one or more communication resources 1730, each of which may be communicatively coupled via a bus 1740.
  • node virtualization e.g., NFV
  • a hypervisor 1702 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1700.
  • the processors 1710 may include, for example, a processor 1712 and a processor 1714.
  • CPU central processing unit
  • RISC reduced instruction set computing
  • CISC complex instruction set computing
  • GPU graphics processing unit
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • RFIC radio-frequency integrated circuit
  • the memory/storage devices 1720 may include main memory, disk storage, or any suitable combination thereof.
  • the memory/storage devices 1720 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 erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Flash memory solid-state storage, etc.
  • the communication resources 1730 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1704 or one or more databases 1706 via a network 1708.
  • the communication resources 1730 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular
  • NFC components NFC components
  • Bluetooth® components e.g., Bluetooth® Low Energy
  • Wi-Fi® components Wi-Fi components
  • Instructions 1750 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1710 to perform any one or more of the methodologies discussed herein.
  • the instructions 1750 may reside, completely or partially, within at least one of the processors 1710 (e.g., within the processor's cache memory), the memory/storage devices 1720, or any suitable combination thereof.
  • any portion of the instructions 1750 may be transferred to the hardware resources 1700 from any combination of the peripheral devices 1704 or the databases 1706. Accordingly, the memory of processors 1710, the memory/storage devices 1720, the peripheral devices 1704, and the databases 1706 are examples of computer-readable and machine-readable media.
  • Example 1 is an apparatus for a user equipment (UE).
  • the apparatus includes a memory and one or more baseband processors.
  • the memory is to store access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN).
  • the one or more baseband processors is/are to: operate in an RRC connected state, decode an RRC message that includes an indication to enter a lightly connected RRC mode, store the AS context information associated with the RRC connection in response to the indication, and transition to an RRC idle state while in the lightly connected RRC mode, wherein the RRC connection is suspended in the lightly connected RRC mode.
  • Example 2 is the apparatus of Example 1 , where the RRC message is an RRC connection release message, and where the RRC connection release message includes an RRC connection release information element (IE).
  • IE RRC connection release information element
  • Example 3 is the apparatus of Example 2 or Example 1 , wherein the indication comprises an inclusion of an rrcLightConnectionlndication-r14 field in the RRC connection release IE.
  • Example 4 is the apparatus of Example 2 or Example 3, where the RRC connection release IE includes a release cause field, wherein the indication comprises an inclusion of an rrcLightlyConnected indication in the release cause field.
  • Example 5 is the apparatus of Example 1 or any of Examples 2-4, where the RRC message comprises an RRC connection reconfiguration message.
  • Example 6 is the apparatus of Example 5, where the RRC connection reconfiguration message includes an OtherConfig information element (IE), where the indication comprises an inclusion of a NghtConnectionConfig-r14 field in the OtherConfig IE.
  • Example 7 is the apparatus of Example 1 or any of Examples 2-6, where the one or more baseband processors are further to decode a resume identity provided by the E-UTRAN and store the resume identity.
  • IE OtherConfig information element
  • Example 8 is the apparatus of Example 7, where the one or more baseband processors are further to generate a request to resume the RRC
  • connection wherein the request includes the stored resume identity.
  • Example 9 is the apparatus of Example 7 or Example 8, where the one or more baseband processors are further to generate an RRC cell update request message, where the RRC cell update request message includes the resume identity.
  • Example 10 is the apparatus of Example 9, where the RRC message comprises an RRC cell update confirm message.
  • Example 1 1 is the apparatus of Example 10, where the indication comprises an inclusion of an rrcLightlyConnected-v14 indication in a cell update release cause field of the RRC cell update confirm message.
  • Example 12 is the apparatus of Example 1 or any of Examples 2-1 1 , where the one or more baseband processors are further to suspend all signaling radio bearers (SRBs) and data radio bearers (DRBs).
  • SRBs signaling radio bearers
  • DRBs data radio bearers
  • Example 13 is the apparatus of Example 1 or any of Example 2-12, where the one or more baseband processors are further to indicate that the UE is in the lightly connected RRC mode to an upper layer.
  • Example 14 is an apparatus for a user equipment (UE).
  • the apparatus includes a memory and one or more baseband processors.
  • the memory is for storing a resume identity and for storing access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN).
  • the one or more baseband processors are to operate in an RRC idle state while in a lightly connected RRC mode, generate an RRC connection resume request message, the RRC connection resume request including the resume identity, decode an RRC connection reject message that includes an indication that the UE should remain in the lightly connected RRC mode, maintain the stored resume identity and stored AS context information in response to the indication, and operate in the RRC idle state while in the lightly connected RRC mode.
  • Example 15 is the apparatus of Example 14, where the indication that the UE should remain in the lightly connected RRC mode is included in an RRC connection reject information element (IE).
  • IE RRC connection reject information element
  • Example 16 is the apparatus of Example 15 or Example 16, where the indication comprises an rrcLightConnectionlndication-r14 field in the RRC connection reject IE.
  • Example 17 is an apparatus for an evolved Node B (eNB.
  • the apparatus includes a memory and one or more processors.
  • the memory is for storing a resume identity associated with a user equipment (UE) and for storing access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN).
  • UE user equipment
  • AS access stratum
  • RRC radio resource control
  • the one or more processors are to establish an S1 -U interface with a serving gateway for the UE in an RRC connected state, generate an RRC message for the UE to transition to an RRC idle state, where the RRC message includes an indication for the UE to enter a lightly connected RRC mode, store the resume identity associated with the UE and the AS context information associated with the RRC connection in response to the indication, and maintain the S1 -U interface with the serving gateway for the UE while the UE is in the lightly connected RRC mode.
  • Example 18 is the apparatus of Example 17, where the one or more processors are further to generate a broadcast signal, wherein the broadcast signal includes a RANPagingArealnfo information element (IE).
  • IE RANPagingArealnfo information element
  • Example 19 is the apparatus of Example 18, where the
  • RANPagingArealnfo IE includes at least one of a trackAreaAllowed-r14 IE and a RANPagingAreaCode IE.
  • Example 20 is the apparatus of Example 19, where the
  • RANPagingArealnfo IE includes a RANpagingAreaCode field, wherein the
  • RANpagingAreaCode field identifies a RAN-based paging area within a public land mobile network (PLMN) tracking area.
  • PLMN public land mobile network
  • Example 21 is the apparatus of Example 17 or any of Examples 18-20, where the RRC message is an RRC connection release message, an RRC connection reconfiguration message, or an RRC cell update confirm message.
  • the RRC message is an RRC connection release message, an RRC connection reconfiguration message, or an RRC cell update confirm message.
  • Example 22 is a User Equipment (UE) configured to operate in a 3GPP network in accordance with stored UE RAN context while being suspended with light connection with an Evolved Node-B (eNB) or NR Base station (gNB or other).
  • the UE includes hardware processing circuitry configured to: suspend/hold its UE RAN context information and other necessary connection configuration for re-use during a next connection.
  • Example 23 is an evolved Node B (eNB) or a similar network node (e.g., NR BS, gNB) which can support communication using suspend and resume signaling or other dedicated signaling through storing of the UE's contexts and other necessary connection configuration information.
  • eNB evolved Node B
  • gNB similar network node
  • Example 24 is the UE of Example 22 or any of the other examples described herein where the RRC connection release cause is added as a new indication within an RRC CONNECTION RELEASE message.
  • Example 25 is the eNB of Example 23 or any of the other examples described herein where the connection release cause is added as a new IE or indication within an RRC CELL UPDATE CONFIRM message in response to an RRC CELL UPDATE REQUEST message from Example 22 to indicate mobility out of a configured RAN paging/notification area.
  • Example 26 is the eNB of Example 23 or any of the other examples described herein where the RAN paging DRX information configured for the UE of Example 22 is provided as part of a RETRIEVE UE CONTEXT RESPONSE message.
  • Example 27 is the eNB of Example 23 or any of the other examples described herein where at least a UE suspend indication or UE release indication is provided as part of a RETRIEVE UE CONTEXT RESPONSE message.
  • Example 28 is the eNB of Example 23 or any of the other examples described herein where a UE-specific list of RAN paging area cells is provided as part of a RETRIEVE UE CONTEXT RESPONSE message to aid in updating the list during re-anchoring of the UE of Example 22.
  • Example 29 is the eNB of Example 23 or any of the other examples described herein where an indication to perform tracking area update (TAU) due to load balancing in core network is sent to the UE of Example 22 through an X2AP paging message.
  • TAU tracking area update
  • Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, a non-transitory computer-readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques.
  • the computing device may include a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device.
  • the volatile and non-volatile memory and/or storage elements may be a RAM, an EPROM, a flash drive, an optical drive, a magnetic hard drive, or another medium for storing electronic data.
  • the eNodeB (or other base station) and UE (or other mobile station) may also include a transceiver component, a counter component, a processing component, and/or a clock component or timer component.
  • One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high-level procedural or an object-oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or an interpreted language, and combined with hardware implementations.
  • API application programming interface
  • a component may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
  • VLSI very large scale integration
  • a component may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.
  • Components may also be implemented in software for execution by various types of processors.
  • An identified component of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, a procedure, or a function.
  • executables of an identified component need not be physically located together, but may comprise disparate instructions stored in different locations that, when joined logically together, comprise the component and achieve the stated purpose for the component.
  • a component of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.
  • the components may be embodied in any suitable form and organized within any suitable type of data structure.
  • the operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
  • the components may be passive or active, including agents operable to perform desired functions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Apparatuses for operating in a lightly connected mode are described. Operating in a lightly connected mode includes initiating the lightly connected mode as well as exciting the lightly connected mode. An apparatus for a user equipment includes a memory and one or more baseband processors. The memory stores access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN). The one or more baseband processors operate in an RRC_Connected state, decode an RRC message that includes an indication to enter a lightly connected RRC mode, configure the lightly connected RRC mode, wherein the RRC connection is suspended in the lightly connected RRC mode, and transition to an RRC_ldle state while in the lightly connected RRC mode.

Description

APPARATUSES FOR CONFIGURATION OF A LIGHT CONNECTION
Related Applications
[0001] This application is a non-provisional of U.S. Provisional Patent Application No. 62/399,969, filed September 26, 2016, which is incorporated by reference herein in its entirety.
Technical Field
[0002] The present disclosure relates to supporting light connection. In particular, the present disclosure relates to changes in RRC to support light connection, defining a RAN-based paging area or notification area in RRC, and defining changes to the X2AP specification for supporting light connection.
Background
[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 3rd
Generation Partnership Project (3GPP) long term evolution (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 radio access networks (RANs) in LTE systems, the base station can include a RAN Node such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) and/or Radio Network Controller (RNC) in an E-UTRAN, which communicate with a wireless communication device, known as user equipment (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 104 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).
[0006] LTE defines two radio resource control (RRC) operating states for a UE. These are RRC_Connected (i.e., RRC_CONNECTED), for when there is data to exchange between the UE and the E-UTRAN, and RRCJdle (i.e., RRCJDLE), for when there is no data to exchange between the UE and the E-UTRAN. When the UE is in RRCJdle and there is data to be exchanged between the UE and the network, the UE has to go into RRC_Connected state. To go into RRC_Connected, a UE RAN context must be established in the UE and in the eNB. This normally involves a lot of signaling both in terms of number of messages and number of bytes that need to be exchanged. There is a need to reduce the signaling load associated RRCJdle to RRC_Connected transitions.
Brief Description of the Drawings
[0007] FIG. 1 is a message diagram that illustrates an embodiment in which a UE is released based on a decision made by the anchor eNB.
[0008] FIG. 2 is a message diagram that illustrates an embodiment in which a UE is released based on a decision made by the eNB2.
[0009] FIG. 3 is a message diagram that illustrates an embodiment in which an anchor eNB suspends a UE that has moved to another eNB (i.e., eNB2). [0010] FIG. 4 is a message diagram that illustrates an embodiment in which the UE context suspend is performed by a new eNB (e.g., eNB2).
[0011] FIG. 5 is a message diagram that illustrates an embodiment of a cell update procedure in which the UE is kept in light connection with the anchor eNB.
[0012] FIG. 6 is a message diagram that illustrates an embodiment of a cell update procedure in which the UE is kept in light connection with a new anchor eNB (e.g., eNB2) after an S1 path switch.
[0013] FIG. 7 is a message diagram that illustrates an embodiment in which the UE has mobile-originated data to send and is resumed from light connected mode for data transfer.
[0014] FIG. 8 is a message diagram that illustrates an embodiment in which the network (e.g., S-GW) has mobile-terminated data for the UE and the UE is resumed from light connected mode for data transfer.
[0015] FIG. 9 is a message diagram that illustrates an embodiment in which a paging message is communicated between a second eNB and a first eNB.
[0016] FIG. 10 is a flow diagram of a method for operating in a light connected mode.
[0017] FIG. 1 1 illustrates an architecture of a system of a network in accordance with some embodiments.
[0018] FIG. 12 illustrates example components of a device in accordance with some embodiments.
[0019] FIG. 13 illustrates example interfaces of baseband circuitry in accordance with some embodiments.
[0020] FIG. 14 is an illustration of a control plane protocol stack in accordance with some embodiments.
[0021] FIG. 15 is an illustration of a user plane protocol stack in accordance with some embodiments.
[0022] FIG. 16 illustrates components of a core network in accordance with some embodiments.
[0023] FIG. 17 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 Preferred Embodiments
[0024] A detailed description of systems and methods consistent with
embodiments of the present disclosure is provided below. While several
embodiments are described, it should be understood that the disclosure is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed herein, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the disclosure.
[0025] Techniques, apparatus, and methods for enabling a light connection between a UE and an E-UTRAN are disclosed. It is appreciated that the techniques, apparatus, and methods discussed herein can be viewed from both the perspective of the UE and the perspective of the E-UTRAN (e.g., eNB). Although the operations of entering light connection, paging in light connection, and exiting light connection are described individually, it is understood that these operations are related and may happen in various combinations (in various sequences, depending on the particular scenario, for example).
[0026] In some embodiments, a UE has a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN) and operates in an RRC_Connected state. While in the RRC_Connected state, the UE decodes an RRC message that includes an indication to enter a lightly connected RRC mode. In response to the indication, the UE configures the lightly connected RRC mode. In the lightly connected RRC mode, the RRC connection is suspended (the access stratus (AS) context information associated with the RRC connection is saved, for example). In some embodiments, the lightly connected RRC mode is a substate within the RRC_Connected state. In other embodiments, the lightly connected RRC mode is a substate within the RRCJdle state. In yet other embodiments, the lightly connected RRC mode is its own RRC state. In one example, the lightly connected RRC mode mode is a substate in the RRCJdle state and the UE transitions to the RRCJdle state while in the lightly connected RRC mode (transitions to the lightly connected RRC mode substate within the RRCJdle state, for example). [0027] In some embodiments, a UE operates in an RRC state (e.g., a lightly connected RRC mode in the RRCJdle state or a lightly connected RRC mode in the RRC_Connected state) but maintains a light connection with an E-UTRAN. The UE generates an RRC connection resume request message. The RRC connection resume request includes a resume identity. The UE decodes an RRC connection reject message that includes an indication that the UE should remain in the lightly connected RRC mode. In response to the indication, the UE maintains the stored resume identity and stored AS context information. The UE operates in the RRC state while in the lightly connected RRC mode.
[0028] In some embodiments, an eNB establishes an S1 -U interface with a serving gateway for a user equipment (UE) in an RRC_Connected state. The eNB generates an RRC message for the UE to transition to an RRC state in a lighly connected RRC mode (transition to a lightly connected substate in the
RRC_Connected state or transition to a lightly connected substate in the RRCJdle substate, for example). The RRC message includes an indication for the UE to enter a lightly connected RRC mode. The eNB maintains the S1 -U interface with the serving gateway for the UE while the UE is in the lightly connected RRC mode.
[0029] 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 3rd
Generation Partnership Project (3GPP) long term evolution (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, which is commonly known to industry groups as Wi-Fi. In 3GPP radio access networks (RANs) in LTE systems, the base station can include Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and/or Radio Network Controllers (RNCs) in an E-UTRAN, which communicate with a wireless communication device, known as user equipment (UE).
[0030] The proposed solution provides advantages, which include supporting an RRC light connection mechanism by which the S1 signaling is kept while the UE is released into lightly connected mode. The signaling to change to active mode is highly reduced in this manner compared to legacy idle (e.g., RRCJdle state) to active mode (e.g., RRC_Connected state) transition. [0031] It is noted that a proposed solution is being considered as part of the 5G control plane where it is being discussed as a new state in RRC (instead of being a separate mode/state (e.g. , substate within either RRC_Connected or RRCJdle) as it is proposed herein). The new state in RRC would be similar to lightly connected state in LTE so that a UE could move seamlessly between new radio (NR) (e.g. , 5G) and LTE in this state. In some embodiments, the paging area could include cells belonging to both NR and LTE.
[0032] As discussed herein, the proposed solution includes specification (e.g. , 3GPP TS 36.331 , 3GPP TS 36.423) changes related to RRC and X2AP for supporting a light connection mechanism. For example, the proposed solution defines novel specification impacts in RRC to support light connection such as capability definition and connection release/reject indications, defines RAN-based Paging area or notification area in RRC (broadcast and dedicated signaling), and defines changes to X2AP specification for supporting light connection mode and different options when there is mobility across paging/notification areas. These changes are discussed in further detail below.
[0033] In LTE, a UE can be in either RRC_Connected or RRCJdle state. In RRC_Connected state, the UE and the eNB have a UE RAN context that stores the current RAN configuration for the UE that is used for communication between the UE and the network. When the UE has no data to send, it can be moved to the
RRCJdle state where the UE RAN context is released. In this state, the UE cannot communicate with the network.
[0034] When the UE is in the RRCJdle state and there is data to be exchanged between the UE and network, it has to go into connected state. During this process, the UE RAN context in the eNB and UE is established. This normally involves a lot of signaling both in terms of number of messages and number of bytes that need to be exchanged.
[0035] 3GPP standards have developed a method for signaling load reduction during idle active transitions. This involves storing the last used UE RAN context in the eNB and UE even when the UE is RRCJdle. Then when the UE goes into RRC_Connected, it just needs to revive the stored context in the eNB and the UE; this process is called resume in current LTE. This resumption of the stored context only involves a couple of signaling messages and thereby saves a lot of signaling messages and bytes. The UE is considered Suspended when the UE is in RRCJdle state but has stored UE RAN context.
[0036] It is understood that typically while the UE is in RRCJdle state, the RAN node (e.g., eNB) does not have the UE's RAN context. Therefore, the UE is paged through the MME using an S1 -AP paging message.
[0037] However, while the UE is suspended, the RAN node retains the UE RAN context. Hence, the UE can be paged by the RAN node itself. This can be called a RAN-based paging mechanism. For this, the interface between RAN nodes needs to be present so that the serving or anchor RAN node can page another RAN node to determine where the UE may have moved. In LTE, this interface between RAN nodes is called the X2 interface (it could be another interface in 5G/NR, for example).
[0038] The interface between an eNB and the MME is called an S1 -MME interface and is used for signaling between the eNB and the MME. The interface between an eNB and the S-GW is called the S1 -U interface and is used for signaling between the eNB and the S-GW. Typically, this interface is torn down when the UE is idle (e.g., in RRCJdle state) or suspended.
[0039] In light connection (e.g., Rel-14 light connection), this S1 (e.g., S1 -U) is kept active when the UE is released into light connection. Some of the necessary specification impacts due to this change are described in the proposed solutions below.
[0040] In some embodiments, the standard (e.g., 3GPP TS 36.331 ) may be updated as set forth in the following pseudocode:
5.3 Connection control
5.3.1 Introduction
5.3.1 .1 RRC connection control <TEXT OMITTED>
The suspension of the RRC connection is initiated by E-UTRAN. When the RRC connection is suspended, the UE stores the UE AS context and the resumeldentity, and transitions to RRCJDLE state. The RRC message to suspend the RRC connection is integrity protected and ciphered. Suspension can only be performed when at least 1 DRB is successfully established. The suspend procedure is also used to enter lightly connected RRC mode. The RRC connection reconfiguration can also be used to enter and/or configure lightly connected RRC mode if necessary.
The resumption of a suspended RRC connection is initiated by upper layers when the UE has a stored UE AS context, RRC connection resume is permitted by E- UTRAN, and the UE needs to transit from RRCJDLE state to RRC_CONNECTED state. When the RRC connection is resumed, RRC configures the UE according to the RRC connection resume procedure based on the stored UE AS context and any RRC configuration received from E-UTRAN. The RRC connection resume
procedure re-activates security and re-establishes SRB(s) and DRB(s). The request to resume the RRC connection includes the resumeldentity. The request is not ciphered, but protected with a message authentication code.
In response to a request to resume the RRC connection, E-UTRAN may resume the suspended RRC connection, reject the request to resume and instruct the UE to either keep or discard the stored context, or setup a new RRC connection.
The resumption procedure of a suspended RRC connection is also used to resume a lightly connected RRC.
[0041] In some embodiments, the standard (e.g., 3GPP TS 36.331 ) may be updated as set forth in the following pseudocode:
5.3.8.2 Initiation
E-UTRAN initiates the RRC connection release procedure to a UE in
RRC_CONNECTED.
5.3.8.3 Reception of the RRCConnectionRelease by the UE <TEXT OMITTED>
1 >else:
2>if the extendedWaitTime is present; and
2>if the UE supports delay tolerant access or the UE is a NB-loT UE:
3>forward the extendedWaitTime to upper layers; 2>if the releaseCause received in the RRCConnectionRelease message indicates rrc-Suspend:
3>perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'RRC suspension';
2>if the releaseCause received in the RRCConnectionRelease message indicates rrc-LightlyConnected:
3>perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'RRC light connection';
2>else:
3>perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'other';
[0042] Additionally or alternatively, in some embodiments, the above standard may be updated as set forth in the following pseudocode:
5.3.8.3 Reception of the RRCConnectionRelease by the UE
<TEXT OMITTED> 1 >else:
2>if the extendedWaitTime is present; and
2>if the UE supports delay tolerant access or the UE is a NB-loT UE:
3>forward the extendedWaitTime to upper layers;
2>if the releaseCause received in the RRCConnectionRelease message indicates rrc-Suspend:
3>if rrc-LightlyConnected is included
4>perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'RRC light connection';
3> else
4>perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'RRC suspension';
2>else:
3>perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'other';
[0043] In some embodiments, the standard (e.g., 3GPP TS 36.331 ) may be updated as set forth in the following pseudocode: 5.3.12 UE actions upon leaving RRC_CONNECTED
Upon leaving RRC_CONNECTED, the UE shall:
1 > reset MAC;
1 > stop all timers that are running except T320, T325 and T330; <TEXT OMITTED>
1 >if leaving RRC_CONNECTED was triggered by entering lightly connected RRC:
2>store the UE AS Context including the current RRC configuration, the current security context, the PDCP state including ROHC state, C-RNTI used in the source PCell, the cellldentity and the physical cell identity of the source PCell;
2>store the following information provided by E-UTRAN:
3>the resumeldentity;
2>suspend all SRB(s) and DRB(s);
2> indicate the RRC light connection to upper layers;
1 > else:
2>release all radio resources, including release of the RLC entity, the MAC
configuration and the associated PDCP entity for all established RBs;
2> indicate the release of the RRC connection to upper layers together with the release cause;
[0044] In some embodiments, one or more of the RRC messages that are defined in the standard (e.g., 3GPP TS 36.331 ) may be updated. For example, the RRC connection reject message may be updated as set forth in the following Abstract Syntax Notation One (ASN1 ) code:
RRCConnectionReject message
- AS N1 START
RRCConnectionReject ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE { rrcConnectionReject-r8
RRCConnectionReject-r8-IEs,
spare3 NULL, spare2 NULL, sparel NULL
}, criticalExtensionsFuture SEQUENCE {}
}
RRCConnectionReject-r8-IEs :: = SEQUENCE {
waitTime INTEGER (1..16), nonCriticalExtension RRCConnectionReject-v8aO- lEs OPTIONAL
}
RRCConnectionReject-v8aO-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING
OPTIONAL,
nonCriticalExtension RRCConnectionReject-v1020-
IEs OPTIONAL
RRCConnectionReject-v1020-IEs ::= SEQUENCE {
extendedWaitTime-r10 INTEGER (1..1800)
OPTIONAL, Need ON
nonCriticalExtension RRCConnectionReject-v1 130- lEs OPTIONAL
}
RRCConnectionReject-v1 130-IEs :: = SEQUENCE {
deprioritisationReq-r1 1 SEQUENCE {
deprioritisationType-r1 1 ENUMERATED {frequency, e- utra},
deprioritisationTimer-r1 1 ENUMERATED {min5, min10, min15, min30}
}
OPTIONAL, - Need ON nonCriticalExtension RRCConnectionReject-v1320- lEs OPTIONAL
OPTIONAL
}
RRCConnectionReject-v1320-IEs ::= SEQUENCE {
rrcSuspendlndication-r13 ENUMERATED {true}
OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
RRCConnectionReject-v14xy-IEs ::= SEQUENCE {
rrcLightConnectionlndication-r14 ENUMERATED {true}
OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL }
- ASN1 STOP
[0045] As shown, the RRCConnectionReject message includes an
RRCConnectionReject-v14xy-IE (information element). The field descriptions for some of the fields in the RRCConnectionReject message including the
RRCConnectionReject-v14xy-IE are provided below.
[0046] The deprioritisationReq field indicates whether the current frequency or RAT is to be de-prioritized. The UE shall be able to store a deprioritisation request for up to 8 frequencies (applicable when receiving another frequency-specific deprioritisation request before T325 expiry).
[0047] The deprioritisationTimerf e\d indicates the period for which either the current carrier frequency or E-UTRA is deprioritised. Value minN corresponds to N minutes.
[0048] The extendedWaitTime field is a value in seconds for the wait time for Delay Tolerant access requests.
[0049] The waitTime field is a Wait time value in seconds.
[0050] The rrcSuspendlndication field, if present, indicates that the UE should remain suspended and not release its stored context.
[0051] The rrcLightConnectionlndication field, if present, indicates that the UE should remain lightly connected and not release its stored context.
[0052] In another example, the RRC connection release message may be updated as set forth in the following ASN1 code:
RRCConnectionRelease message
- AS N1 START
RRCConnectionRelease ::= SEQUENCE {
rrc-Transaction Identifier RRC-Transaction Identifier, criticalExtensions CHOICE {
c1 CHOICE { rrcConnectionRelease-r8
RRCConnectionRelease-r8-IEs,
spare3 NULL, spare2 NULL, sparel NULL
},
criticalExtensionsFuture SEQUENCE {}
} }
RRCConnectionRelease-r8-IEs ::= SEQUENCE {
releaseCause ReleaseCause, redirectedCarrierlnfo RedirectedCarrierlnfo
OPTIONAL, - Need ON
idleModeMobilityControllnfo IdleModeMobilityControllnfo
OPTIONAL, - Need OP
nonCriticalExtension RRCConnectionRelease- v890-IEs OPTIONAL
}
RRCConnectionRelease-v890-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING (CONTAINING
RRCConnectionRelease-v9eO-IEs) OPTIONAL,
nonCriticalExtension RRCConnectionRelease- v920-IEs OPTIONAL
- Late non critical extensions
RRCConnectionRelease-v9eO-IEs ::= SEQUENCE {
redirectedCarrierlnfo-v9eO RedirectedCarrierlnfo-v9eO
OPTIONAL, - Cond NoRedirect-r8
idleModeMobilityControllnfo-v9e0 ldleModeMobilityControllnfo-v9e0
OPTIONAL, - Cond IdlelnfoEUTRA
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
- Regular non critical extensions
RRCConnectionRelease-v920-IEs ::= SEQUENCE {
celllnfoList-r9 CHOICE {
geran-r9 CelllnfoListGERAN-r9, utra-FDD-r9 CelllnfoListUTRA-FDD- r9,
utra-TDD-r9 CelllnfoListUTRA-TDD- r9, utra-TDD-r10 CelllnfoListUTRA-TDD-r10
}
OPTIONAL, - Cond Redirection
nonCriticalExtension RRCConnectionRelease-v1020-IEs
OPTIONAL
}
RRCConnectionRelease-v1020-IEs ::= SEQUENCE {
extendedWaitTime-r10 INTEGER (1..1800)
OPTIONAL, - Need ON
nonCriticalExtension RRCConnectionRelease-v1320-IEs
OPTIONAL }
RRCConnectionRelease-v1320-IEs ::= SEQUENCE {
resumeldentity-r13 Resumeldentity-r13
OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
RRCConnectionRelease-v1400-IEs ::= SEQUENCE {
rrcLightConnectionlndication-r14 ENUMERATED {true}
OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
ReleaseCause ::= ENUMERATED
{loadBalancingTAUrequired,
other, cs-
FallbackHighPriority-v1020, rrcSuspend-v1320}
[0053] Additionally or alternatively, in another example, the RRC connection release message may be updated as set forth in the following ASN1 code:
RRCConnectionRelease message
- AS N1 START
RRCConnectionRelease ::= SEQUENCE {
rrc-Transaction Identifier RRC-Transaction Identifier, criticalExtensions CHOICE {
c1 CHOICE { rrcConnectionRelease-r8
RRCConnectionRelease-r8-IEs,
spare3 NULL, spare2 NULL, sparel NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}
RRCConnectionRelease-r8-IEs ::= SEQUENCE {
releaseCause ReleaseCause, redirectedCarrierlnfo RedirectedCarrierlnfo
OPTIONAL, - Need ON
idleModeMobilityControllnfo IdleModeMobilityControllnfo
OPTIONAL, - Need OP
nonCriticalExtension RRCConnectionRelease- v890-IEs OPTIONAL
} RRCConnectionRelease-v890-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING (CONTAINING
RRCConnectionRelease-v9eO-IEs) OPTIONAL,
nonCriticalExtension RRCConnectionRelease- v920-IEs OPTIONAL
}
- Late non critical extensions
RRCConnectionRelease-v9eO-IEs ::= SEQUENCE {
redirectedCarrierlnfo-v9eO RedirectedCarrierlnfo-v9eO
OPTIONAL, - Cond NoRedirect-r8
idleModeMobilityControllnfo-v9e0 ldleModeMobilityControllnfo-v9e0
OPTIONAL, - Cond IdlelnfoEUTRA
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
- Regular non critical extensions
RRCConnectionRelease-v920-IEs SEQUENCE {
celllnfoList-r9 CHOICE {
geran-r9 CelllnfoListGERAN-r9, utra-FDD-r9 CelllnfoListUTRA-FDD- r9,
utra-TDD-r9 CelllnfoListUTRA-TDD- r9, utra-TDD-r10 CelllnfoListUTRA-TDD-r10
}
OPTIONAL, - Cond Redirection
nonCriticalExtension RRCConnectionRelease-v1020-IEs
OPTIONAL
}
RRCConnectionRelease-v1020-IEs ::= SEQUENCE {
extendedWaitTime-r10 INTEGER (1..1800)
OPTIONAL, - Need ON
nonCriticalExtension RRCConnectionRelease-v1320-IEs
OPTIONAL
}
RRCConnectionRelease-v1320-IEs ::= SEQUENCE {
resumeldentity-r13 Resumeldentity-r13
OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL
RRCConnectionRelease-v1400-IEs ::= SEQUENCE { ReleaseCause-r14 ENUMERATED {rrcLightlyConnected-v1400} OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
ReleaseCause ::= ENUMERATED
{loadBalancingTAUrequired,
other, cs-
FallbackHighPriority-v1020, rrcSuspend-v1320}
[0054] As discussed above, light connection mode may be entered into (i.e., configured) through the use of an RRC connection release message. Additionally or alternatively, light connection mode may be entered into through the use of an RRC connection reconfiguration message. For example an IE (e.g., OtherConfig IE) within an RRC connection reconfiguration message may be used to configure a UE to operate in light connection mode so that it can perform DRX accordingly. The OtherConfig IE contains configuration information related to other configuration. In some embodiments, the OtherConfig IE may be updated as set forth in the following ASN1 code:
OtherConfig information element
- AS N1 START
OtherConfig-r14 ::= SEQUENCE {
NghtConnectionConfig-r14 ObtainLocationConfig-r14
OPTIONAL - Need ON
LightConnectionConfig-r14 ::= SEQUENCE {
NghtConnection-r14 ENUMERATED {true}
OPTIONAL - Need OR
}
[0055] As noted above, traditionally, a UE (that is in RRCJdle state, for example) is paged through the MME using an S1 -AP paging message, because the RAN node does not have a UE RAN context for the UE. When the UE is suspended and/or in light connection mode, the RAN node retains the UE RAN context and can be paged by the RAN node itself. This enables new solutions for RAN-based paging. [0056] In some embodiments, the specification (e.g., 3GPP TS 36.331 ) may be updated to support a RAN-based paging mechanism. For example, a
SystemlnformationBlockTypel -v1400 IE of a broadcast signal may be updated to enable a RAN-based paging mechanism as set forth in the following ASN1 code:
System lnformationBlockType1 -v1400-IEs ::= SEQUENCE {
RANPagingArealnfo-v1400 SEQUENCE { trackingAreaAllowed-r14 ENUMERATED {true}
OPTIONAL - Need OP
RANpagingAreaCode
RANPagingAreaCode OPTIONAL - Need OP
},
nonCriticalExtension System InformationBlockTypel - v1400-IEs OPTIONAL
}
[0057] As shown, the SystemlnformationBlockTypel -v1400 IE includes a RANpagingAreaCode field and a RANPagingAreaCode IE. In some cases, the RANpagingAreaCode field refers to the RAN-based paging area identifier. In some cases, the RANPagingAreaCode IE is used to identify a RAN-based paging area within the scope of a PLMN/tracking area. In some embodiments, a
RANPagingAreaCode IE may be defined as set forth in the following ASN1 code:
RANPagingAreaCode information element
- AS N1 START
RANpagingAreaCode ::= BIT STRING (SIZE (16))
- ASN1 STOP
[0058] In some embodiments, an RRC connection reconfiguration message may be updated to enable a RAN-based paging mechanism. For example, an RRC connection reconfiguration may be updated to enable a RAN-based paging area using dedicated signaling as set forth in the following ASN1 code:
RRCConnectionReconfiguration message
- AS N1 START
RRCConnectionReconfiguration ::= SEQUENCE {
rrc-Transaction Identifier RRC-Transaction Identifier, criticalExtensions CHOICE {
c1 CHOICE{ rrcConnectionReconfiguration-r8
RRCConnectionReconfiguration-r8-IEs,
spare7 NULL,
spare6 NULL, spare5 NULL, spare4 NULL, spare3 NULL, spare2 NULL, sparel NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}
<TEXT OMITTED>
RANPagingArealnfo-r14 ::= SEQUENCE { pagingAreaCellldentityList ::= SEQUENCE (SIZE (1 ..maxCells-r14)) OF
pagingAreaCellldentitylnfo pagingAreaCellldentitylnfo ::= SEQUENCE {
physCellld-r12 PhysCellld, dl-CarrierFreq- 2 ARFCN-ValueEUTRA
}
RANpagingAreaCode RANpagingAreaCode OPTIONAL -Need OP }
[0059] As shown above, the RANPagingArealnfo-r14 IE includes a maxCells-r14 field. In some embodiments, the maxCells-r14 field is defined as set forth in the following ASN1 code: maxCells-r14 INTEGER ::= 16 - Maximum number of cells in the RAN paging Area cell list
[0060] In some embodiments, the RAN paging area defined above could also be defined as RAN Notification Area. In some cases, a RAN Notification Area may consist of a list of cells belonging to one or multiple RAN nodes or a list of RAN Paging Areas.
[0061] In some embodiments, a UE may indicate whether it supports light connection. In one example, the UE may indicate this capability in a UE-EUTRA- Capability IE. The UE-EUTRA-Capability IE may be used to convey the E-UTRA UE Radio Access Capability Parameters, see TS 36.306, and the Feature Group Indicators for mandatory features (defined in Annexes B.1 and C.1 ) to the network. The UE-EUTRA-Capability IE is transferred in E-UTRA or in another RAT. In some embodiments, a UE-EUTRA-Capability IE may be updated as set forth in the following ASN1 code:
UE-EUTRA-Capability information element
- AS N1 START
UE-EUTRA-Capability :: = SEQUENCE {
accessStratum Release AccessStratum Release, ue-Category INTEGER (1 ..5), pdcp-Parameters PDCP-Parameters, phyLayerParameters PhyLayerParameters, rf-Parameters RF-Parameters, measParameters MeasParameters, featureGrouplndicators BIT STRING (SIZE (32))
OPTIONAL,
interRAT-Parameters SEQUENCE {
utraFDD I RAT- ParametersUTRA-FDD OPTIONAL,
utraTDD128 I RAT- ParametersUTRA-TDD128 OPTIONAL,
utraTDD384 I RAT- ParametersUTRA-TDD384 OPTIONAL,
utraTDD768 I RAT- ParametersUTRA-TDD768 OPTIONAL,
geran I RAT- ParametersGERAN OPTIONAL,
cdma2000-HRPD I RAT- ParametersCDMA2000-HRPD OPTIONAL,
cdma2000-1xRTT I RAT- ParametersCDMA2000-1 XRTT OPTIONAL
},
nonCriticalExtension UE-EUTRA-Capability-v920- lEs OPTIONAL
<TEXT OMITTED>
UE-EUTRA-Capability-v1320-IEs ::= SEQUENCE {
ce-Parameters-v1320 CE-Parameters-v1320
OPTIONAL,
phyLayerParameters-v1320 PhyLayerParameters-v1320
OPTIONAL,
rf-Parameters-v1320 RF-Parameters-v1320
OPTIONAL,
fdd-Add-UE-EUTRA-Capabilities-v1320 UE-EUTRA-CapabilityAddXDD- Mode-v1320 OPTIONAL,
tdd-Add-UE-EUTRA-Capabilities-v1320 UE-EUTRA-CapabilityAddXDD- Mode-v1320 OPTIONAL, nonCriticalExtension UE-EUTRA-Capability-v1400- lEs OPTIONAL
Figure imgf000022_0001
OPTIONAL
}
<TEXT OMITTED>
- ASN1 STOP
[0062] As shown, the UE-EUTRA-Capability IE includes multiple UE-EUTRA- Capability field descriptions. For example, the UE-EUTRA-Capability IE includes a lightConnection field description. In some embodiments, the lightConnection field indicates the support of light connection (indicates that the UE supports light connection mode, for example). In some embodiments, support for light connection could also be provided by the UE as part of the device properties IE within 3GPP TS 36.306.
[0063] In some embodiments, RRC-dedicated signaling, such as an RRC Cell Update Request and/or an RRC Cell Update Response, is already defined. These message exchanges are used whenever UE moves across a paging area or a notification area to let the network know about its mobility. These messages are used when there is no data to transfer. In some cases, the response message could carry a suspend or a release indication to suspend or release the UE respectively. Both the RRC Cell Update Request message and the RRC Cell Update Response message are discussed in turn below.
[0064] In some embodiments, the RRC Cell Update Request (e.g.,
RRCCellUpdateRequest) message is used to perform an update procedure when the UE is crossing a paging area boundary of a light RRC connection or a RAN- configured tracking area. In some embodiments, the RRC Cell Update Request message uses signaling radio bearer SRB0, uses radio link control (RLC) service access point (SAP) in transparent mode (TM), uses the common control channel (CCCH) logical channel, and is a message between the UE and the E-UTRAN with a direction of UE to E-UTRAN. In some embodiments, an RRC Cell Update Request message is proposed as set forth in the following ASN1 code: - AS N1 START
RRCCellUpdateRequest-r14 ::= SEQUENCE {
rrc-Transaction Identifier RRC-Transaction Identifier,
criticalExtensions CHOICE {
rrcCellUpdateRequest-r14 RRCCellUpdateRequest-r14- lEs,
criticalExtensionsFuture SEQUENCE {}
}
RRCCellUpdateRequest-r14-IEs :: = SEQUENCE {
resumeldentity-r13 CHOICE { resumelD-r13
Resumeldentity-r13,
truncatedResumelD-r13 BIT
STRING (SIZE (24))
},
shortResumeMAC-l-r13 BIT STRING (SIZE (16)),
resumeCause-r13
ResumeCause,
spare BIT
STRING (SIZE (1 ))
}
ResumeCause ::= ENUMERATED {
emergency, highPriorityAccess, mt-
Access, mo-Signalling,
mo-Data, delayTolerantAccess-v1020, mo-
VoiceCall-v1280, sparel }
- ASN1 STOP
[0065] As shown, the RRCCellUpdateRequest message includes multiple
RRCConnectionResumeRequest or RRCCellUpdateRequest field descriptions. For example, the RRCConnectionResumeRequest field descriptions include a
resumeCause field description, a resumeldentity field description, and a
shortResumeMAC-l field description. In some embodiments, the resumeCause field provides the resume cause for the RRC connection resume request as provided by the upper layers. In some embodiments, the resumeldentity field is the UE identity to facilitate UE context retrieval at the eNB. In some embodiments, the
shortResumeMAC-l field is an authentication token to facilitate UE authentication at the eNB. [0066] It is appreciated that the proposed RRCCellUpdateRequest message is similar to the existing Rel-13 RRCConnectionResumeRequest message. In some embodiments, instead of a new message as defined above, an indication using spare bit can be added to the existing message (e.g.,
RRCConnectionResumeRequest message) to differentiate that the UE is performing Resume Request to do a Cell Update.
[0067] In some cases, the response to an RRCCellUpdateRequest message may be an RRC connection release (as described above, for example) or the following message (e.g., an RRCCellUpdateConfirm message), which involves configuration information for the light connection mode. In some cases, an
RRCCellUpdateConfirm message is provided in the case of a successful cell update.
[0068] The RRCCellUpdateConfirm message may be used to respond to a Cell Update Request for the light RRC connection. In some embodiments, the
RRCCellUpdateConfirm message uses signaling radio bearer SRB1 , uses radio link control (RLC) service access point (SAP) in acknowledged mode (AM), uses the dedicated control channel (DCCH) logical channel, and is a message between the E- UTRAN and the UE with a direction of E-UTRAN to UE. In some embodiments, an RRCCellUpdateConfirm message is proposed as set forth in the following ASN1 code:
- AS N1 START
RRCCellUpdateConfirm-r14 ::= SEQUENCE {
rrc-Transaction Identifier RRC-Transaction Identifier, criticalExtensions CHOICE {
c1 CHOICE { rrcCellUpdateConfirm-r14 RRCCellUpdateConfirm-r14- lEs,
spare3
NULL,
spare2
NULL,
sparel
NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}
RRCCellUpdateConfirm-r14-IEs ::= SEQUENCE { radioResourceConfigDedicated-r13 RadioResourceConfigDedicated
OPTIONAL, - Need ON
nextHopChainingCount-r13 NextHopChainingCount, measConfig-r13 MeasConfig
OPTIONAL, - Need ON
antennalnfoDedicatedPCell-r13 AntennalnfoDedicated-v1 OiO
OPTIONAL, - Need ON
drb-ContinueROHC-r13 ENUMERATED {true}
OPTIONAL, - Need OP
cellUpdateReleaseCause CellUpdateReleaseCause OPTIONAL,
Need OP
lateNonCriticalExtension OCTET STRING
OPTIONAL,
nonCriticalExtension SEQUENCE {}
OPTIONAL
}
- ASN1 STOP
CellUpdateReleaseCause ::= ENUMERATED {rrcSuspend- v14xx, rrcLightlyConnected-v14xx, other, sparel }
[0069] As shown, the RRCCellUpdateConfirm message includes multiple
RRCCellUpdateConfirm fields descriptions. For example, the
RRCCellUpdateConfirm field descriptions include a drb-ContinueROHC field description and a ReleaseCause field description. In some embodiments, the drb- ContinueROHC field indicates whether to continue or reset the header compression protocol context for the DRBs configured with the header compression protocol. Presence of this field indicates that the header compression protocol context continues while absence indicates that the header compression protocol context is reset. In some embodiments, the ReleaseCause field indicates that the RRC connection is released after successful Cell Update.
[0070] In the above message (e.g., the RRCCellUpdateConfirm message), the lEs shown within the RRCCellUpdateConfirm message are exemplary and one or more lEs may not be necessary as it is not necessary to configure DRB-related parameters for the UE that will be released into suspend or light connection or idle mode after the procedure. Furthermore, additional lEs may be added as necessary; an example of ReleaseCause has been added (as shown, for example). This is not an exhaustive list. [0071] In addition, a response to an RRCCellUpdateConfirm message may be sent by the UE which will be similar to an RRCResumeComplete message which can be followed by RRCConnectionRelease message. Alternatively the
RRCCellUpdateConfirm may be sent by the network containing the information that it gets sent by RRCConnectionRelease message directly and including a new indication for the UE to differentiate the network indication to release the connection via the RRCCellUpdateConfirm message such as the cellUpdateReleaseCause as defined above.
[0072] As discussed above, one or more portions of the 3GPP TS 36.331 specification may be updated and/or modified to support a light connection mode. Additionally or alternatively, one or more portions of the 3GPP TS 36.423
specification may be updated and/or modified to support a light connection mode. These changes are described below.
[0073] In some embodiments, the decision on whether the UE is released, suspended or lightly connected could be taken by a second eNB (e.g., eNB2) and/or an anchor eNB (e.g., eNB1 ). For this decision, corresponding indications could be included in the S1 -AP signaling exchanged between eNB2 and anchor eNB1 .
Various cases of this S1 -AP signaling are described below with reference to the figures. Although various cases are discussed below, it is appreciated that these cases are exemplary and that other cases, including various combinations of the cases, are also possible and considered herein. For the least specification impact, the eNB that the UE is currently in (moved into, for example) should have the UE context to be able to perform a release message with integrity and cipher protection.
[0074] FIGs. 1 -10 illustrate a communication system that includes a UE 102, a second eNB (i.e., eNB2) 104, an anchor eNB 106, a mobility management entity (MME) 108, and a serving gateway (S-GW) 1 10. As discussed in additional detail below, the UE 102 may wirelessly communicate with the eNB2 104 via a Uu interface, the eNB2 104 may communicate with the anchor eNB 106 via an X2 interface, the eNB2 104 and/or the anchor eNB 106 may communicate with the MME 108 via an S1 -MME interface, which uses an S1 -AP application layer interface, the eNB2 104 and/or the anchor eNB 106 may communicate with the S-GW 1 10 via an S1 -U interface, and the MME 108 may communicate with the S-GW 1 10 via an S1 1 interface. It is appreciated that the discussed messages are interface-specific and are understood to be communicated using the appropriate interface. [0075] FIG. 1 is a message diagram that illustrates an embodiment 100 in which the UE 102 is released based on a decision made by the anchor eNB 106. In the embodiment 100 the UE 102 transmits a first random access (RA) message (msg) (i.e., RA msg 1 ) 1 12 with an RA preamble to the eNB2 104 using a physical random access channel (PRACH). In response to the RA msg 1 1 12, the eNB2 104 transmits a second RA msg (i.e., RA msg 2) 1 14 to the UE 102. In one example, the RA msg 2 1 14 may be a random access response (RAR) message.
[0076] The UE 102 in the embodiment 100 is in a light connection mode. This means that the UE 102 has a stored UE RAN context and the anchor eNB 106 has a stored UE RAN context for the UE 102. While the UE 102 is in the light connection mode, the anchor eNB 106 maintains an S1 -U interface 1 16 with the S-GW 1 10 for the UE 102. In addition, while the UE 102 is in the light connection mode, the UE 102 maintains a stored Resume ID and a stored resumeMAC-l. As discussed above, the stored UE RAN context and the maintained parameters (e.g., Resume ID, resumeMAC-l) and interfaces (e.g., the S1 -U interface 1 16) enable the UE 102 to resume its prior UE context with only a small amount of signaling.
[0077] The UE 102 transmits an RRC Cell Update Request 1 18 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC Cell Update Request 1 18 with the Resume ID w/resumeMAC-l, and establishment cause, the eNB2 104 transmits a retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
[0078] In this case (i.e., the embodiment 100), the anchor eNB 106 may determine to release the UE 102 from light connection (e.g., light connection mode). In one example, this determination is made in response to receiving the retrieve UE context request 120. In another example, this decision may have been determined previous to the reception of the retrieve UE context request 120. The anchor eNB 106 may transmit an S1 -AP: UE context release request 122 to the MME 108.
[0079] In response to the S1 -AP: UE context release request 122, the MME 108 transmits a release access bearer request 124 to the S-GW 1 10. In response, the S- GW 1 10 transmits a release access bearer response 126 to the MME 108. Upon receiving the release access bearer response 126, the MME 108 transmits an S1 - AP: UE context release command 128 to the anchor eNB 106. In response to receiving the S1 -AP: UE context release command 128, the anchor eNB 106 transmits a retrieve UE context response with a release indication 130 to the eNB2 104. For example, the retrieve UE context response with the release indication 130 may contain the indication that the UE 102 is to be released to RRCJdle state. In addition, the anchor eNB 106 transmits an S1 -AP: UE context release response 134 to the MME 108. Through this process, the S1 -U interface 1 16 that was previously maintained is released.
[0080] In response to receiving the retrieve UE context response with the release indication 130, the eNB2 104 transmits an RRC connection release message 132 to the UE 102. In response to the RRC connection release message 132, a UE RRC connection 136 is released. It is appreciated that this release of the UE RRC connection 136 includes a release of the UE RAN context at the UE 102 and the UE RAN context at the anchor eNB 106. Thus, the anchor eNB 106 releases the S1 -U interface 1 16 and any other context information associated with the UE 102.
Similarly, the UE 102 releases any parameters and context information associated with its prior RRC connection.
[0081] Accordingly, in the embodiment 100, the UE 102, which began in a lightly connected mode, is released to RRCJdle state without light connection (i.e., the RRC connection is released). In the embodiment 100 this release was triggered by the anchor eNB 106.
[0082] FIG. 2 is a message diagram that illustrates an embodiment 200 in which the UE 102 is released based on a decision made by the eNB2 104. It is
appreciated that FIG. 2 is similar to FIG. 1 , except that it is the eNB2 104 rather than the anchor eNB 106 that triggers the release of the UE 102. In some embodiments (as illustrated in the embodiment 200), once the new eNB (e.g., the eNB2 104) has the UE RAN context, it can initiate the release at any time using the UE CONTEXT RELEASE REQUEST as per 3GPP TS 36.413. In some embodiments, no specification change is necessary.
[0083] In the embodiment 200, the UE 102 retrieves the UE RAN context from the anchor eBN 106 in response to the retrieve UE context request 120. For example, the anchor eNB 106 provides the UE RAN context to the eNB2 104 in a retrieve UE context response 202. Upon receiving the UE RAN context, the eNB2 104 may determine to release the UE 102 to RRCJdle state without light connection. [0084] Upon determining to release the UE 102, which is in light connection mode, the eNB2 104 transmits the S1 -AP: UE context release request 122 to the MME 108. In the embodiment 200, the MME 108 transmits the S1 -AP: UE context release command 128 to the eNB2 104 and the release access bearer request 124 to the S-GW 1 10. In response to the release access bearer request 124, the S-GW 1 10 transmits the release access bearer response 126 to the MME 108.
[0085] Upon receiving the S1 -AP: UE context release command 128, the eNB2 104 transmits the RRC connection release message 132 to the UE 102 and transmits the S1 -AP: UE context release response 134 to the MME 108. Through this process, the UE RRC connection 136 is released (the UE RAN context is released at both the UE 102 and at the eNB2 104, for example). As a result, the S1 - U interface 1 16 that was previously maintained is also released. Thus, the UE 102, which was in a light connection mode with a stored UE RAN context, is released in response to a decision made by the new eNB2 104.
[0086] FIG. 3 is a message diagram that illustrates an embodiment 300 in which the anchor eNB 106 suspends the UE 102 that has moved to another eNB (i.e., the eNB2 104). Similar to FIGs. 1 and 2, the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and the maintained S1 -U interface 1 16.
[0087] The UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC Cell Update Request 1 18 with the Resume ID w/resumeMAC-l, and establishment cause, the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
[0088] In response to receiving the retrieve UE context request 120, the anchor eNB 106 may determine to suspend the UE 102. For example, the anchor eNB 106 may determine to suspend the UE 102 since it has moved to another eNB (e.g., the eNB2 104). In response to determining to suspend the UE 102, the anchor eNB 106 may transmit an S1 -AP: UE context suspend request 302 to the MME 108.
[0089] In response to the S1 -AP: UE context suspend request 302, the MME 108 transmits the release access bearer request 124 to the S-GW 1 10. In response, the S-GW 1 10 transmits the release access bearer response 126 to the MME 108. Upon receiving the release access bearer response 126, the MME 108 transmits an S1 -AP: UE context suspend request 304 to the anchor eNB 106. In response to receiving the S1 -AP: UE context suspend request 304, the anchor eNB 106 transmits a retrieve UE context response with a suspend indication 306 to the eNB2 104. For example, the retrieve UE context response with the suspend indication 306 may contain an indication (e.g., suspend indication = TRUE) that the UE 102 is to be suspended while in an RRCJdle state.
[0090] It is appreciated that the previously maintained S1 -U interface 1 16 is released as part of the suspend mode. However, as noted above, the anchor eNB 106 maintains UE RAN context for the UE 102 as part of the suspend mode.
[0091] In response to receiving the retrieve UE context response with the suspend indication 306, the eNB2 104 transmits an RRC connection release with a suspend indication 308 or a cell update response with a suspend indication 308 to the UE 102. In response, the UE 102 is moved to a suspended mode 310.
[0092] Accordingly, in the embodiment 300, the UE 102, which began in a lightly connected mode, is moved to the suspended mode 310 (while in RRCJdle state, for example). In the embodiment 300, the UE 102 is suspended by the anchor eNB 106. In addition, the UE RAN context is moved from the anchor eNB 106 to the eNB2 104 and the MME 108 is made aware of context suspend req/response by the anchor eNB 106.
[0093] In the embodiment 300, as per below, the retrieve UE context response with the suspend indication 306 (RETRIEVE UE CONTEXT RESPONSE as defined in 3GPP TS 36.423, for example) should include whether the UE 102 is being kept in light connection or suspended. In some embodiments, the retrieve UE context response with the suspend indication (e.g., 306) is sent by the old eNB (e.g., the anchor eNB 106) to transfer the UE RAN context to the new eNB (e.g., the eNB2 104). The retrieve UE context response with the suspend indication 306 is transmitted from the old eNB to the new eNB. Additional functional definitions and content associated with the retrieve UE context response with the suspend indication 306 are provided in Table 1 below.
Figure imgf000030_0001
Figure imgf000031_0001
Table 1
[0094] FIG. 4 is a message diagram that illustrates an embodiment 400 in which the UE context suspend is performed by a new eNB (e.g., the eNB2 104). FIG. 4 is similar to FIG. 3 except that the UE context suspend is performed by the new eNB instead of the old eNB. Similar to FIGs. 1 and 2, the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
[0095] The UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC Cell Update Request 1 18 with the Resume ID w/resumeMAC-l, and establishment cause, the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
[0096] In response to receiving the retrieve UE context request 120, the anchor eNB 106 may provide the UE RAN context to the eNB2 104 in the retrieve UE context response 202. In the embodiment 400, the eNB2 104 determines to suspend the UE RAN context. In response to determining to suspend the UE 102, the eNB2 104 transmits the S1 -AP: UE context suspend request 302 to the MME 108.
[0097] In response to the S1 -AP: UE context suspend request 302, the MME 108 transmits the release access bearer request 124 to the S-GW 1 10. In response, the S-GW 1 10 transmits the release access bearer response 126 to the MME 108. In some embodiments, the release access bearer request 124 and the release access bearer response 126 serve to release the previously maintained S1 -U interface 1 16.
[0098] Upon receiving the release access bearer response 126, the MME 108 transmits the S1 -AP: UE context suspend request 304 to the eNB2 104. In response to receiving the S1 -AP: UE context suspend request 304, the eNB2 104 transmits an RRC connection release message with a suspend indication 402 or a cell update response with a suspend indication 402. In addition, the eNB2 104 transmits a UE context release message 404 to the anchor eNB 106 (indicating that the anchor eNB 106 can delete the UE RAN context, for example). In response to the UE context release message 404, the UE 102 is moved to the suspended mode 310.
[0099] Accordingly, in the embodiment 400, the UE 102, which began in a lightly connected mode, is moved to the suspended mode 310 (while in RRCJdle state, for example). In the embodiment 400, the UE 102 is suspended by the eNB2 104, which becomes the new anchor. In other words, the UE RAN context is transferred to the eNB2 104 (and the anchor eNB 106 deletes the UE RAN context, for example) and the MME 108 needs to be aware of context suspend request/response, and S1 context suspend is performed by the eNB2 104, which also acts as a path switch message. In this case, resume occurs from the eNB2 104 without further UE RAN context fetch necessary. Accordingly, no change to RETRIEVE UE CONTEXT REQ/RESP messages may be necessary.
[0100] In the embodiment 400, the decision to suspend the UE 102 is made by the new eNB (e.g., the eNB2 104). In some cases, the UE context release message 404 is sent so that the anchor eNB 106 will not expect any more downlink data to be forwarded to the UE 102 if any is received during this process and can release the corresponding resources.
[0101] FIG. 5 is a message diagram that illustrates an embodiment 500 in which the UE 102 is kept in light connection with the anchor eNB 106 through a cell update procedure. In other words, the UE 102 is kept in light connection and the UE context is kept in the anchor eNB 106. For this to occur, the new eNB (e.g., the eNB2 104) needs to be updated to be part of the paging area. This decision is made by the anchor eNB 106 and is provided in a given response. This may be done using new X2 messages or existing RETRIEVE UE CONTEXT REQUEST/RESPONSE messages as shown in the embodiment 500. It is appreciated that in this case, an S1 -AP path switch is not performed (the S1 -U interface 1 16 is maintained between the anchor eNB 106 and the S-GW 1 10, for example).
[0102] It is appreciated that the UE 102 is in light connection mode with the anchor eNB 106. This means that the anchor eNB 106 maintains the S1 -U interface 1 16 with the S-GW 1 10 for the UE 102. The UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC Cell Update Request 1 18 with the Resume ID w/resumeMAC-l, and
establishment cause, the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
[0103] Upon receiving the retrieve UE context request 120, the anchor eNB 106 transmits a retrieve UE context response message 502 to the eNB2 104. In embodiment 500 the retrieve UE context response message 502 includes a paging area update optimization indication. In addition the retrieve UE context response message 502 may not include a suspend indication (suspend indication = FALSE, for example).
[0104] Upon receiving the retrieve UE context response message 502 with the paging area update optimization indication, the eNB2 104 transmits an RRC cell update response with new cell list 504 or RRC connection reconfiguration with new cell list 504 to the UE 102. In response to the message 504, the UE 102 transmits an RRC connection reconfiguration complete message 506. In the embodiment 500, messages 504 and 506 are performed to update the paging area cell list for the UE 102.
[0105] Once the paging area cell list for the UE 102 has been updated, as acknowledged by the receipt of the RRC connection reconfiguration complete message 506, the eNB2 104 transmits an RRC connection release with light connection indication 508 to the UE 102. In response to the RRC connection release with light connection indication 508, the UE 102 is kept (i.e., stays) in light connected mode and the anchor node is not changed 510. Similarly, the anchor eNB 106 maintains the S1 -U interface 1 16.
[0106] FIG. 6 is a message diagram that illustrates an embodiment 600 of a cell update procedure in which the UE 102 is kept in light connection with a new anchor eNB (e.g., the eNB2 104) after an S1 path switch. In other words, the UE 102 is kept in light connection and the UE RAN context is moved from the anchor eNB 106 to the eNB2 104, which becomes the new anchor (re-anchoring case wherein the context is relocated upon paging area update message from the UE 102 after moving to a different paging area, for example).
[0107] Similar to FIGs. 1 and 2, the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
[0108] The UE 102 transmits the RRC Cell Update Request 1 18 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC Cell Update Request 1 18 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC Cell Update Request 1 18 with the Resume ID w/resumeMAC-l, and establishment cause, the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example).
[0109] In response to receiving the retrieve UE context request 120, the anchor eNB 106 may provide the UE RAN context to the eNB2 104 in a retrieve UE context response 602. In some embodiments, the retrieve UE context response 602 includes an indication to not suspend. In one example, this may be an implicit indication (absence of a suspend indication field, for example). In another example, this may be an explicit indication (suspend indication = FALSE, for example).
[0110] In some embodiments, the eNB2 104 determines to become the new anchor eNB and to switch the S1 path. In response to determining to becoming the new anchor eNB and to switching the S1 path, the eNB2 104 transmits an RRC cell update response with light connection indication 604 or an RRC connection release with light connection indication 604 to the UE 102. In addition, the eNB2 104 transmits an S1 -AP: path switch request 606 to the MME 108.
[0111] In response to the S1 -AP: path switch request 606, the MME 108 transmits a modify bearer request 608 to the S-GW 1 10. In response, the S-GW 1 10 transmits a modify bearer response 610 to the MME 108. In some embodiments, the modify bearer request 608 and the modify bearer response 610 serve to modify the path of the previously maintained S1 -U interface 1 16 so that the S1 -U interface (not shown) is between the eNB2 104 and the S-GW 1 10 instead of between the anchor eNB 106 and the S-GW 1 10. Upon receiving the modify bearer response 610, the MME 108 transmits an S1 -AP: path switch response 612 to the eNB2 104.
[0112] The RRC cell update response with light connection indication 604 or the RRC connection release with light connection indication 604 keeps the UE 102 in a lightly connected mode 614. In this case, the UE 102 is kept in the lightly connected mode 614 with the eNB2 104 as the new anchor eNB. In other words, the eNB2 104 maintains the UE RAN context and maintains the modified S1 -U interface (not shown) for the UE 102.
[0113] Accordingly, in the embodiment 600, the UE 102, which began in a lightly connected mode, is kept in the lightly connected mode 614 but with the eNB2 104 as a new anchor eNB. In the embodiment 600, the UE RAN context is transferred to the eNB2 104 (and the anchor eNB 106 deletes the UE RAN context, for example) and the S1 context is modified to correspond with the new anchor eNB.
[0114] FIG. 7 is a message diagram that illustrates an embodiment 700 in which the UE 102 has mobile-originated data to send and is resumed from light connected mode for data transfer. The UE 102 may either be within the paging area or be outside the paging area. In the embodiment 700, the S1 path switch should be done and context should be retrieved to the current eNB so that the UE 102 can send its mobile-originated data.
[0115] Similar to FIGs. 1 and 2, the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
[0116] The UE 102 transmits an RRC connection resume request 702 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC connection resume request 702 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC connection resume request 702 with the Resume ID w/resumeMAC-l, and establishment cause, the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example). The anchor eNB 106 transmits the retrieve UE context response 202 that includes the UE RAN context to the eNB2 104. [0117] The eNB2 104 determines to become the new anchor eNB and to switch the S1 path. In response to determining to becoming the new anchor eNB and to switching the S1 path, the eNB2 104 transmits an RRC connection resume message 704 to the UE 102. In addition, the eNB2 104 transmits the S1 -AP: path switch request 606 to the MME 108.
[0118] In response to the S1 -AP: path switch request 606, the MME 108 transmits the modify bearer request 608 to the S-GW 1 10. In response, the S-GW 1 10 transmits the modify bearer response 610 to the MME 108. Upon receiving the modify bearer response 610, the MME 108 transmits the S1 -AP: path switch response 612 to the eNB2 104. This process of modifying the path of the previously maintained S1 -U interface 1 16 results in the S1 -U interface being between the eNB2 104 and the S-GW 1 10.
[0119] Meanwhile, the UE 102, in response to the RRC connection resume message 704 transmits an RRC connection resume complete message 706 to the eNB2 104, which establishes the RRC connection (to RRC_Connected state, for example) between the UE 102 and the eNB2 104. With the UE 102 in
RRC_Connected mode and the S1 path updated, the UE 102 may send its mobile- originated data (e.g., uplink (UL) data 708) via the S1 -U interface and may receive data (e.g., downlink (DL) data 710) via the S1 -U interface.
[0120] Accordingly, in the embodiment 700, the UE 102, which began in a lightly connected mode, can efficiently (with minimal signaling, for example) resume its UE RAN context and send and/or receive data via the S1 -U interface.
[0121] FIG. 8 is a message diagram that illustrates an embodiment 800 in which the network (e.g., the S-GW 1 10) has mobile-terminated data for the UE 102 and the UE 102 is resumed from light connected mode for data transfer. The UE 102 may either be within the paging area or be outside the paging area. In the embodiment 800, the S1 path switch should be done and context should be retrieved to the current eNB so that the UE 102 can receive its mobile-terminated data. In some embodiments, mobile-terminated access is enabled through X2 paging.
[0122] Similar to FIGs. 1 and 2, the UE 102 begins in a lightly connected mode with a stored UE RAN context and the anchor eNB 106 having a stored UE RAN context and a maintained S1 -U interface 1 16.
[0123] In the case of mobile-terminated data, the S-GW 1 10 transmits downlink data 802 to the anchor eNB 106. In the case that the UE 102 is not within the coverage area of the anchor eNB 106, the anchor eNB 106 may transmit an X2-AP: paging message 804 to one or more other eNBs (e.g., the eNB2 104). In some cases, the one or more other eNBs are eNBs that are associated with a paging area. In other cases, the one or more other eNBs are eNBs have some geographic nexus to the anchor eNB 106 but are outside of a paging area associated with the anchor eNB 106. In the embodiment 800, the eNB2 104 receives the X2-AP paging message 804 from the anchor eNB 106. In some cases, the X2-AP paging message 804 includes at least a portion of UE RAN context information so that non-anchor eNBs (e.g., the eNB2 104) can page the UE 102 using RRC paging techniques. In response to receiving the X2-AP paging message 804, the eNB2 104 transmits an RRC paging message 806 to its coverage area.
[0124] In response to receiving the RRC paging message 806, the UE 102 transmits an RRC connection resume request 808 to the eNB2 104. In one example (because the UE 102 is in light connection mode, for example), the RRC connection resume request 808 may include a Resume ID with a resumeMAC-l, and/or an establishment cause. In response to the RRC connection resume request 808 with the Resume ID w/resumeMAC-l, and establishment cause, the eNB2 104 transmits the retrieve UE context request 120 to the anchor eNB 106 (which maintains the stored UE RAN context, for example). The anchor eNB 106 transmits the retrieve UE context response 202 to the eNB2 104. In some embodiments, the retrieve UE context response 202 includes the UE RAN context for the UE 102.
[0125] In response to receiving the retrieve UE context response 202, the eNB2 104 transmits the RRC connection resume message 704 to the UE 102. In response to the RRC connection resume message 704 and the resumption of the RRC connection, the UE 102 transmits the RRC connection resume complete message 706 to the eNB2 104.
[0126] Meanwhile, the anchor eNB 106 transmits data 810 (e.g., forwards data 810) to the eNB2 104 that was received in downlink data 802. Since the eNB2 104 is the new anchor for the UE 102, the S1 path needs to be switched from the anchor eNB 106 to the eNB2 104. Accordingly, the eNB2 104 transmits the S1 -AP: path switch request 606 to the MME 108.
[0127] In response to the S1 -AP: path switch request 606, the MME 108 transmits the modify bearer request 608 to the S-GW 1 10. In response, the S-GW 1 10 transmits the modify bearer response 610 to the MME 108. Upon receiving the modify bearer response 610, the MME 108 transmits the S1 -AP: path switch response 612 to the eNB2 104. This process of modifying the path of the previously maintained S1 -U interface 1 16 results in the S1 -U interface being between the eNB2 104 and the S-GW 1 10. As the new anchor eNB, the eNB2 104 may transmit a UE release request 812 to the anchor eNB 106. In some embodiments, the UE release request 812 may be a UE context release request that indicates to the anchor eNB 106 that it can release the UE RAN context for the UE 102.
[0128] With the UE 102 in RRC_Connected mode and the S1 path updated, the UE 102 may receive data (e.g., downlink (DL) data 710) via the S1 -U interface. In addition, the UE 102 may send data (e.g., uplink (UL) data 708, not shown) via the S1 -U interface.
[0129] Accordingly, in the embodiment 800, the UE 102, which began in a lightly connected mode, can efficiently (with minimal signaling, for example) resume its UE RAN context and receive mobile-terminated data via the S1 -U interface.
[0130] In each of the foregoing embodiments, the UE context is retrieved from an old eNB (e.g., the anchor eNB 106) and moved to a new eNB (e.g., the eNB2 104). As part of the process of retrieving the UE context and moving it to the new eNB, the old eNB transmits a retrieve UE context response (as defined in 3GPP TS 36.423, for example) (e.g., retrieve UE context response 130, 202, 306, 502, 602) to the new eNB. The retrieve UE context response message is sent by the old eNB to transfer the UE context to the new eNB. If the old eNB supported eDRX values, then eDRX related parameters could be shared to the new eNB along with the UE context. As mentioned above, the direction of the retrieve UE context response message is from the old eNB to the new eNB. Additional functional definitions and content associated with the retrieve UE context response are provided in Table 2 below.
Figure imgf000038_0001
Extension 9.2.86
Old eNB M eNB UE Allocated YES ignore UE X2AP X2AP ID at the old
ID 9.2.24 eNB
Old eNB O Extended Allocated YES ignore UE X2AP eNB UE at the old
ID X2AP ID eNB
Extension 9.2.86
GUMMEI M 9.2.16 YES reject
UE 1 YES Reject
Context
Information
... <Text
omitted>
>Paging ID M S-TMSI
IMSI
Resume
ID, etc.
>UE e.g.,
Identity IMSI
index mod
1024
>Paging M 9.2.93 RAN
DRX Paging
DRX value
originally
configured
for the UE
(UE- specific)
Table 2
[0131] In some embodiments, the RAN paging discontinuous reception (DRX) can be passed from one eNB to another while the UE RAN context is retrieved and the UE is moved to the new eNB. The RAN Paging DRX IE contains the value of RAN-based DRX configured by the old eNB. The RAN-based DRX configured by the old eNB is mandatory for all messages. As used herein, the value s0.02 corresponds to 0.02 seconds, s0.04 corresponds to 0.04 seconds and so on. The RAN Paging DRX IE also contains optional eDRX parameters configured by the old eNB if applicable. Additional functional definitions and content associated with the RAN Paging DRX IE are provided in Table 3 below.
Figure imgf000040_0001
Table 3
[0132] In some embodiments, the extended DRX parameters indicate the offset of the narrowband internet of things (NB-IOT) channel number to the E-UTRA absolute radio frequency channel number (EARFCN). In some cases, the extended DRX parameters are also applicable to X2AP paging message.
[0133] In some embodiments, X2AP paging (as defined in 3GPP TS 36.423, for example) may be modified to support MME load balancing. For example, a loadbaiancingTAUrequired IE may be included within a paging message so that the UE can perform RRC Resume with corresponding establishment cause and also not use corresponding parameters within the RRC Resume Complete message to perform tracking area update (TAU) (the registered MME should not be provided, for example). Additional functional definitions and content associated with a paging message are provided in Table 4 below.
Figure imgf000040_0002
the UE (UE- specific)
>CN domain M 9.2.x YES Ignore CS or PS
> RAN based M 9.2.x YES Ignore
Paging
priority
> load 0 9.2.x ENUMERATED YES Ignore balancing {true}
TAU required
indication
Table 4
[0134] FIG. 9 is a message diagram that illustrates an embodiment 900 in which a paging message is 906 communicated between a second eNB 904 and a first eNB 902. The paging message 906 may be communicated over the X2 interface via X2- AP. In some embodiments, the paging message 906 includes the
loadbalancingTAUrequired IE discussed above.
[0135] At the reception of the paging message 906, the first eNB 902 shall perform paging firstly in cells which belong to the recommended cells/eNBs list, and secondly those cells which belong to tracking areas as indicated in the List of TAIs IE in an S1 -AP message from MME. The indication "load balancing TAU required" when set indicates that the UE shall perform TAU. This indication is set because the "anchor eNB" (e.g., the second eNB 904) received an S1 release request for the UE from MME. When the indication loadbalancingTAUrequired" is set, the MME assumes the UE is ECM_CONNECTED and the S1 is still active. However, as the UE is not in RRC_CONNECTED, and the RRC connection release is already done and/or the UE might have moved away from that eNB within the paging area, the X2 paging is the only option to inform the UE.
[0136] FIG. 10 is a flow diagram of a method 1000 for operating in a light connected mode. The method 1000 is performed by a device, such as a user equipment (UE) or the like. In particular, the method 1000 may be performed by a processor (e.g., a baseband processor) within the device. Although the operations of the method 1000 are illustrated as being performed in a particular order, it is understood that the operations of the method 1000 may be reordered without departing from the scope of the method.
[0137] At 1002, a UE operates in an RRC_Connected state. At 1004, an RRC message that includes an indication to enter a lightly connected mode is decoded. In some cases, the lightly connected mode may be referred to as a lightly connected RRC mode. At 1006, the lightly connected mode is configured. The RRC
connection is suspended in the lightly connected mode. At 1008, the UE transitions to an RRCJdle state while in the lightly connected mode.
[0138] The operations of the method 1000 may be performed by an application- specific processor, programmable application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like.
[0139] FIG. 1 1 illustrates an architecture of a system 1 100 of a network in accordance with some embodiments. The system 1 100 is shown to include a user equipment (UE) 1 101 and a UE 1 102. The UEs 1 101 and 1 102 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. The UEs 1 101 and 1 102 may be examples of the UE 102 discussed previously. In some embodiments, the UE 102 discussed above is an example of UEs 1 101 and/or 1 102.
[0140] In some embodiments, any of the UEs 1 101 and 1 102 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.
[0141] The UEs 1 101 and 1 102 may be configured to connect, e.g.,
communicatively couple, with a radio access network (RAN) 1 1 10. The RAN 1 1 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 1 101 and 1 102 utilize connections 1 103 and 1 104, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 1 103 and 1 104 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.
[0142] In this embodiment, the UEs 1 101 and 1 102 may further directly exchange communication data via a ProSe interface 1 105. The ProSe interface 1 105 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).
[0143] The UE 1 102 is shown to be configured to access an access point (AP) 1 106 via a connection 1 107. The connection 1 107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.1 1 protocol, wherein the AP 1 106 would comprise a wireless fidelity (WiFi®) router. In this example, the AP 1 106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).
[0144] The RAN 1 1 10 can include one or more access nodes that enable the connections 1 103 and 1 104. 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 1 1 10 may include one or more RAN nodes for providing macrocells, e.g., a macro RAN node 1 1 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., a low power (LP) RAN node 1 1 12.
[0145] Any of the RAN nodes 1 1 1 1 and 1 1 12 can terminate the air interface protocol and can be the first point of contact for the UEs 1 101 and 1 102. In some embodiments, any of the RAN nodes 1 1 1 1 and 1 1 12 can fulfill various logical functions for the RAN 1 1 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. In some embodiments, the eNB2 104 and the anchor eNB 106 discussed above are examples of RAN nodes 1 1 1 1 and/or 1 1 12.
[0146] In accordance with some embodiments, the UEs 1 101 and 1 102 can be configured to communicate using Orthogonal Frequency-Division Multiplexing
(OFDM) communication signals with each other or with any of the RAN nodes 1 1 1 1 and 1 1 12 over a multicarrier communication channel in accordance with 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.
[0147] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 1 1 1 1 and 1 1 12 to the UEs 1 101 and 1 102, 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.
[0148] The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs 1 101 and 1 102. 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 1 101 and 1 102 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 1 102 within a cell) may be performed at any of the RAN nodes 1 1 1 1 and 1 1 12 based on channel quality information fed back from any of the UEs 1 101 and 1 102. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 1 101 and 1 102.
[0149] 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).
[0150] 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.
[0151] The RAN 1 1 10 is shown to be communicatively coupled to a core network (CN) 1 120— via an S1 interface 1 1 13. In embodiments, the CN 1 120 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 1 1 13 is split into two parts: the S1 -U interface 1 1 14, which carries traffic data between the RAN nodes 1 1 1 1 and 1 1 12 and a serving gateway (S-GW) 1 122, and an S1 -mobility
management entity (MME) interface 1 1 15, which is a signaling interface between the RAN nodes 1 1 1 1 and 1 1 12 and MMEs 1 121 . [0152] In this embodiment, the CN 1 120 comprises the MMEs 1 121 , the S-GW 1 122, a Packet Data Network (PDN) Gateway (P-GW) 1 123, and a home subscriber server (HSS) 1 124. The MMEs 1 121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 1 121 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 1 124 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The CN 1 120 may comprise one or several HSSs 1 124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 1 124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. In some embodiments, the MME 108 discussed above is an example of the MMEs 1 121 . In some
embodiments, the S-GW 1 10 discussed above is an example of the S-GW 1 122.
[0153] The S-GW 1 122 may terminate the S1 interface 1 1 13 towards the RAN 1 1 10, and routes data packets between the RAN 1 1 10 and the CN 1 120. In addition, the S-GW 1 122 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.
[0154] The P-GW 1 123 may terminate an SGi interface toward a PDN. The P- GW 1 123 may route data packets between the CN 1 120 (e.g., an EPC network) and external networks such as a network including the application server 1 130
(alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 1 125. Generally, an application server 1 130 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 1 123 is shown to be communicatively coupled to an application server 1 130 via an IP communications interface 1 125. The application server 1 130 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 1 101 and 1 102 via the CN 1 120.
[0155] The P-GW 1 123 may further be a node for policy enforcement and charging data collection. A Policy and Charging Enforcement Function (PCRF) 1 126 is the policy and charging control element of the CN 1 120. 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 1 126 may be communicatively coupled to the application server 1 130 via the P-GW 1 123. The application server 1 130 may signal the PCRF 1 126 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 1 126 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 1 130.
[0156] FIG. 12 illustrates example components of a device 1200 in accordance with some embodiments. In some embodiments, the device 1200 may include application circuitry 1202, baseband circuitry 1204, Radio Frequency (RF) circuitry 1206, front-end module (FEM) circuitry 1208, one or more antennas 1210, and power management circuitry (PMC) 1212 coupled together at least as shown. The components of the illustrated device 1200 may be included in a UE or a RAN node. In some embodiments, the device 1200 may include fewer elements (e.g., a RAN node may not utilize application circuitry 1202, and instead include a
processor/controller to process IP data received from an EPC). In some
embodiments, the device 1200 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).
[0157] The application circuitry 1202 may include one or more application processors. For example, the application circuitry 1202 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 1200. In some embodiments, processors of application circuitry 1202 may process IP data packets received from an EPC.
[0158] The baseband circuitry 1204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1204 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1206 and to generate baseband signals for a transmit signal path of the RF circuitry 1206. Baseband processing circuity 1204 may interface with the application circuitry 1202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1206. For example, in some embodiments, the baseband circuitry 1204 may include a third generation (3G) baseband processor 1204A, a fourth generation (4G) baseband processor 1204B, a fifth generation (5G) baseband processor 1204C, or other baseband processor(s) 1204D 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 1204 (e.g., one or more of baseband processors 1204A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1206. In other embodiments, some or all of the functionality of baseband processors 1204A-D may be included in modules stored in the memory 1204G and executed via a Central Processing Unit (CPU) 1204E. 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 1204 may include Fast- Fourier Transform (FFT), precoding, or constellation mapping/demapping
functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1204 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.
[0159] In some embodiments, the baseband circuitry 1204 may include one or more audio digital signal processor(s) (DSP) 1204F. The audio DSP(s) 1204F 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 1204 and the application circuitry 1202 may be implemented together such as, for example, on a system on a chip (SOC).
[0160] In some embodiments, the baseband circuitry 1204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1204 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 1204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.
[0161] RF circuitry 1206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. The RF circuitry 1206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1208 and provide baseband signals to the baseband circuitry 1204. RF circuitry 1206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1204 and provide RF output signals to the FEM circuitry 1208 for transmission.
[0162] In some embodiments, the receive signal path of the RF circuitry 1206 may include mixer circuitry 1206A, amplifier circuitry 1206B and filter circuitry 1206C. In some embodiments, the transmit signal path of the RF circuitry 1206 may include filter circuitry 1206C and mixer circuitry 1206A. RF circuitry 1206 may also include synthesizer circuitry 1206D for synthesizing a frequency for use by the mixer circuitry 1206A of the receive signal path and the transmit signal path. In some
embodiments, the mixer circuitry 1206A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1208 based on the synthesized frequency provided by synthesizer circuitry 1206D. The amplifier circuitry 1206B may be configured to amplify the down-converted signals and the filter circuitry 1206C 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 1204 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 1206A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.
[0163] In some embodiments, the mixer circuitry 1206A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1206D to generate RF output signals for the FEM circuitry 1208. The baseband signals may be provided by the baseband circuitry 1204 and may be filtered by the filter circuitry 1206C.
[0164] In some embodiments, the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A 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 1206A of the receive signal path and the mixer circuitry 1206A 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 1206A of the receive signal path and the mixer circuitry 1206A may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may be configured for super-heterodyne operation.
[0165] 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 1206 may include analog- to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1204 may include a digital baseband interface to communicate with the RF circuitry 1206.
[0166] 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.
[0167] In some embodiments, the synthesizer circuitry 1206D 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 1206D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.
[0168] The synthesizer circuitry 1206D may be configured to synthesize an output frequency for use by the mixer circuitry 1206A of the RF circuitry 1206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1206D may be a fractional N/N+1 synthesizer.
[0169] 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 1204 or the application circuitry 1202 (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 1202.
[0170] Synthesizer circuitry 1206D of the RF circuitry 1206 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.
[0171] In some embodiments, the synthesizer circuitry 1206D 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 1206 may include an IQ/polar converter.
[0172] FEM circuitry 1208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1206 for further processing. The FEM circuitry 1208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1206 for transmission by one or more of the one or more antennas 1210. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1206, solely in the FEM circuitry 1208, or in both the RF circuitry 1206 and the FEM circuitry 1208.
[0173] In some embodiments, the FEM circuitry 1208 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 1208 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 1208 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 1206). The transmit signal path of the FEM circuitry 1208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by the RF circuitry 1206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1210).
[0174] In some embodiments, the PMC 1212 may manage power provided to the baseband circuitry 1204. In particular, the PMC 1212 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1212 may often be included when the device 1200 is capable of being powered by a battery, for example, when the device 1200 is included in a UE. The PMC 1212 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.
[0175] FIG. 12 shows the PMC 1212 coupled only with the baseband circuitry 1204. However, in other embodiments, the PMC 1212 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 1202, the RF circuitry 1206, or the FEM circuitry 1208. [0176] In some embodiments, the PMC 1212 may control, or otherwise be part of, various power saving mechanisms of the device 1200. For example, if the device 1200 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 1200 may power down for brief intervals of time and thus save power.
[0177] If there is no data traffic activity for an extended period of time, then the device 1200 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 1200 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 1200 may not receive data in this state, and in order to receive data, it transitions back to an RRC_Connected state.
[0178] 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.
[0179] Processors of the application circuitry 1202 and processors of the baseband circuitry 1204 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1204, alone or in combination, may be used to execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1202 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.
[0180] FIG. 13 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 1204 of FIG. 12 may comprise processors 1204A-1204E and a memory 1204G utilized by said processors. Each of the processors 1204A-1204E may include a memory interface, 1304A-1304E, respectively, to send/receive data to/from the memory 1204G.
[0181] The baseband circuitry 1204 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 1312 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1204), an application circuitry interface 1314 (e.g., an interface to send/receive data to/from the application circuitry 1202 of FIG. 12), an RF circuitry interface 1316 (e.g., an interface to send/receive data to/from RF circuitry 1206 of FIG. 12), a wireless hardware connectivity interface 1318 (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 1320 (e.g., an interface to send/receive power or control signals to/from the PMC 1212.
[0182] FIG. 14 is an illustration of a control plane protocol stack in accordance with some embodiments. In this embodiment, a control plane 1400 is shown as a communications protocol stack between the UE 1 101 (or alternatively, the UE 1 102), the RAN node 1 1 1 1 (or alternatively, the RAN node 1 1 12), and the MME 1 121 .
[0183] A PHY layer 1401 may transmit or receive information used by the MAC layer 1402 over one or more air interfaces. The PHY layer 1401 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as an RRC layer 1405. The PHY layer 1401 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.
[0184] The MAC layer 1402 may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, de-multiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization. [0185] An RLC layer 1403 may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer 1403 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. The RLC layer 1403 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.
[0186] A PDCP layer 1404 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).
[0187] The main services and functions of the RRC layer 1405 may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. Said MIBs and SIBs may comprise one or more information elements (lEs), which may each comprise individual data fields or data structures.
[0188] The UE 1 101 and the RAN node 1 1 1 1 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer 1401 , the MAC layer 1402, the RLC layer 1403, the PDCP layer 1404, and the RRC layer 1405. [0189] In the embodiment shown, the non-access stratum (NAS) protocols 1406 form the highest stratum of the control plane between the UE 1 101 and the MME 1 121 . The NAS protocols 1406 support the mobility of the UE 1 101 and the session management procedures to establish and maintain IP connectivity between the UE 1 101 and the P-GW 1 123.
[0190] The S1 Application Protocol (S1 -AP) layer 1415 may support the functions of the S1 interface and comprise Elementary Procedures (EPs). An EP is a unit of interaction between the RAN node 1 1 1 1 and the CN 1 120. The S1 -AP layer services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transfer.
[0191] The Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as the stream control transmission protocol/internet protocol (SCTP/IP) layer) 1414 may ensure reliable delivery of signaling messages between the RAN node 1 1 1 1 and the MME 1 121 based, in part, on the IP protocol, supported by an IP layer 1413. An L2 layer 1412 and an L1 layer 141 1 may refer to communication links (e.g., wired or wireless) used by the RAN node and the MME to exchange information.
[0192] The RAN node 1 1 1 1 and the MME 1 121 may utilize an S1 -MME interface to exchange control plane data via a protocol stack comprising the L1 layer 141 1 , the L2 layer 1412, the IP layer 1413, the SCTP layer 1414, and the S1 -AP layer 1415.
[0193] FIG. 15 is an illustration of a user plane protocol stack in accordance with some embodiments. In this embodiment, a user plane 1500 is shown as a
communications protocol stack between the UE 1 101 (or alternatively, the UE 1 102), the RAN node 1 1 1 1 (or alternatively, the RAN node 1 1 12), the S-GW 1 122, and the P-GW 1 123. The user plane 1500 may utilize at least some of the same protocol layers as the control plane 1400. For example, the UE 1 101 and the RAN node 1 1 1 1 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange user plane data via a protocol stack comprising the PHY layer 1401 , the MAC layer 1402, the RLC layer 1403, and the PDCP layer 1404.
[0194] The General Packet Radio Service (GPRS) Tunneling Protocol for the user plane (GTP-U) layer 1504 may be used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats, for example. The UDP and IP security (UDP/IP) layer 1503 may provide checksums for data integrity, port numbers for addressing different functions at the source and
destination, and encryption and authentication on the selected data flows. The RAN node 1 1 1 1 and the S-GW 1 122 may utilize an S1 -U interface to exchange user plane data via a protocol stack comprising the L1 layer 141 1 , the L2 layer 1412, the UDP/IP layer 1503, and the GTP-U layer 1504. The S-GW 1 122 and the P-GW 1 123 may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising the L1 layer 141 1 , the L2 layer 1412, the UDP/IP layer 1503, and the GTP-U layer 1504. As discussed above with respect to FIG. 14, NAS protocols support the mobility of the UE 1 101 and the session management procedures to establish and maintain IP connectivity between the UE 1 101 and the P-GW 1 123.
[0195] FIG. 16 illustrates components of a core network in accordance with some embodiments. The components of the CN 1 120 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non- transitory machine-readable storage medium). In some embodiments, Network Functions Virtualization (NFV) is utilized to virtualize any or all of the above described network node functions via executable instructions stored in one or more computer readable storage mediums (described in further detail below). A logical instantiation of the CN 1 120 may be referred to as a network slice 1601 . A logical instantiation of a portion of the CN 1 120 may be referred to as a network sub-slice 1602 (e.g., the network sub-slice 1602 is shown to include the PGW 1 123 and the PCRF 1 126).
[0196] NFV architectures and infrastructures may be used to virtualize one or more network functions, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to execute virtual or reconfigurable implementations of one or more EPC
components/functions.
[0197] FIG. 17 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. 17 shows a diagrammatic representation of hardware resources 1700 including one or more processors (or processor cores) 1710, one or more memory/storage devices 1720, and one or more communication resources 1730, each of which may be communicatively coupled via a bus 1740. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1702 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1700.
[0198] The processors 1710 (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 1712 and a processor 1714.
[0199] The memory/storage devices 1720 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1720 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.
[0200] The communication resources 1730 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1704 or one or more databases 1706 via a network 1708. For example, the communication resources 1730 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.
[0201] Instructions 1750 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1710 to perform any one or more of the methodologies discussed herein. The instructions 1750 may reside, completely or partially, within at least one of the processors 1710 (e.g., within the processor's cache memory), the memory/storage devices 1720, or any suitable combination thereof. Furthermore, any portion of the instructions 1750 may be transferred to the hardware resources 1700 from any combination of the peripheral devices 1704 or the databases 1706. Accordingly, the memory of processors 1710, the memory/storage devices 1720, the peripheral devices 1704, and the databases 1706 are examples of computer-readable and machine-readable media.
Example Embodiments
[0202] Example 1 is an apparatus for a user equipment (UE). The apparatus includes a memory and one or more baseband processors. The memory is to store access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN). The one or more baseband processors is/are to: operate in an RRC connected state, decode an RRC message that includes an indication to enter a lightly connected RRC mode, store the AS context information associated with the RRC connection in response to the indication, and transition to an RRC idle state while in the lightly connected RRC mode, wherein the RRC connection is suspended in the lightly connected RRC mode.
[0203] Example 2 is the apparatus of Example 1 , where the RRC message is an RRC connection release message, and where the RRC connection release message includes an RRC connection release information element (IE).
[0204] Example 3 is the apparatus of Example 2 or Example 1 , wherein the indication comprises an inclusion of an rrcLightConnectionlndication-r14 field in the RRC connection release IE.
[0205] Example 4 is the apparatus of Example 2 or Example 3, where the RRC connection release IE includes a release cause field, wherein the indication comprises an inclusion of an rrcLightlyConnected indication in the release cause field.
[0206] Example 5 is the apparatus of Example 1 or any of Examples 2-4, where the RRC message comprises an RRC connection reconfiguration message.
[0207] Example 6 is the apparatus of Example 5, where the RRC connection reconfiguration message includes an OtherConfig information element (IE), where the indication comprises an inclusion of a NghtConnectionConfig-r14 field in the OtherConfig IE. [0208] Example 7 is the apparatus of Example 1 or any of Examples 2-6, where the one or more baseband processors are further to decode a resume identity provided by the E-UTRAN and store the resume identity.
[0209] Example 8 is the apparatus of Example 7, where the one or more baseband processors are further to generate a request to resume the RRC
connection, wherein the request includes the stored resume identity.
[0210] Example 9 is the apparatus of Example 7 or Example 8, where the one or more baseband processors are further to generate an RRC cell update request message, where the RRC cell update request message includes the resume identity.
[0211] Example 10 is the apparatus of Example 9, where the RRC message comprises an RRC cell update confirm message.
[0212] Example 1 1 is the apparatus of Example 10, where the indication comprises an inclusion of an rrcLightlyConnected-v14 indication in a cell update release cause field of the RRC cell update confirm message.
[0213] Example 12 is the apparatus of Example 1 or any of Examples 2-1 1 , where the one or more baseband processors are further to suspend all signaling radio bearers (SRBs) and data radio bearers (DRBs).
[0214] Example 13 is the apparatus of Example 1 or any of Example 2-12, where the one or more baseband processors are further to indicate that the UE is in the lightly connected RRC mode to an upper layer.
[0215] Example 14 is an apparatus for a user equipment (UE). The apparatus includes a memory and one or more baseband processors. The memory is for storing a resume identity and for storing access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN). The one or more baseband processors are to operate in an RRC idle state while in a lightly connected RRC mode, generate an RRC connection resume request message, the RRC connection resume request including the resume identity, decode an RRC connection reject message that includes an indication that the UE should remain in the lightly connected RRC mode, maintain the stored resume identity and stored AS context information in response to the indication, and operate in the RRC idle state while in the lightly connected RRC mode. [0216] Example 15 is the apparatus of Example 14, where the indication that the UE should remain in the lightly connected RRC mode is included in an RRC connection reject information element (IE).
[0217] Example 16 is the apparatus of Example 15 or Example 16, where the indication comprises an rrcLightConnectionlndication-r14 field in the RRC connection reject IE.
[0218] Example 17 is an apparatus for an evolved Node B (eNB. The apparatus includes a memory and one or more processors. The memory is for storing a resume identity associated with a user equipment (UE) and for storing access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN). The one or more processors are to establish an S1 -U interface with a serving gateway for the UE in an RRC connected state, generate an RRC message for the UE to transition to an RRC idle state, where the RRC message includes an indication for the UE to enter a lightly connected RRC mode, store the resume identity associated with the UE and the AS context information associated with the RRC connection in response to the indication, and maintain the S1 -U interface with the serving gateway for the UE while the UE is in the lightly connected RRC mode.
[0219] Example 18 is the apparatus of Example 17, where the one or more processors are further to generate a broadcast signal, wherein the broadcast signal includes a RANPagingArealnfo information element (IE).
[0220] Example 19 is the apparatus of Example 18, where the
RANPagingArealnfo IE includes at least one of a trackAreaAllowed-r14 IE and a RANPagingAreaCode IE.
[0221] Example 20 is the apparatus of Example 19, where the
RANPagingArealnfo IE includes a RANpagingAreaCode field, wherein the
RANpagingAreaCode field identifies a RAN-based paging area within a public land mobile network (PLMN) tracking area.
[0222] Example 21 is the apparatus of Example 17 or any of Examples 18-20, where the RRC message is an RRC connection release message, an RRC connection reconfiguration message, or an RRC cell update confirm message.
[0223] Example 22 is a User Equipment (UE) configured to operate in a 3GPP network in accordance with stored UE RAN context while being suspended with light connection with an Evolved Node-B (eNB) or NR Base station (gNB or other). The UE includes hardware processing circuitry configured to: suspend/hold its UE RAN context information and other necessary connection configuration for re-use during a next connection.
[0224] Example 23 is an evolved Node B (eNB) or a similar network node (e.g., NR BS, gNB) which can support communication using suspend and resume signaling or other dedicated signaling through storing of the UE's contexts and other necessary connection configuration information.
[0225] Example 24 is the UE of Example 22 or any of the other examples described herein where the RRC connection release cause is added as a new indication within an RRC CONNECTION RELEASE message.
[0226] Example 25 is the eNB of Example 23 or any of the other examples described herein where the connection release cause is added as a new IE or indication within an RRC CELL UPDATE CONFIRM message in response to an RRC CELL UPDATE REQUEST message from Example 22 to indicate mobility out of a configured RAN paging/notification area.
[0227] Example 26 is the eNB of Example 23 or any of the other examples described herein where the RAN paging DRX information configured for the UE of Example 22 is provided as part of a RETRIEVE UE CONTEXT RESPONSE message.
[0228] Example 27 is the eNB of Example 23 or any of the other examples described herein where at least a UE suspend indication or UE release indication is provided as part of a RETRIEVE UE CONTEXT RESPONSE message.
[0229] Example 28 is the eNB of Example 23 or any of the other examples described herein where a UE-specific list of RAN paging area cells is provided as part of a RETRIEVE UE CONTEXT RESPONSE message to aid in updating the list during re-anchoring of the UE of Example 22.
[0230] Example 29 is the eNB of Example 23 or any of the other examples described herein where an indication to perform tracking area update (TAU) due to load balancing in core network is sent to the UE of Example 22 through an X2AP paging message.
[0231] Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, a non-transitory computer-readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a RAM, an EPROM, a flash drive, an optical drive, a magnetic hard drive, or another medium for storing electronic data. The eNodeB (or other base station) and UE (or other mobile station) may also include a transceiver component, a counter component, a processing component, and/or a clock component or timer component. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high-level procedural or an object-oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or an interpreted language, and combined with hardware implementations.
[0232] It should be understood that many of the functional units described in this specification may be implemented as one or more components, which is a term used to more particularly emphasize their implementation independence. For example, a component may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.
[0233] Components may also be implemented in software for execution by various types of processors. An identified component of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, a procedure, or a function.
Nevertheless, the executables of an identified component need not be physically located together, but may comprise disparate instructions stored in different locations that, when joined logically together, comprise the component and achieve the stated purpose for the component. [0234] Indeed, a component of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.
Similarly, operational data may be identified and illustrated herein within
components, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components may be passive or active, including agents operable to perform desired functions.
[0235] Reference throughout this specification to "an example" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment. Thus, appearances of the phrase "in an example" in various places throughout this specification are not necessarily all referring to the same embodiment.
[0236] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on its presentation in a common group without indications to the contrary. In addition, various embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of embodiments.
[0237] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the embodiments are not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1 . An apparatus for a user equipment (UE), the apparatus comprising: a memory to store access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN); and
one or more baseband processors to:
operate in an RRC connected state;
decode an RRC message that includes an indication to enter a lightly connected RRC mode;
store the AS context information associated with the RRC connection in response to the indication; and
transition to an RRC idle state while in the lightly connected RRC mode, wherein the RRC connection is suspended in the lightly connected RRC mode.
2. The apparatus of claim 1 , wherein the RRC message comprises an RRC connection release message, wherein the RRC connection release message includes an RRC connection release information element (IE).
3. The apparatus of claim 2, wherein the indication comprises an inclusion of an rrcLightConnectionlndication-r14 field in the RRC connection release IE.
4. The apparatus of claim 2, wherein the RRC connection release IE includes a release cause field, wherein the indication comprises an inclusion of an rrcLightlyConnected indication in the release cause field.
5. The apparatus of claim 1 , wherein the RRC message comprises an RRC connection reconfiguration message.
6. The apparatus of claim 5, wherein the RRC connection reconfiguration message includes an OtherConfig information element (IE), wherein the indication comprises an inclusion of a NghtConnectionConfig-r14 field in the OtherConfig IE.
7. The apparatus of claim 1 , wherein the one or more baseband processors are further to:
decode a resume identity provided by the E-UTRAN; and
store the resume identity.
8. The apparatus of claim 7, wherein the one or more baseband processors are further to:
generate a request to resume the RRC connection, wherein the request includes the stored resume identity.
9. The apparatus of claim 7, wherein the one or more baseband processors are further to:
generate an RRC cell update request message, wherein the RRC cell update request message includes the resume identity.
10. The apparatus of claim 9, wherein the RRC message comprises an RRC cell update confirm message.
1 1 . The apparatus of claim 10, wherein the indication comprises an inclusion of an rrcLightlyConnected-v14 indication in a cell update release cause field of the RRC cell update confirm message.
12. The apparatus of claim 1 , wherein the one or more baseband processors are further to:
suspend all signaling radio bearers (SRBs) and data radio bearers (DRBs).
13. The apparatus of claim 1 , wherein the one or more baseband processors are further to:
indicate that the UE is in the lightly connected RRC mode to an upper layer.
14. An apparatus for a user equipment (UE), the apparatus comprising: a memory to store a resume identity and to store access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN); and
one or more baseband processors to:
operate in an RRC idle state while in a lightly connected RRC mode; generate an RRC connection resume request message, the RRC connection resume request including the resume identity;
decode an RRC connection reject message that includes an indication that the UE should remain in the lightly connected RRC mode;
maintain the stored resume identity and stored AS context information in response to the indication; and
operate in the RRC idle state while in the lightly connected RRC mode.
15. The apparatus of claim 14, wherein the indication that the UE should remain in the lightly connected RRC mode is included in an RRC connection reject information element (IE).
16. The apparatus of claim 15, wherein the indication comprises an rrcLightConnectionlndication-r14 field in the RRC connection reject IE.
17. An apparatus for an evolved Node B (eNB), the apparatus comprising: a memory to store a resume identity associated with a user equipment (UE) and to store access stratum (AS) context information associated with a radio resource control (RRC) connection with an evolved universal terrestrial access network (E-UTRAN); and
one or more processors to:
establish an S1 -U interface with a serving gateway for the UE in an RRC connected state;
generate an RRC message for the UE to transition to an RRC idle state, wherein the RRC message includes an indication for the UE to enter a lightly connected RRC mode;
store the resume identity associated with the UE and the AS context information associated with the RRC connection in response to the indication; and
maintain the S1 -U interface with the serving gateway for the UE while the UE is in the lightly connected RRC mode.
18. The apparatus of claim 17, wherein the one or more processors are further to:
generate a broadcast signal, wherein the broadcast signal includes a
RANPagingArealnfo information element (IE).
19. The apparatus of claim 18, wherein the RANPagingArealnfo IE includes at least one of a trackAreaAllowed-r14 IE and a RANPagingAreaCode IE.
20. The apparatus of claim 19, wherein the RANPagingArealnfo IE includes a RANpagingAreaCode field, wherein the RANpagingAreaCode field identifies a RAN-based paging area within a public land mobile network (PLMN) tracking area.
21 . The apparatus of claim 17, wherein the RRC message comprises at least one of an RRC connection release message, an RRC connection
reconfiguration message, and an RRC cell update confirm message.
PCT/US2017/044658 2016-09-26 2017-07-31 Apparatuses for configuration of a light connection WO2018057120A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201780054776.3A CN109691222B (en) 2016-09-26 2017-07-31 Device for configuring lightweight connections

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662399969P 2016-09-26 2016-09-26
US62/399,969 2016-09-26

Publications (1)

Publication Number Publication Date
WO2018057120A1 true WO2018057120A1 (en) 2018-03-29

Family

ID=59579941

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/044658 WO2018057120A1 (en) 2016-09-26 2017-07-31 Apparatuses for configuration of a light connection

Country Status (2)

Country Link
CN (1) CN109691222B (en)
WO (1) WO2018057120A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019223774A1 (en) * 2018-05-24 2019-11-28 Oppo广东移动通信有限公司 Method and device for improving reliability of paging , and computer storage medium
WO2020007149A1 (en) * 2018-07-06 2020-01-09 华为技术有限公司 Data transmission method and device
CN112088575A (en) * 2018-05-07 2020-12-15 瑞典爱立信有限公司 Method for handling periodic radio access network notification area (RNA) update configuration upon rejection
CN112514528A (en) * 2018-08-03 2021-03-16 瑞典爱立信有限公司 User plane optimization for 5G cellular internet of things
US20210219264A1 (en) * 2018-05-18 2021-07-15 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for network scheduled ue transition to cm-connected/rrc connected mode in 5gs
CN114449680A (en) * 2020-11-06 2022-05-06 维沃移动通信有限公司 Connection state establishing method, terminal, core network function and access network equipment
WO2022116115A1 (en) * 2020-12-03 2022-06-09 Oppo广东移动通信有限公司 Uplink logical channel multiplexing method, terminal device, and network device

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110475387B (en) * 2018-05-11 2021-12-24 展讯通信（上海）有限公司 RRC connection recovery method, base station, terminal and readable medium

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"UE CONTEXT RELEASE REQUEST", 3GPP TS 36.413
HUAWEI ET AL: "Procedure for transition between normal RRC connection and light RRC connection", vol. RAN WG2, no. Gothenburg, Sweden; 20160822 - 20160826, 21 August 2016 (2016-08-21), pages 1 - 2, XP051126837, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN2/Docs/> [retrieved on 20160821] *
INTEL CORPORATION: "Benefits of Light Connection over Suspend-Resume procedure", vol. RAN WG3, no. Goteburg, Sweden; 20160822 - 20160826, 13 August 2016 (2016-08-13), pages 1 - 9, XP051134826, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_93/Docs/> [retrieved on 20160813] *
INTEL CORPORATION: "Benefits of RAN based paging (light connection)", vol. RAN WG3, no. Goteburg, Sweden; 20160822 - 20160826, 21 August 2016 (2016-08-21), pages 1 - 9, XP051127439, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN3/Docs/> [retrieved on 20160821] *
NOKIA ET AL: "NB-IoT - Further details on RRC suspend and resume", vol. RAN WG2, no. Dubrovnik, Croatia; 20160411 - 20160415, 1 April 2016 (2016-04-01), pages 1 - 3, XP051082200, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_93bis/Docs/> [retrieved on 20160401] *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112088575B (en) * 2018-05-07 2024-04-30 瑞典爱立信有限公司 Method for handling periodic radio access network notification area (RNA) update configuration at rejection
CN112088575A (en) * 2018-05-07 2020-12-15 瑞典爱立信有限公司 Method for handling periodic radio access network notification area (RNA) update configuration upon rejection
US11889577B2 (en) 2018-05-07 2024-01-30 Telefonaktiebolaget Lm Ericsson (Publ) Methods for handling periodic radio access network notification area (RNA) update configuration upon reject
US11533708B2 (en) * 2018-05-18 2022-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for network scheduled UE transition to CM-connected/RRC connected mode in 5GS
US20210219264A1 (en) * 2018-05-18 2021-07-15 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for network scheduled ue transition to cm-connected/rrc connected mode in 5gs
WO2019223774A1 (en) * 2018-05-24 2019-11-28 Oppo广东移动通信有限公司 Method and device for improving reliability of paging , and computer storage medium
US11356974B2 (en) 2018-05-24 2022-06-07 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method and device for improving reliabtility of paging
US11778681B2 (en) 2018-07-06 2023-10-03 Huawei Technologies Co., Ltd. Data transmission method and apparatus
WO2020007149A1 (en) * 2018-07-06 2020-01-09 华为技术有限公司 Data transmission method and device
CN112514528A (en) * 2018-08-03 2021-03-16 瑞典爱立信有限公司 User plane optimization for 5G cellular internet of things
CN112514528B (en) * 2018-08-03 2024-05-14 瑞典爱立信有限公司 User plane optimization for 5G cellular Internet of things
CN114449680A (en) * 2020-11-06 2022-05-06 维沃移动通信有限公司 Connection state establishing method, terminal, core network function and access network equipment
WO2022116115A1 (en) * 2020-12-03 2022-06-09 Oppo广东移动通信有限公司 Uplink logical channel multiplexing method, terminal device, and network device

Also Published As

Publication number Publication date
CN109691222A (en) 2019-04-26
CN109691222B (en) 2024-02-02

Similar Documents

Publication Publication Date Title
US11871291B2 (en) Data forwarding tunnel establishment between two user plane functions in fifth generation
EP3482602B1 (en) Systems, methods and devices for control-user plane separation for 5g radio access networks
US10749587B2 (en) Systems, methods and devices for using S-measure with new radio
US20220361064A1 (en) Devices and methods for dynamic rach
US11122453B2 (en) Systems, methods and devices for measurement configuration by a secondary node in EN-DC
WO2018031343A1 (en) Methods for layer 2 relaying optimizations
CN109691222B (en) Device for configuring lightweight connections
US10979958B2 (en) Systems, methods, and apparatuses for providing and obtaining scheduling information for SIB1-BR during handover
WO2018085049A1 (en) Systems, methods, and devices for make-before-break handover and secondary cell group reconfiguration
EP3620028B1 (en) Unifying split bearers in lte interworking
US11076314B2 (en) Systems, methods and devices for congestion control for transport of user data via a control plane
US11812414B2 (en) Interruption and delay for V2X sidelink carrier aggregation
US11265884B2 (en) Systems, methods and devices for uplink bearer and access category mapping
US11838839B2 (en) V2X policy and parameters provisioning to user equipment by a policy and control function
WO2019032532A1 (en) New radio registration management
US11038662B2 (en) Interruption for SCell activation and deactivation with short transmission time interval
WO2018031802A1 (en) Ran-based paging optimizations
EP3646637B1 (en) Improved handling of timer expiry for mt csfb
US10455405B2 (en) Telephone call procedures for power efficient mobile terminating packet switched services
EP3462770A1 (en) Methods and apparatus for multiple tnl associations between ran and amf for virtualized deployments
WO2018031395A1 (en) Common uplink message for user equipment initiated scenarios
WO2018140608A1 (en) eLWA/LWIP ACTIONS UPON WLAN DISCONNECT

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17751197

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17751197

Country of ref document: EP

Kind code of ref document: A1