[go: up one dir, main page]

CN105794135A - 用于数据传输的跨层和跨应用确认 - Google Patents

用于数据传输的跨层和跨应用确认 Download PDF

Info

Publication number
CN105794135A
CN105794135A CN201480041387.3A CN201480041387A CN105794135A CN 105794135 A CN105794135 A CN 105794135A CN 201480041387 A CN201480041387 A CN 201480041387A CN 105794135 A CN105794135 A CN 105794135A
Authority
CN
China
Prior art keywords
application
ack
layer
cross
frame
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.)
Granted
Application number
CN201480041387.3A
Other languages
English (en)
Other versions
CN105794135B (zh
Inventor
王重钢
李晴
丁宗睿
李鸿堃
小保罗·L·罗素
迈克尔·F·斯塔西尼克
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
Convida Wireless LLC
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 Convida Wireless LLC filed Critical Convida Wireless LLC
Publication of CN105794135A publication Critical patent/CN105794135A/zh
Application granted granted Critical
Publication of CN105794135B publication Critical patent/CN105794135B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1664—Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1864—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signalling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

系统和方法可以整合确认，诸如应用级确认和媒体访问控制层确认。在跨层确认方法的实施例，媒体访问控制层确认和应用层确认可以被整合为单个媒体访问控制层确认。在跨应用确认方法的实施例中，用于第一应用的应用层确认和用于第二应用的应用层确认可以被整合在单个媒体访问控制层帧。

Description

用于数据传输的跨层和跨应用确认
相关申请交叉引用
本申请要求2013年6月21日提交的题为“METHODSOFCROSS-LAYERANDCROSS-APPLICATIONACKNOWLEDGMENTFORDATATRANSMISSIONINPROXIMITYCOMMUNICATIONS”的美国临时专利申请No.61/837746的权益，其内容通过引用并入本文。
背景技术
物联网(IOT)将对象或事物引入基于人对人(H2H)的互联网服务。它标志着物理或虚拟对象被互连以实现服务互联网(IoS)的互联网阶段。许多这些服务是基于接近度的，诸如智能购物、智能家居、智能办公、智能医疗、智能交通、智能停车、智能电网和智能城市等。
接近服务可以基于接近的点对点(P2P)通信。P2P设备包括平板电脑、智能电话、音乐播放器、游戏机、个人数字助理、膝上型电脑/PC、医疗设备、联网汽车、智能仪表、传感器、网关、显示器、报警器、机顶盒、打印机、谷歌眼镜、无人驾驶飞机和服务机器人等。P2P通信系统可以是具有控制器或作为基础设施的核心网络的集中式系统、或不具有控制器或作为基础设施的核心网络的分布式系统。接近服务可以包括人对人(H2H)接近服务、机器对机器(M2M)接近服务、机器对人(M2H)接近服务、人对机器(H2M)接近服务和网间网接近服务。
基于接近的应用和服务表示了一种从核心基础设施卸载沉重的本地互联网业务并且提供经由多跳对基础设施的连接的趋势。许多标准已经将接近服务使用情况认为其标准化工作组的一部分，诸如3GPP、oneM2M、IETF、IEEE和OMA。服务层以及跨层技术是支持这些服务的标准化的领域。
接近服务可以使用对于可靠数据传输具有不同确认(即ACK)机制的无线网络，如IEEE802.15和IEEE802.11标准系列中规定的。
“IEEE802.15.4e,MACEnhancementforIEEE802.15.4-2006”ACK信息元素(IE)被定义用于使协调器确认在保证时隙(GTS)中发送的多个数据帧。组ACK用于向重传分配新的时隙。ACK帧可以包含附加内容作为IE。多信道自适应和切换被定义用于使发送方和接收方对切换其通信信道。
在“IEEE802.15.4kinPHY/MACAmendmentforLowEnergyCriticalInfrastructureNetworks”中，定义了增量ACK(IACK)，以协助可靠的MAC片段传输。每个IACK指示成功发送的片段和失败的片段。IACK可以被描述为ACK和NACK的组合。
在IETF约束应用协议(CoAP)中，在CoAP协议中存在ACK和重传。从本质上说，CoAP客户端首先向CoAP服务器发送请求。然后，如果请求需要被确认，则CoAP服务器需要向CoAP客户端发送回ACK。另外，CoAP服务器还可以负担响应以及ACK。这种ACK和响应是与完全独立于MAC层ACK的应用相关的CoAP级功能。无论是否存在MAC层ACK，CoAP协议将以这样的方式工作：分离的CoAPACK和CoAP响应或承载的CoAPACK和CoAP响应，如IETFCoAP中所规定的。
可以进一步优化如上所述的用于可靠数据传输的传统确认(例如，ACK)机制。
发明内容
传统协议中的MAC层确认是应用无视的或应用独立的。本文公开了一种整合了确认(诸如应用级确认和媒体访问控制层确认)的系统和方法。在实施例中，利用整合确认同时服务媒体访问控制层确认和应用层确认。在另一实施例中，可以利用整合的确认来在相同的ACK帧中确认多个应用。
提供该发明内容以简化形式介绍将在以下详细描述中进一步描述的原理的选择。该发明内容不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制要求保护的主题的范围。此外，要求保护的主题不限于解决在公开的任何部分中提出的任何或所有缺点。
附图说明
通过结合附图的示例，可以从下面的描述进行更详细地理解，其中：
图1A示出不使用跨层ACK的单跳消息流；
图1B示出使用跨层ACK的单跳消息流；
图2示出使用流线型跨层ACK的单跳消息流；
图3A示出当从用于跨层ACK的高层接收消息时发送UE的示例性流程图；
图3B示出当从用于跨层ACK的物理层接收消息时发送UE的示例性流程图；
图4示出用于跨层ACK的接收UE的流程图；
图5A示出不使用跨层ACK的多跳情形的消息流；
图5B示出使用跨层ACK的多跳情形的消息流；
图6示出使用跨应用ACK的单跳消息流；
图7示出使用跨层跨应用ACK的单跳消息流；
图8A示出不使用跨层ACK的通过IEEE802.15.4网络的CoAP的单跳消息流；
图8B示出使用跨层ACK的通过IEEE802.15.4网络的CoAP的单跳消息流；
图9示出可以使用整合的确认的用户设备的示例性协议栈；
图10A示出使用3GPPLTEUu接口用户平面协议栈的整合的ACK。
图10B示出使用3GPPLTEUu接口用户平面协议栈的整合的ACK。
图11A示出根据实施例的示例性非限制性修改和/或扩展的一般MAC帧格式；
图11B示出根据实施例的示例性非限制性的帧控制字段格式；
图12A是可以实现一个或多个所公开的实施例的示例性机器对机器(M2M)或物联网(IoT)通信系统的系统图；
图12B是在图12A中示出的M2M/IoT通信系统内可以使用的示例型架构的系统图；
图12C是在图12A中示出的通信系统内可以使用的M2M/IoT终端或网关设备的系统图；以及
图12D是可以实现图12A的通信系统的各方面的示例性计算系统的框图。
具体实施方式
传统协议中的MAC层确认是应用无视的或应用独立的。本文公开了整合和优化应用级ACK(例如，CoAP级ACK)和MAC层ACK(例如，IEEE802.15.4ACK)的方法和系统。可以通过定义整合的ACK消息来实现优化，这能够减少发送方和接收方之间需要的消息的数目。如本文中所讨论的，整合的MACACK可以包括跨层ACK、跨应用ACK或跨层跨应用ACK。
在诸如IEEE802.15和IEEE802.11系列的大多数的MAC协议中，存在基于ACK的重传机制，用于在MAC层中提供单跳可靠传输。高层协议(例如，TCP、COAP)还提供基于端对端ACK机制的端对端(多跳或单跳)可靠传输。然而，MAC层重传和应用层重传是彼此独立的。换句话说，MAC层重传基于MAC层ACK，并且高层重传仅基于应用层ACK，如在下面进一步详细讨论的。
对于单跳内出现多数应用的接近通信，尽管有时需要多跳，但是事实证明，独立处理的MAC层重传和高层重传可能是多余的。在多数MAC协议(例如，IEEE802.15.4)中存在对应用层无用的MAC层ACK消息。可以通过允许在MAC层ACK中允许承载“应用数据”来减少消息的数目。“应用数据”可以是应用ACK。
本文所讨论的方法和系统公开了如何协调和优化用于多个应用的MAC层传输(或重传)和高层传输(或重传)机制。下面更详细地解释用于接近通信的可靠数据传输的确认机制，诸如跨层ACK、跨应用ACK和跨层跨应用ACK。而且，如在本文中更详细讨论的，应用数据是指来自比MAC层更高的层的数据，诸如层4(例如，TCP、SCTP等)、层5(例如，CoAP、HTTP等)或比MAC层更高的其他层的数据。应用ACK是指用于应用数据的ACK。所公开的方法和系统可以对MAC层协议有影响，诸如IEEE802.15.8、IEEE802.15.4或IEEE802.11x。
跨层ACK涉及被整合为单个MAC层ACK的MAC层ACK(例如，IEEE802.15.4)和应用层ACK(例如，CoAP)(下文中的整合的MACACK)。整合的ACK用于服务MAC层确认和应用层确认两者。图1A和图1B示出用户设备(UE)之间的通信在单跳内的情形。如本文所讨论的，UE可以被认为是移动站、固定或移动订户单元、寻呼器、蜂窝电话、个人数字助理(PDA)、智能电话、笔记本电脑、上网本、个人计算机、无线传感器或致动器、消费电子产品、医疗器械、汽车等。
图1A示出不使用跨层ACK的传统消息流110。UE111可以被认为是发送方UE，而UE112可以被认为是接收方UE。在步骤113，UE111向UE112发送包括应用数据的MAC数据帧。在步骤114，UE112向UE111发送MACACK，该MACACK向UE111确认UE112已经接收到步骤113的MAC数据帧。在步骤115，UE112发送包括应用ACK的MAC数据帧，该应用ACK向UE111确认UE112已经接收到步骤113的应用数据。在步骤116，UE111向UE112发送MACACK，该MACACK确认接收步骤115的MAC帧。
传统消息流111示出包含MAC应用数据(在步骤113和步骤115)的两个MAC数据帧所需要的两个MACACK帧(在步骤114和步骤116)。总体上，如图1A所示，在UE111和UE112之间存在四个消息。步骤113的应用数据可以是应用请求，并且步骤115的应用ACK可以是应用响应。
图1B示出UE使用跨层ACK的消息流117。在步骤118，UE111向UE112发送包括应用数据的MAC数据帧。在步骤102，用于步骤118的应用数据的APPACK对UE112变得可用。在步骤119，UE112向UE111发送整合的MACACK。步骤119的整合的MACACK是包括“普通”MACACK(类似于步骤114的MACACK)和“普通”应用ACK(类似于步骤115的应用ACK)的一个消息。换句话说，步骤119的整合的MACACK同时用于两个目的。其用于确认从UE111到UE112的步骤118的先前MAC数据帧。此外，步骤119的整合的MACACK确认包含在步骤118的先前MAC数据帧中的应用数据。
通过跨层ACK，总消息的数目可以从四个被减少到两个，如图1B所示。因为每个消息可以包含MAC报头、MAC末尾、PHY报头和PHY末尾，所以使用跨层ACK可以有助于减少要被发送的总比特。此外，消息的减少可以减少空中信道冲突的可能性。总体上，减少可以提高在延迟、吞吐量和能源消耗等方面的性能。
在图1B中，UE112可能需要时间来计算应用ACK(以下，也称为AppACK)。因此，在跨层ACK的实现中，可以不发出整合的MACACK，直到配对的AppACK变得可用。图2示出用于“流线型跨层ACK”的消息流120，其中，AppACK没有必要与和承载应用数据的MAC帧相关联的MACACK配对。在步骤121，UE111向UE112发送包括第一应用数据的MAC数据帧。在步骤122，UE112向UE111发送对于步骤121的接收的MAC数据帧的MACACK。在步骤123，UE111向UE112发送包括第二应用数据的MAC数据帧。
继续参考图2，在步骤127，对步骤121的应用数据的AppACK对UE112变得可用。在步骤124，UE112向UE111发送整合的MACACK，该整合的MACACK包括用于步骤123的MAC数据帧的MACACK以及用于步骤121的第一应用数据的AppACK。在步骤125，UE111向UE112发送包括第三应用数据的MAC数据帧。在步骤128，用于步骤123的应用数据的AppACK对UE112变得可用。在步骤126，UE112向UE111发送整合的MACACK，该整合的MACACK包括用于步骤125的MAC数据帧的MACACK以及用于步骤123的第二应用数据的AppACK。
参考图2，附加步骤示出UE112可以保持多个AppACK，并且如果多个AppACK在阈值时间间隔内变得可用，则将其一起承载在一个直接MACACK中。在步骤129，UE111向UE112发送包括第四应用数据的MAC数据帧。在步骤130，用于步骤125的第三应用数据的AppACK对UE112变得可用。在步骤131，用于步骤129的第四应用数据的AppACK对UE112变得可用。在步骤132，UE112向UE111发送整合的MACACK，该整合的MACACK包括用于步骤129的MAC数据帧的MACACK以及用于步骤125的第三应用数据的AppACK和用于步骤129的第四应用数据的AppACK。
参考跨层ACK，在一些情况下，当保持AppACK在下一整合的MACACK中被发送时，可能存在延迟。对于诸如语音，视频流送和内容共享等的连续或交互式应用，这通常不是显著问题。此外，从应用的角度，延迟AppACK还可以带来好处。例如，延迟TCPACK可以帮助在发送方减少窗口大小。对无线TCP的研究已经证明：以该方式的TCP延迟可以减轻或移除可能的拥塞(即，用于无线接近通信的TCP增强)。
图3A和图3B示出可以被认为是用于跨层ACK操作的发送方的UE111的流程图。图3A示出UE111的低层(例如，MAC层)从UE111的高层(例如，应用层)接收消息的流程图。在步骤141，从高层接收消息。在步骤142，MAC层可以确定消息是否需要ACK。如果消息需要ACK，则在步骤143，MAC层可以确定该消息是完整消息还是片段消息。如果是完整消息，则在步骤144启用跨层ACK。
在步骤145，在启用跨层ACK之后，执行跨层ACKMAC过程。该过程可以包括禁用MAC片段并且在MAC帧中标记用于从接收方请求整合的ACK的标志。替代地，可以启用片段，并且仅标记整合的ACK的最后一个片段。UE111可以保持在MAC帧和应用消息(即，高层数据)之间的映射关系。在步骤148，经由PHY帧发送消息。在实施例中，可以存在指示符，该指示符提醒MAC层是否将来自应用的消息与来自不同层(例如，层4与层5)的“应用”分组在一起。
参考图3A的步骤142和步骤143，如果高层消息不需要ACK或如果消息被分段，则在步骤146，可以针对该消息禁用或不激活跨层ACK。在步骤147，可以执行传统MAC过程。
图3B示出从PHY层(例如，低层)接收消息的UE111的MAC层的流程图150。在步骤151，UE111的MAC层从PHY层接收消息。在步骤152，MAC层确定MACACK帧是否是整合的MACACK。如果MACACK帧是整合的MACACK，则在步骤153，执行跨层MAC过程。在步骤153，整合的ACK被映射到MAC数据帧。此外，整合的ACK被映射到应用数据。而且在步骤153，传统(即，普通)应用ACK被重构，并且将重构的应用ACK转发到应用层。参考步骤152，如果MACACK帧不是整合的MACACK，则在步骤154执行传统MAC过程。如果针对先前发送的MAC帧，UE111没有从接收方(UE112)接收到预期的整合的MACACK或普通MACACK，则UE111重传MAC帧，直到重传时间期满。
图4示出用于跨层ACK操作的UE112(即，接收方)的流程图160。在步骤161，UE112的MAC层从UE12的PHY层接收MAC帧。在步骤162，UE112确定是否设置整合的ACK标志。如果没有设置该标志，则在框165执行普通MAC过程。如果设置了整合的ACK标志，则在步骤163启用跨层ACK。在框164，执行跨层MAC过程。步骤164的整合的MACACK过程包括将应用数据传递到高层。此外，从高层接收应用ACK或响应。而且，步骤164的整合的MACACK过程可以包括保持MACACK达阈值时间，直到应用ACK到达。如果UE112发现获取应用ACK的阈值时间已经过去，则UE112可以禁用跨层ACK并且使用普通MACACK过程。一旦接收到应用ACK，就可以发送整合的ACKMAC帧。在步骤166，经由PHY帧发送MACACK帧。替代地，UE112可以独立地确定使用普通ACK或跨层ACK。图3A、图3B和图4中的全部或部分步骤可以在一个或多个层之间散布。
参考图4，在实施例中，UE112可以在发送与步骤161相关联的整合的MACACK之前，等待设定的时间，该设定的时间可以是手动地(例如，由用户设置)或者自动地(例如，基于诸如视频流送应用、聊天应用、健康应用等的应用的类型自动地修改)被预先确定。
图5A和图5B示出中继器182位于UE181和UE183之间的多跳情形。图5A示出不使用跨层ACK的多跳流。在步骤184，UE181向中继器182发送包括第一应用数据的MAC数据帧。在步骤185，中继器182向UE181发送MACACK。在步骤186，中继器182向UE183转发包括步骤184的第一应用数据的MAC数据帧。在步骤187，UE183向中继器182发送用于步骤186的MAC数据帧的MACACK。在步骤188，UE183向中继器182发送具有用于在步骤186接收的第一应用数据的AppACK的MAC数据帧。在步骤189，中继器186向UE183发送用于在步骤188接收的MAC数据帧的MACACK。在步骤190，中继器182转发MAC数据帧，该MAC数据帧包括用于步骤186和步骤184的第一应用数据的AppACK。在步骤191，UE181向中继器182发送用于在步骤190接收的MAC数据帧的MACACK。
图5B示出使用跨层ACK的示例性多跳情形。在步骤193，UE181向中继器182发送包括第一应用数据的MAC数据帧。在步骤194，中继器182向UE181发送MACACK。在步骤195，中继器182向UE183转发包括步骤193的第一应用数据的MAC数据帧。在步骤196，用于第一应用数据的AppACK对UE183变得可用。在步骤197，UE183向中继器182发送整合的MACACK，该整合的MACACK包括用于步骤195的MACACK以及用于步骤195和步骤193的第一应用数据的AppACK。在步骤198，中继器182向UE181发送包括用于步骤193的第一应用数据的AppACK的MAC数据帧。不需要发送整合的MACACK，因为对于193的MAC数据帧，在步骤194发送了MACACK。在步骤199，UE181向中继器182发送用于从步骤198中接收的MAC数据的MACACK。
参考图5B，用于每一跳的MACACK帧可以包含用于支持用于改善可靠传输的高级特征的更多信息。例如，标志比特可以用于指示相应的数据帧是否被转发。该比特可以通过UE181(如果UE181使用基于源的路由协议)来设置，或者UE181可以通过中继器182来设置。还可以存在用于指示跳数的更多比特。与UE183相距一跳的中继器182可以确定是否启用跨层ACK。UE183(接收方)可以独立地确定是否使用跨层ACK。
在下面更详细地讨论跨应用ACK。对于跨应用ACK，来自不同应用的ACK被整合在一起，并且在同一MACACK帧中被发送。图6示出在UE201(发送方)和UE202(接收方)之间的另一类型的整合的ACK消息流200(跨应用ACK消息流)。可以假设UE201和UE202同时运行多个应用(例如，应用1和应用2)并且在一跳内。
参考图6，在步骤210，UE201设置用于应用1数据的跨应用ACK标志。跨应用ACK标志可以是MAC数据帧的报头中的比特。该标志指示所包含的应用数据可以是否与其他应用数据被联合确认。在步骤203，UE201向UE202发送包括具有跨appACK标志的应用1数据的MAC数据帧。在步骤213，UE202确定是否存在在步骤203接收的MAC报头中设置的跨应用ACK标志比特。如果设置了标志比特，则UE202将应用数据1标记为用于跨应用ACK的候选。在步骤204，UE202向UE201发送用于步骤203的MAC数据帧的MACACK。
在步骤211，UE201针对应用2数据设置跨应用ACK标志。在步骤205，UE201向UE202发送包括具有设置的跨应用ACK标志的应用2数据的MAC数据帧。在步骤214，UE202确定存在在步骤205接收的MAC报头中设置的跨应用ACK标志比特，并且UE202将应用数据2标记为用于跨应用ACK的候选。在步骤206，UE202向UE201发送用于步骤205的MAC数据帧的MACACK。
在步骤215，UE202在步骤207的MAC数据帧的报头中设置标志比特，以指示跨应用ACK被包含在步骤207的MAC数据帧中。在步骤207，UE202向UE201发送MAC数据帧。
在步骤208，UE201向UE202发送用于步骤207的MAC数据帧的MACACK。步骤207的MAC数据帧包括跨appACK，其用于确认步骤203的应用1数据和步骤205的应用2数据的接收。应用1ACK和应用2ACK可以在步骤207的MAC数据帧的净荷内。在步骤212，UE201确定在MAC报头中设置指示跨应用ACK在步骤207的MAC数据帧中使用的标志(例如，比特)。UE201解码该MAC数据帧，并且向高层中的相应应用转发应用1ACK和应用2ACK。
步骤207的MAC数据帧可以包括支持跨应用层ACK的参数(诸如跨应用ACK标志)、应用ACK参数的数目(在当前帧和允许阈值中-最大)和应用ID的列表等。例如，一些应用参数可以指示包含在步骤207的MAC数据帧中的应用ACK的数目。应用ID可以指示承载的ACK(即，步骤207的跨层ACK)所属的相应应用。
以下更详细地讨论跨层跨应用ACK。对于跨层跨应用ACK，不同层和不同应用被整合为单个MAC层ACK。换句话说，利用单个整合的MACACK来确认来自不同应用的MAC帧和数据。图7示出跨层跨应用消息流220。可以假设UE221(发送方)和UE222(接收方)同时运行多个应用(例如，应用1和应用2)。还可以假设UE221和UE222在一跳内，并且应用1和应用2实现用于保证可靠传输的应用ACK。
参考图7，在步骤225，UE221向UE222发送具有应用1数据的MAC数据帧。在步骤227，UE221向UE222发送具有应用2数据的MAC数据帧。除本文讨论的其他事项外，步骤225和步骤227的MAC数据帧可以包括跨应用ACK标志、应用参数的数目和和应用ID的列表。例如，UE221可以在步骤225和227的MAC数据帧的MAC报头中设置标志比特，以提醒UE222可以针对应用1和应用2启用跨层跨应用。
在步骤230，UE222向UE221发送整合的跨层跨应用MACACK。存在可以包括在步骤230的MACACK中的内容的多个排列。在第一选项中，步骤230的整合的跨层跨应用MACACK可以包括响应于步骤227的MAC数据帧的传统MACACK和步骤225的应用1数据的应用ACK。对于第一选项，UE222不需要等待计算用于应用2数据的应用ACK。UE222在接收步骤227的MAC数据帧之后立即发出MACACK，并且承载用于步骤225的应用1数据的应用ACK，因为其可用于与MACACK同时被发送。
继续参考7，在步骤230的第二选项中，整合的跨层跨应用MACACK包括步骤225和227的MAC数据帧和应用的确认。假设图7中的所有ACK在步骤230的传输之前的阈值时段内已经到达。
下面讨论的是结合本文公开的方法和系统使用约束应用协议(CoAP)的实现的示例性流。CoAP是可以在诸如无线传感器网络节点的资源约束互联网设备中使用的应用层协议。在下面讨论关于CoAPACK(即，应用ACK)和IEEE802.15.4ACK如何(即，MACACK)的细节。
图8A示出使用802.15.4和不使用任何跨层ACK或跨应用ACK的传统(“普通”)CoAP消息流230。协调器231是CoAP客户端，并且设备232是CoAP服务器。在步骤233，设备232向协调器231发送MAC数据请求帧。在步骤234，协调器231向设备232发送用于步骤233的MAC数据请求帧的MACACK。在步骤235，协调器231向设备232发送包括CoAP请求的MAC数据帧。在步骤236，设备232向协调器231发送用于步骤235的MAC数据帧的MACACK。在步骤237，设备232向协调器231发送用于步骤235的CoAP请求的CoAPACK。在步骤238，协调器231向设备232发送用于步骤237的MAC数据帧的MACACK。在步骤239，设备232向协调器231发送包括用于步骤235的CoAP请求的CoAP响应的MAC数据帧。在步骤240，协调器231向设备232发送用于步骤239的MAC数据帧的MACACK。在步骤241，协调器231向设备232发送包括用于步骤29的CoAP响应的CoAPACK的MAC数据帧。在步骤242，设备232向协调器242发送用于步骤241的MAC数据帧的MACACK。
图8B示出跨层ACKCoAP消息流250。在步骤251，设备232向协调器231发送MAC数据请求帧。在步骤252，协调器231向设备232发送用于步骤251的MAC数据请求帧的MACACK。在步骤253，协调器231向设备232发送包括CoAP请求的MAC数据帧。在步骤254，设备232向协调器231发送用于MAC数据帧和步骤253的CoAP请求的跨层ACK。在步骤255，设备232向协调器231发送包括CoAP响应的MAC数据帧。在步骤256，协调器231向设备232发送用于MAC数据帧和步骤255的CoAP响应的跨层ACK。
使用跨层ACK的图8B示出与不使用跨层ACK的图8A相比的消息的减少。在图8A中有10个步骤，而在图8B中有6个步骤。
如上所述，可以存在附加字段或添加的参数，以实现跨层、跨应用和跨层跨应用确认。表1呈现可以在MAC帧中使用的一些字段的示例。例如，在MAC数据帧报头中可以存在跨层ACK比特，以指示当前MAC数据帧期望或请求整合的MACACK。在MACACK帧报头中可以存在跨层ACK比特，以指示当前MACACK是整合的MACACK帧。
表1.MAC帧的示例性附加参数
图9示出可以使用跨层或跨应用ACK并且可以参与接近通信的用户设备(例如，UE111或UE112)的示例性协议栈261。如上所述，如本文所讨论的，应用层(即，高层)可以包括传输层262、应用协议层263、服务层264、应用层265或高于MAC层的其他层。
图10A和图10B示出如本文讨论的使用3GPPLTEUu接口用户平面协议栈的整合的ACK。如图10A和10B所示，3GPP可以包括应用层、应用协议层、传输层、互联网协议(IP)层、分组数据会聚控制(PDCP)层、无线电链路控制(RLC)层、媒体访问控制(MAC)层和物理(PHY)层。所公开的整合的ACK可以被实现为3GPPRLC和3GPPMAC的一部分，以经由所公开的整合的ACK方法来增强系统性能。如上所述的部分或全部MAC级过程(例如，图3A、图3B、图4等)可以使用RLC层273或MAC层274来进行。这里，使用RLC层273和MAC层274来进行指示与整合的ACK相关的MAC过程的至少一部分的点272。TCP271和HTTP270可以使用整合的ACK，其中，点272向不同层分配ACK。图10B示出多个应用(应用277和应用278)但是在同一层的另一示例。应用277和应用278可以使用整合的ACK，其中，点279向不同层分配ACK。
图11示出可以结合本文所述的跨层和跨应用确认过程使用的修改的MAC帧格式400的一个实施例。在图11A和图11B中，以粗体、斜体和下划线指示的字段是新的或修改的字段，并且可以包括新的子字段。其他字段可以具有与现有IEEE802.15.4和802.11标准中定义的相同的含义。
如示，帧400通常包括MAC报头402和MAC净荷404。在一个实施例中，除了辅助字段416和辅助安全报头418之外，可能需要帧中的所有字段。在实施例中，序列号字段408和辅助安全报头418可以具有与IEEE802.15.4标准中定义的相同的含义。
在该实施例中，帧控制字段406承载控制信息，诸如帧类型、确认消息的所需类型和寻址模式。图11B示出帧控制字段的格式400的一个实施例。在实施例中，帧类型、帧待处理(framepending)、帧版本、安全启用和IE存在字段可以具有与IEEE802.15.4标准中定义的相同的含义。在一个实施例中，该帧控制字段406中的所有字段可以是强制性的。
帧类型和子类型字段424、426可以是强制性的，并且可以一起指示帧的类型，即，帧的功能。在一个实施例中，存在四个基本帧类型：信标、管理、数据和确认。每种类型的帧可以具有若干子类型。此外，对于不同帧类型，子类型字段的含义可以变化。在一个实施例中，确认帧类型可以用于指定在本文所述的跨层和跨应用确认过程中使用的帧。表2示出用于确认帧的帧类型424和帧子类型426值的一个实施例。如示，在一个实施例中，子类型“4”、“5”和“6”可以用于指定在跨层、跨应用以及跨层和跨应用二者确认中使用的帧。
帧类型值 帧类型 帧子类型值 帧子类型
3 ACK 0 单独ACK
1 聚合ACK
2 条件ACK
3 组ACK
4 跨层ACK
5 跨应用ACK
6 跨层和跨应用ACK
7 片段增量ACK(IACK)
表2.ACK帧的类型和子类型组合
仍参考图11B，在实施例中，帧控制字段406中的所需ACK类型字段428可以指定希望哪个类型的确认帧。例如，所需的ACK类型字段可以如以下表3中所示被设置。
所需的ACK类型值 所需的ACK类型
0 无ACK
1 单独ACK
2 聚合ACK
3 条件ACK
4 组ACK
5 跨层ACK
6 跨应用ACK
7 跨层跨应用ACK
8 片段增量ACK(IACK)
表3.所需ACK类型字段428的帧
返回参考图11A，寻址字段可以由源地址、目的地地址、发送跳地址和接收跳地址中的一个或多个组成。源地址和目的地地址字段可以承载帧的源和目标地址。发送跳地址和接收跳地址字段可以被保留用于多跳情形，承载中间对等体的地址信息。发送跳地址是发送此该的对等体的地址。接收跳地址是接收该帧的对等体的地址。可以通过寻址字段指示来指示发送跳地址和/或接收跳地址字段的存在。
如图11A所示，MAC帧格式400可以进一步包括地址字段指示字段410，地址字段指示字段410可以包含在寻址字段412中存在发送跳地址的和接收跳地址的指示。尽管源和目的地地址可以总是存在于寻址字段412中，但是发送跳地址和接收跳地址的存在针对多跳情形可以是可选的。例如，对于单跳传输，都不存在，对于多跳传输的第一跳(即，原始源发送帧)，仅存在接收跳地址并且发送跳地址与源地址相同，对于多跳传输的最后一跳，仅存在发送跳地址并且接收跳地址与目的地地址相同，并且对于多跳传输的其他跳，包括发送跳地址和接收跳地址二者。此外，当如最后两个示例(最后一跳和其他跳)建立寻址字段指示时，帧可以是中继帧。
如图11A进一步所示，P2PNW/APPID字段414字段可以包含P2P网络ID或应用ID。加入P2P网络(NW)的所有对等体可以具有本地唯一的P2PNW/APPID。如果当帧被发送时没有确定P2PNWID，则该字段可以承载应用ID。因为可以通过应用或服务形成P2PNW，所以P2PNWID可以是用于定义和区分应用特定的P2PNW的网络标识符。由于接近服务的分布式性质，因此P2PNWID可以是本地唯一的。
P2PNWID可以包括但不限于，指示所希望的服务或应用(例如，用于社交网络的Facebook、用于视频流的Netflix等)的CAID或应用ID、指示P2PNW的位置的位置信息、生成P2PNWID的对等体的ID以及可以用于区分具有相同上下文信息的现有P2PNW的网络序列号。可以使用不同结构生成P2PNWID，诸如每条信息被指派有一些信息比特且所有信息段被级联的级联结构、或者所有信息段通过诸如XOR和哈希的某个数学运算被加在一起的并行结构。
基于不同的控制方案，可以通过网络中的不同方生成和指派P2PNWID。在集中式控制方案实施例中，可以通过超级虚拟领导者(VL)生成P2PNWID，其然后通知VL，或VL可以生成P2PNWID，并且在信标中将其广播以通知超级VL和其他VL。在混合控制方案实施例中，VL可以生成P2PNWID，并且在信标中将其广播，以通知其他VL。在分布式控制方案实施例中，想要形成P2PNW的对等体(即，定义新应用帧的对等体)可以生成P2PNWID，并且广播信标以通知P2PNWID附近内的每个对等体。虚拟领导者(VL)是在共享相同接近服务(即P2PNW内)的对等体的组当中的、可以被动态选择为代表、管理和协调P2P通信的对等体。超级虚拟领导者是被定义为针对不同的附近服务来协调附近P2PNW的所有虚拟领导者的虚拟领导者。虚拟领导者和超级虚拟领导者可以用于同步、功率控制、干扰管理、信道分配、接入控制等目的。
仍参考图11A，辅助字段(AuxiliaryField)字段416可以包含可选的但是对一些功能非常重要的字段。例如，可以包括上下文类别字段，上下文类别字段指示应用或服务的类别，诸如紧急服务、社交联网、智能办公等。作为另一示例，可以包括跳指示符字段，跳指示符字段指示帧发送方是否愿意中继其他帧用于多跳发现过程。
虽然3GPP和802.15通过背景技术的方式被描述并且可以用于示出本文描述的各种实施例，但是应该理解，实施例的实现可以在保持落入本公开的范围内的同时进行变化。本领域技术人员还将认识到，所公开的实施例不限于如上所述的使用802.15或3GPP的实现，而是一些或全部可以使用其他架构和系统来实现和与之整合，诸如ETSIM2M、oneM2M、MQTT和其他系统和架构。
图12A是可以实现一个或多个公开的实施例(诸如图2、图5B或图7)的示例性机器对机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图。通常，M2M技术为IoT/WoT提供构件，并且任何M2M设备、网关或服务平台可以是IoT/WoT服务层以及IoT/WoT的组件等。
如图12A所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息、广播等内容的多址网络。例如，通信网络12可以采用一种或多种信道接入方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。此外，通信网络12可以包括例如其他网络，诸如核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络或者企业网络。
如图12A所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场域(FieldDomain)。基础设施域是指端到端M2M布置的网络侧，并且现场域是指区域网络，通常在M2M网关后。现场域包括M2M网关14和终端设备18。应当理解，任何数目的M2M网关设备14和M2M终端设备18可以根据需要被包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M终端设备18中的每一个被配置为经由通信网络12或直接无线电链路发送和接收信号。在一些实施例中，M2M网关设备14和M2M终端设备18可以使用跨层ACK、跨应用ACK或跨层跨应用ACK进行通信，如本文所讨论的。M2M网关设备14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过诸如通信网络12的运营商网络或直接无线电链路进行通信。例如，M2M设备18可以经由通信网络12或直接无线电链路收集数据并且向M2M应用20或M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。此外，可以经由M2M服务层22向M2M应用20发送和从M2M应用20接收数据和信号，如下所述。M2M设备18和网关14可以经由各种网络进行通信，包括蜂窝、WLAN、WPAN(例如，Zigbee、6L0WPAN、蓝牙)、直接无线电链路和有线线路。
参考如图12B，现场域中示出的M2M服务层22向M2M应用20、M2M网关设备14、以及M2M终端设备18和通信网络12提供服务。应当理解，M2M服务层22可以根据需要与任何数目的M2M应用、M2M网关设备14、M2M终端设备18和通信网络12进行通信。可以通过一个或多个服务器、计算机等实现M2M服务层22。M2M服务层22提供适用于M2M终端设备18、M2M网关设备14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式来在蜂窝核心网络中、在云中等被实现为例如web服务器。
类似于示出的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'在基础设施域中向M2M应用20'和底层通信网络12'提供服务。M2M服务层22'还在现场域中向M2M网关设备14和M2M终端设备18提供服务。应当理解，M2M服务层22'可以与任何数目的M2M应用、M2M网关设备和M2M终端设备进行通信。M2M服务层22'可以通过不同的服务提供商与服务层进行交互。M2M服务层22'可以通过一个或多个服务器、计算机、虚拟机(例如，云/计算/存储群等)等来实现。
还参考图12B，M2M服务层22和22'提供不同应用和垂直可以利用的一组核心服务交付能力。这些服务能力使M2M应用20和20'与装置进行交互，并执行功能，诸如数据采集、数据分析、设备管理、安全、计费、服务/设备发现等。从本质上讲，这些服务功能使应用没有实现这些功能的负担，从而简化应用开发，降低成本和上市时间。服务层22和22'还使M2M应用20和20'通过与服务层22和22'提供的服务连接的各种网络12和12'进行通信。
在一些实施例中，M2M应用20和20'可以包括标记使用跨层ACK，跨应用ACK或跨层跨应用ACK的期望的应用，如本文所讨论的。M2M应用20和20'可以包括各个行业的应用诸如但不限于交通，卫生和健康、家庭联网、能源管理、资产跟踪和安全监视。如上所述，设备间运行的M2M服务层、设备、网关和其他系统的服务器支持功能，诸如，例如，数据收集、设备管理、安全、计费、位置跟踪/地理围栏、设备/服务发现和旧系统整合，并且向M2M应用20和20'提供这些功能作为服务。
本申请的跨层ACK、跨应用ACK或跨层跨应用ACK可以被实现为使用ACK的服务层的一部分。例如，来自服务层的消息可以具有标志，该标志指示对该服务允许跨层ACK。服务层是通过一组应用编程接口(API)和底层网络接口支持增值服务能力的软件中间件层。M2M实体(例如，M2M功能实体，诸如可以通过硬件和软件的组合实现的装置，网关或服务/平台)可以提供应用或服务。ETSIM2M和oneM2M两者使用可以包括与本发明的跨层ACK跨应用ACK或跨层跨应用ACK工作的组件的服务层。ETSIM2M的服务层被称为服务能力层(SCL)。可以在M2M设备(被称为装置SCL(DSCL))网关(被称为网关SCL(GSCL))和/或网络节点(被称为网络SCL(NSCL))内实现SCL。oneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。一组一个或多个特定类型的CSF的实例被称为公共服务实体(CSE)，它可以在不同类型的网络节点(例如，基础设施节点，中间节点，特定应用节点)被托管。此外，本申请可以被实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)的M2M网络的一部分以访问服务。
图12C是示例M2M设备30(例如，UE111，UE112，UE221，UE222等)的系统图，诸如M2M终端设备18或者M2M网关设备14。如图12C所示，M2M设备30可以包括处理器32，收发器34，发送/接收元件36，扬声器/麦克风38，键盘40，显示器/触摸板42，不可移动存储器44，可移动存储器46，电源48，全球定位系统(GPS)芯片组50和其他外围设备52。应该理解，M2M设备30可以包括上述元件的任何子组合，而其余与实施例一致。此装置可以是使用所公开的用于跨层ACK，跨应用ACK或跨层跨应用ACK的系统和方法的装置。
处理器32可以是通用处理器，专用处理器，传统处理器，数字信号处理器(DSP)，多个微处理器，与DSP核心相关联的一个或多个微处理器，控制器，微控制器，专用整合电路(ASIC)，现场可编程门阵列(FPGA)电路，任何其他类型的整合电路(IC)，状态机等。处理器32可以执行信号编码，数据处理，功率控制，输入/输出处理，和/或使M2M设备30在无线环境中操作的任何其他功能。处理器32可以耦合到收发器34，收发器34可以耦合到发送/接收元件36。尽管图12C示出了处理器32和收发器34作为单独的组件，但是应当理解，处理器32和收发器34可以一起整合在电子封装或芯片上。处理器32可以执行应用层程序(例如，浏览器)和/或无线电访问层(RAN)程序和/或通信。处理器32可以执行安全操作，诸如认证，安全密钥协商，和/或加密操作，诸如访问层和/或应用层等。
发送/接收元件36可以被配置为向M2M服务平台22发送信号或从M2M服务平台22接收信号。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，例如WLAN，WPAN，蜂窝等。在实施例中，例如，发送/接收元件36可以是被配置为发送和/或接收IR，UV或可见光信号的发射器/探测器。在又实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。应该理解，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任意组合。
此外，虽然在图12C中发送/接收元件36被描绘为单个元件，但是M2M设备30可以包括任何数量的发送/接收元件36。更具体地，M2M设备30可以采用MIMO技术。因此，在实施例中，M2M设备30可以包括两个或更多个发送/接收元件36(例如，多个天线)，用于发送和接收无线信号。
收发器34可以被配置为对将通过发送/接收元件36发送的信号进行调制，并且对通过发送/接收元件36接收的信号进行解调。如上所述，M2M设备30可以具有多模能力。因此，例如，收发器34可以包括多个收发器，使M2M设备30能够通过多种RAT，诸如UTRA和IEEE802.11进行通信。
处理器32可以从任何类型的适当存储器访问信息并在任何类型的适当存储器中存储数据，诸如不可移动存储器44和/或可移动存储器46。不可移动存储器44可以包括随机存取存储器(RAM)，只读存储器(ROM)，硬盘，或任何其他类型的存储器存储设备。可移动存储器46可以包括订户身份模块(SIM)卡，记忆棒，安全数字(SD)存储卡等。在其他实施例中，处理器32可以从物理上没有位于M2M设备30上的存储器访问信息，并在该存储器中存储数据，诸如服务器或家用计算机。处理器32可以被配置为响应跨层ACK，跨应用ACK或跨层跨应用ACK的状态或配置在显示器或指示器42上控制照明图案，图像或色彩。在本文所述的实施例中，用户界面等可以允许配置或触发跨层ACK，跨应用ACK或跨层跨应用ACK。在一些实施例中，如本文所讨论，可以为跨层ACK，跨应用ACK或跨层跨应用ACK显示使用的能力，基于条件的拒绝，整合ACK帧中的应用ACK的数量或其他状态信息。状态信息可以包括关于程序吞吐量的信息，诸如与图6或图1B相关的程序等。
处理器32可以从电源48接收功率，并且可以被配置为向M2M设备30中的其他组件分配和/或控制功率。电源48可以是给M2M设备30供电的任何适当装置。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)，镍锌(NiZn)，镍金属氢化物(NiMH)，锂离子(Li离子)等)，太阳能电池，燃料电池等。
处理器32也可以耦合到GPS芯片组50，其被配置为提供提供关于M2M设备30的当前位置的位置信息(例如，经度和纬度)。应该理解，M2M设备30可以通过任何适当位置确定方法的方式获取位置信息，而其余与实施例一致。
处理器32还可以耦合到其他外围设备52，其可以包括提供附加特性，功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外围设备52可以包括加速计，电子罗盘，卫星收发器，传感器，数字相机(对照片或视频)，通用串行总线(USB)端口，振动装置，电视收发器，免提耳机，蓝牙模块，调频(FM)无线单元，数字音乐播放器，媒体播放器，视频游戏机模块，互联网浏览器等。
图12D是可以实现图12A和图12B的M2M服务平台22的示例性计算系统90的框图。计算系统90可以包括计算机或服务器，并且可以主要通过计算机可读指令控制，计算机可读指令可以以软件形式实现，可以在任何地方或通过任何手段对这种软件进行存储或访问。可以中央处理单元(CPU)91内执行这种计算机可读指令以使计算系统90进行工作。在许多已知的工作站，服务器和个人计算机中，通过被称为微处理器的单片CPU实现中央处理单元91。在其他机器上，中央处理单元91可以包括多个处理器。协处理器81是与主CPU91不同的可选处理器，执行附加功能或协助CPU91。CPU91和/或协处理器81可以接收，产生和处理与所公开的用于跨层ACK，跨应用ACK或跨层跨应用ACK的系统和方法相关的数据，诸如接收多层和多个应用的组合ACK。
在操作中，CPU91读取，解码和执行指令，并且通过计算机主数据传送路径，系统总线80向其他资源传送信息和从其他资源传输信息。这种系统总线在计算系统90中连接组件，并且定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线，用于发送地址的地址线和用于发送中断和用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围组件互连)总线。
耦合到系统总线80的存储器装置包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括电路，允许信息被存储和检索。ROM93通常包含不能很容易地修改的存储数据。存储在RAM82的数据可以由CPU91或其他硬件装置被读出或改变。对RAM82和/或ROM93的访问可以通过存储器控制器92来控制。存储器控制器92可以提供地址转换功能，指令执行随着将虚拟地址转换到物理地址。存储器控制器92还可以提供存储器保护功能，隔离系统内的处理并隔离系统处理与用户处理。因此，在第一模式下运行的程序只能访问通过其自身的处理虚拟地址空间映射的存储器，而不能访问另一处理的虚拟地址空间内的存储器，除非已经建立处理之间共享存储器。
此外，计算系统90可以包含外围设备控制器83，负责将指令通信到外围设备，诸如打印机94、键盘84、鼠标95和磁盘驱动器85。
由显示器控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本，图形，动画图形和视频。可以使用基于CRT的视频显示器，基于LCD的平板显示器，基于等离子体的平板显示器实现显示器86。显示器控制器96包括生成发送到显示器86的视频信号所需的电子组件。
此外，计算系统90可以包含网络适配器97，可用于将计算系统90连接到外部通信网络，诸如图12A和图12B的网络12。
应当理解，本文描述的系统，方法和处理的任何或全部可以以计算机可读存储介质上存储的计算机可执行指令(即，程序代码)的形式体现，当机器(诸如计算机，服务器，M2M终端设备，M2M网关设备等)执行指令时，执行和/或实现本文描述的系统，方法和处理。具体地，以上描述的任何步骤，操作或功能可以以这种计算机可执行指令的形式来实现。计算机可读存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性，可移动和不可移动介质，但这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于，RAM，ROM，EEPROM，闪存或其他存储器技术，CD-ROM，数字多功能盘(DVD)或其他光盘存储，磁带盒，磁带，磁盘存储或其他磁存储设备，或可以用于存储期望的信息并可由计算机访问的任何其他物理介质。
在描述本公开内容的主题的优选实施例中，如附图所示，为了简明，采用特定术语。然而，所要求的主题并非意在限制到如此选择的特定术语，但是应当理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等效物。
本书面描述使用示例来公开本发明，包括最佳模式，并且还使任何本领域技术人员能够实践本发明，包括制造和使用任何装置或系统，以及执行任何结合的方法。本发明的专利范围由权利要求限定，并且可以包括对本领域技术人员出现的其他示例。如果它们具有不与权利要求的字面语言不同的结构元件，或者如果它们包括与权利要求的字面语言无实质区别的等同结构元件，则这些其他示例旨在落入权利要求的范围内。

