WO2006005252A1 - Procede de traitement pour notification de retransmission dans un service de messagerie multimedia - Google Patents

Procede de traitement pour notification de retransmission dans un service de messagerie multimedia Download PDF

Info

Publication number
WO2006005252A1
WO2006005252A1 PCT/CN2005/001000 CN2005001000W WO2006005252A1 WO 2006005252 A1 WO2006005252 A1 WO 2006005252A1 CN 2005001000 W CN2005001000 W CN 2005001000W WO 2006005252 A1 WO2006005252 A1 WO 2006005252A1
Authority
WO
WIPO (PCT)
Prior art keywords
push notification
field
message
short message
character
Prior art date
Application number
PCT/CN2005/001000
Other languages
English (en)
French (fr)
Inventor
Weiming Cheng
Dawei Li
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to DE602005011304T priority Critical patent/DE602005011304D1/de
Priority to EP05766712A priority patent/EP1781048B1/en
Priority to BRPI0513198-7A priority patent/BRPI0513198A/pt
Publication of WO2006005252A1 publication Critical patent/WO2006005252A1/zh
Priority to US11/619,757 priority patent/US7899476B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]

Definitions

  • the present invention relates to multimedia information communication technologies, and in particular, to a method for processing push notification (PUSH) notifications in a multimedia message service.
  • PUSH push notification
  • Multimedia Messaging Service is a further development of Short Message Service (SMS) and picture messaging, which enables the delivery of comprehensive content and information including images, audio information, video information, data and text.
  • SMS Short Message Service
  • the multimedia information service can realize instant multimedia information transmission between the mobile terminal and the mobile terminal and the Internet.
  • the Multimedia Message Service Center is the network element responsible for sending multimedia messages over the network.
  • the MMSC receives the multimedia message sent by the MMS terminal, the value-added service provider (VASP) or the mail server to the MMS terminal, and starts the delivery process.
  • the delivery process includes two stages: a PUSH notification process and a message extraction process.
  • the current PUSH notification process of the MMS service is mainly that the MMSC carries the PUSH notification in one or more short messages and sends the information to the receiver terminal, where the PUSH notification includes related information about the multimedia message: the receiver terminal needs to extract the multimedia message. Addressing information, sender identification, multimedia message subject and recipient terminal address information, etc., wherein the addressing information includes an MMSC address and a unique identifier of the multimedia message in the MMSC.
  • the receiving terminal After receiving the short message and synthesizing the PUSH notification, the receiving terminal starts the message extraction process, that is, according to the addressing information contained in the PUSH notification, initiates a message extraction request to the MMSC storing the multimedia message, and extracts the multimedia message.
  • the PUSH notification message includes the following parts:
  • TID transaction identifier, length 1 byte
  • Type indicates the message type. When the value is 0x06, it indicates that the message is a PUSH notification, and the length is 1 byte.
  • HeaderLen indicates the length of the message header, encoded by uintvar, with a length of 1 byte;
  • ContentType indicates the type of the message body.
  • PUSH notification of the MMS there are two representation methods: one is represented by a 32-byte string application/vnd.wap.mms-message, and the other is It is represented by a binary code of 0x3E, which is 1 byte, and in most cases, a string representation;
  • Headers indicates the content of the header, the length is equal to the difference between the value of the HeaderLen field and the length of the ContentType field;
  • X-Mms-Message-Type indicates the data unit type of the multimedia message service protocol.
  • the value of the PUSH notification message is 130, and the length is 1 byte.
  • X-Mms-Transaction-ID The internal identifier assigned by the MMSC to ensure that the receiver can correctly extract the multimedia message.
  • the length and encoding rules are allocated and recognized by the MMSC, and the length is variable.
  • X-Mms-MMS-Version Indicates the version number of the MMS, which is 2 bytes in length;
  • Subject indicates the subject of the multimedia message. After the UTF-8 encoding, when the length of the multimedia message is greater than or equal to 31 bytes, the minimum length of the Subject is 6 bytes, otherwise the minimum length is 5 bytes.
  • X-Mms- Message-Class indicates the category of the multimedia message, for example, the multimedia message belongs to a personal, advertisement or information category, and has a length of 2 bytes;
  • X-Mms-Message-Size Indicates the length of the multimedia message, which is 5 or 6 bytes long after encoding with a long integer.
  • X-Mms-Expiry indicates the validity period of the multimedia message, the length is 7 or 8 bytes;
  • X-Mms-Content-Location indicates a Uniform Resource Identifier (URI) address of the multimedia message, including at least an MMSC address and a transaction identifier of the multimedia message, where the MMSC address may be an IP address and a port number, or may be a change Long domain name, the length of this part is variable.
  • URI Uniform Resource Identifier
  • the PUSH notification processed by the above format is sent by the initiator of the multimedia message to the receiver through multiple intermediate links, and then through the message extraction process, thereby completing the transmission of a multimedia message. Since multimedia messages are transmitted similarly in Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA) 95, CDMA2000, and other networks, Therefore, the following describes the transmission process of the multimedia message in the GSM network as an example.
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • WCDMA Wideband Code Division Multiple Access
  • CDMA Code Division Multiple Access
  • the transmission of the multimedia message can be divided into two cases: the delivery by the wireless application gateway (WAPGW) and the direct delivery by the MMSC.
  • WAPGW wireless application gateway
  • MMSC direct delivery by the MMSC.
  • FIG. 1 shows a process of transmitting a multimedia message to a receiver through a WAPGW, such as an MMS terminal, a VASP, or a mail server, using a multimedia message of a PUSH notification in an existing format, including:
  • Step 11 ⁇ 12 The initiator of the multimedia message submits the multimedia message to be sent to the MMSC. After receiving the multimedia message, the MMSC starts the PUSH notification process and sends a PUSH notification to the receiver MMS terminal.
  • the specific process of issuing a PUSH notification includes the following steps:
  • Step 1201. The MMSC sends a push-message message including the PUSH notification to the WAPGW, and records the number of times the step is performed.
  • Step 1202. After receiving the push-message message, the WAPGW returns a PUSH response message push-response to the MMSC.
  • Step 1203. The WAPGW uses the interface protocol between the WAPGW and the short message system to perform short message encapsulation on the PUSH notification in the push-message message, and then the short message system. Send the submit message submit_sm and record the number of times this step was performed.
  • SMSC short message system packet short message center
  • UCP user datagram protocol
  • CIMD computer interface information transmission. Agreement
  • Step 1204. After receiving the submit message submit_sm, the short message system returns a submit response message submit_sm_resp to the WAPGW.
  • the short message system sends a short message to the receiving MSC MMS terminal.
  • Step 1205. The short message system determines the home location register (HLR) address of the receiver MMS terminal by submitting the address information of the receiver included in the PUSH notification in the submit_sm message, and sends a route request message map_sri_for to the HLR. Sm_req, and record the number of times this step is performed.
  • HLR home location register
  • Step 1206 After receiving the route request message map_sri_for_sm_req, the HLR returns a route response message map_sri_for_sm_resp to the short message system including the address of the mobile switching center (MSC) where the receiver is currently located.
  • MSC mobile switching center
  • the short message system sends a short message containing the PUSH notification to the receiver through the short message sending request message map_mt_fwd_sm_req according to the routing information in the route response message map_sri_for_sm_resp;
  • the message system returns a short message sending response message map_mt_fWd_sm_resp, indicating whether the PUSH notification is successfully delivered, and then determining whether the SMSC receives a short message sending response message map_mt_ indicating that the PUSH notification is successfully delivered within a predetermined time.
  • Fd_sm_resp if yes, go to step 1209; otherwise, the short message system selects whether to resend and resend according to the internal resend policy. If retransmission, it determines whether the number of times of performing step 1205 exceeds a predetermined number of times. If the predetermined number of times exceeds the predetermined number of times, the short message system determines that the PUSH notification fails to be delivered, and performs step 1209. If the predetermined number of times is not exceeded, the retransmission policy is adopted, and the process returns to step 1205. At this point, the process of sending a short message to the receiving MSC/MMS terminal by the short message system is completed.
  • Steps 1209 - 1210 The short message system sends a delivery report message deliver_sm to the WAPGW, indicating whether the PUSH notification is successfully delivered; after receiving the delivery report message deliver_sm, the WAPGW returns a delivery response to the short message system, delivery_sm_resp And then, the WAPGW determines whether the PUSH notification is successfully delivered according to the content of the received delivery report message. If yes, step 1211 is performed; otherwise, according to the internal retransmission policy, whether to resend, if resending, determining the execution step If the number of times exceeds a predetermined number of times, the WAPGW determines that the PUSH notification fails to be delivered, and performs step 1211. If the predetermined number of times is not exceeded, the WAPGW adopts a retransmission policy, and returns to step 1203.
  • Steps 1211 to 1212. The WAPGW sends a result notification message resultnotification-message to the MMSC, indicating whether the PUSH notification is successfully sent. After receiving the result notification message, the MMSC returns a result notification response message resultnotification-response to the WAPGW, and according to the result notification message The content is judged whether the PUSH notification is successfully delivered. If yes, the PUSH notification process is ended; otherwise, the MMSC selects whether to resend and retransmit according to the internal retransmission policy.
  • step 1201 determines whether the number of executions of step 1201 exceeds If the predetermined number of times exceeds the predetermined number of times, the MMSC determines that the PUSH notification fails to be delivered, ends the transmission process of the PUSH notification, determines that the PUSH notification is failed to be sent, and performs step 17, if the predetermined number of times is not exceeded, the MMSC takes the weight Send the policy, return to step 1201.
  • Step 13 ⁇ 16 The MMSC interacts with the receiving MSC/MMS terminal to perform message extraction. Step 17.
  • the MMSC sends a multimedia message transmission status report to the initiator, indicating whether the receiver successfully receives the multimedia message. After the PUSH notification is sent, the initiator and the receiver extract the multimedia message according to the message extraction process of steps 13 to 17, thereby completing the transmission of a multimedia message.
  • the above is the flow of delivering a multimedia message through the WAPGW.
  • the following describes the process of directly transmitting a multimedia message by the MMSC.
  • Figure 2 shows the process of transmitting a multimedia message through the MMSC directly to the receiver using the PUSH notification in the existing format, including:
  • Step 21 ⁇ 22 The initiator of the multimedia message submits the multimedia message to the MMSC. After receiving the multimedia message, the MMSC starts the PUSH notification process and sends a PUSH notification to the receiver.
  • the PUSH notification process includes the following steps:
  • Step 2201. The MMSC encapsulates the PUSH notification into a short message by using an interface protocol that communicates with the short message system, and then sends the submission message submit_sm containing the PUSH notification to the short message system using the interface protocol, and records the number of times of performing this step. .
  • Step 2202 After receiving the submit message submit_sm, the short message system returns a submit response submit_sm_resp to the MMSC.
  • the short message system sends a short message to the recipient.
  • Step 2203. The short message system determines the HLR address to which the receiver belongs by submitting the address information of the receiver included in the PUSH notification in the submit message sm, and sends a route request message map_sri_for_sm_req to the HLR, and records The number of times this step was performed.
  • Step 2204 After receiving the route request message map_sri_for_sm_req, the HLR returns a route response message map_sri_for_sm_resp to the short message system, indicating the current MSC address of the receiver.
  • Step 2205 - 2206 The short message system sends the request message map_mt_fd_sm_req to the receiving party via the short message sending request message map_mt_fd_sm_req according to the routing information in the route response message map-sri-for_smjresp.
  • Short message ; receiving direction short message system
  • the system returns a short message sending response message map_mt_fwd__sm_resp, indicating whether the PUSH notification is successfully delivered.
  • the short message system determines whether the short message sending response message map_mt_fd_sm_resp is successfully sent by the PUSH in a predetermined time. If yes, step 2207 is performed; otherwise, the short message system is internally heavy.
  • Sending a policy selecting whether to resend and resend the time, if resending, determining whether the number of times of performing step 2203 exceeds a predetermined number of times. If the predetermined number of times is exceeded, the short message system determines that the PUSH notification fails to be delivered, and performs the next If the predetermined number of times is not exceeded, the short message system adopts a retransmission policy, and returns to step 2203.
  • Deliver_sm_resp and judge whether the PUSH notification is successfully delivered according to the content of the delivery report message, and if yes, end the PUSH notification process; otherwise, the MMSC selects whether to resend and resend according to the internal retransmission policy. If the retransmission is performed, it is determined whether the number of times of performing the step 2201 exceeds a predetermined number of times.
  • the MMSC determines that the PUSH notification fails to be delivered, ends the sending process of the multimedia message, determines that the multimedia message is failed to be sent, and executes Step 27: If the predetermined number of times is not exceeded, the MMSC adopts a retransmission policy, and returns to step 2201.
  • Step 23 ⁇ 26 The MMSC interacts with the receiving MSC/MMS terminal to perform message extraction.
  • Step 27 The MMSC sends a multimedia message transmission status report to the initiator to indicate whether the receiver successfully receives the multimedia message.
  • the initiator and the receiver After the PUSH notification is sent, the initiator and the receiver extract the multimedia message according to the message extraction process of steps 23 to 27, thereby completing the transmission of a multimedia message.
  • the networking mode of FIG. 2 can be adopted, that is, the MMSC directly communicates with various mobile networks or short message systems of fixed networks by using corresponding interface protocols, thereby completing the transmission of multimedia messages.
  • the MMSC can directly connect to the short message center (MC) of the CDMA to complete the transmission of the multimedia message.
  • MC short message center
  • the PUSH notification process is crucial for the entire MMS service, and is a necessary condition for ensuring that the receiver normally obtains the message.
  • the content of the PUSH notification exceeds the maximum length that can be accommodated by a short message, it can be split into multiple short messages by the WAPGW or the short message system.
  • the above steps 1203 ⁇ 1210 may be performed multiple times to complete the sending of a PUSH notification; when the splitting is performed by the short message system, the above steps 1205 ⁇ 1208 or 2203 ⁇ 2206 may be performed multiple times to complete a PUSH.
  • the sending of the notification is crucial for the entire MMS service, and is a necessary condition for ensuring that the receiver normally obtains the message.
  • the disadvantages of the existing PUSH notification processing method are:
  • a PUSH notification is split into multiple short messages when transmitting, and the receiver must After all the short messages waiting for the same PUSH notification arrive, they are reassembled into a complete PUSH notification, so the delay of completing the PUSH notification transmission is longer and the efficiency is lower.
  • a PUSH notification is split into multiple short messages, causing too many intermediate links to be sent, and the cost of operation is relatively high.
  • an object of the present invention is to provide a method for processing a PUSH notification, which shortens the delay between PUSH notifications in transmission and reception, and improves the efficiency and success rate of PUSH notification transmission.
  • the present invention provides a method for processing a PUSH notification in a multimedia message service, the method comprising the following steps:
  • step B determining whether the PUSH notification can be carried by a short message, if yes, using a short message to carry the PUSH notification, and performing step C, otherwise, using two short messages to carry the PUSH notification, and performing step C;
  • the uncompressed field in step A is:
  • the PUSH notification removes 10 fields other than the field, the internal identifier, the initiator, and the subject indicating the message body type.
  • the method for compressing the message body type field in step A is as follows: the message body type field is represented by a binary code occupying 1 byte.
  • A1 Discarding the multimedia message service center identification part in the internal identifier, and expressing the time part in seconds;
  • Step B determining whether the PUSH notification can be carried by a short message To: determine whether the length of the current PUSH notification is less than 140 bytes, and if so, determine that the PUSH notification can be carried by a short message; otherwise, it is determined that the PUSH notification cannot be carried by a short message.
  • step C2 Determine whether the Subject field can use a character set or encoding method that is shorter than the currently used encoding length. If yes, the character field or encoding method with a shorter encoding length is used to represent the field, and step C3 is performed; otherwise, Directly perform step C3;
  • the method for placing the coding sequence corresponding to a single character in the character string encoding part into the PUSH notification in the step C3 includes:
  • C31 Determine the number of coded bytes used to represent a displayable character in the currently used coding mode
  • the present invention has the following beneficial effects:
  • the present invention ensures that the 10 uncompressed fields and the ContentType and X-Mms-Transaction-ID fields in the PUSH notification are included to ensure the integrity of the key information in the PUSH notification;
  • the compressible field in the PUSH notification of the present invention adopts a representation of less bytes, which reduces the overall length of the PUSH notification. Therefore, at most two short messages can be used to carry the PUSH notification during the transmission process, and the transmitted data is reduced. Quantity, shortening the delay and improving the efficiency of transmission;
  • the PUSH notification of the present invention uses up to two short message bearers, which effectively reduces the number of executions of the short message delivery process in the process of transmitting multimedia messages, reduces the execution time of intermediate links, and reduces operating costs.
  • one or two short messages can be used to carry the PUSH notification.
  • a short message fails to be sent, it is easier to determine the short message that should be retransmitted. Therefore, in the presence of the WAPGW, the MMSC and the MMSC are coordinated. The difficulty of the WAPGW retransmission mechanism is reduced, and the success rate of the PUSH notification is improved, thereby improving the service quality of the multimedia message service.
  • FIG. 1 is a flow chart of transmitting a multimedia message through a WAPGW.
  • Figure 2 is a flow chart for directly transmitting a multimedia message through the MMSC.
  • FIG. 3 is a general flowchart of a PUSH notification processing method according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of a compression processing Subject field in an embodiment of the present invention. Mode for carrying out the invention
  • the invention is a processing method for a PUSH notification in a multimedia message service, and the basic idea is: selecting a part of an optional or variable length field in a PUSH notification, and compressing the PUSH notification so that the PUSH notification can be used with no more than two short Message bearer.
  • the processing method of the PUSH notification in the multimedia message service in this embodiment includes the following steps:
  • Step 301 Put the uncompressed field into the PUSH notification.
  • the PUSH notification contains a total of 14 fields, except for ContentType, X-Mms-Transaction-ID, From, and Subject. The remaining 10 fields cannot change the representation, and the words occupied by it cannot be compressed. Section number. Therefore, when processing the PUSH notification, the MMSC puts 10 uncompressed fields into the PUSH notification through this step.
  • Step 302. Compress the ContentType and X-Mms-Transaction-ID fields and put them into the PUSH notification.
  • the ContentType field in the PUSH notification of the International Standard Specification has two representation methods: one is represented by a 32-byte string application/vnd.wap.mms-message, and the other is represented by a 1-byte binary code 0x3E. . In this step, the field is represented by a binary code of 1 byte to save 31 bytes.
  • X-Mms-Transaction-ID is usually: Time + Multimedia Message Service Center Identity (MMSCID) + Message (MSG) Sequence Number + Terminal Number + Session Number.
  • MMSCID Multimedia Message Service Center Identity
  • MSG Message
  • Sequence Number Terminal Number + Session Number.
  • Time Indicates the time when the multimedia message is sent.
  • the format is: month, month, day, hour, minute, minute, second (mmddHHMMSS), occupying 10 bytes;
  • MMSCID used to identify the MMSC, occupying 6 bytes
  • MSG sequence number The serial number of the message, occupying 5 bytes;
  • Terminal number The last two digits of the mobile number, used for legality ⁇ r, occupying 2 bytes;
  • Session sequence number The internal resource allocated by the MMSC to the multimedia message, occupying 5 bytes. The above five parts have a total of 28 bytes. Since X-Mms-Transaction-ID is mainly used by technicians for research work, the following compression strategy can be applied to this field:
  • Step 303 Determine whether the length of the PUSH notification is less than 140 bytes. If yes, go to step 304; otherwise, go to step 305.
  • this step is to determine whether a short message can be used to carry PUSH notifications.
  • Step 304 The MMSC carries the PUSH notification with a short message, and then performs step 306.
  • the MMSC carries the PUSH notification with two short messages. In this step, each field is first placed in the first short message, and then placed in the second short message.
  • Step 306 - 307. Determine whether the short message still exists in the short message, if yes, execute step 308; otherwise, discard the field not placed in the PUSH notification, and end the compression processing flow of the PUSH notification.
  • the method for determining whether the short message still exists in the short message is as follows: determining 10 uncompressed fields and the compressed ContentType and X-Mms-Transaction-ID fields in total Whether the number of occupied bytes is less than 140, and if so, it is determined that there is a free byte in the short message; otherwise, it is determined that there is no free byte in the short message.
  • Step 308. Compress the From and Subject fields according to the number of free bytes of the short message.
  • the MMSC determines whether the From and Subject fields are placed and the compression processing mode of the Subject field according to the number of free bytes of the short message. Specifically, 'while, when the number of spare bytes is enough to include the From field, it is placed in the PUSH notification, and then the Subject field is compressed according to the remaining number of spare bytes; otherwise, the compression processing flow of the PUSH notification is ended. .
  • the process of compressing the From and Subject fields in this step specifically includes the following steps:
  • Steps 401 ⁇ 4 03. The MMSC determines whether the spare byte of the short message contains enough the From field, and if so, puts the From field into the PUSH notification; otherwise, discards the From field and the Subject field, and ends the compression process From and The flow of the Subject field.
  • the purpose of the three steps here is: Only when the short bytes of the short message can be When the From field is all included, it is considered to be placed in the PUSH notification; in the remaining cases, the From field is selected to be discarded.
  • Steps 404 to 405. Determine whether the Subject field can use a character set and encoding method that is shorter than the currently used encoding length. If yes, compress the Subject field with a shorter character length and encoding method, and execute step 406. Otherwise, step 406 is directly executed.
  • the format of the Subject field is: String encoding / character set encoding. This field can be expressed in a variety of character sets and encodings, and different character sets and encoding methods take up different numbers of bytes. Therefore, the method of compressing the Subject field in this step is: Converting the character set or encoding mode with a large number of bytes into a character set or encoding method with a small number of bytes without changing the content expressed by the field. For example: Convert the currently used 6-byte UTF-8 encoded character to a 2-byte GB 2312 encoded character.
  • Step 406 - 408 Determine whether the vacant byte of the short message is enough to be placed in the character set encoding mode part of the Subject field and the code corresponding to at least one character in the Subject, and if so, according to the remaining number of bytes of the short message, first put Enter the character set encoding mode part, and then sequentially put the encoding corresponding to the single character representing the text content in the Subject field; No, J, discard the Subject field, and end the process of compressing the From and Subject fields.
  • the character set encoding mode of the Subject field is used to indicate the character set and encoding mode used for the encoding of the Subject text content. This part must be completely preserved when it exists, and cannot be truncated.
  • the character string encoding part is the specific content of the Subject field, and the character set and encoding method specified by the character set encoding mode part are adopted. If the character set used is N-byte encoded, the encoding per N bytes represents a displayable character. For example, each character in the ANSI character set uses 1-byte encoding, and each character in the Unicode character set uses 6-byte UTF-8 encoding.
  • the MMSC When the vacant byte in the short message can contain the character set encoding mode part of the Subject field and the code corresponding to at least one character, the MMSC first puts the character set encoding mode part into the PUSH notification, and then according to the remaining short message. The number of bytes, starting from the first character, puts the code corresponding to each character into the PUSH notification in order.
  • the Subject field is discarded because: If there is no encoding indicating the contents of the Subject, even if there is a part of the character set encoding mode, It is also useless; if the free bytes are not enough to contain the character set encoding part, the Subject field is discarded and the process of compressing the From and Subject fields is ended.
  • each N bytes represents a displayable character
  • it when truncating the character string encoding part in this step, it must ensure that the inserted character string is encoded as an integer multiple of N bytes, that is, guarantee The last N bytes placed are the encoding of the same original character. If the encoding of the last original character cannot be fully contained, then all encoded bytes of that character are discarded. For example, if the short message has a remaining K bytes, the MMSC first performs a rounding operation on the quotient of K and N; assuming that the rounded result is m, the first character to the mth character of the Subject string encoding portion are The code is placed in the PUSH notification.
  • the compression of the ContentType field is performed by the WAPGW, and the processing of the other respective compressed fields is performed by the MMSC; and when the multimedia message is directly sent by the MMSC to the short message system, The processing of all compressed fields is performed by the MMSC.
  • the PUSH notification in the multimedia message service is processed by the method of the present invention, which effectively shortens the overall length and reduces the number of occupied bytes, thereby simplifying the process of transmitting multimedia messages.
  • the multimedia message notified by the compressed PUSH can perform the transmission of one PUSH notification at the maximum of two steps 1203 to 1210 shown in FIG. 1 when transmitting through the WAPGW; at the time of being directly sent by the short message system, at most Twice
  • the transmission of a PUSH notification can be completed by steps 1205 to 1208 shown in FIG. 1 or steps 2203 to 2206 shown in FIG. 2.
  • the PUSH notification in each of the above networks can adopt the processing method of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

