WO2013032208A2 - Method and apparatus for transceiving messages in a wireless communication system - Google Patents

Abstract

Disclosed in the present invention are a wireless communication system, and more particularly, a method and apparatus for transceiving messages. The method according to one embodiment of the present invention comprises the steps of: generating a message in which information representing one or more of a source address and a destination address is included in a user data portion; and transmitting the message, wherein the source address or the destination address may be a type of IP-based identifier.

Description

 【Specification】

 [Name of invention]

 Method and apparatus for sending and receiving messages in a wireless communication system

 Technical Field

 The following description relates to a wireless communication system, and more particularly, to a method and apparatus for transmitting and receiving a message.

 Background Art

 Various methods for transmitting and / or receiving messages (hereinafter, transmitting and receiving) between devices in a communication system are prepared, and new methods have been proposed as the communication system develops. An example of a message transceiving service is a short message service (SMS). SMS refers to a service that supports the transmission and reception of a predetermined length of text, that is, a short message. Recently, methods for transmitting and receiving messages (eg, short messages) based on IPGnternet Protocol have been discussed.

 In a message transmission / reception method, information identifying an originating device of a message and / or a destination device of a message is required. As an example of device identification information, a Mobile Subscriber Integrated Services Digital Network Number (MSISDN) associated with subscriber information may be used. For example, in the SMS supported by the existing 3rd Generation Partnership Project (3GPP), the MSISDN is used as essential information for determining the source / destination of a message.

 [Detailed Description of the Invention]

 [Technical problem]

 As mentioned above, existing messaging services (e.g., SMS)

The identifier of the device, such as MSISDN, is mandatory. However, an existing device identifier (eg, MSISDN) consists of a limited length of digits and may be depleted as the number of devices increases. For example, MTCXMachine Type

In advanced communication systems that require support for a large number of devices, such as COTimunication (Machine-to-Machine) or M2M (M2M) communication, it may not be possible to assign conventional identifiers to all devices. Accordingly, in an advanced communication system, a device (eg, MSISDN-less) that does not have a conventional identifier may be used. May exist.

 In the present invention, it is a technical problem to provide a method for transmitting and receiving a message for a device that does not have a conventional identifier.

 Technical problems to be achieved in the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Will come.

 Technical Solution

 In order to solve the above technical problem, a method of performing a short message service (SMS) operation according to an embodiment of the present invention includes generating a message including information indicating at least one of a source address or a destination address in a user data portion. Doing; And transmitting the message, wherein the source address or the destination address may be in the form of an IP-based identifier.

 In order to solve the above technical problem, a method of performing a Short Message Service (SMS) operation according to another embodiment of the present invention includes: receiving a message; And obtaining information indicating one or more of a source address or a destination address included in the user data portion of the received message, wherein the source address or the destination address may have the form of an IP-based identifier.

 In order to solve the above technical problem, an apparatus for performing a short message service (SMS) operation according to another embodiment of the present invention, transmitting and receiving modules for transmitting and receiving a signal with the outside; And a processor for controlling the transceiver, wherein the processor is configured to generate a message including information indicating at least one of a source address or a destination address in a user data portion; The message may be configured to transmit through the transmission / reception mode, and the source address or the destination address may have an IP-based identifier.

In order to solve the above technical problem, an apparatus for performing a short message service (SMS) operation according to another embodiment of the present invention, a transmission and reception module for transmitting and receiving a signal with the outside; And a processor for controlling the transmission and reception device, wherein the processor is configured to receive a message through the transmission and reception module; Received above Obtain information indicating at least one of a source address or a destination address included in the user data portion of the message, wherein the source address or the destination address may have the form of an IP-based identifier.

 In the embodiments according to the present invention, the following matters may be commonly applied.

 The field including the source address or the destination address may be continuously located in a field including the content of user data included in the user data portion.

 The field including the source address or the destination address may be located before or after the field including the content of the user data.

 The user data portion may include a user data header, and a field including the source address or the destination address may be included in the user data header.

 Information indicating at least one of a location or a length of a field including the source address or the destination address may be included in the header of the message.

 The user data associated with the source address or the destination address may be sent continuously via additional messages.

 The message including the information indicating the source address or the destination address does not include the content of the user data, and the content of the user data may be transmitted through the additional message.

 The user data portion may be a Transfer Protocol-User Data (TP-UD) field.

 The user data header may be a TP-UDH field. Whether the source address or the destination address is included in the user data portion of the message is RPDIKRelay Protocol Data of the message.

It may be indicated by using MTKMessage Type Indicator (Unit)) or TPDU-DCS (TPDU-Dat a Coding Scheme). ^■

Information indicative of at least one of the source address or the destination address certificate may be coded by the same coding technique applied to the user data. The source address or the destination address may be a Session Initiation Protocol (SIP) Uniform Resource Identifier (URI), and the source device or the destination device may be a device without an MSISDN (Mobile Subscriber Integrated Services Digital Network Number).

 The foregoing general description and the following detailed description of the invention are exemplary and intended for further explanation of the invention as described in the claims.

 Advantageous Effects

 According to the present invention, a message transmission / reception scheme for a device that does not have a conventional identifier may be provided.

 Effects obtained in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

 [Brief Description of Drawings]

 BRIEF DESCRIPTION OF THE DRAWINGS The drawings appended hereto are for the purpose of providing an understanding of the present invention and for illustrating various embodiments of the present invention and for describing the principles of the present invention in conjunction with the description thereof.

 1 is a diagram illustrating a schematic structure of an EPS (Evolved Packet System) including an Evolved Packet Core (EPC).

 2 is a diagram schematically illustrating a structure of an IMS-based wireless communication system. 3 is a diagram illustrating a basic network structure for transmitting and receiving short messages.

 4 is a diagram illustrating a protocol layer for SMS.

 5 is a flowchart illustrating a method of transmitting a short message by an IMS UE.

 6 is a flowchart illustrating a method of receiving a short message by an IMS UE.

 7 is a diagram illustrating an example of an SMS service for an MSISDN-less IMS UE. 8 illustrates a layout of basic elements of an SMS-DELIVER type message.

 9 is a diagram illustrating an exemplary field structure associated with a TP-UD.

10 illustrates a structure of a TP-UD field including a SIP URI according to an example of the present invention. The figure shows by way of example.

 11 is a diagram exemplarily illustrating a structure of a TP_UD field including a SIP URI according to another embodiment of the present invention. ·

 12 is a flowchart illustrating an example of the present invention in which an MSISDN-less IMS UE transmits a short message to a server.

 13 is a flowchart illustrating an example of the present invention in which an MSISDN-less IMS UE transmits a short message to an MSISDN-less IMS UE.

 14 is a diagram showing the configuration of a preferred embodiment of a transmission and reception apparatus according to an example of the present invention.

 [Best form for implementation of the invention]

 The following embodiments combine the components and features of the present invention in a predetermined form. Each component or feature may be considered to be optional unless otherwise stated. Each component or feature may be embodied in a form that is not combined with other components or features. In addition, some components and / or features may be combined to form an embodiment of the present invention. The order of the operations described in the embodiments of the present invention may be changed. Some configurations or features of one embodiment may be included in another embodiment or may be substituted for components or features of another embodiment.

 Specific terms used in the following description are provided to help the understanding of the present invention, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present invention.

 In some cases, well-known structures and devices may be omitted or shown in block diagram form centering on the core functions of the structures and devices in order to avoid obscuring the concepts of the present invention. Elements are described using the same reference numerals.

 Embodiments of the invention are IEEE (Institute of Electrical and Electronics)

Engineers) may be backed by standard documents disclosed in connection with at least one of the 802 series system, 3GPP system, 3GPP LTE and LTE ᅳ A system and 3GPP2 system. That is, to clearly reveal the technical spirit of the present invention among the embodiments of the present invention. Steps or portions not described may be supported by the above documents. In addition, all terms disclosed and described herein can be described by the standard document.

 The following techniques can be used in various wireless communication systems. For clarity, the following description focuses on 3GPP LTE and 3GPP LTE-A systems, but the technical spirit of the present invention is not limited thereto.

 Terms used in this document are defined as follows.

 UMTS (Universal Mobile Telecom® unications system): A third generation mobile communication technology based on the Global System for Mobile Co.unicat ion (GSM), developed by 3GPP.

 EPSCEvolved Packet System (EPCE): A network system including an Evolved Packet Core (EPC), an IP-based packet switched core network, and an access network such as LTE and UTRAN. UMTS is an evolutionary network.

 NodeB: base station of GERAN / UTRAN. It is installed outdoors and its coverage is macro cell size.

 ENodeB: the base station of LTE. It is installed outdoors and its coverage is macro cell size.

 UE Jser Equipment): a user device. The UE may be referred to in terms of terminal, mobile equipment (ME), mobile station (MS), and the like. In addition, the UE may be a portable device such as a laptop, a mobile phone, a personal digital assistant (PDA), a smart phone, a multimedia device, or the like, or may be a non-portable device such as a KXPersonal computer or a vehicle-mounted device.

 IMS (IP Multimedia Subsystem): A subsystem for providing multimedia services based on IP.

 MS ISDN (Mob i le Subscriber Integrated Services Digital Network Number):

