WO2013151530A2

WO2013151530A2 - Apparatus and method for inter domain congestion control in mobile communication networks

Info

Publication number: WO2013151530A2
Application number: PCT/US2012/031897
Authority: WO
Inventors: Li Wei; Hong Cheng; YuXuan ZHOU; Terufumi Takada
Original assignee: Panasonic Corporation
Priority date: 2012-04-02
Filing date: 2012-04-02
Publication date: 2013-10-10
Also published as: WO2013151530A3

Abstract

A system for device trigger delivery in a mobile communication network includes a mobile terminal that is capable of responding to an application layer device trigger, an application layer server that is capable of requesting a new connection establishment from the mobile terminal via device trigger, and a network control entity that is capable of delivering the device trigger through two independent domains and deploying congestion control in these two domain independently. When the mobile terminal decides a new domain connection establishment in response to an application layer device trigger from the application layer server is needed, the mobile terminal triggers an inter domain negotiation to facilitate a connection request to transmit the response to the application layer device trigger.

Description

APPARATUS AND METHOD FOR INTER DOMAIN CONGESTION CONTROL IN MOBILE COMMUNICATION NETWORKS

BACKGROUND

Technical Field

This disclosure relates to mobile communication networks. More specifically, it relates to the inter domain management for the 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 may exceed what the network resources permits. Among these newly added devices, many are used for machine type

communications (MTC), which have requirements quite different from that of the human to human communications, e.g. voice applications. For example, with the trend of increasing use of the Internet, smart meters, sensors, or home appliances may be connected to mobile communication networks to provide necessary information to servers or applications. These kinds of

communications are normally data oriented and generally are less time critical in transmission.

In view of the situation, mobile networks try to optimize their 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 congestion control that employs different access rejections and back-off timers at different access layers, which guards the network from the simultaneous access from the enormous amount of new devices. See, for example, System improvements for Machine-Type

Communications (MTC), 3GPP TR 23.888 v1 .6.0 Release 1 1 , 201 1 -12-14. In congestion control mode, a network can decide to reject a device's access request based on the subscription, service type, equipment capability indications, etc. Together with the rejections, the network may also employ a back-off timer that may prevent the devices from attempting an access request again in a short time period.

Another feature of machine type communications is there are many cases where a session is initiated by an MTC Server in a network.

Therefore, when the MTC Server does not have a direct communication channel with the MTC Device(s), the MTC Server may use a device triggering mechanism to deliver a trigger message via the 3GPP network to the MTC Device(s) to initiate the communication. Currently, in the 3GPP standards, the MTC device triggering mechanism supports both PS (packet switched) domain network and CS (circuit switched) domain network delivery. See System improvements for Machine-Type Communications (MTC), 3GPP TR 23.888 v1 .6.0 Release 1 1 , 201 1 -12-14. Once the MTC Device(s) receives the trigger message, it may establish a connection with the MTC Server for the MTC application layer exchanges.

BRIEF SUMMARY

As described above, the current 3GPP network supports the MTC device trigger delivery through both the 3GPP CS domain and the 3GPP PS domain.

If an MTC Device is attached to both a 3GPP CS domain and a 3GPP PS domain, the 3GPP network could route the device trigger message from MTC Server to the MTC Device via whatever domain the MTC Device is camping on. Therefore, for example, there may be cases that a MTC Device(s) could receive a device trigger message from MTC Server via CS domain and the trigger causes the MTC Device(s) to establish a communication channel in PS domain with the MTC Server.

However, due to the independent congestion control of CS domain and PS domain, the MTC Device(s) may not be able to establish the communication channel in PS domain successfully, e.g. when congestion control is activated in PS domain but not in CS domain.

Therefore, after receiving the device trigger message from MTC Server via CS domain, the MTC Device may be triggered to switch to PS domain and establish a connection in PS domain. In case the PS domain is in congestion control, the PS domain may reject the connection request from the MTC Device. This may result in delay in service operation and waste of energy in performing the signaling.

On the other hand, the MTC Server may be unaware of the failure of connection establishment in PS domain because the delivery report for device trigger sent over the CS domain indicates success. Therefore, seeing no response from the MTC Device after a timeout, the MTC Server may repeat the device trigger to the MTC Device. This may cause an unnecessary waste of network resources, e.g. paging the MTC Device, and may trigger additional operation on the MTC Device(s), e.g. switching domain again.

In an embodiment, techniques may be employed to address the above discussed problems. In an embodiment, a method and system facilitate more intelligent management of congestion control between CS domains and PS domains, such that a connection establishment in a PS domain requested by the device trigger via a CS domain may be supported.

To facilitate congestion control, various embodiments may provide systems, methods, and apparatuss that facilitate a mobile terminal determining that a connection establishment in a PS domain is desired in response to a device trigger received from MTC Server via a CS domain by triggering inter domain negotiation before switching domains, such that PS domain may link the access request with the device trigger via the CS domain and support the connection establishment.

In machine to machine (M2M) communications, there are many cases where the session is initiated by an M2M Server in a network. Therefore, when the MTC Server does not have a direct communication channel with the M2M Device(s), the M2M Server may use a device triggering mechanism to deliver a trigger message via the 3GPP network to the M2M Device(s) to initiate the communication.

Currently, the M2M device triggering mechanism supports both PS (packet switched) domain network and CS (circuit switched) domain network delivery. For example, a M2M Device(s) could receive a device trigger message from M2M Server via CS domain and the trigger may cause the M2M Device(s) to establish a communication channel in PS domain with the M2M Server. However, due to the independent control of CS domain and PS domain, the M2M Device(s) may not be able to establish the communication channel in PS domain successfully, e.g. when the congestion control is activated in PS domain. This may cause wastage in the M2M Device(s) operation and battery resources, and also may cause further stress on the network's PS Domain signaling control function that is already congested.

Embodiments of the present disclosure may provide a solution to the above problem, by introducing some intelligence in the M2M Device(s) that can initiate some negotiation and verification between the domains at the network side via the domain which receives the trigger, before establishing the communication channel in a different domain. An embodiment also includes methods to inform the M2M Device(s) and the M2M Server of the result of the negotiation, which enables more intelligent handling of the signaling, e.g.

avoiding connection attempts at the M2M Device(s) and re-transmission of the device trigger messages from the M2M Server. The discussed techniques may be applied independent of which domain is used for device trigger delivery. According to an embodiment, both the M2M Device(s) and network can benefit from reduced signaling and resources waste.

In an embodiment, a system comprises: means for receiving an application layer trigger request from an application server to a mobile terminal sent over a first communication domain; means for analyzing the application layer trigger request to determine whether the trigger request includes an indication to the mobile terminal to send a connection request to a second communication domain; means for initiating inter-domain communication between the first communication domain and the second communication domain when the trigger request includes the indication to the mobile terminal to send a connection request to the second communication domain; means for determining a congestion control status of the second communication domain; and means for indicating to the application server that a congestion control policy of the second communication domain will block the connection request when the congestion control status indicates the congestion control policy will block the connection request. In an embodiment, the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain. In an embodiment, the system comprises a mobile terminal. In an embodiment, when the means for determining a congestion control status determines a congestion control policy is in place, the mobile terminal is configured to determine whether to request overriding of the congestion control policy. In an embodiment, the congestion control status indicates a backoff timer is running. In an embodiment, the means for determining a congestion control status is configured to analyze a broadcast from the second communication domain. In an embodiment, when the mobile terminal determines to request overriding of the congestion control policy, the means for initiating inter-domain communication is configured to send a request from the mobile terminal to override the congestion control policy to the second communication domain through the first communication domain. In an embodiment, the means for initiating inter-domain

communication is configured to send a request from the mobile terminal to override the congestion control policy to the second communication domain through the first communication domain based at least in part on whether the means for determining a congestion control status determines a congestion control policy is in place. In an embodiment, the request from the mobile terminal to override the congestion control policy is sent via a control signal of the first communication domain. In an embodiment, the request from the mobile terminal to override the congestion control policy is included in a short- message service (SMS) delivery report to the first communication domain. In an embodiment, when a response to the request to override is received by the mobile terminal, the mobile terminal is configured to generate a delivery report to the application server based on the response to the request to override. In an embodiment, when a response to the request to override is received by the first communication domain, the first communication domain is configured to send a delivery report to the application server based on the response to the request to override. In an embodiment, the first communication domain is configured to send a negotiation request to the second communication domain in response to the request to override congestion control. In an embodiment, the request to override includes information related to the congestion control policy to be overridden. In an embodiment, the information related to the congestion control policy includes an identity of a Mobility Management Entity of the second communication domain. In an embodiment, the request to override includes an indication of whether the mobile terminal will wait for a response to the request to override before sending the connection request to the second communication domain. In an embodiment, the information related to the congestion control policy includes a value of a backoff timer. In an embodiment, the mobile terminal is configured to, based at least in part on whether the means for determining congestion control status determines a congestion control policy is in place, send a negotiation notification to the first communication domain and the connection request to the second

communication domain. In an embodiment, the system includes at least part of the first communication domain and at least part of the second communication domain, the at least part of first communication domain is configured to store information based on a negotiation notification received from the mobile terminal and the at least part of the second communication domain is configured to respond to a connection request from the mobile terminal by checking the stored information. In an embodiment, the means for indicating to the application server that a congestion control policy of the second

communication domain will block the connection request is configured to: when the congestion control status indicates the congestion control policy will block the connection request, provide the indication to the application server; and when the congestion control status does not indicate the congestion control policy will block the connection request, forward the trigger request to the mobile terminal. In an embodiment, the indication to the application server includes an indication of a value of a congestion control timer.

In an embodiment, a method comprises: analyzing, by one or more configured devices, an application layer trigger request from an application server addressed to a mobile terminal through a first communication domain; initiating, by the one or more configured devices, inter-domain communication between the first communication domain and a second communication domain when the analysis indicates the trigger request includes an indication to the mobile terminal to send a connection request to the second communication domain; determining, by the one or more configured devices, a congestion control status of the second communication domain; and

generating, by the one or more configured devices, an indication to the application server that a congestion control policy of the second communication domain will block the connection request when the determined congestion control status indicates the congestion control policy will block the connection request. In an embodiment, the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain. In an embodiment, the method further comprises: determining whether to request overriding of the congestion control policy. In an embodiment, the determining the congestion control status includes determining whether a backoff timer related to the mobile terminal is running. In an embodiment, the determining a congestion control status includes analyzing a broadcast from the second communication domain. In an embodiment, the method further comprises: sending a request from the mobile terminal to override the congestion control policy of the second communication domain through the first communication domain. In an embodiment, the request from the mobile terminal to override the congestion control policy is sent via a control signal of the first communication domain. In an embodiment, the request from the mobile terminal to override the congestion control policy is included in a short-message service (SMS) delivery report to the first communication domain. In an embodiment, the method further comprises: generating a delivery report to the application server based on a response to the request to override. In an embodiment, the method further comprises: sending a negotiation request from the first communication domain to the second communication domain in response to the request to override congestion control. In an embodiment, the request to override includes information related to the congestion control policy to be overridden. In an embodiment, the information related to the congestion control policy includes an identity of a Mobility Management Entity of the second communication domain. In an embodiment, the request to override includes an indication of whether the mobile terminal will wait for a response to the request to override before sending the connection request to the second communication domain. In an embodiment, the information related to the congestion control policy includes a value of a backoff timer. In an embodiment, the method further comprises: sending a negotiation notification from the mobile terminal to the first communication domain; and sending the connection request from the mobile terminal to the second communication domain. In an embodiment, the method further comprises: storing information in the first communication domain based on the negotiation notification; and responding to the connection request from the mobile terminal by checking the stored information. In an