一种多媒体消息业务中推送通知的处理方法
技术领域
本发明涉及多媒体信息通讯技术， 尤其涉及一种多媒体消息业务中 推送（PUSH )通知的处理方法。 发明背景
多媒体消息业务（MMS )是短消息服务（SMS )和图片信息传递的 进一步发展， 它使得包括图像、 音频信息、 视频信息、 数据以及文本等 功能全面的内容和信息得以传递。 多媒体信息业务可实现即时的手机端 到端、 手机终端与互联网之间的多媒体信息传送。 多媒体消息业务中心 ( MMSC )就是负责在网络上发送多媒体消息的网元。
在多媒体消息的传送过程中， MMSC接收到 MMS终端、 增值业务 提供商（VASP )或者邮件服务器发给 MMS终端的多媒体消息时， 启动 下发流程。 该下发流程包括 PUSH通知流程和消息提取流程两个阶段。 目前 MMS业务的 PUSH通知流程主要是 MMSC将 PUSH通知携带于一 条或者多条短消息中， 发送给接收方终端， 该 PUSH通知中包含有关多 媒体消息的相关信息： 接收方终端提取多媒体消息所需的寻址信息、 发 送方标识、 多媒体消息主题和接收方终端地址信息等， 其中寻址信息包 括 MMSC地址和多媒体消息在 MMSC中的唯一标识。 接收方终端收到 全部短消息并合成 PUSH通知后， 便启动消息提取过程， 即根据 PUSH 通知中所包含的寻址信息， 向存储多媒体消息的 MMSC发起消息提取 请求， 并提取多媒体消息。
在国际标准规范中， PUSH通知消息包括如下部分：
(1) TID: 事务标识， 长度为 1字节； (2) Type: 表明消息类型， 当取值为 0x06时表明该消息是 PUSH通 知， 长度为 1字节；
(3) HeaderLen: 表明消息头的长度， 采用 uintvar编码， 长度为 1字 节；
(4) ContentType:表明消息体的类型，对于 MMS的 PUSH通知而言， 存在 两种表示 方 法 ： 一种是用 占 32 字 节 的 字 符 串 application/vnd.wap.mms-message表示,另一种是用占 1字节的二进制编 码 0x3E表示， 绝大多数情况下采用字符串表示法；
(5) Headers: 表明消息头的内容， 长度等于 HeaderLen字段的取值与 ContentType字段长度之差；
(6) X-Mms-Message-Type: 表明多媒体消息业务协议数据单元类型， PUSH通知消息取值为 130, 长度为 1字节；
(7) X-Mms-Transaction-ID: MMSC为保证接收方能够正确提取多媒 体消息而分配的内部标识， 其长度和编码规则由 MMSC 自行分配和识 别， 长度可变;
(8) X-Mms-MMS-Version: 表明 MMS的版本号， 长度为 2字节；
(9) From: 表明多媒体消息的发起者， 其长度最小为 4字节；
(10) Subject: 表明多媒体消息的主题， 经 UTF-8编码后， 多媒体消息 的长度大于等于 31字节时， Subject的最小长度为 6字节， 否则其最小 长度为 5字节；
(11) X-Mms- Message-Class: 表明多媒体消息的类别， 例如该多媒体 消息属于个人、 广告或者信息类别等， 长度为 2字节；
(12) X-Mms-Message-Size: 表明多媒体消息的长度， 采用长整型编码 后其长度为 5或 6字节；
(13) X-Mms-Expiry: 表明多媒体消息的有效期， 长度为 7或 8字节； (14) X-Mms-Content-Location： 表明多媒体消息的统一资源标识符 ( URI )地址， 至少包括 MMSC地址和多媒体消息的事务标识， 其中 MMSC地址可以是 IP地址和端口号， 也可以是变长域名， 该部分的长 度可变。
采用上述格式进行处理的 PUSH通知， 由多媒体消息的发起方经过 多个中间环节发送给接收方， 再经过消息提取过程， 进而完成一条多媒 体消息的发送。 由于多媒体消息在全球移动通信网 （GSM )、 通用无线 分组业务网 （GPRS )、 宽带码分多址（WCDMA )、 码分多址（CDMA ) 95、 CDMA2000和其他网络中的发送过程较为类似， 因此下面以多媒体 消息在 GSM网络中的发送过程为例进行说明。
多媒体消息的发送可以分为通过无线应用网关 （WAPGW ) 下发和 由 MMSC直接下发两种情况。
图 1所示为釆用现有格式的 PUSH通知的多媒体消息，由诸如 MMS 终端、 VASP或邮件服务器等发起方， 通过 WAPGW向接收方发送一条 多媒体消息的过程， 包括：
步骤 11 ~ 12. 多媒体消息的发起方将要发送的多媒体消息提交给 MMSC; MMSC收到多媒体消息后， 启动 PUSH通知流程， 向接收方 MMS终端下发 PUSH通知。
下发 PUSH通知的具体过程包括以下步骤：
步骤 1201. MMSC 向 WAPGW 发送包含 PUSH 通知在内的 push-message消息， 并记录执行本步骤的次数。
步骤 1202. WAPGW收到 push-message消息后，向 MMSC返回 PUSH 响应消息 push-response。
步骤 1203. WAPGW使用 WAPGW与短消息系统之间的接口协议对 push-message消息中的 PUSH通知进行短消息封装， 而后向短消息系统 发送提交消息 submit— sm， 并记录执行本步骤的次数。
这里的短消息系统包短消息中心（ SMSC )和短消息网关，而 WAPGW 与短消息系统之间的接口协议可以是短消息点对点协议（SMPP )、 用户 数据报协议（UCP )、 计算机接口信息发送协议（CIMD )或其他同类协 议。
步驟 1204.短消息系统收到提交消息 submit— sm后 , 向 WAPGW返 回提交响应消息 submit— sm_resp。
此后， 短消息系统向接收方 MSC MMS终端下发短消息。
步骤 1205. 短消息系统通过提交消息 submit—sm中 PUSH通知所包 含的接收方地址信息，确定接收方 MMS终端的归属位置寄存器（HLR ) 地址， 向该 HLR发送路由请求消息 map— sri— for— sm_req, 并记录执行本 步骤的次数。
步骤 1206. HLR收到路由请求消息 map_sri一 for— sm— req后， 向短消 息系统返回包括接收方当前所在移动交换中心（MSC )地址的路由响应 消息 map— sri— for_sm— resp。
步骤 1207 - 1208. 短 消 息 系 统才艮据路 由 响 应 消 息 map— sri— for—sm— resp中的路由信息， 向接收方通过短消息发送请求消息 map_mt_fwd_sm_req下发含有 PUSH通知的短消息； 接收方向短消息系 统返回短消息发送响应消息 map— mt—fWd_sm— resp, 指明 PUSH通知是 否下发成功，而后判断 SMSC在预定时间内是否收到表明 PUSH通知下 发成功的短消息发送响应消息 map— mt—f d—sm_resp,如果是，则执行步 骤 1209; 否则， 短消息系统才艮据内部重发策略， 选择是否重发和重发的 时间， 如果重发， 则判断执行步骤 1205 的次数是否超过预定次数， 如 果超过预定次数， 则短消息系统判定 PUSH通知下发失败， 执行步骤 1209, 如果没有超过预定次数， 则采取重发策略， 返回执行步骤 1205。 至此， 完成了短消息系统向接收方 MSC/MMS终端下发短消息的流 程。
步骤 1209 - 1210. 短消息系统向 WAPGW 发送递送报告消息 deliver_sm, 指明 PUSH通知是否下发成功； WAPGW收到递送报告消 息 deliver— sm后， 向短消息系统返回递送 4艮告响应 deliver— sm—resp , 然 后 WAPGW根据接收到的递送报告消息的内容，判断 PUSH通知是否下 发成功， 如果是， 则执行步骤 1211; 否则， 根据内部重发策略， 决定是 否重发， 如果重发， 则判断执行步骤 1203的次数是否超过预定的次数， 如果超过预定次数， 则 WAPGW判定 PUSH通知下发失败， 并执行步骤 1211 , 如果没有超过预定的次数， 则 WAPGW采取重发策略， 返回步骤 1203。
步骤 1211 ~ 1212. WAPGW 向— MMSC 发送结果通知消息 resultnotification-message , 指明 PUSH通知是否下发成功； MMSC收到 结果通知消 息后 ， 向 WAPGW 返回结果通知响应 消 息 resultnotification-response， 并根据结果通知消息的内容判断 PUSH通知 是否下发成功， 如果是， 则结束 PUSH通知流程； 否则， MMSC根据内 部重发策略， 选择是否重发以及重发的时间， 如果重发， 则判断执行步 骤 1201的次数是否超过预定的次数， 如果超过预定的次数， 则 MMSC 认定 PUSH通知下发失败，结束该 PUSH通知的发送流程，认定该 PUSH 通知发送失败， 并执行步骤 17, 如果没有超过预定的次数， 则 MMSC 采取重发策略， 返回步骤 1201。
至此， 完成 PUSH通知流程。
步骤 13 ~ 16. MMSC与接收方 MSC/MMS终端交互，进行消息提取。 步骤 17. MMSC向发起方发送多媒体消息发送状态报告， 指明接收 方是否成功接收多媒体消息。 当 PUSH通知下发完毕后， 发起方与接收方按照步骤 13至步骤 17 的消息提取流程提取多媒体消息， 从而完成一条多媒体消息的发送。
以上为通过 WAPGW下发多媒体消息的流程， 下面说明由 MMSC 直接发送多媒体消息的过程。
图 2所示为使用现有格式的 PUSH通知的多媒体消息，通过 MMSC 直接向接收方发送的过程， 包括：
步骤 21 ~ 22. 多媒体消息的发起方将多媒体消息提交给 MMSC; MMSC收到多媒体消息后， 启动 PUSH通知流程， 向接收方下发 PUSH 通知。
本处 PUSH通知过程包括以下步骤：
步骤 2201. MMSC使用与短消息系统进行通讯的接口协议，将 PUSH 通知封装成短消息， 然后使用该接口协议向短消息系统发送含有 PUSH 通知的提交消息 submit— sm， 并记录执行本步骤的次数。
步骤 2202.短消息系统收到提交消息 submit— sm后，向 MMSC返回 提交响应 submit— sm_resp。
此后， 短消息系统向接收方下发短消息。
步骤 2203. 短消息系统通过提交消息 submit— sm中 PUSH通知所包 含的接收方地址信息， 确定接收方归属的 HLR地址 , 向该 HLR发送路 由请求消息 map— sri—for— sm—req， 并记录执行本步骤的次数。
步骤 2204. HLR收到路由请求消息 map— sri—for— sm—req后， 向短消 息系统返回路由响应消息 map—sri— for_sm— resp, 指明接收方当前所在的 MSC地址。
步骤 2205 - 2206. 短 消 息 系 统才艮据路 由 响 应 消 息 map一 sri—for— smjresp中的路由信息， 向接收方通过短消息发送请求消息 map— mt—f d— sm—req下发含有 PUSH通知的短消息； 接收方向短消息系 统返回短消息发送响应消息 map_mt_fwd_— sm— resp, 指明 PUSH通知是 否下发成功。 而后短消息系统判断在预定的时间内是否收到 PUSH通知 下发成功的短消息发送响应消息 map— mt— f d— sm— resp,如果是，则执行 步骤 2207; 否则， 短消息系统 居内部重发策略， 选择是否重发和重发 的时间， 如果重发， 则判断执行步骤 2203的次数是否超过预定的次数， 如果超过预定次数， 则短消息系统认定 PUSH通知下发失败， 并执行下 一步骤， 如果没有超过预定的次数， 则短消息系统采取重发策略， 返回 步驟 2203。
至此， 完成了短消息系统向接收方下发短消息的流程。
步骤 2207 ~ 2208. 短消息系统向 MMSC 发送递送^ =艮告消息 deliver— sm, 指明 PUSH通知是否下发成功； MMSC收到递送报告消息 deliver— sm后， 向短消息系统返回递送 4艮告响应 deliver— sm— resp, 并才艮 据递送报告消息的内容判断 PUSH通知是否下发成功， 如果是， 则结束 PUSH通知流程； 否则， MMSC根据内部重发策略， 选择是否重发和重 发的时间， 如果重发， 则判断执行步骤 2201 的次数是否超过预定的次 数， 如果超过预定的次数， 则 MMSC认定 PUSH通知下发失败， 结束 该多媒体消息的发送流程，认定该多媒体消息发送失败，并执行步骤 27, 如果没有超过预定的次数， 则 MMSC采取重发策略， 返回步骤 2201。
至此， 完成了 PUSH通知流程。
步骤 23 ~ 26. MMSC与接收方 MSC/MMS终端交互，进行消息提取。 步骤 27. MMSC向发起方发送多媒体消息发送状态报告， 指明接收 方是否成功接收多媒体消息。
当 PUSH通知下发完毕后， 发起方与接收方按照步骤 23至步骤 27 的消息提取流程提取多媒体消息， 从而完成一条多媒体消息的发送。
在 GSM、 GPRS、 WCDMA、 CDMA95、 CDMA2000或其他各种移 动网络和固定网络中， 均可采用图 2的组网方式， 即 MMSC使用相应 的接口协议直接与各种移动网络或固定网络的短消息系统进行通讯 , 从 而完成多媒体消息的发送。 例如在 CDMA 网络中， MMSC 可直接与 CDMA的短消息中心 （MC )连接， 完成多媒体消息的发送。
由上述两个流程可见， PUSH通知流程对于整个 MMS业务至关重 要， 是保证接收方正常获取消息的必要条件。 当 PUSH通知的内容超过 一条短消息所能够容纳的最大长度时，可以由 WAPGW或者短消息系统 将其拆分成多条短消息后进行下发。 当拆分由 WAPGW进行时， 多次执 行上述步骤 1203 ~ 1210才能完成一条 PUSH通知的发送； 当拆分由短 消息系统进行时， 多次执行上述步骤 1205 ~ 1208或者 2203 ~ 2206才能 完成一条 PUSH通知的发送。
具体而言， 现有 PUSH通知处理方法的缺点是：
1、 由于一条短消息最长为 140字节， 而现有的 PUSH通知消息的总 长度超过了 140字节， 因此在发送时要将一个 PUSH通知拆分到多条短 消息中， 接收方须等待承载同一 PUSH通知的所有短消息到达后， 才将 其重新组合成完整的 PUSH通知，因此完成 PUSH通知传送的时延较长， 效率较低。
2、 采用多条短消息承载一条 PUSH通知， 使得 PUSH通知流程的 中间环节较为复杂。 另外， 当某条短消息发送失败时， 在存在 WAPGW 的情况下， MMSC和 WAPGW的重发机制难以协调一致， 无法准确的 确定应该重发的短消息， 造成 PUSH通知的成功率较低， 大大影响了多 媒体消息业务的服务质量。
3、一条 PUSH通知拆分成多条短消息引起发送的中间环节过多，运 营的成本也比较高。 发明内容
有鉴于此， 本发明的目的在于提供一种 PUSH通知的处理方法， 缩 短 PUSH通知在发送与接收之间的时延， 提高 PUSH通知发送的效率和 成功率》
为实现上述目的， 本发明提供了一种多媒体消息业务中 PUSH通知 的处理方法， 该方法包括以下步骤：
A、 将 PUSH通知中的非压缩字段放入 PUSH通知中， 并将表明消 息体类型的字段和为保证接收方正确提取多媒体消息而分配的内部标 识字段压缩处理后放入 PUSH通知中；
B、 判断 PUSH通知是否能用一条短消息承载， 如果是， 则用一条 短消息承载 PUSH通知，并执行步骤 C，否则，用两条短消息承载 PUSH 通知， 并执行步骤 C;
C、 判断短消息中是否仍然存在空余字节， 如果是， 则根据该短消 息的空余字节数， 决定是否将发起者 From字段放入 PUSH通知中， 以 及决定是否压缩处理主题 Subject字段并放入 PUSH通知中， 否则， 将 未放入 PUSH通知中的字段丢弃， 并结束本 PUSH通知的处理流程。
其中， 步骤 A所述非压缩字段为： PUSH通知中除去表明消息体类 型的字段、 内部标识、 发起者和主题以外的 10个字段。
其中， 步骤 A所述将表明消息体类型字段压缩处理的方法为： 用占 用 1字节的二进制编码表示所述消息体类型字段。
其中， 步骤 A所述将内部标识字段压缩处理的方法为：
A1. 丟弃所述内部标识中的多媒体消息业务中心标识部分， 并将时 间部分用秒数表示；
A2. 将经过步骤 A1处理后的内部标识字段转换为 64进制编码。 其中， 步骤 B所述判断 PUSH通知是否能用一条短消息承载的方法 为：判断当前 PUSH通知的长度是否小于 140字节，如果是，则判定 PUSH 通知能够用一条短消息承载； 否则， 判定 PUSH通知无法用一条短消息 承载。
C1. 判断短消息的空余字节是否足够包含 From字段， 如果是， 则 将 From字段放入 PUSH通知中， 并继续执行步骤 C2, 否则，丟弃 From 字段和 Subject字段， 并结束本 PUSH通知的处理流程；
C2. 判断 Subject字段是否能够釆用比目前使用的编码长度更短的 字符集或编码方式， 如果是， 则采用编码长度更短的字符集或编码方式 表示该字段， 并执行步骤 C3 , 否则， 直接执行步骤 C3;
C3. 判断包含了 From 字段的短消息中的空余字节是否足够放入 Subject字段的字符集编码方式部分和该 Subject字段的字符串编码部分 中至少一个字符的编码， 如果是， 则根据短消息的剩余字节数， 首先将 字符集编码方式部分放入 PUSH通知中， 然后将字符串编码部分中的单 个字符所对应的编码顺序放入 PUSH通知中， 否则， 丢弃 Subject字段， 并结束本 PUSH通知的处理流程。
其中， 步骤 C3 所述将字符串编码部分中的单个字符所对应的编码 顺序放入 PUSH通知中的方法包括：
C31. 确定当前所釆用的编码方式下表示一个可显示字符所用的编 码字节数；
C32. 根据包含了字符集编码方式部分的短消息中的空余字节数和 步骤 C31所确定的编码字节数， 计算出该短消息所能容纳的可显示字符 数 m;
C33. 将 Subject字段中字符串编码部分的第 1个字符至第 m个字符 所对应的编码依次放入 PUSH通知中。
应用本发明， 将 PUSH通知中的部分字段进行压缩处理， 使其占用 较少的字节数，则在发送的过程中，至多使用两条短消息就可承载 PUSH 通知。 具体而言， 本发明具有如下有益效果：
1、 本发明确保将 PUSH通知中的 10个非压缩字段及 ContentType 和 X-Mms-Transaction-ID字段包含在内， 保证了 PUSH通知中关键信息 的完整性；
2、本发明 PUSH通知中的可压缩字段采用较少字节的表示方式，减 少了 PUSH通知的总体长度， 因此在发送过程中至多使用两条短消息就 可承载 PUSH通知， 减少了传输的数据量， 缩短了时延， 提高了传输的 效率；
3、本发明的 PUSH通知最多使用两条短消息承载，有效地减少多媒 体消息发送过程中短消息下发流程的执行次数， 减少中间环节的执行时 间， 降低运营成本。
4、本发明中使用一条或两条短消息就可承载 PUSH通知，在某条短 消息发送失败的情况下， 较为容易确定应该重发的短消息， 因此在存在 WAPGW的情况下， 协调 MMSC和 WAPGW的重发机制的难度降低， 提高了 PUSH通知的成功率， 从而提高了多媒体消息业务的服务质量。 附图简要说明
图 1为通过 WAPGW发送多媒体消息的流程图。
图 2为通过 MMSC直接发送多媒体消息的流程图。
图 3为本发明实施例中 PUSH通知处理方法的总体流程图。
图 4为本发明实施例中压缩处理 Subject字段的流程图。 实施本发明的方式
为使本发明的目的、 技术方案更加清楚明白， 以下参照附图并举实 施例， 对本发明做进一步的详细说明。
本发明为一种多媒体消息业务中 PUSH通知的处理方法， 其基本思 想是： 选择 PUSH通知中的部分可选或变长字段， 并对其进行压缩， 使 得 PUSH通知能够用不超过两条的短消息承载。
下面以图 3和图 4所示的过程为实施例， 说明本发明中 PUSH通知 的处理方法。
如图 3所示， 本实施例多媒体消息业务中 PUSH通知的处理方法包 括以下步骤：
步骤 301. 将非压缩字段放入 PUSH通知中。
在国际标准规范中， PUSH 通知共包含 14 个字段， 其中除了 ContentType、 X-Mms-Transaction-ID、 From和 Subject以夕卜， 其余的 10 个字段均无法改变表示方式， 无法压缩其占用的字节数。 因此在处理 PUSH通知时， MMSC通过本步骤将 10个非压缩字段放入到 PUSH通 知中。
步骤 302. 将 ContentType和 X-Mms-Transaction-ID字段压缩处理后 放入 PUSH通知中。
国际标准规范的 PUSH通知中的 ContentType字段有两种表示方法： 一种是用 32字节的字符串 application/vnd.wap.mms-message表示， 另一 种是用 1字节的二进制编码 0x3E表示。 本步骤中将该字段用占 1字节 的二进制编码表示， 以节省 31个字节。
X-Mms-Transaction-ID 的结构通常为： 时间 +多媒体消息业务中心 标识（MMSCID ) +消息（MSG )序号+终端尾号 +会话序号。 其中各 部分的作用及占用的字节数为： 时间： 表明多媒体消息的发送时间， 格式为： 月月日日时时分分秒 秒（ mmddHHMMSS )， 占用 10字节；
MMSCID: 用以识别 MMSC, 占用 6字节；
MSG序号： 消息的序列号， 占用 5字节；
终端尾号： 手机号码的最后两位， 用以进行合法性校 ^r， 占用 2字 节；
会话序号： MMSC给多媒体消息分配的内部资源， 占用 5字节。 上述五部分共 28个字节。由于 X-Mms-Transaction-ID主要用于技术 人员进行研究工作时使用， 因此可以对该字段采取如下压缩策略：
a. 去掉 MMSCID: 由于终端在接收到多媒体消息时，手机会获取到 一个域名， 并根据该域名找到 MMSC, 因此这一部分可以省略；
b. 将时间格式由目前占用 10个字节的 mmddHHMMSS变换为一个 8字节长的整型数值， 即用秒数表示。 由于每年的 1月 1 日均会对时间 进行更新，所以其最大值为： 24小时 χ60分 χ60秒 χ366天 =31622400秒。
经过上述的操作后， X-Mms-Transaction-ID字段的结构为： 时间 （8 字节） + MSG序号 （5字节） +终端尾号 （2字节） +会话序号 （5字 节） = 20字节。 再将上述 20字节转换成整数， 其最大值为 102G-1 , 采 用 16进制编码约为 18个字节， 再转换成 64进制， 则为 12个字节。 可 见， 压缩处理后共节省了 16个字节。
步骤 303. 判断 PUSH通知的长度是否小于 140字节， 如果是， 则 执行步骤 304; 否则， 执行步骤 305。
由于一条短消息最多可容纳 140字节， 则执行本步骤的目的在于确 定能否用一条短消息承载 PUSH通知。
步骤 304. MMSC用一条短消息承载 PUSH通知 ,然后执行步骤 306。 步骤 305. MMSC用两条短消息承载 PUSH通知。 本步骤中首先将各个字段放入第一条短消息， 待放满 '后再放入第二 条短消息。
步骤 306 - 307. 判断短消息是否仍然存在空余字节， 如果是， 则执 行步骤 308; 否则，将未放入 PUSH通知中的字段丢弃， 并结束本 PUSH 通知的压缩处理流程。
在能够采用一条短消息承载 PUSH通知的情况下， 本步骤判断短消 息是否仍然存在空余字节的方法为： 判断 10个非压缩字段及压缩后的 ContentType和 X-Mms-Transaction-ID字段总共所占用的字节数是否小 于 140， 如果是， 则判定短消息中存在空余字节； 否则， 判定短消息中 不存在空余字节。
在采用两条短消息承载 PUSH通知的情况下， 本步骤中只判断后面 一条短消息是否还存在空余字节。
步骤 308.根据短消息的空余字节数， 压缩处理 From和 Subject字 段。
本步骤 MMSC根据短消息的空余字节数决定 From和 Subject字段 是否放入以及 Subject字段的压缩处理方式。 具体而 '言， 当空余的字节 数足够包含 From字段时， 则将其放入 PUSH通知中， 而后再根据剩下 的空余字节数压缩处理 Subject字段； 否则， 结束 PUSH通知的压缩处 理流程。
如图 4所示， 本步骤压缩处理 From和 Subject字段的过程具体包括 以下步骤：
步骤 401 ~ 403. MMSC判断短消息的空余字节是否足够包含 From 字段， 如果是， 则将 From字段放入 PUSH通知中； 否则， 将 From字段 和 Subject字段丟弃， 并结束压缩处理 From和 Subject字段的流程。
此处三个步骤的目的在于： 只有当短消息存在的空余字节能够将 From字段全部包含在内时， 才考虑将其放入 PUSH通知中； 其余的情 况下均选择将 From字段丟弃。
步骤 404 ~ 405. 判断 Subject字段是否能够釆用比目前使用的编码 长度更短的字符集和编码方式， 如果是， 则采用编码长度更短的字符集 和编码方式压缩 Subject字段， 并执行步骤 406; 否则， 直接执行步骤 406。
Subject字段的格式为： 字符串编码 /字符集编码方式。该字段可以采 用多种字符集和编码方式来表达其具体内容， 而不同的字符集和编码方 式所占用的字节数也不同。 所以本步骤压缩 Subject字段的方法为： 在 不改变该字段所表达内容的前提下， 将占用字节数较多的字符集或编码 方式转换为字节数较少的字符集或编码方式。 例如： 将目前使用的占用 6字节的 UTF-8编码字符转换为占用 2字节的 GB 2312编码字符。
步骤 406 - 408. 判断短消息的空余字节是否足够放入 Subject字段 的字符集编码方式部分和 Subject 中至少一个字符所对应的编码， 如果 是， 则根据短消息的剩余字节数， 首先放入字符集编码方式部分， 然后 顺序放入 Subject字段中表示文本内容的单个字符所对应的编码； 否贝， J， 丢弃 Subject字段， 并结束压缩处理 From和 Subject字段的流程。
本实施例中压缩处理 Subject字段的核心思想是对其进行截断，以缩 短其长度。 具体而言， Subject 字段的字符集编码方式部分用于表示 Subject文本内容编码所采用的字符集和编码方式，该部分在存在时必须 完全保留， 不能截断。 字符串编码部分为 Subject字段的具体内容， 采 用字符集编码方式部分所规定的字符集和编码方式。 如果所采用的字符 集为 N字节编码， 则每 N个字节的编码表示一个可显示的字符。 例如 ANSI字符集中每个字符采用 1字节编码、 Unicode字符集中每个字符采 用 6字节的 UTF-8编码等。 本处当短消息中的空余字节能够包含 Subject 字段的字符集编码方 式部分和至少一个字符所对应的编码， 则 MMSC 首先将字符集编码方 式部分放入 PUSH通知中， 然后根据短消息剩余的字节数， 从第一个字 符开始， 按顺序将每个字符所对应的编码放入 PUSH通知中。 如果空余 字节只能包含字符集编码方式部分、 而无法完全包含第一个字符的编 码， 则丢弃 Subject字段， 原因在于： 如果没有任何表明 Subject内容的 编码， 即使存在其字符集编码方式部分， 也是毫无用途的； 如果空余字 节不足以包含字符集编码方式部分， 则丟弃 Subject字段并结束压缩处 理 From和 Subject字段的流程。
需要注意的是： 由于每 N个字节的编码表示一个可显示的字符， 所 以本步骤对字符串编码部分进行截断时， 必须保证放入的字符串编码为 N字节的整数倍， 即保证放入的最后 N个字节是同一原始字符的编码。 如果最后一个原始字符的编码不能被完全包含， 则丢弃该字符的所有编 码字节。 例如短消息中空余 K个字节， 则 MMSC首先对 K与 N之商进 行取整运算； 假设取整后的结果为 m, 则将 Subject字符串编码部分的 第 1个字符至第 m个字符的编码放入 PUSH通知中。
在本发明的 PUSH通知处理方法中， 当通过 WAPGW发送多媒体消 息时， ContentType字段的压缩由 WAPGW进行， 其它各个压缩字段的 处理由 MMSC进行； 而当多媒体消息由 MMSC直接向短消息系统发送 时， 全部压缩字段的处理均由 MMSC进行。
多媒体消息业务中的 PUSH通知采用本发明的方法进行处理后，有 效地缩短了总体长度、 减少了占用的字节数， 从而简化了多媒体消息的 发送流程。 采用经过压缩处理的 PUSH 通知的多媒体消息， 在通过 WAPGW发送时， 至多执行两次图 1所示的步骤 1203 ~ 1210就能完成 一条 PUSH通知的发送； 在直接由短消息系统发送时， 至多执行两次图 1所示的步骤 1205 ~ 1208或者图 2所示的步骤 2203 2206就能完成一 条 PUSH通知的发送。
由于在 GSM、 GPRS、 WCDMA、 CDMA95、 CDMA2000或其他各 种移动网络和固定网络中， 均提供多媒体消息业务， 所以上述各网络中 的 PUSH通知均可采用本发明的处理方法。
以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡 在本发明的精神和原则之内， 所做的任何修改、 等同替换、 改进等， 均 应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种多媒体消息业务中推送 PUSH通知的处理方法， 其特征在 于， 该方法包括以下步骤：
A、 将 PUSH通知中的非压缩字段放入 PUSH通知中， 并将表明消 息体类型的字段和为保证接收方正确提取多媒体消息而分配的内部标 识字段压缩处理后放入 PUSH通知中；
B、 判断 PUSH通知是否能用一条短消息承载， 如果是， 则用一条 短消息承载 PUSH通知，并执行步骤 C,否则，用两条短消息承载 PUSH 通知， 并执行步骤 C;
C、 判断短消息中是否仍然存在空余字节， 如果是， 则根据该短消 息的空余字节数， 决定是否将发起者 From字段放入 PUSH通知中， 以 及决定是否压缩处理主题 Subject字段并放入 PUSH通知中， 否则， 将 未放入 PUSH通知中的字段丢弃， 并结束本 PUSH通知的处理流程。
2、 根据权利要求 1所述的方法， 其特征在于， 步骤 A所述非压缩 字段为： PUSH通知中除去表明消息体类型的字段、 内部标识、 发起者 和主题以外的 10个字段。
3、 根据权利要求 1所述的方法， 其特征在于， 步骤 A所述将表明 消息体类型字段压缩处理的方法为： 用占用 1字节的二进制编码表示所 述消息体类型字段。
4、 根据权利要求 1所述的方法， 其特征在于， 步骤 A所述将内部 标识字段压缩处理的方法为：
A1. 丟弃所述内部标识中的多媒体消息业务中心标识部分， 并将时 间部分用秒数表示；
A2. 将经过步骤 A1处理后的内部标识字段转换为 64进制编码。
5、根据权利要求 1所述的方法，其特征在于，步骤 B所述判断 PUSH 通知是否能用一条短消息承载的方法为： 判断当 I PUSH通知的长度是 否小于 140字节， 如果是， 则判定 PUSH通知能够用一条短消息承载； 否则， 判定 PUSH通知无法用一条短消息承载。
6、 根据权利要求 1所述的方法， 其特征在于， 步骤 C所述决定是 否将发起者 From字段放入 PUSH通知中，以及决定是否压缩处理 Subject 字段并放入 PUSH通知中的方法包括：
C1. 判断短消息的空余字节是否足够包含 From字段， 如果是， 则 将 From字段放入 PUSH通知中， 并继续执行步骤 C2， 否则，丢弃 From 字段和 Subject字段， 并结束本 PUSH通知的处理流程；
C2. 判断 Subject字段是否能够采用比目前使用的编码长度更短的 字符集或编码方式， 如果是， 则采用编码长度更短的字符集或编码方式 表示该字段， 并执行步骤 C3 , 否则， 直接执行步骤 C3;
C3. 判断包含了 From 字段的短消息中的空余字节是否足够放入 Subject字段的字符集编码方式部分和该 Subject字段的字符串编码部分 中至少一个字符的编码， 如果是， 则根据短消息的剩余字节数， 首先将 字符集编码方式部分放入 PUSH通知中， 然后将字符串编码部分中的单 个字符所对应的编码顺序放入 PUSH通知中， 否则， 丟弃 Subject字段， 并结束本 PUSH通知的处理流程。
7、 根据权利要求 6所述的方法， 其特征在于， 步骤 C3所述将字符
括：
C31. 确定当前所采用的编码方式下表示一个可显示字符所用的编 码字节数；
C32. 根据包含了字符集编码方式部分的短消息中的空余字节数和 步骤 C31所确定的编码字节数，计算出该短消息所能容纳的可显示字符 数 m;
C33. 将 Subject字段中字符串编码部分的第 1个字符至第 m个字符 所对应的编码依次放入 PUSH通知中。
PCT/CN2005/001000 2004-07-09 2005-07-07 Procede de traitement pour notification de retransmission dans un service de messagerie multimedia WO2006005252A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE602005011304T DE602005011304D1 (de) 2004-07-09 2005-07-07 Verarbeitungsverfahren für push-anzeigen in multimedia-nachrichtenübermittlungsdiensten
EP05766712A EP1781048B1 (en) 2004-07-09 2005-07-07 Processing method for push notification in multimedia messaging service
BRPI0513198-7A BRPI0513198A (pt) 2004-07-09 2005-07-07 método para processar notificação push em serviço de mensagem multimìdia
US11/619,757 US7899476B2 (en) 2004-07-09 2007-01-04 Method for processing push notification in multimedia message service

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410069703.6 2004-07-09
CNB2004100697036A CN100349474C (zh) 2004-07-09 2004-07-09 一种多媒体消息业务中推送通知的处理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/619,757 Continuation US7899476B2 (en) 2004-07-09 2007-01-04 Method for processing push notification in multimedia message service

