CN101478377A - 一种消息响应方法及设备 - Google Patents
一种消息响应方法及设备 Download PDFInfo
- Publication number
- CN101478377A CN101478377A CNA2008100017172A CN200810001717A CN101478377A CN 101478377 A CN101478377 A CN 101478377A CN A2008100017172 A CNA2008100017172 A CN A2008100017172A CN 200810001717 A CN200810001717 A CN 200810001717A CN 101478377 A CN101478377 A CN 101478377A
- Authority
- CN
- China
- Prior art keywords
- message
- response
- converges
- management
- confirmation code
- 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
本发明实施例公开了一种消息响应方法，包括以下步骤：将至少两个针对接收到的需要响应的消息的响应信息汇聚到一个汇聚消息中；发送所述汇聚消息。本发明实施例还公开了一种消息响应设备，包括：响应消息生成单元，用于生成针对接收到的需要响应的消息的响应信息；汇聚单元，用于将至少两个所述响应信息汇聚到一个汇聚消息中；发送单元，用于发送所述汇聚消息。本发明通过一个汇聚消息将多个需要响应的消息的响应信息发送出去，减少了空口信令开销。
Description
技术领域
本发明涉及通信技术领域，尤其涉及一种消息响应的方法及设备。
背景技术
在通信系统中，相互通信的两个实体通信实体A和对端通信实体B之间要交互大量的信息，在有些情况下，通信实体A向通信实体B发送消息，并要求通信实体B对通信实体A发送给通信实体B的某些关键的消息做出响应，则通信实体B会在接收到这些消息后，发送相应的响应消息给通信实体A，具体流程如图1所示。
现有技术中，BS(BaseStation，基站)会发送多个要求响应的消息给终端，如MAC-REQ(Multicast Assignment Request，多播指配请求)、CHA-REQ(Channel Added Request，信道增加请求)，BLM-REQ(BulkMeasurement Request，批量测量请求)等，在现有技术中，在接收到这些消息后，终端将分别发送对应的响应消息，如MAC-RSP(Multicast AssignmentResponse，多播指配响应)、CHA-RSP(Channel Added Response，信道增加响应)，BLM-RSP(Bulk Measurement Response，批量测量响应)以确认接收到对应的请求消息。对于同一终端，这些响应消息都需要采用HMAC/CMACTuple，用于加密。其中，HMAC占21字节，CMAC占13或19字节(只在MDHO时为19字节)，短HMAC占13/15/17字节。由于每条消息都需要采用HMAC/CMAC tuple加密，通信中存在大量的冗余信息，降低了通信效率。
或者，BS向RS(Relay Station，中继站)发送MS_SCN-INF消息(也可以是MS_INFO-DEL、MR_SLP-INFO、RS_PATH-REQ等消息)。RS收到上述消息中的任何一个消息，向MR_BS响应MR_Generic-ACK消息作为MS_SCN-INF消息的确认。MR_Generic-ACK消息中还可以包括TLV编码信息：HMAC/CMAC Tuple，用于加密。其中，HMAC占21字节，CMAC占13或19字节(只在MDHO时为19字节)，短HMAC占13/15/17字节。如果消息中采用HMAC/CMAC tuple加密，则通信中会存在大量的冗余信息，降低了通信效率。
另外，RS可以向BS发送STA-INFO消息，BS收到STA-INFO消息后向RS响应MR_Generic-ACK消息。BS可能需要在同一帧为来自RS的多个STA-INFO消息响应MR_Generic-ACK消息，如果消息中采用HMAC/CMAC tuple加密，则通信中也会存在大量的冗余信息，降低了通信效率。
在实现本发明的过程中，发明人发现现有技术中存在以下缺点：
在现有技术中，通信实体之间发送的消息很多，一条要求响应的消息对应的都要由对端发送一条对应的响应消息，但实际上，不同的响应消息有部分内容相同，因此，如果每条响应消息都分别打包发送，则带来的冗余较大，降低了通信效率。
发明内容
本发明实施例提供了一种消息响应方法及设备，以减少响应所需的信令开销。
本发明实施例提供了一种消息响应方法，包括：
将至少两个针对接收到的需要响应的消息的响应信息汇聚到一个汇聚消息中；
发送所述汇聚消息。
本发明实施例提供了一种消息响应设备，包括：
响应消息生成单元，用于生成针对接收到的需要响应的消息的响应信息；
汇聚单元，用于将至少两个所述响应信息汇聚到一个汇聚消息中；
发送单元，用于发送所述汇聚消息。
本发明的实施例中，通过一个汇聚消息将多个对接收到的需要响应的消息的响应信息发送出去，减少了冗余信息，减少了空口信令开销，提高了通信效率。
附图说明
图1是现有技术中通信实体发送响应消息流程图；
图2是本发明实施例中一种消息响应方法流程图；
图3是本发明实施例中一种消息响应系统结构图。
具体实施方式
本发明实施例提供了一种消息响应方法，如图2所示，包括以下步骤：
步骤s201，将至少两个针对接收到的需要响应的消息的响应信息汇聚到一个汇聚消息中；
步骤s202，将所述汇聚消息发送出去。
本发明实施例中涉及到两个通信实体：第一通信实体和第二通信实体。第一通信实体向第二通信实体发送多个需要响应的消息。第二通信实体接收到多个需要响应的消息后，为每个消息生成相应的响应信息，并将多个响应信息汇聚到一个汇聚消息中。第二通信实体还可能在汇聚消息中包括其他信息，例如汇聚消息的消息类型、密钥信息。第二通信实体向第一通信实体发送汇聚消息。
具体地，第二通信实体汇聚得到的汇聚消息中包括：
被响应的消息数目，对每个被响应的消息，还包括该被响应消息的交易标识，并可能包括第二通信实体对该被响应消息的确认码(confirmation code)。这里，确认码可以用于表示第二通信实体是否接受该消息，此时确认码的选择可以是接受或者拒绝，如果拒绝，则还可以指示拒绝的原因，如配置失败、消息中的信息无效等。以下所述确认码均指这一含义，后续不再赘述。或者，
汇聚消息中包括发送被响应消息所使用的管理连接的数目，对每个管理连接，还包括管理连接标识、对应的被响应的消息的数目，对每个对应的被响应的消息，还包括交易标识并可能包括确认码。或者，
汇聚消息中包括被响应消息的数目，对每个被响应的消息，还包括该被响应的消息的类型值、交易标识并可能包括确认码。或者，
汇聚消息中包括被响应消息的类型的数目，对每个消息类型，还包括消息类型值、对应的被响应的消息的数目，对每个对应的被响应的消息，还包括交易标识并可能包括确认码。
第二通信实体在接收到每个需要响应的消息后，可以直接生成该消息的响应信息，也可以基于该消息进行一些处理后生成该消息的响应信息。第二通信实体在生成该消息的响应信息后，可以直接将该响应信息及其他响应信息汇聚到汇聚消息中，也可以等待一段时间后将该响应信息及其他响应信息汇聚到汇聚消息中。
本发明实施例一中，一种消息响应方法，包括以下步骤：
步骤s301：第一通信实体向第二通信实体发送多个需要响应的消息，每个消息中包括管理消息类型值、交易标识，并可能包括HMAC/CMAC Tuple TLV编码等其他信息。
步骤s302：第二通信实体接收到需要响应的消息后，确定为该消息返回应答并记录该消息的交易标识。如果第二通信实体在确定为消息返回应答时还为该消息生成了确认码，则还会记录该确认码。
步骤s303：第二通信实体计算被响应的消息数目(即所记录的交易标识的数目)。
步骤s304：第二通信实体生成汇聚消息(也可以称为多确认消息)，汇聚消息中包括汇聚消息的管理消息类型值、被响应的消息数目，对每个被响应的消息，还包括交易标识并可能包括确认码。汇聚消息中还可能包括HMAC/CMAC Tuple TLV编码。其中，汇聚消息的管理消息类型值可以是与其他管理消息类型值不同的某个值。
步骤s305：第二通信实体向第一通信实体发送汇聚消息。
多确认消息的消息格式的具体例子如表1，包括管理消息类型ManagementMessage Type、交易数目Num_of_Transactions、交易标识Transaction_ID、确认码confirmation code、填充部分和TLV编码信息。在表1的例子中，确认码指示接受/拒绝，因此大小设为1bit，这只是确认码的一个例子，此外，确认码大小也可以为多个比特，此时确认码指示接受/拒绝及原因，或者接受/拒绝/拒绝及原因。如果多确认消息中不包括确认码，则消息格式的具体例子是在表1的基础上去掉确认码和填充部分。多确认消息的管理消息类型值可以是不同于现有管理消息类型值的某个管理消息类型值，下同。
表1：
| 语法 | 大小 | 注释 |
| Multi-ACK_Message_Format(){ | ||
| Management Message Type＝TBD | 8bits | 多确认消息的管理消息类型值 |
| Num_of_Transactions | 8bits | 交易数目 |
| For(i＝0；i<Num_of_Transactions；i++){ | ||
| Transaction_ID | 16bits | 交易标识 |
| Confirmation Code | 1bit | 接受/拒绝 |
| } | ||
| Padding | 可变 | 如果需要，则填充以使消息达到整数字节大小 |
| TLV编码信息 | 可变 | TLV Specific |
| } |
本发明实施例二，一种消息响应方法，包括以下步骤：
步骤s401：第一通信实体向第二通信实体发送多个需要响应的消息，每个消息中包括管理消息类型值、交易标识，并可能包括HMAC/CMAC Tuple TLV编码等其他信息。
步骤s402：第二通信实体接收到需要响应的消息后，确定为该消息返回应答，并记录该消息所对应的管理CID和交易标识。如果第二通信实体在确定为消息返回应答时还为该消息生成了确认码，则还会记录该确认码。
步骤s403：第二通信实体计算所记录的管理CID的数目，并计算与每个管理CID对应的被响应的消息的数目(即与该管理CID对应的交易标识的数目)。
步骤s404：第二通信实体生成汇聚消息(也可以称为多确认消息)，汇聚消息中包括汇聚消息的管理消息类型值、被响应的消息的管理连接的数目，对每个管理连接，还包括管理连接CID、对应的被响应的消息的数目，对每个对应的被响应的消息，还包括交易标识并可能包括确认码。汇聚消息中也可能包括HMAC/CMAC Tuple TLV编码。其中，汇聚消息的管理消息类型值可以是与其他管理消息类型值不同的某个值。
步骤s405：第二通信实体向第一通信实体发送汇聚消息。
多确认消息的消息格式的具体例子如表2，多确认消息中包括管理消息类型，管理CID的数目，管理CID，交易数目，交易标识、确认码、填充部分和TLV编码信息。在表2的例子中，确认码指示接受/拒绝，因此大小设为1bit，这只是确认码的一个例子，此外，确认码大小也可以为多个比特，此时确认码指示接受/拒绝及原因，或者接受/拒绝/拒绝及原因。如果多确认消息中不包括确认码，则消息格式的具体例子是在表2的基础上去掉确认码。
表2：
| 语法 | 大小 | 注释 |
| Multi-ACK_Message_Format(){ | ||
| Management Message Type＝TBD | 8bits | 多确认消息的管理消息类型值 |
| Num_of_CID | 1bit | 管理CID的数目(本例中为1或2) |
| for(i＝0；i<Num_of_CIDs；i++){ | ||
| 管理CID | 16bits | 例如，基本CID/首要管理CID |
| Num_of_Transactions | 4bits | 交易数目 |
| for(i＝0；i<Num_of_Transactions；i++){ | ||
| Transaction_ID | 16bits | 交易标识 |
| Confirmation Code | 1bit | 同意/拒绝 |
| } | ||
| } | ||
| Padding | 可变 | 如果需要，则填充以使消息达到整数字节大小 |
| TLV编码信息 | 可变 | TLV Specific |
| } |
本发明实施例三中，一种消息响应方法，包括以下步骤：
步骤s501：第一通信实体向第二通信实体发送多个需要响应的消息，每个消息中包括管理消息类型值、交易标识，并可能包括HMAC/CMAC Tuple TLV编码等其他信息。
步骤s502：第二通信实体接收到需要响应的消息后，确定为该消息返回应答，然后，记录每个消息中的管理消息类型和交易标识。第二通信实体如果在确定为消息返回应答时还为该消息生成确认码，则还会记录该确认码。
步骤s503：第二通信实体计算被响应的消息数目(即管理消息类型的数目)。
步骤s504：第二通信实体生成汇聚消息(也可以称为多确认消息)，汇聚消息中包括汇聚消息的管理消息类型值、被响应的消息数目，对每个被响应的消息，还包括对应的管理消息类型值、交易标识、并可能包括确认码。汇聚消息中还可能包括HMAC/CMAC Tuple TLV编码。其中，汇聚消息的管理消息类型值可以是与其他管理消息类型值不同的某个值。
步骤s505：第二通信实体向第一通信实体发送汇聚消息。
多确认消息的消息格式的具体例子如表3，消息中包括被响应的消息的数目、管理消息类型值、交易标识、确认码、填充部分和TLV编码信息。此外，消息中也可以不包括确认码和填充部分。
表3：
| 语法 | 大小 | 注释 |
| Multi-ACK_Message_Format(){ | ||
| Management Message Type＝TBD | 8bits | 多确认消息的管理消息类型值 |
| Num_of_Messages | 8bits | 被响应的消息的数目 |
| for(i＝0；i<Num_of_Messages；i++){ | ||
| Management Message Type Value | 8bits | 管理消息类型值 |
| Transaction_ID | 16bits | 交易标识 |
| Confirmation Code | 1bit | 同意/拒绝 |
| } | ||
| Padding | 可变 | 如果需要，则填充以使消息达到整数字节大小 |
| TLV编码信息 | 可变 | TLV Specific |
| } |
本发明实施例四中，一种消息响应方法，包括以下步骤：
步骤s601：第一通信实体向第二通信实体发送多个需要响应的消息，每个消息中包括管理消息类型值、交易标识，并可能包括HMAC/CMAC Tuple TLV编码等其他信息。
步骤s602：第二通信实体接收到需要响应的消息后，确定可以对该消息做出响应并记录该消息的管理消息类型和交易标识。通信实体B如果为该消息生成了确认码，则还会记录该确认码。
步骤s603：第二通信实体计算被响应的消息所对应的管理消息类型的数目，并为每个管理消息类型计算对应的被响应的消息的数目(即所记录的与该管理消息类型对应的交易标识的数目)。
步骤s604：第二通信实体生成汇聚消息(也可以称为多确认消息)，汇聚消息中包括：汇聚消息的管理消息类型值、被响应的消息的管理消息类型数目，对每种类型的管理消息，还包括管理消息类型值、对应的被响应的消息的数目，对每个对应的被响应的消息，还包括交易标识并可能包括确认码。汇聚消息中还可能包括HMAC/CMAC Tuple TLV编码。其中，汇聚消息的管理消息类型值可以是与其他管理消息类型值不同的某个值。
步骤s605：第二通信实体向第一通信实体发送汇聚消息。
多确认消息的消息格式的具体例子如表4，消息中包括汇聚消息的管理消息类型值、被响应的消息的管理消息类型的数目、被响应的消息的管理消息类型值、交易数目、交易标识、确认码、填充部分和TLV编码信息。此外，消息中也可以不包括确认码。
表4：
| 语法 | 大小 | 注释 |
| Multi-ACK_Message_Format(){ | ||
| Management Message Type＝TBD | 8bits | 多确认消息的管理消息类型值 |
| Num_of_Message_Types | 8bits | 被响应的消息的管理消息类型的数目 |
| for(i＝0；i<Num_of_Messages_Types；i++){ | ||
| Management Message Type Value | 8bits | 被响应的消息的管理消息类型值 |
| Num_of_Transactions | 4bits | 交易数目 |
| for(j＝0；j<Num_of_Transactions；j++){ | ||
| Transaction_ID | 16bits | 交易标识 |
| Confirmation Code | 1bit | 同意/拒绝 |
| } | ||
| } | ||
| Padding | 可变 | 如果需要，则填充以使消息达到整数字节大小 |
| TLV编码信息 | 可变 | TLV Specific |
| } |
本发明实施例还提供了一种消息响应设备，如图3所示，包括：响应消息生成单元10，用于生成针对接收到的需要响应的消息的响应信息；汇聚单元20，用于将至少两个所述响应信息汇聚到一个汇聚消息中；发送单元30，用于发送所述汇聚消息；延时单元40，用于等待预设时间后将多个响应信息汇聚到汇聚消息中。其中，响应消息还携带被响应的消息的数目、交易标识、确认码、管理连接标识、消息类型值、管理连接的数目和消息类型的数目中的一种或几种。
本发明的实施例中，通过一个响应消息将多个对接收到的需要响应的消息的响应信息发送出去，减少了冗余信息，减少了空口信令开销，提高了通信效率。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (11)
1、一种消息响应方法，其特征在于，包括以下步骤：
将至少两个针对接收到的需要响应的消息的响应信息汇聚到一个汇聚消息中；
发送所述汇聚消息。
2、如权利要求1所述消息响应方法，其特征在于，所述汇聚消息中包括被响应的消息数目，及每个被响应的消息的交易标识。
3、如权利要求2所述消息响应方法，其特征在于，所述汇聚消息中还包括发送被响应的消息所使用的管理连接的数目，及每个管理连接的管理连接标识。
4、如权利要求2所述消息响应方法，其特征在于，所述汇聚消息中还包括被响应的消息的类型值。
5、如权利要求4所述消息响应方法，其特征在于，所述汇聚消息中还包括被响应的消息的类型的数目。
6、如权利要求2至5中任一项所述消息响应方法，其特征在于，所述汇聚消息中还包括对该被响应的消息的确认码，所述确认码用于表示是否接受该消息。
7、如权利要求6所述消息响应方法，其特征在于，所述确认码的选择为拒绝时，所述汇聚消息中包括指示拒绝的原因。
8、如权利要求1所述消息响应方法，其特征在于，所述将多个针对接收到的需要响应的消息的响应信息汇聚到一个汇聚消息中具体包括：
在生成该消息的响应信息后，直接将该响应信息及其他响应信息汇聚到汇聚消息中，或等待一段时间后将该响应信息及其他响应信息汇聚到汇聚消息中。
9、一种消息响应设备，其特征在于，包括：
响应消息生成单元，用于生成针对接收到的需要响应的消息的响应信息；
汇聚单元，用于将至少两个所述响应信息汇聚到一个汇聚消息中；
发送单元，用于发送所述汇聚消息。
10、如权利要求9所述消息响应设备，其特征在于，还包括：
延时单元，用于等待预设时间后将多个响应信息汇聚到汇聚消息中。
11、如权利要求9所述消息响应设备，其特征在于，所述响应消息还携带被响应消息的数目、交易标识、确认码、管理连接标识、消息类型值、管理连接的数目和消息类型的数目中的一种或几种。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008100017172A CN101478377A (zh) | 2008-01-02 | 2008-01-02 | 一种消息响应方法及设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008100017172A CN101478377A (zh) | 2008-01-02 | 2008-01-02 | 一种消息响应方法及设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101478377A true CN101478377A (zh) | 2009-07-08 |
Family
ID=40839015
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2008100017172A Pending CN101478377A (zh) | 2008-01-02 | 2008-01-02 | 一种消息响应方法及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101478377A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103391521A (zh) * | 2012-05-09 | 2013-11-13 | 华为技术有限公司 | 一种短消息传输的方法、装置及系统 |
| CN105450362A (zh) * | 2012-03-23 | 2016-03-30 | 广东新岸线计算机系统芯片有限公司 | 一种用于帧确认的方法和装置 |
| CN110209448A (zh) * | 2019-05-14 | 2019-09-06 | 李航 | 一种多输入共享视窗并发操作装置及方法 |
-
2008
- 2008-01-02 CN CNA2008100017172A patent/CN101478377A/zh active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105450362A (zh) * | 2012-03-23 | 2016-03-30 | 广东新岸线计算机系统芯片有限公司 | 一种用于帧确认的方法和装置 |
| CN103391521A (zh) * | 2012-05-09 | 2013-11-13 | 华为技术有限公司 | 一种短消息传输的方法、装置及系统 |
| CN103391521B (zh) * | 2012-05-09 | 2017-06-06 | 华为技术有限公司 | 一种短消息传输的方法、装置及系统 |
| CN110209448A (zh) * | 2019-05-14 | 2019-09-06 | 李航 | 一种多输入共享视窗并发操作装置及方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101877604B (zh) | 一种传输文件的方法及系统 | |
| CN104580158A (zh) | 一种分布式平台文件与内容分发方法及系统 | |
| US20090323580A1 (en) | Frame structure and sequencing for enabling network coding for wireless relaying | |
| CN112055078B (zh) | 一种数据传输方法、装置、计算机设备和存储介质 | |
| CN104683216A (zh) | 客服信息的转发方法及装置、客服系统 | |
| CN103312528A (zh) | 一种心跳消息发送方法及用户终端 | |
| CN105183687B (zh) | 一种分时串口通信方法及系统 | |
| CN100596123C (zh) | 一种网关系统及其消息业务处理方法 | |
| CN101478377A (zh) | 一种消息响应方法及设备 | |
| WO2010012221A1 (zh) | 一种短信发送的方法、设备和系统 | |
| CN107181794B (zh) | 基于dimse消息发送与接收的dicom网络传输方法 | |
| CN103391521B (zh) | 一种短消息传输的方法、装置及系统 | |
| CN101449539B (zh) | 配置连接的方法、无线电信网和移动终端 | |
| CN101888412A (zh) | 一种服务于移动终端直播的视频推送处理方法及系统 | |
| CN102497306B (zh) | 一种配网子站实现数据传输的方法和系统 | |
| CN111757553B (zh) | 一种提高冗余分组数据会话性能的方法和设备 | |
| CN104507059B (zh) | 一种彩信发送管理方法和彩信发送管理装置 | |
| CN104427473A (zh) | 通信设备和通信方法 | |
| EP4243354A1 (en) | Internet of things device monitoring method, server, and internet of things device | |
| CN103634843A (zh) | 数据传输方法、无线网络控制器、基站及移动通信系统 | |
| CN104486031A (zh) | 智能电表的长数据传输方法 | |
| CN101730317A (zh) | 发送消息的方法、装置和系统 | |
| CN110572440B (zh) | 用于数据传输的方法及装置、家电设备、存储介质 | |
| CN104506424A (zh) | 即时通讯中联系人状态的通知方法及通知装置 | |
| CN101174929A (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 | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20090708 |