embodiment, the method further comprises: when the congestion control status does not indicate the congestion control policy will block the connection request, forwarding the trigger request to the mobile terminal. In an

embodiment, the indication to the application server includes an indication of a value of a congestion control timer. In an embodiment, a non-transitory computer-readable medium's contents configure one or more processing devices to perform a method as described herein.

In an embodiment, a mobile terminal comprises: one or more processors; and one or more modules that are configured to, when executed by at least one of the one or more processors, respond to a device trigger message received in a first communication domain by: determining whether the trigger message includes an indication to establish a communication session in a second communication domain; and when it is determined the trigger message includes an indication to establish a communication session in the second communication domain, determining whether to request an override of congestion control of the second communication domain. In an embodiment, the determining whether to request an override of the congestion control includes determining whether a congestion control policy is activated. In an embodiment, the determining whether a congestion control policy is activated comprises determining whether a backoff timer is running. In an embodiment, the determining whether a congestion control policy is activated comprises analyzing a broadcast of the second communication domain. In an

embodiment, the determining whether to request an override of the congestion control is based on at least one of: whether a congestion control policy is activated; information in the device trigger message; a configuration of the mobile terminal; subscription data; and an indication of whether an activated congestion control policy is allowed to be overridden. In an embodiment, the responding to the device trigger message includes, when it is determined to request the override of congestion control, requesting the override through the first communication domain. In an embodiment, the override is requested through a control signal in the first communication domain. In an embodiment, the responding to the device trigger message includes, when it is determined to request the override of congestion control, responding to an answer to the request to override by generating a delivery report to an application server associated with the device trigger message. In an embodiment, the override is requested in a short-messaging service (SMS) delivery report. In an

embodiment, the mobile terminal is configured to respond to an answer to the request to override by generating an SMS delivery report to an application server associated with the device trigger message. In an embodiment, the SMS delivery report includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a

communication session in the second communication domain; and a value of a backoff timer. In an embodiment, the responding to the device trigger message includes, when it is determined to request the override of congestion control: providing a override request notification to the first communication domain; and requesting the override of congestion control from the second communication domain. In an embodiment, the override request notification includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a communication session in the second communication domain; and a value of a backoff timer. In an embodiment, the override request notification includes an identity of a Mobility Management Entity of the second communication domain. In an embodiment, the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain.

In an embodiment, a method comprises: determining, by one or more configured processing devices, whether a trigger message addressed in a first communication domain to a mobile terminal includes an indication to the mobile terminal to establish a communication session in a second

communication domain; and when it is determined the trigger message includes an indication to establish a communication session in the second

communication domain, determining, by the one or more configured processing devices, whether to request an override of congestion control of the second communication domain. In an embodiment, the determining whether to request an override of the congestion control includes determining whether a

congestion control policy is activated. In an embodiment, the determining whether a congestion control policy is activated comprises determining whether a backoff timer is running. In an embodiment, the determining whether a congestion control policy is activated comprises analyzing a broadcast of the second communication domain. In an embodiment, the determining whether to request an override of the congestion control is based on at least one of:

whether a congestion control policy is activated; information in the device trigger message; a configuration of the mobile terminal; subscription data; and an indication of whether an activated congestion control policy is allowed to be overridden. In an embodiment, the method further comprises: requesting an override of congestion control. In an embodiment, the override is requested through a control signal in the first communication domain. In an embodiment, the method further comprises: responding to an answer to the request to override by generating a delivery report to an application server associated with the device trigger message. In an embodiment, the override is requested in a short-messaging service (SMS) delivery report. In an embodiment, the method further comprises: responding to an answer to the request to override by generating an SMS delivery report to an application server associated with the device trigger message. In an embodiment, the SMS delivery report includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a communication session in the second communication domain; and a value of a backoff timer. In an embodiment, the method of claim 56 further comprises: providing a override request notification to the first communication domain; and requesting an override of congestion control from the second communication domain. In an embodiment, the override request notification includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a

communication session in the second communication domain; and a value of a backoff timer. In an embodiment, the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain. In an embodiment, a non-transitory computer-readable medium's contents configure one or more processing devices to perform one or more of the methods as described herein. In an embodiment, a mobile terminal comprises: means for determining whether a trigger message addressed in a first communication domain to a mobile terminal includes an indication to the mobile terminal to establish a communication session in a second communication domain; and means for determining, when it is determined the trigger message includes an indication to establish a communication session in the second communication domain, whether to request an override of congestion control of the second communication domain. In an embodiment, the mobile terminal further comprises: means for requesting the override of congestion control.

In an embodiment, a system comprises: one or more processors; and one or more modules configured to, when executed by at least one of the one or more processors, manage a first communication domain by: selectively activating congestion control; and responding to a request, from a mobile terminal device subject to an activated congestion control policy, to establish a communication session in the first communication domain by: determining whether there is a valid device trigger associated with a second communication domain and with the request from the mobile terminal device; and when it is determined there is a valid device trigger associated with the second

communication domain and with the request from the mobile terminal device, selectively overriding the activated congestion control policy. In an

embodiment, the managing the first communication domain includes:

responding to a communication related to a device trigger associated with the second communication domain by: determining whether overriding of the activated congestion control policy may be permitted; and providing an indication of whether overriding of the activated congestion control policy may be permitted. In an embodiment, the communication is received from at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device; and a Machine-Type-Communication Internetworking Device (MTC IWF). In an embodiment, the managing the first communication domain includes: storing information related to valid device triggers associated with the second communication domain, wherein the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with the stored information. In an embodiment, the first communication domain is a packet switching (PS) domain and the second communication domain is a circuit switching domain (CS). In an embodiment, the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with information stored on at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second communication domain; a short- message service (SMS) device coupled to the second communication domain; and a Machine-Type-Communication Internetworking Device (MTC IWF) coupled to the second communication domain.

In an embodiment, a method comprises: selectively activating, by one or more configured devices, congestion control in a first communication domain; and responding, by the one or more configured devices, to a request, from a mobile terminal device subject to an activated congestion control policy of the first communication domain, to establish a communication session in the first communication domain by: determining whether there is a valid device trigger associated with a second communication domain and with the request from the mobile terminal device; and when it is determined there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device, selectively overriding the activated congestion control policy. In an embodiment, the method further comprises: responding to a communication related to a device trigger associated with the second communication domain by: determining whether overriding of the activated congestion control policy may be permitted; and providing an indication of whether overriding of the activated congestion control policy may be permitted. In an embodiment, the communication is received from at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device; and a Machine-Type-Communication Internetworking Device (MTC IWF). In an embodiment, the method further comprises: storing information related to valid device triggers associated with the second communication domain, wherein the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with the stored information. In an embodiment, the first communication domain is a packet switching (PS) domain and the second communication domain is a circuit switching domain (CS). In an embodiment, the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with information stored on at least one of: a Mobile Switching CenterA/isitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device coupled to the second communication domain; and a Machine-Type- Communication Internetworking Device (MTC IWF) coupled to the second communication domain. In an embodiment, a non-transitory computer-readable medium's contents configure one or more processing devices to perform at least one of the methods described herein.

In an embodiment, a networking device comprises: means for selectively activating congestion control in a first communication domain; and means for responding to a request, from a mobile terminal device subject to an activated congestion control policy of the first communication domain, to establish a communication session in the first communication domain by:

determining whether there is a valid device trigger associated with a second communication domain and with the request from the mobile terminal device; and when it is determined there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device, selectively overriding the activated congestion control policy. In an embodiment, the device further comprises: means for responding to a communication related to a device trigger associated with the second

communication domain by: determining whether overriding of the activated congestion control policy may be permitted; and providing an indication of whether overriding of the activated congestion control policy may be permitted. In an embodiment, the device further comprises: means for storing information related to valid device triggers associated with the second communication domain, wherein means the for responding to the request is configured to compare information included in the request with the stored information. In an embodiment, the means for responding to the request is configured to compare information included in the request with information stored on at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device coupled to the second communication domain; and a Machine-Type-Communication

Internetworking Device (MTC IWF) coupled to the second communication domain.

In an embodiment, a system comprises: one or more processors; and one or more modules configured to, when executed by at least one of the one or more processors, manage communications in a first communication domain by, processing a device trigger message addressed to a mobile device through the first communication domain, the device trigger message including an indication to the mobile device to establish a communication session in a second communication domain with an application server; and selectively engaging in at least one communication with the second communication domain related to the device trigger message. In an embodiment, the processing the device trigger message comprises analyzing the device trigger message to determine whether the device trigger message includes an indication to the mobile device to establish a communication session in a second communication domain. In an embodiment, when it is determined the device trigger message includes an indication to the mobile device to establish a communication session in the second communication domain, the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises obtaining information related to a congestion control status of the second communication domain from the second communication domain. In an embodiment, when the obtained information related to the congestion control status of the second

communication domain indicates a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message comprises not delivering the device trigger message to the mobile device. In an embodiment, when the obtained information related to the congestion control status of the second communication domain indicates a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message further comprises providing the application server with an indication of a failure of the device trigger message. In an embodiment, the obtained information includes an indication of a backoff timer value and the indication of the failure of the device trigger message include an indication of the backoff timer value. In an embodiment, when the obtained information related to the congestion control status of the second communication domain does not indicate a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message further comprises forwarding the device trigger message to the mobile device. In an embodiment, the forwarding the device trigger message to the mobile device comprises delivering the device trigger message to a network of the first communication domain. In an embodiment, the forwarding the device trigger message comprises delivering the device trigger message to the mobile device. In an embodiment, the processing the device trigger message comprises forwarding the device trigger message and the one or more processing devices are further configured to respond to a negotiation notification of the mobile terminal by storing information related to the device trigger message. In an embodiment, the selectively engaging in at least one communication with the second communication domain related to the device trigger message

comprises responding to a communication from the second communication domain based on the stored information related to the device trigger message. In an embodiment, the one or more processing devices are further configured to send a device trigger report to the application server. In an embodiment, the processing the device trigger message comprises forwarding the device trigger message and the managing communications in the first communication domain comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain. In an embodiment, the responding to the request from the mobile device to override the congestion control policy comprises denying the request to override the congestion control policy. In an embodiment, the responding to the request from the mobile device to override the congestion control policy comprises generating a report to the application server. In an embodiment, the processing the device trigger message comprises forwarding the device trigger message and the selectively engaging in the at least one communication with the second communication domain comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain by initiating an inter-domain communication between the first and second communication domains. In an embodiment, the inter-domain communication is a request to override the congestion control policy transmitted to the second communication domain. In an embodiment, when the second communication domain denies the request, the one or more processors are configured to provide an indication of a failure related to the device trigger message to the application server. In an embodiment, the indication includes an indication of when a backoff timer related to the mobile device will expire. In an embodiment, the one or more processors comprise at least one processor of at least one of: a Mobile Switching Center/Visitor Location Register

(MSCA/LR) of the first communication domain; a short-message service (SMS) device coupled to the first and second communication domains; and a Machine- Type-Communication Internetworking Device (MTC IWF) coupled to the first and second communication domains.