A number that uniquely identifies a subscription in a GSM or UMTS network. See 3GPP TS 23.003 and TS 22.101 for more details.

IMSK International Mobile Subscriber Identity): A user identifier that is uniquely assigned internationally in a mobile communication network. Subscriber Identity Module (SIM): Modes containing user information such as IMS I.

 RANCRadio Access Network: A unit including a NodeB, an eNodeB, and a Radio Network Controller (RNC) for controlling them in a 3GPP network. It exists between UEs and provides a connection to the core network.

 Home Location Register (HLR) / Home Subscriber Server (HSS): A database that contains subscriber information within a 3GPP network. HLR / HSS can perform configuration storage (conf igurat ion storage), identity management (user identity management), user state storage.

一 IMS Registration0 3 ^" ^ 1011): The process by which a UE informs its home IMS network about its current location.

 RANAPCRAN Application Part: between the RAN and the node responsible for controlling the core network (丽 E (Mobility Management Entity) / SGSN (Serving GPRS (General Packet Radio Service) Supporting Node) / MSC (Mob i les Switching Center)) Interface.

 Public Land Mobile Network (PLMN): A network composed for the purpose of providing mobile communication services to individuals. It may be configured separately for each operator.

 Non-Access Stratum (NAS): A functional layer for sending and receiving signaling and traffic messages between a UE and a core network in an EPC protocol stack. The main function is to support mobility of the UE and to support a session management procedure for establishing and maintaining an IP connection between the UE and the PDN Packet Data Network Gateway (GW).

 CSCFCCall Session Control Function): A server or proxy server that processes SIP signaling packets in IMS. P-CSCF (Proxy-CSCF), S-CSCF (Serving-CSCF) and I-CSCF (Interrogating-CSCF) can be divided.

 IFCCinitial Filter Criteria: Filter criteria stored in the HSS as part of the user profile and downloaded to the S-CSCF upon user registration. Indicates that a user's subscription to an application is provisioned. See 3GPP TS 23.218 for more details.

IMPU IP Multimedia PUblic identity: An IMS user has more than one IMPU (or Public User Identity) to communicate with other users. Also, Multiple IEs may share a single IMPU. Follow the form of the ^'IMPU is (resources identified by telephone numbers) SIP URI (Uniform Resource Identifier) or Tel URI.

 Short Message Entity (SME): An entity that sends or receives a short message. See 3GPP TS 23.040 for more details.

 Short Message Service-Service Center (SMS-SC): An entity responsible for relaying and storing-and-forwarding short messages between an SME and a UE.

 IP-SM-GK IP-Short Massage-Gateway: An entity that provides protocol interworking for delivery of short messages between an IP-based UE and an SMS—SC. See 3GPP TS 23.204 for more details.

 -Server: In this document, in the case of simply referred to as a server without a separate description, it refers to an SME that transmits / receives a short message from / to an (MSISDN-less) IMS UE without an MSISDN. See 3GPP TR 23.863 for more details.

 Hereinafter will be described based on the terms defined above.

 Evolved Packet Core (EPC)

 1 is a diagram illustrating a schematic structure of an EPS (Evolved Packet System) including an Evolved Packet Core (EPC).

EPC is a key element of System Architecture Evolution (SAE) to improve the performance of 3GPP technologies. SAE is a research project to determine network structure supporting mobility between various kinds of networks. SAE aims to provide an optimized packet-based system, for example, supporting various radio access technologies on an IP basis and providing improved data transmission capabilities. Specifically, the EPC is a core network of the IP mobile communication system for the 3GPP LTE system and may support packet-based real-time and non-real-time services. In existing mobile communication systems (i.e., 2nd or 3rd generation mobile communication systems), the core network is divided into two distinct sub-domains: circuit-switched (CS) for voice and packet-switched (PS) for data. The function has been implemented. However, in the 3GPP LTE system, an evolution of the third generation mobile communication system, the sub-domains of CS and PS have been unified into one IP domain. In other words, 3GPP LTE In the system, the connection between the terminal and the terminal having the IP capability (capability) may be configured through an IP-based base station (eg, evolved Node B), an EPC, an application domain (eg, IMS). . That is, EPC is an essential structure for implementing end-to-end IP service.

 The EPC may include various components, and in FIG. 1, some of them correspond to a Serving Gateway (SGW), a PDN Packet Data Network Gateway (GW), an MMEC Mobility Management Entity (SGN), and a Serving General Packet Radio Service (SGRS). (Supporting Node), and enhanced Packet Data Gateway (ePDG).

 SCT acts as a boundary point between a radio access network (RAN) and a core network, and is an element that functions to maintain a data path between an eNodeB and a PDN GW. In addition, when the terminal moves over an area served by the eNodeB, the SCT serves as a local mobility anchor point. That is, packets may be routed through the SGW for mobility in E—UTRAN (Evolved—Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network defined in 3GPP Release-8 or later). SGW also provides mobility with other 3GPP networks (RANs defined before 3GPP Release-8, for example, UTRAN or GERAN (Global System for Mobile Communicat ion (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It may also serve as an anchor point for.

The PDN GW corresponds to the termination point of the data interface towards the packet data network. The PDN CT may support policy enforcement features, packet filtering, charging support, and the like. In addition, mobility between 3GPP networks and non-3GPP networks (e.g., untrusted networks such as Interworking Wireless Local Area Networks (I-WLANs), trusted networks such as Code Division Multiple Access (CDMA) networks or WiMax) Can serve as an anchor point for management. Although the example of the network structure of FIG. 1 shows that the SGW and the PDN GW are configured as separate gateways, two gateways may be implemented according to a single gateway configuration option. 匪 E is an element that performs signaling and control functions to support access to the network connection of the UE, allocation of network resources, tracking, paging, roaming and handover, and the like.匪 E controls the control plane functions related to subscriber and session management.匪 E manages a number of eNodeBs and performs signaling for the selection of a conventional gateway for handover to another 2G / 3G network.匪 E also performs functions such as security procedures, terminal-to-network session handling, and idle terminal location management.

 SGSN handles all packet data, such as user's mobility management and authentication for other 3GPP networks (e.g., GPRS networks). The ePDG acts as a secure node for untrusted non-3GPP networks (eg I-WLAN, WiFi hot spots, etc.).

 As described with reference to FIG. 1, a terminal having IP capability is provided with an IP service network (eg, provided by an operator) via various elements in the EPC, based on 3GPP access as well as non-3GPP access. , IMS).

 In addition, FIG. 1 shows various reference points (eg, Sl-U, S1— 匪 E, etc.). In the 3GPP system, a conceptual link connecting two functions existing in different functional entities of E-UTRAN and EPC is defined as a reference point. Table 1 below summarizes the reference points shown in FIG. 1. In addition to the examples of Table 1, there may be various reference points according to the network structure.

 Table 1

lane tunnelling inter eNodeB path switching during handover)

 A reference point between E and SGSN that provides user and bearer information exchange for mobility between 3GPP access networks in idle and / or active states. This reference point can be used in PLMN-to-PLMN-to-for example (for PLMN-to-PLMN handover)

S3

 (It enables user and bearer information exchange for inter 3GPP access network mobility in idle and / or active state.This reference point can be used intra-PLMN or inter ᅳ PUN (e.g. in the case of Inter-PLMN HO).)

 Reference point between SGW and SGSN that provides relevant control and mobility support between the GPRS core and SGW's 3GPP anchor functionality. It also provides user plane tunneling if no direct tunnel is established.

S4 provides related control and mobility support between GPRS

 Core and the 3GPP Anchor function of Serving GW. In addition, if Direct Tunnel is not established, it provides the user lane tunnelling.)

 Reference point providing user plane tunneling and tunnel management between the SGW and the PDN GW. Used for SGW relocation due to UE mobility and when a connection to a PDN GW where no SGW is located is required for the required PDN connectivity.

S5

 user lane tunnelling and tunnel management between Serving GW and PDN GW. It is used for Serving GW relocation due to UE mobility and if the Serving GW needs to connect to a non- col located PDN GW for the required PDN connectivity. )

