CN101047879A - 多条可拆分及包含简单多媒体信息的ussd传输方法 - Google Patents
多条可拆分及包含简单多媒体信息的ussd传输方法 Download PDFInfo
- Publication number
- CN101047879A CN101047879A CNA2006100253049A CN200610025304A CN101047879A CN 101047879 A CN101047879 A CN 101047879A CN A2006100253049 A CNA2006100253049 A CN A2006100253049A CN 200610025304 A CN200610025304 A CN 200610025304A CN 101047879 A CN101047879 A CN 101047879A
- Authority
- CN
- China
- Prior art keywords
- ussd
- message
- field
- udh
- string
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明针对USSD现有业务的不足，在考虑与3GPP已有协议兼容的同时，提出对USSD信令层协议的补充协议，以扩充USSD在现代移动通信网络中的功能范围。对于USSD信令层协议的扩充，主要基于以上所述之两大需求进行。一是将一条消息放不下的内容放在多条消息中传送，通过在ussd－String中增加UDH(User Data Header，用户数据头)字段，先在发送端分拆消息，利用UDH中定义的序号标识和在接收端进行重组。二在简单多媒体内容的传输上，将简单的多媒体内容放在UDH中进行传输。
Description
技术领域
本申请涉及一种多条可拆分及包含简单多媒体信息的USSD传输方法，所述方法是对3GPP USSD业务信令层3协议的一种扩充。
背景技术
关于当前3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)USSD(Unstructured Supplementary Service Data，非结构化补充业务数据)业务的定义可以参见相关的技术规范，例如3GPP TS 24.080 V3.7.0(2002-06)，以及3G TS 24.090 V3.0.0(1999-05)。
技术规范3G TS 24.090 V3.0.0(1999-05)定义了3GPP系统中USSD数据操作的层3描述。其中包括，网络发起(network initiated)的USSD数据操作USSD request、USSD notification等；以及移动端发起(mobile initiated)的各种USSD数据操作。关于上述操作过程的细节可以参见上述文档的详细说明。技术规范3GPP TS 24.080 V3.7.0(2002-06)定义了支持3GPP系统中层3移动射频接口上的补充业务所必需的信息编码。
在现有的3GPP中定义的移动通信补充业务中的USSD业务中，由于存在较大不足之处而制约了其应用：
首先，单条ussd-String的长度有限，这样对于包含较多信息的消息只能通过在内容上削减、或采取多次交互的方式实现。
另外，在3GPP的USSD相关协议中，ussd-String的内容只能包含文本，这在内容的丰富及多样性上是一个短处。
发明内容
基于USSD业务的以上两个不足，在考虑与3GPP已有协议兼容的同时，提出对USSD信令层协议的补充协议，以扩充USSD在现代移动通信网络中的功能范围。
对于USSD信令层协议的扩充，主要基于以上所述之两大需求进行。一是将一条消息放不下的内容放在多条消息中传送，通过在ussd-String中增加UDH(User Data Header，用户数据头)字段，先在发送端分拆消息，利用UDH中定义的序号标识和在接收端进行重组(序列号的取值范围暂定为0-127，大于或等于128的值用于出错处理)。二在简单多媒体内容的传输上，将简单的多媒体内容放在UDH中进行传输。
因此，通过在ussd-String中引入UDH数据字段，可以解决上述的技术问题。同时，为了引入UDH，在各消息中加入UDHI(User DataHeader Indicator，用户数据头指示位)以指示UDH是否在ussd-String中存在。
本发明提出了一种基于3GPP USSD业务系统来发送USSD消息的改进方法，所述方法包括如下步骤：在ussd-String字段加入用户数据头(UDH)字段；在发送端发送消息时，将一个超长的USSD消息被拆分成多个单条USSD消息，其中在每个单条USSD消息中的UDH字段中定义了其序号标识ID；接收端在每次接收到单条USSD消息后，向发送方返回一条USSD proceed消息，以确认所述单条USSD消息；以及在接收端接收到所述过长的USSD消息的全部内容后，利用所述每个单条USSD消息的UDH中的序号标识ID，将多个单条USSD消息重新组合成初始的USSD消息。
此外，所述USSD proceed消息还包括：出错指示(proceed-Succeed)字段，用于指示接收端收到的上一条消息正确或错误；消息标识号(proceed-Index)字段，用于标识接收端收到的上一条消息的ID号；当所述出错指示字段指示所接收的单条消息正确时，发送方继续发送下一个单条消息；以及当所述出错指示字段指示所接收的单条消息错误时，发送方根据所述消息标识号字段所标识的ID号重新发送所述出错的单条消息，或者按照现有的出错处理流程释放本次连接
本发明还提出了一种基于3GPP USSD业务系统来发送USSD消息的改进方法，所述方法包括如下步骤：在ussd-String字段加入用户数据头(UDH)字段，所述UDH中包含了简单多媒体内容；发送方发送所述具有UDH字段的USSD消息；以及接收方接收所述具有UDH字段的USSD消息，并提取所述UDH字段中的简单多媒体内容。
所述用户数据头(UDH)字段包括：UDHL字段，指示ussd-String中的用户数据头(UDH)的长度；IEI字段，用于指示IE数据的类型；IEIDL字段，用于指示IE数据的长度；IEID字段，用于指示IE数据的内容。
此外，所述简单多媒体内容的至少包括：预定义声音；自定义声音；预定义图片；大尺寸黑白图片；小尺寸黑白图片；预定义动画；大尺寸黑白动画；小尺寸黑白动画；格式定义；以及保留用途。
附图说明
图1示出了多条可拆分MO USSD request交互顺序图。
图2示出了多条可拆分MO USSD request中间某条出错的交互顺序图。
图3示出了对MO USSD request网络结点为多条可拆分USSDrequest的交互顺序图。
图4出了对MO USSD request网络结点为多条可拆分USSDresponse的交互顺序图。
图5示出了对MO USSD request网络结点为多条可拆分USSDrequest传输中某条出错的交互顺序图。
图6示出了对MO USSD request网络结点为多条可拆分USSDresponse传输中某条出错的交互顺序图。
图7示出了多条可拆分MT USSD request交互顺序图。
图8示出了多条可拆分MT USSD request传输中某条出错的交互顺序图。
图9示出了对MT USSD request移动台多条可拆分USSDresponse的交互顺序图。
图10示出了对MT USSD request移动台多条可拆分USSDresponse传输中某条出错的交互顺序图。
图11示出了网络结点释放MT USSD request交互。如果网络结点需要从移动台获取更多信息，则可以按现有的流程继续该次USSD交互过程。
图12示出了多条可拆分MT USSD notification交互顺序图。
图13示出了多条可拆分MT USSD notification中间某条出错的交互顺序图。
图14示出了网络结点收到错误的USSD proceed释放交互的交互顺序图。
图15示出了移动台收到错误的USSD proceed释放交互的交互顺序图。
图16示出了移动台检测到网络结点不支持本扩充协议时释放交互的交互顺序图。
图17示出了网络结点检测到移动台不支持本扩充协议时释放交互的交互顺序图。
图18示出了ussd-String引入UDH后的数据内容结构图。
图19示出了UDH的数据内容结构图。
图20示出了为16*16图片的点阵编码举例。
图21示出了补充业务软件部分通常实现方式架构图。
此外，对于本技术领域中常常使用的中英文简写，给出如下对照表及名词解释：
| 英文简写 | 英文全称 | 中文意义 |
| HLR | Home Location Register | 归属位置寄存器 |
| HPLMN | Home PLMN | 归属PLMN |
| IE | Information Element | IE |
| IEI | Information ElementIdentifier | IE标识位 |
| IED | Information Element Data | IE数据 |
| IEDL | Information Element DataLength | IE数据长度 |
| MMI | Man Machine Interface | 人机界面(特指移动台) |
| MO | Mobile Originated | 移动用户发起的 |
| MS | Mobile Station | 移动台 |
| MSC | Mobile Switching Center | 移动交换中心 |
| MSISDN | Mobile Subscriber ISDNNumber | 移动台国际ISDN号码 |
| MT | Mobile Terminated | 移动用户接收的 |
| PLMN | Public Land Mobile Network | 公众陆地移动网 |
| SS | Supplementary Service | 补充业务 |
| TE | Terminal Entity | 用户终端设备 |
| UDH | User Data Header | 用户数据头 |
| UDHI | User Data Header Indicator | 用户数据头指示位 |
| UDHL | User Data Header Length | 用户数据头长度 |
| USSD | Unstructured SupplementaryService Data | 非结构化补充业务数据 |
| VLR | Visited Location Register | 拜访位置寄存器 |
| VPLMN | Visited PLMN | 拜访PLMN |
| Serving network | 服务网络(指移动台登录的网络，可能是HPLMN或VPLMN) | |
| USSD notification | ||
| USSD request | ||
| USSD response |
以下将参考附图更完整地描述本发明，附图中示出了本发明的优选实施例。但是本发明可体现在许多其他的形式中，而不应当被理解为限于这里所述的实施例；相反提供这些实施例是为了公开内容将会详尽和完整，并且将会完整地将本发明的范围传达给本领域的技术人员。
具体实施方式
如前所述，在现有的3GPP中定义的移动通信补充业务中的USSD业务中，由于存在较大不足之处而制约了其应用：单条USSD STRING的长度有限，这样对于包含较多信息的消息只能通过在内容上削减、或采取多次交互的方式实现，很不方便。
根据本发明的一个实施例，将一条消息放不下的内容放在多条消息中传送，先在发送端分拆消息，随后在接收端进行重组，因此，需要对现有的USSD业务流程进行改进。
下面的第1节将介绍本发明提出的对现有USSD业务流程的改动。
1.1 USSD proceed的引入
为了实现本发明的发明目的，提出了一种全新的数据操作USSDproceed。
对于超长内容分拆后的多条USSD，接收端在收到第一条后，首先判断其UDH中的内容，如果UDH中显示该USSD消息是一条多条消息，则向发送端发送一条USSD proceed(proceeding)消息。发送端在收到该条消息后，继续依次发送余下的消息。接收端在收到最后一条消息后，才根据其内容做出响应，发送USSD response或者发送一条RELEASE COMPLETE以释放此次交互。接收端在收到某条消息后发现此消息数据损坏或出现其他错误，应向发送端发送一条USSD proceed(error)，指明接收的数据出错，发送端在收到该出错消息后应重发该条消息，或者在无法处理的情况下，释放此次交互。
USSD proceed的协议数据的详细定义请参见后文第2节。
以下结合附图1-17来具体说明本发明所提出的改进流程。
1.2 MO USSD request流程的改动
注：在本节及以下两小节的USSD消息顺序流程图中，为简化，将MSC，HLR，VLR视为统一的网络结点，不考虑USSD消息需要中继的情况。
如附图1所示，MO USSD request为一个多条消息的顺序图。
图2显示了MO USSD request中间某条出错的消息顺序图。如果在收到某条消息后，网络结点发现此条消息已经损坏或出现了其他错误，则向MS发送USSD proceed(error)消息，MS在收到出错消息后可以选择重发或者直接释放此次交互。
网络结点在每收到一条消息时，则保存该条消息，在收到最后一条消息后，分析其内容(MMI-mode时)或者将组合后的内容交给指定的应用程序(application mode时)处理。
消息处理完毕后，网络结点将给移动台发送USSD response(RELEASE COMPLETE)同时释放该次交互，或者发送USSDrequest(FACILITY)，以从移动台处获取进一步的内容。如果该条USSD response或USSD request也是一条需要多条消息才能发送的消息，则也按多条内容的方式进行处理。如果是USSD response(RELEAS ECOMPLETE)，移动台在收到最后一条单条消息，网络结点收到移动台对最后一条的确认后才认为该次交互完全结束。
图3显示了对MO USSD request网络结点为多条可拆分USSDrequest的交互顺序图。
图4显示了对MO USSD request网络结点为多条可拆分USSDresponse的交互顺序图。
当移动台检查到收到的单条消息出错时，也可以选择要求网络结点重发该条消息或发送一条空的USSD response表明需要中止当前交互，网络结点收到后则向移动台发送RELEASE COMPLETE直接释放该交互，不再继续发送后续的消息。如图5、图6所示。
图5是对MO USSD request网络结点为多条可拆分USSD request传输中某条出错的交互顺序图。
图6是对MO USSD request网络结点为多条可拆分USSDresponse传输中某条出错的交互顺序图。
移动台也可在任何时候向网侧发送RELEASE COMPLETE释放该次交互。
1.3 MT USSD request流程的改动
当网络结点发起MT USSD request消息时，此消息可能是一个多条消息，移动台也需要向网络结点发送USSD proceed消息以确认对前一条消息的接收。
图7显示了多条可拆分MT USSD request交互顺序图。
当移动台检查到收到的单条消息出错时，也可以选择要求网络结点重发该条消息或发送一条空的USSD response表明需要中止当前交互，网络结点收到后则向移动台发送RELEASE COMPLETE直接释放该交互，不再继续发送后续的消息。
图8显示了多条可拆分MT USSD request传输中某条出错的交互顺序图。
在移动台收到全部单条消息后，对其消息内容进行重组，然后将其内容显示在移动台屏幕上让用户进行下一步操作(MMI-mode)，或者将其完整地转送给ME/TE/SIM(application mode)。在用户或者应用程序做出响应后，如果该响应也需要拆分后多条发送，移动台就按序依次向网络结点发送。图9显示了对MT USSD request移动台多条可拆分USSD response的交互顺序图。
如果网络结点收到移动台的USSD response中出现错误，则网络结点可以选择要求移动台重发或者直接发送RELEASE COMPLETE以释放该次交互。如图10，是对MT USSD request移动台多条可拆分USSD response传输中某条出错的交互顺序图。
网络结点在完全收到移动台的响应后，可以发送RELEASECOMPLETE来释放此次交互。如图11，是网络结点释放MT USSDrequest交互。如果网络结点需要从移动台获取更多信息，则可以按现有的流程继续该次USSD交互过程。
移动台也可在任何时候向网侧发送RELEASE COMPLETE释放该次交互。
1.4 MT USSD notification流程的改动
当网络结点发送的MT USSD notification也是一个多条消息时，也需要按次序依次发送，移动台在收到全部的单条消息后再向网络结点发送响应消息。网络结点收到USSD response后按正常流程向移动台发送RELEASE COMPLETE以释放此次交互。顺序图如图12所示，是多条可拆分MT USSD notification交互顺序图。
若移动台收到的USSD notification的单条消息出错，则移动台可以要求网络结点重发该条消息，或者发送一条USSD response以让网络结点释放此次交互。顺序图如图13，是多条可拆分MT USSDnotification中间某条出错的交互顺序图。
移动台也可在任何时候向网侧发送RELEASE COMPLETE释放该次交互。
1.5 对USSD proceed的出错处理
如果发送端收到USSD proceed，发现该条USSD proceed本身是一条错误消息，无法解析。则发送端应向接收端发一条出错消息。如果网络结点为发送端，则向移动台直接发一条Facility为Return error的RELEASE COMPLETE消息释放此次交互。如图14所示，网络结点收到错误的USSD proceed释放交互的交互顺序图。
如果移动台为发送端，则向网络结点发送一条Facility为Returnerror的FACILITY消息通知网络结点释放此次交互。如图15，移动台收到错误的USSD proceed释放交互的交互顺序图。
移动台或网络结点在发出某条拆分后的单条USSD消息后，应等待接收USSD proceed，同时启动一个定时器。在定时器到时后若还未收到，则可以认为对端没有响应，应发送一条RELEASE COMPLETE释放此次交互同时以某种方式通知用户。
1.6 与当前版本USSD信令层协议信令流程中兼容性的考虑
如果移动台或网络的一方并不支持多条消息的处理，在当前的协议下，接收方不会发送USSD proceed给发送方。在这种情况下，发送方发现接收方未发来USSD proceed，如果发送方是移动台，网络结点发的响应可能有以下几种情况：
1、为RELEASE COMPLETE，Facility为正常响应或者error，则此次交互自然结束；
2、为FACILITY，不管里面的内容如何，移动台检测到是这种情况时，向网络结点发送空的USSD response，通知网络中止此次交互。如图16所示，移动台检测到网络结点不支持本扩充协议时释放交互的交互顺序图。
如果发送方是网络结点，则网络结点直接向移动台发送RELEASE COMPLETE以释放此次交互。如图17所示，网络结点检测到移动台不支持本扩充协议时释放交互的交互顺序图。
2.定义USSD proceed
如上所述，根据本发明的一个实施例，将一条消息放不下的内容放在多条消息中传送，通过在ussd-String中增加UDH字段，先在发送端分拆消息，利用UDH中定义的序号标识和在接收端进行重组(序列号的取值范围暂定为0-127，大于或等于128的值用于出错处理)。
为了实现上述第1节描述的相关流程改进，本发明提出了上述的USSD proceed。USSD proceed用来移动台与网络结点间传输对对端传来的多条组合式USSD消息中的某一条的回应；用来确认对端传来的该单条消息出错同时要求对端重传该条USSD。
USSD proceed的ASN.1的定义如下：
UnstructuredSS-Proceed OPERATION
ARGUMENT
proceed-Arg SEQUENCE{
proceed-Succeed[0]IMPLICIT BOOLEAN OPTIONAL，
proceed-Index[1]IMPLICIT INTEGER(0..255)OPTIONAL，
...，
｝
RESULT
ussd-Res SEQUENCE{
ussd-DataCodingScheme OCTET STRING(SIZE(1))，
ussd-String OCTET STRING(SIZE(1..160))，
...，
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL}
ERRORS
--systemFailure--localValue：34，
--unexpectedDataValue--localValue：36，
--callBarred--localValue：13}
∷＝localValue：58
上述定义中，proceed-Succeed字段用来标识接收端收到的上一条消息正确或错误。proceed-Index用来标识接收端收到的上一条消息的ID号。当proceed-Succeed取值为TRUE时，proceed-Index字段可以省略。proceed-Succeed字段本身也可以省略，此时proceed-Index字段也必须省略，用来表示上一条消息接收成功。当proceed-Succeed取值为FALSE时，proceed-Index字段可以填入接收到的错误消息的ID号(见下述4.4节)。当接收到的错误消息中UDH损坏无法得知ID时，该字段也可省略。由发送方收到该USSD proceed时自行判断哪一条出错。
3.定义USSD UDHI参数
为了在中ussd-String引入UDH，需要在USSD request，USSDresponse，USSD notification中加上UDHI。它的具体作用就是指示在ussd-String中是否有UDH存在。
UDHI的取值如下：
1、TRUE，表示ussd-String中含有UDH；
2、FALSE，表示ussd-String中不包含UDH。
则在ProcessUnstructuredSS-Request的ASN.1定义中增加UDHI如下：
processUnstructuredSS-Request OPERATION
ARGUMENT
ussd-Arg SEQUENCE{
ussd-DataCodingScheme OCTET STRING(SIZE(1))，
ussd-String OCTET STRING(SIZE(1..160))，
...，
alertingPattern OCTET STRING(SIZE(1))OPTIONAL，
msisdn[0]IMPLICIT OCTET STRING(SIZE(1..20))(SIZE(1..9))OPTIONAL
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL}
RESULT
ussd-Res SEQUENCE{
ussd-DataCodingScheme OCTET STRING(SIZE(1))，
ussd-String OCTET STRING(SIZE(1..160))，
...，
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL}
ERRORS{
--systemFailure--localValue：34，
--dataMissing--localValue：35，
--unexpectedDataValue--localValue：36，
--unknownAlphabet--localValue：71，
--callBarred--localValue：13}
∷＝localValue：62
则在unstructuredSS-Request的ASN.1定义中增加UDHI如下：
unstructuredSS-Request OPERATION
ARGUMENT
ussd-Arg SEQUENCE{
ussd-DataCodingScheme OCTET STRING(SIZE(1))，
ussd-String OCTET STRING(SIZE(1..160))，
...，
alertingPattern OCTET STRING(SIZE(1))OPTIONAL，
msisdn[0]IMPLICIT OCTET STRING(SIZE(1..20))(SIZE(1..9))OPTIONAL
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL}
RESULT
ussd-Res SEQUENCE{
ussd-DataCodingScheme OCTET STRING(SIZE(1))，
ussd-String OCTET STRING(SIZE(1..160))，
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL，
...，
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL}
ERRORS{
--systemFailure--localValue：34，
--dataMissing--localValue：35，
--unexpectedDataValue--localValue：36，
--absentSubscriber--localValue：27，
--illegalSubscriber--localValue：9，
--illegalEquipment--localValue：12，
--unknownAlphabet--localValue：71，
--ussd-Busy--localValue：72}
∷＝localValue：60
则在unstructuredSS-Notify的ASN.1定义中增加UDHI如下：
unstructuredSS-Notify OPERATION
ARGUMENT
ussd-Arg SEQUENCE{
ussd-DataCodingScheme OCTET STRING(SIZE(1))，
ussd-String OCTET STRING(SIZE(1..160))，
...，
alertingPattern OCTET STRING(SIZE(1))OPTIONAL，
msisdn[0]IMPLICIT OCTET STRING(SIZE(1..20))(SIZE(1..9))OPTIONAL
ussd-String-Udhi[0]IMPLICIT BOOLEAN OPTIONAL}
ERRORS{
--systemFailure--localValue：34，
--dataMissing--localValue：35，
--unexpectedDataValue--localValue：36，
--absentSubscriber--localValue：27，
--illegalSubscriber--localValue：9，
--illegalEquipment--localValue：12，
--unknownAlphabet--localValue：71，
--ussd-Busy--localValue：72}
∷＝localValue：61
网络结点或移动台在处理时，若发现没有UDHI，则应认为这非扩充协议的USSD信令层协议数据单元，应按现在方式以单条USSD处理。
4.定义USSD UDH参数
4.1 ussd-String的结构
ussd-String在3GPP的定义中是1至160个字节长的数据，本身并没有什么格式，可以理解成就是一块BUFFER，里面用来填充需要发送的内容。
根据本发明的一个实施例，在ussd-String中引入UDH后，其结构如图18，是ussd-String引入UDH后的数据内容结构图。
UDH的长度为整数字节，剩下的内容为按ussd-DataCodingScheme编码的文本内容。如果文本内容是以GSM7bit编码的，若其编码后的长度不是整数字节，则在最后一个字节的末尾填充0补齐。
4.2 UDH的结构
如前所述，在现有的3GPP的USSD相关协议中，USSD String的内容只能包含文本，这在内容的丰富及多样性上是一个短处。
而根据本发明的另一个实施例，提出了在简单多媒体内容的传输上，将简单的多媒体内容放在UDH中进行传输。
在USSD的信令层扩充协议中，UDH的结构设计如图19所示，是UDH的数据内容结构图。其中的字段含义如下：
| 字段 | 长度(octets) | 说明 |
| UDHL | 1 | ussd-String中用户数据头的长度 |
| IEI | 1 | IE标示位，批示IE类型 |
| IEIDL | 1 | IE数据长度 |
| IEID | 0-n | IE数据 |
表1：UDH的数据内容字段定义
UDHL，IEIDL的取值都为整型，指明UDH和IEI的包含的字节数。UDHL的值应不大于159(0x9F)。
在UDH中可能包含一个或多个IE，每个IE可能是同一或不同类型的数据。但是如果IE代表的是多条可拆分USSD的序号时，此类型IE在UDH中应只出现一次。
IEID中的数据可能因为IE的类型不同而其长度非整数字节，则USSD发送方应根据IE的类型决定如何将其填充为整数字节。不一定填零。
4.3 IE的类型
IE的类型定义如下表，包括多条可拆分USSD与简单多媒体内容的定义。
| 取值(16进制) | 说明 |
| 00 | 多条可拆分USSD标记 |
| 01 | 预定义声音 |
| 02 | 自定义声音(iMelody格式最大128bytes) |
| 03 | 预定义图片 |
| 04 | 大尺寸黑白图片(32*32＝128bytes) |
| 05 | 小尺寸黑白图片(16*16＝32bytes) |
| 06 | 预定义动画 |
| 07 | 大尺寸黑白动画(16*16times 4＝32*4＝128bytes) |
| 08 | 小尺寸黑白动画(8*8times 4＝8*4＝32bytes) |
| 09 | 格式定义 |
| 10-FF | 保留 |
表2：UDH的IEI取值
当IEI的取值在09-FF时，USSD的接收方应忽略该IE。为今后扩充协议升级考虑，不向发送方发出错消息。
接收方在判断IEI的类型后，按照其类型分别处理。
4.4 多条可拆分USSD的IE设置
当IEI的值为0x00时，IEID为多条可拆分USSD的序号。序号的取值以0x00开始，以1递增，以0xFF结束。
如果IEI的类型为多条可拆分USSD，则此IE应为UDH中第一个IE。
接收方在收到包括可拆分指示位IEI的USSD时，表明多条可拆分的USSD的发送开始。在收到序号为0xFF的可拆分USSD时，接收方把之前收到的所有USSD的内容组合后在待机界面显示或者转送给应用程序处理。
接收方在收到第二条开始的可拆分USSD时，若检测到其中的序号与上一次接收到的序号比较后发现序号有误，应按上述1.5中所述的流程释放此次交互。
4.5 声音的IE设置
当IEI的值为0x01时，IEID的值为预定义的存储在移动台的声音的ID值(整型)。这种IE一般只存在于MT的USSD中。如果这也是一个多条交互，则应在多条可拆分USSD全部收取后再行处理。
在处理时，在人机界面模式下(MMI-mode)，移动台将在显示文本内容的同时，播放预定义在移动台侧的声音。在应用程序模式(application mode)下，应用程序播放预定义在应用程序中的声音。一般来说，此预定义的声音应为移动台或驻留在移动台的应用程序与网络结点约定好的声音内容。
下表是一个预定义声音的推荐约定：
| 声音ID(十六进制) | 说明 |
| 00 | 叮 |
| 01 | 咚 |
| 02 | 钟声 |
| 03 | 嗒嗒声 |
| 04 | 提示音 |
| 05 | 鼓声 |
| 06 | 掌声 |
| 07 | 号角声 |
| 08 | 欢呼声 |
| 09 | 口哨声 |
| 10-FF | 保留 |
表3：预定义声音的推荐取值
当IEI的值为0x02时，IEID的值为iMelody格式定义的声音，长度最长为128个字节。IEIDL用来指示IEID的长度。与预定义的声音一样，这种IE一般只存在于MT的USSD中。如果这也是一个多条交互，则应在多条可拆分USSD全部收取后再行处理。
在处理时，也与预定义的声音类似。在人机界面模式下(MMI-mode)，移动台将在显示文本内容的同时，将该IEID中的声音数据转换后播出。在应周程序模式(application mode)下，应用程序将该IEID中的声音数据转换后播出。
为避免冲突，USSD消息中类型为预定义或自定义声音的IE最好只包含一个。
关于iMelody格式的声音，请参考Specifications for Ir MobileCommunications(IrMC)iMelody，Infrared Data Association，October 24th2000。
4.6 图片的IE设置
当IEI的值为0x03时，IEID的值为预定义的存储在移动台的黑白两色图片的ID值(整型)。如果这也是一个多条交互，则应在多条可拆分USSD全部收取后再行处理。
在处理时，在人机界面模式下(MMI-mode)，移动台将在显示文本内容的同时，显示该预定义图片。在应用程序模式(applicationmode)下，应用程序自己决定如何处理预定义在应用程序中的图片。一般来说，此预定义的图片应为移动台或驻留在移动台的应用程序与网络结点约定好的图片。
下表是一个预定义图片的推荐约定：
| 图片ID(十六进制) | 说明 |
| 00 | 笑脸 |
| 01 | 哭脸 |
| 02 | 鲜花 |
| 03 | 蛋糕 |
| 04 | 汽车 |
| 05 | 手机 |
| 06 | 礼物 |
| 07 | 硬币 |
| 08 | 酒瓶 |
| 09 | 酒杯 |
| 10-FF | 保留 |
表4：预定义图片的推荐取值
当IEI的值为0x04或0x05时，IEID为黑白图片数据，长度最长为128(32*32)或者32个字节(16*16)。IEIDL用来指示IEID的长度。如果这也是一个多条交互，则应在多条可拆分USSD全部收取后再行处理。
在处理时，在人机界面模式下(MMI-mode)，移动台将在显示文本内容的同时，显示该自定义图片。在应用程序模式(applicationmode)下，应用程序自己决定如何处理该自定义图片。
自定义图片的点阵定义如下：
图片的每一个点对应一个bit，每一行从左到右对应一个字节的高位到低位，第一行的第一个字节对应图片数据的第一个字节，接下来是第一行的其余字节，第二行的第一个字节，依次类推。
图20为16*16图片的点阵编码举例。
4.7 动画的IE设置
当IEI的值为0x06时，IEID的值为预定义的存储在移动台的黑白两色动画的ID值(整型)。如果这也是一个多条交互，则应在多条可拆分USSD全部收取后再行处理。
在处理时，在人机界面模式下(MMI-mode)，移动台将在显示文本内容的同时，显示该预定义动画。在应用程序模式(applicationmode)下，应用程序自己决定如何处理预定义在应用程序中的动画。一般来说，此预定义的动画应为移动台或驻留在移动台的应用程序与网络结点约定好的动画。
下表是一个预定义动画的推荐约定：
| 动画ID(十六进制) | 说明 |
| 00 | 高兴 |
| 01 | 沮丧 |
| 02 | 赞同 |
| 03 | 怀疑 |
| 04 | 大笑 |
| 05 | 哭泣 |
| 10-FF | 保留 |
表5：预定义动画的推荐取值
当IEI的值为0x07或0x08时，IEID为黑白图片数据，长度最长为128(16*16 times 4)或者32个字节(8*8 times 4)。IEIDL用来指示IEID的长度。如果这也是一个多条交互，则应在多条可拆分USSD全部收取后再行处理。
在处理时，在人机界面模式下(MMI-mode)，移动台将在显示文本内容的同时，显示该自定义动画。在应用程序模式(applicationmode)下，应用程序自己决定如何处理该自定义动画。
自定义动画的每帧按照自定义图片的点阵编码方式编码，按照各帧的播放顺序按顺序组织动画数据。
4.8 格式定义的IE设置
当IEI的值为0x09时，IEID的值为本IE后的IE(图片或动画)在文本内容中的位置，从0开始。
若图片IE或动画IE前无格式定义IE，则由接收方自行决定该多媒体内容显示在文本内容的位置。一般来说，多媒体内容放在文本内容的最前面。
5.参考实现
本USSD业务补充协议只需要在处理USSD的L3消息的网络结点(包括移动台，MSC，HLR，VLR)处稍加修改就可以实现。
在软件处理的层次上看，USSD业务一般的软件实现如图21，补充业务软件部分通常实现方式架构图。
本补充协议在实现时，一般来说，需要修改L3处理部分以及应用层处理部分。
一、发送USSD消息时、
应用层接受用户或其他应用的输入，将USSD内容(包括超长文本或多媒体消息)构建成内部数据或消息发送给L3处理部分。
在L3处理部分，在接收到应用层发来的USSD发送请求时，判断相应的USSD内容的长度，以及是否包含多媒体消息，计算出是否需要分拆消息及构建UDH参数。发送完某条单条消息后等待USSDproceed消息，正常收到时继续发送后续消息直至结束。在出错时按第二章中定义的流程处理错误情况。
二、接收USSD消息时、
L3处理部分在收到分拆的第一条USSD消息时不立即将结果传送给应用层，而是等全部消息接收完毕后构建相应的内部消息，将分拆的文本合并，加入收到的多媒体内容，然后再把内部数据或消息传送给应用层处理。在收到的分拆的USSD消息出错时，L3处理部分向对端发送USSD proceed(error)消息，若不能收到对方重发的上一条出错的分拆消息，则向应用层发送出错消息。
应用层处理部分，收到L3发来的内部消息时，向用户显示该超长消息，若包含图片或动画，则按格式定义与文本一起显示；若包含声音信息，则按声音信息的类型调用相应功能播放。应用层处理部分的另一种可能处理是再转送给驻留于该网络结点的某一应用进行处理。若L3处理部分发来的是出错指示，则向用户提示出错。
在前述描述和相关附图中给出的教导的帮助下，本发明所属领域的技术人员将会想到本发明的许多修改和其他实施例。因此，要理解本发明不限于所公开的特定实施例，修改和其他实施例想要被包括在所附权利要求书的范围内。虽然这里采用了特定术语，但是它们只是在一般的描述性意义上使用的，而不是用于限制目的。
作为对详细描述的结论，应该注意本领域的技术人员将会很清楚可对优选实施例做出许多变化和修改，而实质上不脱离本发明的原理。另外，这种变化和修改想要被包含在所附权利要求书所述的本发明的范围之内。此外，在以下权利要求书中，结构、材料、行为和所有装置的等同物或者步骤加功能元素想要包含用于执行其引证的功能的任何结构、材料或行为。
Claims (19)
1.一种基于3GPP USSD业务系统来发送USSD消息的改进方法，所述方法包括如下步骤：
在ussd-String字段加入用户数据头(UDH)字段；
在发送端发送消息时，将一个超长的USSD消息被拆分成多个单条USSD消息，其中在每个单条USSD消息中的UDH字段中定义了其序号标识ID；
接收端在每次接收到单条USSD消息后，向发送方返回一条USSDproceed消息，以确认所述单条USSD消息的接收；以及
在接收端接收到所述超长的USSD消息的全部内容后，利用所述每个单条USSD消息的UDH字段中的序号标识ID，将多个单条USSD消息重新组合成初始的USSD消息。
2.根据权利要求1的方法，其中所述USSD消息是指Operationtype为UnstructuredSS-Request、UnstructuredSS-Notify、或ProcessUnstructuredSS-Request的任意USSD消息。
3.根据权利要求1的方法，还包括在USSD消息中加入用户数据头指示位(UDHI)字段，其中UDHI字段可指示UDH字段的存在与否。
4.根据权利要求3的方法，其中UDHI的取值如下：
TRUE，表示ussd-String中含有UDH；
FALSE，表示ussd-String中不包含UDH。
5.根据权利要求1的方法，其中
所述USSD proceed消息还包括：出错指示(proceed-Succeed)字段，用于指示接收端收到的上一条消息正确或错误；消息标识号(proceed-Index)字段，用于标识接收端收到的上一条消息的ID号；
当所述出错指示字段指示所接收的单条消息正确时，发送方继续发送下一个单条消息；以及
当所述出错指示字段指示所接收的单条消息错误时，发送方根据所述消息标识号字段所标识的ID号重新发送所述出错的单条消息，或者按照现有的出错处理流程释放本次连接。
6.根据权利要求1的方法，还包括：
当拆分消息的发送方收到的USSD proceed消息本身是错误消息时，发送方释放此次交互。
7.根据权利要求1的方法，还包括：
当移动台或网络之一不支持所述多条拆分业务时，接收方不发送USSD Proceed确认消息给发送方，该交互被释放。
8.根据权利要求1的方法，所述用户数据头(UDH)字段位于ussd-String的头部。
9.根据权利要求1的方法，所述用户数据头(UDH)字段至少包括如下之一：
UDHL字段，指示ussd-String中的用户数据头(UDH)的长度；
IEI字段，用于指示IE数据的类型；
IEIDL字段，用于指示IE数据的长度；
IEID字段，用于指示IE数据的内容。
10.根据权利要求9的方法，还包括将IE数据类型IEI设置为多条可拆分USSD指示位，以及IEID数据表示多条可拆分USSD消息的序号ID。
11.根据权利要求9的方法，其中相应于IEI字段的数值，IE数据的类型还包括如下预定项的至少之一：
预定义声音；
自定义声音；
预定义图片；
大尺寸黑白图片；
小尺寸黑白图片；
预定义动画；
大尺寸黑白动画；
小尺寸黑白动画；
格式定义；以及
保留用途。
12.根据权利要求10的方法，还包括
接收方在收到其IEI是多条可拆分USSD指示位的USSD时，表明多条可拆分的USSD的发送开始；
在收到序号为0xFF的可拆分USSD时，接收方把之前收到的所有USSD的内容组合后在待机界面显示或者转送给应用程序处理。
13.一种基于3GPP USSD业务系统来发送USSD消息的改进方法，所述方法包括如下步骤：
在ussd-String字段加入用户数据头(UDH)字段，所述UDH中包含了简单多媒体内容；
发送方发送所述具有UDH字段的USSD消息；
接收方接收所述具有UDH字段的USSD消息，并提取所述UDH字段中的简单多媒体内容。
14.根据权利要求13的方法，其中所述USSD消息是指Operationtype为UnstructuredSS-Request、UnstructuredSS-Notify、或ProcessUnstructuredSS-Request的任意USSD消息。
15.根据权利要求13的方法，还包括在USSD消息中加入用户数据头指示位(UDHI)字段，其中UDHI字段可指示UDH字段的存在与否。
16.根据权利要求13的方法，其中UDHI的取值如下：
TRUE，表示ussd-String中含有UDH；
FALSE，表示ussd-String中不包含UDH。
17.根据权利要求13的方法，所述用户数据头(UDH)字段位于ussd-String的头部。
18.根据权利要求13的方法，所述用户数据头(UDH)字段至少包括如下之一：
UDHL字段，指示ussd-String中的用户数据头(UDH)的长度；
IEI字段，用于指示IE数据的类型；
IEIDL，用于指示IE数据的长度；
IEID，用于指示IE数据内容。
19.根据权利要求18的方法，其中相应于IEI的数值，IE数据的类型包括如下预定的简单多媒体内容的至少之一：
预定义声音；
自定义声音；
预定义图片；
大尺寸黑白图片；
小尺寸黑白图片；
预定义动画；
大尺寸黑白动画；
小尺寸黑白动画；
格式定义；以及
保留用途。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006100253049A CN101047879A (zh) | 2006-03-30 | 2006-03-30 | 多条可拆分及包含简单多媒体信息的ussd传输方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006100253049A CN101047879A (zh) | 2006-03-30 | 2006-03-30 | 多条可拆分及包含简单多媒体信息的ussd传输方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101047879A true CN101047879A (zh) | 2007-10-03 |
Family
ID=38772020
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2006100253049A Pending CN101047879A (zh) | 2006-03-30 | 2006-03-30 | 多条可拆分及包含简单多媒体信息的ussd传输方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101047879A (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101925895B (zh) * | 2007-12-13 | 2012-11-07 | 谷歌公司 | 用于高效传输数据的通用格式 |
| CN102780981A (zh) * | 2011-05-12 | 2012-11-14 | 中兴通讯股份有限公司 | 动态菜单的分页方法及装置 |
| CN103893971A (zh) * | 2012-12-25 | 2014-07-02 | 腾讯科技（深圳）有限公司 | 一种游戏音效的制作方法和客户端 |
| CN106131925A (zh) * | 2011-11-01 | 2016-11-16 | 华为技术有限公司 | Gas查询方法及装置 |
| CN107645700A (zh) * | 2017-09-21 | 2018-01-30 | 数据通信科学技术研究所 | 一种基于ussd协议的移动通信数据传输方法 |
| CN109558476A (zh) * | 2018-12-20 | 2019-04-02 | 惠州Tcl移动通信有限公司 | 一种移动终端查询非结构化补充数据业务的方法及其终端 |
-
2006
- 2006-03-30 CN CNA2006100253049A patent/CN101047879A/zh active Pending
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101925895B (zh) * | 2007-12-13 | 2012-11-07 | 谷歌公司 | 用于高效传输数据的通用格式 |
| CN102780981A (zh) * | 2011-05-12 | 2012-11-14 | 中兴通讯股份有限公司 | 动态菜单的分页方法及装置 |
| CN106131925A (zh) * | 2011-11-01 | 2016-11-16 | 华为技术有限公司 | Gas查询方法及装置 |
| CN106131925B (zh) * | 2011-11-01 | 2020-01-03 | 华为技术有限公司 | Gas查询方法及装置 |
| CN103893971A (zh) * | 2012-12-25 | 2014-07-02 | 腾讯科技（深圳）有限公司 | 一种游戏音效的制作方法和客户端 |
| CN103893971B (zh) * | 2012-12-25 | 2015-05-27 | 腾讯科技（深圳）有限公司 | 一种游戏音效的制作方法和客户端 |
| US9993722B2 (en) | 2012-12-25 | 2018-06-12 | Tencent Technology (Shenzhen) Company Limited | Method and device for generating sounds effects for a game |
| US10258871B2 (en) | 2012-12-25 | 2019-04-16 | Tencent Technology (Shenzhen) Company Limited | Method and device for generating sounds effects for a game |
| CN107645700A (zh) * | 2017-09-21 | 2018-01-30 | 数据通信科学技术研究所 | 一种基于ussd协议的移动通信数据传输方法 |
| CN107645700B (zh) * | 2017-09-21 | 2020-10-27 | 数据通信科学技术研究所 | 一种基于ussd协议的移动通信数据传输方法 |
| CN109558476A (zh) * | 2018-12-20 | 2019-04-02 | 惠州Tcl移动通信有限公司 | 一种移动终端查询非结构化补充数据业务的方法及其终端 |
| CN109558476B (zh) * | 2018-12-20 | 2021-01-05 | 惠州Tcl移动通信有限公司 | 一种移动终端查询非结构化补充数据业务的方法及其终端 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1711784A (zh) | 用于发送sms以及文本消息的系统和方法 | |
| CN1235740A (zh) | 具有服务小区广播业务层次索引的移动站及网络 | |
| CN1297169C (zh) | 信息包通信终端、信息包通信系统及信息包通信方法 | |
| CN1708177A (zh) | 移动通信系统、访问路由器、管理装置以及移动通信方法 | |
| CN1852453A (zh) | 一种一卡多号业务呼出及呼入的方法 | |
| CN101047879A (zh) | 多条可拆分及包含简单多媒体信息的ussd传输方法 | |
| CN101064866A (zh) | 一种短信的路由寻址方法及系统 | |
| CN101040543A (zh) | 发送应用特定的登记或撤销登记数据的方法和系统、服务器和通信终端 | |
| CN1348664A (zh) | 网关中的电信业务标识 | |
| CN1852362A (zh) | 被叫向主叫提供指示信息的方法及其系统 | |
| CN1894921A (zh) | 发送台、接收台、通信方法、通信程序和记录了通信程序的计算机可读记录介质 | |
| CN1889771A (zh) | 一种hlr以及将传统移动终端接入ims域的方法及系统 | |
| CN1838642A (zh) | 利用即时消息系统实现问答业务的方法及系统 | |
| CN1889785A (zh) | 分组切换过程中对切换失败进行处理的方法和系统 | |
| CN1243370A (zh) | 通信系统及其网关、无线信息终端和无线通信方法 | |
| CN1867090A (zh) | 短信网址装置及实现短信增值业务的系统和方法 | |
| CN101047655A (zh) | 一种基于ip传输的消息路由方法和系统 | |
| CN1925519A (zh) | 电话呼叫的方法及电话终端 | |
| CN1778126A (zh) | 用于将多媒体消息多次元素插入多媒体消息中的方法和系统 | |
| CN1949752A (zh) | 一种电路交换网与ip多媒体子系统网络互通的系统和方法 | |
| CN1220808A (zh) | 智能网络中的外设控制 | |
| CN1523837A (zh) | 移动通信控制系统、网络管理服务器及节点 | |
| CN1625276A (zh) | 多区布置中的无线专网系统之间的短消息服务 | |
| CN101060703A (zh) | 用户设备切换时的策略和计费控制方法 | |
| CN101064683A (zh) | 处理补充业务的方法、系统及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20071003 |