Publications (1)

Publication Number Publication Date
WO2006005252A1 true WO2006005252A1 (fr) 2006-01-19

Family

ID=35783514

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001000 WO2006005252A1 (fr) 2004-07-09 2005-07-07 Procede de traitement pour notification de retransmission dans un service de messagerie multimedia

Country Status (9)

Country Link
US (1) US7899476B2 (zh)
EP (1) EP1781048B1 (zh)
CN (1) CN100349474C (zh)
AT (1) ATE415788T1 (zh)
BR (1) BRPI0513198A (zh)
DE (1) DE602005011304D1 (zh)
ES (1) ES2315888T3 (zh)
RU (1) RU2339185C1 (zh)
WO (1) WO2006005252A1 (zh)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100455053C (zh) * 2006-07-04 2009-01-21 华为技术有限公司 提供mms服务的方法
CN101136837A (zh) * 2007-09-21 2008-03-05 华为技术有限公司 推送消息的控制方法、装置和系统
KR100979202B1 (ko) * 2007-11-21 2010-09-01 한국전자통신연구원 메시지 서비스 방법 및 메시지 서비스 시스템
US8521809B2 (en) * 2009-07-31 2013-08-27 Z2Live, Inc. Mobile device notification controls system and method
US9439057B2 (en) * 2009-09-30 2016-09-06 Alcatel Lucent Registration notification for SMS over LTE
CN101695057A (zh) * 2009-10-20 2010-04-14 中兴通讯股份有限公司 多媒体消息发送方法、发送设备和域名解析服务器
CN101674548B (zh) * 2009-10-21 2014-12-17 中兴通讯股份有限公司 一种投递报告的分配方法及系统
US8763089B2 (en) * 2010-01-12 2014-06-24 Microsoft Corporation Flexible authentication and authorization mechanism
CN102123359B (zh) * 2011-03-31 2014-12-10 中兴通讯股份有限公司 彩信的转发方法、装置、系统及彩信接收装置
US10769923B2 (en) 2011-05-24 2020-09-08 Verna Ip Holdings, Llc Digitized voice alerts
US8970400B2 (en) 2011-05-24 2015-03-03 Verna Ip Holdings, Llc Unmanned vehicle civil communications systems and methods
US8265938B1 (en) 2011-05-24 2012-09-11 Verna Ip Holdings, Llc Voice alert methods, systems and processor-readable media
CN103139176B (zh) * 2011-11-30 2016-02-17 中国联合网络通信集团有限公司 媒体业务推送方法、多媒体交换网和多媒体交换网设备
CN103139724B (zh) * 2011-11-30 2015-10-14 中国联合网络通信集团有限公司 媒体业务推送方法、多媒体交换网和多媒体交换网设备
US20150205464A1 (en) * 2014-01-22 2015-07-23 Microsoft Corporation Updating a user interface to a service
CN107666430B (zh) * 2016-07-27 2021-04-06 中兴通讯股份有限公司 一种电子邮件发送方法、装置及终端
CN106991108A (zh) 2016-09-27 2017-07-28 阿里巴巴集团控股有限公司 一种信息的推送方法及装置
TWM547218U (zh) * 2017-06-13 2017-08-11 Hsiang-Che Kung 訊息傳播系統
KR102079222B1 (ko) * 2018-10-12 2020-02-19 주식회사 케이티 멀티미디어 메시지의 통지 메시지를 최적화하는 방법 및 그 장치
CN114157598B (zh) * 2021-12-13 2023-04-07 百果园技术(新加坡)有限公司 一种消息转发方法、系统、电子设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020126708A1 (en) * 2001-01-18 2002-09-12 Robert Skog Multimedia messaging service routing system and method
WO2004021663A1 (de) * 2002-08-13 2004-03-11 Siemens Aktiengesellschaft Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten
KR20040041943A (ko) * 2002-11-12 2004-05-20 한국전자통신연구원 푸쉬기반 멀티미디어 메시징 서비스 방법

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5719918A (en) * 1995-07-06 1998-02-17 Newnet, Inc. Short message transaction handling system
US7209955B1 (en) * 1998-05-29 2007-04-24 Research In Motion Limited Notification system and method for a mobile data communication device
US6400942B1 (en) * 1998-11-09 2002-06-04 Telefonaktie Bolaget Lm Ericsson (Publ) Method and system for broadcasting large short messages
KR100296049B1 (ko) * 1999-03-19 2001-07-28 윤종용 단문메시지서비스를 통한 디지털 휴대용 단말기의 사용자 정보 송수신장치 및 그 방법
DE10104713A1 (de) * 2001-02-02 2002-08-08 Siemens Ag Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten
US6707801B2 (en) * 2001-03-28 2004-03-16 Qualcomm Incorporated Method and apparatus for data transport in a wireless communication system
DE10117895A1 (de) * 2001-04-10 2002-10-17 Siemens Ag Benachrichtigung im Multimedia Messaging Service (MMS)
EP1361712B1 (en) * 2002-05-07 2006-03-29 Sony Ericsson Mobile Communications AB Method for communicating messages to an electronic communication equipment
WO2004034651A1 (en) * 2002-09-30 2004-04-22 Nokia Corporation Routing data packets in a compressed-header domain
WO2004070584A2 (en) * 2003-02-04 2004-08-19 Canonline Global Media, Inc. Method and apparatus for converting objects between weakly and strongly typed programming frameworks
US8732239B2 (en) * 2003-10-02 2014-05-20 Hong Kong Applied Science And Technology Research Institute Co., Ltd. System and method for providing multimedia wireless messages across a broad range and diversity of networks and user terminal display equipment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020126708A1 (en) * 2001-01-18 2002-09-12 Robert Skog Multimedia messaging service routing system and method
WO2004021663A1 (de) * 2002-08-13 2004-03-11 Siemens Aktiengesellschaft Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten
KR20040041943A (ko) * 2002-11-12 2004-05-20 한국전자통신연구원 푸쉬기반 멀티미디어 메시징 서비스 방법