Reference Point Between Sll ffi and SGW

 Reference point between the PDN GW and the PDN. The PDN may be an operator external public or private PDN or, for example, a PDN within the operator for providing IMS services. This reference point is the Gi of 3GPP access (It is the reference point between the

SGi PDN GW and the packet data network. Packet data network may be an operator external public or private packet data network or an intra operator packet data network, eg for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses. Among the reference points shown in FIG. 1, S2a and S2b correspond to non-3GPP interfaces. S2a is a reference point that provides the user plane with relevant control and mobility support between trusted non-3GPP access and PDNCT. S2b is a reference that provides the user plane with relevant control and mobility support between ePDGs and PDN GWs. It is a point

 IP Multimedia Subsystem (IMS)

 2 is a diagram schematically illustrating a structure of an IMS-based wireless communication system.

The IMS-based wireless communication system may include various components. In FIG. 2, a terminal, an access and core network, a multiple imedia resource function (MRF), various call 1 session control functions (CSCFs), SCC Service Centralization and Continuity Application Server (HSC) and Home Subscriber Server (HSS). Here, the CSCF is a server or proxy server that processes SIP signaling packets in the IMS, and may be divided into a P-CSCF (Proxy-CSCF), a S-CSCF (Serving-CSCF), and an I—CSCF (Interrogating-CSCF). .

 The terminal may communicate with IMS-related nodes and / or other terminals via an IP-based radio access network and a core network such as E-UTRAN. A terminal having IP capability may have a unique ID (eg, an IMPU ID such as a SIP URI or Tel URI) and an IP address.

 MRF corresponds to a server that provides media related functions such as media conditioning (eg, voice stream mixing), and consists of MRFC and MRFP. The MRFC interprets the information from the AS and S-CSCFs and controls the MRFP. The MRFP performs the function of mixing, providing or processing a media stream.

 P-CSCF is a SIP proxy server that is a contact point for the IMS terminal. The P-CSCF may perform a function of allocating resources for media flow and security of messages between the network and the terminal.

 I-CSCF is a SIP server that is a point of contact from a peer network. I— The CSCF may perform a function such as performing a query to the HSS to determine the S-CSCF for the UE.

 The S-CSCF is a server that handles SIP registration and performs location determination, terminal authentication, call processing (eg, call routing), etc. of each terminal. For example, if the terminal

When registering to the IMS network, the registration message of the terminal including information on the media type, codec related information, screen size, etc. supported by the terminal passes through the P-CSCF.

Can be forwarded to S-CSCF. The behavior of S-CSCF depends on the policies stored in the HSS. Thus it can be controlled.

 SCC AS provides the functionality required for IMS centralized services and is the home network foundation for service continuity of multimedia sessions. IMS application.

 HSS can perform configuration storage, identity management, and user state storage.

 Short Message Service (SMS)

 3 is a diagram illustrating a basic network structure for transmitting and receiving short messages.

 The SME refers to an entity that transmits or receives a short message, and the SMS-SC may perform a function of storing and forwarding a message between the SME and the MS. SMEs and SMS-SCs exist outside the system boundaries defined by the 3GPP standard, and function as gateways of systems defined by the Gateway MSC for SMS (SMS-GMSC) or SMS-Ill SC Working Systems MSC for SMS (3GPP). Can be performed.

 The SMS-GMSC may perform the function of receiving a short message from the SMS—SC, querying the HLR to route SMS related information, and forwarding the short message to the recipient MS's SGSN or VMSC Visited MSC. The SMS-IWMSC may perform a function of receiving a short message from inside the PLMN and submitting the received short message to the recipient SMS-SC.

 An SMS-router is an optional object and ᅳ MT (Mobile Terminated)

Only used for SMS.

 The MSC and SGSN are the entities that perform switching for the mobile stations in the Circuit Switching (CS) and Packet Switching (PS) domains, respectively. The VLR is associated with the MSC and is a database containing temporary information about roaming subscribers.

 4 is a diagram illustrating a protocol layer for SMS.

The protocol layer of SMS consists of Short Message-Application Layer (SM-AL), Transfer Layer (SM-TL), Relay Layer (SM-RL), and Lower Layers (SM-LL) in order from the upper layer to the lower layer. . The SM-TL may include six PDl Protocol Data Units. Specifically, i) the SMS-DELIVER type conveys a short message from the SMS_SC (Service Center) to the MS (mobile station), and ii) the SMS-DELIVER-REPORT type is positive for SMS-DELIVER or SMS-STATUS-REPORT. / Iii) the SMS-SUBMIT type carries a short message from MS to SMS-SC, and iv) the SMS-SUBM IT-REPORT type is affirmative for SMS—SUBMIT or SMS ᅳ COMMAND. V) SMS-STATUS-REPORT type carries status report from SMS-SC to MS, and v) SMS-C0MMAND type is defined as PDU carrying command from MS to SMS-SC.

 Among these, the SMS-DELIVER type is a TPDL Transfer Protocol Data Unit containing user data (i.e., the content of a short message) transferred from the SMS 'SC to the MS. Table 2 below shows the basic elements of the SMS-DELIVER type.

Table 2

Meanwhile, the SMS-SUBMIT type is a TPDU including user data transferred from the MS to the SMS-SC, and essentially includes a destination address (TP-DA) parameter which is an address of the destination SME. Detailed description of other parameters of the SMS-SUBMIT type will be omitted.

Further, more specific ^information, related to the SMS can refer to a standard document 3GPP TS 23.040.

 SMS behavior of IMS UE

 5 is a flowchart illustrating a method of transmitting a short message by an IMS UE.

 In step S501, the UE-K10 may register with the IMS network.

 In step S502, the UE-K10 may send a session initiation request (eg, a SIP MESSAGE request message) to the S_CSCF 20 to send a short message. Here, a short message may be encapsulated in the SIP MESSAGE request message. That is, the body of the SIP MESSAGE request message may include RP-DATA, which is an RPDUCRelay Protocol Data Unit) parameter. Encoded “SMS headers” and “SMS user information”.

 In step S503, the S_CSCF 20 may forward the SIP MESSAGE request message received in step S502 to the IP_SM-GW 30 based on the iFO downloaded from the HSS 40.

In step S504, the IP-SM-GW 30 sends a SIP reply 2XX message (eg, SIP) indicating that the SIP MESSAGE request message received in step S503 has been processed normally. 202 Accepted message) may be sent to the S-CSCF 20.

 In step S505, the S-CSCF 20 may forward the SIP 202 Accepted message received in step S504 to UE-l (10).

 In step S506, IP—SM-G 30) may perform service authorization based on the stored subscriber information. That is, the IP-SM-GW 30 checks whether the subscriber of the UE_1 10 that has sent the SIP MESSAGE request message including the short message is allowed to use the short service. If the service authentication is successful, the IP-SM-GW 30 may extract the short message encapsulated in the SIP MESSAGE request message received in step S503 and send it to the SMS-IWMSCX50. At this time, the IP-SM-GW 30 may transmit the extracted short message to the SMS-Ilia SC 50 using MAP-M0 (Mobile Or iginated) -FORWARD—SHORT-MESSAGE.

 In step S507, the SMS—IWMSCX50 may forward the received short message to the SMS-SC 60. SMS— The SC 60 may send a short message to the SME to receive the short message (ie, the destination SME) (not shown).

 In step S508, the SMS-SC 60 sends a submission report to the SMS_IWMSC 50.

Can transmit

 In step S509, the SMS-IWMSC 50 may transmit the submission report received in step S508 to the IP-SM-GW 30.

 In step S510, the IP 'SM-GW 30 sends the SIP report received in step S509.

It can be encapsulated in a MESSAGE request message and sent to the S_CSCF 20.

 In step S511, S—CSCF 20 requests SIP MESSAGE with the submission report encapsulated.

Message may be sent to the UE-K10.

 In step S512, UE-l (lO) includes a submission report received in step S511.

SIP response 2XX message indicating that the request message was successfully processed (for example,

SIP 2000K message) may be sent to the S-CSCF 20.

 In step S513, the S-CSCF 20 may forward the voice answer message received in step S512 to the IP-SM-GW 30.

 In the short transmission procedure of the IMS UE as shown in FIG. 5, the address of the short destination is RP−.

It is included in RP-User-Data of DATA. Specifically, the destination address, in step S502 UE-l (10) is included in the TP-DA (TP-Destinat ion-Address) field of the TP—TPDlKTransfer protocol data unit constituting User-Data. RP—The TPDU constituting User-Data is a TPDU of SMS-SUBMIT type.

 In addition, in the short transmission procedure of the IMS UE of FIG. 5, the address of the short source (i.e., UE-1) before the IP-SM-G 30 in step S506 forwards the short message to the SMS-IfMSC 50, It is included in the RP-Originator Address IE (Informat ion Element) of RP-DATA. Here, the source address included in the RP-Originator Address IE is the MSISDN of the UE-1, and the IP-SM 'G 30) is the UE-1's information during the IMS registration process of the UE-1 in step S501.