In an embodiment, a method comprises: processing, by one or more configured devices, a device trigger message addressed to a mobile device through a first communication domain, the device trigger message including an indication to the mobile device to establish a communication session in a second communication domain with an application server; and selectively engaging, by the one or more configured devices, in at least one communication with the second communication domain related to the device trigger message. In an embodiment, the processing the device trigger message comprises analyzing the device trigger message to determine whether the device trigger message includes an indication to the mobile device to establish a communication session in a second communication domain. In an embodiment, when it is determined the device trigger message includes an indication to the mobile device to establish a communication session in the second communication domain, the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises obtaining information related to a congestion control status of the second communication domain from the second communication domain. In an embodiment, when the obtained information related to the congestion control status of the second communication domain indicates a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message comprises not delivering the device trigger message to the mobile device. In an embodiment, when the obtained information related to the congestion control status of the second communication domain indicates a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message further comprises providing the application server with an indication of a failure of the device trigger message. In an embodiment, the obtained information includes an indication of a backoff timer value and the indication of the failure of the device trigger message include an indication of the backoff timer value. In an embodiment, when the obtained information related to the congestion control status of the second communication domain does not indicate a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message further comprises forwarding the device trigger message to the mobile device. In an embodiment, the forwarding the device trigger message to the mobile device comprises delivering the device trigger message to a network of the first communication domain. In an embodiment, the forwarding the device trigger message comprises delivering the device trigger message to the mobile device. In an embodiment, the processing the device trigger message comprises forwarding the device trigger message and the method comprises responding to a negotiation notification of the mobile terminal by storing information related to the device trigger message. In an embodiment, the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises responding to a communication from the second communication domain based on the stored information related to the device trigger message. In an embodiment, the method comprises sending a device trigger report to the application server. In an embodiment, the

processing the device trigger message comprises forwarding the device trigger message and the method comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain. In an embodiment, the responding to the request from the mobile device to override the congestion control policy comprises determining whether to deny the request to override the congestion control policy. In an

embodiment, the responding to the request from the mobile device to override the congestion control policy comprises generating a report to the application server. In an embodiment, the processing the device trigger message comprises forwarding the device trigger message and the selectively engaging in the at least one communication with the second communication domain comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain by initiating an inter-domain communication between the first and second communication domains. In an embodiment, the inter-domain communication is a request to override the congestion control policy transmitted to the second communication domain. In an embodiment, the method comprises responding to a denial of the request by the second communication domain by providing an indication of a failure related to the device trigger message to the application server. In an embodiment, the indication includes an indication of when a backoff timer related to the mobile device will expire. In an embodiment, the one or more configured devices includes at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the first communication domain; a short- message service (SMS) device coupled to the first and second communication domains; and a Machine-Type-Communication Internetworking Device (MTC IWF) coupled to the first and second communication domains. In an

embodiment, a non-transitory computer-readable medium's contents configure one or more processing devices to perform one or more of the methods described herein.

In an embodiment, a networking device comprises: means for processing a device trigger message addressed to a mobile device through a first communication domain, the device trigger message including an indication to the mobile device to establish a communication session in a second communication domain with an application server; and means for engaging in at least one communication with the second communication domain related to the device trigger message. In an embodiment, the means for processing is configured to analyzing the device trigger message to determine whether the device trigger message includes an indication to the mobile device to establish a communication session in a second communication domain. In an

embodiment, the device further comprises means for responding to a negotiation notification from the mobile terminal. In an embodiment, the means for engaging is configured to respond to a request from the mobile device to override a congestion control policy of the second communication domain.

In an embodiment, a system comprises: a mobile terminal; an application layer server configured to request a new connection from the mobile terminal via a device trigger message; and a network control entity configured to deliver the device trigger message through one of two independent communication domains, wherein the mobile terminal is configured to determine whether the requested new connection is a connection in the other communication domain, and when it is determined that the requested new connection in a connection in the other communication domain, trigger an inter- domain communication related to the new connection. In an embodiment, the mobile terminal is configured to request the first domain to negotiate with the second domain regarding the requested new connection. In an embodiment, the mobile terminal is configured to provide an indication of a failure of the new connection to the application layer server when the second domain indicates a connection request from the mobile terminal will be blocked. In an

embodiment, the network control entity is configured to perform an inter-domain negotiation. In an embodiment, the network control entity is configured to determine whether to initiate an inter domain negotiation in response to a request from the mobile terminal. In an embodiment, the network control entity is configured to provide an indication to the mobile terminal and to the application layer server of a negotiation result.

In an embodiment, the application server is a machine type communication server.

In an embodiment, a mobile terminal is able to establish a connection in a PS domain in response to the device trigger message received via a CS domain when the PS network is in congestion control. This facilitates better support of the different machine type communications, and avoidance of wastage of energy and computation resources on the mobile terminal. At the same time, the congested network may avoid waste of network resources on mobile terminals that have no meaningful need for timely use of a connection, and reduce the need for potential additional mobility management controls. An embodiment may also facilitate the network serving more terminals with higher efficiency, which can contribute to alleviate network congestion. 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 through both a 3GPP Circuit Switched (CS) Domain and a 3GPP Packet Switched (PS) Domain.

Figure 2 illustrates an example operation sequence of an embodiment where a MTC Device requests a negotiation and establishes a connection in a PS domain.

Figure 3 illustrates an example operation sequence of an embodiment where a MTC Device requests a negotiation and establishes a connection in a PS domain.

Figure 4 illustrates an example operation sequence of an embodiment where a MTC Device requests a negotiation and establishes a connection in a PS domain.

Figure 5 illustrates an example architecture of a MTC Device of an embodiment.

Figure 6 illustrates an example architecture of a Mobile Switching Center/Visitor Location Register (MSC/VLR) of an embodiment.

Figure 7 illustrates an example architecture of a Short Message service-Service Center (SMS-SC) of an embodiment.

Figure 8 illustrates example logic that can be used by a Connection Manager of a MTC Device for the handling of connections for an MTC application according to an embodiment.

Figure 9 illustrates an example system architecture to support an MTC application over a control plane in a 3GPP Domain according to an embodiment.

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 after reviewing the disclosure 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 technologies and network architectures. However, it will be apparent to anyone skilled in the art after reviewing the specification that embodiments of the present disclosure may be practiced with other access technologies and network architectures, e.g. GSM, GPRS, UMTS, WiMAX, LTE Advanced, etc.

With reference to Figure 1 , an example architecture of an embodiment of a basic network 100 that supports Machine Type

Communication (MTC) is shown. The Machine Type Communication Device (MTC Device) 101 is configured to access MTC services from an MTC Server 170 via both a 3GPP Circuit Switched (CS) Domain 150 and a 3GPP Packet Switched (PS Domain) 130. Both 3GPP CS Domain 150 and 3GPP PS Domain 130 may be any network that supports the CS and/or PS domain systems and access technologies, such as those defined by the 3^rd Generation Partnership Project (3GPP). In an embodiment where the network 100 comprises a System Architecture Evolution (SAE) for the Evolved Universal Terrestrial Radio Access Network (EUTRAN), such as defined in General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E- UTRAN) access, 3GPP TS 23.401 v1 1 .0.0 Release 1 1 , 201 1 -12-16, the 3GPP PS Domain 130 may comprise one or more Mobility Management Entities (MME) 131 , one or more Serving Gateways (SGW) 132 and one or more Packet Data Network Gateways (PGW) 133. In an embodiment where the network 100 comprises a General Universal Mobile Telecommunications System (UMTS) for General Packet Radio Service (GPRS), such as defined in General Packet Radio Service (GPRS); Service description; Stage 2, 3GPP TS 23.060, v1 1 .0.0 Release 1 1 , 201 1 -12-16, the 3GPP PS Domain 130 may comprise one or more Serving GPRS Support Nodes (SGSN) 135 and one or more Gateway GPRS Support Nodes (GGSN) 137. The network of 3GPP CS Domain 150 as illustrated comprises one or more Mobile Switching

Center/Visitor Location Register (MSC/VLR) 151 .

As illustrated, an MTC Server 170 is coupled to a Short Message service-Service Center (SMS-SC) 155 via an interface 149. In case the MTC Server 170 would like to trigger an MTC Device 101 which is not available or reachable by the MTC Server 170, the MTC Server 170 may be configured to send a device trigger request message to the SMS-SC 155. The SMS-SC 155 may be configured to forward the SMS device trigger message to an SMS- GMSC/SMS-IWMSC 153 via an interface 147. The SMS-GMSC/SMS-IWMSC 153 may be configured to route the SMS device trigger message towards the MTC Device 101 either via the 3GPP CS domain 150 or via the 3GPP PS domain 130, for example, based on subscription information of MTC Device 101 . For a 3GPP CS domain delivery, the SMS-GMSC/SMS-IWMSC 153 may be configured to forward the SMS device trigger message to the MSC/VLR 151 via an interface 143. The MSC/VLR 151 may be configured to transmit the SMS device trigger message through a GSM EDGE Radio Access Network (GERAN) 109 to the MTC Device 101 . The MTC Device 101 may be

configured to transmit a mobile-originating SMS to the MTC Server 170 through the CS domain 150, for example, the mobile-originating SMS carrying the information requested by device trigger message from MTC Server.

For an example 3GPP PS domain delivery, the SMS-GMSC/SMS- IWMSC 153 as illustrated has an interface 145 with the SGSN 135. The SMS device trigger message may be transmitted to the SGSN 135 via the interface 145. The SGSN 135 may be configured to transfer the SMS device trigger message through a Universal Terrestrial Radio Access Network (UTRAN) 107 to the MTC Device 101 . For another example of a PS domain delivery, for example in case the interface 145 is not available or the MTC Device 101 accesses the MTC service through a EUTRAN 105 via a radio interface 102, the SMS-GMSC/SMS-IWMSC 153 may be configured to forward the SMS device trigger message to MSC/VLR 151 . The MSCA/LR 151 may be configured to relay the SMS device trigger message to the SGSN 135 or MME 131 after establishing a connection to the SGSN 135 or MME 131 . The SGSN 135 or MME 131 may be configured to transfer the SMS device trigger message to the MTC Device 101 through the UTRAN 107 or the EUTRAN 105, respectively.

MTC Device 101 may be configured to transmit application data through 3GPP PS domain 130 to MTC Server 170. For example, after receiving a device trigger message, the MTC Device 101 may be requested to perform some measurement or collect data and transmit related information and/or data to the MTC Server 170. In a case where the MTC Device 101 is accessing the UTRAN 107 via the radio interface 103, the data may be transmitted from UTRAN 107 to the MTC Server 170 through the SGSN 135 and GGSN 137 over the interfaces 121 , 123, 125. In a case where the MTC Device 101 is accessing the EUTRAN 105, the data may be transmitted from EUTRAN 105 to the MTC Server 170 through the SGW 132 and PGW 133 over the interfaces 1 13, 1 14, 1 15.

In order to avoid obscuring the disclosure, Figure 1 shows some of the entities in both the 3GPP CS domain 150 and the 3GPP PS domain 130 relevant to the present disclosure. In practice, there may be more functional entities in these two 3GPP Domains, 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 disclosure.

As normally Machine Type Communication involves a large number of devices, the network 100 may protect itself from surges in both data and signaling traffic. Therefore, the network 100 may employ congestion mechanisms at different layers, e.g., such as those introduced in 3GPP TR 23.888 v1 .5.0 Release 1 1 . For example, the MME 131 may activate 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 EUTRAN 105 may start to reject radio connection establishment requests from the MTC Device {e.g., MTC Device 101 ). In some cases, the EUTRAN 105 may even broadcast an access barring indication that may force lower priority devices to backoff from

accessing the network 100.

Although Figure 1 shows that the PGW 133, SGW 132, MME 131 , EUTRAN 105, SGSN 135 and GGSN 137 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 an EUTRAN 105, an MME 131 , and an SGW 132, but the PGW 133 may be in a second operator's network. In some deployment cases, e.g.

network sharing, the EUTRAN 105 may be even shared by different operators.

With reference to Figure 2, an operation sequence example 200 is provided to illustrate an embodiment in context of the network shown in Figure 1 . It is assumed that the congestion control mechanisms in the CS domain network 150 and the PS domain network 130 are separate and PS domain network 130 is in congestion control mode. The MTC Device 101 , e.g., a User Terminal (UE) in 3GPP point of view, is originally attached in both the CS domain and the PS domain and is currently on the CS domain, as indicated in step 201 . When the MTC Device 101 is under the CS domain, the MTC Device 101 does not have an active connection in the PS domain, e.g., it needs signaling with the MME 131 through EUTRAN 105 (or, with the SGSN 135 through UTRAN 107, not show in Figure 2) before sending any data in the PS domain. The operation sequences described in Figure 2 are generally still applicable, with the SGSN 135 replacing the MME 131 .

In another case, the MTC Device 101 may be just registered in the CS domain, and have an identifier that may be reached by the MTC Server 170, e.g. an Mobile Subscriber Integrated Services Digital Network Number (MSISDN), etc., or an external ID (Network Access Identifier, Fully Qualified Domain Name, etc). The MTC Server 170 may send a device trigger towards this identifier if the MTC Server 170 needs to have a communication session with the MTC Device (UE) 101 . The MTC Device (UE) 101 , after receiving this device trigger via the CS domain, may be triggered to establish a connection in the PS domain, e.g., by registering to the PS domain in the same or a different cell, and start a session with the MTC Server 170.

The device trigger in the CS domain may be formatted as a Short Message Service (SMS) message. This formatting may be done, for example, by the MTC Server 170 itself, or by a SMS server in an operator's network.

In the following description, the SMS based device trigger is used as example to facilitate description of operation of an embodiment. The device trigger may be forwarded and delivered to the MTC Device (UE) 101 via other means, such as other CS domain specific means, e.g. as an extension to a control signal, etc.

When a device trigger request message is received from the MTC

Server 170, the SMS-SC 155 forwards the message to SMS-GMSC/SMS- IWMSC 153, as indicated in step 203 and 205. The SMS-GMSC/SMS-IWMSC 153 will obtain routing information for the Short message, as in step 207. Since the MTC Device 101 is registered in CS domain, SMS-GMSC/SMS-IWMSC 153 will forward the short message to the MSC/VLR 151 with which the MTC Device 101 registered, as in step 209.

When there is no connection between the MTC Device 101 and the MSC/VLR 151 , the MSC/VLR 151 will send a Paging message to the MTC Device 101 , as in step 21 1 {e.g., the Paging message may be transferred through the GERAN 109). Upon the reception of the Paging message 21 1 , the MTC Device 101 responds, e.g. by sending a Paging response towards the MSC/VLR 151 , and establishes the corresponding connections, as in step 213, e.g. enter into a Dedicated Mode. After the connections are established between MTC Device 101 and MSC/VLR 151 , the short message is transported to the MTC Device 101 , as in step 215. When the MTC Device 101 receives the Short Message 215, the MTC Device 101 informs its SMS Application/management function (see Figure 5), and analyzes the device trigger short message, as in step 217. In a case where the device trigger short message indicates a need for a connection establishment in a PS domain, the SMS Application/management function is configured to check the PS domain status with PS Domain Mobility

Management of the MTC Device 101 and determine whether congestion control should be overridden and/or a negotiation is needed.

For example, if the MTC Device 101 has a previous PS domain backoff timer running, the SMS Application/management may be configured to use information indicated in the device trigger short message, a MTC Device configuration, and/or subscription data, etc., to decide whether to override the backoff timer and/or request a negotiation with the network. If the backoff timer is not allowed to be overridden, the MTC Device 101 may be configured to send an SMS delivery report message to inform the MTC Server 170 via MSCA/LR 151 and SMS-SC 155 about the failure of requested connection establishment in PS domain due to PS congestion control backoff timer running and may also indicate the value of the backoff timer.

In a case where is decided by the MTC Device 101 to override the congestion control and negotiate with the network, the MTC Device 101 may be configured to send a negotiation notification, together with relevant information {e.g., a target MME, etc.), to MSCA/LR 151 to request a negotiation with a PS domain network to support the connection establishment needed to respond to the device trigger short message, as in step 219. The negotiation notification may be transmitted using CS domain control signaling, encapsulated in an SMS delivery report message, etc.

In a case where an SMS delivery report is used for carrying a negotiation notification, the SMS delivery report message may include a negotiation notification and the associated information, e.g., target MME address, UE identifier, etc, for the MSCA/LR 151 to read. After negotiation with the PS domain, the MSCA/LR 151 informs the MTC Device 101 of a negotiation result.

It should be noted that the SMS delivery report may be encapsulated in various formats and therefore be called different names when forwarded between different network nodes from the mobile terminal towards the final destination. For example, between the MSC and SMS-SC, the delivery report may be encapsulated into another message with other additional information elements. However, this does not affect the general principles of the present disclosure.

In another operational example, the SMS delivery report message may include not only the negotiation notification, but also information relevant to the MTC Server 170. The additional information for the MTC Server 170, e.g. the connection setup is delayed, the backoff time left, etc., may be

encapsulated in an information element which may be transparent to the MSCA/LR 151 . After the negotiation with the PS domain, the MSCA/LR 151 will forward the encapsulated information element to the SMS-SC 155, which in turn may forward the information element to the MTC Server 170.

In an embodiment, the MTC Device 101 may include multiple encapsulated information elements in the SMS delivery report. The MSCA/LR 151 may forward all, some or none of the elements to the SMS-SC 155 according to the negotiation results with the PS domain. For example, the MSCA/LR 151 may not forward any additional information to the SMS-SC 155 if the negotiation is successful, but may forward an encapsulated information element marked as failure report to the SMS-SC 155.

When a negotiation request notification from MTC Device 101 is received by the MSCA/LR 151 , the MSCA/LR 151 performs an evaluation based on stored information related to MTC Device 101 , a subscription data of MTC Device 101 , network status, local policy or operator configurations, etc., to decide whether to accept and forward the request of MTC Device 101 , as in step 221 . In case the request is accepted, the MSCA/LR 151 establishes a connection to the target MME 131 if the connection is not available, and sends a negotiation request to the target MME 131 using the MTC Device 101 indicated information, as in step 223. The negotiation request may include information about the MTC Device 101 , e.g., the identifier, the service requested, etc.

As the PS domain network is in congestion control mode, the target MME 131 uses the corresponding subscription information of the MTC Device 101 , its local policy, network status, operation rules, etc., to decide whether the congestion control should be overridden to allow the MTC Device 101 a data connection. The MME 131 provides an indication to the MSCA/LR 151 of the decision, as indicated in step 225 and 227. The MME 131 may also provide further information related to the decision to the MSCA/LR 151 , for example a duration when MME 131 may not allow the MTC Device 101 to setup a connection, etc. The MSCA/LR 151 forwards an indication of the decision regarding the negotiation request to the MTC Device 101 , as in step 229. In case the MME 131 allows the connection establishment, the MME 131 stores MTC Device 101 associated information.

Once the MTC device receives the negotiation result from

MSCA/LR 151 , the MTC Device 101 may generate an SMS delivery report again based on the negotiation result and transmit the delivery report to the MTC Server 170 through MSCA/LR 151 and SMS-SC 155, as indicated in step 231 , step 233 and step 235. The MTC Device 101 may decide whether to generate this additional delivery report based on the indicated network capabilities, e.g. that of the MSCA/LR 151 or SMS-SC 155. If the MSCA/LR 151 or SMS-SC 155 indicated that they can process the negotiation result directly, the MTC Device 101 does not need to send the delivery report.

In case the MTC Device 101 needs to send the delivery report again, if it receives the negotiation result of MME 131 supporting the connection establishment, the MTC Device 101 sends the SMS-successful-delivery report to MTC Server 170. Otherwise, the MTC Device 101 provides an indication to the MTC Server 170 that it cannot setup the requested connection in PS domain, for example due to PS domain network in congestion control, using the SMS delivery report. The MTC Device 101 may also include further information received from negotiation result 229 in the SMS delivery report for MTC Server 170. For example, the MTC Device 100 may inform the MTC Server 170, based on the negotiation result, of an expected time the congestion back off may stop. The MTC Server 170 may initiate a further trigger after the time out of such a backoff period.

Alternatively, in case both the negotiation notification and the information for MTC Server 170 is carried in the SMS delivery report in step 219, the MSC/VLR 151 may reorganize the delivery report based on the negotiation result and transmit the report to the MTC Server 170.

In case the MME 131 can support the connection establishment requested by the MTC Device 101 , the MTC Device 101 switches to PS domain and selects a suitable PS cell, as in step 237. The MTC Device 101 may trigger the PS domain Mobility Management function (see Figure 5) to establish the connection to the network. The PS domain Mobility Management function evaluates and decides whether to override the congestion control, as in step 239.

The MTC Device 101 may send a Combined Tracking Area Update (TAU) (or Combined Routing Area Update (RAU)) message to the MME 131 (or to the SGSN 135) even if the congestion control is activated, as in step 241 . When the MME 131 receives the Combined TAU message 241 , the MME 131 checks if a connection is allowed for the indicated MTC Device 101 based on the information stored in step 229. If the verification is successful, the MME 131 will override a congestion control policy in place, and grant access to the MTC Device 101 , as in step 243. If the MTC Device 101 has not registered to the PS domain before, it may send a registration message to the PS domain and obtain a connection. For example, it can send an Attach Request, or a PDP Context request towards the PS domain control entities.

With reference to Figure 3, another embodiment of an operation sequence example 300 is presented in the context of the network 100 shown in Figure 1 . Briefly, it is assumed that the congestion control mechanisms in CS domain and PS domain are deployed independently and only the PS domain network is in congestion control mode. Originally the MTC Device 101 is either registered to both the CS domain and the PS domain or just registered in the CS domain. Currently the MTC Device 101 is under the CS domain, as indicated in step 301 . The device trigger from MTC Server 170 to MTC Device 101 may be delivered via a Short Message Service (SMS) message or via other specific means, e.g., as an extension to control signaling, etc. The operation sequences described in Figure 3 are still applicable, with the SGSN 135 replacing the MME 131 . When a device trigger request message is received from the MTC Server 170, the SMS-SC 155 forwards the message to SMS- GMSC/SMS-IWMSC 153, as indicated in step 303 and 305. The SMS- GMSC/SMS-IWMSC 153 obtains the routing information for the Short message, as in step 307. Since the MTC Device 101 is registered in CS domain, SMS- GMSC/SMS-IWMSC 153 will forward the short message to the MSC/VLR 151 with which the MTC Device 101 registered, as in step 309.

When there is no connection between the MTC Device 101 and the MSC/VLR 151 , the MSC/VLR 151 sends a Paging message to the MTC Device 101 , as in step 31 1 . The Paging message is transferred through the GERAN 109 (see Figure 1 ). Upon the reception of the Paging message 31 1 , the MTC Device 101 responds, e.g. by sending a Paging response toward the MSC/VLR 151 , and establishes the corresponding connections, as in step 313, e.g., enters into the Dedicated Mode. After the connections are established between MTC Device 101 and MSC/VLR 151 , the short message is transported to the MTC Device 101 , as in step 315.

When the MTC Device 101 receives the Short message 315, the

MTC Device 101 informs its SMS Application/management function (see Figure 5), and analyzes the device trigger short message, as in step 317. In case the device trigger short message needs a connection establishment in a PS domain, the SMS Application/management function checks the PS domain status with PS Domain Mobility Management (see Figure 5) of the MTC Device 101 and evaluates whether the congestion control should be overridden and/or a negotiation should be initiated.

For example, if the MTC Device 101 has a previous PS domain backoff timer running, the SMS Application/management may use the information indicated in the device trigger short message, an MTC Device configuration, and/or a subscription data, etc., to decide whether to override the backoff timer and/or initiate a request for a negotiation with the network 100. If the backoff timer may not be overridden, the MTC Device 101 may directly send an SMS delivery report message to inform the MTC Server 170 via MSCA/LR 151 and SMS-SC 155 about the failure of requested connection establishment in PS domain due to a PS congestion control backoff timer running and may also indicate the value of the backoff timer.

When it is decided to override the congestion control and negotiate with the network, the MTC Device 101 sends a negotiation

notification, together with associated information {e.g., target MME, etc.), to SMS-SC 155 to request a negotiation with PS domain network to support the connection establishment requested by the device trigger short message. The negotiation notification to the SMS-SC 155 may be encapsulated in the SMS delivery report message and be transparently transported by the MSCA/LR 151 , as indicated in step 319 and step 321 .

For example, the SMS delivery report message may include an indication to SMS-SC 155 whether MTC Device 101 will wait for the

confirmation of the negotiation result before switching to the PS domain. This indication may guide the SMS-SC 155 on transmitting the negotiation result to MTC Device 101 .

In a case where the MTC Device 101 does not wait for confirmation of the negotiation result, it may include a timer value in the SMS delivery report message, indicating how long the MTC Device 100 will switch to the PS domain.

When the SMS-SC 155 receives the negotiation request in the

SMS delivery report, the SMS-SC 155 decides whether to initiate a negotiation to the target MME 131 as requested by the MTC Device 101 according to its local policy, operation configurations, the indicated information of device trigger request message for the given MTC device 101 , or a subscription of the given MTC Device 101 , etc. as in step 323. When the SMS-SC 155 decides not to start the negotiation, the SMS-SC 155 informs the MTC Server 170 of the inability to support the requested connection in the PS domain due to congestion control and may also inform the MTC Server 170 of the remain time of a congestion control backoff. Otherwise, the SMS-SC 155 starts the negotiation by sending the request message to the target MME 131 , as in step 325.

Upon reception of the negotiation request message from the SMS-SC 155, as the congestion control is activated, the target MME 131 uses the corresponding subscription information of the MTC Device 101 , the MME's local policy, network status, or operation rules, etc., to decide whether the congestion control should be overridden to allow the MTC Device 101 a data connection. The MME 131 provides an indication of the decision to the SMS- SC 155, as indicated in step 327 and step 329. The messages transmitted between the SMS-SC 155 and the MME 131 may be relayed by the MSCA/LR 151 . The MME 131 may also provide further information related to the decision to the SMS-SC 155, for example the duration when the MME 131 may not allow the MTC Device 101 to setup a connection. When the MME 131 allows the connection establishment, the MME 131 stores information associated with the MTC Device 101 .

When the SMS-SC 155 receives the result of the negotiation from the MME 131 , the SMS-SC 155 sends the delivery report to the MTC Server 170 to indicate the device trigger message was successful delivered based on the negotiation result, as in step 331 .

The SMS-SC 155 may also forward information related to the negotiation to the MTC Device 101 , as in step 333. The negotiation result may be transmitted over a new network-originating SMS message. When the MTC device does not need a notification (and the MTC device 101 may provide an indication a notification is not necessary), the SMS-SC 155 may not forward the decision to the MTC Device 101 .

When the MME 131 can support the connection establishment requested by the MTC Device 101 , the MTC Device 101 switches to the PS domain and selects a suitable PS cell, as in step 335. The MTC Device 101 triggers the PS domain Mobility Management function (see Figure 5) to establish the connection to the network. The PS domain Mobility Management function evaluates and decides to override the congestion control, as in step 337.

The MTC Device 101 sends a Combined Tracking Area Update

(TAU) (or Combined Routing Area Update (RAU)) message to MME 131 (or SGSN 135), as in step 339. When the MME 131 receives the Combined TAU message 339, the MME 131 checks whether a connection is allowed for the indicated MTC Device 101 based on the information stored in step 329. If the verification is successful, the MME 131 overrides a congestion control policy in place, and grants access to the MTC Device 101 , as in step 341 . If the MTC Device 101 has not registered to the PS domain before, it may send a registration message to the PS domain and obtain a connection. For example, the MTC Device 101 may send an Attach Request, or a PDP Context request towards the PS domain control entities.

With reference to Figure 4, an embodiment of an operational sequence example is presented in the context of the network 100 shown in Figure 1 . Briefly, it is assumed that the congestion control mechanisms in CS domain and PS domain are deployed independently and only the PS domain network is in congestion control mode. Originally the MTC Device 101 is either registered to both CS domain and PS domain or just registered in the CS domain. Currently the MTC Device 101 is under CS domain, as seen in step 401 . The device trigger from MTC Server 170 to MTC Device 101 may be delivered via a Short Message Service (SMS) message or via other means, e.g. as an extension to the control signaling, etc. The operation sequences described in Figure 4 are applicable, with the SGSN 135 replacing the MME 131 .

When a device trigger request message is received from the MTC Server 170, the SMS-SC 155 forwards the message to SMS-GMSC/SMS- IWMSC 153, as indicated in step 403 and 405. The SMS-GMSC/SMS-IWMSC 153 obtains the routing information for the Short message, as in step 407.

Since the MTC Device 101 is under the CS domain, SMS- GMSC/SMS-IWMSC 153 forwards the short message to the MSCA/LR 151 with which the MTC Device 101 registered, as in step 409.

When there is no connection between the MTC Device 101 and the MSCA/LR 151 , the MSCA/LR 151 sends a Paging message to the MTC Device 101 , as in step 41 1 . The Paging message may be transferred through the GERAN 109 (see Figure 1 ). Upon the reception of the Paging message 41 1 , the MTC Device 101 responds by sending a Paging response towards the MSCA/LR 151 , e.g. entering into the Dedicated Mode, as in step 413. After the connections are established between MTC Device 101 and MSCA/LR 151 , the short message is transported to the MTC Device 101 , as in step 415.

When the MTC Device 101 receives the Short message 415, it informs the SMS Application/management function (see Figure 5), and analyzes the device trigger short message, as in step 417. In case the device trigger short message indicates a need for a connection establishment in the PS domain, the SMS Application/management function checks the PS domain status with PS Domain Mobility Management (see Figure 5) of the MTC Device 101 and evaluates whether the congestion control should be overridden and/or a negotiation is required.

For example, if the MTC Device 101 has a previous PS domain backoff timer running, the SMS Application/management may use the information indicated in the device trigger short message, a MTC Device configuration, and/or a subscription data, etc., to decide whether to override the backoff timer and/or request a negotiation with the network. If the backoff timer may not be overridden, the MTC Device 101 may directly send an SMS delivery report message to inform the MTC Server 170 via MSC/VLR 151 and SMS-SC 155 about inability to establish the requested connection in the PS domain due to the PS congestion control backoff timer running and may also indicate the value of the backoff timer.

When it is decided to override the congestion control and also negotiate with the PS domain, the MTC Device 101 sends a negotiation notification, together with associated information {e.g., target MME, etc.), within the SMS delivery report message to the MTC Server 170. The SMS delivery report message is transmitted via the MSC/VLR 151 and the SMS-SC 155 to the MTC Server 170, as indicated in step 419, step 421 and step 423.

The negotiation notification in the SMS delivery report message indicates to the MSC/VLR 151 and the SMS-SC 155 that the MTC Device 101 will initiate a negotiation with the target MME for connection establishment in response to the received SMS device trigger message. The MSC/VLR 151 and SMS-SC 155 store the device trigger information associated with the given MTC Device 101 , respectively, as in step 425 and step 427.

The SMS-SC 155 also indicates to the MTC Server 170 that the SMS device trigger message has been received but the connection requested in PS domain may not be established due to PS domain in congestion control.

MTC Device 101 switches to the PS domain, as in step 429, and select a suitable PS cell in order to establish the connection to the target MME 131 . The PS domain Mobility Management function (see Figure 5) of MTC Device 101 evaluates and decides whether to override the congestion control, as in step 431 .

The MTC Device 101 sends a Combined Tracking Area Update

(TAU) message to MME 131 (or a Combined Routing Area Update (RAU) to SGSN 135), as in step 433. The Combined TAU message may include an indication of the device trigger to indicate to the MME 131 that the connection establishment is associated with the device trigger message received via the CS domain previously. If the MTC Device 101 has not registered to the PS domain before, it may send a registration message to the PS domain and obtain a connection. For example, the MTC Device 101 may send an Attach Request, or a PDP Context request towards the PS domain control entities.

When the MME 131 receives the Combined TAU message 433, as congestion control is activated, the MME 131 checks if the connection establishment is allowed for the indicated MTC Device 101 based on its local policy, a subscription data of the MTC Device 101 or operator configurations, etc. When the MTC Device 101 is allowed to override the congestion control, the MME 131 verifies if there is a valid device trigger associated with the MTC Device 101 against the information stored in the MSCA/LR 151 and/or stored in the SMS-SC 155, as in step 435. If the verification is successful, the MME 131 overrides the congestion control policy in place and grants access to the MTC Device 101 .

With reference to Figure 5, an embodiment of a device structure of an MTC device 500 is illustrated, which may be employed, for example, by the embodiment of Figure 1 (e.g., as the MTC device 101 ). The MTC Device 500 includes a SMS Application & Management function or module 501 , which is capable of communicating at application layer with the MTC Server 170 through SMS services. The SMS Application & Management function 501 receives the SMS device trigger message from the MTC Server 170 and transmits the SMS delivery report message or other MTC Device-originating SMS message through either CS domain network via interface 51 1 or PS domain network via interface 521 .

Upon reception of the SMS device trigger message from MTC Server 170, the SMS Application & Management 501 analyzes the device trigger message to decide the action of the lower layer [e.g., the 3GPP Radio Transport 507). In case the device trigger message indicates a need for a connection establishment to the PS network, the SMS Application and

Management function 501 checks the PS domain mobility status with PS Domain Mobility Management function or module 505 via interface 521 . The SMS Application & Management function 501 is configured to decide whether to request a negotiation with the PS domain network for supporting the connection establishment based on some local policy, operator rules, or user introduction, etc. The SMS Application & Management function 501 also is configured to decide the routing of the negotiation request message. The messages which SMS Application & Management function 501 generates to transmit to the network, for example, SMS delivery report message, negotiation request message, etc. would be passed to either the CS domain Mobility Management function or module 503 or to the PS domain Mobility Management function 505 for transmission.

The CS domain Mobility Management function 503 has an interface 513 with the 3GPP Radio Transport module 507. This allows the CS Domain Mobility Management function 503 to pass the messages from the SMS Application & Management 501 for transmission.

In case the device trigger message is delivered over control signaling, after receiving the device trigger message from the 3GPP Radio Transport 507, the CS domain Mobility Management 503 would process the device trigger message carried in the control signaling. If the device trigger message indicates a need for a connection establishment to the PS domain, the CS domain Mobility Management 503 checks the PS domain mobility status with PS domain Mobility Management 505 via interface 515. The CS domain Mobility Management 503 would evaluate and decide whether to request a negotiation with the PS domain.

The 3GPP Radio Transport 507 also interworks with the PS domain Mobility Management 505 via an interface 523. The PS domain Mobility Management 505 routes the messages from the SMS Application &

Management function 501 towards the 3GPP Radio Transport 507 for transmission.

As illustrated, the MTC Device 500 comprises one or more processors P, one or more memories M and one or more discrete devices 525, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer. The various functions or modules of the MTC Device 500 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 devices 525, and various combinations thereof, etc.

With reference to Figure 6, an embodiment of a device structure of an MSCA/LR 600 is illustrated, which may be employed, for example, by the embodiment of Figure 1 {e.g., as the MSCA/LR 151 ). The MSCA/LR 600 includes a UE SMS Management function or module 601 that is capable of receiving from and transmitting to the MTC Device 101 SMS messages. The UE SMS Management 601 is also responsible for processing the SMS messages from MTC Device 101 . In case of receiving the negotiation request with the PS core network within an SMS message from the MTC Device 101 , the UE SMS Management 601 is configured to verify and decide whether to accept the request based on its local policy, operator configurations, or a subscription of MTC Device 101 , etc. After the decision, the UE SMS

Management 601 may check with the PS Core Network Management function or module 607, via the interface 621 , to setup a connection to the target PS Core network, e.g. a target MME, for a negotiation requested by the MTC Device 101 . The PS Core Network Management 607 has an interface 623 with the PS Core Network transport layer or module 609. The PS Core Network Management 607 is configured to route the negotiation request message toward the PS Core Network transport layer 609 for transmission. The PS Core Network Management 607 also is configured to pass messages received from the PS core network transport layer 609 to the UE SMS Management 601 .

In case the negotiation request message is transmitted in the NAS signaling, the UE Connection Management function or module 603 is

configured to process this message after receiving it from UE Transport layer or module 605 via the interface 613. The UE Connection Management 603 is configured to check the validity of the negotiation request with the UE SMS Management 601 via interface 61 1 . The UE connection management 603 is configured to decide whether to accept the request, for example, based on the local policy, operator configurations, or a subscription of MTC Device 101 , etc. If the negotiation request is accepted, the UE Connection

Management 603 is configured to check with the PS Core Network

Management module 607 via the interface 615 to setup a connection to the target PS Core network for negotiation. The PS Core Network Management 607 is also configured to pass the negotiation response message from the target PS core network to the UE Connection Management via the same interface 615.

As illustrated, the MSCA/LR 600 comprises one or more processors P, one or more memories M and one or more discrete devices 625, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer. The various functions or modules of the MSCA/LR 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 devices 625, and various combinations thereof, etc.

With reference to Figure 7, an embodiment of a device structure of an SMS-SC 700 is illustrated, which may be employed, for example, by the embodiment of Figure 1 {e.g., as the SMA-SC 155). The SMS-SC 700 includes an UE SMS Management 701 module that is in charge of handling the SMS messages for the MTC Device 101 . The UE SMS Management module 701 is configured to generate the SMS device trigger message and pass it to UE Connection Management 703 module via an interface 71 1 for transmission to the MTC Device 101 by Transport layer module 709. The UE Connection Management 703 also is configured to forward the SMS messages or SMS delivery report messages from MTC Device 101 received from the Transport layer 709 via an interface 713 to the UE SMS Management 701 . The UE SMS Management module 701 is configured to process the SMS message or SMS delivery report message from MTC Device 101 . When a negotiation request is received encapsulated in an SMS delivery report, the UE SMS Management module 701 is configured to evaluate and decide whether to accept the negotiation request, for example based on local policy, operator configurations, or a subscription of MTC Device 101 , etc. According to the decision, the UE SMS Management 701 is configured to inform the Core Network Connection Management module 705 to initiate the negotiation with the requested PS core network via the interface 721 . The Core Network Connection Management module 705 has an interface 723 with the Transport Layer 709. This interface allows the Core Network Connection Management 705 to receive messages from and transmit messages to the core network. The UE SMS Management module 701 is configured to generate a device trigger delivery report based on the SMS delivery report received from the MTC Device 101 and/or the negotiation result from the requested PS network. The UE SMS Management module 701 is configured to pass the device trigger delivery report to the MTC Server Connection Manager 707 via an interface 731 . The MTC Server Connection Manager 707 is configured to route the device trigger delivery report to Transport Layer 709 via an interface 733 for the transmission to the MTC Server 170.

As illustrated, the SMS-SC 700 comprises one or more processors P, one or more memories M and one or more discrete devices 725, which may comprise, for example, multipliers, adders, logic circuits, etc., and which as illustrated include a logic device and a mixer. The various functions or modules of the SMS-SC 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 devices 725, and various combinations thereof, etc.

With reference to Figure 8, an embodiment of a logic flow 800 that can be used by an embodiment of an MTC Device, such as the embodiment of an MTC Device 500 of Figure 5, is illustrated. SMS Application & Management 501 implementing the present invention is illustrated. This corresponds to the embodiments of operation as illustrated in Figures 2-4. For convenience, the logic flow 800 is discussed with reference to the embodiment of an MTC Device 500 of Figure 5. When the SMS Application & Management function 501 receives the SMS device trigger message via CS domain network, as in step 801 , the SMS Application and Management function 501 analyzes the device trigger message to determine whether connection establishment in the PS domain network is needed by the device trigger message, as in step 803. When it is determined that connection in the PS domain is not needed, the MTC Device 101 remains on the CS domain and performs the necessary operation of the MTC application, e.g. transmitting some application data in the CS domain, as in step 805. When it is determined a connection in the PS domain is needed, the SMS Application & Management 501 checks the PS domain mobility status with the PS domain Mobility Management 505, as in step 807.

When the PS domain Mobility Management 505 indicates that currently the PS domain mobility status indicates the congestion control is activated for the MTC device, for example, a Mobility Management backoff timer is running, the MTC Device 101 would evaluate and decide whether to override the current congestion control policy, as in step 817.

When the PS domain Mobility Management indicates that currently the PS domain congestion control for the MTC Device 101 is not activated, for example, the Mobility Management backoff timer is not running, the MTC Device 101 optionally reads broadcast system information of a PS domain cell, as in step 81 1 . This broadcasted system information may indicate whether a particular PS domain radio access network is performing congestion control, e.g. EAB, etc., which may indicate a negotiation request (see step 821 ) is likely needed.

When the broadcast indicates the target PS network is not in congestion control, the MTC Device 101 initiates the connection establishment request procedure towards the PS domain, as in step 815. Otherwise, the SMS Application & Management function 501 evaluates and decides whether to override the current congestion control, as in step 817. The information used for the evaluation may include the indicated information in an SMS device trigger message, a subscription of MTC Device 101 , or the operator

configurations, etc.

When optional steps 81 1 and 813 are omitted, the flow may proceed from step 809 to step 815 when it is determined that PS domain congestion control is not activated in the MTC device, as indicated by a dashed line from step 809 to step 815.

When it is determined not to override a current congestion control policy, the SMS Application & management 501 sends a delivery report to the MTC Server 170 to indicate a failure of connection establishment in the PS domain, for example due to congestion control, as in step 819. Otherwise, the SMS Application & Management function 501 informs the CS Domain Mobility Management 503 to initiate a negotiation with target PS domain network through the CS domain, as in step 821 . The negotiation request message may be transmitted, for example, by SMS delivery report message or by NAS signaling.

The SMS Application & Management function 501 checks the negotiation result, as in step 823. When the target PS domain network agrees to support the connection establishment, the MTC Device 101 switches to the PS domain and overrides the current congestion control to establish the connection, as indicated in step 827 and step 829. Otherwise, the MTC Device 101 sends delivery report to the MTC Server 170 to indicate a failure of connection establishment in PS domain, for example due to congestion control, as in step 825.

In an embodiment, the operator of the MTC Server 170 and mobile operator might have an agreement that allows an MSCA/LR 151 and/or a SMS-SC 155 to understand a device trigger message. This may be useful for legacy MTC Devices {e.g., an MTC Device 101 which does not support enhanced device trigger delivery procedures), without the need to upgrade the legacy MTC devices. However, such embodiments may use more network side operation support for understanding the device trigger message. When the MSCA/LR 151 and/or SMS-SC 155 know that the MTC Device 101 is a legacy MTC Device, after receiving a device trigger message from the MTC Server 170, the SMS-SC 155 or MSC/VLR 151 may, before delivering the device trigger message to the MTC Device 101 , check the status of the target PS domain {e.g., MME 131 or SGSN 135) in which a connection establishment is desired as indicated by the device trigger message. If the target PS domain cannot support the connection establishment due to congestion control, the MSC/VLR 151 or SMS-SC 155 may not deliver the device trigger message to MTC Device 101 and inform the MTC Server 170 about the failure due to PS domain congestion control. The MSC/VLR 151 or SMS-SC 155 may also include further information received from the PS domain, for example the expected time a congestion back off would stop. The MTC Server 170 may initiate a further trigger after the time out of this backoff period. Otherwise, the MSC/VLR 151 or SMS-SC 155 will deliver the device trigger message to the MTC Device 101 .

In the previous description, it was assumed that the device trigger message from MTC Server 170 is transported over the SMS-SC 155. However, in deployment of the MTC systems, there are other alternatives, for example where the device trigger message is delivered over an MTC Interworking Function (MTC IWF).

With reference to Figure 9, an example architecture of an embodiment of a basic network 900 that supports Machine Type

Communication (MTC) is shown. In this network 900, the MTC Server 970 communicates with the 3GPP Domain via a MTC IWF 955. The MTC IWF 955 translates and encapsulates the traffic from the MTC Server 970 into control plane messages and delivers it to the MTC Device 901 via either 3GPP CS domain 950 or 3GPP PS domain 930. For the CS domain transmission, the MTC IWF 955 transports the device trigger message to the MSC/VLR 951 via an interface 945. The MSC/VLR 951 transmits the device trigger message to the MTC Device 901 through GERAN 909.

For the PS domain transmission, the MTC IWF 955 has an interface 947 to the SGSN 935 and an interface 949 to the MME 931 , respectively. The device trigger message may be transmitted from the MTC IWF 955 to the SGSN 935 via interface 947 and to the MME 931 via interface 949 directly. The SGSN 935 and the MME 931 transmits the device trigger message to the MTC Device 901 through UTRAN 907 and EUTRAN 905 respectively.

The example procedures introduced in previous embodiments are still applicable, with the MTC IWF 955 replacing the SMS-SC 155 in the operation.

It is obvious to anyone skilled in the art after reviewing the disclosure that some of the signaling messages discussed in the above descriptions of embodiments could be changed with other signaling messages without affecting the general principles of the disclosure.

Embodiments of the present disclosure are, for example, applicable to the mobile communication networks that support the device trigger and congestion control mechanism for machine type communications, and thus have industrial applicability.

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 receiving an application layer trigger request from an application server to a mobile terminal sent over a first communication domain;

means for analyzing the application layer trigger request to determine whether the trigger request includes an indication to the mobile terminal to send a connection request to a second communication domain;

means for initiating inter-domain communication between the first communication domain and the second communication domain when the trigger request includes the indication to the mobile terminal to send a connection request to the second communication domain;

means for determining a congestion control status of the second communication domain; and

means for indicating to the application server that a congestion control policy of the second communication domain will block the connection request when the congestion control status indicates the congestion control policy will block the connection request.

2. The system of claim 1 wherein the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain.

3. The system of claim 1 wherein the system comprises a mobile terminal.

4. The system of claim 3 wherein when the means for determining a congestion control status determines a congestion control policy is in place, the mobile terminal is configured to determine whether to request overriding of the congestion control policy.

5. The system of claim 4 wherein the congestion control status indicates a backoff timer is running.

6. The system of claim 4 wherein the means for determining a congestion control status is configured to analyze a broadcast from the second communication domain.

7. The system of claim 4 wherein when the mobile terminal determines to request overriding of the congestion control policy, the means for initiating inter-domain communication is configured to send a request from the mobile terminal to override the congestion control policy to the second communication domain through the first communication domain.

8. The system of claim 3 wherein the means for initiating inter-domain communication is configured to send a request from the mobile terminal to override the congestion control policy to the second communication domain through the first communication domain based at least in part on whether the means for determining a congestion control status determines a congestion control policy is in place.

9. The system of claim 8 wherein the request from the mobile terminal to override the congestion control policy is sent via a control signal of the first communication domain.

10. The system of claim 8 wherein the request from the mobile terminal to override the congestion control policy is included in a short-message service (SMS) delivery report to the first communication domain.

1 1 . The system of claim 9 or 10 wherein when a response to the request to override is received by the mobile terminal, the mobile terminal is configured to generate a delivery report to the application server based on the response to the request to override.

12. The system of claim 10 wherein when a response to the request to override is received by the first communication domain, the first communication domain is configured to send a delivery report to the application server based on the response to the request to override.

13. The system of claim 8 wherein the first communication domain is configured to send a negotiation request to the second

communication domain in response to the request to override congestion control.

14. The system of claim 8 wherein the request to override includes information related to the congestion control policy to be overridden.

15. The system of claim 14 wherein the information related to the congestion control policy includes an identity of a Mobility Management Entity of the second communication domain.

16. The system of claim 14 wherein the request to override includes an indication of whether the mobile terminal will wait for a response to the request to override before sending the connection request to the second communication domain.

17. The system of claim 14 wherein the information related to the congestion control policy includes a value of a backoff timer.

18. The system of claim 3 wherein the mobile terminal is configured to, based at least in part on whether the means for determining congestion control status determines a congestion control policy is in place, send a negotiation notification to the first communication domain and the connection request to the second communication domain.

19. The system of claim 1 wherein the system includes at least part of the first communication domain and at least part of the second

communication domain, the at least part of first communication domain is configured to store information based on a negotiation notification received from the mobile terminal and the at least part of the second communication domain is configured to respond to a connection request from the mobile terminal by checking the stored information.

20. The system of claim 1 wherein the means for indicating to the application server that a congestion control policy of the second

communication domain will block the connection request is configured to:

when the congestion control status indicates the congestion control policy will block the connection request, provide the indication to the application server; and

when the congestion control status does not indicate the congestion control policy will block the connection request, forward the trigger request to the mobile terminal.

21 . The system of claim 20 wherein the indication to the application server includes an indication of a value of a congestion control timer.

22. A method, comprising:

analyzing, by one or more configured devices, an application layer trigger request from an application server addressed to a mobile terminal through a first communication domain;

initiating, by the one or more configured devices, inter-domain communication between the first communication domain and a second communication domain when the analysis indicates the trigger request includes an indication to the mobile terminal to send a connection request to the second communication domain;

determining, by the one or more configured devices, a congestion control status of the second communication domain; and

generating, by the one or more configured devices, an indication to the application server that a congestion control policy of the second communication domain will block the connection request when the determined congestion control status indicates the congestion control policy will block the connection request.

23. The method of claim 22 wherein the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain.

24. The method of claim 22 further comprising: determining whether to request overriding of the congestion control policy.

25. The method of claim 22 wherein the determining the congestion control status includes determining whether a backoff timer related to the mobile terminal is running.

26. The method of claim 22 wherein the determining a congestion control status includes analyzing a broadcast from the second communication domain.

27. The method of claim 22, further comprising: sending a request from the mobile terminal to override the congestion control policy of the second communication domain through the first communication domain.

28. The method of claim 27 wherein the request from the mobile terminal to override the congestion control policy is sent via a control signal of the first communication domain.

29. The method of claim 27 wherein the request from the mobile terminal to override the congestion control policy is included in a short- message service (SMS) delivery report to the first communication domain.

30. The method of claim 27, further comprising: generating a delivery report to the application server based on a response to the request to override.

31 . The method of claim 27, further comprising: sending a negotiation request from the first communication domain to the second communication domain in response to the request to override congestion control.

32. The method of claim 27 wherein the request to override includes information related to the congestion control policy to be overridden.

33. The method of claim 32 wherein the information related to the congestion control policy includes an identity of a Mobility Management Entity of the second communication domain.

34. The method of claim 27 wherein the request to override includes an indication of whether the mobile terminal will wait for a response to the request to override before sending the connection request to the second communication domain.

35. The method of claim 32 wherein the information related to the congestion control policy includes a value of a backoff timer.

36. The method of claim 24, further comprising:

sending a negotiation notification from the mobile terminal to the first communication domain; and

sending the connection request from the mobile terminal to the second communication domain.

37. The method of claim 36, further comprising: storing information in the first communication domain based on the negotiation notification; and

responding to the connection request from the mobile terminal by checking the stored information.

38. The method of claim 22, further comprising: when the congestion control status does not indicate the congestion control policy will block the connection request, forwarding the trigger request to the mobile terminal.

39. The method of claim 22 wherein the indication to the application server includes an indication of a value of a congestion control timer.

40. A non-transitory computer-readable medium whose contents configure one or more processing devices to perform a method according to any of claims 22 through 39.

41 . A mobile terminal, comprising:

one or more processors; and

one or more modules that are configured to, when executed by at least one of the one or more processors, respond to a device trigger message received in a first communication domain by: determining whether the trigger message includes an indication to establish a communication session in a second communication domain; and

when it is determined the trigger message includes an indication to establish a communication session in the second communication domain, determining whether to request an override of congestion control of the second communication domain.

42. The mobile terminal of claim 41 wherein the determining whether to request an override of the congestion control includes determining whether a congestion control policy is activated.

43. The mobile terminal of claim 42 wherein the determining whether a congestion control policy is activated comprises determining whether a backoff timer is running.

44. The mobile terminal of claim 42 wherein the determining whether a congestion control policy is activated comprises analyzing a broadcast of the second communication domain.

45. The mobile terminal of claim 41 wherein the determining whether to request an override of the congestion control is based on at least one of: whether a congestion control policy is activated; information in the device trigger message; a configuration of the mobile terminal; subscription data; and an indication of whether an activated congestion control policy is allowed to be overridden.

46. The mobile terminal of claim 41 wherein the responding to the device trigger message includes, when it is determined to request the override of congestion control, requesting the override through the first communication domain.

47. The mobile terminal of claim 46 wherein the override is requested through a control signal in the first communication domain.

48. The mobile terminal of claim 41 wherein the responding to the device trigger message includes, when it is determined to request the override of congestion control, responding to an answer to the request to override by generating a delivery report to an application server associated with the device trigger message.

49. The mobile terminal of claim 46 wherein the override is requested in a short-messaging service (SMS) delivery report.

50. The mobile terminal of claim 49 wherein the mobile terminal is configured to respond to an answer to the request to override by generating an SMS delivery report to an application server associated with the device trigger message.

51 . The mobile terminal of claim 49 wherein the SMS delivery report includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a communication session in the second communication domain; and a value of a backoff timer.

52. The mobile terminal of claim 41 wherein the responding to the device trigger message includes, when it is determined to request the override of congestion control:

providing a override request notification to the first communication domain; and

requesting the override of congestion control from the second communication domain.

53. The mobile terminal of claim 52 wherein the override request notification includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a communication session in the second communication domain; and a value of a backoff timer.

54. The mobile terminal of claim 52 wherein the override request notification includes an identity of a Mobility Management Entity of the second communication domain.

55. The mobile terminal of claim 41 wherein the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain.

56. A method, comprising:

determining, by one or more configured processing devices, whether a trigger message addressed in a first communication domain to a mobile terminal includes an indication to the mobile terminal to establish a communication session in a second communication domain; and

when it is determined the trigger message includes an indication to establish a communication session in the second communication domain, determining, by the one or more configured processing devices, whether to request an override of congestion control of the second communication domain.

57. The method of claim 56 wherein the determining whether to request an override of the congestion control includes determining whether a congestion control policy is activated.

58. The method of claim 57 wherein the determining whether a congestion control policy is activated comprises determining whether a backoff timer is running.

59. The method of claim 57 wherein the determining whether a congestion control policy is activated comprises analyzing a broadcast of the second communication domain.

60. The method of claim 56 wherein the determining whether to request an override of the congestion control is based on at least one of: whether a congestion control policy is activated; information in the device trigger message; a configuration of the mobile terminal; subscription data; and an indication of whether an activated congestion control policy is allowed to be overridden.

61 . The method of claim 56, further comprising: requesting an override of congestion control.

62. The method of claim 61 wherein the override is requested through a control signal in the first communication domain.

63. The method of claim 61 , further comprising: responding to an answer to the request to override by generating a delivery report to an application server associated with the device trigger message.

64. The method of claim 61 wherein the override is requested in a short-messaging service (SMS) delivery report.

65. The method of claim 64, further comprising: responding to an answer to the request to override by generating an SMS delivery report to an application server associated with the device trigger message.

66. The method of claim 64 wherein the SMS delivery report includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a communication session in the second communication domain; and a value of a backoff timer.

67. The method of claim 56, further comprising: providing a override request notification to the first communication domain; and

requesting an override of congestion control from the second communication domain.

68. The method of claim 67 wherein the override request notification includes at least one of: information related to the requested override; an indication of whether the mobile terminal will wait for a response to the override request before attempting to establish a communication session in the second communication domain; and a value of a backoff timer.

69. The method of claim 56 wherein the first communication domain is a circuit switching (CS) domain and the second communication domain is a packet switching (PS) domain.

70. A non-transitory computer-readable medium whose contents configure one or more processing devices to perform a method according to any of claims 56 through 69.

71 . A mobile terminal, comprising:

means for determining whether a trigger message addressed in a first communication domain to a mobile terminal includes an indication to the mobile terminal to establish a communication session in a second

communication domain; and means for determining, when it is determined the trigger message includes an indication to establish a communication session in the second communication domain, whether to request an override of congestion control of the second communication domain.

72. The mobile terminal of claim 71 , further comprising:

means for requesting the override of congestion control.

73. A system, comprising:

one or more processors; and

one or more modules configured to, when executed by at least one of the one or more processors, manage a first communication domain by:

selectively activating congestion control; and

responding to a request, from a mobile terminal device subject to an activated congestion control policy, to establish a communication session in the first communication domain by:

determining whether there is a valid device trigger associated with a second communication domain and with the request from the mobile terminal device; and

when it is determined there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device, selectively overriding the activated congestion control policy.

74. The system of claim 73 wherein the managing the first communication domain includes:

responding to a communication related to a device trigger associated with the second communication domain by:

determining whether overriding of the activated congestion control policy may be permitted; and providing an indication of whether overriding of the activated congestion control policy may be permitted.

75. The system of claim 74 wherein the communication is received from at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device; and a Machine-Type-Communication Internetworking Device (MTC IWF).

76. The system of claim 73 wherein the managing the first communication domain includes:

storing information related to valid device triggers associated with the second communication domain, wherein the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with the stored information.

77. The system of claim 73 wherein the first communication domain is a packet switching (PS) domain and the second communication domain is a circuit switching domain (CS).

78. The system of claim 73 wherein the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with information stored on at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second

communication domain; a short-message service (SMS) device coupled to the second communication domain; and a Machine-Type-Communication

Internetworking Device (MTC IWF) coupled to the second communication domain.

79. A method, comprising:

selectively activating, by one or more configured devices, congestion control in a first communication domain; and

responding, by the one or more configured devices, to a request, from a mobile terminal device subject to an activated congestion control policy of the first communication domain, to establish a communication session in the first communication domain by:

80. The method of claim 79, further comprising: responding to a communication related to a device trigger associated with the second communication domain by:

determining whether overriding of the activated congestion control policy may be permitted; and

providing an indication of whether overriding of the activated congestion control policy may be permitted.

81 . The method of claim 80 wherein the communication is received from at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device; and a Machine-Type-Communication Internetworking Device (MTC IWF).

The method of claim 79, further comprising storing information related to valid device triggers associated with the second communication domain, wherein the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with the stored information.

83. The method of claim 79 wherein the first communication domain is a packet switching (PS) domain and the second communication domain is a circuit switching domain (CS).

84. The method of claim 79 wherein the determining whether there is a valid device trigger associated with the second communication domain and with the request from the mobile terminal device includes comparing the request with information stored on at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the second

Internetworking Device (MTC IWF) coupled to the second communication domain.

85. A non-transitory computer-readable medium whose contents configure one or more processing devices to perform a method according to any of claims 79 through 84.

86. A networking device, comprising:

means for selectively activating congestion control in a first communication domain; and

means for responding to a request, from a mobile terminal device subject to an activated congestion control policy of the first communication domain, to establish a communication session in the first communication domain by: determining whether there is a valid device trigger associated with a second communication domain and with the request from the mobile terminal device; and

87. The device of claim 86, further comprising:

means for responding to a communication related to a device trigger associated with the second communication domain by:

88. The device of claim 86, further comprising:

means for storing information related to valid device triggers associated with the second communication domain, wherein means the for responding to the request is configured to compare information included in the request with the stored information.

89. The device of claim 86 wherein the means for responding to the request is configured to compare information included in the request with information stored on at least one of: a Mobile Switching CenterA/isitor Location Register (MSCA/LR) of the second communication domain; a short-message service (SMS) device coupled to the second communication domain; and a Machine-Type-Communication Internetworking Device (MTC IWF) coupled to the second communication domain.

90. A system, comprising:

one or more processors; and

one or more modules configured to, when executed by at least one of the one or more processors, manage communications in a first communication domain by,

processing a device trigger message addressed to a mobile device through the first communication domain, the device trigger message including an indication to the mobile device to establish a

communication session in a second communication domain with an application server; and

selectively engaging in at least one communication with the second communication domain related to the device trigger message.

91 . The system of claim 90 wherein the processing the device trigger message comprises analyzing the device trigger message to determine whether the device trigger message includes an indication to the mobile device to establish a communication session in a second communication domain.

92. The system of claim 91 wherein when it is determined the device trigger message includes an indication to the mobile device to establish a communication session in the second communication domain, the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises obtaining information related to a congestion control status of the second communication domain from the second communication domain.

93. The system of claim 92 wherein when the obtained information related to the congestion control status of the second

communication domain indicates a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message comprises not delivering the device trigger message to the mobile device.

94. The system of claim 93 wherein when the obtained information related to the congestion control status of the second

communication domain indicates a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message further comprises providing the application server with an indication of a failure of the device trigger message.

95. The system of claim 94 wherein the obtained information includes an indication of a backoff timer value and the indication of the failure of the device trigger message include an indication of the backoff timer value.

96. The system of claim 92 wherein when the obtained information related to the congestion control status of the second

communication domain does not indicate a request from the mobile device to establish a communication session with the second communication domain may be blocked, the processing the device trigger message further comprises forwarding the device trigger message to the mobile device.

97. The system of claim 96 wherein the forwarding the device trigger message to the mobile device comprises delivering the device trigger message to a network of the first communication domain.

98. The system of claim 96 wherein the forwarding the device trigger message comprises delivering the device trigger message to the mobile device.

99. The system of claim 90 wherein the processing the device trigger message comprises forwarding the device trigger message and the one or more processing devices are further configured to respond to a negotiation notification of the mobile terminal by storing information related to the device trigger message.

100. The system of claim 99 wherein the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises responding to a communication from the second communication domain based on the stored information related to the device trigger message.

101 . The system of claim 99 wherein the one or more

processing devices are further configured to send a device trigger report to the application server.

102. The system of claim 90 wherein the processing the device trigger message comprises forwarding the device trigger message and the managing communications in the first communication domain comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain.

103. The system of claim 102 wherein the responding to the request from the mobile device to override the congestion control policy comprises denying the request to override the congestion control policy.

104. The system of claim 102 wherein the responding to the request from the mobile device to override the congestion control policy comprises generating a report to the application server.

105. The system of claim 90 wherein the processing the device trigger message comprises forwarding the device trigger message and the selectively engaging in the at least one communication with the second communication domain comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain by initiating an inter-domain communication between the first and second communication domains.

106. The system of claim 105 wherein the inter-domain communication is a request to override the congestion control policy transmitted to the second communication domain.

107. The system of claim 105 wherein when the second communication domain denies the request, the one or more processors are configured to provide an indication of a failure related to the device trigger message to the application server.

108. The system of claim 107 wherein the indication includes an indication of when a backoff timer related to the mobile device will expire.

109. The system of claim 90 wherein the one or more

processors comprise at least one processor of at least one of: a Mobile

Switching Center/Visitor Location Register (MSCA/LR) of the first

communication domain; a short-message service (SMS) device coupled to the first and second communication domains; and a Machine-Type-Communication Internetworking Device (MTC IWF) coupled to the first and second

communication domains.

1 10. A method, comprising:

processing, by one or more configured devices, a device trigger message addressed to a mobile device through a first communication domain, the device trigger message including an indication to the mobile device to establish a communication session in a second communication domain with an application server; and

selectively engaging, by the one or more configured devices, in at least one communication with the second communication domain related to the device trigger message.

1 1 1 . The method claim 1 10 wherein the processing the device trigger message comprises analyzing the device trigger message to determine whether the device trigger message includes an indication to the mobile device to establish a communication session in a second communication domain.

1 12. The method of claim 1 1 1 wherein when it is determined the device trigger message includes an indication to the mobile device to establish a communication session in the second communication domain, the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises obtaining information related to a congestion control status of the second communication domain from the second communication domain.

1 13. The method of claim 1 12 wherein when the obtained information related to the congestion control status of the second

1 14. The method of claim 1 13 wherein when the obtained information related to the congestion control status of the second

1 15. The method of claim 1 14 wherein the obtained information includes an indication of a backoff timer value and the indication of the failure of the device trigger message include an indication of the backoff timer value.

1 16. The method of claim 1 12 wherein when the obtained information related to the congestion control status of the second

1 17. The method of claim 1 16 wherein the forwarding the device trigger message to the mobile device comprises delivering the device trigger message to a network of the first communication domain.

1 18. The method of claim 1 16 wherein the forwarding the device trigger message comprises delivering the device trigger message to the mobile device.

1 19. The method of claim 1 10 wherein the processing the device trigger message comprises forwarding the device trigger message and the method comprises responding to a negotiation notification of the mobile terminal by storing information related to the device trigger message.

120. The method of claim 1 19 wherein the selectively engaging in at least one communication with the second communication domain related to the device trigger message comprises responding to a communication from the second communication domain based on the stored information related to the device trigger message.

121 . The method of claim 1 19, comprising sending a device trigger report to the application server.

122. The method of claim 1 10 wherein the processing the device trigger message comprises forwarding the device trigger message and the method comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain.

123. The method of claim 122 wherein the responding to the request from the mobile device to override the congestion control policy comprises determining whether to deny the request to override the congestion control policy.

124. The method of claim 122 wherein the responding to the request from the mobile device to override the congestion control policy comprises generating a report to the application server.

125. The method of claim 1 10 wherein the processing the device trigger message comprises forwarding the device trigger message and the selectively engaging in the at least one communication with the second communication domain comprises responding to a request from the mobile device to override a congestion control policy of the second communication domain by initiating an inter-domain communication between the first and second communication domains.

126. The method of claim 125 wherein the inter-domain communication is a request to override the congestion control policy transmitted to the second communication domain.

127. The method of claim 125, comprising responding to a denial of the request by the second communication domain by providing an indication of a failure related to the device trigger message to the application server.

128. The method of claim 127 wherein the indication includes an indication of when a backoff timer related to the mobile device will expire.

129. The method of claim 1 10 wherein the one or more configured devices includes at least one of: a Mobile Switching Center/Visitor Location Register (MSCA/LR) of the first communication domain; a short- message service (SMS) device coupled to the first and second communication domains; and a Machine-Type-Communication Internetworking Device (MTC IWF) coupled to the first and second communication domains.

130. A non-transitory computer-readable medium whose contents configure one or more processing devices to perform a method according to any of claims 90 through 129.

131 . A networking device, comprising:

means for processing a device trigger message addressed to a mobile device through a first communication domain, the device trigger message including an indication to the mobile device to establish a

means for engaging in at least one communication with the second communication domain related to the device trigger message.

132. The networking device of claim 131 wherein the means for processing is configured to analyzing the device trigger message to determine whether the device trigger message includes an indication to the mobile device to establish a communication session in a second communication domain.

133. The networking device of claim 131 , further comprising means for responding to a negotiation notification from the mobile terminal.

134. The networking device of claim 131 wherein the means for engaging is configured to respond to a request from the mobile device to override a congestion control policy of the second communication domain.

135. A system, comprising:

a mobile terminal;

an application layer server configured to request a new connection from the mobile terminal via a device trigger message; and

a network control entity configured to deliver the device trigger message through one of two independent communication domains, wherein the mobile terminal is configured to determine whether the requested new connection is a connection in the other communication domain, and when it is determined that the requested new connection in a connection in the other communication domain, trigger an inter-domain communication related to the new connection.

136. The system of claim 135 wherein the mobile terminal is configured to request the first domain to negotiate with the second domain regarding the requested new connection.

137. The system of claim 136 wherein the mobile terminal is configured to provide an indication of a failure of the new connection to the application layer server when the second domain indicates a connection request from the mobile terminal will be blocked.

138. The system of claim 135 wherein the network control entity is configured to perform an inter-domain negotiation.

139. The system of claim 138 wherein the network control entity is configured to determine whether to initiate an inter domain negotiation in response to a request from the mobile terminal.

140. The system of claim 139 wherein the network control entity is configured to provide an indication to the mobile terminal and to the application layer server of a negotiation result.

141 . The system of any of claims 1 , 90, 1 10 and 135, wherein the application server is a machine type communication server.