Claims (20)

1.一种设备，包括：
处理器；以及
与所述处理器可通信地连接的存储器，所述存储器存储有可执行指令，当所述处理器执行所述可执行指令时，使得所述处理器执行操作，所述操作包括：
接收第一帧，所述第一帧包括第一媒体访问控制数据和第一应用数据；以及
提供用于发送整合的ACK帧的指令，所述整合的ACK帧包括所述第一媒体访问控制数据的确认和所述第一应用数据的确认。
2.如权利要求1所述的设备，其中，在等待用于所述应用数据的确认的提供性的阈值时段之后，发送所述整合的ACK帧。
3.如权利要求1所述的设备，其中，所述应用驻留在传输层、服务层、应用协议层或应用层中的至少一个中。
4.如权利要求1所述的设备，其中，所述整合的ACK帧进一步包括第二媒体访问控制数据和第二应用数据，在第二帧中接收所述第二媒体访问控制数据和所述第二应用数据。
5.如权利要求1所述的设备，其中，所述第一帧包括指示向所述设备提供用于发送整合的ACK帧的指令的比特。
6.如权利要求1所述的设备，其中，所述整合的ACK帧包括指示在所述整合的ACK帧内的应用ACK的数目的比特。
7.一种设备，包括：
处理器；以及
与所述处理器可通信地连接的存储器，所述存储器存储有可执行指令，当所述处理器执行所述可执行指令时，使得所述处理器执行操作，所述操作包括：
发送第一帧，所述第一帧包括第一媒体访问控制数据和第一应用数据；以及
接收整合的ACK帧，所述整合的ACK帧包括所述第一媒体访问控制数据的确认和所述第一应用数据的确认。
8.如权利要求7所述的设备，其他操作包括：对所述第一帧设置指示在所述整合的ACK帧中允许多个确认的比特，所允许的多个确认包括所述第一应用数据的确认和包括下述中的至少一个的确认：
所述第一媒体访问控制数据的确认，
第二媒体访问控制数据的确认，和
第二应用数据的确认。
9.如权利要求7所述的设备，其他操作包括：确定所述整合的ACK具有设置的比特，所述比特指示在所述整合的ACK帧中使用跨层ACK或跨应用ACK。
10.如权利要求9所述的设备，其他操作包括：通过所述设备的MAC层向高层转发所述第一应用数据的确认，其中，所述转发基于相关联的应用标识符。
11.如权利要求7所述的设备，其中，所述整合的ACK帧进一步包括第二应用数据的确认，所述第二应用数据的确认来自与所述第一应用数据不同的应用。
12.如权利要求7所述的设备，其中，所述第一帧包括指示在所述整合的ACK帧中允许的应用ACK的最大数目的比特。
13.如权利要求7所述的设备，其中，所述设备是中继器。
14.如权利要求7所述的设备，其中，在与所述设备的无线接近通信中，向接收方设备发送所述第一帧。
15.如权利要求14所述的设备，其中，所述接收方设备在距所述设备的一跳内。
16.一种设备，包括：
处理器；以及
与所述处理器可通信地连接的存储器，所述存储器存储有可执行指令，当所述处理器执行所述可执行指令时，使得所述处理器执行操作，所述操作包括：
经由无线通信向对等体设备发送第一帧，所述第一帧包括第一应用数据；
经由无线通信向所述对等体设备发送第二帧，所述第二帧包括第二应用数据；以及
接收整合的ACK帧，所述整合的ACK帧包括所述第一应用数据的确认和所述第二应用数据的确认。
17.如权利要求16所述的设备，进一步包括：提供用于在用户界面上显示所述整合的ACK的状态的指示的指令。
18.如权利要求17所述的设备，其中，所述整合的ACK的状态包括在所述整合的ACK内的应用确认的数量。
19.如权利要求17所述的设备，其中，所述整合的ACK的状态包括所述整合的ACK内的确认是否与同一应用相关联的指示。
20.如权利要求16所述的设备，其中，所述第二应用数据来自与所述第一应用数据不同的应用。
CN201480041387.3A 2013-06-21 2014-06-20 用于数据传输的跨层和跨应用确认 Active CN105794135B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361837746P 2013-06-21 2013-06-21
US61/837,746 2013-06-21
PCT/US2014/043460 WO2014205377A1 (en) 2013-06-21 2014-06-20 Cross-layer and cross-application acknowledgment for data transmission