MS ISDN information may be obtained from the S-CSCF 20.

 6 is a flowchart illustrating a method of receiving a short message by an IMS UE.

 In step S601, the UE-K10 may perform registration in the IMS network.

In step S602, the SMS-SC 60 may send a short message to the SMS_GMSC 51. In step S603a, the SMS-GMSCX51 having received the short message transmits a routing information request message to the HSS 40 to retrieve routing information. HSS (40) has, for the subscriber of the UE-K10 of the destination short message) based on a predetermined (pre-configured) address of the IP-SM-GW, IP- SM request mail ^"message received from the SMS-GMSCX51) -Can forward to GW 30 (step S603b). Specifically, the SMS-GMSCX51 includes the MSISDN of UE-l (lO), which is the short destination, in the MAP-SEND-R0UTING-INF0-F0R-SM message to retrieve routing information to the short destination. 40).

 In step S603b, the HSS 40 performs IMSKlnternational of the UE-1 10, which is a short destination.

Mobile Subscriber Identity) may be transmitted to the IP_SM-GW 30.

In step S603c, the IP-SM-G 30 may generate an MT Correlation ID based on the IMSI value received from the HSS 40 in step S603b and store the value along with the IMSI value. MT Correlation ID is a service element that is used only when HPL 丽 (Home PLMN) of SMS recipient MS uses SMS router or IP-SM—CT, Forward SM operation and previous information extraction (Info Retrieval) Can be used to correlate operations, and security can be enhanced by using MT Correlation IDs (see Standard Document 3GPP TS 23.040 for further details). IP-SM-GW 30 includes the generated MT Correlation ID and its address value. Routing information response message to the SMS-GMSCX51).

 In step S604, the SMS-GMSCX51 may transmit a short message including the MT Correlation ID received from the IP-SM-GW 30 to the IP-SM_CT 30 in step S603c. At this time, the SMS 'GMSC 51 can transmit a short message to the IP SM-GW 30 using the MAP # MT-F0RWARD-SH0RT # MESSAGE.

In step S605, the IP # SM-GW 30 may perform service authentication based on the stored subscriber information. That is, the IP-SM-GW 30 checks whether the subscriber of the short-term UE-1 1 10 is allowed to use the short service. If the service authentication is successful, the IP-SM-GW 30 may encapsulate the short message received in step S604 into the SIP MESSAGE request message and transmit the encapsulated short message to the S—CSCF 20. That is, the body of the SIP MESSAGE request message may include RP-DATA, which is encoded in accordance with a predetermined rule (for example, a rule defined in 3GPP TS 23.040) and the "SMS header part" and " SMS user information ' ¹ may be included.

 In step S606, S—CSCF 20 may forward the SIP MESSAGE request message received in step S605 to UE−1 (10).

 In step S607, the UE-lO may transmit a response message (eg, a SIP 200 OK message) to the S-CSCF 20 for the received SIP MESSAGE request message.

 In step S608, S—CSCF 20 may forward the SIP 200 0K message to IP-SM-GW 30.

 In step S609, the UE-1 10 sends a delivery report including an acknowledgment (positive or negative acknowledgment) indicating whether the short message was successfully received in step S606. 20 can be sent.

 In step S610, the S-CSCF 20 may forward the delivery report to the IP-SM-G 30.

 In step S611, the IP-SM-GW 30 may transmit a response message (eg, a SIP 202 Accepted message) to the S-CSCF 20 in response to the delivery report received in step S610.

In step S612, the S-CSCF 20 may forward the SIP 202 Accepted message to the UE # 1 (10). In step S613, the IP-SMG GW 30 transmits a Delivery Report to the SMS-GMSC 51.

 In step S614, the SMS—GMSCX51 may send a Delivery R 印 ort to the SMS_SC 60.

 In the short receiving procedure of the IMS UE of FIG. 6, the address of the short source is sent in step S602.

SMS-SCX60) is included in the RP-User-Data of the RP-DATA. Specifically, the address of the short source is included in the TP-0A (TP-0r iginat ing-Address) field of the TPDU composing the RP-User-Data. The TPDU constituting the RP-User-Data is a TPDU of the SMS-DELIVER type.

 In addition, in step S605, the IP-SM-GW 30 requests-—the SIP MESSAGE request message.

The URI is set to the IMPU of UE-l (lO) which is the short destination. At this time, IP—SM-GW 30 may know the destination of the short message based on the MT Correlation ID value generated by using the IMSI value of UE-1 included in the short message received in step S604.

 As mentioned above, the IMS UE gives a short message. In order to receive the IP-SM-GW performs protocol interworking, for this purpose, the IP-SM-GW must know the MSISDN information of the IMS UE it serves.

 Advanced Messaging Service

 As mentioned above, in an existing messaging service, an identifier of a device, such as MSISDN, is essentially used to specify the source device (i.e. sender) or destination device (i.e. recipient). However, since a device identifier such as MSISDN has a limited length, it may be impossible to assign an existing device identifier as the number of devices increases. Accordingly, there is a need for a messaging service scheme for devices (eg, MSISDN-less) devices that do not have a conventional identifier.

 For example, a method for allowing a terminal belonging to an IMS Gabibja that does not have an MSISDN associated with IMS subscriber information to send and receive ip based SMS is under discussion. Specifically, a terminal belonging to an IMS subscriber that does not have an MSISDN currently being discussed (ie

A method for the MS ISDN-less IMS UE to send a short message to a server (for example, a server for M2M) having an MSISDN will be described with reference to FIG. 7. 7 is a diagram illustrating an example of an SMS service for an MSISDN-less IMS UE. In step S701a, the UE-l (ll), which is an MSISDN-less IMS UE, may encapsulate the short message in the SIP MESSAGE request message and send it to the S_CSCF 20 in order to send a short message to the server 100. That is, the body of the SIP MESSAGE request message may include RP-DATA including the Sl ^ header part and SMS user information encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040). Here, RP-DATA may include RP—User—Data, and RP—User-Data may include a TPDU of SMS—SUBMIT type.

 In step S701b, the S-CSCF 20 may forward the SIP MESSAGE request message received in step S701a to the IP-SM—GW 30 based on the stored iFC.

 In steps S702a to S702b, the IP_SM-GW 30 receives the SIP received in step S701b.

A SIP 200 OK message, which is a response to the MESSAGE request message, may be transmitted to the UE-l (ll) via the S-CSCF 20.

In step S703, the IP-SM-GW 30 may generate a terminating short message based on the SIP MESSAGE request message received in step S701b. This is because UE-l (ll) which has sent the SIP MESSAGE request message is a UE belonging to an IMS subscriber having no MSISDN. As a specific example, the IP-SM-GW 30 converts the TPDU of the SMS-SUBMIT type into the TPDU of the SMS-DELIVER type. In addition, IP-SM- GW (30) ^is' IMPU the TP-UD (TP-User - Data) of the SIP URI of the short MSISDN-less IMS UE (ll) and included in the. In addition, IP-SM-GW 30 sets RP-0r iginating-Address and TP- Or iginating-Address to MSISDN of IP-SM-G 30).

In steps S704a to S704b, the IP-SM-GW 30 may send a SIP MESSAGE request message including the incoming short message generated in step S703 to the server 100. In steps S705a to S705b, the server 100 may transmit a SIP 200 0K message, which is a response message to the request message received in step S704b, to the IP-SM-GW 30 via the S-CSCF 20. ^'

 In steps S706a to S706b, the server 100 transmits a delivery report including an acknowledgment indicating whether or not the short message was successfully received in step S704b.

Report) may be transmitted to the IP_SM-GW 30 via the S-CSCF 20.

In steps S707a to S707b, the IP-SM—GW 30 forwards received in step S706b. A SIP 200 OK message, which is a voting message for the report, may be transmitted to the server 100 via the S-CSCF 20.

 In step S708, the IP-SM-GW 30 generates a Submit Report based on the delivery report received in step S706b. At this time, the TPDU of the SMS-DELIVER-REPORT type may be converted into the TPDU of the SMS-SUBM IT-REPORT type.

 In steps S709a to S709b, the IP-SM-GW 30 may transmit a submission report to the UE-U11 via the S_CSCF 20.

 In steps S710a to S710b, the UE-l (ll) may transmit a SIP 200 OK message, which is a response message to the submission report received in step S708b, to the SIP-SM-GW 30 via the S-CSCF 20. .

 For more details on the SMS operation of the MSISDN-less IMS UE described with reference to FIG. 7, refer to section 5.1.2.3 of the standard document TR 23.863.

 Meanwhile, according to the SMS operation related to the existing MSISDN-less IMS UE described with reference to FIG. 7, in step S703, the IP-SM-GW 30 sends the short message to the server 100 so that the MSISDN- which is the actual short source. less The IMS UE's address (i.e., SIP URI) is defined as being sent in the actual message part (i.e. TP-User-Data) rather than a short header.

 In addition, even in the case of a short message in which the MSISDN-less IMS UE is a destination, the actual message portion (ie, TP-User-Data), not the short header, includes the address of the MSISDN-less IMS UE (ie, SIP URI). It is defined.

 However, since a specific method is not defined, it is required to define a method of encoding a SIP URI, which is an IMPU of an MSISDN-less IMS UE, into an actual message (ie, user data portion). The present invention proposes a method for encoding the SIP URI when the SIPS of the MSISDN-less IMS UE is included in the actual message part rather than the header part of the short message in order to send and receive a short message.

The address encoding scheme of the MSISDN-less IMS UE proposed in the present invention defines an essential configuration for actually implementing a new SMS service scheme, which is not previously defined, so that SMS transmission and reception for the MSISDN-less IMS UE is correct. It can be done efficiently. Further, according to the present invention, the SMS URI using the existing MSISDN and the SMS service proposed in the present invention (that is, the MSISDN is encoded by including the SIP URI of the MSISDN-less IMS UE in the actual message portion rather than the header portion of the short message) are included. SMS service in IMS which does not exist) can coexist. Furthermore, according to the present invention, the SMS can include the SIP URI of the MSISDN-less IMS UE in the actual data portion of the short message, while maintaining compatibility with the existing SMS service without affecting user data (that is, the content of the short text). The service can be implemented. Various embodiments of the present invention described below include communication via SMS between a server and an MSISDN-less IMS UE (eg, M2M communication), communication via SMS between an MSISDN-less IMS UE and an MSISDN-less IMS UE, SMS interworking between a UE having a MSISDN (non-IMS or IMS UE) and an MSISDN-less, and the like.

 Further, in encoding the SIP URI of the MSISDN-less IMS UE to the short user data portion according to the examples of the present invention, the subject of the encoding may be the source of the short, and together or independently, the subject of the encoding It may be a network node (e.g., IP-SM-GW, etc.) in charge of the short source, or a third node (e.g., an SMS proxy server on the path through which the short is transmitted). Also, the subject that decodes the SIP URI included in the short user data part may be a short destination, and together or independently, the subject of the decoding may be a network node (e.g. IP- SM-GW, etc.) or a third node (eg, an SMS proxy server on the path through which the short message is sent). Here, the node 3 may correspond to a function performed by an existing node (IP-SM-GW, S-CSCF, etc.), may exist in the form of co-locate with an existing node, or May exist as a separate node from the existing node.

 Also, in the present invention, a "short message" may be understood as, for example, a message having a TPDU of SMS-SUBMIT type, a message having a TPDU of SMS—DELIVER type, but is not limited thereto. The principles of the invention can be equally applied to all messages related to.

In addition, the method of encoding the SIP URI of the MSISDN-less IMS UE proposed in the present invention into the short user data part, the SIP URI of the UE is Applicable in all cases that are encoded. Further, the principles of the present invention can be equally applied even when a value encoded in a short user data portion is not limited to a UE address or a SIP URI, and predetermined information is encoded in the short user data portion. have. In addition, the encoding scheme proposed by the present invention includes not only short transmission but also information (eg, a general URI or ID) in the payload portion of a control message (eg, NAS message). The principles of the present invention can also be applied. In short, examples of the present invention described below exemplarily describe a case of encoding a SIP URI of an MSISDN-less IMS UE into a short user data portion for convenience of description, but the principle proposed by the present invention is The same applies to the case where the source address or the destination address of a specific message is included in the user data (or payload) portion instead of the header of the message.

 Example 1

 This embodiment relates to a method of encoding a SIP URI of an MSISDN-less IMS UE into a short user data portion.

 An example of a SIP URI being included in an SMS Transfer Protocol Data Unit (TPDU) is S S-.

It describes with reference to the structure of a DELIVER type TPDU. However, this is merely an example, and the principles of the present invention may equally apply to other types of SMS TPDUs that include user data portions (ie, TP-UD).

 8 illustrates a layout of basic elements of an SMS-DELIVER type message. A detailed description of the elements shown in the layout of FIG. 8 may refer to Table 2 above. In FIG. 8, elements other than the user data (TP-UD) may correspond to a short header part.

 9 is a diagram illustrating an exemplary field structure associated with TP—UD. 9 (a) shows a general layout of TP—User-Data-Length (TP-UDL) and TP-User-Qata TP-UD. FIG. 9 (b) is a specific example, illustrating an uncompressed GSM

Represents the layout of TP-UDL and TP_UD for 7-bit default alphabetic data. In the example of FIGS. 9 (a) and 9 (b), the first octet corresponds to the TP-UDL and the remaining fields

Corresponds to TP-UD. Depending on the value of the TP-UDHI element (see Table 2 and FIG. 8 above), the TP-UD field may contain only short content itself, or in addition to the short content, a header (this header is distinguished from the short text header described above). It may also include user data headers defined within the TP-UD (ie, TP—UD—Header). If the TP-UDHI field is set to 0, the TP—UD field may include only short content. If the TP-UDHI field is set to 1, the first octets of the TP—UD field may include a header (ie, a TP-UD-Header). Accordingly, in the example of FIG. 9A, the TP-UD-Header field is illustrated as being present.

 In the examples of FIGS. 9A and 9B, the value of the UDL field (ie, the TP-UDL of FIG. 8) represents the total length of the TP-UD field. Referring to FIG. 9B, up to the UDHL field and up to IEIa to IEDn fields correspond to TP-UD-Headers. For example, when the value of the TP-UDHI field is set to 1, the TP-UD header may be included in the TP-UD, and the length of the TP-UD header is determined according to the value of the UDHL field. The IEIa and IEIn fields in the TP-UD-Header correspond to Information Element Identifiers, and the IEDLa, ..., IEDLn fields correspond to Length of Information Element Data, and IEDa, ..., the IEDn field corresponds to information element data. If the value of the TP- UDHI field is set to 0, the TP-UD-Header (that is, the UDHL field and the IEIa to IEDn fields) may not exist.

 Next, if 7 bit data is used and the TP-UD-Header does not end at the sept boundary, fill bits may be added after the last IED octet. This ensures that the short content itself starts at the septum boundary. If it is not 7-bit data, or if the TP-UD header does not exist, or if the TP_UD-Header exists, the fill bit may not exist. Accordingly, in the example of FIG. 9A, the filling bit field is illustrated as being optional.

Next, the short content SM may be included. As described above, when the TP_UD-Header and the Fill Bit field do not exist, the TP-UD field may exist continuously after the UDL field. This embodiment will be described with reference to the SMS message field structure (Fig. 8) and the TP-UD field structure (Fig. 9) as described above.

 10 is a diagram exemplarily illustrating a structure of a TP-UD field including a SIP URI according to an embodiment of the present invention.

 According to the present embodiment, a SIP URI may be included in an TP-UD (TP-User-Data) which is an element including a short content SM in an SMS TPDU. At this time, the SIP URI according to the same coding scheme as the scheme used for coding the short content (for example, coding scheme indicated by TP—DCS (TP-Data-Coding-Scheme) in Table 2). Can be coded. However, the present invention is not necessarily limited thereto, and the SIP URI may be coded using a technique different from that of the short content.

 As shown in Fig. 10 (a), after the short content (SM) is included in the TP-UD in the same manner as the existing method, the new oxeep or septet (after the short and or according to the coding scheme of the SIP URI) is added. Or immediately following the SIP URI. The new octet / ceptet after the short content means that if the short content does not end at the octet / ceptlet boundary, then a technique such as adding a fill bit may be applied so that the SIP URI starts at the new octet / ceptlet.

 Alternatively, as shown in FIG. 10 (b), after including the SIP URI at the beginning of the TP-UD, the short text is immediately followed by or immediately after a new oxeep or septet (short and or according to the coding scheme of the SIP URI). You can also include content. Although the example of FIG. 10 (b) may appear to exist after the TP-UD ′ header and the fill bit, the SIP URI field may be present after the TP-UD-Header and the fill bit in the example of the present invention. Immediately after the SIP URI field is present.

 In this case, information indicating whether the SIP URI is included at the end of the TP-UD (see FIG. 10 (a)) or at the beginning (see FIG. 10 (b)) is included in the header portion of the short message (that is, the TP-UD). -Header> may be included in the SMS header portion (see FIG. 8) excluding the TP-UD.