Also Published As

Publication number Publication date
BRPI0513198A (pt) 2008-04-29
EP1781048B1 (en) 2008-11-26
CN1719912A (zh) 2006-01-11
RU2339185C1 (ru) 2008-11-20
ES2315888T3 (es) 2009-04-01
RU2007102820A (ru) 2008-08-20
DE602005011304D1 (de) 2009-01-08
EP1781048A4 (en) 2007-11-21
US20070180037A1 (en) 2007-08-02
EP1781048A1 (en) 2007-05-02
CN100349474C (zh) 2007-11-14
ATE415788T1 (de) 2008-12-15
US7899476B2 (en) 2011-03-01

Similar Documents

Publication Publication Date Title
WO2006005252A1 (fr) Procede de traitement pour notification de retransmission dans un service de messagerie multimedia
TWI375478B (en) Short message conversion between different formats for wireless communication systems
JP4197538B2 (ja) メッセージ伝送方法
US8229480B2 (en) Methods, systems, and computer program products for transferring a message service payload between messaging entities
US7243152B2 (en) Method for transmitting short messages over the internet
WO2005109793A1 (fr) Procede de transmission de messages multimedia
US8374583B2 (en) Message format conversion in communications terminals and networks
TWI322592B (en) Method and apparatus for conveying reports for sms messages in wireless communication systems
US20070198731A1 (en) System and method for processing multimedia messages
WO2008022600A1 (fr) Procédé, dispositif et système de transfert de sms en ims
WO2010031329A1 (zh) 一种即时消息收发的方法、系统和设备
EP1279263A1 (en) Method for transmitting messages
WO2007025432A1 (fr) Procede destine a realiser un service de transfert d'informations, systeme et terminal correspondantsprocede fournissant un service de transfert d'informations, systeme et terminal connexes
CN107645700B (zh) 一种基于ussd协议的移动通信数据传输方法
CN101647253B (zh) Smsip中的提交报告处理
JP2004532567A (ja) マルチメディアメッセージサービス（ｍｍｓ）におけるメッセージング
CN100455049C (zh) 一种多媒体消息服务系统中对消息的处理方法
WO2000074343A1 (en) Adaptation of wap to sms in cellular networks
JP2003516039A (ja) パケット・ベースのクライアント／サーバ・プロトコル
WO2008003268A1 (fr) Système d'envoi groupé de messages multimédia et procédé associé
Alliance Wireless Control Message Protocol

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005766712

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11619757

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2007102820

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2005766712

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11619757

Country of ref document: US

ENP Entry into the national phase

Ref document number: PI0513198

Country of ref document: BR