Publications (2)

Publication Number Publication Date
CN105794135A true CN105794135A (zh) 2016-07-20
CN105794135B CN105794135B (zh) 2019-04-19

Family

ID=51211330

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480041387.3A Active CN105794135B (zh) 2013-06-21 2014-06-20 用于数据传输的跨层和跨应用确认

Country Status (6)

Country Link
US (3) US9496989B2 (zh)
EP (1) EP3011698B1 (zh)
JP (2) JP6259514B2 (zh)
KR (2) KR101838412B1 (zh)
CN (1) CN105794135B (zh)
WO (1) WO2014205377A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109792441B (zh) * 2016-10-13 2022-01-14 霍尼韦尔国际公司 跨安全层安全通信
CN115866109A (zh) * 2022-11-30 2023-03-28 长城信息股份有限公司 一种远程设备原生驱动控制方法及装置

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9496989B2 (en) * 2013-06-21 2016-11-15 Convida Wireless, Llc Cross-layer and cross-application acknowledgment for data transmission
DK3047696T3 (da) * 2013-09-18 2020-08-03 Ericsson Telefon Ab L M Indretning-til-indretning-kommunikation mellem trådløse kommunikationsindretninger under anvendelse af gruppe-ID og applikations-ID
US11088807B2 (en) * 2014-05-30 2021-08-10 Apple Inc. Application-level acknowledgements
CN112491733B (zh) * 2014-05-30 2024-08-02 索尼公司 用户设备侧和网络侧的电子设备以及方法
WO2016007057A1 (en) * 2014-07-10 2016-01-14 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for signalling in a communication network
CN104968037B (zh) * 2015-05-29 2018-07-06 乐鑫信息科技（上海）有限公司 基于代理设备的低功耗物联网实现方法
CN106550316B (zh) * 2015-09-21 2020-03-31 海能达通信股份有限公司 在直通模式dmo通信中的单呼方法及终端
KR101869154B1 (ko) * 2016-07-25 2018-06-19 이화여자대학교 산학협력단 복수의 스마트 기기에 대한 CoAP 메시지 기반의 비콘 서비스 제공 방법
US10862971B2 (en) 2018-04-27 2020-12-08 EMC IP Holding Company LLC Internet of things gateway service for a cloud foundry platform
US10715640B2 (en) * 2018-07-13 2020-07-14 EMC IP Holding Company LLC Internet of things gateways of moving networks
US11343281B2 (en) 2019-08-16 2022-05-24 Cisco Technology, Inc. Enhanced web application security communication protocol
CN116615873A (zh) * 2020-12-31 2023-08-18 联想(北京)有限公司 使用一个或多个中继器中继信息
US11902406B2 (en) * 2022-01-12 2024-02-13 Nxp B.V. Data communication using Constrained Application Protocol over local area network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102186207A (zh) * 2011-04-06 2011-09-14 重庆大学 一种无线局域网络下跨层减少tcp重复应答方法
US20120218949A1 (en) * 2011-02-24 2012-08-30 Snu R&Db Foundation Data transmission method using ack transmission opportunity in wireless network
US20130155938A1 (en) * 2011-12-16 2013-06-20 Belair Networks Tcp-relay for wireless applications

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5836866B2 (ja) * 1978-04-28 1983-08-12 日本電気株式会社 応答制御方式
JP3266199B2 (ja) * 1999-12-22 2002-03-18 日本電気株式会社 信頼性あるデータ転送方法
JP4561630B2 (ja) * 2003-02-03 2010-10-13 ソニー株式会社 通信方法及び通信装置、並びにコンピュータプログラム
US20060136614A1 (en) 2004-07-30 2006-06-22 Nokia Corporation System and method for variable length aggregate acknowledgements in a shared resource network
US20060034274A1 (en) * 2004-07-30 2006-02-16 Nokia Corporation System and method for variable length acknowledgements in a shared resource network
US7606213B2 (en) * 2004-08-12 2009-10-20 Qualcomm Incorporated Wireless MAC layer throughput improvements
EP1959693A1 (en) * 2007-02-19 2008-08-20 Siemens Networks S.p.A. Cross-layer error recovery optimisation in wireless systems
JP2008300936A (ja) * 2007-05-29 2008-12-11 Nec Access Technica Ltd 通信システム、通信システムに用いられる端末装置、及び、通信システムの通信方法
KR101671804B1 (ko) * 2008-04-25 2016-11-16 인텔렉추얼디스커버리 주식회사 Ｔｃｐ ａｃｋ 패킷 전송 및 수신 방법과, 이를 지원하는 장치
JP2009273094A (ja) * 2008-05-12 2009-11-19 Nec Corp データ通信システム、データ通信端末、データ通信方法、およびプログラム
CN101631065B (zh) * 2008-07-16 2012-04-18 华为技术有限公司 一种无线多跳网络拥塞的控制方法和装置
US8553645B2 (en) 2009-07-31 2013-10-08 Motorola Mobility Llc Method and apparatus for service continuity on a mobile communication device
US8717900B2 (en) * 2011-02-07 2014-05-06 LivQoS Inc. Mechanisms to improve the transmission control protocol performance in wireless networks
US20130230059A1 (en) * 2011-09-02 2013-09-05 Qualcomm Incorporated Fragmentation for long packets in a low-speed wireless network
US20140056223A1 (en) * 2011-09-02 2014-02-27 Qualcomm Incorporated Fragmentation for long packets in a low-speed wireless network
US9100177B2 (en) * 2011-09-02 2015-08-04 Qualcomm Incorporated Systems and methods for acknowledging communications from a plurality of devices
US9549371B2 (en) * 2013-03-14 2017-01-17 Qualcomm Incorporated Access point proxy and multi-hop wireless communication
US9496989B2 (en) * 2013-06-21 2016-11-15 Convida Wireless, Llc Cross-layer and cross-application acknowledgment for data transmission

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120218949A1 (en) * 2011-02-24 2012-08-30 Snu R&Db Foundation Data transmission method using ack transmission opportunity in wireless network
CN102186207A (zh) * 2011-04-06 2011-09-14 重庆大学 一种无线局域网络下跨层减少tcp重复应答方法
US20130155938A1 (en) * 2011-12-16 2013-06-20 Belair Networks Tcp-relay for wireless applications

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JIHYUN LEE: "Cross-layer Design for Fast TCP ACK-Clocking over WiMedia UWB Networks", 《CONSUMER ELECTRONICS, 2008. ICCE 2008. DIGEST OF TECHNICAL PAPERS》 *
M. YABANDEH: "E2E-PACK: A Cross-Layer Design for Multipath Routing over Mobile Ad Hoc Networks", 《COMMUNICATION SYSTEMS SOFTWARE AND MIDDLEWARE》 *
QIAN WANG: "Improving TCP Performance Using Cross-Layer Feedback in Wireless LANs", 《WIRELESS COMMUNICATIONS NETWORKING AND MOBILE COMPUTING (WICOM)》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109792441B (zh) * 2016-10-13 2022-01-14 霍尼韦尔国际公司 跨安全层安全通信
CN115866109A (zh) * 2022-11-30 2023-03-28 长城信息股份有限公司 一种远程设备原生驱动控制方法及装置