Furthermore, if both the source and destination of the short are MSISDN-less IMS UEs, then both the source and destination IMPUs (i.e., the SIP URI) are added to the short user data portion. You may need to include it. In this case, the user data part (i.e., TP-UD) may be included in the order of the source SIP URI, the destination SIP URI, and the short content, or in the order of the short content, the source SIP URI, and the destination SIP URI. You can also Alternatively, it may be included in the order of the SIP URI of the source, the short content, and the SIP URI of the destination. Here, the positions of the SIP URI of the source and the SIP URI of the destination may be interchanged.

 In addition, as described above, when the SIP URI of the MSISDN-less IMS UE is included in the TP-UD, the TP-UDL field is the same as the existing scheme, that is, the added SIP URI It may be set to a value indicating the length of the TP-UD except the length. Alternatively, the TP-UDL field may be set to a value indicating the length of the TP-UD including the length of the added SIP URI.

 Next, a method of indicating that the SIP URI of the MSISDN-less IMS UE is included in the TP-UD will be described.

 First, a method of explicitly indicating that the SIP URI of the MSISDN-less IMS UE is included in the TP-UD will be described.

^"The first scheme is a scheme for setting by defining a new value indicative of whether the SIP URI included in the RP-Message Type RPDU of containing the TPDU. MTKMessage Type Indicator indicating RP-Message Type is a 3-bit field and may be included in the first octet of the RP-Message. The coding of the MTI is defined as shown in Table 3 below. For details of the contents of Table 3, refer to standard document TS 24.011.

Table 3

 In the present invention, using the values reserved in Table 3, MSISDN-less IMS in TP-UD as well as the type of RPDU (ie, RP-DATA, RP-ACK, etc.).

A specific value for notifying that the SIP URI of the UE is included may be defined. For example, assuming that the specific value is 111, the subject decoding the RPDU having the MTI of 111 may recognize that the SIP URI is included in the TP-UD of the TPDU included in the RPDU, and may extract the same. . In this case, a specific value may be defined by distinguishing whether only the SIP URI of the source is included, only the SIP URI of the destination, or both.

 The second method is to define and set a new value indicating whether to include the SIP URI in the TP-DCS of the TPDU. The TP-DCS field may indicate a data coding scheme of the TP-UD field and may indicate a message class. As shown in Table 4 below, the TP_DCS field is a structure in which the use of bits 3, 2, 1 ᅳ 0 is determined according to a coding group indicated by bits 7, 6, 5, and 4 in an octet. For details of the contents of Table 4, reference may be made to standard document TS 23.038.

Table 4

In the present invention, using the values reserved in Table 4, MSI SDN-less IMS UE in TP-UD as well as data coding schemes (e.g., GSM 7-bit default alphabet, 8-bit data, etc.). You can define a specific value to indicate that the SIP URI is included. For example, assuming that the specific value is 10001011, a subject decoding a TPDU having a value of 10001011 of the TP-DCS may recognize that the SIP URI is included in the TP-UD of the TPDU, and may extract the same. . In this case, a specific value may be defined by distinguishing whether only the SIP URI of the source is included, only the SIP URI of the destination, or both.

In addition, the method of explicitly indicating that the SIP URI of the MSISDN-less IMS UE is included in the TP-UD according to the present invention is limited to the above-described first and second methods only. It is not limited and may define a new value in another field of the existing message header (eg TP-MTI, etc.) or add a new value in the header of the existing message format (eg RPDU, header part of the TPDU). Various measures may be applied, such as defining elements.

 If the subject decoding the SIP URI of the MSISDN—less IMS UE already knows that the SIP URI is included in the message, there is no need to explicitly indicate whether the SIP URI is included in the message.

 In addition, a method of indicating the end of the SIP URI is required so that a more accurate operation can be performed in the subject decoding the SIP URI. The present invention proposes a method of explicitly indicating the end of a SIP URI by adding a special character after the SIP URI when including the SIP URI in the message. For example, the special character is a character not used in the SIP URI and may be defined as, for example, a line feed (LF) or a carriage return (CR). Alternatively, you can use spaces to indicate the end of a SIP URI, even if you do not explicitly include special characters. In addition or independently, information indicating the length of the SIP URI included in the TP-UD may be included in the header part of the short sentence.

 In addition, when the size of the TP-UD exceeds the limited size by including the SIP URI in the TP-UD, the encoding subject may generate additional short text to include the SIP URI in the TP-UD.

 As a specific example, the first message including the SIP URI is generated in the TP-UD including the short message, and the second message including the short content not included in the TP-UD of the first message due to the size exceeded. Can be generated additionally. The additionally generated second message may be transmitted following the first message. Here, the TP-UD of the second message may also include a SIP URI.

 Alternatively, an additional message including only the SIP URI may be generated. Additionally, the generated message may be sent before or after the message containing the short content. If the first message including the short content is transmitted before the additionally generated second message (SIP URI including message), the first message itself

The SIP URI is not included, but there is a second message that contains the SIP URI. It may also contain explicit information.

 In addition, when including a SIP URI in the TP-UD, if the decoding subject of the SIP URI knows or can estimate the short host name, the "@" character and the host name in the SIP URI are TP-. May not be included in the UD. Accordingly, the size of the SIP URI information included in the TP-UD can be reduced.

 Example 2

 This embodiment is for another scheme for encoding the SIP URI of MSISDN—less IMS UE into the short user data portion.

 As described above, the SIP URI is included in TP—UD, which is an element in which a short message is included in the TPDU. The present embodiment relates to a method of including the SIP URI in the TP-User-Header part. For example, when the TP-UDHI field is set to 1, the TP-UD includes a TP-User-Header field and a Short Content (SM) field. In this case, the SIP URI may be included in the TP-User-Header portion.

 11 is a diagram exemplarily illustrating a structure of a TP-UD field including a SIP URI according to another embodiment of the present invention. 11 shows examples in which a SIP URI is included in a TP-User-Header in a TP-UD.

 As described with reference to FIG. 9B, the TP—User-Header portion may include a plurality of information elements (IE), and each information element may include an IE identifier (IEI) and an IE data length (IEDL). And IE data (IED). In the example of FIG. 11, TP—User-Header also includes n IEs (ie, IEa, IEb, ..., IEn).

 According to the present invention, the SIP URI of the MSISDN-less IMS UE may be included in the last one or more IE (s), as in the example of FIG. 11 (a), and the intermediate one, as in the example of FIG. 11 (b). It may be included in the above IE (s) or may be included in the first one or more IE (s) as in the example of FIG. 11 (c). Here, the SIP URI included in the TP-User— Header may correspond to the SIP URI of the source and / or the destination.

The examples of 11 (a) to 11 (c) may be combined. For example, the source SIP URI is

It may be included in the first plurality of IEs of the TP-User-Header consecutively. Or, the source SIP URI is at the beginning of the TP-User-Header, and the destination SIP URI is at the TP-User-Header. It may also be configured in the form included at the end.

 In addition, a new IEK Information Element Identifier) value may be defined and used to inform that the TP-UD-Header includes a SIP URI, and the existing IEI value may be reused. In this case, an IEI value indicating that the source of the SIP URI is included and an IEI value indicating that the destination of the SIP URI is included may be defined separately or may be defined as one IEI value without distinguishing it.

 In addition, when the size of the TP-UD exceeds the limited size by including the SIP URI in the TP-UD, the encoding entity may generate an additional short message to include the SIP URI in the TP-UD.

 In a specific example, a first message including a SIP URI is included in a header of a TP-UD including a short message (that is, a TP-UD-Header), and is included in the TP-UD of the first message due to an oversize. The second message including the short content that is not included may be additionally generated. The additionally generated second message may be transmitted following the first message. Here, the TP-UD of the second message may also include a SIP URI.

 Alternatively, an additional message including only the SIP URI may be generated. Additionally, the generated message may be sent before or after the message containing the short content. If the first message including the short content is transmitted before the additionally generated second message (SIP URI included message), the first message itself does not include the SIP URI, but the second message includes the SIP URI. It may also contain information that explicitly indicates that the message exists. For example, the first message may indicate that the SIP URI is included in another message by setting only the TP-UDHI value to 1 and not including the user data header information. Alternatively, the SIP URI may be notified in another message by setting the TP-UDHI value to 1 in the first message and the IEDL value to 0 while setting the IEI value to a specific value.

 In addition, when including the SIP URI in the TP— UD, if the decoding subject of the SIP URI knows or can estimate the short host name,

You may not include the "@" character and the host name in the TP-UD. Accordingly, The size of the SIP URI information included in the TP-UD can be reduced.

 Example 3

 This embodiment relates to a specific method of performing an SMS service using a TP-UD including a SIP URI as described above.

 12 is a flowchart illustrating an example of the present invention in which an MSISDN-less IMS UE transmits a short message to a server.

 In step S1201a, UE-l (llO), which is an MSISDN-less IMS UE, may encapsulate the short message in the SIP MESSAGE request message and send the short message to the server 1000 to the S_CSCF 200. That is, the body of the SIP MESSAGE request message may include an RP-DATA including an SMS header part and SMS user information encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040). Here, RP-DATA may include RP-User-Data, and RP—User-Data may include a TPDU of SMS-SUBMIT type.

 In step S1201b, the S—CSCF 200 may forward the SIP MESSAGE request message received in step S1201a to the IP # SM-GW 300 based on the stored iFC.

 In steps S1202a to S1202b, the IP-SM-GW 300 receives the SIP received in step S1201b.

The SIP 200 OK message, which is a response to the MESSAGE request message, is passed through the S-CSCF 200.

UE-l (llO) can be transmitted.

 In operation S1203, the IP-SM-GW 300 may generate a terminating short message based on the SIP MESSAGE request message received in operation S1201b. This means that the UE-l (llO) that sent the SIP MESSAGE request message does not have an MSISDN.

This is because the UE belongs to the IMS subscriber. As a specific example, IP-SM-GW 300 is

Convert TPDUs of SMS-SUBMIT type into TPDUs of SMS-DELIVER type. In addition, IP-SM-

The GW 300 includes the SIP URI, which is the IMPU of the MSISDN-less IMS UE (llO), in a short TP-UD (TP-UD). In addition, IP-SM_GW (300) is the RP-0riginat ing-Address and TP 一

Originating—Sets the Address to the MSISDN of IP_SM-CT (300).

 Here, as described in the above-described embodiments of the present invention, the SIP URI may be included before or after the short content (SM) field of the TP-UD, or in the TP-UD.

TP-UD— SIP URI may be included in the header. In the above examples of the present invention Descriptions overlapping descriptions will be omitted.

 In steps S1204a through S1204b, the IP-SM_GW 300 may transmit a SIP MESSAGE request message including the incoming short message generated in step S1203 to the server 1000. Here, as described in the above-described embodiments of the present invention, the server 1000 that has received the short message is, before or after the short content (SM) field of the TP—UD, or TP-UD—in the TP—UD. The source of the short message can be known by decoding the SIP URI of the UE-1 (110) included in the header. Descriptions overlapping descriptions of the exemplary embodiments of the present invention will be omitted.

 In steps S1205a through S1205b, the server 1000 may transmit a SIP 200 OK message, which is a response message to the request message received in step S1204b, to the IP-SM-GW 300 via the S-CSCF 200.

 In steps S1206a to S1206b, the server 1000 sends a delivery report including an acknowledgment indicating whether the short message was successfully received in step S1204b to the IP_SM-GW 300 via the S-CSCF 200. Can transmit

 In steps S1207a to S1207b, the IP-SM-CT 300 may transmit a SIP 200 OK message, which is a response message to the delivery report received in step S1206b, to the server 1000 via the S-CSCF 200.

 In step S1208, the IP-SM—GW 300 generates a submit report based on the delivery report received in step S1206b. At this time, the TPDU of the SMS-DELIVER-REP0RT type may be converted into the TPDU of the SMS—SUBMIT—REPORT type.

 In steps S1209a to S1209b, the IP-SM_GW 300 may transmit a submission report to the UE- 1 (llO) via the S-CSCF 200.

 In steps S1210a to S1210b, the UE- 1110 may transmit a SIP 200 0K message, which is a response message to the submission report received in step S1208b, to the IP-SM-GW 300 via the S-CSCF 200. .

13 is a flowchart illustrating an example of the present invention in which an MSISDN-less IMS UE transmits a short message to an MSISDN-less IMS UE. ^'

In step S13 () l, UE-l (llO), which is an MSISDN-less IMS UE, is an MSISDN-less IMS UE. In order to send a short message to the UE- 2800, the short message may be encapsulated in a SIP MESSAGE request message and transmitted to the S-CSCF-200. That is, the body of the SIP MESSAGE request message may include an RP-DATA including an SMS header part and SMS user information encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040). Here, the RP-DATA may include RP-User—Data, and the RP-User-Data may include a TPDU of SMS-SUBMIT type.

 Here, the UE-K110 selects a SIP URI (ie, source address) which is its IMPU and a SIP UI (destination address) which is an IMPU of the UE- 2800 according to the method described in the above-described embodiments of the present invention. It may be included in TP-UD (TP-User-Data). For example, SIP URIs (source and destination address) may be included before or after the short content (SM) field of the TP-UD, or within the TP-UD-Header within the TP-UD (source and destination address). It may also include. Descriptions overlapping descriptions of the exemplary embodiments of the present invention will be omitted.

 In step S1302, S—CSCF-U200 may forward the SIP MESSAGE request message received in step S13 () l to IP_SM-CT 300 based on the stored iFC.

 In steps S1303 to S1304, the IP-SM ᅳ GW 30 may transmit a SIP 202 Accepted message, which is a good answer to the SIP MESSAGE request message received in step S1302, to the UE ᅳ 1 110 via the S-CSCF_1 200. have.

 In steps S1305 to S1306, the IP-SM-GW 300 may transmit an Ack message, which is a good answer to the short message received in step S1302, to the UE-l (llO) via the S-CSCF-K200. The Ack message is encapsulated in a SIP MESSAGE request message, and the body of the SIP MESSAGE request message may include an RP-ACK encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040).

 In steps S1307 and S1308, UE-l (llO) sends a SIP 202 Accepted message, which is a response to the SIP request message including the RP-ACK received in step S1306, to the S-CSCF-.

1-200 can be transmitted to the IP-SM—GW (300).

 In step S1309, the IP-SM-GW 300 is the short destination received by the step S1302.

To obtain routing information for the UE-2 800, the IP-SM-OT 300 sends an HSS 400 to the HSS 400. Send user data request message. At this time, the identifier information of the UE-2 800 used by the IP-SM-GW 300 decodes the SIP URI of the UE-2 800 encoded in the short TP-UD received in step S1302. It can be obtained by the IP-SM_GW (300).

 In operation S1310, the HSS 400 may reply to the user data request message received in operation S1309 to transmit a user data answer message to the IP-SM—GW 300. The user data reply message may include the IMS registration status of the UE-2 800 and information about the S ᅳ CSCF (ie, the S-CSCF-2 700) in charge of the UE-2 800. .

 In step S1311, the IP-SM-GW 300 sends a SIP to the UE-2 800 for sending a short message.

The short message may be encapsulated in the MESSAGE request message and transmitted to the S-CSCF_2 700 in charge of the UE-2. That is, the body of the SIP MESSAGE request message may include an RP-DATA including an SMS header part and SMS user information encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040). Here, the RP-DATA may include RP-User-Data, and the RP-User-Data may include a TPDU of SMS—DELIVER type.

 Here, the short-live TP-UD transmitted in step S1311 is a SIP URI that is an IMPU of UE-l (llO) included in step S13 by UE-1110 in step S13. It may be included in (TP-User-Data) as it is. Here, the specific scheme of including the SIP URI in the TP-UD is the same as described in the above-described various embodiments of the present invention, duplicate description will be omitted.

 In operation S1312, S—CSCF-K700 may forward the SIP MESSAGE request message received in operation S1311 to the UE- 2800. The UE- 2800 decodes the SIP URI of the short source that is encoded in the TP_UD, so that the UE-l (llO) can transmit the short message.

 In steps S1313 to S1314, the UE-2 800 receives the SIP received in step S1312.

The SIP 202 Accepted message, which is a response to the MESSAGE request message, may be transmitted to the IP-SM-G 300 via the C_CSCF-2 700.

 In step S1315, UE-2 (800) is an answer to the short message received in step S1312.

Ack message can be sent to the S—CSCF-2 (200). The Ack message is SIP MESSAGE Encapsulated in the request message, the body of the SIP MESSAGE request message may include an RP-ACK encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040).

 Here, the RP-ACK may include a TPDU of a DELIVER REPORT type or a TPDU of a SUBMIT REPORT type. UE-2800 may include in the TP-UD of the TPDU the SIP URI which is the IMPU of UE-1, which is the source of the short message, and the SIP URI which is its IMPU, which is the destination of the short message, received in step S1312. Here, since the specific scheme for including the SIP URI in the TP-UD is the same as described in the above-described various embodiments of the present invention, redundant description is omitted.

 In step S1316, the S-CSCF-2 700 IP-checks the Ack message received in step S1315.

It may forward to the SM-CT 300.

 In steps S1317 to S1318, the IP-SM_GW 300 may transmit a SIP 202 Accepted message, which is a response to the received Ack message, to the UE-2 800 via the S_CSCF-2 700.

 In step S1319, in order to obtain routing information for UE-l (llO), which is the source of a short message, the IP-SM-GW 300 receives the Ack message received in step S1316. Send a user data request message to 400. At this time, the identifier information of the UE-l (llO) used by the IP-SM 一 CT 300 decodes the SIP URI of the UE-K110 encoded in the TP-UD of the Ack message received in step S1316. It can be obtained by the 1P-SM-GW (300).

 In operation S1320, the HSS 400 may transmit a user data answer message to the IP—SM-GW 300 in response to the user data request message received in operation S1319. The user data reply message may include information about the IMS registration status of the UE-l (llO) and the S-CSCF (ie, the S-CSCF-K200) in charge of the UE-l (llO).

In step S1321, IP-SM-GW ( 300) is ^"a UE- received in step S1302

Status report including short transmission status information from 1 (110)

In order to send a report) to the UE-l (llO), the status report can be encapsulated in a SIP MESSAGE request message and transmitted to the S-CSCF-K200 in charge of the UE-l (llO). Ie SIP The body of the MESSAGE request message may include RP-DATA including an SMS header portion and SMS user information encoded according to a predetermined rule (for example, a rule defined in 3GPP TS 23.040). Here, the RP-DATA may include RP— User-Data, and the RP-User- Data may include a TPDU of SMS-STATUS-REPORT type.

 Here, the IP-SM-GW 300 is a UE- which is a short source of the status report.

The SIP URI, which is the IMPU of 1110, and the SIP URI, which is the IMPU of UE-2800, which are short destinations, may be included in the TFMJD of the TPDU of the status report type. Here, the specific scheme of including the SIP URI in the TP-UD is the same as described in the above-described various embodiments of the present invention, duplicate description will be omitted.

 In step S1322, the S-CSCF-K200 may forward the status report message received in step S1321 to the UE- 1 (llO). The UE-K110 decodes and obtains the SIP URI of the short destination decoded in the TP-UD, thereby knowing that the status report received in step S1321 is the transmission status information for the short message transmitted in step S13 () l. Can be.

 In steps S1323 to S1324, the UE-l (llO) transmits a SIP 202 Accepted message, which is a response to the status report message received in step S1322, to the IP-SM-GW 300 via the S-CSCF-1 200. Can be.

 Items described in the various embodiments of the present invention described above may be applied independently or two or more embodiments may be applied at the same time. According to the invention, it does not have an MSISDN which is an identifier associated with IMS subscriber information

An essential and specific method for implementing a method in which an IMS terminal can transmit and receive an IP-based SMS is provided. Accordingly, while coexisting with the existing SMS service, it is possible to support the IP-based SMS service for the MS ISDN- less IMS UE without affecting user data.

 14 is a diagram showing the configuration of a preferred embodiment of a transmission and reception apparatus according to an example of the present invention.

Referring to FIG. 14, the transceiver 1400 according to the present invention may include transmission / reception modules 1410, a processor 1420, and a memory 1430. The transmission / reception modules 1410 transmit various signals, data, and information to an external device, and various signals, data to an external device. And receive information. The transceiver 1400 may be connected to an external device by wire and / or wirelessly. The processor 1420 may control operations of the entire transceiver device 1400, and may be configured to perform a function of the transceiver device 1400 to process and process information to be transmitted and received with an external device. The memory 1430 may store the computed information and the like for a predetermined time and may be replaced with a component such as a buffer (not shown).

 The transmission and reception apparatus 1400 according to an embodiment of the present invention may be configured to perform a short message service (SMS) operation. The processor 1420 of the transceiver device 1400 may be configured to generate a message in which information indicating one or more of a source address or a destination address is included in the user data portion. In addition, the processor 1420 may be configured to transmit the generated message through the transmission and reception modes. Here, the source or destination address may be in the form of an IP-based identifier. In addition, the source or destination device may be a device without an identifier (eg, MSISDN) based on subscriber information.

 The transmitting and receiving device 1400 according to an embodiment of the present invention is an SMS (Short Message)

Service) operation. The processor 1420 of the transceiver device 1400 may be configured to receive a message through a transceiver module. In addition, the processor 1420 may be configured to obtain information indicating one or more of a source address or a destination address included in the user data portion of the received message. Here, the source or destination address may be in the form of an IP-based identifier. The source or destination device may be a device without an identifier (eg, MSISDN) based on subscriber information.

 In addition, the specific configuration of the above-described transmission and reception apparatus 1400 may be implemented so that the matters described in the above-described various embodiments of the present invention may be independently applied or two or more embodiments may be applied at the same time. Omit the description.

Embodiments of the present invention described above may be implemented through various means. For example, the embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof. In the case of a hardware implementation, a method according to embodiments of the present invention may include one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), and Programmable Logic Devices (PLDs). Field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and the like.

 In the case of implementation by firmware or software, the method according to the embodiments of the present invention may be implemented in the form of modules, procedures, or functions for performing the functions or operations described above. The software code may be stored in a memory unit and driven by a processor. The memory unit may be located inside or outside the processor, and may exchange data with the processor by various known means.

 The detailed description of the preferred embodiments of the invention disclosed as described above is provided to enable those skilled in the art to implement and practice the invention. Although the above has been described with reference to preferred embodiments of the present invention, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of the present invention. For example, those skilled in the art can use each configuration described in the above embodiments in a manner that combines with each other. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The invention can be embodied in other specific forms without departing from the spirit and essential features of the invention. Accordingly, the above detailed description should not be interpreted as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention. The present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. Also, by combining claims that do not have an explicit citation relationship in the claims, Embodiments may be constituted or incorporated into new claims by post-application correction. Industrial Applicability

 Embodiments of the present invention as described above may be applied to various mobile communication systems.

Claims

[Range of request]

 [Claim 11

 As a method of performing a Short Message Service (SMS) operation,

 Generating a message including information indicative of at least one of a source address or a destination address in a user data portion; And

 Sending the message;

 The source address or the destination address in the form of an IP-based identifier.

 [Claim 2]

 The method of claim 1,

 And the field including the source address or the destination address is consecutively located in a field including the content of user data included in the user data portion.

 [Claim 3]

 The method of claim 2,

 And the field containing the source address or the destination address is located before or after the field containing the content of the user data.

[Claim 4]

 The method of claim 1,

 The user data portion includes a user data header,

 And a field containing the source address or the destination address is included in the user data header.

 [Claim 5]

 According to the term 11

 And information indicating at least one of a location or a length of a field including the source address or the destination address is included in a header of the message.

 [Claim 6]

The method of claim 1, And the user data associated with the source address or the destination address is continuously transmitted via an additional message.

 [Claim 7]

 The method of claim 6,

 And the message including the information indicating the source address or the destination address does not include the content of the user data, and the content of the user data is transmitted through the additional message.

 [Claim 8]

 The method of claim 1,

 The user data portion is a Transfer Protocol-User Data (TP-UD) field,

How to perform SMS operation.

 [Claim 9]

 The method of claim 4,

 And the user data header is a TP-User Data Header (TP-UDH) field.

 [Claim 10]

 The method of claim 1,

 Whether the source address or the destination address is included in the user data portion of the message is indicated by using MTKMessage Type Indicator (RPK) of the RPDlKRelay Protocol Data Unit (RPD) or TPDU-Dat a Coding Scheme (TP-DCS) of the message. How to perform the SMS operation.

 [Claim 11]

 The method of claim 1,

 And information indicative of at least one of the source address or the destination address is coded by the same coding scheme applied to the user data.

 [Claim 12]

 The method of claim 1,

The source address or the destination address is a Session Initiation (SIP) Protocol) URI (Uniform Resource Identifier)

 The source device or the destination device is a MSISDN (Mobile Subscriber)

Method of performing SMS operation, which is a device without an Integrated Services Digital Network Number.

 [Claim 13]

 As a method of performing a Short Message Service (SMS) operation,

 Receiving a message; Obtaining information indicative of at least one of a source address or a destination address included in the user data portion of the received message;

 The source address or the destination address has a form of an IP-based identifier;

How to perform SMS operation.

 [Claim 14]

 As a device that performs Short Message Service (SMS) operation,

 Transmitting and receiving module for transmitting and receiving a signal with the outside; And

 It includes a processor for controlling the transceiver device,

 The processor is,

 Generate a message including information indicative of at least one of an originating address or a destination address in a user data portion;

 Send the message through the transmit / receive modules, wherein the source address or the destination address is in the form of an IP-based identifier;

Device for performing SMS operations.

 [Claim 15]

 As a device that performs Short Message Service (SMS) operation,

 Transmitting and receiving module for transmitting and receiving a signal with the outside; And

 It includes a processor for controlling the transceiver device,

 The processor is,

 Receive a message through the transmit and receive modules;

Obtain information indicating at least one of a source address or a destination address included in the user data portion of the received message, And the source address or the destination address is in the form of an IP-based identifier.