US20220191823A1 - Communication system - Google Patents
Communication system Download PDFInfo
- Publication number
- US20220191823A1 US20220191823A1 US17/689,151 US202217689151A US2022191823A1 US 20220191823 A1 US20220191823 A1 US 20220191823A1 US 202217689151 A US202217689151 A US 202217689151A US 2022191823 A1 US2022191823 A1 US 2022191823A1
- Authority
- US
- United States
- Prior art keywords
- base station
- mobile device
- mme
- paging
- context
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
- 238000004891 communication Methods 0.000 title abstract description 117
- 238000000034 method Methods 0.000 claims abstract description 70
- 230000008569 process Effects 0.000 claims description 8
- 230000000977 initiatory effect Effects 0.000 abstract description 13
- 239000002585 base Substances 0.000 description 358
- 230000011664 signaling Effects 0.000 description 27
- 238000007726 management method Methods 0.000 description 23
- 230000004044 response Effects 0.000 description 18
- 230000005540 biological transmission Effects 0.000 description 13
- 101150074586 RAN3 gene Proteins 0.000 description 12
- 238000010586 diagram Methods 0.000 description 12
- 230000007704 transition Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000009286 beneficial effect Effects 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 4
- 238000010295 mobile communication Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 238000013500 data storage Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000009118 appropriate response Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000002349 favourable effect Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 239000000243 solution Substances 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 101100465000 Mus musculus Prag1 gene Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 239000003637 basic solution Substances 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
- H04W68/08—User notification, e.g. alerting and paging, for incoming communication, change of service or the like using multi-step notification by increasing the notification area
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
- H04W68/005—Transmission of information for alerting of incoming communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
- H04W68/02—Arrangements for increasing efficiency of notification or paging channel
-
- 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
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0055—Transmission or use of information for re-establishing the radio link
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/24—Reselection being triggered by specific parameters
- H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Definitions
- the present invention relates to a communication system.
- the invention has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including LTE-Advanced and Next Generation or 5G networks).
- 3GPP 3rd Generation Partnership Project
- the invention has particular although not exclusive relevance to managing connection states for communication devices.
- 5G and ‘new radio’ (NR) refer to an evolving communication technology that is expected to support a variety of applications and services.
- 5G networks are described in, for example, the ‘NGMN 5G White Paper’ V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https://www.ngmn.org/5g-white-paper.html.
- NNMN Next Generation Mobile Networks
- a NodeB (or an eNB in LTE, gNB in 5G) is the base station via which communication devices (user equipment or ‘UE’) connect to a core network and communicate to other communication devices or remote servers.
- UE user equipment
- the core network i.e. the EPC in case of LTE
- Communication devices might be, for example, mobile communication devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop/tablet computers, web browsers, e-book readers and/or the like. Such mobile (or even generally stationary) devices are typically operated by a user.
- 3GPP standards also make it possible to connect so-called ‘Internet of Things’ (IoT) devices (e.g. Narrow-Band IoT (NB-IoT) devices) to the network, which typically comprise automated equipment, such as various measuring equipment, telemetry equipment, monitoring systems, tracking and tracing devices, in-vehicle safety systems, vehicle maintenance systems, road sensors, digital billboards, point of sale (POS) terminals, remote control systems and the like.
- IoT Internet of Things
- NB-IoT Narrow-Band IoT
- POS point of sale
- the Internet of Things is a network of devices (or “things”) equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enables these devices to collect and exchange data with each other and with other communication devices.
- IoT devices are sometimes also referred to as Machine-Type Communication (MTC) communication devices or Machine-to-Machine (M2M) communication devices.
- MTC Machine-Type Communication
- M2M Machine-to-Machine
- the present application refers to mobile devices in the description but it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
- RRC Radio Resource Control
- 3GPP TS 36.331 V14.0.0 Radio Resource Control
- RRC handles the control plane signalling of Layer 3 between mobile telephones and the radio access network, and includes, amongst other things, functions for broadcasting system information, paging, connection establishment and release, radio bearer establishment, reconfiguration and release, mobility procedures, and power control.
- RRC Radio Resource Control
- a mobile device may operate either in an ‘RRC idle mode’ (in which no data communication takes place) or an ‘RRC connected mode’ (in which data communication may take place between the mobile device and its serving base station).
- an idle mobile device whilst in the RRC idle mode, mobile devices are programmed to select a ‘serving’ cell, having a good quality signal, to camp on so that when new data is to be transmitted to/from these mobile devices, they can benefit from favourable signal conditions.
- an idle mobile device detects a new cell with better signal quality than the current serving cell, e.g. due to the mobile device changing its location, the mobile device can perform a so-called cell reselection procedure.
- an idle mode mobile device does not inform the network about the selected new cell as long as this cell is within the same ‘tracking area’ (i.e. a larger geographic area comprising a pre-defined set of cells), because the radio network transmits system information and UE specific paging messages within the whole tracking area thus making it possible to initiate communication to/from the mobile device regardless of the current cell it camps on.
- the mobile devices In order to benefit from the lowest energy consumption and to free up valuable system resources, the mobile devices return to the RRC idle mode whenever possible and perform cell reselections (instead of handovers) as long as they remain within the same tracking area.
- the base station controls the transition between the various operating modes for each mobile device within its cell(s). Since the setting up and termination of an RRC connection between the base station and the mobile device requires exchanging of signalling messages and hence utilises valuable system resources, and also takes some time to complete, the transition from connected to idle mode is allowed under specific circumstances as defined in 3GPP TS 36.331. For example, the serving base station might instruct a mobile device to enter the RRC idle mode only after it has confirmed that there is no more data to be transmitted to/from the particular mobile device (e.g. both uplink (UL) and downlink (DL) buffers are empty).
- UL uplink
- DL downlink
- each mobile device When it registers its current location (e.g. cell) with the core network, each mobile device also has an associated ‘S1’ connection between its serving base station and the core network.
- the S1 connection is either in a so-called ‘ECM-IDLE’ mode (when the mobile device is in RRC idle mode) or in an ‘ECM-CONNECTED’ mode (when the mobile device is in RRC connected mode).
- the S1 connection is used for transferring data (control and user data) between the mobile device and the core network (and beyond) and it is maintained as long as the mobile device remains in the RRC connected mode.
- the network When the network has data to send to an RRC idle mobile device, it triggers an appropriate paging procedure in the last known area (tracking/paging area) of the mobile device, which causes the base stations within that area to broadcast appropriate paging messages in their cells requesting that particular mobile device to enter the RRC connected state.
- a previously idle mobile telephone has data to send again (or it has been paged for receiving downlink data)
- it initiates a so called RRC connection establishment procedure by sending an appropriately formatted RRC connection request message to the base station (following a so-called Random Access Procedure which ensures that the lower layers, and in particular the Media Access Control (MAC) layer, are set up for communication with the base station).
- Random Access Procedure which ensures that the lower layers, and in particular the Media Access Control (MAC) layer, are set up for communication with the base station.
- a mobile device may also operate in a new RRC state, or new radio state, referred to as a ‘light-connected’ (LC) state.
- LC light-connected
- the core network maintains both its control-plane and user-plane connection even after the mobile device has no more data to send or receive (and hence it is normally configured to enter the RRC idle mode).
- the mobile device is seen as operating in idle mode from the radio access network's (base station's) point of view, it may still be seen as being connected from the core network's point of view.
- an LC state capable mobile device can be configured to resume its existing RRC connection with the current serving base station whenever needed and then return to a more power efficient mode of operation until it has data to send/receive again.
- the mobile device can resume its RRC connection by sending to its current base station information (e.g. a resume ID) identifying the connection to be resumed.
- a resume ID e.g. a resume ID
- the concept of a so-called anchor base station is being considered by 3GPP.
- the anchor base station is a base station responsible for storing UE Access Stratum (AS) context, caching the mobile device's user data (UE context) and for providing the user data to other base stations as needed while terminating S1.
- AS UE Access Stratum
- the anchor base station may be the first (or previous) base station that the mobile device registered with in a particular tracking area (or other pre-defined area).
- the new base station can contact the anchor base station and retrieve the UE context along with the cached user data based on information provided by the mobile device (e.g. resume ID and/or the like). Since in the LC state the S1 connection is maintained, beneficially, the new base station can avoid having to contact the core network and/or establish a new S1 connection for the mobile device (although the new base station might need to switch the S1 connection from the anchor/previous base station to the new base station).
- the anchor base station concept is illustrated in FIG. 8 which is reproduced from 3GPP draft no. R3-160655.
- the current agreement in 3GPP is that the base station maintains the S1 connection while the mobile device is lightly connected and the base station is responsible for RAN paging (within an appropriate paging/tracking area configured by the base station) when it receives the downlink data from core network.
- the LC state mobile device notifies the network when it moves out of its configured RAN based paging area, in which case the network can decide whether to keep the mobile device in LC mode or suspend the mobile device (e.g. request it to enter RRC idle mode).
- preferred example embodiments of the present invention aim to provide methods and apparatus which address or at least partially deal with one or more of the above issues whilst still allowing mobile devices to maintain a light connection with the network.
- the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to receive, from a core network node, downlink data for a communication device; attempt to initiate communication with the communication device; and control the transceiver to send to the core network node, when the communication device does not respond to said attempt to initiate communication, a message to request initiation of a paging procedure for the communication device.
- the invention provides core network apparatus for a communication network, the core network apparatus comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to send, to a base station, downlink data for a communication device; control the transceiver to receive from the base station, when the communication device does not respond to an attempt by the base station to initiate communication, a message to request initiation of a paging procedure for the communication device; and initiate a paging procedure for the communication device based on said message.
- the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to send a notification to a core network node indicating that at least one core network operation is not possible (or banned) for a given communication device.
- the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: maintain information identifying at least one communication device, for which the base station operates as an anchor base station, in association with respective context information for each communication device for which the base station operates as an anchor base station; and control the transceiver to provide to another base station at least one identifier to identify at least one respective communication device for which the base station operates as an anchor base station.
- the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to receive from at least one other base station at least one identifier to identify at least one communication device for which the at least one other base station operates as an anchor base station; and fetch, from the at least one other base station, context information for each communication device for which the at least one other base station operates as an anchor base station based on said at least one identifier.
- the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to, receive from a core network node, a message indicating that data forwarding from another base station is to happen for a communication device, together with at least one of: an identifier, associated with that communication device, for use in fetching a context relating to that communication device from the other base station; information identifying the communication device at the core network node over an S1 interface (e.g. ‘MME UE S1AP ID’); information identifying the other base station (e.g.
- an ‘anchor eNB ID’ a tracking area code (TAC) associated with the other base station
- TAC tracking area code
- GUMMEI globally unique ID
- the core network node currently serving the communication device information identifying at least one cell identifier for at least one cell to which a handover of the communication device is prohibited; and at least one other parameter acquired by the core network node in a previously handled handover request relating to the communication device; and control the transceiver to receive data forwarded by the other base station accordingly.
- aspects of the invention extend to corresponding systems, methods, and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.
- FIG. 1 illustrates schematically a cellular telecommunication system to which example embodiments of the invention may be applied;
- FIG. 2 is a block diagram of a mobile device forming part of the system shown in FIG. 1 ;
- FIG. 3 is a block diagram of a base station forming part of the system shown in FIG. 1 ;
- FIG. 4 is a block diagram of a mobility management entity forming part of the system shown in FIG. 1 ;
- FIG. 5 is a timing diagram illustrating an exemplary way in which example embodiments of the invention can be implemented in the system of FIG. 1 ;
- FIG. 6 is a timing diagram illustrating an exemplary way in which example embodiments of the invention can be implemented in the system of FIG. 1 ;
- FIG. 7 is a timing diagram illustrating an exemplary way in which example embodiments of the invention can be implemented in the system of FIG. 1 ;
- FIG. 8 illustrates schematically the anchor base station concept.
- FIG. 1 schematically illustrates a telecommunications network 1 in which mobile devices 3 , mobile telephones, and other communication devices (e.g. IoT devices) can communicate with each other via E-UTRAN base stations 5 and a core network 7 using an E-UTRA radio access technology (RAT).
- RAT E-UTRA radio access technology
- Each base station 5 operates one or more associated cell.
- the base station 5 b operates ‘Cell # 1 ’ and the base station 5 c operates ‘Cell # 2 ’.
- base station 5 a will also typically operate one or more cells. It will also be appreciated that in some scenarios the ‘old’ base station 5 a and the ‘anchor’ base station 5 b might be the same.
- Communication devices may connect to either cell (depending on their location and possibly on other factors, e.g. signal conditions, subscription data, capability, and/or the like) by establishing a radio resource control (RRC) connection with the appropriate base station 5 operating that cell.
- RRC radio resource control
- the mobile device 3 is located in an area where the cells operated by the base stations 5 b and 5 c partially overlap.
- the mobile device 3 when operating in RRC idle mode (not sending/receiving data), the mobile device 3 camps on the cell having the best signal quality, and when in RRC active mode, the mobile device 3 communicates data via that cell (using e.g. the ‘Uu’ air interface).
- the IoT device 3 ′ camps on Cell # 2 (when in RRC idle mode) and communicates via the base station 5 c (when in RRC active mode).
- the serving base station 5 When the mobile device 3 (IoT device 3 ′) first registers with the network (via one of the base stations 5 ), its serving base station 5 also establishes an associated S1 connection for relaying communications (user and control data) between the serving base station 5 and the core network 7 .
- the base stations 5 are connected to the core network 7 via an S1 interface and to each other via an X2 interface (either directly, or via an X2 gateway).
- the core network 7 includes, amongst others, a mobility management entity (MME) 9 , a serving gateway (S-GW) 10 , and a packet data network gateway (P-GW) 11 for providing a connection between the base stations 5 and other networks (such as the Internet) and/or servers hosted outside the core network 7 .
- MME mobility management entity
- S-GW serving gateway
- P-GW packet data network gateway
- the MME 9 is the network node responsible for keeping track of the locations of the mobile communication devices (mobile devices and IoT devices alike) within the telecommunications network 1 especially when a UE is RRC_IDLE mode.
- the MME 9 stores an identifier of the mobile communication devices' last known cell (or tracking area) so that they can be notified when there is an incoming (voice or data) call for them and that a communication path is set up via the base station 5 currently serving the particular mobile communication device.
- the mobile device 3 connects to the network periodically (e.g. whenever one of its applications needs to communicate with the network) for sending data to a remote endpoint (e.g. a server or another communication device).
- a remote endpoint e.g. a server or another communication device.
- the mobile device 3 is configured to operate in a light connected (LC) mode in which the network maintains an associated S1 connection even when the mobile device 3 is operating in an idle mode from the RAN's point of view. Therefore, between its periodic re-connections, the mobile device 3 effectively enters an idle (or ‘suspended’) mode and thus avoids performing handovers as long as it remains within an area configured by its anchor base station.
- LC light connected
- the serving base station 5 is responsible for configuring an appropriate RAN based paging area for the mobile device 3 (e.g. by providing a list of cells and/or paging area IDs to the mobile device 3 ).
- the RAN based paging area may be configured as one or more cells from the same or different base stations 5 .
- the RAN based paging area may be a tracking area.
- the mobile device 3 previously connected to the base station 5 b (via Cell # 1 ) and thus the base station 5 b (acting as the anchor base station for the mobile device 3 ) maintains an associated UE context and terminates S1.
- the anchor base station may be a different base station, e.g. the old base station 5 a .
- the anchor base station 5 b configures the mobile device 3 with a RAN paging area that includes the anchor base station's own cell (Cell # 1 ) and any cells operated by base station 5 a.
- the mobile device 3 is now reachable via the base station 5 c (via Cell # 2 ), e.g. due to a change in signal conditions in Cell # 1 and/or movement of the mobile device 3 .
- the mobile device 3 currently has no active connections with the radio access network (the base stations 5 ), thus it is configured to perform cell reselection when it moves to Cell # 2 (without informing the network).
- the mobile device 3 is still seen as connected (ECM-CONNECTED) from the core network's 7 (MME 9 ) point of view even after the mobile device 3 has, in effect, entered an idle mode from the perspective of the base stations (and hence the mobile device 3 does not have an active data connection with its base station 5 ). Accordingly, when there is downlink data to send, the MME 9 does not initiate paging, for a mobile device 3 in the LC state/mode (e.g. throughout an associated tracking/paging area) because the MME 9 assumes that the mobile device 3 still has an active connection with its serving base station 5 (in this example, the anchor base station 5 b ).
- the MME 9 starts sending the downlink data to the anchor base station 5 b .
- the anchor base station 5 b starts appropriate procedures for (RAN based) paging of the mobile device 3 within the paging area appropriate for that mobile device 3 .
- the RAN based paging indicates to the mobile device 3 that it needs to resume its RRC connection (re-connect) via an appropriate base station for receiving downlink data.
- the anchor base station 5 b stores the downlink data from the MME 9 (in case of control-planes signalling or data) or from the S-GW 10 (in case of user-plane data) in its cache (memory).
- the base station 5 b decides which cells to page when it receives the downlink data. If necessary, the anchor base station 5 b may send appropriate X2 paging signalling to its neighbour base station(s) in order to reach the mobile device 3 via other than its own cell(s). However, as the mobile device 3 has moved in the meantime and it is now camping on Cell # 2 , it might not be able to receive (or respond to) the paging signalling.
- the base station 5 b requests the MME 9 to initiate S1 based (legacy) paging procedures.
- the MME 9 needs to move the mobile device 3 from connected state to idle state (e.g. ECM-CONNECTED to ECM-IDLE).
- the base station 5 b is configured to use legacy signalling in order to tear down the existing S1 connection.
- the base station 5 b may be configured to send an appropriately formatted message (such as a ‘UE Context Release Request’ and/or the like) including information indicating that S1 based paging is required for the mobile device 3 in its last recorded tracking area.
- the base station's request allows the MME 9 to move the mobile device 3 to idle state (ECM-IDLE) allowing the MME 9 to trigger a legacy S1-based paging.
- the message from the base station 5 b may also indicate that the paging is requested without triggering a release of the mobile device's 3 bearer via the S-GW 10 (i.e. unlike the conventional procedure upon receipt of a UE Context Release Request for a UE in legacy RRC idle state).
- the MME 9 triggers S1 based paging and waits for an appropriate response from the mobile device 3 .
- the mobile device 3 responds to the MME's paging request via the new base station 5 c by performing appropriate RRC and S1 connection setup procedures (via the new base station 5 c /Cell # 2 ). This is possible when a new base station 5 does not know or understand as to how to locate the associated UE context using the UE identifier (e.g. Resume ID) received from the mobile device 3 .
- the MME 9 registers Cell # 2 as the mobile device's 3 new location.
- the MME 9 When the new base station 5 c establishes a new RRC and S1 connection for the mobile device 3 , the MME 9 is beneficially able to indicate to the new base station 5 c that data forwarding from the old (anchor) base station 5 b is to happen. In this example, the MME 9 requests data forwarding in its response to the anchor base station 5 b (e.g. a ‘UE Context Release Response’ and/or the like).
- the anchor base station 5 b e.g. a ‘UE Context Release Response’ and/or the like.
- the MME 9 may also be configured to monitor (preceding) handovers performed by the mobile device 3 and obtain context information and other parameters relating to the mobile device 3 . Therefore, the MME's 9 message to the new base station 5 c may also include information (previously obtained or held by the MME 9 ) that may be used by the new base station 5 c to fetch the UE context from the anchor base station 5 b . Similarly, the MME 9 is able to provide information relevant to the anchor base station 5 b in order to perform data forwarding.
- the MME 9 can follow appropriate legacy procedures in order to release the UE context (held at the anchor base station 5 b and the MME 9 ) and trigger a release of the access bearer towards the S-GW 10 .
- the mobile device 3 is considered to be in RRC idle state (instead of LC state) and the mobile device 3 is able to communicate with the network again by moving to RRC connected state, e.g. by triggering an appropriate RRC connection establishment operation (instead of a simple resume operation).
- the base stations 5 may be configured to notify the MME 9 that certain operations are not possible for the mobile device 3 because it is currently operating in LC state.
- MME operations may include, for example, load balancing, TAU required, Power Saving Mode, MT CSFB, and/or the like.
- the serving/anchor base station 5 (in this example, the base station 5 b ) is configured to send, to the MME 9 , information identifying whether the mobile device 3 is operating in LC state and/or whether certain MME operations are to be avoided (or banned). Based on the received information, the MME 9 takes different handling for certain operations such as CSFB or will not release S1 with load balancing TAU required. As a result, when overloaded, the MME 9 may be configured to release S1 connections that do not belong to those UEs that are in LIGHT-CONNECTED mode.
- the above procedures allow the MME 9 to avoid performing and/or requesting procedures that would otherwise be inappropriate for the current operating state of the mobile device 3 .
- the base stations 5 of this system may also be configured to exchange information with each other relating to the mobile devices 3 (users) for which they act as an anchor base station.
- the base stations 5 may be configured to provide, to their neighbour base station(s) over the X2 interface, information identifying any UE AS context, security data, suspended bearers at that particular base station 5 , and/or the mobile devices 3 associated with such suspended bearers.
- neighbour base stations 5 are beneficially able to pre-fetch the associated UE context for bearers suspended at another (anchor) base station. This allows them to minimise latency at the time of handover (or idle mode mobility) of a particular mobile device 3 to a cell operated by the new (neighbour) base station 5 (because the UE context is already available locally at the new base station 5 ). This may be useful for ultra-reliable low latency communications.
- this network it is possible to provide better service continuity and more efficient resource usage at user equipment (the mobile device and/or the IoT device), base stations, and the MME when the user equipment (which may be operating in LC state) moves to and/or camps on a new cell operated by a different base station.
- FIG. 2 is a block diagram illustrating the main components of the mobile device 3 shown in FIG. 1 (e.g. a mobile telephone or an IoT device).
- the mobile device 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5 via one or more antenna 33 .
- the mobile device 3 has a controller 37 to control the operation of the mobile device 3 .
- the controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31 .
- the mobile device 3 might of course have all the usual functionality of a conventional mobile telephone (such as a user interface 35 ) and this may be provided by any one or any combination of hardware, software and firmware, as appropriate.
- Software may be pre-installed in the memory 39 and/or may be downloaded via the telecommunications network or from a removable data storage device (RMD), for example.
- RMD removable data storage device
- the controller 37 is configured to control overall operation of the mobile device 3 by, in this example, program instructions or software instructions stored within the memory 39 .
- these software instructions include, among other things, an operating system 41 , a communications control module 43 , a UE state module 45 , an RRC module 46 , and a NAS module 49 .
- the communications control module 43 is operable to control the communication between the mobile device 3 and its serving base station 5 (and other communication devices connected to the serving base station 5 , such as further mobile devices, IoT devices, core network nodes, etc.).
- the UE state module 45 is responsible for managing an operating state of the mobile device 3 (e.g. by obtaining appropriate configuration (such as state transition timer(s), information identifying a RAN paging area) and information identifying UE location, cell information, etc.) and control the other modules (e.g. the RRC module 46 and the NAS module 49 ) according to the current operating state of the mobile device 3 .
- the RRC module 46 is operable to generate, send and receive signalling messages formatted according to the RRC standard. For example, such messages are exchanged between the mobile device 3 and its serving base station 5 .
- the RRC messages may include, for example, messages relating to establishing/resuming an RRC connection with an appropriate base station 5 .
- the NAS module 49 is operable to generate, send and receive signalling messages formatted according to the NAS standard. For example, such messages are exchanged between the mobile device 3 and the MME 9 (via the serving base station 5 , using the RRC module 46 ).
- the NAS messages may include, for example, messages relating to registering and/or updating a tracking area (or cell) where the mobile device 3 is currently located.
- FIG. 3 is a block diagram illustrating the main components of a base station 5 shown in FIG. 1 .
- the base station 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from user equipment (such as the mobile device 3 /IoT device 3 ′) via one or more antenna 53 , a core network interface 55 (e.g. an S1 interface, NG-C interface, and/or the like) for transmitting signals to and for receiving signals from the core network 7 , and a base station interface 56 (e.g. an X2 interface, Xn interface, and/or the like) for transmitting signals to and for receiving signals from neighbouring base stations.
- the base station 5 has a controller 57 to control the operation of the base station 5 .
- the controller 57 is associated with a memory 59 .
- the base station 5 will of course have all the usual functionality of a cellular telephone network base station and this may be provided by any one or any combination of hardware, software and firmware, as appropriate.
- Software may be pre-installed in the memory 59 and/or may be downloaded via the telecommunications network 1 or from a removable data storage device (RMD), for example.
- the controller 57 is configured to control the overall operation of the base station 5 by, in this example, program instructions or software instructions stored within the memory 59 .
- these software instructions include, among other things, an operating system 61 , a communications control module 63 , a UE state module 65 , an RRC module 66 , an X2 module 67 , and an S1AP module 68 .
- the communications control module 63 is operable to control the communication between the base station 5 and user equipment (mobile device 3 /IoT device 3 ′) and other network entities that are connected to the base station 5 .
- the communications control module 63 also controls the separate flows of downlink user traffic (via associated data radio bearers) and control data to be transmitted to the communication devices associated with this base station 5 including, for example, control data for managing operation of the mobile device 3 and/or the IoT device 3 ′.
- the UE state module 65 is responsible for managing and monitoring the operating states of mobile devices 3 served by the base station 5 (e.g. by generating and sending appropriate configuration, such as state transition timer(s), information identifying a RAN paging area, etc.) and, when appropriate, providing information on the current operating state of a particular mobile device 3 to other nodes (e.g. the MME 9 ).
- the RRC module 66 is operable to generate, send and receive signalling messages formatted according to the RRC standard. For example, such messages are exchanged between the base station 5 and the mobile device 3 (and other user equipment within the cell of the base station 5 ).
- the RRC messages may include, for example, messages relating to establishing/resuming an RRC connection for a particular mobile device 3 .
- the X2 module 67 is operable to generate, send and receive signalling messages (X2/Xn messages) formatted according to the X2AP (or XnAP) standard.
- the X2/Xn messages may include, for example, messages relating to paging a mobile device 3 , data forwarding, transferring/fetching of UE context (and other information relating to the mobile device 3 ) between neighbouring base stations.
- the S1AP module 68 is operable to generate, send and receive signalling messages formatted according to the S1AP (or NG-C AP) standard. For example, such messages are exchanged between the base station 5 and the mobility management entity (MME) 9 .
- the S1AP messages may include, for example, messages relating to registering the location and/or operating state (e.g. LC) of user equipment in a cell of the base station and/or associated responses.
- FIG. 4 is a block diagram illustrating the main components of the mobility management entity (MME) 9 shown in FIG. 1 .
- the mobility management entity 9 has a transceiver circuit 71 for transmitting signals to and for receiving signals from the base stations 5 (and/or communication devices connected to the base stations 5 ) via a base station interface 75 (e.g. an S1 interface).
- the mobility management entity 9 has a controller 77 to control the operation of the mobility management entity 9 .
- the controller 77 is associated with a memory 79 .
- the mobility management entity 9 will of course have all the usual functionality of a cellular telephone network mobility management entity and this may be provided by any one or any combination of hardware, software and firmware, as appropriate.
- Software may be pre-installed in the memory 79 and/or may be downloaded via the telecommunications network 1 or from a removable data storage device (RMD), for example.
- the controller 77 is configured to control the overall operation of the mobility management entity 9 by, in this example, program instructions or software instructions stored within the memory 79 .
- these software instructions include, among other things, an operating system 81 , a communications control module 83 , a UE state/location registration module 85 , an S1AP module 88 , and a NAS module 89 .
- the communications control module 83 is operable to control the communication between the mobility management entity 9 and the base stations 5 , mobile devices 3 , IoT devices, and other network entities that are connected to the mobility management entity 9 .
- the UE state/location registration module 85 is responsible for keeping track of current location and state (e.g. idle or connected) of user equipment connected to the MME 9 .
- the S1AP module 88 is operable to generate, send and receive signalling messages formatted according to the S1AP (or NG-C AP) standard. For example, such messages are exchanged between the mobility management entity 9 and connected base stations 5 .
- the S1AP messages may include, for example, messages relating to registering the location and/or operating state (e.g. LC) of user equipment in a cell of the base station, requesting data forwarding, requesting path switching, and/or associated responses.
- the NAS module 89 is operable to generate, send and receive signalling messages formatted according to the NAS standard. For example, such messages are exchanged between the MME 9 and the mobile device 3 (via a base station 5 , using the S1AP module 88 ).
- the NAS messages may include, for example, messages relating to registering and/or updating a tracking area (or cell) where the mobile device 3 is currently located.
- the mobile device 3 , the base station 5 , and the mobility management entity 9 are described for ease of understanding as having a number of discrete modules (such as the communications control modules and the UE state modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.
- FIG. 5 is a timing diagram (message sequence chart) illustrating an example process performed by components of the network 1 when performing a paging operation for a mobile device (UE or IoT device) operating in LC state.
- UE mobile device
- the new base station 5 c is a base station configured in accordance with Rel-14 standards (or later) and hence it supports user equipment operating in LC mode.
- the mobile device 3 operates in LC state and its previous serving base station 5 b acts as an anchor base station for the mobile device 3 .
- the anchor base station 5 b (using its UE state module 65 ) stores the UE context associated with the mobile device 3 and configures an appropriate RAN based paging area for the mobile device 3 (e.g. by providing a list of cells and/or paging area IDs to the mobile device 3 ) while terminating S1.
- the mobile device 3 leaves the area (Cell # 1 ) served by the anchor base station 5 b (and/or the signal conditions in Cell # 1 deteriorate)
- the mobile device 3 selects a new cell to camp on that has more favourable signal conditions.
- the mobile device 3 selects and camps on Cell # 2 which is operated by the base station 5 c . Since the mobile device 3 has no active connections with the radio access network, the anchor base station 5 b is not aware of the mobile device's 3 current location (Cell # 2 ). From the perspective of the anchor base station 5 b , therefore, the mobile device 3 is deemed to be idle (in LC state).
- the MME 9 Whilst the mobile device 3 is deemed to be operating in the LC state, the MME 9 (using its UE state/location registration module 85 ) maintains an associated S1 connection (ECM-CONNECTED state) even when the mobile device 3 is operating in an idle mode from the RAN's point of view (which may not be visible by the MME 9 ). Accordingly, as generally shown in steps S 501 a and S 501 b , when the MME 9 has downlink data to send to the mobile device 3 (e.g. control-plane signalling/user-plane data), the MME 9 (using its S1AP module 88 ) starts transmitting the downlink data to the anchor base station 5 b without performing paging. It will also be appreciated that in some cases, a different core network node, e.g. the S-GW 10 may transmit downlink data to the anchor base station 5 b.
- a different core network node e.g. the S-GW 10 may transmit downlink data to the anchor base station 5
- the controller 57 of the anchor base station 5 b triggers, in step S 502 , RAN-based paging, which typically involves transmitting paging signalling via the Uu interface, via the X2 interface, or both.
- the anchor base station 5 b performs RAN based paging of the mobile device 3 within the paging area that is appropriate for that mobile device 3 .
- the anchor base station 5 b may also send appropriate X2 paging signalling to its neighbour base station(s) 5 in order to attempt to reach the mobile device 3 via neighbour cells. Effectively, the RAN based paging indicates to the mobile device 3 that it needs to resume its RRC connection (re-connect) via the anchor base station 5 b or another appropriate base station for receiving the downlink data.
- the anchor base station 5 b starts an appropriate timer (e.g. a paging timer) and stores the downlink data from the MME 9 (or S-GW 10 ) in its local cache (memory 59 ).
- an appropriate timer e.g. a paging timer
- the mobile device 3 is unable to receive (or respond to) the paging signalling. This might happen, for example, when the anchor base station 5 b does not perform paging via its neighbours (even though Cell # 2 may belong to the currently configured RAN paging area), when Cell # 2 does not belong to the paging area configured for the mobile device 3 , or when signal conditions at the edge of Cell # 2 prevent the mobile device 3 from successfully receiving (or responding to) paging signalling in that cell.
- step S 504 if the anchor base station 5 b does not receive any response from the mobile device 3 within a predefined time interval (e.g. at expiry of the paging timer), the base station 5 b proceeds to requesting help from the MME 9 .
- a predefined time interval e.g. at expiry of the paging timer
- the anchor base station 5 b generates and sends, in step S 505 , and appropriately formatted S1 signalling message (such as a ‘UE Context Release Request’ and/or the like) requesting the MME 9 to initiate S1 based (legacy) paging procedures.
- S1 signalling message such as a ‘UE Context Release Request’ and/or the like
- the message from the base station 5 b may also indicate (or it may be interpreted such) that the MME 9 does not need to trigger a release of the mobile device's 3 bearer via the S-GW 10 .
- the MME 9 needs to align the UE state from connected to idle (ECM-CONNECTED to ECM-IDLE). Therefore, upon receipt of the message at S 505 , the MME 9 (using its UE state/location registration module 85 ) moves the S1 connection for the mobile device 3 into idle (e.g. ECM-IDLE) and then it proceeds to initiating legacy paging procedures in the last know tracking area of the mobile device 3 in step S 506 .
- idle e.g. ECM-IDLE
- the MME 9 generates (using its S1AP module 88 ) and sends, in step S 507 , and appropriately formatted paging request to the base stations 5 operating cells that belong to the last know tracking area (including the new base station 5 c ).
- the MME's paging request triggers the new base station 5 c to carry out, in step S 508 , appropriate paging for the mobile device 3 over the Uu interface (in Cell # 2 ).
- the MME 9 and the S-GW 10 do not carry out a ‘Release Access Bearer’ procedure, i.e. the MME 9 maintains the existing S1 bearer for the mobile device 3 via the S-GW 10 despite having received a UE Context Release Request from the base station 5 a.
- step S 509 the mobile device 3 responds to the Uu paging request by the new base station 5 c by performing appropriate RRC and S1 connection setup procedures (via Cell # 2 ).
- step S 509 involves the mobile device 3 (using its NAS module 49 ) generating and sending an appropriately formatted handover request to the MME 9 (via the new base station 5 c ).
- the MME 9 registers Cell # 2 as the mobile device's 3 new location.
- the MME 9 may also indicate (for example, in an appropriately formatted ‘Initial Context Setup request’ and/or the like) to the new base station 5 c that data forwarding from the anchor base station 5 b to the new base station 5 c is imminent so that the new base station 5 c is able to prepare appropriate resources for receiving the forwarded data.
- the MME 9 may be configured to monitor (preceding) handovers performed by the mobile device 3 and obtain (hold in memory 79 ) context information and other parameters relating to the mobile device 3 . Therefore, the MME's 9 message to the new base station 5 c may also include one or more of the following information held by the MME 9 : an appropriate identifier associated with the mobile device 3 (e.g. a Resume Id) that the new base station 5 c may use for context fetching; information identifying the mobile device 3 at the MME 9 over the S1 interface (e.g. ‘MME UE S1AP ID’); information identifying the anchor base station 5 b (e.g.
- an appropriate identifier associated with the mobile device 3 e.g. a Resume Id
- information identifying the mobile device 3 at the MME 9 over the S1 interface e.g. ‘MME UE S1AP ID’
- information identifying the anchor base station 5 b e.g.
- an ‘anchor eNB ID’) a TAC of the anchor base station 5 b ; a Globally Unique MME ID (GUMMEI) associated with the MME 9 currently serving the mobile device 3 , a handover restriction list (e.g. a list of cell identifier for cells to which a handover of the mobile device 3 is not allowed), and other parameter found in previously handled handover requests relating to the mobile device 3 .
- GUMMEI Globally Unique MME ID
- the MME 9 is able to provide information relevant to the anchor base station 5 b in order to perform data forwarding.
- the MME 9 requests the anchor base station 5 b to perform data forwarding by generating and sending an appropriate S1 signalling message to the anchor base station 5 b (e.g. a ‘UE Context Release Command’ and/or the like).
- the MME 9 sends the UE Context Release Command to the anchor base station 5 b and includes information identifying the new base station 5 c (e.g. an eNB ID/gNB ID) and information identifying an appropriate forwarding address for the new base station 5 c (e.g. a tunnel endpoint identifier (TEID) and/or the like).
- TEID tunnel endpoint identifier
- the new base station 5 c is thus able to trigger an appropriate procedure (e.g. by generating and sending a ‘Retrieve UE Context Request’ to the anchor base station 5 b ) in order to fetch the context relating to the mobile device 3 from the anchor base station 5 b .
- the anchor base station 5 b generates and transmits an appropriately formatted ‘Retrieve UE Context Response’ to the new base station 5 c including the requested UE context.
- the base stations 5 proceed to SN Status transfer and data forwarding.
- the anchor base station 5 b (using its X2 module 67 ) generates and sends, in step S 511 , and appropriate ‘SN Status transfer’ message in order to transfer the status of the transceiver (uplink receiver status/downlink transmitter status) relating to the mobile device 3 .
- the status of the transceiver may include respective Packet Data Convergence Protocol (PDCP) sequence numbers (SNs) used in the uplink and downlink direction which allow the new base station 5 c to preserve the status following the mobile device 3 resuming its connection with the network via Cell # 2 .
- PDCP Packet Data Convergence Protocol
- step S 512 the anchor base station 5 b (using its X2 module 67 ) starts forwarding, to the new base station 5 c using the forwarding address provided by the MME 9 , any cached downlink data, and the new base station 5 c relays the forwarded data (not shown in FIG. 5 ) to the mobile device 3 via the Uu interface.
- the MME 9 and the new base station 5 c also initiates an appropriate path switch procedure (comprising a ‘Path Switch Request’ including information identifying the path to be switched (e.g. in an ‘MME UE S1AP ID’ information element) and an associated acknowledgement).
- the MME 9 also requests, in step S 514 , the S-GW 10 to modify the bearer associated with the mobile device 3 (i.e. to tunnel data to the new base station 5 c instead of the anchor base station 5 b ). Once the bearer has been modified, there is no need for the anchor base station 5 b to forward downlink data to the new base station 5 c.
- the new base station 5 c After the path switch triggered by new base station 5 c (in step S 513 ), the new base station 5 c is able to trigger UE context release towards the old (anchor) base station 5 b .
- the new base station 5 c After switching the path (S1 connection) associated with the mobile device 3 from the anchor base station 5 b to the new base station 5 c , the new base station 5 c generates and sends, in step S 515 , a UE Context release message indicating to the anchor base station 5 b that the anchor base station 5 b no longer needs to store the UE context associated with the mobile device 3 . Effectively, this message prompts the anchor base station 5 b to delete the UE context associated with the mobile device 3 (e.g.
- step S 516 the former anchor base station 5 b confirms that the UE context release has been completed by generating and sending an appropriate S1 acknowledgement to the MME's 9 command.
- FIG. 6 is a timing diagram (message sequence chart) illustrating another example process performed by components of the network 1 when performing a paging operation for a mobile device (UE or IoT device) operating in LC state.
- the new base station 5 c is a base station configured in accordance with pre-Rel-14 standards (and hence it is not capable of receiving forwarded data from the anchor base station 5 b ). Therefore, in this example, the anchor base station 5 b is configured to forward any cached data to the S-GW 10 .
- Steps S 601 a to S 608 correspond to steps S 501 a to S 508 described above hence their description is omitted herein for brevity.
- the MME 9 and the mobile device 3 proceed to step S 609 , and the mobile device 3 performs a legacy RRC connection establishment procedure in order to receive its downlink data.
- the mobile device 3 responds to the paging on the Uu interface by initiating and performing appropriate RRC (with the new base station 5 c ) and S1 (with the MME 9 through the new base station 5 c ) connection setup procedures (e.g. because base station 5 c is a pre-Rel-14 base station).
- the MME 9 (using its controller 77 ) also determines that the current serving cell (Cell # 2 ) of the mobile device 3 is operated by a base station 5 c which is configured in accordance with pre-Rel-14 standards.
- step S 610 the MME 9 (using its S1AP module 88 ) generates and sends a UE Context Release Command (and/or the like) to the anchor base station 5 b , requesting the anchor base station 5 b to perform data forwarding to the S-GW 10 .
- step S 612 the anchor base station 5 b starts data forwarding to the S-GW 10 (for delivery to the mobile device 3 via the S-GW 10 using the new S1 connection established for the mobile device 3 via Cell # 2 ).
- the new base station 5 c is a pre-Rel-14 base station
- downlink data intended for the mobile device 3 and that has been already sent to the anchor base station 5 b can still be delivered to the mobile device 3 via the S-GW 10 using the new S1 connection that was set up in step S 609 . It is possible therefore to avoid loss and/or unnecessary retransmissions of the downlink data for the mobile device (UE or IoT device) operating in LC state.
- step S 616 the anchor base station 5 b releases the UE context, as requested, then it generates and sends an appropriate response to the MME's 9 request received at step S 610 .
- the base stations 5 may be configured to notify the MME 9 that certain operations are not possible for the mobile device 3 because it is currently operating in LC state.
- MME operations may include, for example, load balancing, TAU required, PSM, MT CSFB, and/or the like. In this case, therefore, even if the MME 9 continues to see the mobile device 3 as being in a connected state (S1 connected/ECM-CONNECTED), the MME 9 is able to avoid such procedures (which would most likely fail or be ineffective).
- the serving/anchor base station 5 (in this example, the base station 5 b ) is configured to send, to the MME 9 , information identifying whether the mobile device 3 is operating in LC state and/or whether certain MME operations are to be avoided (or banned).
- this information may be included in an appropriately formatted information element (IE) associated with the mobile device 3 , such as an IE of an appropriate UE associated signalling message, such as a ‘UE Status Notification’ message and/or the like.
- IE information element
- the IE may include information identifying the mobile device 3 (e.g. an ‘MME UE S1AP ID’ and/or an ‘eNB UE S1AP ID’) and information indicating that certain MME operations are not possible for that particular device.
- the information indicating that certain MME operations are not possible may comprise: a flag (1-bit) indicating that certain pre-configured MME operations are banned for identified mobile device 3 ; and/or an enumerated list (and/or the like) identifying the particular operations that are not possible for the mobile device 3 .
- the contents of an exemplary IE are shown in Table 1.
- the above procedures allow the MME 9 to maintain information on the accurate state/location of the mobile device 3 even when the mobile device 3 operates in the LC state. Accordingly, the MME 9 can avoid performing and/or requesting procedures that would otherwise be inappropriate for the current operating state of the mobile device 3 .
- the MME 9 may be configured to avoid responding positively to the node initiating CSFB (e.g. an MSC) straight away—instead, the MME 9 may be configured to wait until it receives updated information from base station (e.g. that the mobile device 3 is no longer in LC state and/or CSCF is no longer banned for that particular mobile device 3 ).
- the base stations 5 of this system are beneficially configured to exchange information with each other relating to the mobile devices 3 (users) for which they are configured to act as an anchor base station.
- the base stations 5 are configured to provide, to their neighbour base station(s), information identifying any suspended bearers, UE AS context, security context at that particular base station 5 , and/or the mobile devices 3 associated with such suspended bearers.
- each anchor base station 5 may be configured to exchange (via X2) the unique identifiers that identify each UE for other neighbours for performing context pre-fetch.
- each base station 5 may hold (in its associated UE state module 65 ) information relating to bearers/mobile devices served by that base station.
- Such information may include, for example, an associated identifier (e.g. a ‘UE RRA Identifier’, a ‘Resume ID’, and/or the like) used within the RAN routing area (RRA).
- an associated identifier e.g. a ‘UE RRA Identifier’, a ‘Resume ID’, and/or the like
- RRA RAN routing area
- an appropriate identifier may be constructed using the RAN Routing Area ID/tracking area code (TAC) of the anchor base station 5 b , an identifier of the base station itself (e.g. an eNB ID/gNB ID), and a random number (e.g. a binary number).
- TAC RAN Routing Area ID/tracking area code
- neighbour base stations 5 may be configured to exchange the identities of UEs being anchored by them.
- Anchor base stations 5 may also exchange their respective RAN Routing Area Identifiers used for the anchored mobile devices 3 (at least with their neighbours within the same RAN Routing Area).
- each base station 5 may be configured to pre-fetch each UE context in order to minimize latency at the time of handover or idle mode mobility of these mobile devices 3 .
- Context pre-fetching may be applied to all anchored mobile devices.
- context fetching may be applied selectively, e.g. to mobile devices 3 of a specific type (e.g. MTC/IoT devices only).
- context pre-fetching may be applied to mobile devices 3 accessing a certain network slice/type of network slice (e.g. Slice Network Template) and/or mobile devices 3 belonging to certain tenant types.
- context pre-fetching may also be applied selectively to stationary/non-stationary UEs (as appropriate).
- context pre-fetching may be particularly useful for Ultra-Reliable and Low Latency Communications (URLCC) use cases.
- URLCC Ultra-Reliable and Low Latency Communications
- Pre-fetching and maintaining a common RRA UE Identifier pool within a RRA also allows the base stations to address mobile devices 3 uniquely within an RRA.
- example embodiments of the invention may be particularly beneficial for Internet of Things (or machine-type) data transmissions (e.g. transmission of data acquired during measurement events and the like).
- example embodiments are also beneficially for transmission of any form of data depending on the application in which the communication device is being used.
- the above example embodiments may be applicable for transmitting data such as user data, backup data, synchronisation data, diagnostic data, monitoring data, usage statistics, error data and/or the like.
- an X2 interface is provided between two neighbouring base stations and an S1 interface is provided between each base station and the core network.
- a different base station to base station interface and/or a different base station to core network interface may be provided.
- the interface between neighbouring base stations is referred to as the ‘Xn’ interface and the interface between a base station and the core network is referred to as the ‘NG-C’ interface.
- base stations are referred to as gNBs.
- a 3GPP radio communications (radio access) technology is used.
- any other radio communications technology i.e. WLAN, Wi-Fi, WiMAX, Bluetooth, etc.
- WLAN wireless local area network
- Wi-Fi Wireless Fidelity
- WiMAX WiMAX
- Bluetooth wireless personal area network
- the mobile device, the base station, and the MME are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.
- the software modules may be provided in compiled or un-compiled form and may be supplied to the base station, to the mobility management entity, to the mobile/IoT device, or to other user equipment as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the base station, the mobility management entity, or the mobile device in order to update their functionalities.
- the above described UE Status Notification may be implemented as a ‘class-1’ procedure requiring a response as well (from the MME to the base station sending the UE Status Notification).
- it may be implemented as a ‘class-2’ procedure requiring only a notification from the base station (but no response from the MME).
- the base stations are configured to exchange information with each other in order to facilitate a swift resumption of anchored mobile devices connection.
- the base station may assist a mobile device in order to speed up the transition between LC mode and connected mode.
- the base station may provide appropriate random access channel (RACH) preample information to the mobile device (e.g. whilst in connected mode) for use by the mobile device when it needs to transit to connected mode (e.g. when the mobile device has new uplink data to send after a period of inactivity).
- RACH random access channel
- the RACH preample may be specific to a particular mobile device so that the base station is able to retrieve the associated UE context upon receipt of the preamble (i.e. in the early phase of connection resumption).
- the mobile device is able to transition from LC mode to connected mode without unnecessary delay.
- the base station may provide the RACH preample to the mobile device when the mobile device is brought (by the base station) to LC mode from connected mode.
- the preamble information may be encoded in an appropriate message used by the base station to instruct the mobile device to move from connected mode to LC mode.
- the message may comprise an RRC Connection Release message and/or the like.
- the preamble information may be dynamically provided to a particular mobile device at the time of a UE-terminated call for that mobile device.
- the message may comprise an RRA Paging message and/or the like.
- the preamble information may be dynamically provided using system information block (SIB) on-demand signalling.
- SIB system information block
- the base station may also be configured to set a maximum validity for the RACH preample allocated to the mobile device. For example, the base station may set a timer (which may be provided to the mobile device together with the allocated preamble or separately). Thus, if the mobile device remains in LC mode for longer than a threshold (measured by the timer) without making any UL/DL data transmission, the base station may move the mobile device from LC mode to idle mode (upon expiry of the timer). This beneficially allows the base station to allocated unused preambles for other mobile device (if required).
- the base station may be configured to synchronise any RRA update made by the mobile device with a corresponding tracking area update (TAU) towards the core network (MME).
- TAU tracking area update
- MME core network
- the base station may be configured to map the RRA to a corresponding TA and initiate a conventional TAU on behalf of the mobile device.
- the base station may implement an appropriate local location management system per RRA (e.g. a local database mapping RRA/cell information to tracking area information).
- the base station may be configured to use the RRA Identifier of the mobile device in order to obtain the appropriate core network identity (e.g. a Globally Unique Temporary ID (GUTI), a Temporary International Mobile Subscriber Identity (T-IMSI), and/or the like) associated with the mobile device.
- the appropriate core network identity e.g. a Globally Unique Temporary ID (GUTI), a Temporary International Mobile Subscriber Identity (T-IMSI), and/or the like
- the obtained core network identity is then used in the TAU request generated by the base station on behalf of the mobile device.
- FIG. 7 is a timing diagram (message sequence chart) illustrating another example process performed by components of the system when resuming a connection for transmitting uplink data in LC mode. This process may be particularly beneficial for transmission of small data packets.
- the RRC Connection Resume Request in this case includes information indicating whether the mobile device wishes to resume its connection for a single transmission or multiple transmissions. Accordingly, the base station is able to allocate appropriate resources and configure the mobile device accordingly. In effect, the mobile device may be able to remain in LC mode or move to connected mode only for the indicated (single or multiple) transmission(s). In this case the mobile device is also beneficially able to return to LC mode more quickly following the transmission(s).
- the message (sent by the base station to the core network node) may comprise an S1AP: UE Context Release Request.
- the message may include at least one of i) an indication S1 paging is required for the communication device; ii) an indication that the communication device is an idle (or light-connected (LC)) condition; and/or iii) an indication that a communication bearer for the communication device should not be released.
- the transceiver of the base station may be configured to receive, from the core network node (e.g. in response to said message to request initiation of a paging procedure), a message requesting the base station to initiate forwarding of the received downlink data to another node (e.g. another base station or a gateway node).
- the received message requesting the base station to initiate forwarding may include information identifying a new base station serving the communication device (e.g an eNB ID and/or a forwarding address/TEID).
- the controller of the base station may be configured to control the transceiver to forward the downlink data to at least one of: a new base station; and a core network entity; based on said message requesting the base station to initiate forwarding.
- the controller of the base station may be configured to control the transceiver to provide a context associated with the communication device to another base station as part of a context fetching procedure (e.g. an X2 based context fetching procedure).
- the attempt to initiate communication with the communication device may comprise attempting paging of the communication device, and said message to request initiation of a paging procedure for the communication device may be sent when the communication device does not respond to said paging.
- the controller of the base station may be configured to control the transceiver to send a notification (e.g. a UE status notification) to the core network node indicating that at least one core network operation is not possible (or banned).
- a notification e.g. a UE status notification
- the notification may comprise a class 1 notification requiring a response.
- the notification may comprise a class 2 notification.
- the notification may comprise at least one of a flag and a list indicating one or more operations that are not possible/banned.
- the communication device may be in an idle state (e.g. an idle state in a lightweight connected, ‘LC’, mode).
- the base station may be configured to operate as an anchor base station for the communication device which maintains information identifying the communication device in association with context information for that communication device and/or terminates an associated S1 communication bearer for the communication device.
- the controller of the base station may be configured to control the transceiver to fetch a context associated with the communication device from the other base station as part of a context fetching procedure (e.g. an X2 based context fetching procedure).
- the controller of the base station may be configured to control the transceiver to provide, to the core network node, a message configured to trigger initiation of a path switching procedure.
- the controller of the core network apparatus may be configured to move the communication device into an idle state (e.g. ECM-IDLE) from a connected state (e.g. ECM-CONNECTED) and to trigger paging in a previously known tracking area (TA).
- the controller may be configured to move the communication device into said idle state without releasing a communication bearer associated with the communication device.
- the core network apparatus may comprise a mobility management entity (‘MME’).
- MME mobility management entity
- the transceiver of the core network apparatus may be configured to send, to the base station (e.g. in response to said message to request initiation of a paging procedure), a message requesting the base station to initiate forwarding of the received downlink data to another node (e.g. another base station or a gateway node).
- the message requesting the base station to initiate forwarding may include information identifying a new base station serving the communication device (e.g an eNB ID and/or a forwarding address/TEID).
- the controller of the core network apparatus may be configured to control the transceiver to send, to another base station, a message (e.g. an Initial Context Setup Request) indicating that data forwarding from the base station is to happen for the communication device, together with at least one of: an identifier, associated with the communication device, for use in fetching a context relating to the communication device from the other base station; information identifying the communication device at the core network apparatus over an S1 interface (e.g. ‘MME UE S1AP ID’); information identifying the base station (e.g. an ‘anchor eNB ID’); a tracking area code (TAC) associated with the base station; a globally unique ID (e.g.
- a message e.g. an Initial Context Setup Request
- an identifier associated with the communication device, for use in fetching a context relating to the communication device from the other base station
- information identifying the communication device at the core network apparatus over an S1 interface e.g. ‘MME UE S1AP
- a GUMMEI associated with the core network apparatus; information identifying at least one cell identifier for at least one cell to which a handover of the communication device is prohibited; and at least one other parameter acquired by the core network apparatus in a previously handled handover request relating to the communication device.
- the controller of the core network apparatus may be configured: to control the transceiver to receive, from another base station, a message configured to trigger initiation of a path switching procedure; and to initiate the path switching procedure accordingly.
- the message configured to trigger initiation of a path switching procedure may comprise an MME UE S1AP ID IE for the communication device.
- RAN-based paging might fail and hence, there has to be a mechanism in place for an eNB to seek MME for paging assistance.
- RAN-based paging may not fail unless UE is switched off, failed or has slipped out of cellular coverage, it is better to have a fall back mechanism for the purpose of getting an eNB to resort to CN-based paging, if necessary.
- some basic solutions were presented in RAN3 #93bis, it is better to look into it in depth in order to make it proper.
- the objective of this paper is to make a CN-based paging work if sought by an eNB. Further it explores, the various ways to make such a CN-based paging to work especially in mixed-deployment cases.
- an anchor eNB moves a UE from LIGHT-CONNECTED to RRC-IDLE State after a time out, it can trigger S1-AP: UE Context Release Request for the purpose of releasing S1 resources and states.
- Proposal 1 RAN3 is respectfully requested to ensure that a UE is not configured to take LIGHT-CONNECTED State indefinitely unless otherwise it is necessary and S1 resources are released after a time out.
- a new or existing identifier (e.g. Resume Id) that can be used for identification purposes especially by the E-UTRAN when a UE takes LIGHT-CONNECTED State needs to be unique across neighbours. For instance when a UE tries to resume with a Resume Id that is not comprehensible to a new eNB in terms of which eNB to contact in order to fetch associated UE context. This is especially difficult when there is no X2 between an anchor eNB and a new eNB.
- Resume Id e.g. Resume Id
- Observation 2 UE has to be uniquely identified across neighbour eNBs for context retrieval purposes.
- the new or existing identifier includes tracking area code (TAC) or RAN Routing Area Code (i.e. the RAN routing area code that is analogous to TAC) and eNB Id. This way a new eNB can determine the exact anchor eNB from which to fetch a UE context.
- TAC tracking area code
- RAN Routing Area Code i.e. the RAN routing area code that is analogous to TAC
- Proposal 2 RAN3 is respectfully requested to ensure that a new or existing identifier (e.g. ResumeID) includes tracking area code (TAC) or RAN Routing Area Code (i.e. the RAN routing area code that is analogous to TAC) and eNB ID.
- a new or existing identifier e.g. ResumeID
- TAC tracking area code
- RAN Routing Area Code i.e. the RAN routing area code that is analogous to TAC
- eNB ID i.e. the RAN routing area code that is analogous to TAC
- the new UE state is hidden from MME.
- an eNB configures a UE to take this new state, it does not explicitly notify an MME.
- a UE which takes LIGHT-CONNECTED State is considered to be in ECM-CONNECTED mode from the perspectives of an MME.
- MME has to be brought back to the normal state in terms of how a UE in question is seen by an MME before a help of MME can be sought in this respect by an eNB.
- MME has to be made to move a UE from ECM-CONNECTED to ECM-IDLE for triggering a legacy paging.
- an MME has to move a UE from ECM-CONNECTED to ECM-IDLE mode before it can trigger a legacy-based paging.
- Existing procedures and messages can be used for this purpose.
- an anchor eNB can trigger a UE Context Release procedure whenever an anchor eNB cannot reach out a UE through its RAN-based paging.
- the anchor eNB can additionally seek MME assistance for paging while releasing S1 context.
- an MME can pass those details to an old and new anchor eNB for either X2-based or S1-based context retrieval and subsequent data forwarding.
- an MME can indicate to a new eNB that data forwarding from an old anchor eNB is to happen in Initial Context Setup Request message, together with UE identifiers for context fetch (e.g. Resume Id), MME UE S1AP ID, old anchor eNB ID, TAC of an old anchor eNB and other key parameters that can be found in HO Request message.
- an old anchor eNB can be notified by an MME in terms of new eNB ID, TEID and data forwarding address using existing legacy UE Context Release command.
- a new eNB can trigger RETRIEVE UE CONTEXT REQUEST with a passed on details of an old anchor eNB which in turn respond with RETRIEVE UE CONTEXT RESPONSE.
- This context fetch can happen between Steps 10 and 11 in FIG. 8 although this is not shown for clarity.
- SN Status transfer and data forwarding can happen.
- the new eNB can trigger UE context release towards an old anchor eNB which in turn trigger S1-AP: UE Context Release Complete.
- UE Context Release procedure can be used for getting an MME to move UE from the ECM-CONNECTED to the ECM-IDLE State and to trigger S1-based paging.
- Proposal 3 RAN3 is respectfully requested to ensure that MME is put to the right state using existing procedures for the purpose of enabling an eNB to seek MME assistance for paging when RAN-based paging fails.
- Step 10 an MME can request an old anchor eNB to forward data nack to S-GW. After data forwarding is complete, old anchor eNB can trigger S1-AP: UE Context Release Complete.
- Proposal 4 RAN3 is respectfully requested to ensure existing procedure is used to get an old eNB to forward data back to S-GW when RAN-based paging fails in mixed deployment cases.
- Proposal 1 RAN3 is respectfully requested to ensure that a UE is not configured to take LIGHT-CONNECTED State indefinitely unless otherwise it is necessary and S1 resources are released after a time out.
- Observation 2 UE has to be uniquely identified across neighbour eNBs for context retrieval purposes.
- Proposal 2 RAN3 is respectfully requested to ensure that a new or existing identifier (e.g. ResumeID) includes tracking area code (TAC) or RAN Routing Area Code (i.e. the RAN routing area code that is analogous to TAC) and eNB ID.
- a new or existing identifier e.g. ResumeID
- TAC tracking area code
- RAN Routing Area Code i.e. the RAN routing area code that is analogous to TAC
- eNB ID i.e. the RAN routing area code that is analogous to TAC
- MME has to be made to move a UE from ECM-CONNECTED to ECM-IDLE for triggering a legacy paging.
- UE Context Release procedure can be used for getting an MME to move UE from the ECM-CONNECTED to the ECM-IDLE State and to trigger S1-based paging.
- Proposal 3 RAN3 is respectfully requested to ensure that MME is put to the right state using existing procedures for the purpose of enabling an eNB to seek MME assistance for paging when RAN-based paging fails.
- Proposal 4 RAN3 is respectfully requested to ensure existing procedure is used to get an old eNB to forward data back to S-GW when RAN-based paging fails in mixed deployment cases.
Abstract
A communication system is disclosed in which am anchor base station receives, from a core network node, downlink data for a communication device. The base station attempts (e.g. by RAN-based paging) to initiate communication with the communication device, and when the communication device does not respond to the attempt to initiate communication, the base station sends a message to the core network node, the message requesting initiation of a paging procedure for the communication device (e.g. S1-based paging).
Description
- The present application is a continuation application of U.S. patent application Ser. No. 16/347,074 filed on May 2, 2019, which is a National Stage Entry of international application PCT/JP2017/038723, filed on Oct. 26, 2017, which claims the benefit of priority from United Kingdom Patent Application 1618663.7 filed on Nov. 4, 2016, the disclosures of all of which are incorporated in their entirety by reference herein.
- The present invention relates to a communication system. The invention has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including LTE-Advanced and Next Generation or 5G networks). The invention has particular although not exclusive relevance to managing connection states for communication devices.
- The latest developments of the 3GPP standards are referred to as the Long Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred as ‘4G’. In addition, the term ‘5G’ and ‘new radio’ (NR) refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the ‘NGMN 5G White Paper’ V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https://www.ngmn.org/5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.
- Under the 3GPP standards, a NodeB (or an eNB in LTE, gNB in 5G) is the base station via which communication devices (user equipment or ‘UE’) connect to a core network and communicate to other communication devices or remote servers. For simplicity, the present application will use the term base station to refer to any such base stations and use the term mobile device, user device, or UE to refer to any such communication device. The core network (i.e. the EPC in case of LTE) hosts functionality for subscriber management, mobility management, charging, security, and call/session management (amongst others), and provides connection for communication devices to external networks, such as the Internet.
- Communication devices might be, for example, mobile communication devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop/tablet computers, web browsers, e-book readers and/or the like. Such mobile (or even generally stationary) devices are typically operated by a user. However, 3GPP standards also make it possible to connect so-called ‘Internet of Things’ (IoT) devices (e.g. Narrow-Band IoT (NB-IoT) devices) to the network, which typically comprise automated equipment, such as various measuring equipment, telemetry equipment, monitoring systems, tracking and tracing devices, in-vehicle safety systems, vehicle maintenance systems, road sensors, digital billboards, point of sale (POS) terminals, remote control systems and the like. Effectively, the Internet of Things is a network of devices (or “things”) equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enables these devices to collect and exchange data with each other and with other communication devices. It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) communication devices or Machine-to-Machine (M2M) communication devices.
- For simplicity, the present application refers to mobile devices in the description but it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
- Communication between mobile devices and base stations is controlled using a Radio Resource Control (RRC) protocol as defined in 3GPP TS 36.331 V14.0.0. RRC handles the control plane signalling of
Layer 3 between mobile telephones and the radio access network, and includes, amongst other things, functions for broadcasting system information, paging, connection establishment and release, radio bearer establishment, reconfiguration and release, mobility procedures, and power control. In accordance with the current version of the RRC protocol, at any given time, a mobile device may operate either in an ‘RRC idle mode’ (in which no data communication takes place) or an ‘RRC connected mode’ (in which data communication may take place between the mobile device and its serving base station). - As mobile devices operating in the RRC connected mode move around in the area covered by the communication system, they are handed over from one cell (i.e. operated by a base station) to another cell (operated by the same or a different base station), depending on signal conditions and other requirements, such as requested quality of service, the type of service used, overall system load, and the like. Handover requires extensive signalling between the mobile device and the base stations (old and new) and also between the base stations and the core network as well.
- On the other hand, whilst in the RRC idle mode, mobile devices are programmed to select a ‘serving’ cell, having a good quality signal, to camp on so that when new data is to be transmitted to/from these mobile devices, they can benefit from favourable signal conditions. In the event that an idle mobile device detects a new cell with better signal quality than the current serving cell, e.g. due to the mobile device changing its location, the mobile device can perform a so-called cell reselection procedure. However, an idle mode mobile device does not inform the network about the selected new cell as long as this cell is within the same ‘tracking area’ (i.e. a larger geographic area comprising a pre-defined set of cells), because the radio network transmits system information and UE specific paging messages within the whole tracking area thus making it possible to initiate communication to/from the mobile device regardless of the current cell it camps on.
- In order to benefit from the lowest energy consumption and to free up valuable system resources, the mobile devices return to the RRC idle mode whenever possible and perform cell reselections (instead of handovers) as long as they remain within the same tracking area. The base station controls the transition between the various operating modes for each mobile device within its cell(s). Since the setting up and termination of an RRC connection between the base station and the mobile device requires exchanging of signalling messages and hence utilises valuable system resources, and also takes some time to complete, the transition from connected to idle mode is allowed under specific circumstances as defined in 3GPP TS 36.331. For example, the serving base station might instruct a mobile device to enter the RRC idle mode only after it has confirmed that there is no more data to be transmitted to/from the particular mobile device (e.g. both uplink (UL) and downlink (DL) buffers are empty).
- When it registers its current location (e.g. cell) with the core network, each mobile device also has an associated ‘S1’ connection between its serving base station and the core network. The S1 connection is either in a so-called ‘ECM-IDLE’ mode (when the mobile device is in RRC idle mode) or in an ‘ECM-CONNECTED’ mode (when the mobile device is in RRC connected mode). The S1 connection is used for transferring data (control and user data) between the mobile device and the core network (and beyond) and it is maintained as long as the mobile device remains in the RRC connected mode. On the other hand, when a mobile device enters the RRC idle mode, its associated S1 connection is also terminated (or suspended) until the mobile device has more data to send or receive in which case a new S1 connection is established to the current serving base station (or the suspended S1 connection is re-activated).
- When the network has data to send to an RRC idle mobile device, it triggers an appropriate paging procedure in the last known area (tracking/paging area) of the mobile device, which causes the base stations within that area to broadcast appropriate paging messages in their cells requesting that particular mobile device to enter the RRC connected state. When a previously idle mobile telephone has data to send again (or it has been paged for receiving downlink data), in order to be allocated communication resources it initiates a so called RRC connection establishment procedure by sending an appropriately formatted RRC connection request message to the base station (following a so-called Random Access Procedure which ensures that the lower layers, and in particular the Media Access Control (MAC) layer, are set up for communication with the base station).
- For the latest developments of the 3GPP standards, the so-called Next Generation (NG) or 5G networks, it is envisaged that mobile devices may also operate in a new RRC state, or new radio state, referred to as a ‘light-connected’ (LC) state. When a mobile device is in the LC state, the core network maintains both its control-plane and user-plane connection even after the mobile device has no more data to send or receive (and hence it is normally configured to enter the RRC idle mode). In other words, even though in the LC state the mobile device is seen as operating in idle mode from the radio access network's (base station's) point of view, it may still be seen as being connected from the core network's point of view. One of the benefits of this new LC state is that mobile devices (IoT devices in particular) that have small and infrequent data transmissions do not need to perform the entire RRC connection establishment procedure every time they have data to send (or receive). Instead, an LC state capable mobile device can be configured to resume its existing RRC connection with the current serving base station whenever needed and then return to a more power efficient mode of operation until it has data to send/receive again.
- The mobile device can resume its RRC connection by sending to its current base station information (e.g. a resume ID) identifying the connection to be resumed. This beneficially avoids the base station and the mobile device having to go through authentication and radio bearer establishment. In order to facilitate such lightweight connection and simplified resumption of the connection between the mobile device and its serving base station, the concept of a so-called anchor base station is being considered by 3GPP. Effectively, the anchor base station is a base station responsible for storing UE Access Stratum (AS) context, caching the mobile device's user data (UE context) and for providing the user data to other base stations as needed while terminating S1. For example, the anchor base station may be the first (or previous) base station that the mobile device registered with in a particular tracking area (or other pre-defined area). Thus, when the mobile device attempts to resume its RRC connection via a different base station (within the same area), the new base station can contact the anchor base station and retrieve the UE context along with the cached user data based on information provided by the mobile device (e.g. resume ID and/or the like). Since in the LC state the S1 connection is maintained, beneficially, the new base station can avoid having to contact the core network and/or establish a new S1 connection for the mobile device (although the new base station might need to switch the S1 connection from the anchor/previous base station to the new base station). The anchor base station concept is illustrated in
FIG. 8 which is reproduced from 3GPP draft no. R3-160655. - The current agreement in 3GPP is that the base station maintains the S1 connection while the mobile device is lightly connected and the base station is responsible for RAN paging (within an appropriate paging/tracking area configured by the base station) when it receives the downlink data from core network. The LC state mobile device notifies the network when it moves out of its configured RAN based paging area, in which case the network can decide whether to keep the mobile device in LC mode or suspend the mobile device (e.g. request it to enter RRC idle mode).
- However, the inventors have realised that since the mobile device appears to be in different states towards the RAN and the core network, this may cause a number of issues that the currently proposed systems cannot handle. Such issues include, although they are not limited to:
-
- how to avoid loss of DL data when RAN based paging fails;
- how to perform core network (e.g. MME) based paging as a fall-back when RAN based paging fails;
- how to inform a mobility management entity (MME) that certain operations such as load balancing, tracking area update (TAU) required, power saving mode (PSM), mobile terminated (MT) circuit switched fallback (CSFB) may be impacted due to the mobile device's LC operation.
- how to notify the MME when a mobile device enters the LC state;
- how to exchange a RAN-based identifier (e.g. resume ID) that is used to uniquely identify a mobile device when it is in LC mode within the RAN routing area (e.g. for reducing the time it takes to resume a connection by performing context pre-fetch);
- how to expedite random access channel (RACH) processes when a mobile device transits from LC mode to regular connected mode for data transmission;
- how to synchronise RAN location update with core network location update; and
- how to enable UL data transmission when the mobile device is in LC mode.
- Accordingly, preferred example embodiments of the present invention aim to provide methods and apparatus which address or at least partially deal with one or more of the above issues whilst still allowing mobile devices to maintain a light connection with the network.
- Although for efficiency of understanding for those of skill in the art, the invention will be described in detail in the context of a 3GPP system (UMTS, LTE), the principles of the invention can be applied to other systems in which communication devices or User Equipment (UE) access a core network using a radio access technology.
- In one aspect, the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to receive, from a core network node, downlink data for a communication device; attempt to initiate communication with the communication device; and control the transceiver to send to the core network node, when the communication device does not respond to said attempt to initiate communication, a message to request initiation of a paging procedure for the communication device.
- In one aspect, the invention provides core network apparatus for a communication network, the core network apparatus comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to send, to a base station, downlink data for a communication device; control the transceiver to receive from the base station, when the communication device does not respond to an attempt by the base station to initiate communication, a message to request initiation of a paging procedure for the communication device; and initiate a paging procedure for the communication device based on said message.
- In one aspect, the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to send a notification to a core network node indicating that at least one core network operation is not possible (or banned) for a given communication device.
- In one aspect, the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: maintain information identifying at least one communication device, for which the base station operates as an anchor base station, in association with respective context information for each communication device for which the base station operates as an anchor base station; and control the transceiver to provide to another base station at least one identifier to identify at least one respective communication device for which the base station operates as an anchor base station.
- In one aspect, the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to receive from at least one other base station at least one identifier to identify at least one communication device for which the at least one other base station operates as an anchor base station; and fetch, from the at least one other base station, context information for each communication device for which the at least one other base station operates as an anchor base station based on said at least one identifier.
- In one aspect, the invention provides a base station for a communication network, the base station comprising: a transceiver and a controller wherein the controller is configured to: control the transceiver to, receive from a core network node, a message indicating that data forwarding from another base station is to happen for a communication device, together with at least one of: an identifier, associated with that communication device, for use in fetching a context relating to that communication device from the other base station; information identifying the communication device at the core network node over an S1 interface (e.g. ‘MME UE S1AP ID’); information identifying the other base station (e.g. an ‘anchor eNB ID’); a tracking area code (TAC) associated with the other base station; a globally unique ID (e.g. a GUMMEI) associated with the core network node currently serving the communication device; information identifying at least one cell identifier for at least one cell to which a handover of the communication device is prohibited; and at least one other parameter acquired by the core network node in a previously handled handover request relating to the communication device; and control the transceiver to receive data forwarded by the other base station accordingly.
- Aspects of the invention extend to corresponding systems, methods, and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.
- Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the invention independently of (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually.
- Example embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:
-
FIG. 1 illustrates schematically a cellular telecommunication system to which example embodiments of the invention may be applied; -
FIG. 2 is a block diagram of a mobile device forming part of the system shown inFIG. 1 ; -
FIG. 3 is a block diagram of a base station forming part of the system shown inFIG. 1 ; -
FIG. 4 is a block diagram of a mobility management entity forming part of the system shown inFIG. 1 ; -
FIG. 5 is a timing diagram illustrating an exemplary way in which example embodiments of the invention can be implemented in the system ofFIG. 1 ; -
FIG. 6 is a timing diagram illustrating an exemplary way in which example embodiments of the invention can be implemented in the system ofFIG. 1 ; -
FIG. 7 is a timing diagram illustrating an exemplary way in which example embodiments of the invention can be implemented in the system ofFIG. 1 ; and -
FIG. 8 illustrates schematically the anchor base station concept. -
FIG. 1 schematically illustrates atelecommunications network 1 in whichmobile devices 3, mobile telephones, and other communication devices (e.g. IoT devices) can communicate with each other via E-UTRAN base stations 5 and a core network 7 using an E-UTRA radio access technology (RAT). As those skilled in the art will appreciate, whilst one mobile device 3 (denoted ‘UE’), oneIoT device 3′, and three base stations 5 a to 5 c are shown inFIG. 1 for illustration purposes, the system, when implemented, will typically include other base stations and communication devices. - Each base station 5 operates one or more associated cell. In this example, the base station 5 b operates ‘Cell #1’ and the base station 5 c operates ‘Cell #2’. Although not shown in
FIG. 1 , base station 5 a will also typically operate one or more cells. It will also be appreciated that in some scenarios the ‘old’ base station 5 a and the ‘anchor’ base station 5 b might be the same. - Communication devices may connect to either cell (depending on their location and possibly on other factors, e.g. signal conditions, subscription data, capability, and/or the like) by establishing a radio resource control (RRC) connection with the appropriate base station 5 operating that cell. As can be seen, the
mobile device 3 is located in an area where the cells operated by the base stations 5 b and 5 c partially overlap. Thus, when operating in RRC idle mode (not sending/receiving data), themobile device 3 camps on the cell having the best signal quality, and when in RRC active mode, themobile device 3 communicates data via that cell (using e.g. the ‘Uu’ air interface). Similarly, in this example, theIoT device 3′ camps on Cell #2 (when in RRC idle mode) and communicates via the base station 5 c (when in RRC active mode). - When the mobile device 3 (
IoT device 3′) first registers with the network (via one of the base stations 5), its serving base station 5 also establishes an associated S1 connection for relaying communications (user and control data) between the serving base station 5 and the core network 7. - The base stations 5 are connected to the core network 7 via an S1 interface and to each other via an X2 interface (either directly, or via an X2 gateway). The core network 7 includes, amongst others, a mobility management entity (MME) 9, a serving gateway (S-GW) 10, and a packet data network gateway (P-GW) 11 for providing a connection between the base stations 5 and other networks (such as the Internet) and/or servers hosted outside the core network 7.
- The MME 9 is the network node responsible for keeping track of the locations of the mobile communication devices (mobile devices and IoT devices alike) within the
telecommunications network 1 especially when a UE is RRC_IDLE mode. In particular, the MME 9 stores an identifier of the mobile communication devices' last known cell (or tracking area) so that they can be notified when there is an incoming (voice or data) call for them and that a communication path is set up via the base station 5 currently serving the particular mobile communication device. - In the following examples, the
mobile device 3 connects to the network periodically (e.g. whenever one of its applications needs to communicate with the network) for sending data to a remote endpoint (e.g. a server or another communication device). Themobile device 3 is configured to operate in a light connected (LC) mode in which the network maintains an associated S1 connection even when themobile device 3 is operating in an idle mode from the RAN's point of view. Therefore, between its periodic re-connections, themobile device 3 effectively enters an idle (or ‘suspended’) mode and thus avoids performing handovers as long as it remains within an area configured by its anchor base station. - The serving base station 5 is responsible for configuring an appropriate RAN based paging area for the mobile device 3 (e.g. by providing a list of cells and/or paging area IDs to the mobile device 3). The RAN based paging area may be configured as one or more cells from the same or different base stations 5. For example, the RAN based paging area may be a tracking area.
- As illustrated by a dashed line, the
mobile device 3 previously connected to the base station 5 b (via Cell #1) and thus the base station 5 b (acting as the anchor base station for the mobile device 3) maintains an associated UE context and terminates S1. However, it will also be appreciated that the anchor base station may be a different base station, e.g. the old base station 5 a. In the present example, the anchor base station 5 b configures themobile device 3 with a RAN paging area that includes the anchor base station's own cell (Cell #1) and any cells operated by base station 5 a. - As illustrated by a continuous line, the
mobile device 3 is now reachable via the base station 5 c (via Cell #2), e.g. due to a change in signal conditions inCell # 1 and/or movement of themobile device 3. In this example, themobile device 3 currently has no active connections with the radio access network (the base stations 5), thus it is configured to perform cell reselection when it moves to Cell #2 (without informing the network). - As explained above, in LC state the
mobile device 3 is still seen as connected (ECM-CONNECTED) from the core network's 7 (MME 9) point of view even after themobile device 3 has, in effect, entered an idle mode from the perspective of the base stations (and hence themobile device 3 does not have an active data connection with its base station 5). Accordingly, when there is downlink data to send, the MME 9 does not initiate paging, for amobile device 3 in the LC state/mode (e.g. throughout an associated tracking/paging area) because the MME 9 assumes that themobile device 3 still has an active connection with its serving base station 5 (in this example, the anchor base station 5 b). Thus, the MME 9 starts sending the downlink data to the anchor base station 5 b. In response to the downlink data, the anchor base station 5 b starts appropriate procedures for (RAN based) paging of themobile device 3 within the paging area appropriate for thatmobile device 3. The RAN based paging indicates to themobile device 3 that it needs to resume its RRC connection (re-connect) via an appropriate base station for receiving downlink data. Until themobile device 3 resumes its connection, the anchor base station 5 b stores the downlink data from the MME 9 (in case of control-planes signalling or data) or from the S-GW 10 (in case of user-plane data) in its cache (memory). - The base station 5 b decides which cells to page when it receives the downlink data. If necessary, the anchor base station 5 b may send appropriate X2 paging signalling to its neighbour base station(s) in order to reach the
mobile device 3 via other than its own cell(s). However, as themobile device 3 has moved in the meantime and it is now camping onCell # 2, it might not be able to receive (or respond to) the paging signalling. This might happen, for example, when the anchor base station 5 b does not perform paging via its neighbours (even thoughCell # 2 may belong to the currently configured RAN paging area), whenCell # 2 does not belong to the paging area configured for themobile device 3, or when signal conditions at the edge ofCell # 2 prevent themobile device 3 from successfully receiving (or responding to) paging signalling in that cell. - Beneficially, if the anchor base station 5 b does not receive any response from the
mobile device 3 within a predefined time interval (after start of paging), the base station 5 b requests the MME 9 to initiate S1 based (legacy) paging procedures. However, before the MME 9 is able to provide assistance in this respect, the MME 9 needs to move themobile device 3 from connected state to idle state (e.g. ECM-CONNECTED to ECM-IDLE). In order to allow this, the base station 5 b is configured to use legacy signalling in order to tear down the existing S1 connection. For example, the base station 5 b may be configured to send an appropriately formatted message (such as a ‘UE Context Release Request’ and/or the like) including information indicating that S1 based paging is required for themobile device 3 in its last recorded tracking area. Beneficially, the base station's request allows the MME 9 to move themobile device 3 to idle state (ECM-IDLE) allowing the MME 9 to trigger a legacy S1-based paging. Advantageously, the message from the base station 5 b may also indicate that the paging is requested without triggering a release of the mobile device's 3 bearer via the S-GW 10 (i.e. unlike the conventional procedure upon receipt of a UE Context Release Request for a UE in legacy RRC idle state). - The MME 9 triggers S1 based paging and waits for an appropriate response from the
mobile device 3. In this example, themobile device 3 responds to the MME's paging request via the new base station 5 c by performing appropriate RRC and S1 connection setup procedures (via the new base station 5 c/Cell #2). This is possible when a new base station 5 does not know or understand as to how to locate the associated UE context using the UE identifier (e.g. Resume ID) received from themobile device 3. The MME 9registers Cell # 2 as the mobile device's 3 new location. - When the new base station 5 c establishes a new RRC and S1 connection for the
mobile device 3, the MME 9 is beneficially able to indicate to the new base station 5 c that data forwarding from the old (anchor) base station 5 b is to happen. In this example, the MME 9 requests data forwarding in its response to the anchor base station 5 b (e.g. a ‘UE Context Release Response’ and/or the like). - Moreover, the MME 9 may also be configured to monitor (preceding) handovers performed by the
mobile device 3 and obtain context information and other parameters relating to themobile device 3. Therefore, the MME's 9 message to the new base station 5 c may also include information (previously obtained or held by the MME 9) that may be used by the new base station 5 c to fetch the UE context from the anchor base station 5 b. Similarly, the MME 9 is able to provide information relevant to the anchor base station 5 b in order to perform data forwarding. - On the other hand, in case the
mobile device 3 is not found (i.e. it does not respond to the network-wide S1 based paging either), then the MME 9 can follow appropriate legacy procedures in order to release the UE context (held at the anchor base station 5 b and the MME 9) and trigger a release of the access bearer towards the S-GW 10. After the UE context is released, themobile device 3 is considered to be in RRC idle state (instead of LC state) and themobile device 3 is able to communicate with the network again by moving to RRC connected state, e.g. by triggering an appropriate RRC connection establishment operation (instead of a simple resume operation). - In a particularly beneficial example, the base stations 5 may be configured to notify the MME 9 that certain operations are not possible for the
mobile device 3 because it is currently operating in LC state. Such MME operations may include, for example, load balancing, TAU required, Power Saving Mode, MT CSFB, and/or the like. Thus, even if the MME 9 continues to see themobile device 3 as being in a connected state (S1 connected/ECM-CONNECTED), the MME 9 is able to avoid such procedures. - Beneficially, the serving/anchor base station 5 (in this example, the base station 5 b) is configured to send, to the MME 9, information identifying whether the
mobile device 3 is operating in LC state and/or whether certain MME operations are to be avoided (or banned). Based on the received information, the MME 9 takes different handling for certain operations such as CSFB or will not release S1 with load balancing TAU required. As a result, when overloaded, the MME 9 may be configured to release S1 connections that do not belong to those UEs that are in LIGHT-CONNECTED mode. - Beneficially, the above procedures allow the MME 9 to avoid performing and/or requesting procedures that would otherwise be inappropriate for the current operating state of the
mobile device 3. - In order to facilitate swift resuming of an RRC connection for
mobile devices 3 via a different based station (in this example, resuming the mobile device's connection via base station 5 c and Cell #2), the base stations 5 of this system may also be configured to exchange information with each other relating to the mobile devices 3 (users) for which they act as an anchor base station. - Specifically, the base stations 5 (at least the ones which operate as anchor base stations) may be configured to provide, to their neighbour base station(s) over the X2 interface, information identifying any UE AS context, security data, suspended bearers at that particular base station 5, and/or the
mobile devices 3 associated with such suspended bearers. - Using such exchanged information (e.g. identifiers of suspended bearers and/or mobile devices associated with such bearers), neighbour base stations 5 are beneficially able to pre-fetch the associated UE context for bearers suspended at another (anchor) base station. This allows them to minimise latency at the time of handover (or idle mode mobility) of a particular
mobile device 3 to a cell operated by the new (neighbour) base station 5 (because the UE context is already available locally at the new base station 5). This may be useful for ultra-reliable low latency communications. - In summary, in this network it is possible to provide better service continuity and more efficient resource usage at user equipment (the mobile device and/or the IoT device), base stations, and the MME when the user equipment (which may be operating in LC state) moves to and/or camps on a new cell operated by a different base station.
- Mobile Device
-
FIG. 2 is a block diagram illustrating the main components of themobile device 3 shown inFIG. 1 (e.g. a mobile telephone or an IoT device). As shown, themobile device 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5 via one ormore antenna 33. Themobile device 3 has a controller 37 to control the operation of themobile device 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, themobile device 3 might of course have all the usual functionality of a conventional mobile telephone (such as a user interface 35) and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 39 and/or may be downloaded via the telecommunications network or from a removable data storage device (RMD), for example. - The controller 37 is configured to control overall operation of the
mobile device 3 by, in this example, program instructions or software instructions stored within the memory 39. As shown, these software instructions include, among other things, anoperating system 41, acommunications control module 43, a UE state module 45, an RRC module 46, and a NAS module 49. - The
communications control module 43 is operable to control the communication between themobile device 3 and its serving base station 5 (and other communication devices connected to the serving base station 5, such as further mobile devices, IoT devices, core network nodes, etc.). - The UE state module 45 is responsible for managing an operating state of the mobile device 3 (e.g. by obtaining appropriate configuration (such as state transition timer(s), information identifying a RAN paging area) and information identifying UE location, cell information, etc.) and control the other modules (e.g. the RRC module 46 and the NAS module 49) according to the current operating state of the
mobile device 3. - The RRC module 46 is operable to generate, send and receive signalling messages formatted according to the RRC standard. For example, such messages are exchanged between the
mobile device 3 and its serving base station 5. The RRC messages may include, for example, messages relating to establishing/resuming an RRC connection with an appropriate base station 5. - The NAS module 49 is operable to generate, send and receive signalling messages formatted according to the NAS standard. For example, such messages are exchanged between the
mobile device 3 and the MME 9 (via the serving base station 5, using the RRC module 46). The NAS messages may include, for example, messages relating to registering and/or updating a tracking area (or cell) where themobile device 3 is currently located. - Base Station
FIG. 3 is a block diagram illustrating the main components of a base station 5 shown inFIG. 1 . As shown, the base station 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from user equipment (such as themobile device 3/IoT device 3′) via one or more antenna 53, a core network interface 55 (e.g. an S1 interface, NG-C interface, and/or the like) for transmitting signals to and for receiving signals from the core network 7, and a base station interface 56 (e.g. an X2 interface, Xn interface, and/or the like) for transmitting signals to and for receiving signals from neighbouring base stations. The base station 5 has a controller 57 to control the operation of the base station 5. The controller 57 is associated with a memory 59. Although not necessarily shown inFIG. 3 , the base station 5 will of course have all the usual functionality of a cellular telephone network base station and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 59 and/or may be downloaded via thetelecommunications network 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the base station 5 by, in this example, program instructions or software instructions stored within the memory 59. As shown, these software instructions include, among other things, an operating system 61, a communications control module 63, a UE state module 65, an RRC module 66, an X2 module 67, and an S1AP module 68. - The communications control module 63 is operable to control the communication between the base station 5 and user equipment (
mobile device 3/IoT device 3′) and other network entities that are connected to the base station 5. The communications control module 63 also controls the separate flows of downlink user traffic (via associated data radio bearers) and control data to be transmitted to the communication devices associated with this base station 5 including, for example, control data for managing operation of themobile device 3 and/or theIoT device 3′. - The UE state module 65 is responsible for managing and monitoring the operating states of
mobile devices 3 served by the base station 5 (e.g. by generating and sending appropriate configuration, such as state transition timer(s), information identifying a RAN paging area, etc.) and, when appropriate, providing information on the current operating state of a particularmobile device 3 to other nodes (e.g. the MME 9). - The RRC module 66 is operable to generate, send and receive signalling messages formatted according to the RRC standard. For example, such messages are exchanged between the base station 5 and the mobile device 3 (and other user equipment within the cell of the base station 5). The RRC messages may include, for example, messages relating to establishing/resuming an RRC connection for a particular
mobile device 3. - The X2 module 67 is operable to generate, send and receive signalling messages (X2/Xn messages) formatted according to the X2AP (or XnAP) standard. The X2/Xn messages may include, for example, messages relating to paging a
mobile device 3, data forwarding, transferring/fetching of UE context (and other information relating to the mobile device 3) between neighbouring base stations. - The S1AP module 68 is operable to generate, send and receive signalling messages formatted according to the S1AP (or NG-C AP) standard. For example, such messages are exchanged between the base station 5 and the mobility management entity (MME) 9. The S1AP messages may include, for example, messages relating to registering the location and/or operating state (e.g. LC) of user equipment in a cell of the base station and/or associated responses.
- Mobility Management Entity
FIG. 4 is a block diagram illustrating the main components of the mobility management entity (MME) 9 shown inFIG. 1 . As shown, the mobility management entity 9 has atransceiver circuit 71 for transmitting signals to and for receiving signals from the base stations 5 (and/or communication devices connected to the base stations 5) via a base station interface 75 (e.g. an S1 interface). The mobility management entity 9 has a controller 77 to control the operation of the mobility management entity 9. The controller 77 is associated with a memory 79. Although not necessarily shown inFIG. 4 , the mobility management entity 9 will of course have all the usual functionality of a cellular telephone network mobility management entity and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 79 and/or may be downloaded via thetelecommunications network 1 or from a removable data storage device (RMD), for example. The controller 77 is configured to control the overall operation of the mobility management entity 9 by, in this example, program instructions or software instructions stored within the memory 79. As shown, these software instructions include, among other things, an operating system 81, a communications control module 83, a UE state/location registration module 85, anS1AP module 88, and a NAS module 89. - The communications control module 83 is operable to control the communication between the mobility management entity 9 and the base stations 5,
mobile devices 3, IoT devices, and other network entities that are connected to the mobility management entity 9. - The UE state/location registration module 85 is responsible for keeping track of current location and state (e.g. idle or connected) of user equipment connected to the MME 9.
- The
S1AP module 88 is operable to generate, send and receive signalling messages formatted according to the S1AP (or NG-C AP) standard. For example, such messages are exchanged between the mobility management entity 9 and connected base stations 5. The S1AP messages may include, for example, messages relating to registering the location and/or operating state (e.g. LC) of user equipment in a cell of the base station, requesting data forwarding, requesting path switching, and/or associated responses. - The NAS module 89 is operable to generate, send and receive signalling messages formatted according to the NAS standard. For example, such messages are exchanged between the MME 9 and the mobile device 3 (via a base station 5, using the S1AP module 88). The NAS messages may include, for example, messages relating to registering and/or updating a tracking area (or cell) where the
mobile device 3 is currently located. - In the above description, the
mobile device 3, the base station 5, and the mobility management entity 9 are described for ease of understanding as having a number of discrete modules (such as the communications control modules and the UE state modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these. - A more detailed description will now be given (with reference to
FIGS. 5 to 7 ) of the scenario discussed above where a mobile device operating in LC state moves between cells operated by different base stations. -
FIG. 5 is a timing diagram (message sequence chart) illustrating an example process performed by components of thenetwork 1 when performing a paging operation for a mobile device (UE or IoT device) operating in LC state. - It will be appreciated that in this example, the new base station 5 c is a base station configured in accordance with Rel-14 standards (or later) and hence it supports user equipment operating in LC mode.
- Initially, the
mobile device 3 operates in LC state and its previous serving base station 5 b acts as an anchor base station for themobile device 3. Accordingly, the anchor base station 5 b (using its UE state module 65) stores the UE context associated with themobile device 3 and configures an appropriate RAN based paging area for the mobile device 3 (e.g. by providing a list of cells and/or paging area IDs to the mobile device 3) while terminating S1. When themobile device 3 leaves the area (Cell #1) served by the anchor base station 5 b (and/or the signal conditions inCell # 1 deteriorate), themobile device 3 selects a new cell to camp on that has more favourable signal conditions. In this example themobile device 3 selects and camps onCell # 2 which is operated by the base station 5 c. Since themobile device 3 has no active connections with the radio access network, the anchor base station 5 b is not aware of the mobile device's 3 current location (Cell #2). From the perspective of the anchor base station 5 b, therefore, themobile device 3 is deemed to be idle (in LC state). - Whilst the
mobile device 3 is deemed to be operating in the LC state, the MME 9 (using its UE state/location registration module 85) maintains an associated S1 connection (ECM-CONNECTED state) even when themobile device 3 is operating in an idle mode from the RAN's point of view (which may not be visible by the MME 9). Accordingly, as generally shown in steps S501 a and S501 b, when the MME 9 has downlink data to send to the mobile device 3 (e.g. control-plane signalling/user-plane data), the MME 9 (using its S1AP module 88) starts transmitting the downlink data to the anchor base station 5 b without performing paging. It will also be appreciated that in some cases, a different core network node, e.g. the S-GW 10 may transmit downlink data to the anchor base station 5 b. - In response to receiving the downlink data from the MME 9, the controller 57 of the anchor base station 5 b triggers, in step S502, RAN-based paging, which typically involves transmitting paging signalling via the Uu interface, via the X2 interface, or both. In step S503, the anchor base station 5 b performs RAN based paging of the
mobile device 3 within the paging area that is appropriate for thatmobile device 3. Although not shown inFIG. 5 , the anchor base station 5 b may also send appropriate X2 paging signalling to its neighbour base station(s) 5 in order to attempt to reach themobile device 3 via neighbour cells. Effectively, the RAN based paging indicates to themobile device 3 that it needs to resume its RRC connection (re-connect) via the anchor base station 5 b or another appropriate base station for receiving the downlink data. - At the start of the paging, the anchor base station 5 b starts an appropriate timer (e.g. a paging timer) and stores the downlink data from the MME 9 (or S-GW 10) in its local cache (memory 59).
- In this example, the
mobile device 3 is unable to receive (or respond to) the paging signalling. This might happen, for example, when the anchor base station 5 b does not perform paging via its neighbours (even thoughCell # 2 may belong to the currently configured RAN paging area), whenCell # 2 does not belong to the paging area configured for themobile device 3, or when signal conditions at the edge ofCell # 2 prevent themobile device 3 from successfully receiving (or responding to) paging signalling in that cell. - As generally shown in step S504, if the anchor base station 5 b does not receive any response from the
mobile device 3 within a predefined time interval (e.g. at expiry of the paging timer), the base station 5 b proceeds to requesting help from the MME 9. - Specifically, the anchor base station 5 b generates and sends, in step S505, and appropriately formatted S1 signalling message (such as a ‘UE Context Release Request’ and/or the like) requesting the MME 9 to initiate S1 based (legacy) paging procedures. As shown in
FIG. 5 , the message from the base station 5 b may also indicate (or it may be interpreted such) that the MME 9 does not need to trigger a release of the mobile device's 3 bearer via the S-GW 10. - However, before the MME 9 can proceed to assist the base station 5 b (e.g. by initiating a network-wide paging procedure), the MME 9 needs to align the UE state from connected to idle (ECM-CONNECTED to ECM-IDLE). Therefore, upon receipt of the message at S505, the MME 9 (using its UE state/location registration module 85) moves the S1 connection for the
mobile device 3 into idle (e.g. ECM-IDLE) and then it proceeds to initiating legacy paging procedures in the last know tracking area of themobile device 3 in step S506. Therefore, the MME 9 generates (using its S1AP module 88) and sends, in step S507, and appropriately formatted paging request to the base stations 5 operating cells that belong to the last know tracking area (including the new base station 5 c). - As shown, the MME's paging request triggers the new base station 5 c to carry out, in step S508, appropriate paging for the
mobile device 3 over the Uu interface (in Cell #2). However, as shown inFIG. 5 , the MME 9 and the S-GW 10 do not carry out a ‘Release Access Bearer’ procedure, i.e. the MME 9 maintains the existing S1 bearer for themobile device 3 via the S-GW 10 despite having received a UE Context Release Request from the base station 5 a. - After triggering the S1 based paging, the MME 9 waits for a response from the
mobile device 3. In this example, as generally shown in step S509, themobile device 3 responds to the Uu paging request by the new base station 5 c by performing appropriate RRC and S1 connection setup procedures (via Cell #2). Typically, step S509 involves the mobile device 3 (using its NAS module 49) generating and sending an appropriately formatted handover request to the MME 9 (via the new base station 5 c). Using its UE state/location registration module 85, the MME 9registers Cell # 2 as the mobile device's 3 new location. As part of step S509, the MME 9 may also indicate (for example, in an appropriately formatted ‘Initial Context Setup request’ and/or the like) to the new base station 5 c that data forwarding from the anchor base station 5 b to the new base station 5 c is imminent so that the new base station 5 c is able to prepare appropriate resources for receiving the forwarded data. - Beneficially, the MME 9 may be configured to monitor (preceding) handovers performed by the
mobile device 3 and obtain (hold in memory 79) context information and other parameters relating to themobile device 3. Therefore, the MME's 9 message to the new base station 5 c may also include one or more of the following information held by the MME 9: an appropriate identifier associated with the mobile device 3 (e.g. a Resume Id) that the new base station 5 c may use for context fetching; information identifying themobile device 3 at the MME 9 over the S1 interface (e.g. ‘MME UE S1AP ID’); information identifying the anchor base station 5 b (e.g. an ‘anchor eNB ID’); a TAC of the anchor base station 5 b; a Globally Unique MME ID (GUMMEI) associated with the MME 9 currently serving themobile device 3, a handover restriction list (e.g. a list of cell identifier for cells to which a handover of themobile device 3 is not allowed), and other parameter found in previously handled handover requests relating to themobile device 3. - Similarly, the MME 9 is able to provide information relevant to the anchor base station 5 b in order to perform data forwarding. Thus, in step S510, the MME 9 requests the anchor base station 5 b to perform data forwarding by generating and sending an appropriate S1 signalling message to the anchor base station 5 b (e.g. a ‘UE Context Release Command’ and/or the like). In this example, the MME 9 sends the UE Context Release Command to the anchor base station 5 b and includes information identifying the new base station 5 c (e.g. an eNB ID/gNB ID) and information identifying an appropriate forwarding address for the new base station 5 c (e.g. a tunnel endpoint identifier (TEID) and/or the like). The new base station 5 c is thus able to trigger an appropriate procedure (e.g. by generating and sending a ‘Retrieve UE Context Request’ to the anchor base station 5 b) in order to fetch the context relating to the
mobile device 3 from the anchor base station 5 b. Although not shown in detail inFIG. 5 , the anchor base station 5 b generates and transmits an appropriately formatted ‘Retrieve UE Context Response’ to the new base station 5 c including the requested UE context. - After a successful X2-based (or S1-based) context retrieval, the base stations 5 proceed to SN Status transfer and data forwarding. Specifically, the anchor base station 5 b (using its X2 module 67) generates and sends, in step S511, and appropriate ‘SN Status transfer’ message in order to transfer the status of the transceiver (uplink receiver status/downlink transmitter status) relating to the
mobile device 3. It will be appreciated that the status of the transceiver may include respective Packet Data Convergence Protocol (PDCP) sequence numbers (SNs) used in the uplink and downlink direction which allow the new base station 5 c to preserve the status following themobile device 3 resuming its connection with the network viaCell # 2. - In step S512, the anchor base station 5 b (using its X2 module 67) starts forwarding, to the new base station 5 c using the forwarding address provided by the MME 9, any cached downlink data, and the new base station 5 c relays the forwarded data (not shown in
FIG. 5 ) to themobile device 3 via the Uu interface. - As generally shown in step S513, the MME 9 and the new base station 5 c also initiates an appropriate path switch procedure (comprising a ‘Path Switch Request’ including information identifying the path to be switched (e.g. in an ‘MME UE S1AP ID’ information element) and an associated acknowledgement). In response to the path switch procedure the MME 9 also requests, in step S514, the S-GW 10 to modify the bearer associated with the mobile device 3 (i.e. to tunnel data to the new base station 5 c instead of the anchor base station 5 b). Once the bearer has been modified, there is no need for the anchor base station 5 b to forward downlink data to the new base station 5 c.
- After the path switch triggered by new base station 5 c (in step S513), the new base station 5 c is able to trigger UE context release towards the old (anchor) base station 5 b. In more detail, after switching the path (S1 connection) associated with the
mobile device 3 from the anchor base station 5 b to the new base station 5 c, the new base station 5 c generates and sends, in step S515, a UE Context release message indicating to the anchor base station 5 b that the anchor base station 5 b no longer needs to store the UE context associated with themobile device 3. Effectively, this message prompts the anchor base station 5 b to delete the UE context associated with the mobile device 3 (e.g. after transferring the UE context to the new base station 5 c) and thus the new base station 5 c becomes the new anchor base station for themobile device 3. In step S516, the former anchor base station 5 b confirms that the UE context release has been completed by generating and sending an appropriate S1 acknowledgement to the MME's 9 command. -
FIG. 6 is a timing diagram (message sequence chart) illustrating another example process performed by components of thenetwork 1 when performing a paging operation for a mobile device (UE or IoT device) operating in LC state. In this example, which is a modification of the example described with reference toFIG. 5 , the new base station 5 c is a base station configured in accordance with pre-Rel-14 standards (and hence it is not capable of receiving forwarded data from the anchor base station 5 b). Therefore, in this example, the anchor base station 5 b is configured to forward any cached data to the S-GW 10. - Steps S601 a to S608 correspond to steps S501 a to S508 described above hence their description is omitted herein for brevity.
- However, in this example, after the MME 9 sending a paging request to the new base station 5 c (in step S607) and the new base station 5 c paging the
mobile device 3 via the Uu interface (in step S608), the MME 9 and themobile device 3 proceed to step S609, and themobile device 3 performs a legacy RRC connection establishment procedure in order to receive its downlink data. - In more detail, the
mobile device 3 responds to the paging on the Uu interface by initiating and performing appropriate RRC (with the new base station 5 c) and S1 (with the MME 9 through the new base station 5 c) connection setup procedures (e.g. because base station 5 c is a pre-Rel-14 base station). The MME 9 (using its controller 77) also determines that the current serving cell (Cell #2) of themobile device 3 is operated by a base station 5 c which is configured in accordance with pre-Rel-14 standards. - Therefore, in step S610, the MME 9 (using its S1AP module 88) generates and sends a UE Context Release Command (and/or the like) to the anchor base station 5 b, requesting the anchor base station 5 b to perform data forwarding to the S-GW 10.
- Accordingly, in step S612, the anchor base station 5 b starts data forwarding to the S-GW 10 (for delivery to the
mobile device 3 via the S-GW 10 using the new S1 connection established for themobile device 3 via Cell #2). Beneficially, even though the new base station 5 c is a pre-Rel-14 base station, downlink data intended for themobile device 3 and that has been already sent to the anchor base station 5 b can still be delivered to themobile device 3 via the S-GW 10 using the new S1 connection that was set up in step S609. It is possible therefore to avoid loss and/or unnecessary retransmissions of the downlink data for the mobile device (UE or IoT device) operating in LC state. - In step S616, the anchor base station 5 b releases the UE context, as requested, then it generates and sends an appropriate response to the MME's 9 request received at step S610.
- In another beneficial example, the base stations 5 may be configured to notify the MME 9 that certain operations are not possible for the
mobile device 3 because it is currently operating in LC state. Such MME operations may include, for example, load balancing, TAU required, PSM, MT CSFB, and/or the like. In this case, therefore, even if the MME 9 continues to see themobile device 3 as being in a connected state (S1 connected/ECM-CONNECTED), the MME 9 is able to avoid such procedures (which would most likely fail or be ineffective). - Beneficially, the serving/anchor base station 5 (in this example, the base station 5 b) is configured to send, to the MME 9, information identifying whether the
mobile device 3 is operating in LC state and/or whether certain MME operations are to be avoided (or banned). For example, this information may be included in an appropriately formatted information element (IE) associated with themobile device 3, such as an IE of an appropriate UE associated signalling message, such as a ‘UE Status Notification’ message and/or the like. - It will be appreciated that the IE may include information identifying the mobile device 3 (e.g. an ‘MME UE S1AP ID’ and/or an ‘eNB UE S1AP ID’) and information indicating that certain MME operations are not possible for that particular device. The information indicating that certain MME operations are not possible may comprise: a flag (1-bit) indicating that certain pre-configured MME operations are banned for identified
mobile device 3; and/or an enumerated list (and/or the like) identifying the particular operations that are not possible for themobile device 3. The contents of an exemplary IE are shown in Table 1. -
TABLE 1 an exemplary IE indicating banned MME operations IE/Group IE type and Semantics Assigned Name Presence Range reference description Criticality Criticality Message M 9.2.1.1 YES reject Type MME UE M 9.2.3.3 YES reject S1AP ID eNB UE M 9.2.3.4 YES reject S1AP ID MME List of MME Operation operations banned that are List/flag banned on this UE - Beneficially, the above procedures allow the MME 9 to maintain information on the accurate state/location of the
mobile device 3 even when themobile device 3 operates in the LC state. Accordingly, the MME 9 can avoid performing and/or requesting procedures that would otherwise be inappropriate for the current operating state of themobile device 3. In the case of CSFB, for example, the MME 9 may be configured to avoid responding positively to the node initiating CSFB (e.g. an MSC) straight away—instead, the MME 9 may be configured to wait until it receives updated information from base station (e.g. that themobile device 3 is no longer in LC state and/or CSCF is no longer banned for that particular mobile device 3). - In order to reduce any potential delay caused by the need to resume a mobile device's connection via a different based station than its anchor base station (in this example, resuming the mobile device's 3 connection via base station 5 c and Cell #2), the base stations 5 of this system are beneficially configured to exchange information with each other relating to the mobile devices 3 (users) for which they are configured to act as an anchor base station.
- Specifically, the base stations 5 (at least the ones which operate as an anchor base station) are configured to provide, to their neighbour base station(s), information identifying any suspended bearers, UE AS context, security context at that particular base station 5, and/or the
mobile devices 3 associated with such suspended bearers. Alternatively, each anchor base station 5 may be configured to exchange (via X2) the unique identifiers that identify each UE for other neighbours for performing context pre-fetch. - It will be appreciated that each base station 5 may hold (in its associated UE state module 65) information relating to bearers/mobile devices served by that base station. Such information may include, for example, an associated identifier (e.g. a ‘UE RRA Identifier’, a ‘Resume ID’, and/or the like) used within the RAN routing area (RRA).
- For example, for any base station 5 to be able to uniquely identify a particular UE and to determine as to where to fetch the associated context from, an appropriate identifier may be constructed using the RAN Routing Area ID/tracking area code (TAC) of the anchor base station 5 b, an identifier of the base station itself (e.g. an eNB ID/gNB ID), and a random number (e.g. a binary number).
- Using appropriate X2 signalling, neighbour base stations 5 (anchor base stations) may be configured to exchange the identities of UEs being anchored by them. Anchor base stations 5 may also exchange their respective RAN Routing Area Identifiers used for the anchored mobile devices 3 (at least with their neighbours within the same RAN Routing Area).
- Beneficially, using the information relating to
mobile devices 3 anchored by their neighbours, each base station 5 may be configured to pre-fetch each UE context in order to minimize latency at the time of handover or idle mode mobility of thesemobile devices 3. - Context pre-fetching may be applied to all anchored mobile devices. Alternatively, context fetching may be applied selectively, e.g. to
mobile devices 3 of a specific type (e.g. MTC/IoT devices only). When network sharing/slicing is in place, context pre-fetching may be applied tomobile devices 3 accessing a certain network slice/type of network slice (e.g. Slice Network Template) and/ormobile devices 3 belonging to certain tenant types. Moreover, context pre-fetching may also be applied selectively to stationary/non-stationary UEs (as appropriate). - It will be appreciated that context pre-fetching may be particularly useful for Ultra-Reliable and Low Latency Communications (URLCC) use cases.
- Pre-fetching and maintaining a common RRA UE Identifier pool within a RRA (using identifiers constructed as described above) also allows the base stations to address
mobile devices 3 uniquely within an RRA. By constructing appropriate RRA identifiers that are unique per UE (across different cells/base stations within an RRA) cell update and mobility (in idle or connected mode) become easier and can be performed with a sufficiently low latency even for mobile devices operating in the LC state. - Modifications and Alternatives
- Detailed example embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above example embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.
- It will be appreciated that example embodiments of the invention may be particularly beneficial for Internet of Things (or machine-type) data transmissions (e.g. transmission of data acquired during measurement events and the like). However, it will be appreciated that the example embodiments are also beneficially for transmission of any form of data depending on the application in which the communication device is being used. For example, the above example embodiments may be applicable for transmitting data such as user data, backup data, synchronisation data, diagnostic data, monitoring data, usage statistics, error data and/or the like.
- In
FIG. 1 , an X2 interface is provided between two neighbouring base stations and an S1 interface is provided between each base station and the core network. However, it will be appreciated that in other systems, a different base station to base station interface and/or a different base station to core network interface may be provided. For example, in 5G systems the interface between neighbouring base stations is referred to as the ‘Xn’ interface and the interface between a base station and the core network is referred to as the ‘NG-C’ interface. In 5G systems, base stations are referred to as gNBs. - In the above example embodiments, a 3GPP radio communications (radio access) technology is used. However, any other radio communications technology (i.e. WLAN, Wi-Fi, WiMAX, Bluetooth, etc.) can be used for managing transmissions of IoT devices in accordance with the above example embodiments. The above example embodiments are also applicable to ‘non-mobile’ or generally stationary user equipment.
- In the above description, the mobile device, the base station, and the MME are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.
- In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the base station, to the mobility management entity, to the mobile/IoT device, or to other user equipment as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the base station, the mobility management entity, or the mobile device in order to update their functionalities.
- It will be appreciated that the above described UE Status Notification may be implemented as a ‘class-1’ procedure requiring a response as well (from the MME to the base station sending the UE Status Notification). Alternatively, it may be implemented as a ‘class-2’ procedure requiring only a notification from the base station (but no response from the MME).
- In the above described fourth example, the base stations are configured to exchange information with each other in order to facilitate a swift resumption of anchored mobile devices connection. In another example, the base station may assist a mobile device in order to speed up the transition between LC mode and connected mode. Specifically, the base station may provide appropriate random access channel (RACH) preample information to the mobile device (e.g. whilst in connected mode) for use by the mobile device when it needs to transit to connected mode (e.g. when the mobile device has new uplink data to send after a period of inactivity). It will be appreciated that the RACH preample may be specific to a particular mobile device so that the base station is able to retrieve the associated UE context upon receipt of the preamble (i.e. in the early phase of connection resumption). Thus, by transmitting the appropriate (pre-allocated) RACH preample at the time of resuming its connection, the mobile device is able to transition from LC mode to connected mode without unnecessary delay.
- In one option, the base station may provide the RACH preample to the mobile device when the mobile device is brought (by the base station) to LC mode from connected mode. In this case, the preamble information may be encoded in an appropriate message used by the base station to instruct the mobile device to move from connected mode to LC mode. The message may comprise an RRC Connection Release message and/or the like. In another option, the preamble information may be dynamically provided to a particular mobile device at the time of a UE-terminated call for that mobile device. In this case, the message may comprise an RRA Paging message and/or the like. In yet another option, the preamble information may be dynamically provided using system information block (SIB) on-demand signalling.
- The base station may also be configured to set a maximum validity for the RACH preample allocated to the mobile device. For example, the base station may set a timer (which may be provided to the mobile device together with the allocated preamble or separately). Thus, if the mobile device remains in LC mode for longer than a threshold (measured by the timer) without making any UL/DL data transmission, the base station may move the mobile device from LC mode to idle mode (upon expiry of the timer). This beneficially allows the base station to allocated unused preambles for other mobile device (if required).
- In order to assist maintaining up-to-date location information in the core network, the base station may be configured to synchronise any RRA update made by the mobile device with a corresponding tracking area update (TAU) towards the core network (MME). Specifically, when the base station receives a RRA update from a mobile device (e.g. when the mobile device moves to a new cell), the base station may be configured to map the RRA to a corresponding TA and initiate a conventional TAU on behalf of the mobile device. Beneficially, the base station may implement an appropriate local location management system per RRA (e.g. a local database mapping RRA/cell information to tracking area information). The base station may be configured to use the RRA Identifier of the mobile device in order to obtain the appropriate core network identity (e.g. a Globally Unique Temporary ID (GUTI), a Temporary International Mobile Subscriber Identity (T-IMSI), and/or the like) associated with the mobile device. The obtained core network identity is then used in the TAU request generated by the base station on behalf of the mobile device.
-
FIG. 7 is a timing diagram (message sequence chart) illustrating another example process performed by components of the system when resuming a connection for transmitting uplink data in LC mode. This process may be particularly beneficial for transmission of small data packets. Whilst this example is similar to the solution presented in 3GPP draft R2-165538, the RRC Connection Resume Request in this case includes information indicating whether the mobile device wishes to resume its connection for a single transmission or multiple transmissions. Accordingly, the base station is able to allocate appropriate resources and configure the mobile device accordingly. In effect, the mobile device may be able to remain in LC mode or move to connected mode only for the indicated (single or multiple) transmission(s). In this case the mobile device is also beneficially able to return to LC mode more quickly following the transmission(s). - The message (sent by the base station to the core network node) may comprise an S1AP: UE Context Release Request. The message may include at least one of i) an indication S1 paging is required for the communication device; ii) an indication that the communication device is an idle (or light-connected (LC)) condition; and/or iii) an indication that a communication bearer for the communication device should not be released.
- The transceiver of the base station may be configured to receive, from the core network node (e.g. in response to said message to request initiation of a paging procedure), a message requesting the base station to initiate forwarding of the received downlink data to another node (e.g. another base station or a gateway node). In this case, the received message requesting the base station to initiate forwarding may include information identifying a new base station serving the communication device (e.g an eNB ID and/or a forwarding address/TEID). The controller of the base station may be configured to control the transceiver to forward the downlink data to at least one of: a new base station; and a core network entity; based on said message requesting the base station to initiate forwarding.
- The controller of the base station may be configured to control the transceiver to provide a context associated with the communication device to another base station as part of a context fetching procedure (e.g. an X2 based context fetching procedure). The attempt to initiate communication with the communication device may comprise attempting paging of the communication device, and said message to request initiation of a paging procedure for the communication device may be sent when the communication device does not respond to said paging.
- The controller of the base station may be configured to control the transceiver to send a notification (e.g. a UE status notification) to the core network node indicating that at least one core network operation is not possible (or banned). The notification may comprise a
class 1 notification requiring a response. Alternatively, the notification may comprise aclass 2 notification. The notification may comprise at least one of a flag and a list indicating one or more operations that are not possible/banned. - The communication device may be in an idle state (e.g. an idle state in a lightweight connected, ‘LC’, mode). The base station may be configured to operate as an anchor base station for the communication device which maintains information identifying the communication device in association with context information for that communication device and/or terminates an associated S1 communication bearer for the communication device.
- The controller of the base station may be configured to control the transceiver to fetch a context associated with the communication device from the other base station as part of a context fetching procedure (e.g. an X2 based context fetching procedure). The controller of the base station may be configured to control the transceiver to provide, to the core network node, a message configured to trigger initiation of a path switching procedure.
- The controller of the core network apparatus may be configured to move the communication device into an idle state (e.g. ECM-IDLE) from a connected state (e.g. ECM-CONNECTED) and to trigger paging in a previously known tracking area (TA). The controller may be configured to move the communication device into said idle state without releasing a communication bearer associated with the communication device.
- The core network apparatus may comprise a mobility management entity (‘MME’).
- The transceiver of the core network apparatus may be configured to send, to the base station (e.g. in response to said message to request initiation of a paging procedure), a message requesting the base station to initiate forwarding of the received downlink data to another node (e.g. another base station or a gateway node). The message requesting the base station to initiate forwarding may include information identifying a new base station serving the communication device (e.g an eNB ID and/or a forwarding address/TEID).
- The controller of the core network apparatus may be configured to control the transceiver to send, to another base station, a message (e.g. an Initial Context Setup Request) indicating that data forwarding from the base station is to happen for the communication device, together with at least one of: an identifier, associated with the communication device, for use in fetching a context relating to the communication device from the other base station; information identifying the communication device at the core network apparatus over an S1 interface (e.g. ‘MME UE S1AP ID’); information identifying the base station (e.g. an ‘anchor eNB ID’); a tracking area code (TAC) associated with the base station; a globally unique ID (e.g. a GUMMEI) associated with the core network apparatus; information identifying at least one cell identifier for at least one cell to which a handover of the communication device is prohibited; and at least one other parameter acquired by the core network apparatus in a previously handled handover request relating to the communication device.
- The controller of the core network apparatus may be configured: to control the transceiver to receive, from another base station, a message configured to trigger initiation of a path switching procedure; and to initiate the path switching procedure accordingly. The message configured to trigger initiation of a path switching procedure may comprise an MME UE S1AP ID IE for the communication device.
- Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
- The following is a detailed description of the way in which some of the above procedures may be implemented in the currently proposed 3GPP standard. Whilst various features are described as being essential or necessary, this may only be the case for the proposed 3GPP standard, for example due to other requirements imposed by the standard. These statements should not, therefore, be construed as limiting the present invention in any way.
- In RAN3 #93bis, it was argued that RAN-based paging might fail and hence, there has to be a mechanism in place for an eNB to seek MME for paging assistance. Although it may seem that RAN-based paging may not fail unless UE is switched off, failed or has slipped out of cellular coverage, it is better to have a fall back mechanism for the purpose of getting an eNB to resort to CN-based paging, if necessary. Although some basic solutions were presented in RAN3 #93bis, it is better to look into it in depth in order to make it proper.
- The objective of this paper is to make a CN-based paging work if sought by an eNB. Further it explores, the various ways to make such a CN-based paging to work especially in mixed-deployment cases.
- 2.1 Conserving Network Resource
- Although different companies put forward arguments that are in favour of or against RAN-based paging, the basic tenet was to reduce core signalling by hiding UE state transitions between the legacy and new states. Although signalling can be minimised on S1, resources would be permanently allocated for a UE especially on S1 together with active state maintenance. This does not come for free given the fact that MME can easily be overloaded that may either trigger S1 release with a cause of Load balancing TAU required or S1 Overload Start/Stop. Given that UE does not maintain RRC connection when it takes the new LIGHT-CONNECTED State, triggering fact that MME can easily be overloaded that may either trigger S1 may defeat the purpose of this WI. Hence, it is more appropriate for an anchor eNB to release UE context if a UE does not transmit/receive data within a time period.
- Observation 1: If a UE hardly transmit/receive data, it is better for an Anchor eNB to move a UE from LIGHT-CONNECTED to RRC-IDLE State to conserve network resources.
- When an anchor eNB moves a UE from LIGHT-CONNECTED to RRC-IDLE State after a time out, it can trigger S1-AP: UE Context Release Request for the purpose of releasing S1 resources and states.
- Proposal 1: RAN3 is respectfully requested to ensure that a UE is not configured to take LIGHT-CONNECTED State indefinitely unless otherwise it is necessary and S1 resources are released after a time out.
- 2.2 Identifying a UE Uniquely Across Neighbour eNBs
- For context retrieval purposes, a new or existing identifier (e.g. Resume Id) that can be used for identification purposes especially by the E-UTRAN when a UE takes LIGHT-CONNECTED State needs to be unique across neighbours. For instance when a UE tries to resume with a Resume Id that is not comprehensible to a new eNB in terms of which eNB to contact in order to fetch associated UE context. This is especially difficult when there is no X2 between an anchor eNB and a new eNB.
- Observation 2: UE has to be uniquely identified across neighbour eNBs for context retrieval purposes.
- If the new or existing identifier includes tracking area code (TAC) or RAN Routing Area Code (i.e. the RAN routing area code that is analogous to TAC) and eNB Id. This way a new eNB can determine the exact anchor eNB from which to fetch a UE context.
- Proposal 2: RAN3 is respectfully requested to ensure that a new or existing identifier (e.g. ResumeID) includes tracking area code (TAC) or RAN Routing Area Code (i.e. the RAN routing area code that is analogous to TAC) and eNB ID.
- 2.3 Non-Transparent Nature of New State
- It is one of the design principles that the new UE state is hidden from MME. In other words, whenever an eNB configures a UE to take this new state, it does not explicitly notify an MME. As a result, a UE which takes LIGHT-CONNECTED State is considered to be in ECM-CONNECTED mode from the perspectives of an MME. Hence, it is inappropriate for an eNB to suddenly seek an MME for CN-based legacy paging.
- Observation 3: When UE takes LIGHT-CONNECTED state, it is inappropriate for an eNB to seek CN-assistance without aligning states.
- Given the limited coverage size of RAN-based paging, it is always better to seek CN assistance in case an anchor eNB finds it difficult to reach out an UE for MT data. However, MME has to be brought back to the normal state in terms of how a UE in question is seen by an MME before a help of MME can be sought in this respect by an eNB.
- Observation 4: MME has to be made to move a UE from ECM-CONNECTED to ECM-IDLE for triggering a legacy paging.
- In other words, an MME has to move a UE from ECM-CONNECTED to ECM-IDLE mode before it can trigger a legacy-based paging. Existing procedures and messages can be used for this purpose. As it is depicted in
FIG. 8 , for instance, an anchor eNB can trigger a UE Context Release procedure whenever an anchor eNB cannot reach out a UE through its RAN-based paging. Using the eNB-triggered UE Context Release mechanism on S1, the anchor eNB can additionally seek MME assistance for paging while releasing S1 context. This in turn can get an MME to initiate the legacy paging and suppose a UE makes the connection/resume request from a new eNB, MME can pass those details to an old and new anchor eNB for either X2-based or S1-based context retrieval and subsequent data forwarding. In Step 9, an MME can indicate to a new eNB that data forwarding from an old anchor eNB is to happen in Initial Context Setup Request message, together with UE identifiers for context fetch (e.g. Resume Id), MME UE S1AP ID, old anchor eNB ID, TAC of an old anchor eNB and other key parameters that can be found in HO Request message. Similarly, an old anchor eNB can be notified by an MME in terms of new eNB ID, TEID and data forwarding address using existing legacy UE Context Release command. A new eNB can trigger RETRIEVE UE CONTEXT REQUEST with a passed on details of an old anchor eNB which in turn respond with RETRIEVE UE CONTEXT RESPONSE. This context fetch can happen between Steps 10 and 11 inFIG. 8 although this is not shown for clarity. After X2-based or S1-based context retrieval, SN Status transfer and data forwarding can happen. After the path switch, the new eNB can trigger UE context release towards an old anchor eNB which in turn trigger S1-AP: UE Context Release Complete. - Observation 5: Existing S1-AP: UE Context Release procedure can be used for getting an MME to move UE from the ECM-CONNECTED to the ECM-IDLE State and to trigger S1-based paging.
- Proposal 3: RAN3 is respectfully requested to ensure that MME is put to the right state using existing procedures for the purpose of enabling an eNB to seek MME assistance for paging when RAN-based paging fails.
- 2.4 What Happens when UE Moves into Legacy Area
- It is difficult to ensure that a mobile network operator (MNO) rolled out completely new system within its service region. Hence, it is possible to find pockets of legacy eNB coverage. Under such circumstances, RAN-based paging can fail and it will be necessary for an anchor eNB to seek MME for paging assistance. In Step 10, an MME can request an old anchor eNB to forward data nack to S-GW. After data forwarding is complete, old anchor eNB can trigger S1-AP: UE Context Release Complete.
- Observation 6: S1-based paging is necessary when a UE moves into legacy eNB area.
- Proposal 4: RAN3 is respectfully requested to ensure existing procedure is used to get an old eNB to forward data back to S-GW when RAN-based paging fails in mixed deployment cases.
- Seeking MME assistance for paging may become necessary and this paper tries to ensure that MME states are aligned before MME assistance is sought. With this analysis, it makes the following 6 Observations and 4 proposals:
- Observation 1: If a UE hardly transmit/receive data, it is better for an Anchor eNB to move a UE from LIGHT-CONNECTED to RRC-IDLE State to conserve network resources.
- Proposal 1: RAN3 is respectfully requested to ensure that a UE is not configured to take LIGHT-CONNECTED State indefinitely unless otherwise it is necessary and S1 resources are released after a time out.
- Observation 2: UE has to be uniquely identified across neighbour eNBs for context retrieval purposes.
- Proposal 2: RAN3 is respectfully requested to ensure that a new or existing identifier (e.g. ResumeID) includes tracking area code (TAC) or RAN Routing Area Code (i.e. the RAN routing area code that is analogous to TAC) and eNB ID.
- Observation 3: When UE takes LIGHT-CONNECTED state, it is inappropriate for an eNB to seek CN-assistance without aligning states.
- Observation 4: MME has to be made to move a UE from ECM-CONNECTED to ECM-IDLE for triggering a legacy paging.
- Observation 5: Existing S1-AP: UE Context Release procedure can be used for getting an MME to move UE from the ECM-CONNECTED to the ECM-IDLE State and to trigger S1-based paging.
- Proposal 3: RAN3 is respectfully requested to ensure that MME is put to the right state using existing procedures for the purpose of enabling an eNB to seek MME assistance for paging when RAN-based paging fails.
- Observation 6: S1-based paging is necessary when a UE moves into legacy eNB area.
- Proposal 4: RAN3 is respectfully requested to ensure existing procedure is used to get an old eNB to forward data back to S-GW when RAN-based paging fails in mixed deployment cases.
-
- 3GPP R3-162432, “On common and Specific building blocks for Light connected UEs”, RAN3 #93bis, Ericsson, France, October 2016.
- 3GPP R3-162490, “Response to R3-162156”, RAN3 #93bis, NTT DoCoMo, France, October 2016.
- This application is based upon and claims the benefit of priority from United Kingdom patent application No. 1618663.7, filed on Nov. 4, 2016, the disclosure of which is incorporated herein in its entirety by reference.
Claims (8)
1. A user equipment (UE) comprising:
a memory storing instructions; and
at least one processor configured to process the instructions to:
transmit, to a first access network node, a request including a resume identity for resuming, to connected mode, a connection between the UE and a network including the first access network node, wherein
the resume identity includes an identifier indicating a second access network node which last served the UE in the network.
2. The UE according to claim 1 , wherein
the request causes the first access network node to retrieve a context for the UE from the second access network node using the identifier.
3. A first access network node, comprising:
a memory storing instructions; and
at least one processor configured to process the instructions to:
receive, from a user equipment (UE) a request including a resume identity for resuming, to connected mode, a connection between the UE and a network including the first access network node, wherein
the resume identity includes an identifier indicating a second access network node which last served the UE in the network.
4. The first access network node according to claim 3 , wherein
the at least one processor is configured to process the instructions to retrieve a context for the UE from the second access network node using the identifier.
5. A method for a user equipment (UE), the method comprising:
transmitting, to a first access network node, a request including a resume identity for resuming, to connected mode, a connection between the UE and a network including the first access network node, wherein
the resume identity includes an identifier indicating a second access network node which last served the UE in the network.
6. The method according to claim 5 , wherein
the request causes the first access network node to retrieve a context for the UE from the second access network node using the identifier.
7. A method for a first access network node, the method comprising:
receiving, from a user equipment, UE, a request including a resume identity for resuming, to connected mode, a connection between the UE and a network including the first access network node, wherein
the resume identity includes an identifier indicating a second access network node which last served the UE in the network.
8. The method according to claim 7 , comprising:
retrieving a context for the UE from the second access network node using the identifier.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/689,151 US20220191823A1 (en) | 2016-11-04 | 2022-03-08 | Communication system |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1618663.7 | 2016-11-04 | ||
GB1618663.7A GB2555784A (en) | 2016-11-04 | 2016-11-04 | Communication system |
PCT/JP2017/038723 WO2018084070A1 (en) | 2016-11-04 | 2017-10-26 | Communication system |
US201916347074A | 2019-05-02 | 2019-05-02 | |
US17/689,151 US20220191823A1 (en) | 2016-11-04 | 2022-03-08 | Communication system |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2017/038723 Continuation WO2018084070A1 (en) | 2016-11-04 | 2017-10-26 | Communication system |
US16/347,074 Continuation US11659517B2 (en) | 2016-11-04 | 2017-10-26 | Managing connection states for communications devices |
Publications (1)
Publication Number | Publication Date |
---|---|
US20220191823A1 true US20220191823A1 (en) | 2022-06-16 |
Family
ID=60320947
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/347,074 Active US11659517B2 (en) | 2016-11-04 | 2017-10-26 | Managing connection states for communications devices |
US17/689,151 Abandoned US20220191823A1 (en) | 2016-11-04 | 2022-03-08 | Communication system |
US18/137,240 Pending US20230254813A1 (en) | 2016-11-04 | 2023-04-20 | Managing connection states for communications devices |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/347,074 Active US11659517B2 (en) | 2016-11-04 | 2017-10-26 | Managing connection states for communications devices |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/137,240 Pending US20230254813A1 (en) | 2016-11-04 | 2023-04-20 | Managing connection states for communications devices |
Country Status (9)
Country | Link |
---|---|
US (3) | US11659517B2 (en) |
EP (2) | EP4290927A3 (en) |
JP (1) | JP2019537358A (en) |
KR (4) | KR20220045239A (en) |
CN (3) | CN116017695A (en) |
BR (1) | BR112019009028A2 (en) |
GB (1) | GB2555784A (en) |
RU (1) | RU2744010C2 (en) |
WO (1) | WO2018084070A1 (en) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11445564B2 (en) * | 2016-12-20 | 2022-09-13 | Apple Inc. | Apparatuses to switch between LTE rat and NR rat during transition from inactive state to active state |
US10951285B2 (en) * | 2017-01-06 | 2021-03-16 | Futurewei Technologies, Inc. | Hybrid mobility and radio resource management mechanisms |
US10999819B2 (en) * | 2017-04-20 | 2021-05-04 | Lg Electronics Inc. | Method and apparatus to support mobility in LWA |
WO2019024103A1 (en) * | 2017-08-04 | 2019-02-07 | Oppo广东移动通信有限公司 | Paging failure processing method, access network device, and core network device |
US10660063B2 (en) * | 2017-11-16 | 2020-05-19 | Comcast Cable Communications, Llc | Beam paging assistance |
US11153792B2 (en) * | 2018-04-18 | 2021-10-19 | Qualcomm Incorporated | Signaling for inactive mobility |
CN109314948A (en) * | 2018-09-04 | 2019-02-05 | 北京小米移动软件有限公司 | Transmit the method and device of lead code |
CN109526066A (en) * | 2018-11-05 | 2019-03-26 | 代志芬 | A kind of 5G base station system based on municipal highway road lighting network |
WO2020034572A1 (en) * | 2019-01-11 | 2020-02-20 | Zte Corporation | Information transmission for pre-configuring dedicated resources in idle mode |
WO2020198274A1 (en) * | 2019-03-28 | 2020-10-01 | Kyocera Corporation | Inactive mdt log with inactive duration |
US11172422B2 (en) * | 2020-03-18 | 2021-11-09 | Verizon Patent And Licensing Inc. | Systems and methods for anchor selection in a non-standalone wireless network environment |
WO2023004594A1 (en) * | 2021-07-27 | 2023-02-02 | Huawei Technologies Co.,Ltd. | Devices and method for configuration of a user device during small data transmission |
WO2023037586A1 (en) * | 2021-09-08 | 2023-03-16 | シャープ株式会社 | User equipment (ue), communication system, and communication method |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170202050A1 (en) * | 2016-01-12 | 2017-07-13 | Spreadtrum Communications (Shanghai) Co., Ltd. | Method for accessing cell, and base station |
US20170202051A1 (en) * | 2016-01-12 | 2017-07-13 | Electronics And Telecommunications Research Institute | Method and apparatus for reusing access stratum context through unique base station identifier, and method and apparatus for resuming radio resource control (rrc) connection by using the same |
US20190052607A1 (en) * | 2015-09-14 | 2019-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Radio access nodes and terminal devices in a communication network |
US20190320476A1 (en) * | 2016-09-30 | 2019-10-17 | Samsung Electronics Co., Ltd. | Method and apparatus for establishing dual-connectivity to transmit data in new radio communication architecture |
US20190357296A1 (en) * | 2015-11-17 | 2019-11-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Ue identifier in rrc resume |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9094933B2 (en) | 2008-01-14 | 2015-07-28 | Qualcomm Incorporated | Wireless communication paging utilizing multiple types of node identifiers |
KR20100092855A (en) | 2009-02-13 | 2010-08-23 | 엘지전자 주식회사 | Optimized paging method at home (e)nodeb system |
EP2317822A1 (en) * | 2009-10-29 | 2011-05-04 | Panasonic Corporation | Enhancement of the attachement procedure for re-attaching a UE to a 3GPP access network |
US20110268085A1 (en) | 2009-11-19 | 2011-11-03 | Qualcomm Incorporated | Lte forward handover |
US8838106B2 (en) | 2010-02-23 | 2014-09-16 | Apple Inc. | Method and apparatus for cell reselection |
US20130039287A1 (en) * | 2011-08-12 | 2013-02-14 | Venkata Ratnakar Rao Rayavarapu | Simplified ue + enb messaging |
US9071635B1 (en) * | 2011-10-19 | 2015-06-30 | Wichorus, Inc. | Methods and apparatus for identifying paging activities during idle mode |
US8619799B1 (en) * | 2011-11-02 | 2013-12-31 | Wichorus, Inc. | Methods and apparatus for improving idle mode performance using deep packet inspection (DPI) idle mode agent |
US9247575B2 (en) * | 2012-03-27 | 2016-01-26 | Blackberry Limited | eNB storing RRC configuration information at another network component |
EP2880958B1 (en) * | 2012-08-02 | 2018-06-06 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for reducing signaling in a core network |
US8923880B2 (en) * | 2012-09-28 | 2014-12-30 | Intel Corporation | Selective joinder of user equipment with wireless cell |
EP2908583B1 (en) | 2012-10-10 | 2019-02-27 | LG Electronics Inc. | Method for processing paging and method for relaying downlink data |
TWI513350B (en) | 2012-10-11 | 2015-12-11 | Mstar Semiconductor Inc | Mobile communication device and control method thereof |
CN104185278B (en) | 2013-05-20 | 2018-12-28 | 上海诺基亚贝尔股份有限公司 | A method of for calling optimization |
CN104244346A (en) | 2014-09-04 | 2014-12-24 | 京信通信系统(中国)有限公司 | Method and device for determining switched target cells |
US9723651B2 (en) | 2014-11-10 | 2017-08-01 | Qualcomm Incorporated | Enhanced connection management for multiple access networks |
CN107409304A (en) * | 2015-03-13 | 2017-11-28 | 三星电子株式会社 | It is used for the method and apparatus of calling terminal in wireless communication system |
ES2657365T3 (en) * | 2015-04-17 | 2018-03-05 | Panasonic Intellectual Property Corporation Of America | Signaling of the level of coverage improvement and efficient information packaging of the MTC system |
EP3320728B1 (en) * | 2015-07-06 | 2019-05-29 | Telefonaktiebolaget LM Ericsson (publ) | Core network assisted ran paging |
US10149217B2 (en) * | 2015-09-01 | 2018-12-04 | Qualcomm Incorporated | Service-based, separated access and paging cell selection and reselection |
CN107113906B (en) * | 2015-09-16 | 2021-02-12 | 华为技术有限公司 | Method and device for releasing Radio Resource Control (RRC) connection |
GB201600474D0 (en) | 2016-01-11 | 2016-02-24 | Nec Corp | Communication system |
GB2548878A (en) | 2016-03-31 | 2017-10-04 | Nec Corp | Communication system |
EP3425993B1 (en) * | 2016-04-01 | 2020-09-02 | LG Electronics Inc. | Method for managing connection of ue for transmitting and receiving v2x message in wireless communication system, and apparatus therefor |
WO2017184856A1 (en) * | 2016-04-20 | 2017-10-26 | Convida Wireless, Llc | Mobility signaling load reduction |
US20190230625A1 (en) * | 2016-07-05 | 2019-07-25 | Lg Electronics Inc. | Method and apparatus for notifying mme of unsuccessful paging for terminal |
CN115665857A (en) * | 2016-07-13 | 2023-01-31 | 三星电子株式会社 | Access control method and apparatus for use in mobile communication |
WO2018030304A1 (en) * | 2016-08-10 | 2018-02-15 | 京セラ株式会社 | Base station and mobility management entity |
WO2018056347A1 (en) | 2016-09-21 | 2018-03-29 | 京セラ株式会社 | Base station and wireless terminal |
US10440691B2 (en) * | 2016-09-30 | 2019-10-08 | Kt Corporation | Method for controlling connection status of UE and apparatus thereof |
US10820192B2 (en) * | 2017-06-16 | 2020-10-27 | Huawei Technologies Co., Ltd. | Downlink transmission in a RAN inactive mode |
-
2016
- 2016-11-04 GB GB1618663.7A patent/GB2555784A/en not_active Withdrawn
-
2017
- 2017-10-26 WO PCT/JP2017/038723 patent/WO2018084070A1/en unknown
- 2017-10-26 KR KR1020227010156A patent/KR20220045239A/en not_active Application Discontinuation
- 2017-10-26 KR KR1020217015848A patent/KR102398463B1/en active IP Right Grant
- 2017-10-26 JP JP2019522595A patent/JP2019537358A/en active Pending
- 2017-10-26 CN CN202211561067.3A patent/CN116017695A/en active Pending
- 2017-10-26 CN CN202211561020.7A patent/CN115988683A/en active Pending
- 2017-10-26 EP EP23206265.3A patent/EP4290927A3/en active Pending
- 2017-10-26 BR BR112019009028A patent/BR112019009028A2/en unknown
- 2017-10-26 KR KR1020227010155A patent/KR102503605B1/en active IP Right Grant
- 2017-10-26 EP EP17797769.1A patent/EP3536067B1/en active Active
- 2017-10-26 US US16/347,074 patent/US11659517B2/en active Active
- 2017-10-26 CN CN201780082109.6A patent/CN110169154B/en active Active
- 2017-10-26 RU RU2019117048A patent/RU2744010C2/en active
- 2017-10-26 KR KR1020197015370A patent/KR20190073512A/en active Application Filing
-
2022
- 2022-03-08 US US17/689,151 patent/US20220191823A1/en not_active Abandoned
-
2023
- 2023-04-20 US US18/137,240 patent/US20230254813A1/en active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190052607A1 (en) * | 2015-09-14 | 2019-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Radio access nodes and terminal devices in a communication network |
US20190357296A1 (en) * | 2015-11-17 | 2019-11-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Ue identifier in rrc resume |
US20170202050A1 (en) * | 2016-01-12 | 2017-07-13 | Spreadtrum Communications (Shanghai) Co., Ltd. | Method for accessing cell, and base station |
US20170202051A1 (en) * | 2016-01-12 | 2017-07-13 | Electronics And Telecommunications Research Institute | Method and apparatus for reusing access stratum context through unique base station identifier, and method and apparatus for resuming radio resource control (rrc) connection by using the same |
US20190320476A1 (en) * | 2016-09-30 | 2019-10-17 | Samsung Electronics Co., Ltd. | Method and apparatus for establishing dual-connectivity to transmit data in new radio communication architecture |
Also Published As
Publication number | Publication date |
---|---|
EP3536067B1 (en) | 2023-12-06 |
CN116017695A (en) | 2023-04-25 |
RU2744010C2 (en) | 2021-03-02 |
BR112019009028A2 (en) | 2019-07-09 |
KR20220045238A (en) | 2022-04-12 |
KR20190073512A (en) | 2019-06-26 |
KR20210064414A (en) | 2021-06-02 |
US20230254813A1 (en) | 2023-08-10 |
WO2018084070A1 (en) | 2018-05-11 |
RU2019117048A3 (en) | 2020-12-04 |
RU2019117048A (en) | 2020-12-04 |
EP3536067A1 (en) | 2019-09-11 |
CN110169154A (en) | 2019-08-23 |
US20200037285A1 (en) | 2020-01-30 |
EP4290927A3 (en) | 2024-03-06 |
CN115988683A (en) | 2023-04-18 |
KR102398463B1 (en) | 2022-05-13 |
US11659517B2 (en) | 2023-05-23 |
KR20220045239A (en) | 2022-04-12 |
KR102503605B1 (en) | 2023-02-23 |
JP2019537358A (en) | 2019-12-19 |
CN110169154B (en) | 2022-12-13 |
GB2555784A (en) | 2018-05-16 |
EP4290927A2 (en) | 2023-12-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220191823A1 (en) | Communication system | |
EP3577964B1 (en) | Methods and apparatuses for paging in a communications network | |
US11129131B2 (en) | Configuration of a ran based notification area for a user equipment in RRC inactive state | |
US11405974B2 (en) | Communication system | |
RU2668071C1 (en) | Communication optimization method and device | |
JP6665946B2 (en) | Base station, core network device and communication device | |
US9860734B2 (en) | Method and device of supporting group mobility | |
EP3420749B1 (en) | Methods and devices to forward data from first radio access network node to wireless device over a network node | |
KR101429167B1 (en) | Apparatus and method for paging in wireless communication system | |
EP3310116A1 (en) | Downlink data notification | |
WO2023069665A1 (en) | Enabling paging occasion of idle state for the inactive state |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |