US20130268604A1

US20130268604A1 - Short message service (sms) communication in wireless networks in the packet switched domain

Info

Publication number: US20130268604A1
Application number: US13/631,044
Authority: US
Inventors: Vivek Gupta; Puneet K. Jain
Original assignee: Individual
Current assignee: Intel Corp
Priority date: 2012-04-09
Filing date: 2012-09-28
Publication date: 2013-10-10
Also published as: WO2013155057A1; CN104221410A; CN104365037B; EP2837106A4; US20130265945A1; US9712302B2; US9078109B2; EP2837217A1; EP2837106A1; EP2837217A4; WO2013155071A1; CN104365037A; US20150263839A1; CN104221410B

Abstract

Technology for communicating a short message service (SMS) communication in a packet switched (PS) domain of an evolved packet system (EPS) network. One method comprises receiving, at a core network (CN) control node, a request message from a user equipment (UE) indicating that the UE supports PS based SMS and performs a circuit switched (CS) registration only to receive SMS service via a CS domain; and sending, from the CN control node, an accept message to the UE indicating that SMS over a non-access stratum (NAS) is supported by the CN control node.

Description

RELATED APPLICATIONS

This application claims the benefit of and hereby incorporates by reference U.S. Provisional Patent Application Ser. No. 61/621,939, filed Apr. 9, 2012, with an attorney docket number of P44666Z.

BACKGROUND

As the use of mobile wireless devices, such as smart phones and tablet devices, becomes more ubiquitous, the demands on the limited amount of radio frequency spectrum used by those devices also increases, resulting in wireless network congestion in the licensed spectrum. In addition, the increased use of high bandwidth applications such as audio and video streaming can increase demands beyond the capability of the available spectrum. This is especially true in high density and high use locations such as large cities and universities. One projection estimates a growth of 20 times in mobile internet traffic from 2010 to 2015.
Improvements in wireless architectures, hardware design, and processor speed have significantly increased the efficiency of wireless devices in their use of the available spectrum. However, certain legacy aspects from previous generations of wireless network specifications continue to reduce the potential efficiency of modern wireless architectures.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the invention will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the invention; and, wherein:

FIG. 1 illustrates an example of a General Packet Radio Service (GPRS) Logical Architecture when based on the S4, S5, and S8 interfaces;

FIG. 2 illustrates an a Mobility Management Entity (MME) architecture configured to provide packet switched (PS) Short Message Service (SMS) communications in accordance with an example;

FIG. 3 illustrates an example of an Attach Request message illustrated in a table format;

FIG. 4 illustrates an EPS mobility management (EMM) message information element that includes a new cause message in accordance with an example;

FIG. 5 depicts a flow chart of a method for communicating a short message service (SMS) communications in a packet switched (PS) domain of an evolved packet system (EPS) network in accordance with an example;

FIG. 6 depicts a flow chart of a method for adapting a wireless network for packet switched communication of a short message service message in accordance with an example; and

FIG. 7 illustrates a mobile wireless device in accordance with an example.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.

DETAILED DESCRIPTION

Before the present invention is disclosed and described, it is to be understood that this invention is not limited to the particular structures, process steps, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular embodiments only and is not intended to be limiting.

DEFINITIONS

As used herein, the term “substantially” refers to the complete or nearly complete extent or degree of an action, characteristic, property, state, structure, item, or result. For example, an object that is “substantially” enclosed would mean that the object is either completely enclosed or nearly completely enclosed. The exact allowable degree of deviation from absolute completeness may in some cases depend on the specific context. However, generally speaking the nearness of completion will be so as to have the same overall result as if absolute and total completion were obtained. The use of “substantially” is equally applicable when used in a negative connotation to refer to the complete or near complete lack of an action, characteristic, property, state, structure, item, or result.
As used herein, the term “Core Network (CN) control node” is a generic term that refers to either a Mobility Management Entity (MME) or a Serving GPRS (General Packet Radio Service) Support Node (SGSN).
As used herein, the term User Equipment (UE) refers to a wireless device configured to communicate with a Third Generation Partnership Project (3GPP) wireless network.
As used herein, the term mobile station (MS) refers to a wireless device configured to communicate with a Third Generation Partnership Project (3GPP) wireless network. The terms UE and MS are considered to be synonymous and may be used interchangeably throughout this document, unless otherwise noted.
Additional definitions may be provided in the proceeding paragraphs in the example embodiments.

Example EMBODIMENTS

An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is intended to aid readers in understanding the technology more quickly but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.
An exponential increase in the amount of wireless data transmission has created congestion in wireless networks using licensed spectrum to provide wireless communication services for wireless devices such as smart phones and tablet devices, to name a few. The congestion is especially apparent in high density and high use locations such as urban locations and universities.
One technique for providing additional bandwidth capacity to wireless devices is through the transformation of wireless networks from circuit switching to packet switching. In circuit switching, wireless communication involves using a limited number of dedicated connections that typically have a constant bit rate and a constant delay between the wireless nodes. These dedicated connections may be open even if no data is being transmitted by a wireless device. This can lead to inefficiencies in the use of radio frequency spectrum.
In contrast with circuit switching, packet switching involves grouping data that is to be transmitted, regardless of the data's content, type, or structure, into blocks referred to as packets. Packet switching provides the ability to deliver variable bit rate data streams over a shared network. Packets can be buffered or queued at network adapters, switches, routers, or other network nodes, thereby enabling packets to be delivered with variable delay and throughput depending on the traffic load in the network. The use of packet switching improves the ability of a wireless network to provide a desired Quality of Service (QoS) in a wireless network. In addition, the use of packet switching can significantly improve the efficiency in which data is transmitted, resulting in lower costs for consumers and more efficient use of the crowded radio frequency spectrum.
As wireless communication standards have continued to develop, the use of packet switching has become more and more prevalent. However, certain legacies from earlier standards still remain in even the most modern wireless communication standards. One such legacy is the use of circuit switching to communicate Short Message Service (SMS) communications between wireless devices configured to operate with the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) specification.
Short Message Service communications, which are typically referred to as “text messaging” is a communications protocol that enables the interchange of a text message of up to 160 characters in length between mobile devices. Messages are sent to a Short Message Service Centre (SMSC) where they can be stored until the destination wireless device is active. Once the destination wireless device is connected to a wireless network, the SMS message can be communicated from the SMSC to the wireless device.
Releases 8, 9, 10 and 11 (Stage 2 freeze in September, 2012) of the 3GPP LTE specification still use circuit switching (CS) to provide SMS communications. The communication of SMS is one of the last vestiges of CS in the 3GPP network. In order to provide SMS communication using CS, a user equipment (UE) typically has to connect with a Mobile Switching Center (MSC). The MSC provides an interface between the radio system and the fixed networks. The MSC can perform desired functions in order to provide CS services to and from the UE. Thus, user equipment (UEs) often connect with an MSC. This connection can result in excessive overhead, as well as the use of unnecessary dedicated wireless connections.
To overcome this limitation, the advent of SMS communication using packet switching (PS) in the 3GPP network can be implemented. The implementation of PS based SMS can be accomplished in different ways depending on the age and/or architecture of the wireless network.
Modern 3GPP LTE based networks can implement PS based SMS communication using the network's Mobility Management Entity (MME). The MME is the control node that processes the signaling between the UE and the Core Network (CN). The MME can provide Visitor Location Register (VLR) functionality for an Evolved Packet System (EPS). This will be discussed more fully in the proceeding paragraphs.
Older wireless networks can include an assortment of old and new wireless networking equipment. The wireless networking equipment is often generally referred to based on the “generation” to which the equipment belongs, according to the equipment's age and capabilities. For example, wireless networking equipment may be designated based on the “generation” to which the equipment belongs, such as 2G, 2.5G, 3G, or 4G. Networks that include an assortment of different generations can include a Serving GPRS (General Packet Radio Service) Support Node (SGSN).
GPRS is a mobile data service extension to the Global System for Mobile communications (GSM). GSM is a 2G system. GPRS is often described as a 2.5G system. The SGSN acts as the control node, similar to the MME in 4G systems. The SGSN is the interface between the radio system and the fixed network for Packet Switched (PS) services. The SGSN can perform the functions to handle packet transmission to and from the UE. The SGSN can be used to provide PS based SMS, thereby eliminating the need for a UE to connect to an MSC merely for SMS communication in a 2.5G or 3G wireless network.
A discussion of the SMS in SGSN architecture for SMS services will be described below. Messaging used between the UE and the SGSN to implement the SMS in SGSN architecture will be provided. A discussion of the SMS in MME architecture will follow.
FIG. 1 provides an example of a GPRS Logical Architecture when based on S4/S5/S8 interfaces. The architecture is described in the 3GPP Technical Specification (TS) 23.060. One example is provided in 3GPP TS 23.060 V11.1.0 (2012-03).
A GPRS Support Node (GSN) contains functionality used to support GPRS functionality for the GSM/EDGE Radio Access Network (GERAN) and/or the Universal Terrestrial Radio Access Network (UTRAN). In one Public Land Mobile Network (PLMN), there may be more than one GSN.
The SGSN and Gateway GPRS Support Node (GGSN) functionalities may be combined in the same physical node, or they may reside in different physical nodes. The SGSN and the GGSN contain Internet Protocol (IP) or other (i.e. Asynchronous Transfer Mode (ATM)) routing functionality. The SGSN and GGSN may be interconnected with IP routers.
The Gateway GPRS Support Node (GGSN) is the node that is accessed by the packet data network (PDN) after evaluation of the Packet Data Protocol (PDP) address. The GGSN contains routing information for PS-attached users. The routing information is used to tunnel N protocol data units (PDUs) to the UE's current point of attachment, i.e. the Serving GPRS Support Node. The GGSN may request location information from the Home Location Register (HLR) via the optional Gc interface. The GGSN is the first point of PDN interconnection with a PLMN supporting GPRS (i.e. the Gi reference point is supported by the GGSN). GGSN functionality is common for all types of RANs.
The Serving GPRS Support Node (SGSN) is the node that is serving the UE (i.e. mobile station (MS)). The SGSN supports GPRS for A/Gb mode (i.e. the Gb interface is supported by the SGSN) and/or lu-mode (i.e. the lu interface is supported by the SGSN). At PS attach, the SGSN establishes a mobility management context containing information pertaining to e.g. mobility and security for the MS. At PDP Context Activation, the SGSN establishes a PDP context, to be used for routing purposes, with the GGSN that the subscriber will be using. In lu mode, the SGSN and RNC may be interconnected with one or more IP routers.
In Gn/Gp mode and when the SGSN and the GGSN are in different PLMNs, they are interconnected via the Gp interface. The Gp interface provides the functionality of the Gn interface, plus security functionality required for inter-PLMN communication. The security functionality is based on mutual agreements between operators.
In Gn/Gp mode, the SGSN interworks signaling on the Gn/Gp interface with lu/Gb interface signaling. In S4 mode, the SGSN interworks signaling on the S4 interface with lu/Gb interface signaling. One SGSN may have some UEs using Gn/Gp mode and other UEs using S4 mode.
The SGSN may send location information to the MSC/VLR via the optional Gs interface. The SGSN may receive paging requests from the MSC/VLR via the Gs interface.
The SGs interface can connect databases in the VLR and the MME. The SGs is also used to convey some circuit switched related procedures via the MME. The basis for the interworking between a VLR and an MME is the existence of an SGs association between those entities per UE. The SGs association is applicable to UEs which are configured to use CS fallback and SMS ove SGs, or SMS over SGs only. The SGs association is not applicable if the subscriber data indicates that the subscription is for packet switched (PS) communication only. The SGs association is also not applicable if the Home Subscriber Server (HSS) signals “SMS in MME Support” capability and the MME determines that SMS service is to be provided using the SMS in MME feature.
The SGSN interfaces with the GSM-SCF for optional Customized Application for Mobile Enhanced network Logic (CAMEL) control using the Ge reference point. Depending on the result from the CAMEL interaction, the session and packet data transfer may proceed normally. Otherwise, interaction with the GSM-SCF continues as described in TS 23.078.
The functionality of the Serving Gateway is defined in 3GPP TS 23.401 with the following additions and exceptions: The Serving Gateway can terminate the user plane interface towards the UTRAN when the Direct Tunnel feature is in use. The Serving Gateway is the local Mobility Anchor point for the Serving Radio Network Subsystem (SRNS) relocation when the Direct Tunnel feature is in use. The Serving Gateway can also be the local Mobility Anchor for an inter-SGSN routing area update.

SMS in SGSN Architecture

In accordance with one embodiment of the present invention, the SMS in SGSN can be performed as follows. An indication can be added where the SGSN indicates to the Home Subscriber Server (HSS) in the Attach/Routing Area Update (RAU) procedures that it offers SMS in SGSN using the Gd. Subscription data information can be added for “PS-and-SMS-only” subscriptions. The SGSN identity can be registered for terminating SMS services. When this occurs, the HLR, operating on the HSS, can cancel any registered MSC. These operations align the behavior of the HLR/HSS for SGSN and MME. The handshaking of SMS support between the HSS and the SGSN (in both directions) can be based on existing Teleservice List parameters in the Gr MAP and S6d Diameter protocols. The Inter-SGSN RAU procedure can be updated to provide the same support for “SMS in SGSN” as the combined Attach/RAU procedures. A clarification about the “SMS-Supported” indication to the MS can be added in the GPRS Attach Procedure.
The SGSN can indicate that it offers SMS services via the PS domain (i.e. Gd) to the HSS by an indication “SMS in SGSN offered” in the signaling with the HSS during the Attach/RAU procedure. When the subscription information indicates “PS and SMS only” the HSS can respond to queries from SMS-GMSCs and SMS routers so that Mobile Terminated (MT) SMS gets routed to serving nodes in the PS domain when SMS via the PS domain are offered by these serving nodes.
A CS/PS enabled UE that needs only PS domain services and SMS services over a Non Access Stratum (NAS) layer indicates this capability as “SMS-only” to the SGSN during combined Attach/RAU procedures, i.e. the included CS registration is only requested for obtaining SMS services over NAS. Based on the UE provided information (i.e. the SMS-only indication to the SGSN) and when the HSS provided subscription information indicates “SMS in SGSN Support” and the SGSN supports SMS services over NAS, the SGSN can then determine to not establish an association with an MSC when requested by the UE in the combined Attach/RAU procedures.
The SGSN can forward the capability indicated by the UE as an “SMS-only” indication in the Location Update procedure to the HSS. If the HSS has an old serving MSC registered, the HSS can cancel the serving MSC for a UE that indicates “SMS-only” and subscribes to SMS services if both the SGSN and the HSS supports SMS in SGSN (i.e. the SGSN has indicated “SMS in SGSN offered” and the HSS supports SMS in SGSN). As only the SGSN is registered for MT SMS, the HSS can then respond to queries from SMS-GMSCs and SMS routers so that MT SMS is routed to serving node(s) in the PS domain.

SMS in MME Architecture

FIG. 2 provides an illustration of an MME architecture configured to provide PS based SMS services. The MME is in communication with the HSS via an S6a interface, which is a Diameter based interface that is enhanced with SMS support. A new direct “E” interface exists between the MME and SMS central functions, such as SMS router, SMS-Gateway Mobile Switching Center (GMSC) and SMS-Inter Working Mobile Switching Center (IWMSC). The E interface can be either a MAP or Diameter based protocol.
Mobile Application Part (MAP) is an SS7 protocol which provides an application layer for the various nodes in GSM and UMTS mobile core networks and GPRS core networks to communicate with each other in order to provide services to mobile phone users. The Mobile Application Part is the application-layer protocol used to access the Home Location Register, Visitor Location Register, Mobile Switching Center, Equipment Identity Register, Authentication Centre, Short message service center and Serving GPRS Support Node (SGSN).
The SGs interface can be used to relay SMS messages between the MME and VLR. The SMS-Switching Center (SC) may be integrated with the SMS-GMSC/SMS_IWMSC. The interface between the HSS and SMS central functions (SMS_IWMSC and SMS-GMSC, SMS-router) can be Diameter or a MAP C interface. There is a Diameter E interface between the MME and SMS central functions.
The use of the SMS in MME architecture is for SMS services only. This functionality may not trigger any CS fallback and does not require an SGs. In addition, to provide SMS In MME, the MME can be configured to provide the following: SMS procedures between the UE and the MME can include support for the Short Message Control (SMC) and Short Message Relay (SMR) functions.
In one embodiment, the MME can be configured to support the combined EPS/IMSI procedures for “SMS-only” and in these: provide a non-broadcasted Location Area Identity (LAI) that is not associated with any Visitor Location Register (VLR). If needed, the MME can provide a reserved TMSI that is configured such that it cannot cause any ambiguities with other TMSIs. For instance, when the UE changes to an area where it needs to derive SMS services from a GERAN/UTRAN MSC. The MME can indicate in the Attach/TAU Accept message that the IMSI attach is for “SMS-only”. The MME can notify the HSS that it is capable of SMS transfer without the need of establishing an SGs association with an MSC. The MME can obtain SMS related subscription information.
If the UE performs a combined attach/TAU with “SMS-only” indication, the MME can forward the “SMS-only” indication in the location update procedure to the HSS. The HSS can allow an operator to configure a subscription that is limited to only PS services and SMS services. This limitation is indicated in the PS subscription data as “PS and SMS only”.
In order to setup a 3GPP LTE EPS to provide PS based SMS, a UE can indicate its request for SMS services to the MME. This can involve sending a message that the UE only request CS registration to receive SMS services, but is capable of supporting PS based SMS. One way of communicating this message from the UE to the MME is by altering an Attach Request message. The Attach Request message is defined in 3GPP TS 24.301. One example is shown in 3GPP TS 24.301 V11.3.0 (2012-06).
The Attach Request message is sent by the UE to the network in order to perform an attach procedure with the network. An example of an Attach Request message is illustrated in FIG. 3 in a table format. The table includes information including the Information Element Identifier (IEI), the name of the Information Element (IE), the type of IE and a reference to the IE in the 3GPP TS 24.301, along with the presence, format, and length of each IE in the Attach Request message.
In accordance with one embodiment, the UE shall include an additional IE in the Attach Request message if the UE requests “SMS only” or if the UE supports PS based SMS and does CS registration only to receive SMS service via the CS domain. Several different types of IE can be used to communicate this message from the UE to the MME. Five different examples are provided herein. These examples are not intended to be limiting. Any means may be used to communicate this message from the UE to the MME. The examples below are labeled Solution A through Solution E.

Solution A

In this solution, a new IE Additional Update Type is added to the Attach Request message. The format of the Additional Update Type IE is provided in the proceeding paragraphs.
The purpose of the additional update type IE is to provide additional information about the type of request for a combined attach (i.e. an Attach/RAU procedure) or a combined tracking area updating procedure. The Additional Update Type IE can be coded as shown in Table 1 and Table 2.

TABLE 1

Additional Update Type information element

TABLE 2

Additional Update Type information element

Additional update type value (AUTV) (octet 1)

Bit
1

0	No additional information. If received it shall be interpreted as
	request for combined attach or combined tracking
	area updating.
1	SMS only

PS SMS Support (PSSS) (octet 1)

Bit
2

0	UE does not support PS based SMS
1	UE supports PS based SMS and does CS registration only to
	receive SMS service via CS domain

Bits
4 to 3 of octet 1 are spare and shall be all coded as zero.

As shown in Table 2 above, Bit 2 in octet 1 can be a PS based SMS Support (PSSS) message. In this example, a Bit value of 0 provides the message that the UE does not support PS based SMS. A Bit value of 1 provides the message that the UE supports PS based SMS and does CS registration only to receive SMS service via the CS domain. The IE illustrated in Table 1 and 2 can be included in the Attach Request message shown in FIG. 3.

Solution B

In this solution one spare bit of the MS Network Feature Support IE of the Attach Request message is used to indicate a UE PS-only capability to the network; i.e. that the UE intent to request CS registration only for obtaining SMS services, but is capable of PS based SMS.
In accordance with one embodiment, the MS Network Feature Support IE, which is defined in section 9.9.3.20A of 3GPP TS 24.301 and section 10.5.1.15 of 3GPP TS 24.008, can be configured to include a PS based SMS Support message, as follows. One example of the 3GPP TS 24.008 is TS 24.008 V11.3.0 (2012-06).

TABLE 3

MS Network Feature Support information element

TABLE 4

MS Network Feature Support information element

Extended periodic timers (octet 1)

Bit
1

0	MS does not support the extended periodic timer in this domain
1	MS supports the extended periodic timer in this domain

The relevant extended periodic timer is T3212 for Mobility Management

(MM) messages, T3312 for GPRS MM (GMM) messages, and T3412

for EPS MM (EMM) messages.

PS based SMS Support (PSSS) (octet 1)

Bit
2

0	MS does not support PS based SMS
1	MS supports PS based SMS

Bit
2 set to 1 indicates MS support PS based SMS and CS registration is only to receive SMS service
Bits

4 and 3 of octet 1 are spare and shall be coded as zero.

As illustrated in Tables 3 and 4, Bit 2 in octet 1 can be a PS based SMS Support (PSSS) message in the MS network feature support IE. In this example, a Bit value of 0 provides the message that the MS does not support PS based SMS. A Bit value of 1 provides the message that the MS supports PS based SMS and does CS registration only to receive SMS service via the CS domain. The IE illustrated in Table 3, 4 can be included in the Attach Request message shown in FIG. 3.

Solution C

In this solution, one spare bit of the UE Network Capability IE of the ATTACH REQUEST message is used to indicate UE PS-only capability to the network; i.e. the UE's intent to request CS registration only for obtaining SMS based service, but is capable of PS based SMS.
In accordance with one embodiment, the UE Network Capability IE, which is defined in section 9.9.3.34 of 3GPP TS 24.301, can be configured to include a PS based SMS Support message, as follows.

TABLE 5

UE Network Capability information element

TABLE 6

UE Network Capability information element
PS based SMS Support (PSSS) (octet 7, bit 7)

0	MS does not support PS based SMS
1	MS supports PS Based SMS

Bit
7 set to 1 indicates MS support PS based SMS and CS registration is only to receive SMS service
All other bits in octet 8 to 15 are spare and shall be coded as zero, if the respective octet is included in the information element.

As illustrated in Tables 5 and 6, Bit 7 in octet 7 can be a PS based SMS Support (PSSS) message in the UE Network Capability IE. In this example, a Bit value of 0 provides the message that the MS does not support PS based SMS. A Bit value of 1 provides the message that the MS supports PS based SMS and does CS registration only to receive SMS service via the CS domain. The IE illustrated in Table 5 and 6 can be included in the Attach Request message shown in FIG. 3.

Solution D

In this solution one spare bit of EPS Attach Type IE of ATTACH REQUEST is used to indicate UE PS-only capability to the network i.e. the UE's intent to request CS registration only for obtaining SMS based service, but is capable of PS based SMS.
In accordance with one embodiment, the EPS Attach Type IE, which is defined in section 9.9.3.11 of 3GPP TS 24.301, can be configured to include a PS based SMS Support message, as follows.

TABLE 7

EPS Attach Type information element

TABLE 8

EPS Attach Type information element

EPS attach type value (octet 1)

Bits

3	2	1

0	0	1	EPS attach
0	1	0	combined EPS/IMSI attach
1	1	0	EPS emergency attach
1	1	1	Reserved

Bit


4

PS based SMS Support (PSSS)

0	MS does not support PS based SMS
1	MS supports PS based SMS

As illustrated in Tables 7 and 8, Bit 4 in octet 1 can be a PS based SMS Support (PSSS) message in the UE EPS Attach Type IE. In this example, a Bit value of 0 provides the message that the MS does not support PS based SMS. A Bit value of 1 provides the message that the MS supports PS based SMS and does CS registration only to receive SMS service via the CS domain. The IE illustrated in Table 7 and 8 can be included in the Attach Request message shown in FIG. 3.

Solution E

In this solution, an existing IE MS Network Capability in the ATTACH REQUEST message can be extended to indicate a UE PS-only capability to the network; i.e. UE's intent to request CS registration only for obtaining SMS based service, but is capable of PS based SMS.
In accordance with one embodiment, the MS Network Capability IE, which is defined in section 10.5.5.12 of 3GPP TS 24.008, can be configured to include a PS based SMS Support message, as follows

TABLE 9

MS Network Capability information element
. . .
PS based SMS Support (PSSS)

0	MS does not support PS based SMS
1	MS supports PS based SMS

As illustrated in Table 9, a selected bit in a selected octet of the IE can be a PS based SMS Support (PSSS) message. In this example, a Bit value of 0 provides the message that the MS does not support PS based SMS. A Bit value of 1 provides the message that the MS supports PS based SMS and does CS registration only to receive SMS service via the CS domain. The IE illustrated in Table 9 can be included in the Attach Request message shown in FIG. 3.
While several examples have been provided to illustrate communication from the UE to the 3GPP network to communicate the UE's ability to perform PS based SMS support via the Attach Request message, this is not intended to be limiting. There are also additional ways in which this information could be communicated.
For example, enhancements, substantially similar to those shown in Solutions A-E, can be made to the Tracking Area Update Request Message described in section 8.2.29 of 3GPP TS 24.301. These enhancements can be used to communicate the UE's ability to perform PS based SMS support via the Tracking Area Update Request Message, as can be appreciated.

3GPP Network Messaging

In order for the 3GPP wireless network to support PS based SMS support, the network can support SMS communication over the Non Access Stratum (NAS) layer. The network can provide an indication to a UE if SMS over NAS is supported by the MME.
In addition, in a GSM network, when an MS is switched on, the International Mobile Subscriber Identity (IMSI) attach procedure is executed. This procedure is used to connect the MS with the Mobile Switching Center (MSC) and Visitor Location Register (VLR) to register the MS in the network. With the ability to perform PS based SMS support, an MS/UE may no longer need to connect with the MSC. Accordingly, an IMSI attach procedure is not needed. When the network is informed that a UE supports PS based SMS support, the network can then reject any IMSI attach request. The network can send an indication to the UE that the IMSI attach was rejected due to the PS-only service provisioning based on the UE capability and therefore, the UE shall not imitate any CS related procedures.
To accomplish this, an EPS network feature supported IE in the Attach Accept message defined in the 3GPP TS 24.301 specification can be enhanced to include additional information. Two different examples, referred to as Solution A and Solution B, are provided in the proceeding paragraphs. These examples are not intended to be limiting. A variety of messaging means may be used to allow the 3GPP network to communicate with the UE to identify the network's ability to perform PS based SMS support.

Solution A

In this solution, if an MME in an EPS supports SMS over NAS then it can indicate the support to the UE in the Attach Accept message using a new EPS Network Feature Supported IE. One example format of the new IE in the Attach Accept message is provided below.
The purpose of the EPS Network Feature Support IE is to indicate whether certain features are supported by the network. The EPS Network Feature Support IE can be coded as shown in Tables 10 and 11. In one example, the EPS Network Feature Support IE is a type 4 IE with a length of 3 octets.

TABLE 10

EPS Network Feature Support information element

TABLE 11

EPS Network Feature Support information element
. . .

Bit 7

0	SMS over NAS not supported
1	SMS over NAS is supported

Bit 8 of octet 3 is spare and shall be coded all zero.

As illustrated in Tables 10 and 11, Bit 7 in octet 3 can be a PS based SMS Support (PSSS) message in the EPS Network Support IE. In this example, a Bit value of 0 provides the message that the SMS over NAS is not supported. A Bit value of 1 provides the message that SMS over NAS is supported by the EPS. The IE illustrated in Table 10 and 11 can be included in the Attach Accept message communicated from the EPS to the UE.

Solution B

In this solution, if an MME in an EPS supports SMS over NAS then it can indicate the support to the UE in the Attach Accept message using a new EPS Extended Network Feature Supported IE. One example format of the new IE in the Attach Accept message is provided below.
The EPS Extended Network Feature Support IE is to indicate whether certain features are supported by the network. The EPS Extended Network Feature Support IE can be coded as shown in Tables 12 and 13.

TABLE 12

EPS Extended Network Feature Support information element

TABLE 13

EPS Extended Network Feature Support information element
PS based SMS Support (PSSS) (octet 1)

Bit
1

0	SMS over NAS not supported
1	SMS over NAS supported

Bit 1 set to 1 indicates SMS over NAS is supported by SGSN
Bits
4 to 2 of octet 1 are spare and shall be all coded as zero.

As illustrated in Tables 12 and 13, Bit 1 in octet 1 can be a PS based SMS Support (PSSS) message in the EPS Extended Network Support IE. In this example, a Bit value of 0 provides the message that the SMS over NAS is not supported by the EPS. A Bit value of 1 provides the message that SMS over NAS is supported by the EPS. The IE illustrated in Table 12 and 13 can be included in the Attach Accept message communicated from the EPS to the UE.
While several examples have been provided to illustrate communication from the EPS to the UE to communicate the network's ability to perform PS based SMS support via the Attach Accept message, this is not intended to be limiting. There are also additional ways in which this information could be communicated.
For example, enhancements, substantially similar to those shown in Solutions A-B, can be made to the Tracking Area Update Accept Message described in section 8.2.26 of 3GPP TS 24.301. These enhancements can be used to communicate the network's ability to perform SMS over NAS t via the Tracking Area Update Accept Message, as can be appreciated.

EMM Cause Value

In addition to the PSSS message from the EPS to the UE, an EPS mobility management (EMM) message can be communicated from the EPS to the UE. The EMM message may be communicated in an IE. The purpose of the EMM cause IE is to indicate the reason why an EMM request from the UE Is rejected by the network. In this case, the EMM cause IE can be used to identify that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS. Accordingly, no IMSI attach is necessary, as previously discussed. The EMM cause IE is a type 3 IE with 2 octets length. One example is shown in Table 14 and in FIG. 4.

TABLE 14

EMM cause information element

As shown in FIG. 4, Cause #41 can provide information that the IMSI attach is rejected by the EPS since PS-only is supported and the network supports SMS over NAS. This EMM cause can be sent to the UE when the UE is supposed to send and receive SMS via PS NAS signaling.
In another example embodiment, a method 500 for communicating a short message service (SMS) communications in a packet switched (PS) domain of an evolved packet system (EPS) network is disclosed, as depicted in the flow chart of FIG. 5. The method comprises receiving, at a core network (CN) control node, a request message from a user equipment (UE) indicating that the UE supports PS based SMS and performs a circuit switched (CS) registration only to receive SMS service via a CS domain, as shown in block 510; and sending, from the CN control node, an accept message to the UE indicating that SMS over a non-access stratum (NAS) is supported by the CN control node, as shown in block 520. The CN control node can be one of a mobility management entity (MME) and a serving general packet radio service (GPRS) support node (SGSN), as previously discussed.
In one embodiment, the CN control node of the method 500 can be either a mobility management entity (MME) or a serving general packet radio service (GPRS) support node (SGSN). The request message can be either an attach request message or a tracking area update request message. The accept message can be either an attach accept message or a tracking area update accept message. The attach accept message or the tracking area update accept message can indicate that the IMSI attach is only for SMS.
The method 500 can further comprise sending, from the CN control node, an evolved packet system (EPS) mobility management (EMM) message identifying that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS.
The method 500 can further comprise receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an additional update type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
The method 500 can further comprise receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises a mobile station network feature support information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
The method 500 can further comprise receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises a UE network capability information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
The method 500 can further comprise receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an EPS attach type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
The method 500 can further comprise receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises a mobile station network capability information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
The method 500 can further comprise sending an attach accept message or a tracking area update accept message to the UE, wherein the attach accept message or the tracking area update accept message comprises an EPS network feature support information element (IE) using a selected bit in the IE to identify if SMS over NAS is supported or is not supported by the EPS network.
The method 500 can further comprise sending an attach accept message or a tracking area update accept message to the UE, wherein the attach accept message or the tracking area update accept message comprises an EPS extended network feature support information element (IE) using a selected bit in the IE to identify if SMS over NAS is supported or is not supported by the EPS network.
In one embodiment, the method 500 comprises providing a non-broadcasted Location Area Identity (LAI) by the CN control node. A reserved Temporary Mobile Subscriber Identity (TMSI) from the CN control node can be provided to the UE.
The method 500 can further comprise sending a notification from the CN control node to a Home Subscriber Server that the CN control node is capable of SMS transfer without establishing an SGs association with a mobile switching center (MSC).
In another embodiment, a method 600 for adapting a wireless network for packet switched communication of a short message service message is described, as depicted in the flow chart of FIG. 6. The method comprises transmitting a request message from a user equipment (UE) to a mobility management entity (MME) indicating that the UE supports packet switched (PS) based short message service (SMS) and performs a circuit switched (CS) registration only to receive CS based SMS service, as shown in block 610; and receiving, at the UE, an accept message from the MME indicating that SMS over a non-access stratum (NAS) is supported by the MME, as shown in block 620. In one embodiment, the request message can be one of an attach request message and a tracking area update request message. The accept message can be one of an attach accept message and a tracking area update accept message, as previously discussed.
The method 600 can further comprise sending, from MME, an evolved packet system (EPS) mobility management (EMM) message identifying a cause code that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS. The operation of transmitting the request message can further comprise transmitting an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an additional update type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
In another embodiment, a mobility management entity (MME) configured to adapt a user equipment (UE) for packet switched (PS) communication of a short message service (SMS) message is disclosed. The MME comprises a PS support module operable at the MME, as illustrated in FIG. 2. The PS support module is configured to receive a request message from a UE indicating that the UE supports PS based SMS and performs a circuit switched (CS) registration only to receive SMS service via a CS domain; and send an accept message to the UE indicating that SMS over a non-access stratum (NAS) is supported by MME. The request message can be one of an attach request message and a tracking area update request message. The accept message can be one of an attach accept message and a tracking area update accept message.
In one embodiment, the PS support module is further configured to transmit an evolved packet system (EPS) mobility management (EMM) message identifying a cause code that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS.
In another embodiment, the PS support module is further configured to receive the request message from the UE, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an additional update type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.
FIG. 7 provides an example illustration of a mobile device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of mobile wireless device. The mobile device can include one or more antennas configured to communicate with a base station (BS), an evolved Node B (eNB), or other type of wireless wide area network (WWAN) access point. The mobile device can be configured to communicate using at least one wireless communication standard including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The mobile device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The mobile device can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a wireless wide area network (WWAN).
FIG. 7 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the mobile device. The display screen may be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen may use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to a user. The non-volatile memory port may also be used to expand the memory capabilities of the mobile device. A keyboard may be integrated with the mobile device or wirelessly connected to the mobile device to provide additional user input. A virtual keyboard may also be provided using the touch screen.
It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be passive or active, including agents operable to perform desired functions.
Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
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 of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.
As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as defacto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of materials, fasteners, sizes, lengths, widths, shapes, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.

