WO2013066350A1 - Apparatus and method for delayed response handling in mobile communication congestion control - Google Patents

Apparatus and method for delayed response handling in mobile communication congestion control Download PDF

Info

Publication number
WO2013066350A1
WO2013066350A1 PCT/US2011/059401 US2011059401W WO2013066350A1 WO 2013066350 A1 WO2013066350 A1 WO 2013066350A1 US 2011059401 W US2011059401 W US 2011059401W WO 2013066350 A1 WO2013066350 A1 WO 2013066350A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
application layer
mobile terminal
response
delayed response
Prior art date
Application number
PCT/US2011/059401
Other languages
French (fr)
Inventor
Li Wei
Hong Cheng
YuXuan ZHOU
Original Assignee
Panasonic Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corporation filed Critical Panasonic Corporation
Priority to PCT/US2011/059401 priority Critical patent/WO2013066350A1/en
Publication of WO2013066350A1 publication Critical patent/WO2013066350A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure

Definitions

  • the network would allow network initiated machine type communications even if the network is in congestion control mode. This is important for some applications that require only lower priority for device initiated session but require higher priority for network initiated sessions. For example, a medical sensor as a mobile terminal that takes medical vital signs and sends data reports regularly to a server can wait for the next opportunity to transmit when no emergent event is detected. However, if the server application concludes that some abnormal sign is present and needs another reading of the patient's data, the communication should happen as soon as possible.
  • the SGW will deliver the application layer request message to the sensor.
  • the application layer response may only be ready after an extended period. Therefore, the sensor would not send any data during this period, and the mobile network, unaware of the situation, would move the sensor back to the IDLE mode, e.g. by releasing the RRC
  • the sensor when the sensor has the application layer response ready, it needs to initiate an access request towards the network again to transit to CONNECTED mode to transmit the data.
  • the sensor can only indicate the new access request as a mobile initiating request, which is of lower priority. Therefore, the network in the congestion control would reject the access request and may enforce a long back-off, e.g. in the order of several hours. This is obviously an undesired behavior for the medical application as the reading may lose its meaning after such a long delay.
  • An embodiment may address the above discussed problems.
  • an embodiment may provide a method and system to allow a more intelligent management of the congestion control, such that a delayed response to a network initiated session could be supported.
  • An embodiment may introduce some intelligence in the device ⁇ e.g., an MTC Device) that can create a correlation with the network, e.g.
  • a system for congestion control in a mobile communication network comprises: a mobile terminal that is capable of responding to an application layer request; an application layer server that is capable of requesting a response from the mobile terminal; and a network control entity that is capable of rejecting a connection request from the mobile terminal; wherein, in use, the mobile terminal decides that the response to a application layer request from the application layer server is delayed and releases an existing connection, such that the network control entity does not reject a connection request from the mobile terminal for transmitting the delayed response to the application layer request.
  • the mobile terminal is capable of negotiating with the network control entity and deciding the parameters to be used, such that the network control entity does not reject the connection request for transmitting the delayed response to the application layer request.
  • the network is configured to determine, based on information derived from the received application layer request and in response to the request to accept the subsequent connection request, a set of parameters and to selectively override the congestion control policy based on the determined parameters.
  • the application layer server is a machine type communication server.
  • the communicatively coupling is configured to selectively override a congestion control policy based on the determined parameters included in the request to accept the subsequent connection request.
  • the parameters include a time period and the means for communicatively coupling is configured to accept the subsequent connection request from the mobile terminal when the subsequent connection request is received within the time period.
  • the mobile terminal comprises a connection manager configured to determine whether a generated response is to an application layer request received from the means for generating application layer requests.
  • the means for communicatively coupling comprises: a network controller; and an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is configured to instruct the access network controller to accept a connection request based on the determined parameters included in the request to accept the subsequent connection request.
  • a communication network comprises: one or more memories; and one or more configured processing devices configured to implement a communication control block, wherein the communication control block is configured to: selectively block connection requests from mobile terminals; and respond to a request from a mobile terminal to accept a subsequent connection request associated with a delayed response to an application layer request by selectively storing an indication of an expected delayed response from the mobile terminal to the application layer request.
  • the communication control block is configured to determine whether the mobile terminal is authorized to submit the request to accept a subsequent connection request associated with the delayed response to the application layer request.
  • an existing connection with the mobile terminal is released in response to the request to accept the subsequent connection request.
  • the subsequent connection request is a mobile terminating request.
  • the subsequent connection request is a mobile originating request including a delayed response indicator.
  • the subsequent connection request is a radio link recovery request.
  • the communication control block is configured to selectively accept the subsequent connection request based on when the subsequent connection request is received.
  • the one or more configured processing devices comprise a mobile management controller and a base station.
  • the method further comprises: determining whether a delayed response to the application layer request has been generated; and when it is determined that a delayed response to the application layer request has been generated, determining whether to override congestion control; and when it is determined to override congestion control, generating the subsequent connection request.
  • the generating the subsequent connection request comprises generating a mobile terminating request.
  • the generating the subsequent connection request comprises generating a mobile originating request including a delayed response indicator.
  • the method further comprises: determining whether a delayed response to the application layer request has been generated; and when it is determined that a delayed response to the application layer request has been generated, determining whether a timer has expired; and when it is determined the timer has not expired, generating the subsequent connection request.
  • the generating the subsequent connection request comprises initiating a radio link recovery.
  • a method comprises: receiving a request from a mobile terminal to accept a subsequent connection request from the mobile terminal associated with a delayed response to an application layer request; selectively storing an indication of an expected delayed response from the mobile terminal to the application layer request; and responding to a
  • congested network can avoid waste network resources on mobile terminals that have no meaningful use of the connection, and reduce potential additional mobility management controls. It may allow the network to serve more terminals with higher efficiency, which can contribute to alleviate the
  • FIG 1 illustrates a network configuration of an embodiment where Machine Type Communication (MTC) services are provided in a separate Service Domain than the 3GPP Domain;
  • Figure 2 illustrates an example operation sequence of an embodiment where an MTC Device decides that a delayed response is desired and releases its existing connections;
  • MTC Machine Type Communication
  • Figure 4 illustrates an alternative operation sequence of an embodiment where an MTC Device recovers a connection for transmitting the delayed response data
  • LTE Long Term Evolution
  • EPS Evolved Packet System
  • FIG. 1 an example architecture of a network 100 that supports Machine Type Communication (MTC) is shown.
  • the network supports one or more Machine Type Communication Devices, as illustrated MTC Devices 101 to 107, to access MTC services from an MTC Server 151 in a Service Domain 150 via a 3GPP Domain 130.
  • the 3GPP Domain 130 may, for example, be any network that supports the systems and access
  • PGW Network Gateways
  • the network may protect itself from surges in both data and signaling traffic. Therefore, the network may employ congestion mechanisms at different layers, e.g., such as those introduced in 3GPP TR 23.888 v1 .5.0 Release 1 1 , referenced above.
  • the MME 133 may active congestion control when the signaling or data load exceeds certain threshold levels, and may simply reject connection requests from an MTC Device ⁇ e.g., MTC Device 101 ).
  • the congestion control may be extended to radio access, e.g., the eNB 131 may start to reject radio connection establishment requests from the MTC Device ⁇ e.g., MTC Device 101 ).
  • the eNB 131 may even broadcast an access barring indication that may force lower priority devices to backoff from accessing the network.
  • Figure 1 shows that the PGW 137, SGW 135, MME 133, eNB 131 are in the same 3GPP Domain 130, they can be under different operators' control in practice.
  • the MTC Device 101 may access a first operator's network that includes eNB 131 , MME 133, SGW 135, but the PGW 137 may be in a second operator's network.
  • the eNB 131 may be even shared by different operators.
  • FIG. 1 only shows the most essential entities in the 3GPP domain relevant to the present disclosure.
  • there are more functional entities in the 3GPP Domain 130 e.g. Home Subscriber Server (HSS), Policy Control and Charging Rules Function (PCRF), Authentication Authorization and Accounting Server (AAA Server), etc.
  • HSS Home Subscriber Server
  • PCRF Policy Control and Charging Rules Function
  • AAA Server Authentication Authorization and Accounting Server
  • an operation sequence example is provided to illustrate an embodiment in the context of the network 100 shown in Figure 1 .
  • the MTC Device e.g., the User Terminal (UE) in 3GPP Domain's point of view
  • the MTC Device e.g., the User Terminal (UE) in 3GPP Domain's point of view
  • the MTC Device 101 does not have any radio connection with the eNB 131
  • the eNB 131 does not have any context information about the MTC Device 101 .
  • the MME 133 uses the EPS Bearer identifier to determine the service that triggers the notification, and uses the corresponding subscription information of the MTC Device 101 and the indicated priority to decide whether the congestion control should be overridden and allow the MTC Device 101 to have a data connection, in step 21 1 .
  • the MTC Device 101 When the MTC Device 101 receives the Paging 215 on the radio layer, it informs the connection management function (see Connection Manager 603 in Figure 6), and decides that the congestion control should be overridden, in step 217. For example, if the MTC Device 101 has a backoff timer running on either the Non-Access Stratum (NAS) layer (see NAS control 605 in Figure 6) or Radio Resource Control (RRC) layer (see Radio Control 607 in Figure 6), the connection management stops those timers, and triggers a NAS layer signaling message, e.g. Service Request, towards the MME 133 for transiting to CONNECTED mode and establishing the corresponding data connections.
  • NAS Non-Access Stratum
  • RRC Radio Resource Control
  • the eNB 131 accepts the RRC connection request by replying with an RRC Connection Setup, in step 223, and the MTC Device will use the established RRC connection to forward the NAS layer signaling towards the MME 133, e.g. by piggybacking the NAS layer Service Request message onto the radio layer RRC Connection Setup Complete message, in step 225.
  • the NAS layer Service Request message will be forwarded to the MME 133 by the eNB 131 in an Initial UE Message, in step 227, which also includes other information, e.g. the identity of the eNB, location, CSG ID, etc.
  • the Initial Context Setup Complete message also includes information to establish the data connection for the MTC Device 101 , e.g. the downlink tunnel end point identifier, etc. With such information, the MME 133 instructs the SGW 135 to establish the data connections with a Modify Bearer Request or Modify Access Bearer Request message, in step 237.
  • the SGW 135 When the Modify Bearer Request 237 is received, the SGW 135 has enough information to deliver the Downlink Data towards the eNB 131 , in step 239. This Downlink Data would be forwarded to the MTC Device 101 via the radio bearer established in step 233, in step 241 . The received Downlink Data will be forwarded to the MTC application layer (see MTC Application 601 in Figure 6) on the MTC Device 101 .
  • Delayed Response indicator it may use the Type-Length-Value (TLV) coding, such that the additional information could be optionally included when necessary without affecting the indicator's format.
  • TLV Type-Length-Value
  • delayedResponseFlag ENUMERATED ⁇ true, false ⁇ , correlationToken OCTET STRING OPTIONAL, expectedTimerforDelayedResponse INTEGER (0..4095)
  • the "Correlation Token” may be generated by the MTC Device 101 based, for example, on its subscription, temporary identifier, permanent identifier, device identifier, or random number, etc.
  • the Correlation Token may be used to help the network to correlate and verify the connection established later for the delayed response data.
  • the MME 133 includes the updated "Delayed Response" indicator and associated information in the TAU Accept message sent towards the MTC Device 101 , in step 251 . It should be noted that the MME 133 may decide that the Delayed Response feature should not be supported for this particular MTC Device 101 due to subscription limitation, or network status, operator policy, etc. In such a case, the MME 133 may update the "Delayed Response" indicator in the TAU Accept 251 to signal that the delayed response is not allowed, e.g. by setting the "delayedResponseFlag" to "false". The MME 133 may not store any information at step 249 if the delayed response is not allowed.
  • This "Delayed Response Record” may include among other information a timer that is set to the value of "expectedTimerforDelayedResponse", a token set with the value of "correlationToken", and other information to identify the delayed MTC application, e.g. application identifier, addresses, etc.
  • the MTC Device 101 may typically remove the "Delayed Response Record” once the timer expires.
  • the eNB 131 initiates the release of the radio bearers and RRC connections, as in step 259.
  • the eNB 131 also uses the "Delayed Response" indicator to manage the context for the MTC Device 101 . For example, if the "delayedResponseFlag" is set to true, the eNB 131 may remove all the local context information for the MTC Device 101 , but keep a "Delayed Response Entry,” in step 257, with the MTC Device's 101 identity, e.g.
  • the eNB 131 may store the "correlationToken" together with the IMSI or TMSI if it is included in the "Delayed Response" indicator.
  • the eNB 131 starts a timer with the value indicated in "expectedTimerforDelayedResponse", and associate the timer with the "Delayed Response Entry”. If the
  • the eNB 131 may, based on its local policy, network status, and operator configuration, decide the value for the timer. The eNB 131 may typically remove this "Delayed Response Entry" when the timer expires.
  • the MTC Device 101 may indicate "mobile originating" as the cause in the RRC Connection Request 305, and include a "Delayed Response” indicator. This indicates to the eNB 131 to treat the request differently from a normal mobile originating connection request.
  • the MTC Device 101 may include the "Delayed Response" indicator or a subset of it, e.g. the Correlation Token.
  • This NAS layer Service Request or Extended Service Request message is forwarded by the eNB 131 to the MME 133 using a Initial UE Message, in step 313.
  • the MME 133 When the Service Request or Extended Service Request with the "Delayed Response" indicator is received, the MME 133 does not reject the request as a matter of course even if the congestion control is in place.
  • the MME 133 accepts the Service
  • the MME 133 instructs the eNB 131 to establish the corresponding bearers with the Initial Context Setup Request 317.
  • the eNB 131 in turn establishes the radio bearers, in step 319.
  • the MTC Device 101 transmits the delayed response data towards the MTC Server 151 via the eNB 131 , SGW 135, and PGW 137.
  • the rest of the signaling may be the same as that discussed in General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, 3GPP TS 23.401 v10.4.0 Release 10, 201 1 -06-12.
  • GPRS General Packet Radio Service
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • 3GPP TS 23.401 v10.4.0 Release 10, 201 1 -06-12 3GPP TS 23.401 v10.4.0 Release 10, 201 1 -06-12.
  • the MTC Device 101 could be mobile in certain deployments. Therefore, when the delayed response data is ready, the MTC Device 101 may have moved to another eNB's coverage.
  • the MME 133 may assist in this aspect as well. As the MME 133 may be capable of predicting the mobility of the MTC Device 101 based on its track record, the MME 133 may decide a group of eNBs to be covered based on the current location of the MTC Device 101 , the value of
  • the MME 133 may signal to this group of eNBs with an S1 interface message indicating the information in the "Delayed Response Entry”. This way, the eNBs may also be prepared to support the MTC Device 101 for the delayed response.
  • an alternative embodiment of an operation sequence for the MTC Device 101 to transmit the delayed response data is illustrated.
  • the eNBs and the MTC Device 101 make use of the radio link failure recovery mechanism to establish the connection when delayed response data is ready. It is assumed that the MTC Device 101 has been following the operation of the embodiment shown in Figure 2 before starting the operation shown in Figure 4, e.g. the step 201 to 249 were carried out before step 401 .
  • the eNB 131 then releases the radio layer connection, e.g. RRC connection, towards the MTC Device 101 , in step 409. At this point of time, both the MTC Device 101 and the eNB 131 would start the radio link failure timer, and enter the radio link failure recovery mode.
  • RRC connection e.g. RRC connection
  • the MTC Device 101 For the MTC Device 101 , it is using a modified Delayed Response radio link failure recovery mode, in step 41 1 . In this mode, the MTC Device 101 does not attempt any recovery signaling or transmission before the timer expires, even if it detected the signal for the eNB 131 . Instead, the MTC Device 101 performs some other essential IDLE mode radio layer operation, e.g.
  • the eNB 131 side the eNB releases the data bearer context towards the MME 133, in step 413. Therefore, if there is any downlink traffic towards the MTC Device 101 , paging procedure will be triggered, and the eNB 101 will broadcast the paging message accordingly, as if the MTC Device 101 is in IDLE mode. At the moment, the eNB 131 only keep the signaling bearer context for the MTC Device 101 , associated with the "Delayed Response" indicator.
  • the eNB 131 may also propagate the stored context of the MTC Device to other eNBs surrounding the location. Therefore, the MTC Device 101 would be able to perform the radio link failure recovery on any of these prepared eNBs.
  • the MTC application on the MTC Device 101 has the response data ready, in step 415.
  • the MTC Device 101 has the response data ready, in step 415.
  • the MTC Device 101 determines the data is subject to delayed response treatment based on operation similar to that of step 301 .
  • the MTC Device 101 checks if the radio link failure recovery timer has expired. If not, the MTC Device 101 performs radio link failure recovery signaling, e.g., by sending a RRC Connection Re-establishment Request, in step 417.
  • This RRC Connection Re-establishment Request may contain the "Delayed Response" indicatoror, it may only include a subset information element of the "Delayed Response” indicator, e.g. the Correlation Token.
  • the MME 133 checks and determines whether the access should be granted. As illustrated, steps 425 to 451 of Figure 4 are identical to those of steps 315 to 341 of Figure 3.
  • the TAU Request 247 and TAU Accept 251 , 401 may be replaced by a Detach Request and Detach Accept with special information elements, e.g. "Delayed Response" indicator.
  • these messages could be the UE initiated Request Bearer Resources
  • the MTC Device 101 may lose the connection, e.g. due to loss of radio signals. For example, when going through a long tunnel or a lift, the MTC Device 101 may experience radio link failure. If the radio link failure is not recovered in time, the MTC Device 101 may fall into IDLE mode. Therefore, if the MTC Device 101 tries to send data again, it would need to request to establish the connection and transit to CONNECTED mode first. In a congestion controlled network, such request may be rejected.
  • the operation of Figure 5 provides a solution to this issue.
  • the MTC Device 101 receives Downlink Data from the MTC Server 151 following the steps 501 to 537, which as illustrated are essentially identical to those of steps 201 to 243 of Figure 2. Some differences between and common features of the illustrated embodiments of Figures 2 and 5 are mentioned in the discussion below of Figure 5, with some of the detail of Figure 2 omitted from Figure 5.
  • the MTC Device 101 may indicate in the Service Request or Extended Service Request that the device supports delayed response handling. This could be achieved by including a special flag or using a new cause code in the Extended Service Request.
  • the MME 133 knowing the service type and priority based on the Downlink Data Notification 507 and the MTC Device 101 subscription, may decide if a delayed response handling should be allowed, in step 525. If the MME 133 decides that the delayed response handling is to be supported, it also decides the corresponding parameters to be used, e.g. Correlation Token, Expected Timer for Delayed Response, etc.
  • the MME 133 stores this information together with the MTC Device 101 context in step 525, and passes the information in a "Delayed Response Allowed" information element in the Initial Context Setup Request to the eNB 131 , in step 527.
  • the "Delayed Response Allowed" information element may take the format of the "Delayed Response” indicator discussed above with respect to Figure 2.
  • the eNB 131 may select to forward the "Delayed Response Allowed" information to the MTC Device 101 if the radio layer signaling is enhanced to support it.
  • the MTC Device 101 has MTC application data to be sent towards the MTC Server 151 .
  • the MTC Device 101 decides that congestion control should be overridden in step 543, and a RRC Connection should be requested, in step 545. Upon receiving this RRC Connection
  • the MTC Device 101 indicates the "Delayed Response” indicator, which may include a Correlation Token that is configured or transported at step 529.
  • the MME 133 may, based on the stored "Delayed Response Allowed” data and the received "Delayed Response” indicator, decide whether to accept the connection request, e.g. checking if the timer associated with the "Delayed Response Allowed" is expired.
  • FIG. 6 an embodiment of a device structure that can be used by a MTC Device 600 in accordance with the methods and systems discussed herein is illustrated.
  • the MTC Device 600 of Figure 6 may be employed as an MTC Device 101 to 107 of Figure 1 .
  • the Connection Manager 603 is configured to decide based on some local policy or operator rules which access should be used for the transmission of the data traffic, in case there are multiple accesses available in the same MTC Device 600, e.g. 3GPP Radio Transport 609 and Non-3G Access 61 1 , or there are multiple bearers over the same access, e.g. multiple Packet Data Network (PDN) connections over the 3GPP Radio Transport 609.
  • PDN Packet Data Network
  • the Connection Manager 603 is also configured to use these policies and routing rules to identify the MTC Application 601 that generated the data traffic. This can be achieved by associating an Application Identifier with the interface 623, such that the Connection Manager 603 knows which application is generating the traffic, and whether a delayed response should be supported. This Application Identifier could be also mapped to a class of applications, e.g. certain type of MTC services, and the Connection Manager 603 could decide if delayed response support is desired for this type of applications.
  • the interface 623 may also allow the MTC Application 601 to indicate to the Connection Manager 603 whether the delayed response support is desired.
  • the Connection Manager 603 based on the "Delayed Response" manages the connection and decides if it should trigger the NAS Control 605 to perform connection request signaling to the MME 133 even if congestion control is active, e.g. a backoff timer is running.
  • the Radio Control 607 has a control interface 633 with the Connection Manager 603.
  • This interface 633 allows the Connection Manager 603 to pass the "Delayed Response” indicator to Radio Control 607 for including into RRC signaling.
  • the interface 633 also allows the Radio Control 607 to pass the "Delayed Response Allowed” information element to the Connection Manager when supported.
  • the Connection Manager 603 When in use, the Connection Manager 603 after deciding that delayed response should be supported and that delayed response data from MTC Application 601 is pending to be sent, the Connection Manager 603 triggers the Radio Control 607 to establish a signaling control connection with an indication to reduce the likelihood that the connection will be blocked by congestion control, such as with a cause of "mobile terminating" or with a cause of "mobile originating” and a "Delayed Response” indicator.
  • the MTC Device 600 comprises one or more processors P, one or more memories M and one or more discrete devices 635, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer.
  • the various functions of the MTC Device 600 may be implemented in various ways, such as by the processor P and the memory M (for example by executing instructions stored in the memory M), the discrete circuit 635, and various combinations thereof, etc.
  • the Extended Access Control 705 When in use, the Extended Access Control 705 receives the "Delayed Response” indicator or “Delayed Response Allowed” information element, and creates and stores the corresponding "Delayed Response Entry”. The Extended Access Control 705 also is configured to manage and handle the timer to be associated with the "Delayed Response Entry”.
  • the Radio Control 703 When the Radio Control 703 receives a connection request for the delayed response, e.g. the RRC Connection Request with the "Delayed Response” indicator, it checks with the Extended Access Control 705 whether the request should be accepted.
  • the Extended Access Control 705 is configured to decide whether the request should be accepted based on the presence and information of the "Delayed Response Entry". For example, if the timer for the "Delayed Response Entry" associated with the request has not expired, the connection should be accepted.
  • the 700 may be implemented in various ways, such as by the processor P and the memory M (for example by executing instructions stored in the memory M), the discrete circuit 735, and various combinations thereof, etc.
  • MME 800 With reference to Figure 8, an embodiment of a device structure that can be used by a MME 800 in accordance with the methods and systems discussed herein is illustrated.
  • the MME 800 of Figure 8 may be employed as an MME 133 of Figure 1 .
  • the MME 800 includes a Congestion Control 801 module that is configured to handle access management for the MTC Device 101 .
  • Congestion Control 801 receives a Downlink Data Notification from the SGW
  • Core Network Control 807 it is configured to page the MTC Device 101 via the eNB 131 through Access Network Control 805.
  • the UE NAS Control 803 passes the received "Delayed Response” indicator to the Congestion Control 801 .
  • Control 801 may be configured to update the contents in the "Delayed
  • the Congestion Control 801 may be configured to generate the "Delayed Response Allowed" element based on knowledge of the service, network status, and the MTC Device 101 subscription information, etc.
  • the Congestion Control 801 may be configured to pass the "Delayed Response” indicator or the "Delayed Response Allowed” element to the Access Network Control 805, such that they could be included in the UE Context Release or UE Context Setup Request message respectively.
  • a logic flow 900 that can be used by a
  • MTC Device Connection Manager such as Connection Manager 603 of MTC Device 600 of Figure 6, implementing an embodiment of the present disclosure is illustrated. This corresponds to an embodiment of the operation as illustrated in Figures 2 and 3. For convenience, the logic flow 900 is discussed with reference to the embodiment of an MTC Device 600 of Figure 6.
  • the Connection Manager 603 When the Connection Manager 603 receives the Paging trigger from the Radio Control 607, in step 901 , the Connection Manager overrides any congestion control timer that is currently running, and triggers the NAS Control 605 to signal toward the MME 133 with a Service Request or Extended Service Request, in step 903.
  • the MTC Application 601 receives the Downlink Data, and may indicate via the interface 623 that delayed response is likely necessary, in step 905.
  • the Connection Manager 603 generates the corresponding "Delayed Response” indicator when necessary, and passes it to the NAS Control 605 to signal to the MME 133, which would trigger the release of the connections, in step 907.
  • the MTC Device 600 would then fall into IDLE mode.
  • the Connection Manager 603 periodically or continuously checks if the MTC Application 601 has generated response data, as in step 909. When the data traffic is received from the MTC Application 601 , the Connection Manager 603 checks its local policy and other configurations to determine whether the traffic is to be forwarded over the 3GPP Radio Transport, in step 91 1 . If not, the traffic is passed to the Non-3G Access 61 1 for transport.
  • the Connection Manager 603 checks if the Delayed Response is still valid, e.g. if the timer associated with the MTC application's delayed response context has expired, in step 913. If the timer has expired, the Connection Manager 603 follows normal congestion control, e.g., to honor backoff timers in place before triggering any signaling to establish a connection, in step 923.
  • the Connection Manager 603 finds that the delayed response context for the MTC application is still valid, the Connection Manager ignores the congestion control mechanism, and triggers the NAS Control 605 to signal to the MME to transit to CONNECTED mode, e.g., by sending a Service Request or Extended Service Request, or TAU Request with active flag, as in step 915.
  • the Connection Manager 603 also sets the Radio Control 607 to override any congestion control, e.g., extended wait time at RRC layer, or extended access barring, etc, and perform signaling to request an RRC connection setup in step 917, for example by indicating a "mobile terminating" cause or a "mobile originating” cause with the "Delayed Response" indicator.
  • the Connection Manager 603 will forward the MTC application data to the 3GPP Radio Transport 609 in step 919, to be transmitted to the MTC Server 151 .
  • a logic flow 1000 that can be used by a MTC Device Connection Manager, such as the
  • the steps 1001 to 1007 as illustrated are identical to those of step 901 to 907 of Figure 9. However, when the Connection Manager 603 detects that the connections for the MTC Device 600 have been released, the Connection Manager 603 detects that the connections for the MTC Device 600 have been released.
  • the Radio Control 607 does not initiate a recovery procedure unless the recovery procedure is triggered by the Connection Manager 603, and the Radio Control 607 performs the procedure defined for the IDLE mode devices.
  • FIG. 1 Another embodiment of a system architecture 1 100 that supports Machine Type Communication is presented.
  • the MTC Server 1 151 communicates with the 3GPP Domain via an MTC interworking function MTC IWF 1 135.
  • the MTC IWF 1 135 is configured to translate and encapsulate the traffic from the MTC Server 1 151 into control plane messages and deliver the traffic to the MME 1 133 via interface 1 1 15.
  • the traffic from MTC Server 1 151 are encapsulated into Short Message Service (SMS) messages.
  • SMS Short Message Service
  • the MME 1 133 is configured to deliver the SMS messages as control plane signaling messages, e.g., NAS layer signaling messages, to the MTC Device, e.g., MTC Devices 1 101 to 1 107.
  • SMS Short Message Service
  • Figures 2, 3, 4, and 5 may still be used with some minor adaptation, e.g.
  • the MTC application could be also supported in a UTRAN system.
  • the same operations presented above could be applied, with minor adjustments.
  • the eNB 131 may be replaced by a Radio Network Controller (RNC)
  • the MME 133 and SGW 135 may be replaced by the Serving GPRS Support Node SGSN
  • the PGW 137 may be replaced by the Gateway GPRS Support Node GGSN.
  • the signaling messages used may be replaced by corresponding UTRAN signaling messages, e.g., a TAU Request may be replaced by Routing Area Update (RAU) Request or Location Area update (LAU) request.
  • RAU Routing Area Update
  • LAU Location Area update
  • TR23.888 describes general optimizations for the SMS transmission carrying the device trigger or data.
  • Section 6.52 of TR23.888 describes omit the establishment of the U-plane bearer(s) during the transmission of the device trigger from an MME to a UE (for example, an MTC Device). Depending on the trigger information the UE initates the
  • the MTC Server corresponding (IP or SMS) communication to the MTC Server (see section 6.52.2.7). More specifically, after receiving the Device Trigger message, if the UE determines that the uplink data responding to the Device Trigger message should be sent to the MTC Sever immediately, the UE establishes the U-plane bearer(s) immediately or reuses the existing NAS MM connection to transmit a Mobile Originating (MO) SMS to the MTC Server. Otherwise, if the UE determines that the uplink data will be transmitted later ⁇ e.g., an MO
  • the network will reject the MO access request.
  • MTC congestion control the MME can reject the access request from MTC Device with a back-off timer except for Service Users, emergency services and mobile terminated services.
  • an eNB can reject the RRC connection request at the RAN layer with an extended wait time or broadcast extended access barring.
  • TR23.888 specifies a scenario that a UE can determine to transmit the responding uplink data later (i.e.
  • MO communication will be established later) with effect of releasing NAS signalling connection. This means later UE may initiate MO communication because it tries to respond to a previous trigger message. Such MO communication access request should not be rejected even during congestion, but there is no mechanism to identify and allow the request. Even if the connection is not intentially released by UE after receiving the trigger, it may be released due to other reasons such as an UE inactive time ⁇ e.g., a threshold period of inactivity), radio link failure, radio access network events, etc. Later when the UE tries to transmit delayed response data for the trigger but the network is already congested, the UE will face the same situation of being rejected.
  • an UE inactive time e.g., a threshold period of inactivity
  • section 6.52.2.7 may be supplemented to support MO communication establishment for delayed uplink data transmission in case of congestion.
  • the UE determines to send the uplink response data later, it indicates to the MME to release the NAS signalling connection and also to store a delay-response indicator as a link between the previous Device Trigger message and the delayed response.
  • the MME may also inform the eNB of this delay-response indicator when it releases the NAS signaling connection. With this preparation, when uplink data is ready, the UE can establishes the MO communication with the same delay-response indicator to avoid being rejected by an MME/eNB even if the network is congested.
  • Section 6.52.2.7 of TS 23.888 may be modified to include text similar to the following:
  • used for MTC may either not require the establishment of U-plane bearers, or not require the immediate establishment of U-plane bearers.
  • the UE used for the MTC server may reply to the MTC server using MO SMS; 2) the UE used for the MTC server using MO SMS; 2) the UE used for the MTC server using MO SMS;
  • MTC may first need some time to gather information and then the IP-based communication to the MTC server may be initiated (e.g. 1 minute later).
  • the eNB/MME may not immediately initiate the NAS/RRC connection release after the delivery of the Device Trigger (e.g. MT SMS) to the UE.
  • the Device Trigger e.g. MT SMS
  • the UE determines if uplink data may be immediately sent to the MTC server. Further, the uplink data may result in either 1 ) establishment/activation of EPS bearers for IP/based MO communication or 2) the transmission of MO SMS to the MTC Server. If the UE decides to transmit an MO SMS, the UE reuses the existing NAS MM connection to the MME. If the UE needs to set up the U-plane bearers, the UE sends a corresponding EPS Bearer Activation message to the MME.
  • the UE determines that the uplink data may be transmitted later (i.e. MO communication will be established later), the UE indicates to the MME that the NAS signaling connection may be released. The latter helps the network to shorten the radio resource occupation.
  • the MME may establish the Access Stratum (AS) security for the Signaling Radio Bearers. For this reason, the MME may establish only the UE AS-security context at the eNB for the RRC connection ⁇ e.g., the MME doesn't include the E-RAB context in the S1 -AP Initial Context Setup request message to the eNB).
  • Reasons for the establishment of the AS-security are 1 ) the support of mobility and 2) the ability of the UE to reliably activate the U-plane bearers if needed.
  • the UE indicates further actions to the
  • MME such as keeping the NAS signaling connection or releasing the NAS signaling connection and storing an indicator for delayed response.
  • the MME may also inform eNB of the delayed response indicator when releasing the NAS signaling
  • a computer readable medium comprising a computer program adapted to perform one or more of the methods described above.
  • the medium may be a physical storage medium such as for example a Read Only Memory (ROM) chip, or a disk such as a Digital Versatile Disk (DVD-ROM), Compact Disk (CD-ROM), a hard disk, a memory, a network, or a portable media article to be read by an appropriate drive or via an appropriate connection, including as encoded in one or more barcodes or other related codes stored on one or more such computer- readable mediums and being readable by an appropriate reader device.
  • ROM Read Only Memory
  • DVD-ROM Digital Versatile Disk
  • CD-ROM Compact Disk
  • some or all of the systems and/or modules may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits (ASICs), discrete circuitry, standard integrated circuits, controllers (e.g., by executing appropriate instructions, state machines, and including microcontrollers and/or embedded controllers), field- programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc., as well as devices that employ RFID technology.
  • ASICs application-specific integrated circuits
  • controllers e.g., by executing appropriate instructions, state machines, and including microcontrollers and/or embedded controllers
  • FPGAs field- programmable gate arrays
  • CPLDs complex programmable logic devices
  • some of the modules or controllers separately described herein may be combined, split into further modules and/or split and recombined in various manners.
  • the various embodiments described above can be combined to provide further embodiments. Aspects of
  • Each functional block used in the description of the embodiments as given above can be realized as LSI, typically represented by an integrated circuit. These may be produced as one chip individually or may be designed as one chip to include a part or all. Here, it is referred as LSI, while it may be called IC, system LSI, super LSI, or ultra LSI, depending on the degree of integration. Also, the technique of integrated circuit is not limited only to LSI and it may be realized as a dedicated circuit or a general-purpose processor. FPGA (Field Programmable Gate Array), which can be programmed after the manufacture of LSI, or a reconfigurable processor, in which connection or setting of circuit cell inside LSI can be reconfigured, may be used. Further, with the progress of semiconductor technique or other techniques derived from it, when the technique of circuit integration to replace LSI may emerge, the functional blocks may be integrated by using such technique. For example, the adaptation of bio-technology is one of such possibilities.

Landscapes

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

Abstract

With congestion control applied, an access request from a lower priority device, e.g., a machine type communication (MTC) device, may be rejected by a communication network, with the exception of network initiated communication sessions. For example, if a server in the network decides to obtain information from a device, the network could page the device and allow the communication. However, for certain devices, especially MTC devices, the generation of the response to the server can take a long time. This may result in the response being considered an independent communication session initiated by the device, and thus rejected. The device may voluntarily disconnect in exchange for a priority raise for a next access request. The network could verify and grant the access when the device comes back with a request for the response transmission.

Description

APPARATUS AND METHOD FOR DELAYED RESPONSE HANDLING IN MOBILE COMMUNICATION CONGESTION CONTROL
BACKGROUND
Technical Field
This disclosure relates to data communications networks. More specifically, it relates to the management for a mobile terminal's connections in a mobile communication system.
Description of the Related Art
With the increasing number of devices equipped with network access capabilities, mobile communication networks need to handle
tremendous connections that exceed what network resources permit. Among these newly added devices, many are used for machine type communications, which may have quite different requirements from that of the human to human communications, e.g. voice applications. For example, with Internet trends, smart meters, sensors, or home appliances may be connected to a mobile communication network to provide necessary information to servers or applications. These kinds of communications are normally data oriented and are less time critical in transmission.
In view of the situation, the mobile network may optimize operations, such that resources may be used more efficiently in serving the machine type communications. One of the major improvements introduced in the 3GPP networks is the congestion control that employs the different access rejections and back-off timers at different access layers. See, System improvements for Machine-Type Communications (MTC), 3GPP TR 23.888 v1 .5.0 Release 1 1 , 201 1 -10. In congestion control mode, the network may decide to reject a device's access request based on the subscription, service type, equipment capability indications, etc. Depending on the congestion level, the network may reject the request at the Non-Access Stratum (NAS) signalling layer that are per User Equipment (UE) based, the Radio Resource Control (RRC) layer that are per Mobility Management Entity based, or perform the Access Baring that are general for all the devices in the same Radio Access Network. Together with the rejections, the network also indicates extended back-off timers that can prevent the devices from attempting the access request again in a threshold period.
On the other hand, in order to support some important network initiated services, the network may decided to override the congestion control for the devices. For example, if a machine type communication server requires some essential reading from the sensors, it could send an application layer request towards the 3GPP network, which would trigger a notification to the Mobility Management Entity (MME) of the network. Based on the bearer identification and priority information associated with the application layer traffic, the MME may decide to page the device and bring it online even though the device was previous placed into congestion control back-off mode. The device, in response to the paging from the MME, may override the back-off control and initiate a connection request as a response. The Network, at both RRC layer and NAS layer, would accept this connection request as it is a response to the paging from the network.
In the development of the 3GPP standards, it was realized that the congestion control mechanism could also apply to normal devices not meant for machine type communications, if the operators desire so.
BRIEF SUMMARY
With the current trend of Internet and machine to machine communications, more and more devices are equipped with network access capabilities. This puts pressure on the existing mobile communication networks, which are not designed to handle large amount of devices with limited resources. Therefore, congestion control mechanisms are employed in order to spread out accesses of the devices.
With congestion control applied, an access request from a lower priority device, e.g. a machine type communication device, may be rejected, with the exception of network initiated communication sessions. For example, if a server in the network decides to obtain information from a device, the network could page the device and allow the communication. However, for certain devices, especially the machine type communication (MTC) devices, the generation of the response to the server can take a long time. This may result in the response being considered an independent communication session initiated by the device, and thus being rejected. Network operation would be affected, as the rejection would cause service interruption and waste of resources.
As described in the previous background, the network would allow network initiated machine type communications even if the network is in congestion control mode. This is important for some applications that require only lower priority for device initiated session but require higher priority for network initiated sessions. For example, a medical sensor as a mobile terminal that takes medical vital signs and sends data reports regularly to a server can wait for the next opportunity to transmit when no emergent event is detected. However, if the server application concludes that some abnormal sign is present and needs another reading of the patient's data, the communication should happen as soon as possible.
However, as the machine type communication applications and the underlying communication network are normally controlled by different operators, the server initiated session may not be able to obtain the desired priority, especially when the network is in the congestion control mode.
In an embodiment of the above example use case, the server application requesting a new reading from the sensor would send the
application layer request message towards the sensor. This application layer request message will arrive at the Serving Gateway (SGW) via the Packet Data Network Gateway (PGW), when the mobile network is using 3GPP Long Term Evolution (LTE) and System Architecture Evolution (SAE). As the sensor is in the IDLE mode, the SGW sends a Downlink Data Notification towards the MME, which includes also the bearer identifier and priority information. The MME decides to perform a paging procedure by sending a paging message to the sensor, and the sensor starts to initiate a mobile terminating session request towards the network by sending a service request with the proper indications. The radio networks and the MME allow the connection
establishment as it is responding to the paging. The SGW will deliver the application layer request message to the sensor.
However, as the sensor may take some time to perform the new measurement and other calculations, the application layer response may only be ready after an extended period. Therefore, the sensor would not send any data during this period, and the mobile network, unaware of the situation, would move the sensor back to the IDLE mode, e.g. by releasing the RRC
connections. This is true especially for networks in the congestion control mode, which may time out the mobile devices much faster than usual.
In this case, when the sensor has the application layer response ready, it needs to initiate an access request towards the network again to transit to CONNECTED mode to transmit the data. As this access request is no longer associated with the previous paging procedure, the sensor can only indicate the new access request as a mobile initiating request, which is of lower priority. Therefore, the network in the congestion control would reject the access request and may enforce a long back-off, e.g. in the order of several hours. This is obviously an undesired behavior for the medical application as the reading may lose its meaning after such a long delay.
The same problem exists for other machine type communication applications as well. For example, a surveillance camera may be triggered by application server to send video or images when it detects a certain event. This camera would only have data to send when the event is detected, which could be, for example, a few minutes later after the radio connection timed out.
A potential approach to avoid this behavior is for the sensor to always send bogus application layer data even if the data is not ready to keep the network connections. However, this has drawbacks for both the mobile terminal (e.g. the sensor) and the network. To keep in the connect mode, the mobile terminal (e.g. the sensor) needs to perform all the necessary operations, e.g. perform measurement, deliver measurement reports to the network, and produce the application layer data. These all consume power. For a battery powered device that needs to work over a long time, such power wastage may significantly reduce its life time. For the network, keep a mobile terminal (e.g. the sensor) in the CONNECT mode with meaningless data transmission also wastes network resources, especially if it is also in congestion. In addition, keeping the mobile terminal in CONNECT mode requires additional mobility related signalling and management. For example, whenever the mobile terminal changes its serving cells, even without changing its location, the network would be need to perform a handover procedure that involves several radio access network nodes and core network nodes. This could further aggravate the network congestion.
Another possible approach is for the mobile terminal (e.g. the sensor) to indicate some higher priority when it tries to initiate the access request to send the application layer data. However, as the network has the record of its subscription and states, such priority change by the mobile terminal would not pass the access control and authorization, which would still result in the request being rejected with a back-off penalty.
An embodiment may address the above discussed problems. In particular, an embodiment may provide a method and system to allow a more intelligent management of the congestion control, such that a delayed response to a network initiated session could be supported. An embodiment may introduce some intelligence in the device {e.g., an MTC Device) that can create a correlation with the network, e.g.
volunteering disconnection in exchange of a priority raise for the next access request in case of delay in generating the response to a network initiated session. The network may verify and grant the access based on the correlation when the device comes back with a request for the response transmission. Embodiments may also include methods to coordinate different layers when the network applies layered congestion control. An embodiment allows service interruption to be avoided. In additional, in an embodiment, the device does not need to maintain the connection with the network while generating the response. This may greatly reduce the device battery consumption and use of network resources.
An embodiment provides a system, method, and apparatus that is able to allow a mobile terminal to determine that a response to a network initiated session should be delayed and signal to the network to create a correlation of the network initiated session with the delayed response by voluntarily releasing the network initiated connection, such that network could link the access request for the delayed response with the network initiated connection and provides higher priority.
In an embodiment, a system for congestion control in a mobile communication network comprises: a mobile terminal that is capable of responding to an application layer request; an application layer server that is capable of requesting a response from the mobile terminal; and a network control entity that is capable of rejecting a connection request from the mobile terminal; wherein, in use, the mobile terminal decides that the response to a application layer request from the application layer server is delayed and releases an existing connection, such that the network control entity does not reject a connection request from the mobile terminal for transmitting the delayed response to the application layer request. In an embodiment, the mobile terminal is capable of negotiating with the network control entity and deciding the parameters to be used, such that the network control entity does not reject the connection request for transmitting the delayed response to the application layer request. In an embodiment, the negotiated parameters include a time period within which the network control entity does not reject the connection request from the mobile terminal. In an embodiment, the mobile terminal comprises of a connection manager that is capable of deciding whether a response is for an application layer request received from the application layer server. In an embodiment, the system further comprises: a access network controller that is capable of rejecting a connection request of the mobile terminal, wherein, the network control entity is capable of instructing the access network controller to accept a connection request based on the parameters negotiated between the network control entity and the mobile terminal. In an embodiment, the network control entity is capable of deciding a set of parameters to control whether to reject a connection request from the mobile terminal based on the information derived from transporting the application layer request. In an embodiment, the application layer server is a machine type communication server.
In an embodiment, a system comprises: a mobile terminal configured to generate responses to application layer requests; an application layer server configured to generate application layer requests; and a
communication network configured to communicatively couple the mobile terminal and the application layer server and to selectively reject connection requests from the mobile terminal in accordance with a congestion control policy, wherein the mobile terminal is configured to respond to a received application layer request by: determining whether a response to the request is likely to be a delayed response; and when it is determined the response to the request is likely to be a delayed response, generating a request to the network to accept a subsequent connection request associated with a delayed response to the application layer request. In an embodiment, the request to accept the subsequent connection request associated with the delayed response comprises an indication to release an existing connection with the mobile terminal. In an embodiment, the mobile terminal is configured to determine parameters included in the request to accept the subsequent connection request and the communication network is configured to selectively override the congestion control policy based on the determined parameters included in the request to accept the subsequent connection request. In an embodiment, the parameters include a time period and a network control entity of the
communication network is configured to accept the subsequent connection request from the mobile terminal when the subsequent connection request is received within the time period. In an embodiment, the mobile terminal comprises a connection manager configured to determine whether a generated response is to an application layer request received from the application layer server. In an embodiment, the network comprises: a network controller; and an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is capable of instructing the access network controller to accept a connection request based on the parameters negotiated between the network control entity and the mobile terminal. In an embodiment, the network comprises: a network controller; and an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is configured to instruct the access network controller to accept a connection request based on the determined parameters included in the request to accept the subsequent connection request. In an embodiment, the network is configured to determine, based on information derived from the received application layer request and in response to the request to accept the subsequent connection request, a set of parameters and to selectively override the congestion control policy based on the determined parameters. In an embodiment, the application layer server is a machine type communication server.
In an embodiment, a system comprises: means for generating responses to application layer requests; means for generating application layer requests; and means for communicatively coupling the means for generating responses to application layer requests to the means for generating application layer requests and for selectively rejecting connection requests from the means for generating responses to application layer requests; means for determining whether a response to an application layer request will be a delayed response; and means for generating, when it is determined the response to the application layer request will be a delayed response, a request to the means for
communicatively coupling to accept a subsequent connection request associated with a delayed response to the application layer request. In an embodiment, the request to accept the subsequent connection request associated with the delayed response comprises an indication to release an existing connection with means for generating responses to application layer requests. In an embodiment, the system comprising a mobile terminal including: the means for generating responses to application layer requests; the means for determining whether a response to an application layer request will be a delayed response; and the means for generating, when it is determined the response to the application layer request will be a delayed response, the request to the means for communicatively coupling. In an embodiment, the mobile terminal is configured to determine parameters included in the request to accept the subsequent connection request and the means for
communicatively coupling is configured to selectively override a congestion control policy based on the determined parameters included in the request to accept the subsequent connection request. In an embodiment, the parameters include a time period and the means for communicatively coupling is configured to accept the subsequent connection request from the mobile terminal when the subsequent connection request is received within the time period. In an embodiment, the mobile terminal comprises a connection manager configured to determine whether a generated response is to an application layer request received from the means for generating application layer requests. In an embodiment, the means for communicatively coupling comprises: a network controller; and an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is configured to instruct the access network controller to accept a connection request based on the determined parameters included in the request to accept the subsequent connection request. In an embodiment, the means for communicatively coupling is configured to determine, based on information derived from the received application layer request and in response to the request to accept the subsequent connection request, a set of parameters, and to selectively override a congestion control policy based on the determined parameters. In an embodiment, the means for generating application layer requests comprises a machine type communication server.
In an embodiment, a mobile terminal comprises: one or more configured devices configured to implement: an application response block configured to generate responses to application layer requests; and a connection manager block configured to: determine whether a response to an application layer request will be a delayed response; and when it is determined that the response to the application layer request will be a delayed response, generate a request to a communication network to accept a subsequent connection request associated with a delayed response to the application layer request. In an embodiment, the request to accept the subsequent connection request associated with the delayed response comprises an indication to release an existing connection with the mobile terminal. In an embodiment, the request to accept the subsequent connection request associated with the delayed responses comprises an indication to store an indicator of the delayed response. In an embodiment, the connection manager block is configured to determine parameters of the request to accept the subsequent connection request to cause the communication network to selectively override a congestion control policy. In an embodiment, the parameters include an indication of when the subsequent connection request should be treated as a valid request. In an embodiment, the connection manager block is configured to determine whether a generated response is to the application layer request. In an embodiment, when it is determined the generated response is to the application layer request, the connection manager block is configured to determine whether a congestion control policy should be overridden. In an embodiment, when it is determined the congestion control policy should be overridden, the mobile terminal is configured to transmit the subsequent connection request. In an embodiment, the subsequent connection request is a mobile terminating request. In an embodiment, the subsequent connection request is a mobile originating request including a delayed response indicator. In an embodiment, when it is determined the generated response is to the application layer request, the mobile terminal is configured to initiate a radio link recovery as the subsequent connection request.
In an embodiment, a communication network comprises: one or more memories; and one or more configured processing devices configured to implement a communication control block, wherein the communication control block is configured to: selectively block connection requests from mobile terminals; and respond to a request from a mobile terminal to accept a subsequent connection request associated with a delayed response to an application layer request by selectively storing an indication of an expected delayed response from the mobile terminal to the application layer request. In an embodiment, the communication control block is configured to determine whether the mobile terminal is authorized to submit the request to accept a subsequent connection request associated with the delayed response to the application layer request. In an embodiment, an existing connection with the mobile terminal is released in response to the request to accept the subsequent connection request. In an embodiment, the network comprises: a network controller; and an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is configured to instruct the access network controller to accept a connection request based on parameters included in the request to accept the subsequent connection request. In an embodiment, the communication control block is configured to determine, based on information derived from a received application layer request and in response to the request to accept the
subsequent connection request, a set of parameters and to selectively override a congestion control policy based on the determined parameters. In an embodiment, the parameters include an indication of when the subsequent connection request should be treated as a valid request. In an embodiment, communication control block is configured to respond to a subsequent connection request from the mobile terminal by determining whether the subsequent connection request is associated with a delayed response to the application layer request based on the stored indication of an expected delayed response from the mobile terminal to the application layer request and to selectively accept the subsequent connection request based on the
determination of whether the subsequent connection request is associated with a delayed response to the application layer request. In an embodiment, the subsequent connection request is a mobile terminating request. In an embodiment, the subsequent connection request is a mobile originating request including a delayed response indicator. In an embodiment, the subsequent connection request is a radio link recovery request. In an embodiment, the communication control block is configured to selectively accept the subsequent connection request based on when the subsequent connection request is received. In an embodiment, the one or more configured processing devices comprise a mobile management controller and a base station. In an
embodiment, the base station is an eNodeB base station.
In an embodiment, a method comprises: determining whether a response to a received application layer request will be a delayed response; and when it is determined that the response to the received application layer request will be a delayed response, generating a request to a communication network to accept a subsequent connection request associated with a delayed response to the application layer request, wherein the determining and generating are performed by a configured mobile terminal. In an embodiment, the method further comprises: receiving a page associated with the application layer request; and, in response to the page: overriding a congestion control policy; and transiting the configured mobile terminal to a connect mode. In an embodiment, the generated request includes an indication to release an existing connection with the mobile terminal. In an embodiment, the method further comprises: determining whether a delayed response to the application layer request has been generated; and when it is determined that a delayed response to the application layer request has been generated, determining whether to override congestion control; and when it is determined to override congestion control, generating the subsequent connection request. In an embodiment, the generating the subsequent connection request comprises generating a mobile terminating request. In an embodiment, the generating the subsequent connection request comprises generating a mobile originating request including a delayed response indicator. In an embodiment, the method further comprises: determining whether a delayed response to the application layer request has been generated; and when it is determined that a delayed response to the application layer request has been generated, determining whether a timer has expired; and when it is determined the timer has not expired, generating the subsequent connection request. In an embodiment, the generating the subsequent connection request comprises initiating a radio link recovery.
In an embodiment, a method comprises: receiving a request from a mobile terminal to accept a subsequent connection request from the mobile terminal associated with a delayed response to an application layer request; selectively storing an indication of an expected delayed response from the mobile terminal to the application layer request; and responding to a
subsequent connection request received from the mobile terminal by:
determining whether the subsequent connection request is associated with the delayed response to the application layer request based on the stored indication; and when it is determined the subsequent connection request is associated with the delayed response to the application layer request, selectively establishing a connection with the mobile terminal, the storing and responding being performed by one or more configured processing devices of a communication network. In an embodiment, the selectively storing the indication comprises determining whether the mobile terminal is authorized to provide a delayed response to the application layer request. In an embodiment, the selectively establishing a connection comprises determining whether a timer has expired and establishing a connection when it is determined the timer has not expired. In an embodiment, the selectively establishing a connection comprises overriding a congestion control policy. In an embodiment, the subsequent connection request comprises a mobile terminating request. In an embodiment, the subsequent connection request is a mobile originating request including a delayed response indicator. In an embodiment, the subsequent connection request comprises a radio link recovery request.
In an embodiment, a mobile terminal is able to go to IDLE mode before sending a delayed response to a network initiated session even when the network is in congestion control. This may allow a better support of the different machine type communications, and avoids wastage of energy and computation resources on the mobile terminal. At the same time, the
congested network can avoid waste network resources on mobile terminals that have no meaningful use of the connection, and reduce potential additional mobility management controls. It may allow the network to serve more terminals with higher efficiency, which can contribute to alleviate the
congestions.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
Figure 1 illustrates a network configuration of an embodiment where Machine Type Communication (MTC) services are provided in a separate Service Domain than the 3GPP Domain; Figure 2 illustrates an example operation sequence of an embodiment where an MTC Device decides that a delayed response is desired and releases its existing connections;
Figure 3 illustrates an example operation sequence of an embodiment where an MTC Device establishes a connection to transmit delayed response data;
Figure 4 illustrates an alternative operation sequence of an embodiment where an MTC Device recovers a connection for transmitting the delayed response data;
Figure 5 illustrates an alternative operation sequence of an embodiment where the network decides that a delayed response is desired and allows an MTC Device to establish a connection to transmit the delayed response data;
Figure 6 illustrates an example architecture of an embodiment of an MTC Device;
Figure 7 illustrates an example architecture of an embodiment of an eNodeB (eNB);
Figure 8 illustrated an example architecture of an embodiment of a Mobility Management Entity (MME);
Figure 9 illustrated example logic of an embodiment that can be used by a Connection Manager of an MTC Device for the handling of connections for an MTC application;
Figure 10 illustrated an embodiment of alternative logic that can be used by a Connection Manager of an MTC Device for the handling of connections for an MTC application;
Figure 1 1 illustrated an embodiment of an alternative system architecture that supports an MTC application over a control plane in 3GPP Domain. DETAILED DESCRIPTION
In the following description, for the purpose of explanation, specific numbers, times, structures, protocols, and other parameters are set forth in order to provide a thorough understanding of embodiments. However, it will be apparent to anyone skilled in the art that embodiments of the present disclosure may be practiced without these specific details.
In the following description, certain details are set forth in order to provide a thorough understanding of various embodiments of devices, methods and articles. However, one of skill in the art will understand that other embodiments may be practiced without these details. In other instances, well- known structures and methods associated with, for example, communication networks, congestion control, etc., have not been shown or described in detail in some figures to avoid unnecessarily obscuring descriptions of the
embodiments.
Unless the context requires otherwise, throughout the specification and claims which follow, the word "comprise" and variations thereof, such as "comprising," and "comprises," are to be construed in an open, inclusive sense, that is, as "including, but not limited to."
Reference throughout this specification to "one embodiment," or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment," or "in an embodiment" in various places throughout this specification are not necessarily referring to the same embodiment, or to all embodiments.
Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments to obtain further embodiments.
The headings are provided for convenience only, and do not interpret the scope or meaning of this disclosure or the claims. The sizes and relative positions of elements in the drawings are not necessarily drawn to scale. For example, the shapes of various elements and angles are not drawn to scale, and some of these elements may be enlarged and positioned to improve drawing legibility. Further, the particular shapes of the elements as drawn are not necessarily intended to convey any information regarding the actual shape of particular elements, and have been selected solely for ease of recognition in the drawings. References, such as timing and geometric references, etc., are not intended to refer to ideal embodiments. For example, a reference to square-shaped object does not mean that an element has a geometrically perfect square shape.
In the following description, for the purpose of explanation, the 3GPP Long Term Evolution (LTE) and Evolved Packet System (EPS) are used as example access technology and network architecture. However, it will be apparent to anyone skilled in the art that embodiments of the present disclosure may be practiced with other access technology and network architectures, e.g. GSM, GPRS, UMTS, WiMAX, LTE Advanced, etc.
With reference to Figure 1 , an example architecture of a network 100 that supports Machine Type Communication (MTC) is shown. The network supports one or more Machine Type Communication Devices, as illustrated MTC Devices 101 to 107, to access MTC services from an MTC Server 151 in a Service Domain 150 via a 3GPP Domain 130. The 3GPP Domain 130 may, for example, be any network that supports the systems and access
technologies as defined by the 3rd Generation Partnership Project (3GPP). For example, the system may be a System Architecture Evolution (SAE) for the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) as defined in General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, 3GPP TS 23.401 v10.4.0 Release 10, 201 1 -06-12, the 3GPP Domain 130 may comprise one or more E- UTRAN NodeBs (eNB) 131 , one or more Mobility Management Entities (MME) 131 , one or more Serving Gateways (SGW) 135, and one or more Packet Data
Network Gateways (PGW) 137.
The MTC Device {e.g. MTC Device 101 ) connects to the eNB 131 via a wireless interface 1 1 1 , which includes control and data channels. The eNB 131 is managed by the MME 133 via a control interface 121 , and can also relay control signaling between the MTC Device 101 and the MME 133 over the same interface. The eNB 131 provides a data transport interface 1 13 towards the SGW 135, which is managed by the MME 133 with a control interface 123.
The SGW 135 has an interface 1 15 towards the PGW 137, which supports both data and control. The PGW 137 provides a communication interface 153 to the
Service Domain 150, which includes the MTC Server 151 .
Therefore, in use, the MTC Device 101 is configured to use control signaling over the interface 1 1 1 and 121 to signal eNB 131 and MME
133 to establish radio connections and Evolved Packet System (EPS) bearers respectively. The MME 133 based on the signaling instructs eNB 131 and
SGW 135 to setup the data connections over the interface 1 1 1 , 1 13, and 1 15, such that the MTC Device 101 is able to communicate with the MTC Server
151 .
As normally Machine Type Communication involves a large number of devices, the network may protect itself from surges in both data and signaling traffic. Therefore, the network may employ congestion mechanisms at different layers, e.g., such as those introduced in 3GPP TR 23.888 v1 .5.0 Release 1 1 , referenced above. For example, the MME 133 may active congestion control when the signaling or data load exceeds certain threshold levels, and may simply reject connection requests from an MTC Device {e.g., MTC Device 101 ). When the situation becomes worse, for example, the congestion control may be extended to radio access, e.g., the eNB 131 may start to reject radio connection establishment requests from the MTC Device {e.g., MTC Device 101 ). In some cases, the eNB 131 may even broadcast an access barring indication that may force lower priority devices to backoff from accessing the network.
Although Figure 1 shows that the PGW 137, SGW 135, MME 133, eNB 131 are in the same 3GPP Domain 130, they can be under different operators' control in practice. For example, in a roaming case, the MTC Device 101 may access a first operator's network that includes eNB 131 , MME 133, SGW 135, but the PGW 137 may be in a second operator's network. In some deployment cases, e.g. network sharing, the eNB 131 may be even shared by different operators.
Figure 1 only shows the most essential entities in the 3GPP domain relevant to the present disclosure. In practice, there are more functional entities in the 3GPP Domain 130, e.g. Home Subscriber Server (HSS), Policy Control and Charging Rules Function (PCRF), Authentication Authorization and Accounting Server (AAA Server), etc. The existence of these additional entities does not affect the general principles of the present disclosure.
With reference to Figure 2, an operation sequence example is provided to illustrate an embodiment in the context of the network 100 shown in Figure 1 . It is assumed that the network 100 is in congestion control mode, and the MTC Device, e.g., the User Terminal (UE) in 3GPP Domain's point of view, is originally in an IDLE mode, as indicated in step 201 . In the IDLE mode, the MTC Device 101 does not have any radio connection with the eNB 131 , and the eNB 131 does not have any context information about the MTC Device 101 . Also, there is no data connection for the MTC Device 101 between the eNB 131 and the SGW 135.
However, the data connection for the MTC Device 101 still exists between the SGW 135 and the PGW 137. Therefore, when the MTC Server 151 sends Downlink Data towards the MTC Device 101 , the Downlink Data will arrive at the PGW 137 and be forwarded to the SGW 135, as indicated in step 203 and 205. For example, the MTC Sever 151 may send a MTC application layer request for obtaining a reading from a meter towards the IP Address of the MTC Device. The request will be routed to the PGW 137 as the IP Address belongs to it. The PGW 137 will map the IP Address to the Evolved Packet System (EPS) Bearer tunnel for the MTC Device 101 , and forward the request towards SGW 135 inside the tunnel.
Because there is no data connection between the eNB 131 and the SGW 135, the SGW 135 buffers the Downlink Data, in step 207, and triggers a Downlink Data Notification to the MME 133, in step 209, such that the data connection towards the MTC Device 101 may be established. This Downlink Data Notification 209 may carry the EPS Bearer identifier, priority, information, etc.
As the network is in congestion control mode, the MME 133 uses the EPS Bearer identifier to determine the service that triggers the notification, and uses the corresponding subscription information of the MTC Device 101 and the indicated priority to decide whether the congestion control should be overridden and allow the MTC Device 101 to have a data connection, in step 21 1 .
In case the MME 133 decides that the service triggering the notification is, for example, a high priority service, and should be allowed, it sends a Paging message to the eNB 131 , in step 213, which includes the identifier of the MTC Device 101 . This Paging message would be translated by the eNB 131 into the radio layer Paging and be broadcasted in the cell. It is obvious to anyone skilled in the art after reviewing this disclosure that the MME 133 may send the Paging to multiple eNBs, e.g. all the eNBs within a Tracking Area (TA), and all the eNBs may translate and broadcast the Paging message. In certain cases, the MME 133 may limit the number of the eNBs that should send the Paging message based on MTC Device 101 subscription information, e.g. Close Subscriber Group (CSG) data, or network topology information, etc.
When the MTC Device 101 receives the Paging 215 on the radio layer, it informs the connection management function (see Connection Manager 603 in Figure 6), and decides that the congestion control should be overridden, in step 217. For example, if the MTC Device 101 has a backoff timer running on either the Non-Access Stratum (NAS) layer (see NAS control 605 in Figure 6) or Radio Resource Control (RRC) layer (see Radio Control 607 in Figure 6), the connection management stops those timers, and triggers a NAS layer signaling message, e.g. Service Request, towards the MME 133 for transiting to CONNECTED mode and establishing the corresponding data connections.
This NAS layer signaling may trigger the radio control function to establish a RRC connection by sending a RRC Connection Request towards the eNB 131 , in step 219, indicating it is "mobile terminating", e.g. it is in response to a previous paging, and the identity of the MTC Device. After receiving this RRC Connection Request 219, the eNB 131 verifies it against the identity indicated in the Paging message 213, and decides to override the congestion control, if any, in step 221 , because it is a response to the network initiated service that is allowed by the MME 133.
The eNB 131 accepts the RRC connection request by replying with an RRC Connection Setup, in step 223, and the MTC Device will use the established RRC connection to forward the NAS layer signaling towards the MME 133, e.g. by piggybacking the NAS layer Service Request message onto the radio layer RRC Connection Setup Complete message, in step 225. The NAS layer Service Request message will be forwarded to the MME 133 by the eNB 131 in an Initial UE Message, in step 227, which also includes other information, e.g. the identity of the eNB, location, CSG ID, etc.
The MME 133, in the congestion control mode, would then use the information in the Initial UE Message and the Service Request 227 to decide whether to accept the connection request. In case the request is accepted, in step 231 the MME 133 sends an Initial Context Setup Request to the eNB 131 indicating the data connections to be established and the MTC Device (101 ) context information, e.g. the keying materials to start the encryptions and integrity protection between MTC Device 101 and eNB 131 . This Initial Context Setup Request triggers the eNB 131 to establish the corresponding radio bearers with the MTC Device 101 , in step 233. Afterwards, the eNB 131 responds with an Initial Context Setup Complete message to the MME 133 in step 235. The Initial Context Setup Complete message also includes information to establish the data connection for the MTC Device 101 , e.g. the downlink tunnel end point identifier, etc. With such information, the MME 133 instructs the SGW 135 to establish the data connections with a Modify Bearer Request or Modify Access Bearer Request message, in step 237.
When the Modify Bearer Request 237 is received, the SGW 135 has enough information to deliver the Downlink Data towards the eNB 131 , in step 239. This Downlink Data would be forwarded to the MTC Device 101 via the radio bearer established in step 233, in step 241 . The received Downlink Data will be forwarded to the MTC application layer (see MTC Application 601 in Figure 6) on the MTC Device 101 .
The MTC Device 101 may not be able to provide a response in a timely manner. For example, the Downlink Data may be an MTC application layer request, and the MTC Device 101 may not be able to generate a response to the request immediately. For example, a sensor may require a few minutes to get a measurements, a low power device may take over ten minutes to generate a calculated response, etc.
In another example, an MTC Device 101 may be configured to wait for some event to trigger a response. For example, if the MTC application layer request is for a Surveillance Camera to stream videos if a facial detection located a certain person, the Surveillance Camera/MTC Device 101 may only have a response after a much longer time.
In another example, a response from the MTC Device 101 may depend on the mobility of the device. For example, an MTC Server 151 may request in the Downlink Data a receiving Mobile Monitoring Device to send data or Audio-Visual report once it arrives at an accident location. The MTC Device/Mobile Monitoring Device 101 may be configured to wait to generate a response when the device arrives at the indicated location.
The MTC Device 101 may decide that a Delayed Response to the Downlink Data 241 would be used, in step 245. This may be an application layer decision, a MTC Device 101 configuration, or a subscription feature, etc. Once it is decided that the response would be delayed, the MTC Device 101 triggers a NAS layer signaling towards the MME 133 to indicate request for the support of Delayed Request, e.g. by using a Tracking Area Update (TAU) Request message, as in step 247. In the TAU Request 247, the MTC Device 101 includes a "Delayed Response" indicator, which informs the MME 133 that the MTC Device 101 does not have uplink data to send for a period of time and prefers to voluntarily release the connection.
The "Delayed Response" indicator could be a simple flag, or include additional information, e.g. a "Correlation Token", "Expected Timer for the Delayed Response", etc. In case there is additional information in the
"Delayed Response" indicator, it may use the Type-Length-Value (TLV) coding, such that the additional information could be optionally included when necessary without affecting the indicator's format.
An example format of the "Delayed Response" indicator could be as following (using the Abstract Syntax Notation ONE (ASN.1 ) of
Telecommunication Standardization Sector of the International
Telecommunications Union (ITU-T)):
DelayedResponse ::= SEQUENCE {
delayedResponseFlag ENUMERATED { true, false}, correlationToken OCTET STRING OPTIONAL, expectedTimerforDelayedResponse INTEGER (0..4095)
OPTIONAL
}
The "Correlation Token" may be generated by the MTC Device 101 based, for example, on its subscription, temporary identifier, permanent identifier, device identifier, or random number, etc. The Correlation Token may be used to help the network to correlate and verify the connection established later for the delayed response data.
The "Expected Timer for the Delayed Response" provides a timer value, within which the MTC Device 101 expects the network to support the establishment of a new connection for delivering the delayed response data. It may be in the format of a relative time period value, e.g. 10 minutes, or an absolute time, e.g. certain time of the day, etc. In the above example format, the timer is indicated in number of seconds. This value could be indicated by the MTC application on the MTC Device 101 , based on the device configuration and operation status, or derived from the subscription, etc. When provided in the TAU Request 247, this timer may be a suggestion from the MTC Device 101 . The final timer value may be decided by the network, e.g. MME 133.
After receiving a TAU Request 247 with the "Delayed Response " indicator, the MME 133 in step 249 evaluates whether the requested Delayed Response is allowable, for example based on the subscription data of the MTC Device 101 , and the information in the indicator, e.g. the "Expected Timer for the Delayed Response".
In case the "Delayed Response" indicator does not include any of the additional information, e.g. it is a simple flag, the MME 133 may generate the corresponding information. For example, the MME 133 may generate a "Correlation Token" based on the temporary identity allocated to the MTC Device 101 and some keying materials. The MME 133 may also decide an "Expected Timer for the Delayed Response" based on the MTC Device 101 subscription information and the network status, etc.
The MME 133 stores the "Delayed Response" indicator and the corresponding information, in step 249. In this process, the MME 133 may update the additional information associated with the "Delayed Response" and store it, in step 249.
The MME 133 includes the updated "Delayed Response" indicator and associated information in the TAU Accept message sent towards the MTC Device 101 , in step 251 . It should be noted that the MME 133 may decide that the Delayed Response feature should not be supported for this particular MTC Device 101 due to subscription limitation, or network status, operator policy, etc. In such a case, the MME 133 may update the "Delayed Response" indicator in the TAU Accept 251 to signal that the delayed response is not allowed, e.g. by setting the "delayedResponseFlag" to "false". The MME 133 may not store any information at step 249 if the delayed response is not allowed.
In response to the TAU Accept 251 , in step 253 the MTC Device 101 creates a "Delayed Response Record" entry based on the "Delayed
Response" indicator the MTC Device 101 sent in the TAU Request 247 and/or the updated "Delayed Response" indicator received in the TAU Accept 251 . This "Delayed Response Record" may include among other information a timer that is set to the value of "expectedTimerforDelayedResponse", a token set with the value of "correlationToken", and other information to identify the delayed MTC application, e.g. application identifier, addresses, etc. The MTC Device 101 may typically remove the "Delayed Response Record" once the timer expires.
The MME 133 also signals towards the eNB 131 to release the connection for the MTC Device 101 with a UE Context Release message, in step 255. The MME 133 only needs to perform this step if the delayed response is to be supported. The MME 133 also includes the "Delayed
Response" indicator in the UE Context Release message 255. If the MME 133 decides at step 249 that the delayed response is not to be supported, it is up to the MME's 133 local policy or operator configurations to decide if the
connection should be released.
After receiving this UE Context Release with the "Delayed
Response" indicator 255, the eNB 131 initiates the release of the radio bearers and RRC connections, as in step 259. The eNB 131 also uses the "Delayed Response" indicator to manage the context for the MTC Device 101 . For example, if the "delayedResponseFlag" is set to true, the eNB 131 may remove all the local context information for the MTC Device 101 , but keep a "Delayed Response Entry," in step 257, with the MTC Device's 101 identity, e.g.
International Mobile Subscriber Identity (IMSI), Temporary Mobile Subscriber Identity (TMSI), or International Mobile Equipment Identity (IMEI), etc. The eNB 131 may store the "correlationToken" together with the IMSI or TMSI if it is included in the "Delayed Response" indicator. The eNB 131 starts a timer with the value indicated in "expectedTimerforDelayedResponse", and associate the timer with the "Delayed Response Entry". If the
"expectedTimerforDelayedResponse" is not present in the "Delayed Response" indicator, the eNB 131 may, based on its local policy, network status, and operator configuration, decide the value for the timer. The eNB 131 may typically remove this "Delayed Response Entry" when the timer expires.
The eNB 131 will acknowledge the release of MTC Device 101 connections with a UE Context Release message to the MME 133, in step 261 . The MME 133 may update the context for the MTC Device 101 accordingly. At this point of time, the MTC Device 101 may go to IDLE mode at both the MTC Device 101 side and network side, e.g. eNB 131 and MME 133.
With reference to Figure 3, an embodiment of an operation sequence example for the MTC Device 101 to send the delayed response data is presented. It is assumed that the MTC Device 101 has followed the operation embodiment presented in Figure 2 before this operation.
At some point of time, the MTC application on the MTC Device 101 may have the data ready to respond to the application layer request from the MTC Server 151 , as shown in step 301 . As the MTC Device 101 is in the IDLE mode, this data triggers the connection manager of the MTC Device 101 to request establishing of connections, e.g. to transit to CONNECTED mode. The MTC Device 101 may internally check whether the data is for the Delayed Response application, e.g. it is generated in response to the previous received Downlink Data 241 . This may be achieved by checking for example the application identifier, the target address or domain of the data, etc. Also, the MTC Device 101 may check if there is a valid "Delayed Response Record" associated with the MTC application, in step 303.
If the MTC Device 101 has a valid "Delayed Response Record" for the MTC application that generates the data, the MTC Device 101 overrides any congestion control in place, e.g. the Mobility Management Backoff timer at NAS layer, or the extended Wait time at RRC layer, etc. The MTC Device 101 then instructs its RRC layer to signal to the eNB 131 for the establishment of a RRC connection, with a RRC Connection Request, in step 305.
This RRC Connection Request 305 includes the MTC Device 101 identifier, e.g. the IMSI or TMSI, and the Correlation Token set to the value of "correlationToken" if it exists in the "Delayed Response" indicator. The RRC Connection Request 305 is configured to indicate that the response is a delayed response to reduce the possibility the request will be rejected. For example, the MTC Device 101 may indicate "mobile terminating" as the cause in the RRC Connection Request 305, even though the MTC Device did not receive a current paging message to which to respond. This reduces the possibility the RRC layer congestion control at the eNB 131 rejects the request.
In another example, the MTC Device 101 may indicate "mobile originating" as the cause in the RRC Connection Request 305, and include a "Delayed Response" indicator. This indicates to the eNB 131 to treat the request differently from a normal mobile originating connection request.
When the eNB 131 receives the RRC Connection Request 305, the eNB 131 checks if a valid "Delayed Response Entry" for the indicated MTC Device 101 identifier, e.g. IMSI or TMSI, is stored. In case the RRC Connection Request 305 includes a Correlation Token, the eNB 131 may also verify the Correlation Token against that stored in the "Delayed Response Entry".
If the verification is successful, the eNB 131 may override any congestion control policy in place, and grant access to the MTC Device 101 , in step 307. The eNB 131 accepts the RRC Connection Request with a RRC Connection Setup message, in step 309.
The MTC Device 101 then signals towards the MME 133 with a NAS layer Service Request or Extended Service Request message
piggybacked on the RRC Connection Setup Complete toward the eNB 131 , in step 31 1 . In the Service Request or Extended Service Request, the MTC Device 101 may include the "Delayed Response" indicator or a subset of it, e.g. the Correlation Token. This NAS layer Service Request or Extended Service Request message is forwarded by the eNB 131 to the MME 133 using a Initial UE Message, in step 313.
When the Service Request or Extended Service Request with the "Delayed Response" indicator is received, the MME 133 does not reject the request as a matter of course even if the congestion control is in place.
Instead, the MME 133 verifies whether there is a valid "Delayed Response" indicator associated with the MTC Device's 101 context, e.g., the timer of the "Delayed Response" indicator has not expired. The MME 133 may also verify the Correction Token, if included in the Service Request or Extended Service Request, against that stored in the "Delayed Response" indicator. If verification is not successful, the MME 133 rejects the request.
If the verification is successful, the MME 133 accepts the Service
Request or Extended Service Request and transits the MTC Device 101 to CONNECTED mode. The MME 133 instructs the eNB 131 to establish the corresponding bearers with the Initial Context Setup Request 317. The eNB 131 in turn establishes the radio bearers, in step 319.
At this point of time, the MTC Device 101 transmits the delayed response data towards the MTC Server 151 via the eNB 131 , SGW 135, and PGW 137. The rest of the signaling may be the same as that discussed in General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, 3GPP TS 23.401 v10.4.0 Release 10, 201 1 -06-12. The MTC Device 101 could be mobile in certain deployments. Therefore, when the delayed response data is ready, the MTC Device 101 may have moved to another eNB's coverage. In order to support this case, the eNB 133 may decide locally to propagate the "Delayed Response Entry" to a few other eNBs around itself, e.g. those eNBs having X2 interface established with itself. This way, even if the MTC Device 101 is requesting the RRC connection from a different eNB, in step 305, the new eNB would be able to verify and grant the access according to the delayed response settings.
The MME 133 may assist in this aspect as well. As the MME 133 may be capable of predicting the mobility of the MTC Device 101 based on its track record, the MME 133 may decide a group of eNBs to be covered based on the current location of the MTC Device 101 , the value of
"expectedTimerforDelayedResponse", and mobility pattern of the MTC Device 101 , etc. The MME 133 may signal to this group of eNBs with an S1 interface message indicating the information in the "Delayed Response Entry". This way, the eNBs may also be prepared to support the MTC Device 101 for the delayed response.
With reference to Figure 4, an alternative embodiment of an operation sequence for the MTC Device 101 to transmit the delayed response data is illustrated. In this operation, the eNBs and the MTC Device 101 make use of the radio link failure recovery mechanism to establish the connection when delayed response data is ready. It is assumed that the MTC Device 101 has been following the operation of the embodiment shown in Figure 2 before starting the operation shown in Figure 4, e.g. the step 201 to 249 were carried out before step 401 .
When the MTC Device 101 receives the TAU Accept message 401 with the "Delayed Response" indicator, it configures a radio layer entry for the delayed response. In this example, the MTC device 101 sets a radio link failure recovery timer to the value of the "expectedTimerforDelayedResponse". Similarly, when the eNB 131 receives the UE Context Release 405 message with the "Delayed Response" indicator, the eNB configures the radio link failure recovery timer for the MTC Device 101 to be the value of "expectedTimerforDelayed Response" in step 407.
The eNB 131 then releases the radio layer connection, e.g. RRC connection, towards the MTC Device 101 , in step 409. At this point of time, both the MTC Device 101 and the eNB 131 would start the radio link failure timer, and enter the radio link failure recovery mode.
For the MTC Device 101 , it is using a modified Delayed Response radio link failure recovery mode, in step 41 1 . In this mode, the MTC Device 101 does not attempt any recovery signaling or transmission before the timer expires, even if it detected the signal for the eNB 131 . Instead, the MTC Device 101 performs some other essential IDLE mode radio layer operation, e.g.
keeping the synchronization, listening for the paging, etc.
At the eNB 131 side, the eNB releases the data bearer context towards the MME 133, in step 413. Therefore, if there is any downlink traffic towards the MTC Device 101 , paging procedure will be triggered, and the eNB 101 will broadcast the paging message accordingly, as if the MTC Device 101 is in IDLE mode. At the moment, the eNB 131 only keep the signaling bearer context for the MTC Device 101 , associated with the "Delayed Response" indicator.
As part of the radio link failure recovery process, the eNB 131 may also propagate the stored context of the MTC Device to other eNBs surrounding the location. Therefore, the MTC Device 101 would be able to perform the radio link failure recovery on any of these prepared eNBs.
At some point of time, the MTC application on the MTC Device 101 has the response data ready, in step 415. The MTC Device 101
determines the data is subject to delayed response treatment based on operation similar to that of step 301 . When it is determined that delayed response data is ready, the MTC Device 101 checks if the radio link failure recovery timer has expired. If not, the MTC Device 101 performs radio link failure recovery signaling, e.g., by sending a RRC Connection Re-establishment Request, in step 417. This RRC Connection Re-establishment Request may contain the "Delayed Response" indicatoror, it may only include a subset information element of the "Delayed Response" indicator, e.g. the Correlation Token.
Upon receiving the RRC Connection Re-establishment Request 417, the eNB 131 checks in step 419 if the context for the MTC Device 101 is present and the radio link failure recovery timer is expired. If the context does not exist on the eNB 131 , the eNB 131 may try to retrieve the context from another eNB 131 around itself identified by the cell information, e.g. Physical Cell Identifier, provided by the MTC Device 101 in the RRC Connection Re- establishment Request 417 message.
If the check is successful, the eNB 131 accepts the recovery, and indicates to the MTC Device 101 with the RRC Connection Re-establishment message, in step 421 , and recovers the signaling radio bearer. The MTC Device 101 , after receiving the RRC Connection Re-establishment message 421 and recovering the signaling radio bearer, will notify the eNB 131 that the RRC Connection Re-establishment is complete in step 423, and send a NAS layer Service Request or Extended Service Request to the MME 133 to recover the connections for data bearers in step 424. The contents of the NAS layer Service Request or Extended Service Request may be the same as that of step 31 1 and 313 of Figure 3.
When the Service Request or Extended Service Request 423 is received, the MME 133 checks and determines whether the access should be granted. As illustrated, steps 425 to 451 of Figure 4 are identical to those of steps 315 to 341 of Figure 3.
It is obvious to anyone skilled in the art after reviewing the disclosure that some of the signaling messages used in the above description could be changed with other signaling messages without affecting the general principles of the disclosure. For example, the TAU Request 247 and TAU Accept 251 , 401 may be replaced by a Detach Request and Detach Accept with special information elements, e.g. "Delayed Response" indicator. Alternatively, these messages could be the UE initiated Request Bearer Resources
Modification and Session Management Request message carrying the
"Delayed Response" indicator. Or, these messages could be the UE initiated PDN Disconnection Request and Deactivate EPS Bearer Context Request message carrying the "Delayed Response" indicator.
When the MTC Device 101 uses the Extended Service Request
31 1 , 313, 423, it may define a new cause code in the NAS layer message such that it can indicate the request is for Delayed Response. In that case, there is no need to carry additional "Delayed Response" indicator if no additional information, e.g. Correlation Token, is used by the system.
With reference to Figure 5, an alternative operation sequence of an embodiment is illustrated. As the MTC Device 101 is communicating with the MTC Server 151 using a wireless connection, in certain cases, the MTC Device 101 may lose the connection, e.g. due to loss of radio signals. For example, when going through a long tunnel or a lift, the MTC Device 101 may experience radio link failure. If the radio link failure is not recovered in time, the MTC Device 101 may fall into IDLE mode. Therefore, if the MTC Device 101 tries to send data again, it would need to request to establish the connection and transit to CONNECTED mode first. In a congestion controlled network, such request may be rejected. The operation of Figure 5 provides a solution to this issue.
It is assumed that the network is in congestion control mode, i.e. the MME 133 and eNB 131 may reject a connection request if it is not considered as high priority. The MTC Device 101 receives Downlink Data from the MTC Server 151 following the steps 501 to 537, which as illustrated are essentially identical to those of steps 201 to 243 of Figure 2. Some differences between and common features of the illustrated embodiments of Figures 2 and 5 are mentioned in the discussion below of Figure 5, with some of the detail of Figure 2 omitted from Figure 5.
At step 521 and 523, the MTC Device 101 may indicate in the Service Request or Extended Service Request that the device supports delayed response handling. This could be achieved by including a special flag or using a new cause code in the Extended Service Request.
The MME 133, knowing the service type and priority based on the Downlink Data Notification 507 and the MTC Device 101 subscription, may decide if a delayed response handling should be allowed, in step 525. If the MME 133 decides that the delayed response handling is to be supported, it also decides the corresponding parameters to be used, e.g. Correlation Token, Expected Timer for Delayed Response, etc. The MME 133 stores this information together with the MTC Device 101 context in step 525, and passes the information in a "Delayed Response Allowed" information element in the Initial Context Setup Request to the eNB 131 , in step 527. The "Delayed Response Allowed" information element may take the format of the "Delayed Response" indicator discussed above with respect to Figure 2.
After receiving the "Delayed Response Allowed" information element, the eNB 131 creates a "Delayed Response Entry", (not shown in Figure 5) identical to that of step 257 of Figure 2.
When establishing the radio bearer at step 529, the eNB 131 may select to forward the "Delayed Response Allowed" information to the MTC Device 101 if the radio layer signaling is enhanced to support it.
At some point of time, the MTC Device 101 falls into IDLE mode, as illustrated in step 539. This could due to different reasons, e.g. long period of inactivity, radio link failure, or other radio access network events, etc. In this case, the bearer and context of the MTC Device 101 would be removed on the eNB 131 , and the trigger would be sent to the MME 133. The eNB 131 and the MME 133 at this time each starts a timer with the value set to "expectedTimerforDelayedResponse".
At some point, the MTC Device 101 has MTC application data to be sent towards the MTC Server 151 . The MTC Device 101 decides that congestion control should be overridden in step 543, and a RRC Connection should be requested, in step 545. Upon receiving this RRC Connection
Request 545, the eNB checks if it has a valid "Delayed Response Entry" for the MTC Device 101 , e.g., whether the timer is expired. If the "Delayed Response Entry" is valid, the eNB 131 allows the RRC Connection, in step 549, and the MTC Device 101 would request at NAS layer for connection establishment, in step 551 .
In this NAS layer Service Request or Extended Service Request, the MTC Device 101 indicates the "Delayed Response" indicator, which may include a Correlation Token that is configured or transported at step 529. The MME 133 may, based on the stored "Delayed Response Allowed" data and the received "Delayed Response" indicator, decide whether to accept the connection request, e.g. checking if the timer associated with the "Delayed Response Allowed" is expired.
If the verification is successful, the MME grants the access and the MTC Device 101 would be able to transmit the traffic to the MTC Server 151 , in steps 555 to 559.
With reference to Figure 6, an embodiment of a device structure that can be used by a MTC Device 600 in accordance with the methods and systems discussed herein is illustrated. For example, the MTC Device 600 of Figure 6 may be employed as an MTC Device 101 to 107 of Figure 1 .
The MTC Device 600 includes a MTC Application 601 , which is configured to communicate at an application layer with the MTC Server 151 and providing MTC services. The application layer data traffic generated by this MTC Application 601 is passed to a Connection Manager layer or block 603 via interface 623. The Connection Manager is configured to control transmission methods. The data traffic received by the lower layer transport would be passed to the MTC Application 601 via the same interface 623.
The Connection Manager 603 is configured to decide based on some local policy or operator rules which access should be used for the transmission of the data traffic, in case there are multiple accesses available in the same MTC Device 600, e.g. 3GPP Radio Transport 609 and Non-3G Access 61 1 , or there are multiple bearers over the same access, e.g. multiple Packet Data Network (PDN) connections over the 3GPP Radio Transport 609.
The information used by the Connection Manager 603 to decide the routing of the traffic includes for example the user configurations, operator specified policies for IP interface selection (OPUS), inter-system routing policies (ISRP), or other Access Network Discovery and Selection Function (ANDSF) policies. These policies could be pre-configured on the MTC Device 600, or dynamically provisioned using ANDSF channel or Open Mobile Alliance (OMA) Device Management (DM) (OMA-DM) methods, or various combinations.
The Connection Manager 603 is also configured to use these policies and routing rules to identify the MTC Application 601 that generated the data traffic. This can be achieved by associating an Application Identifier with the interface 623, such that the Connection Manager 603 knows which application is generating the traffic, and whether a delayed response should be supported. This Application Identifier could be also mapped to a class of applications, e.g. certain type of MTC services, and the Connection Manager 603 could decide if delayed response support is desired for this type of applications. The interface 623 may also allow the MTC Application 601 to indicate to the Connection Manager 603 whether the delayed response support is desired.
A NAS Control 605 is interacting with the Connection Manager 603 via an interface 631 . The NAS Control 605 is responsible, for example, for the signaling message exchanges with the MME 133 in the operation as shown in Figures 2, 3, 4, and 5. When delayed response support is active on the MTC Device 600, the Connection Manager 603 passes the "Delayed Response" indicator to the NAS Control 605, such that it can be included into the signaling message to the MME 133. The NAS Control 605 passes the updated "Delayed Response" indicator from the MME 133 to the Connection Manager 603.
The Connection Manager 603 based on the "Delayed Response" manages the connection and decides if it should trigger the NAS Control 605 to perform connection request signaling to the MME 133 even if congestion control is active, e.g. a backoff timer is running.
The NAS Control 605 has its signaling message transported by the Radio Control 607 function. The Radio Control 607 is also configured to control the signaling exchange with the eNB 131 , for example in the operation embodiments as shown in Figures 2, 3, 4, and 5.
The Radio Control 607 has a control interface 633 with the Connection Manager 603. This interface 633 allows the Connection Manager 603 to pass the "Delayed Response" indicator to Radio Control 607 for including into RRC signaling. The interface 633 also allows the Radio Control 607 to pass the "Delayed Response Allowed" information element to the Connection Manager when supported.
When in use, the Connection Manager 603 after deciding that delayed response should be supported and that delayed response data from MTC Application 601 is pending to be sent, the Connection Manager 603 triggers the Radio Control 607 to establish a signaling control connection with an indication to reduce the likelihood that the connection will be blocked by congestion control, such as with a cause of "mobile terminating" or with a cause of "mobile originating" and a "Delayed Response" indicator.
After the connection was fully established, indicated by the Radio Control 607 when the data bearers are setup, the Connection Manager 603 would route the delayed response data towards the 3GPP Radio Transport 609 accordingly. As illustrated, the MTC Device 600 comprises one or more processors P, one or more memories M and one or more discrete devices 635, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer. The various functions of the MTC Device 600 may be implemented in various ways, such as by the processor P and the memory M (for example by executing instructions stored in the memory M), the discrete circuit 635, and various combinations thereof, etc.
With reference to Figure 7, an embodiment of a device structure that can be used by a eNB 700 in accordance with the methods and systems discussed herein is illustrated. For example, the eNB 700 of Figure 7 may be employed as an eNB 131 of Figure 1 .
The eNodeB (eNB) 700 includes a 3GPP Radio Transport 701 that is configured to receive from and transmit to the MTC Device 101 data and signaling traffic. When the MTC Device 101 is in CONNECTED mode, the data traffic received will be forwarded to the Backhaul Transport 707 directly that would forward the traffic to the corresponding SGW 135.
The signaling traffic, including that of the RRC layer and NAS layer, received from the MTC Device 101 is handled by the Radio Control 703. The Radio Control 703 is also configured to control and schedule the radio resources for the MTC Device 101 . The NAS layer signaling will be further forwarded by the Radio Control 703 to the Extended Access Control 705, which in turn forwards the NAS layer signaling to the MME 133 via the Backhaul Transport 707.
When in use, the Extended Access Control 705 receives the "Delayed Response" indicator or "Delayed Response Allowed" information element, and creates and stores the corresponding "Delayed Response Entry". The Extended Access Control 705 also is configured to manage and handle the timer to be associated with the "Delayed Response Entry".
When the Radio Control 703 receives a connection request for the delayed response, e.g. the RRC Connection Request with the "Delayed Response" indicator, it checks with the Extended Access Control 705 whether the request should be accepted. The Extended Access Control 705 is configured to decide whether the request should be accepted based on the presence and information of the "Delayed Response Entry". For example, if the timer for the "Delayed Response Entry" associated with the request has not expired, the connection should be accepted.
As illustrated, the eNB 700 comprises one or more processors P, one or more memories M and one or more discrete devices 735, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer. The various functions of the eNB
700 may be implemented in various ways, such as by the processor P and the memory M (for example by executing instructions stored in the memory M), the discrete circuit 735, and various combinations thereof, etc.
With reference to Figure 8, an embodiment of a device structure that can be used by a MME 800 in accordance with the methods and systems discussed herein is illustrated. For example, the MME 800 of Figure 8 may be employed as an MME 133 of Figure 1 .
The MME 800 includes a Congestion Control 801 module that is configured to handle access management for the MTC Device 101 . When the Congestion Control 801 receives a Downlink Data Notification from the SGW
135 via Core Network Control 807, it is configured to page the MTC Device 101 via the eNB 131 through Access Network Control 805.
When the MTC Device 101 sends a TAU Request with the
"Delayed Response" indicator, the UE NAS Control 803 passes the received "Delayed Response" indicator to the Congestion Control 801 . The Congestion
Control 801 may be configured to update the contents in the "Delayed
Response" indicator, and pass it back to the UE NAS Control 803 such that it can be included in the TAU Accept message. The Congestion Control 801 may be configured to generate the "Delayed Response Allowed" element based on knowledge of the service, network status, and the MTC Device 101 subscription information, etc.
The Congestion Control 801 may be configured to pass the "Delayed Response" indicator or the "Delayed Response Allowed" element to the Access Network Control 805, such that they could be included in the UE Context Release or UE Context Setup Request message respectively.
As illustrated, the MME 800 comprises one or more processors P, one or more memories M and one or more discrete devices 835, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer. The various functions of the MME 800 may be implemented in various ways, such as by the processor P and the memory M (for example by executing instructions stored in the memory M), the discrete circuit 835, and various combinations thereof, etc.
With reference to Figure 9, a logic flow 900 that can be used by a
MTC Device Connection Manager, such as Connection Manager 603 of MTC Device 600 of Figure 6, implementing an embodiment of the present disclosure is illustrated. This corresponds to an embodiment of the operation as illustrated in Figures 2 and 3. For convenience, the logic flow 900 is discussed with reference to the embodiment of an MTC Device 600 of Figure 6.
When the Connection Manager 603 receives the Paging trigger from the Radio Control 607, in step 901 , the Connection Manager overrides any congestion control timer that is currently running, and triggers the NAS Control 605 to signal toward the MME 133 with a Service Request or Extended Service Request, in step 903.
After the connection establishment, the MTC Application 601 receives the Downlink Data, and may indicate via the interface 623 that delayed response is likely necessary, in step 905. In this case, the Connection Manager 603 generates the corresponding "Delayed Response" indicator when necessary, and passes it to the NAS Control 605 to signal to the MME 133, which would trigger the release of the connections, in step 907. The MTC Device 600 would then fall into IDLE mode.
The Connection Manager 603 periodically or continuously checks if the MTC Application 601 has generated response data, as in step 909. When the data traffic is received from the MTC Application 601 , the Connection Manager 603 checks its local policy and other configurations to determine whether the traffic is to be forwarded over the 3GPP Radio Transport, in step 91 1 . If not, the traffic is passed to the Non-3G Access 61 1 for transport.
When the Connection Manager 603 decides that the traffic should be delivered over the 3GPP radio transport, the Connection Manager checks if the Delayed Response is still valid, e.g. if the timer associated with the MTC application's delayed response context has expired, in step 913. If the timer has expired, the Connection Manager 603 follows normal congestion control, e.g., to honor backoff timers in place before triggering any signaling to establish a connection, in step 923.
If the Connection Manager 603 finds that the delayed response context for the MTC application is still valid, the Connection Manager ignores the congestion control mechanism, and triggers the NAS Control 605 to signal to the MME to transit to CONNECTED mode, e.g., by sending a Service Request or Extended Service Request, or TAU Request with active flag, as in step 915. The Connection Manager 603 also sets the Radio Control 607 to override any congestion control, e.g., extended wait time at RRC layer, or extended access barring, etc, and perform signaling to request an RRC connection setup in step 917, for example by indicating a "mobile terminating" cause or a "mobile originating" cause with the "Delayed Response" indicator.
After the radio bearers are established, as indicated by the Radio Control 607, the Connection Manager 603 will forward the MTC application data to the 3GPP Radio Transport 609 in step 919, to be transmitted to the MTC Server 151 . With reference to Figure 10, an embodiment of a logic flow 1000 that can be used by a MTC Device Connection Manager, such as the
Connection Manager 603 of MTC Device 600 of Figure 6, to implementing an embodiment is illustrated. This corresponds to an embodiment of the operation as illustrated in Figure 4. For convenience, the logic flow 1000 is discussed with reference to the embodiment of an MTC Device 600 of Figure 6.
The steps 1001 to 1007 as illustrated are identical to those of step 901 to 907 of Figure 9. However, when the Connection Manager 603 detects that the connections for the MTC Device 600 have been released, the
Connection Manager instructs the Radio Control 607 into a Radio Link Failure state, and starts a timer set to the value of
"expectedTimerforDelayedResponse", in step 1009. In this Radio Link Failure State, the Radio Control 607 does not initiate a recovery procedure unless the recovery procedure is triggered by the Connection Manager 603, and the Radio Control 607 performs the procedure defined for the IDLE mode devices.
Once the Connection Manager 603 receives the data from the MTC Application 601 in step 101 1 , the Connection Manager 603 checks if the data is to be transported over the 3GPP radio transport, in step 1013. If the data not to be transported over the 3GPP radio transport, the data is
transported over Non-3G access in step 1023. If the data is to be transported over 3GPP, in step 1015, the Connection Manager 603 checks if the timer started in step 1009 has expired. If the timer has expired (indicating radio link failure state is invalid), the Connection Manager 603 in step 1025 instructs the Radio Control 607 to move to IDLE mode, and follow all the necessary congestion control procedures before attempting establishing a connection.
If the timer has not expired (indicating the radio link failure state is valid), the Connection Manager 603 will instruct in step 1017 the Radio Control 607 to start performing the radio link failure recovery procedure with signaling towards the eNB 131 . After the recovery of the signaling radio bearer, the Connection Manager 603 will instruct the NAS Control 605 to signal to the MME 133 to recover the data bearers, in step 1019. When the data bearers are established, the Connection Manager 603 in step 1021 forwards the MTC Application 601 data toward the 3GPP Radio Transport 609 to transmit to the MTC Server 151 .
In the previous description of example embodiments, it was assumed that the MTC application traffic was transported over the data plane of the 3GPP Domain 130. However, in deployment of MTC systems, there are other alternatives, such as where the MTC application traffic is delivered over the control plane of the 3GPP Domain 1 130.
With reference to Figure 1 1 , another embodiment of a system architecture 1 100 that supports Machine Type Communication is presented. In this system 1 100, the MTC Server 1 151 communicates with the 3GPP Domain via an MTC interworking function MTC IWF 1 135. The MTC IWF 1 135 is configured to translate and encapsulate the traffic from the MTC Server 1 151 into control plane messages and deliver the traffic to the MME 1 133 via interface 1 1 15. In one possible implementation, the traffic from MTC Server 1 151 are encapsulated into Short Message Service (SMS) messages. The MME 1 133 is configured to deliver the SMS messages as control plane signaling messages, e.g., NAS layer signaling messages, to the MTC Device, e.g., MTC Devices 1 101 to 1 107.
Similarly, the MTC application data from the MTC Device, e.g., MTC Devices 1 101 to 1 107, is also delivered via control plane signaling, e.g., as an SMS message, towards the MME 1 133, and is forwarded to the MTC IWF 1 135. The MTC IWF 1 135 is configured to decapsulate and translate SMS messages from the MTC Device to MTC application layer messages to be forwarded to the MTC Server 1 151 .
In this case, the transport of the MTC application data does not involve the 3GPP Domain 1 130 data plane entities, e.g., SGW or PGW. However, in order to deliver the control plane signaling message to the MTC Device 1 101 , the network still needs to bring the MTC Device 1 101 to CONNECTED mode. And, in order for the MTC Device 1 101 to transmit a control plane signaling message to the MME 1 133, the MTC Device also needs to transit to CONNECTED mode first. In this sense, the previous embodiments discussed above still apply to the alternative system architecture 1 100 shown in Figure 1 1 .
Therefore, embodiments of the operations as presented in
Figures 2, 3, 4, and 5 may still be used with some minor adaptation, e.g.
change the cause code of RRC Connection Request to "mo-Signalling", and there is no need to establish data bearers towards the SGW or PGW. The rest of the operation may be substantially the same.
In the above description, all the operations are presented based on the E-UTRAN system. However, the MTC application could be also supported in a UTRAN system. In such case, the same operations presented above could be applied, with minor adjustments. For example, in the UTRAN system, the eNB 131 may be replaced by a Radio Network Controller (RNC), the MME 133 and SGW 135 may be replaced by the Serving GPRS Support Node SGSN, and the PGW 137 may be replaced by the Gateway GPRS Support Node GGSN. Also, the signaling messages used may be replaced by corresponding UTRAN signaling messages, e.g., a TAU Request may be replaced by Routing Area Update (RAU) Request or Location Area update (LAU) request. The above discussed concepts of the disclosure still apply.
The following discussion describes an embodiment in the context of device trigger delivery services/mechanisms described in TR23.888, which may be roughly classified into two categories: IP-based communcation and MT SMS transfer. Section 6.52 of TR23.888 describes general optimizations for the SMS transmission carrying the device trigger or data. Section 6.52 of TR23.888 describes omit the establishment of the U-plane bearer(s) during the transmission of the device trigger from an MME to a UE (for example, an MTC Device). Depending on the trigger information the UE initates the
corresponding (IP or SMS) communication to the MTC Server (see section 6.52.2.7). More specifically, after receiving the Device Trigger message, if the UE determines that the uplink data responding to the Device Trigger message should be sent to the MTC Sever immediately, the UE establishes the U-plane bearer(s) immediately or reuses the existing NAS MM connection to transmit a Mobile Originating (MO) SMS to the MTC Server. Otherwise, if the UE determines that the uplink data will be transmitted later {e.g., an MO
communication will be established later), for example, a sensor may require a few minutes first to get some measurements and send the data to the MTC Server later; or a camera may be asked to send the videos after the facial detection located a certain person which may take a long time, the UE indicates to the MME that the NAS signalling connection is not needed (for example, indicating the connection may be released).
In the second case where UE determines to delay the response to a trigger message by indicating MME to release the connection, if the network later becomes congested when UE tries to initiate MO communication to transmit the delayed response data, the network will reject the MO access request. Applying MTC congestion control, the MME can reject the access request from MTC Device with a back-off timer except for Service Users, emergency services and mobile terminated services. Furthermore, to prevent MTC Devices sending access requests during congestion, an eNB can reject the RRC connection request at the RAN layer with an extended wait time or broadcast extended access barring. However, as mentioned above, TR23.888 specifies a scenario that a UE can determine to transmit the responding uplink data later (i.e. MO communication will be established later) with effect of releasing NAS signalling connection. This means later UE may initiate MO communication because it tries to respond to a previous trigger message. Such MO communication access request should not be rejected even during congestion, but there is no mechanism to identify and allow the request. Even if the connection is not intentially released by UE after receiving the trigger, it may be released due to other reasons such as an UE inactive time {e.g., a threshold period of inactivity), radio link failure, radio access network events, etc. Later when the UE tries to transmit delayed response data for the trigger but the network is already congested, the UE will face the same situation of being rejected.
In an embodiment, section 6.52.2.7 may be supplemented to support MO communication establishment for delayed uplink data transmission in case of congestion. In an embodiment, when the UE determines to send the uplink response data later, it indicates to the MME to release the NAS signalling connection and also to store a delay-response indicator as a link between the previous Device Trigger message and the delayed response. In some embodiments, the MME may also inform the eNB of this delay-response indicator when it releases the NAS signaling connection. With this preparation, when uplink data is ready, the UE can establishes the MO communication with the same delay-response indicator to avoid being rejected by an MME/eNB even if the network is congested.
For example, Section 6.52.2.7 of TS 23.888 may be modified to include text similar to the following:
For the transmission of the Device Trigger contained in the MT
SMS the establishment of U-plane bearers is not necessarily
needed. Depending on the triggered MTC application, the UE
used for MTC may either not require the establishment of U-plane bearers, or not require the immediate establishment of U-plane bearers.
NOTE 1 : In the following exemplary cases the establishment of the U-plane bearers is not needed: 1 ) the UE used for MTC
may reply to the MTC server using MO SMS; 2) the UE used for
MTC may first need some time to gather information and then the IP-based communication to the MTC server may be initiated (e.g. 1 minute later).
The eNB/MME may not immediately initiate the NAS/RRC connection release after the delivery of the Device Trigger (e.g. MT SMS) to the UE. During the Device Trigger processing in the
UE, the UE determines if uplink data may be immediately sent to the MTC server. Further, the uplink data may result in either 1 ) establishment/activation of EPS bearers for IP/based MO communication or 2) the transmission of MO SMS to the MTC Server. If the UE decides to transmit an MO SMS, the UE reuses the existing NAS MM connection to the MME. If the UE needs to set up the U-plane bearers, the UE sends a corresponding EPS Bearer Activation message to the MME.
If the UE determines that the uplink data may be transmitted later (i.e. MO communication will be established later), the UE indicates to the MME that the NAS signaling connection may be released. The latter helps the network to shorten the radio resource occupation.
The MME may establish the Access Stratum (AS) security for the Signaling Radio Bearers. For this reason, the MME may establish only the UE AS-security context at the eNB for the RRC connection {e.g., the MME doesn't include the E-RAB context in the S1 -AP Initial Context Setup request message to the eNB). Reasons for the establishment of the AS-security are 1 ) the support of mobility and 2) the ability of the UE to reliably activate the U-plane bearers if needed.
NOTE 2: Some further alternative signaling and/or indications during the Paging and Service Request procedure are possible compared to the MT SMS solution from sub clause 6.52.2.6. If the UE has no data to send via the U-plane when responding to the Paging message with "SMS flag", then the UE can send a new or an existing initial NAS message, e.g., a TAU request without an active flag, to the MME. This message triggers the establishment of the NAS signaling connection. After the reception of the Device Trigger, in the reply from the UE to the MME (e.g. SMS Relay
protocol PDUs, RPDUs), the UE indicates further actions to the
MME such as keeping the NAS signaling connection or releasing the NAS signaling connection and storing an indicator for delayed response. In some cases, the MME may also inform eNB of the delayed response indicator when releasing the NAS signaling
connection. This helps the network to shorten the radio resource occupation and facilitates establishing an uplink data transmission in case that network becomes congested when UE initiates MO communication for delayed response with the same delayed
response indicator.
Some embodiments may take the form of computer program products. For example, according to one embodiment there is provided a computer readable medium comprising a computer program adapted to perform one or more of the methods described above. The medium may be a physical storage medium such as for example a Read Only Memory (ROM) chip, or a disk such as a Digital Versatile Disk (DVD-ROM), Compact Disk (CD-ROM), a hard disk, a memory, a network, or a portable media article to be read by an appropriate drive or via an appropriate connection, including as encoded in one or more barcodes or other related codes stored on one or more such computer- readable mediums and being readable by an appropriate reader device.
Furthermore, in some embodiments, some or all of the systems and/or modules may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits (ASICs), discrete circuitry, standard integrated circuits, controllers (e.g., by executing appropriate instructions, state machines, and including microcontrollers and/or embedded controllers), field- programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc., as well as devices that employ RFID technology. In some embodiments, some of the modules or controllers separately described herein may be combined, split into further modules and/or split and recombined in various manners. The various embodiments described above can be combined to provide further embodiments. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, application and publications to provide yet further embodiments.
These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific
embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.
Each functional block used in the description of the embodiments as given above can be realized as LSI, typically represented by an integrated circuit. These may be produced as one chip individually or may be designed as one chip to include a part or all. Here, it is referred as LSI, while it may be called IC, system LSI, super LSI, or ultra LSI, depending on the degree of integration. Also, the technique of integrated circuit is not limited only to LSI and it may be realized as a dedicated circuit or a general-purpose processor. FPGA (Field Programmable Gate Array), which can be programmed after the manufacture of LSI, or a reconfigurable processor, in which connection or setting of circuit cell inside LSI can be reconfigured, may be used. Further, with the progress of semiconductor technique or other techniques derived from it, when the technique of circuit integration to replace LSI may emerge, the functional blocks may be integrated by using such technique. For example, the adaptation of bio-technology is one of such possibilities.

Claims

[CLAIMS]
1 . A system, comprising:
means for generating responses to application layer requests;
means for generating application layer requests; and
means for communicatively coupling the means for generating responses to application layer requests to the means for generating application layer requests and for selectively rejecting connection requests from the means for generating responses to application layer requests;
means for determining whether a response to an application layer request will be a delayed response; and
means for generating, when it is determined the response to the application layer request will be a delayed response, a request to the means for communicatively coupling to accept a subsequent connection request associated with a delayed response to the application layer request.
2. The system of claim 1 wherein the request to accept the subsequent connection request associated with the delayed response comprises an indication to release an existing connection with means for generating responses to application layer requests.
3. The system of claim 1 , comprising a mobile terminal including: the means for generating responses to application layer requests; the means for determining whether a response to an application layer request will be a delayed response; and
the means for generating the request to accept the subsequent connection request.
4. The system of claim 3 wherein the mobile terminal is configured to determine parameters included in the request to accept the subsequent connection request and the means for communicatively coupling is configured to selectively override a congestion control policy based on the determined parameters included in the request to accept the subsequent connection request.
5. The system of claim 4 wherein the parameters include a time period and the means for communicatively coupling is configured to accept the subsequent connection request from the mobile terminal when the subsequent connection request is received within the time period.
6. The system of claim 4 wherein the mobile terminal comprises a connection manager configured to determine whether a generated response is to an application layer request received from the means for generating application layer requests.
7. The system of claim 4 wherein the means for communicatively coupling comprises:
a network controller; and
an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is configured to instruct the access network controller to accept a connection request based on the determined parameters included in the request to accept the subsequent connection request.
8. The system of claim 1 wherein the means for communicatively coupling is configured to determine, based on information derived from the received application layer request and in response to the request to accept the subsequent connection request, a set of parameters, and to selectively override a congestion control policy based on the determined parameters.
9. A mobile terminal, comprising:
one or more configured devices configured to implement:
an application response block configured to generate responses to application layer requests; and
a connection manager block configured to:
determine whether a response to an application layer request will be a delayed response; and
when it is determined that the response to the application layer request will be a delayed response, generate a request to a communication network to accept a subsequent connection request associated with a delayed response to the application layer request.
10. The mobile terminal of claim 9 wherein the request to accept the subsequent connection request associated with the delayed response comprises an indication to release an existing connection with the mobile terminal.
1 1 . The mobile terminal of claim 10 wherein the request to accept the subsequent connection request associated with the delayed responses comprises an indication to store an indicator of the delayed response.
12. The mobile terminal of claim 9 wherein the connection manager block is configured to determine parameters of the request to accept the subsequent connection request to cause the communication network to selectively override a congestion control policy.
13. The mobile terminal of claim 12 wherein the parameters include an indication of when the subsequent connection request should be treated as a valid request.
14. The mobile terminal of claim 9 wherein the connection manager block is configured to determine whether a generated response is to the application layer request.
15. The mobile terminal of claim 14 wherein when it is determined the generated response is to the application layer request, the connection manager block is configured to determine whether a congestion control policy should be overridden.
16. The mobile terminal of claim 15 wherein when it is determined the congestion control policy should be overridden, the mobile terminal is configured to transmit the subsequent connection request.
17. The mobile terminal of claim 16 wherein the subsequent connection request is a mobile terminating request.
18. The mobile terminal of claim 16 wherein the subsequent connection request is a mobile originating request including a delayed response indicator.
19. The mobile terminal of claim 14 wherein when it is determined the generated response is to the application layer request, the mobile terminal is configured to initiate a radio link recovery as the subsequent connection request.
20. A communication network, comprising:
one or more memories; and
one or more configured processing devices configured to implement a communication control block, wherein the communication control block is configured to:
selectively block connection requests from mobile terminals; and respond to a request from a mobile terminal to accept a subsequent connection request associated with a delayed response to an application layer request by selectively storing an indication of an expected delayed response from the mobile terminal to the application layer request.
21 . The communication network of claim 20 wherein the communication control block is configured to determine whether the mobile terminal is authorized to submit the request to accept a subsequent connection request associated with the delayed response to the application layer request.
22. The communication network of claim 20 wherein an existing connection with the mobile terminal is released in response to the request to accept the subsequent connection request.
23. The communication network of claim 20 wherein the network comprises:
a network controller; and
an access network controller configured to selectively reject connection requests of the mobile terminal, wherein the network controller is configured to instruct the access network controller to accept a connection request based on parameters included in the request to accept the subsequent connection request.
24. The communication network of claim 20 wherein the communication control block is configured to determine, based on information derived from a received application layer request and in response to the request to accept the subsequent connection request, a set of parameters and to selectively override a congestion control policy based on the determined parameters.
25. The communication network of claim 24 wherein the parameters include an indication of when the subsequent connection request should be treated as a valid request.
26. The communication network of claim 20 wherein the communication control block is configured to respond to a subsequent connection request from the mobile terminal by determining whether the subsequent connection request is associated with a delayed response to the application layer request based on the stored indication of an expected delayed response from the mobile terminal to the application layer request and to selectively accept the subsequent connection request based on the determination of whether the subsequent connection request is associated with a delayed response to the application layer request.
27. The communication network of claim 26 wherein the communication control block is configured to selectively accept the subsequent connection request based on when the subsequent connection request is received.
28. The communication network of claim 20 wherein the one or more configured processing devices comprise a mobile management controller and a base station.
29. A method, comprising:
determining whether a response to a received application layer request will be a delayed response; and
when it is determined that the response to the received application layer request will be a delayed response, generating a request to a communication network to accept a subsequent connection request associated with a delayed response to the application layer request, wherein the determining and generating are performed by a configured mobile terminal.
30. The method of claim 29, further comprising:
receiving a page associated with the application layer request; and, in response to the page:
overriding a congestion control policy; and
transiting the configured mobile terminal to a connect mode.
31 . The method of claim 29 wherein the generated request includes an indication to release an existing connection with the mobile terminal.
32. The method of claim 29, further comprising:
determining whether a delayed response to the application layer request has been generated; and
when it is determined that a delayed response to the application layer request has been generated,
determining whether to override congestion control; and when it is determined to override congestion control, generating the subsequent connection request.
33. The method of claim 29, further comprising:
determining whether a delayed response to the application layer request has been generated; and
when it is determined that a delayed response to the application layer request has been generated,
determining whether a timer has expired; and when it is determined the timer has not expired, generating the subsequent connection request.
34. A method, comprising:
receiving a request from a mobile terminal to accept a subsequent connection request from the mobile terminal associated with a delayed response to an application layer request;
selectively storing an indication of an expected delayed response from the mobile terminal to the application layer request; and
responding to a subsequent connection request received from the mobile terminal by:
determining whether the subsequent connection request is associated with the delayed response to the application layer request based on the stored indication; and
when it is determined the subsequent connection request is associated with the delayed response to the application layer request, selectively establishing a connection with the mobile terminal, the storing and responding being performed by one or more configured processing devices of a communication network.
35. The method of claim 34 wherein the selectively storing the indication comprises determining whether the mobile terminal is authorized to provide a delayed response to the application layer request.
36. The method of claim 34 wherein the selectively establishing a connection comprises determining whether a timer has expired and establishing a connection when it is determined the timer has not expired.
37. The method of claim 34 wherein the selectively establishing a connection comprises overriding a congestion control policy.
PCT/US2011/059401 2011-11-04 2011-11-04 Apparatus and method for delayed response handling in mobile communication congestion control WO2013066350A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2011/059401 WO2013066350A1 (en) 2011-11-04 2011-11-04 Apparatus and method for delayed response handling in mobile communication congestion control

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2011/059401 WO2013066350A1 (en) 2011-11-04 2011-11-04 Apparatus and method for delayed response handling in mobile communication congestion control

Publications (1)

Publication Number Publication Date
WO2013066350A1 true WO2013066350A1 (en) 2013-05-10

Family

ID=48192534

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2011/059401 WO2013066350A1 (en) 2011-11-04 2011-11-04 Apparatus and method for delayed response handling in mobile communication congestion control

Country Status (1)

Country Link
WO (1) WO2013066350A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104823469A (en) * 2013-09-23 2015-08-05 华为技术有限公司 Data transmission method and entity
WO2015195014A1 (en) * 2014-06-19 2015-12-23 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for handling radio resources
EP3018963A1 (en) * 2014-11-07 2016-05-11 Ericsson-LG Co., Ltd. Method and apparatus for controlling of ddn message, and computer readable medium for the same
EP3021617A1 (en) * 2014-11-14 2016-05-18 Gemalto M2M GmbH Method for operating a wireless communication device in a cellular network
EP3172935A4 (en) * 2014-07-22 2018-03-14 Intel IP Corporation Systems, apparatuses, and methods for lightweight over-the-air signaling mechanisms in data communications
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
CN108924841A (en) * 2017-03-20 2018-11-30 中国移动通信有限公司研究院 Method for security protection, device, mobile terminal, base station and MME equipment
US20220174584A1 (en) * 2014-01-31 2022-06-02 Fujitsu Limited Access Method of Wireless Communication Network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090150536A1 (en) * 2007-12-05 2009-06-11 Microsoft Corporation Application layer congestion control
US20090222573A1 (en) * 2008-03-03 2009-09-03 Alcatel-Lucent System and method for application layer resource traffic control
US20090228594A1 (en) * 2008-03-10 2009-09-10 Microsoft Corporation Policies for Session Types

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090150536A1 (en) * 2007-12-05 2009-06-11 Microsoft Corporation Application layer congestion control
US20090222573A1 (en) * 2008-03-03 2009-09-03 Alcatel-Lucent System and method for application layer resource traffic control
US20090228594A1 (en) * 2008-03-10 2009-09-10 Microsoft Corporation Policies for Session Types

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10153971B2 (en) 2013-09-23 2018-12-11 Huawei Technologies Co., Ltd Data transmission method and entity
CN104823469A (en) * 2013-09-23 2015-08-05 华为技术有限公司 Data transmission method and entity
US20220174584A1 (en) * 2014-01-31 2022-06-02 Fujitsu Limited Access Method of Wireless Communication Network
US9629173B2 (en) 2014-06-19 2017-04-18 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for handling radio resources
WO2015195014A1 (en) * 2014-06-19 2015-12-23 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for handling radio resources
EP3172935A4 (en) * 2014-07-22 2018-03-14 Intel IP Corporation Systems, apparatuses, and methods for lightweight over-the-air signaling mechanisms in data communications
US10285076B2 (en) 2014-11-07 2019-05-07 Ericsson-Lg Co., Ltd. Method and apparatus for controlling of DDN message, and computer readable medium for the same
EP3018963A1 (en) * 2014-11-07 2016-05-11 Ericsson-LG Co., Ltd. Method and apparatus for controlling of ddn message, and computer readable medium for the same
WO2016075006A1 (en) * 2014-11-14 2016-05-19 Gemalto M2M Gmbh Method for operating a wireless communication device in a cellular network
EP3021617A1 (en) * 2014-11-14 2016-05-18 Gemalto M2M GmbH Method for operating a wireless communication device in a cellular network
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
CN108924841A (en) * 2017-03-20 2018-11-30 中国移动通信有限公司研究院 Method for security protection, device, mobile terminal, base station and MME equipment
CN108924841B (en) * 2017-03-20 2021-11-19 中国移动通信有限公司研究院 Security protection method and device, mobile terminal, base station and MME (mobility management entity) equipment

Similar Documents

Publication Publication Date Title
US11375471B2 (en) Method for performing service request procedure and apparatus therefor in wireless communication system
CN110447250B (en) Method for interaction between layers in wireless communication system and apparatus therefor
US10582522B2 (en) Data transmission and reception method and device of terminal in wireless communication system
US10856265B2 (en) Method for selecting resource operation preferred by user in wireless communication system and device for same
US10362511B2 (en) Method and apparatus for determining PDU session identity in wireless communication system
US11765631B2 (en) Extended buffering determination by a session management function
US20190021064A1 (en) Method for managing registration in wireless communication system and device for same
EP2768251B1 (en) Data transmission method, mobility management entity and mobile terminal
US20200178048A1 (en) V2x communication support method in wireless communication system
WO2013066350A1 (en) Apparatus and method for delayed response handling in mobile communication congestion control
US10681637B2 (en) Method and apparatus for transmitting and receiving data, by terminal, in wireless communication system
JP7423744B2 (en) User data transmission over the control plane in communication systems using designated payload container types
US10568018B1 (en) Methods and systems for preventing message overloading in wireless networks
EP3726890A1 (en) Method for controlling access to network in wireless communication system and apparatus therefor
WO2012051752A1 (en) Serving gateway for handling communications of mobile terminal
US20220210670A1 (en) Ue and control apparatus in core network
US20240114586A1 (en) Handling communication errors during early data communication
RU2788399C1 (en) Transmission of user data through the control plane in the communication system using designated types of payload containers
WO2023211982A1 (en) Managing positioning measurement for an inactive state

Legal Events

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

Ref document number: 11875236

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11875236

Country of ref document: EP

Kind code of ref document: A1