Also Published As

Publication number Publication date
US9496989B2 (en) 2016-11-15
EP3011698A1 (en) 2016-04-27
EP3011698B1 (en) 2020-06-17
KR20160020573A (ko) 2016-02-23
JP6259514B2 (ja) 2018-01-10
KR20180028549A (ko) 2018-03-16
US10425194B2 (en) 2019-09-24
US20170063499A1 (en) 2017-03-02
CN105794135B (zh) 2019-04-19
JP2016526831A (ja) 2016-09-05
US20140376521A1 (en) 2014-12-25
WO2014205377A1 (en) 2014-12-24
KR101838412B1 (ko) 2018-03-13
JP2018078589A (ja) 2018-05-17
US9979511B2 (en) 2018-05-22
US20180262301A1 (en) 2018-09-13

Similar Documents

Publication Publication Date Title
US10425194B2 (en) Cross-layer and cross-application acknowledgment for data transmission
JP6480553B2 (ja) 近接サービスのためのコンテキストおよび電力制御情報管理
CN106170969B (zh) 上下文管理
EP3100471B1 (en) Context-aware and proximity-aware service layer connectivity management
JP2018196139A (ja) サービス層サウスバウンドインターフェースおよびサービスの質
CN111314892B (zh) 与基站通信的装置、方法和计算机可读介质
WO2017040948A1 (en) Enabling time flexibility for block transfer in coap protocol

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20221107

Address after: Wilmington, Delaware, USA

Patentee after: INTERDIGITAL PATENT HOLDINGS, Inc.

Address before: Delaware

Patentee before: CONVIDA WIRELESS, LLC

TR01 Transfer of patent right