Claims

What is claimed is:

1. A method for communicating a short message service (SMS) communications in a packet switched (PS) domain of an evolved packet system (EPS) network, comprising:

receiving, at a core network (CN) control node, a request message from a user equipment (UE) indicating that the UE supports PS based SMS and performs a circuit switched (CS) registration only to receive SMS service via a CS domain; and

sending, from the CN control node, an accept message to the UE indicating that SMS over a non-access stratum (NAS) is supported by the CN control node.

2. The method of claim 1, wherein the CN control node is one of a mobility management entity (MME) and a serving general packet radio service (GPRS) support node (SGSN).

3. The method of claim 1, wherein the request message is one of an attach request message and a tracking area update request message.

4. The method of claim 1, wherein the accept message is one of an attach accept message and a tracking area update accept message.

5. The method of claim 1, further comprising sending, from the CN control node, an evolved packet system (EPS) mobility management (EMM) message identifying that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS.

6. The method of claim 4, further comprising indicating in the attach accept message or the tracking area update accept message that the IMSI attach is only for SMS.

7. The method of claim 1, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an additional update type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

8. The method of claim 1, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises a mobile station network feature support information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

9. The method of claim 1, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises a UE network capability information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

10. The method of claim 1, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an EPS attach type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

11. The method of claim 1, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises a mobile station network capability information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

12. The method of claim 1, wherein sending the accept message further comprises sending an attach accept message or a tracking area update accept message to the UE, wherein the attach accept message or the tracking area update accept message comprises an EPS network feature support information element (IE) using a selected bit in the IE to identify if SMS over NAS is supported or is not supported by the EPS network.

13. The method of claim 1, wherein sending the accept message further comprises sending an attach accept message or a tracking area update accept message to the UE, wherein the attach accept message or the tracking area update accept message comprises an EPS extended network feature support information element (IE) using a selected bit in the IE to identify if SMS over NAS is supported or is not supported by the EPS network.

14. The method of claim 1, further comprising providing a non-broadcasted Location Area Identity (LAI) by the CN control node.

15. The method of claim 1, further comprising providing a reserved Temporary Mobile Subscriber Identity (TMSI) from the CN control node to the UE.

16. The method of claim 1, further comprising sending a notification from the CN control node to a Home Subscriber Server that the CN control node is capable of SMS transfer without establishing an SGs association with a mobile switching center (MSC).

17. A non-transitory machine readable storage medium comprising a plurality of instructions adapted to be executed to implement the method for adapting a wireless network for packet switched communication of a short message service message, comprising:

transmitting a request message from a user equipment (UE) to a mobility management entity (MME) indicating that the UE supports packet switched (PS) based short message service (SMS) and performs a circuit switched (CS) registration only to receive CS based SMS service;

receiving, at the UE, an accept message from the MME indicating that SMS over a non-access stratum (NAS) is supported by the MME.

18. The non-transitory machine readable storage medium of claim 17, further comprising transmitting the request message, wherein the request message is one of an attach request message and a tracking area update request message.

19. The non-transitory machine readable storage medium of claim 17, further comprising sending, from MME, an evolved packet system (EPS) mobility management (EMM) message identifying a cause code that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS.

20. The non-transitory machine readable storage medium of claim 17, wherein transmitting the request message further comprises transmitting an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an additional update type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

21. A mobility management entity (MME) configured to adapt a user equipment (UE) for packet switched (PS) communication of a short message service (SMS) message, comprising:

a PS support module operable at the MME and configured to:

receive a request message from a UE indicating that the UE supports PS based SMS and performs a circuit switched (CS) registration only to receive SMS service via a CS domain; and

send an accept message to the UE indicating that SMS over a non-access stratum (NAS) is supported by MME.

22. The MME of claim 21, wherein the PS support module is further configured to transmit an evolved packet system (EPS) mobility management (EMM) message identifying a cause code that an international mobile subscriber identity (IMSI) attach is rejected as PS only is supported and the EPS network supports SMS over the NAS.

23. The MME of claim 21, further comprising receiving the request message from the UE, wherein receiving the request message further comprises receiving an attach request message or a tracking area update request message, wherein the attach request message or the tracking area update request message comprises an additional update type information element (IE) having a selected bit set to indicate if the UE supports PS based SMS and performs the CS registration only to receive SMS service via the CS domain.

24. The MME of claim 21, wherein the request message is one of an attach request message and a tracking area update request message.

25. The MME of claim 21, wherein the accept message is one of an attach accept message and a tracking area update accept message.