数据传输的制作方法

专利名称：数据传输的制作方法
技术领域：
本发明涉及数据传输。特别是、但不仅仅涉及将数据传输给移动终端和从那里将数据传输出来。可以利用互连网获得所述数据。
随着蜂窝式移动终端应用的日益增长，对经由无线链路发送和接收数据的这种终端的需求也在增长。为此，可以使用与蜂窝式电话连接的、或或集成式计算机/蜂窝电话设备构成的便携式计算机。浏览互连网就是这种数据传输的一个例子。
术语“互连网”通常用于说明可以使用终端访问的信息，使用的终端通常是通过调制解调器与通信网络连接地PC机。虽然每一个远程站点也与电信网络连接，但是，其内容可以存放在许多远离访问的计算机的不同站点上。所述内容可以使用超文本标记语言(HTML)构成。互连网可以按照标准通信系统的规范工作，它使用多个协议，诸如传输控制协议(TCP)、用户数据报文协议(UDP)、以及因特网协议(IP)控制互连网许多不同部件周围的数据流。TCP和UDP涉及利用不同服务质量特性的互连网数据传输，诸如正常的可靠的数据传输、或者不可靠的独立数据分组传输。IP涉及数据的结构和路由选择。在其上部，可以提供其它专用协议、以便管理和处理可以通过互连网获得的各种类型的信息，例如，访问HTML内容的HTTP、访问文件的FTP或访问e-mail的SMTP。
互连网在物力上由远程通信和数据通信网络的分层结构、例如、局域网(LAN)、区域电话网以及国际电话网构成。这些网络通过所谓的“路由器”在内部和外部连接，所述路由器接收来自源主机或传输链中的先前路由器的数据，并且将它们按规定路由发送给目的主机、或者传输链中的下一个路由器。
要访问互连网，通常涉及终端、例如、移动终端和服务器之间的对话。对话是终端和服务器之间一系列交互活动，这种活动具有完全确定的开始和结束，并且包括一致的特性。一般地说，对话涉及一个同位体对另一个同位体建立对话所需的广播、两个同位体协商对话特征、各同位体执行各种事务以及两个同位体之一结束对话。一般地说，协商的特征是交换分组的长度、可以理解和操作的字符集以及使用的协议版本。
由于多媒体和其它无线服务需求的增加，使用的无线带宽也在增加，因此，要求能够提供大量数据的无线传输的需求也在增长。
为了提供与移动终端的标准化通信，人们提出了一种无线应用协议(WAP)。这是一套全行业规范，适用于开发无线通信网络的应用和服务。WAP规定了无线通信设备、例如移动电话、寻呼电话接收机和个人数字助理(PDA)的应用框架和网络协议。WAP可实用于各种不同系统，包括GSM-900、GSM-1800、GSM-1900、CDMA IS-95、TDMA IS-136、宽带IS-95以及第三代系统，例如，IMT-2000、UMTS和W-CDMA。
WAP的体系结构是以以下部分和层次为基础的
应用层(称为无线应用环境或WAE)是通用目的的应用环境。其目的就是提供一种相互联系的环境，后者允许操作人员和服务提供商为各种无线平台提供应用和服务。
对话层(称为无线对话协议或WSP)为两种对话服务提供具有相同接口的应用层。第一种服务是面向连接的服务，它是在事务层协议WTP上执行的(见下文)。第二种服务是一种无连接服务，它是在安全的或非安全的数据报文服务WDP上执行的(见下文)。
事务处理层(称为无线事务处理协议或WTP)是在数据报文服务上面运行，它提供一种简便的面向事务的协议，所述协议适用于在“瘦”客户机、例如、移动终端上实现。WTP经由安全的或非安全的无线数据报文网络运行并且提供以下特征
三类事务请求
类0是不可靠的单向请求；
类1是可靠的单向请求；以及
类2是可靠的双向请求-回答事务。
任选的用户到用户的可靠性，其中WTP用户激发对接收的每一个报文的确认，
根据确认的任选的带外数据，
协议数据单元(PDU)的级联和延迟确认、用以压缩发送的报文数量，
异步事务。
安全层(称为无线传输层的安全性或WTLS)。所述层是以工业标准的传输层安全性(TLS)协议为基础的。它最适合在窄带通信信道上应用。它包括数据完整性、保密、验证及拒绝服务保护。应用能够根据它们对网络的要求和基础网络的特性，选择允许或禁止WTLS特征。
传输层(称为无线数据报文协议或WDP)。WDP层是在由不同网络类型支持的数据容量承载业务上运行。正如一般传输服务那样，WDP为WAP的高层协议提供统一的服务，并经由可用的承载业务之一进行透明的通信。
所述各层以协议栈的形式设置，同时，所述体系结构的每一层可由其上面的各层以及其它服务和应用访问。这些协议设计成在各种不同的承载业务上运行。所述结构和各协议层的详细说明可从网址http//www.wapforum.org/上得到。
WAP是以事务为基础的。大多数事务要么是推入式的要么是拉出(请求-应答)式的。在推入式事务中，同位体发送的信息是还没有明确请求的信息，而在拉出式事务中，同位体明确请求接收另一个同位体的信息。拉出式事务可以采取在客户(发送者)和服务器(接收者)之间调用WAP事务形式。这样的事务包括客户发送请求(调用)给服务器和所述服务器返回的响应(结果)，包括请求需要的数据。客户机和服务器两者都有WAP协议栈，并且请求和响应都借助于在每一个栈的各层之间调用的服务原语来进行，使得协议数据单元形式的报文经由适当的荷载层在客户机和服务器之间流动。服务原语表示信息的逻辑变化，用它可以实现在协议层和另一个实体之间的控制，例如，对话层和应用环境(WAE)之间的控制。它们由命令和它们各自的与提供的具体服务相关连的响应组成。在通信链路一侧的同位体中调用服务原语将在链路的另一侧的同位体中产生一个事件。
在本说明书中，术语报文用来既指服务原语又指PDU。报文是出现在服务原语请求中的服务数据单元(SDU)的逻辑抽象，使得它象服务原语表示中的SDU一样出现在同位体一侧。在目前情况下，SDU是服务原语中的用户数据域。
如果任何报文的长度超过了承载服务的最大传输单位(MTU)尺寸，即，由具体承载服务规定的单个分组的最大尺寸，那么，在报文发送之前，它就被分割成WTP层中的分组序列。分组以单个或组的形式传输，然后，一旦它们被接收到就重新组装。这个过程称作为分割和重组(SAR)。SAR将一些连续的序列号分配给被分割的数据分组，使得它们的顺序可以在重组时重新建立。在WAP中，分割后的报文的最大尺寸为256个分组。由于每一个分组具有1至2KB(一般为1.5KB)的最大尺寸，所以报文的最大尺寸一般小于0.5MB。
当通过WTP接收数据分组并将其重组时，重组的报文被传输给WTP的用户、即WSP或直接在WTP上的应用。然而，由于一旦被分割的所有报文分组都到达时WTP只将重组的报文提供给高层，这就意味着，发送者和接收者不得不使用等于最大报文尺寸的数据缓冲区。
数据传输单元是PDU。PDU包括八进制整数，并且由头(包括固定部分和变化部分)和数据组成(如果存在数据的话)。固定部分包括为达到一致和满意的通信所需要的信息。只需要与固定部分连接的变化部分包括并非绝对必要的任选信息。头的固定部分包括经常使用的参数和标识特定PDU的代码。固定部分的长度和结构由PDU代码定义。通常使用的PDU包括Invoke(调用)、Result(结果)、Acknowledgr(确认)和Abort(异常中断)。通常在WAP中使用的PDU代码是在无线事务处理协议规格说明中定义的。
PDU头部固定部分的参数包括
连续标记(CON)，它表示在变化部分中出现任何传输信息项(TPI)。
组尾(GTR)标记，它表示传输组的最后分组(GTR分组)。
传输尾(TTR)标记，它表示被分割报文的最后分组(TTR分组)。
分组序列编号(PSN)，它用于给被分割的报文和数据分组编号。它表示有序的数据流里数据分组的位置。所述参数的长度为8比特。
重发指示符(RID)，它使接收器能够区分网络复制的分组和发送者重发的分组。
事务标识符(TID)，它用于将分组与特定事务相联系。
事务类(TCL)，它表示调用报文中所需要的事务类。它由始发端选择。
当始发端已经“环绕”TID值、即、当各TID值的范围已经全面增值时设置TID新标记，使得下一个TID值重新在其范围的低端开始，因而比前一个TID值低。
当设置U/P标志时，该U/P标志表示始发端要求服务器的WTP用户发送用户确认。这种确认将使WTP的用户证实每一个接收到的报文。
丢失分组编号参数，它表示在接收当前组期间丢失的分组编号。如果所述参数值为0，所述组的所有分组都被丢失，否则，在所述参数后，将列出丢失的分组的分组编号。
丢失分组的参数PSN(s)，它是一个请求其重发的丢失分组的分组顺序编号的列表。
PDU头的变化部分用于定义并非经常使用的参数。变化参数被装入传输信息项(TPI)中。这些可以用于许多目的，例如，表示同位体的最大组尺寸和组延迟。
终端和服务器的各数据缓冲区必须大到足以存放发送的数据。在WAP标准中，在事务内由发送者向接收者发送一个报文。如果数据在单个块中，例如，100KB长的报文，则接收者需要100KB的数据缓冲区存放整个报文。然而，某些报文不需要存放，因此，所述报文不需要数据缓冲区。这就是视频电话的数据流情况；由于它能够直接发送给用于显示的视频显示器，因此，它不需要存储。
TCP用于在有线网络中发送大数据量的数据。然而，它并不特别适用于无线网络。它需要具有往返程的连接安装。它启动事务缓慢。在分组丢失的情况下(这常常出现在无线环境中)，它具有累积确认功能。由于它们产生太多的数据业务量，所以这些累积确认是不希望有的。在有线网络中，如果分组丢失，通常是由路由器拥挤产生的。为了解决这一问题，发送者的数据传输速率要压缩，因此，要花费更多的数据传输时间。在无线网络中，分组的丢失是普遍的，并且可能是由与拥挤无关的几个因子，例如，无线链路引起的信元转移或错误引起的。因此，分组丢失未必提供压缩传输速率的理由。
根据本发明的第一方面，提供一种经由发送者和接收者之间的链路实现事务处理、以便以多数据报文方式传输数据的方法，每一个报文至少包括一个数据分组，
所述方法包括以下步骤
接收者确认接收到数据分组，以便提供可靠的连接；
发送者将每一个数据报文的最后的数据分组通知接收者；并且发送者将最后的数据报文通知接收者。
当然，在据说接收者确认接收到数据分组的地方，在某些情况下，实际上可能并没有接收到数据分组。在这样的情况下，接收者可能要通知发送者，有一个或几个分组没有接收到。
所述链路最好是无线链路。
最好不要预先确定报文的长度。在这个意义上，“预先确定”意味着在接收之前，接收者知道有多少报文或有多少分组可能要接收。在本发明的一个实施例中，数据可能仅包括一个报文。
在这里，“可靠的”意味着被确认，使得发送者知道所述报文已被接收者接收。通过提供可靠的数据分组序列，数据报文的传输就具有数据流的特性。由于各个分组被可靠地接收，因而，就不需要提供大的缓冲区来存放任意长度的整个报文。在视频会议传输的情况下，这可能是一个巨大的数据量，并且因此将需要巨大的缓冲区。
在一个实施例中，本发明应用许多WAP标准特性和体系结构，并且即使它扩展了对话的数据量，也与WAP反向兼容。本发明为大数据量的传输提供了比按各个事务顺序传输更为有效的传输。它使象数据流一样任意长度的报文序列能够在事务内传输。
本发明最好在WAP标准内应用。它可能形成新事务类的基础，所述新事务类具有一个可靠的调用报文和一个可靠的结果报文。引用报文和结果报文都能有条件地利用可靠的数据报文扩展，从而保证大数据量的传输。
在那里，最好在任何时候都能有几个尚未认可的事务。最好能有几个存在于单个对话中的异步事务。
最好以分组的组的形式发送各个分组。当来自组里的所有分组都被接收时，接收者就可以确认一个完整的组。接收者可能通过以下方法来确认完整的组当证实所述组的其它分组都被接收时，接收者确认一个组的最后分组。这样，通过确认所述组而隐含地确认除所述最后分组以外的其他分组。
在数据报文传输期间，最好将各数据分组连续编号。可以使用诸如SAR那样的分割和重组技术。然而，可以不使用分割。数据分组序列最好由PSN排序。这还可能使丢失的分组能够被识别。可以借助具有环绕的PSN来提供任意长的数据报文。
在所述事务中，发送者和接收者之间的通信最好是双向的。可以有两个信道，只要一个用于把数据从始发端发送到应答器、而另一个用于在相反方向上发送数据。通过提供两个信道，本发明提供全双工可靠的事务服务。最好通过发送最后一个数据报文来关闭每一个信道。一个WSP对话可以包括几个这种类型的事务。本发明考虑到交互式通信。
可以通过调用命令开始事务处理。一旦开始，它就可以通过流式数据命令继续。根据本发明，数据报文可以或者通过始发端或者通过事务应答器发送。最好在发送者发送DataEnd TPI并且该信号被接收者接收时终止经由一个信道的数据传输。如果经由两个信道的传输被终止，则事务可能也被终止。
根据本发明的第二方面，提供了一种用于以多数据报文的形式发送数据的移动终端，其中每一个数据报文至少包括一个数据分组，所述移动终端包括包含在存储器中的应用程序和协议栈，所述应用程序和所述协议栈经由无线链路在发送者和接收者之间进行事务处理，其中，发送者按顺序将报文发送给接收者、接收者确认接收到所述分组、以便提供一种可靠的连接，发送者将每一个数据报文的最后数据分组通知接收者，并且发送者将最后的数据报文通知接收者。
根据本发明的第三方面，提供一种用于以多数据报文形式发送数据的网关，每一个数据报文至少包括一个数据分组，所述网关包括包含在存储器中的应用程序和协议栈，所述应用程序和所述协议栈经由无线链路、在发送者和接收者之间进行事务处理，其中，发送者将报文按顺序发送给接收者、接收者确认接收到所述各分组、以便提供一种可靠的连接，发送者将每一个数据报文的最后数据分组通知接收者，并且发送者将最后的数据报文通知接收者。
根据本发明的第四方面，提供了一种数据传输系统，所述系统包括用于接收多数据报文形式的数据的多个移动终端，每一个移动终端包括包含在存储器中的应用程序和协议栈，所述应用程序和所述协议栈经由无线链路与网关一起进行事务处理，其中，网关按顺序将报文发送给移动终端、移动终端确认接收到所述各分组、以便提供一种可靠的连接，网关将每一个数据报文的最后数据分组通知移动终端，并且网关将最后的数据报文通知移动终端。
根据本发明的第五方面，提供了一种数据传输系统，所述系统包括用于传输多数据报文形式的数据的多个移动终端，每一个移动终端包括包含在存储器中的应用程序和协议栈，所述应用程序和所述协议栈经由无线链路与所述网关一起进行事务处理，其中，移动终端按顺序将报文发送给网关、网关确认接收到所述各分组、以便提供一种可靠的连接，移动终端将每一个数据报文的最后数据分组通知网关，并且移动终端将最后的数据报文通知网关。
根据本发明的第六方面，提供存储在计算机可读媒体中的计算机程序产品，所述计算机程序产品包括
用于使计算机经由无线链路、在发送者和接收者之间进行事务处理的计算机可读程序方法，所述事务处理包括传输包含多个数据报文的数据；
用于使发送者将所述报文按顺序发送给接收者的计算机可读程序方法；
用于使接收者确认接收到所述各分组、以便提供可靠的连接的计算机可读程序方法；
用于使发送者将每一个数据报文的最后数据分组通知接收者的计算机可读程序方法；以及
用于使发送者将最后的数据报文通知接收者的计算机可读程序方法。
根据本发明的第七方面，提供一种经由发送者和接收者之间的链路进行事务处理、以便以多个数据分组形式发送没有预定长度的数据的方法，所述方法包括以下步骤
将分组顺序编号加到各个分组，所述分组顺序编号具有这样的范围从由第一个分组顺序编号确定的第一端点到由最后的分组顺序编号确定的第二端点；
当达到其范围的端点之一时，对分组顺序编号进行环绕式处理。
虽然每一个分组的顺序编号最好是连续的，但是，它可以从一个分组到下一个分组递增或递减。它可以以一为步长从一个分组到下一个分组变化，或者它可以以除一以外的步长、例如以二或其它整数为步长变化。
现在参照附图仅以举例的方式说明本发明的实施例，附图中
图l示出使用分割的事务处理；
图2示出报文的结构；
图3示出不使用分割的事务处理；
图4示出图3事务处理的另一个视图5示出有效服务原语顺序表；
图6示出一个通信系统；
图7示出一个网关；
图8示出一个移动终端；
图9以不同形式示出根据图6的系统。
在一个实施例中，本发明提供WAP标准的新事务类，它使得能够传输任意长度的数据。所述新类是类3。这样的数据可能是视频会议的数据流，它可能是多媒体数据流或者可能是下载的软件。
现在将说明类3的事务处理。在类3的事务处理期间使用了以下服务原语
TR-Stream Invoke；
TR-Stream Result；
TR-Stream Invoke Data；
TR-Stream Result Data；以及
TR-Abort
前缀TR-表示在协议栈中各层之间使用的服务原语。前缀S-表示在对话层(例如，WSP)中使用的服务原语。
在以下说明中，服务原语描述或者从高本地层或者从低本地层对WTP的请求。这导致产生一个PDU，后者是编码分组(包含头和数据)，并在事务处理期间通过网络发送。


图1示出其中发送数据的类3事务处理的一部分。所述事务处理由一个称之为始发端的通信实体与另一个称之为应答器的通信实体一起启动。始发端和应答器经由两个信道上通信，根据数据流动方向，每个信道具有发送者和接收者。存在输入信道和输出信道输入信道由始发端建立、用于其数据流，而输出信道由应答器建立、用于其数据流。由于存在两个信道，始发端和应答器的每一个都要起数据的发送者和接收者的作用。术语“信道”指的是用于在一个方向上发送有序报文序列的流式数据路径。所述术语指的不是物理实体，而是指提供所述结果的逻辑运算。
WTP的用户可以或者是WSP、或者是经由连接直接与WTP通信的应用程序。在前者情况下，每一个事务处理都是在对话的范围内完成的。在后者情况下，WSP和WSP用户简单地处在相同的四地址(address quadruplet)上。
图1只显示经由输入信道从始发端(发送者)向应答器(接收者)发送的报文。在输出信道发送的报文，具体地说由应答器反向发送给始发端的数据结果没有示出。在任何一个信道中，数据的确认以与数据相反的方向流动。
在详细说明图1的事务处理前，将用简单术语说明，为的是图解说明它是如何进行的。在输入信道上发送一个Stream Invoke报文。应答器在输出信道上以一个Stream Result报文响应。因此，两个报文后面可能都有附加的流式数据(Stream Data)报文，这被认为是原始报文的继续，并携带有附加的数据。向附加数据报文中的分组提供连续的PSN、以便在接收数据报文后，数据报文的接收者能够正确地安排所述数据报文。事务处理中的任何一个通道可以被End-Of-Data报文中断。如果始发端和应答器接收End-Of-Data报文，则事务处理被中断。所有报文都要被确认。报文可以包括单个分组，或者可以分割为多个分组。
类3中使用的PDU具有以下代码
本发明PDU的固定头结构格式与WAP标准使用的相同。下面说明PDU的应用和操作。
在事务处理期间，在每一个始发端和应答器的WAP协议栈中的供应商层和用户层之间调用服务原语。可以由服务原语调用的特定参数从下面选择
源地址。这是向WTP层提出请求的设备的唯一地址。它可以是MSISDN编号、IP地址、x.25地址或其它标识符。
源端口编号。它与源地址相关联。
目标地址。这是提供给WTP层的用户数据的地址。目标地址可以是MSISDN编号、IP地址、x.25地址或其它标识符。
目标端口编号。它与关于所请求的或现有事务处理的目标地址相关联。
用户数据。它由被调用的源语产生的报文携带。提供给WTP层或从WTP层接收数据单元，即SDU。这是较高层提供给WTP层用于传输的完整的数据单元(报文)。WTP层发送数据报SDU，并且不对其内容做任何处理，将它传递给它的目标。
End-Of-Data。它用于表示特定的SDU携带用户数据的最后部分，这部分数据将发送给事务处理中的应答器。
事务处理。这是返回给较高层的一个索引，以便它能够区分事务处理和接收的与有效事务处理相联系的数据。所述事务处理唯一地识别事务。它是事务的源地址、源端口、目标地址和目标端口的别名。所述事务处理仅具有局部意义。
Exit info。发送给报文序列始发端的有关其完整性的附加用户数据。这仅仅出现在TR-Stream-Result和TR-Stream-Result-Data服务原语中。
现在回到图1，将根据出现在始发端和应答器的协议栈中以及在它们之间传送的PDU中的服务原语的序列说明事务处理。通过WTP层上面的层(称作为WTP用户(始发端))、例如WAE或WSP、在WTP层(称作为WTP提供者(始发端))中调用TR-Stream Invoke请求服务原语，来启动新类3事务。当新的事务被调用时，始发端将事务标识符(TID)加一、以便表示它是一个新事务。在特定的类3事务中，所有报文(包括所有PDU)都携带相同的TID。
调用TR-Stream Invoke的请求服务原语要调用WTP提供者(始发端)中的参数，这些参数是设置事务所需要。用户数据也包括其中。包括在TR-Stream Invoke服务原语中的参数在下表中列出
在所述表及后面的表中，图表符号M、O和C有以下含义
M表示参数是强制性的且必须存在；
O表示参数是任选的并且可以忽略；以及
C表示参数是有条件的，它取决于其它参数值。
Stream Invoke的服务原语接收调用的PDU的头，然后，WTP提供者(始发端)发送带有隐含分组编号为0的Invoke PDU。所述调用的PDU总是所述事务的第一个报文。它包括TCL参数。下面给出可使用的事务类
在这种情况下，PDU的头表示所述事务属于类3。首先发送PDU，清除报头的重发标志(RID)字段。应当指出，象类0、1和2的TCL一样，识别类3事务的TCL只需要两个比特，因而与WAP标准反向兼容。如果应答器不支持类3事务，则应答器将终止所述事务。
当接收调用的PDU时，WTP提供者(应答器)检查TID，并确定是否必须启动检验。如果必须启动，则WTP提供者(应答器)开始TID的检验过程。如果不必启动，则它将报文传递给WTP用户(应答器)。在类3事务的TID检验过程中使用证实PDU(AcknowledgementPDU)、确认PDU(Ack PDU)。
现在，参照图2中示出的实例说明报文的结构。如果Stream Invoke报文大小超过了网络的MTU，那么，所述报文被分割成有序的分组序列。在本例中，存在PSN值为0的流调用分组，第一组分组具有1至16的PSN值，第二组分组具有17至33的PSN值。在开始传输报文时，清除始发端中调用服务原语中的End-Of-Data标记，表示还有数据分组待发送。如果End-Of-Data标记没有被清除，这就表示没有其他SDU要到来。在分组中设置的GTR标记表示一个组的结束。在分组中设置的TTR标记表示SDU的结束。这可以标记两个SDU之间的分隔或报文最后的SDU。DataEnd TPI与最后的SDU中的最后分组连接。
从调用报文产生的第一分组总携带调用的PDU头，并且假设具有隐含的PSN 0(正如图2所示)。如果流式调用报文被分割，则应答器把调用的PDU当作为分组编号0，并等待后面的被分割的流式调用PDU。附加分组配备有被分割的流式调用头，后者具有按顺序递增的PSN。在图2中，分组1至33包括所述类型的PDU。这样的PDU如下
分组是以组的形式发送的。后面还要详细讨论组的传输。分组是以组的形式确认的。
不管Stream Invoke PDU是否被分割，在类3的事务中，PSN由始发端和应答器两者保存。这是为了让发送者知道下一个PSN(下一个分组的PSN)和让接收者知道最后一个被确认的分组的PSN，因而知道下一个期望的分组(它不是需要下一次接收的分组)。如果在Stream Invoke的服务原语中设置End-Of-Data标记，则报文处理程序将DataEnd TPI与PDU头的固定部分相连接。如果Stream Invoke报文没有被分割，则它的Invoke PDU就携带有DataEnd TPI。如果Stream Invoke报文被分割，则最后报文组的最后分割的分组就携带有DataEnd TPI，并且所述信道被关闭。
PSN环绕并且具有32比特的字段。这是为了为数据传输提供较多的时间，以便数据流中的所有分组更可能在PSN完全环绕之前被接收，并且使PSN的编号能重用。事务可能有长的生存期，因此，只有PSN(或偶然有RID)将把新的有效分组与复制的老分组区分开。
WTP提供者(始发端)将Invoke PDU发送，启动重发计时器，并将重发计数器设置为0。此外，WTP提供者(始发端)将PSN初始化为0，并开始等待WTP提供者(应答器)的确认。当WTP提供者(应答器)接收带有TID的Invoke PDU时，它确认Invoke报文，并将它传递给由生成的TR-Stream Invoke表示的服务原语的WTP的用户(应答器)。
当重发记时器到期，即已达到重发间隔时，如果发送者未接收到Invoke PDU的确认或任何其它分组时，重发计数器递增1，所述组的最后分组重发，并且重发计时器重启动。对于所有的重发，都要设置RID字段。它就是唯一被修改的字段。WTP提供者继续重发，直到重发数目超过最大的重发值。如果直到重发计数器计数全满并且计时器到期时还没有接收到确认信息，那么，所述事务将被终止，并通知本地WTP用户。
假设WTP的提供者(应答器)接收到Invoke PDU，它就利用StreamAcknowledgement PDU、Stream Ack PDU确认第一个分组，即InvokePDU。这是一个Ack PDU，它携带有Stream PSN TPI的头，它的PSN等于0。WTP提供者(应答者)也以Option TPI(MaxGroupSize TPI)形式发送它的最大组尺寸，以表示被允许的发送者的组窗口尺寸。组的尺寸由发送者选择，使其能够适合当前网络的加载，并且不会比接收者的窗口大。最后一个窗口是有效的，直到接收者将MaxGroupSize TPI添加到最后组的确认中而使下一个窗口发生变化。为了对网络和加载变化有最佳反应，接收者应该选择组的尺寸，这个组不宜太大。
如果整个Stream Invoke报文可以用一个数据报从始发端发送给应答者、因而不需要分割和重组，那么，可以以Invoke PDU的形式发送。为了使所需要的PDU的数目达到最小，即使没有分割，所述PDU也被重用。因此，为了表示它是报文中的最后一个分组，在它的头中，TTR标记设置为1。
分组是以组的形式发送和确认的。如果没有必要进行分割，那么，一个组就由一个分组组成。在一个分割成分组的组中，各分组是以单个批形式发送的。由于第一个组是在不知道接收者的状况的情况下发送的，所以分组编号应该是1。下面说明两个可选择的组装传输方法的实施例。传输方法1
所述传输方法实施例不是“停止-等待”。就是说，在可以于确认接收到前一个组之前发送的后续组的各个分组中，可能存在尚未认可的分组的组。
所述组的最后分组为GTR分组。GTR的标记表示发送者请求确认在所述组中发送的所有分组。整个报文的最后分组为TTR分组。
在传输方法1中，如果设置了标记GTR，那么，接收器必须利用确认的最后一个组和接收到最后分组之间的PSN列表发送确认(携带有所述流式PSN TPI的Ack PDU)，所述确认具有接收到最后一个完整组的最后分组的PSN或者Stream Nack PDU。Stream Nack PDU包括最近的组丢失的分组的PSN，并且可能还包括直到被确认的最后组之前的各组丢失的分组的PSN、但是不包括被确认的最后的组。
报文的每一个最后分组(SDU)是组的末端并且要进行确认。TTR也是对确认的请求。
包括在Stream PSN TPI中的PSN是确认分组(GTR分组)的PSN。所述确认是在组内累积的，在那里，它确认所述组中到达的所有分组，但是，不确认接收到的所述组之外的其它先前到达的所有分组。
报文是按顺序发送的。新报文的发送不能在前一个报文传输结束之前开始。当接收者接收非GTR分组的分组时，它将所述分组存储，并等待新的分组。当接收者接收到一个报文的所有分组(即最后分组是TTR分组)时，它应该能够重组完整的报文。当接收者接收GTR分组时，它将检查它是否已经接收了属于那个分组的组的所有分组。如果是这种情况，接收者就向发送者发送Stream Ack PDU(在携带Stream PSN TPI的Stream Ack PDU中，将PSN设置为等于GTR分组的PSN)。当已接收到设置的GTR分组，并且所述组有一个或多个分组丢失时，在返回带有丢失分组列表的Stream Nack PDU前，WTP提供者等待一个时段、例如平均往返时间的一半。如果在所述时段内所述组的状态改变了，即实际接收到了丢失的分组中的一个，那么，等待时间复位。为了指明错误接收组数据，在类3事务中唯一地使用Stream Nack PDU。这种情况显示如下
Stream Nack PDU可以列出属于其它组的其它丢失的分组。用这种方法，如果接收到了当前的Stream Nack PDU，但是，前一个StreamNack PDU已经丢失，就不需要发送者重发最后未确认的GTR分组，并等待接收者重发先前丢失的Stream Nack PDU。这可以说明如下。假设在第一组里有一些丢失的分组，在第二组里也有一些丢失的分组。接收者将第一组的第一个Stream Nack PDU和第二组的第二个Stream Nack PDU发送。如果第一个Stream Nack PDU丢失，发送者不知道第一组的状态是什么样。所以，如果第一组丢失的分组包括在第二个Stream Nack PDU中，这就可以避免全程往返和相关的重发时间。发送者用原来的PSN，而不是用设置的RID标记重发丢失的分组。当接收者已经接收到完整的分组的组、包括被重发的分组时，它就确认GTR分组。
第一组的大小可以是取决于荷载电路的缺省值。在Stream AckPDU中，下面传输的第一分组的组，所述接收器可以将它的表示其当前窗口分组空间的MaxGroupSize传输出去。定义窗口分组空间，它是任何一个时刻尚未认可的分组的数目。所述窗口分组空间在发送者和接收者中都存在。
在所述初始过程后，接收者可以用其窗口分组空间控制数据流。控制数据流的一种方法就是在单个报文传输期间改变组的大小。使用的窗口分组空间是用字节量度的。一个组中最大分组数目由最大荷载电路的分组大小确定。一个组中可传输的最大分组数目由接收者中可使用的数据缓冲区的数目确定。
窗口分组空间被映射到PSN空间，即从尚未认可的最长分组(即最长时间没有确认的分组)开始的PSN的范围，并扩展到使PSN等于尚未认可的最长分组的PSN加上窗口分组空间的分组数目。如果一个特定的组被确认，这虽然意味着属于那个特定组的所有分组都已经被接收，但这并不需要对在接收到那个特定组的前后传输的组中的分组作解释。如果一个组确认已经到达，并且在接收者的PSN空间中，所有其它分组具有的PSN比已经接收到的PSN小，窗口就要调整，使得它从新的尚未认可的最长分组开始，以便重新定义PSN空间。这样，PSN空间可以渐快地移动，甚至使它的起点PSN和终点PSN移动一步，而不是与窗口分组空间对应的跳跃移动。
当发送者发送分组和接收者接收分组时，分组传输中的延迟可以导致尚未认可的分组。假设这些尚未认可的分组已被接收，当接收每一个尚未认可的最长分组时，接收者向发送者发送对接收到尚未认可的最长分组的确认，并将它的窗口分组空间移动去占据下一个PSN空间。这样，PSN空间现在就从新的尚未认可的最长分组开始。当发送者接收到确认时，它就相应地移动它的窗口分组空间，使得发送者和接收者的窗口分组空间对应。
发送者不应该生成比窗口分组空间更大分组数目的组。
当重发时间截止时，如果发送者还没有接收到确认，那么只有GTR分组被重发，而不是整个分组的组被重发。
如果在Stream Nack PDU中，丢失分组数目的参数值为0，那么所述组的所有分组都被重发。
由于没有更多的缓冲区空间接收数据，接受者通过发送等于0的、带有确认的MaxGroupSize TPI可以关闭它的窗口。然而，接收者仍然不得不保留一个分组的缓冲区接收可能的异常终止。为了使接收器给出关于其窗口的信息，即使窗口被关闭，接收者也将传输一个分组的组(GTR分组)。接收者发送对表示当前窗口的状态的应答的确认。所述窗口不可能仍然被关闭。当窗口再次打开时，接收者重复对最后分组的组的确认。确认携带具有新的可用窗口大小(也许不是0)的MaxGroupSize TPI。然而，接收者不能接收关于打开窗口的确认。这可能是由于确认已经被丢失，但是它已经发送，可能还没有接收到，或者甚至还没有发送。如果发送者没有接收到确认，在通常的方法中，就使用重发计时器控制任何需要的重发。在任何情况下，发送者将被告知关于接收者中的源问题，这样，重发计时器就比正常的大。传输方法2
该传输方法实施例是停止-等待。这就是说，没有可能存在尚未认可的分组的组。仅仅在已经接收到前一个组的所有分组的确认时才发送后续组的GTR分组。根据接收到的确认，沿着窗口的分组空间移动的详细方案与上述说明对应。
一个组的最后分组是GTR分组。一个完整报文的最后分组的组的最后分组是TTR分组。在传输方法2中，GTR和TTR标记具有与WAP无线事务协议规格中说明的含义相同。
当接收者接收到一个既不是GTR分组也不是TTR分组的分组时，它将分组存储并等待一个新的分组。当接收者已经接收一个完整的分组的组，并且最后分组是TTR分组时，它应该能够重组所述完整的报文。当接收者接收或者是一个GTR或者是一个TTR分组，并且所述组的所有分组都已成功地接收到时，它就将一个确认PDU(携带有Stream PSN TPI)发送给发送者。当接收到或者是一个GTR或者是一个TTR分组、并且所述组有一个或多个分组丢失时，在返回带有丢失分组详情的Stream Nack PDU之前，WTP的提供者等待一个时段，例如，平均往返时间的一半。如果在这个时间期间，所述组的状态发生了变化，即实际接收到一个丢失的分组，这时，等待时间被复位。
当接收者接收到或者是一个GTR或者是一个TTR分组时，它就检查它是否接收到属于那个分组的组的所有分组。如果接收到了完整的分组的组，接收者就返回一个带有连接的Stream PSN TPI的头的Stream Ack PDU，在那个头中，PSN等于GTR或TTR分组的分组顺序编号。包括在Stream PSN TPI中的PSN是被确认分组(GTR或TTR分组)的PSN。这个确认被累计，它确认被接收到的先前发送的分组。
如果有一个或多个分组丢失，接收器就用Stream Nack PDU回答，并且将丢失的分组列在Stream Nack PDU中。丢失的分组用原始的PSN而不是用设置的RID标记重发。当接收者接收到完整的分组的组，包括被发送的那些分组时，它就要确认GTR或TTR分组。
如果重发计时器已经到期，发送者还没有接收到确认信息，那么，只重发GTR或TTR分组，而不是整个分组的组。
如果在Stream Nack PDU中，丢失的分组数目的参数值为0，那么，所述组的所有分组都重发。
为了改善本传输方法中的通过量，应包括以下特征
1.在传输一个组期间，如果发现丢失了序列中的一些分组，接收者可以不必等待GTR或TTR分组，发送Stream Nack PDU。因此，如果关于一个特定分组的第一Stream Nack PDU在接收到GTR或TTR分组之前发送出去，并且所述特定分组在接收到GTR或TTR后仍然没有接收到，那么，特定分组将用第二个Stream Nack PDU表示，因而，将表示为在Stream Nack PDU两者中丢失。
2.组的大小被选择为所述组窗口大小数值的一半。在所述组窗口大小为奇数的情况下，所述组的大小为((组窗口的大小)-1)/2。通过接收者利用MaxGroupSize TPI表示它的窗口大小来确定组的大小，而发送者则选择合适的组大小。将通过以下例子来说明所述传输系统的运行。让我们假设窗口的大小为11。
因此，所述组的大小为5。有四个分组被发送。在第一传输突发中，分组0、1、2、3、4(第一组的GTR分组)、5、6、7和8被发送。所述第一传输突发是整个第一组和第二组的一部分。第二组的GTR分组没有用这种传输突发发送。在第二传输突发中，待发送的第一分组是第三组的一部分跟随其后的第二分组的GTR分组。第三组的GTR分组在这个传输突发中没有发送。在后续的传输突发中，第一分组是以前发送的突发的组的GTR分组和拒绝所述新组的GTR分组的一个新组。正如接收到的每一个GTR分组一样，如果已经接收到它的组的所有分组，就传输一个对那个组的确认，并且出现下一个传输突发。在任何时候，只能有一个GTR/TTR分组可以是尚未认可的。在提供所述传输方法时，接收者要求能够存储一个组的不完整的分组序列和后续的传输突发，以及对组进行重组。这就要求接收者能够处理两个重叠传输的分组的组。丢失的组将被列在Stream Nack PDU中，然后重发。在此期间，下一个组的分组已经可以发送，并且可以在接收缓冲区等待重组。
在传输方法1和传输方法2两种情况下，TTR隐含地标记一个组的结束。
在包含DataEnd TPI的报文被确认后，没有数据报文可以发送给接收者。
报文在WTP提供者(应答器)中被重新组装。一旦报文被重组，WTP提供者(应答器)调用在WTP提供者(应答器)中的服务原语TR-Stream Invoke.ind，然后，WTP用户接收报文，然后通过调用在WTP提供者(应答器)中的服务原语TR-Stream Invoke.res响应。
在类2的事务中，单个调用的报文不要发送或接收确认报文，就可以通过单个的Result报文确认。这就是隐含确认。在类3中，可能存在许多与同一事务相关的分组和分组的组，并且所述事务可以继续很长时间。因此，由于它能够涉及不同的调用报文，所以，接收Stream Result报文就不是隐含确认特定的调用报文。这是因为Stream Result报文不包括PSN或与调用报文相关的PSN。此外，定时很重要。在一个信道上传输的PDU不是(需要)象彼此应答那样发送。单个的确认是为单个分组设置的，那就是指定GTR分组的确认，并且隐含对非GTR分组的确认。
在类3中提供了用户的确认功能。当它被设置(在Stream Invoke服务原语中由WTP用户设置，在Invoke PDU中由WTP的提供者设置)时，所有报文不是由接收WTP的提供者自动确认，而是发送给高层以便对报文响应。当高层响应时，WTP的提供者将向发送所述报文的WTP的提供者发送确认。
如上所述，图1只显示了在事务处理期间，经输入信道发送的报文。在输出信道上，事务处理以类似方式出现。在应答者接收类3的Stream Invoke PDU并确认它后，Stream Invoke PDU向上传送、以便由WTP提供者(应答者)上方的一层或几层处理。Result报文按照处理调用报文相同方式处理。在装配数据时，WTP的用户(应答者)通过启动WTP提供者(应答者)中的TR-Stream Result请求原语来发送Result报文。这种TR-Stream Result请求原语用于传输类3事务中的Stream Invoke报文的结果。它具有的参数由下表给出
Result报文被发送给使用Result PDU的始发端。它是被分割还是不被分割，这取决于它的大小。当Result PDU被发送时，应答器启动重发计时器，并等待始发端的确认。在Result PDU由始发端接收后，WTP的提供者(始发端)将TR-Result表示的原语转送给WTP的用户(始发端)。
在包含DataEnd TPI的报文被被确认后，事务处理结束。
由最后报文的最后组的接收者发送最后的确认后，发送者和接收者在撤消它们各自对相关信道的管理之前都必须等待。这就是如果没有接收到确认，发送者可以重发最后组的原因，并且接收者能够知道发送者接收到了所述确认。
图4示出类3事务的一部分，其中，数据是以扩展形式发送的。与图1一样，只显示了在输入信道上的通信。图4示出类3事务的启动，其中，Stream Invoke报文的大小没有超过网络的MTU，并且没有使用分割。WTP用户(应答者)调用在WTP提供者(应答者)中的服务原语TR-Stream Invoke.req。如果在TR-Stream Invoke的请求原语中没有设置End-Of-Data参数，那么，始发端必须发布至少一条以上的TR-Stream Invoke Data服务原语。下面将对这些问题进行讨论。由于报文没有分割成附加的分组，WTP的提供者(始发端)将包括整个报文的Invoke PDU发送给WTP的提供者(应答器)，并且WTP的提供者(应答器)调用WTP用户中的一条服务原语TR-StreamInvoke.ind。当WTP用户(应答器)接收到报文时，它就调用WTP的提供者(应答器)中的一条服务原语TR-Stream Invoke.res。WTP的提供者(应答器)将一条带有PSN值为0的Stream Ack发送给WTP的提供者(始发端)，这就导致了WTP提供者(始发端)调用WTP用户(始发端)的服务原语TR-Stream Invoke.cnd。Stream Ack携带MaxGroupSizeTPI。
在图3的情况下，始发端决定在相同的事务处理内将更多的数据发送给应答器。WTP用户(始发端)调用WTP提供者(始发端)中的一条TR-Stream Invoke Data.req服务原语发送附加数据。下面示出TR-Stream Invoke Data(Stream Invoke Data)服务原语的参数。所述原语用于连续传输类3事务中的Stream Invoke报文数据。
另外，由于Stream Invoke报文大小没有超过网络的MTU，所以所述报文没有分割成附加的分组。WTP提供者(始发端)将一条Sgemented Stream Invoke PDU发送给WTP的提供者(应答器)。由于所述PDU是所述事务的下一个分组，并且设置的TTR标记表示PDU是所述报文中的最后分组，同时也表示请求一个确认，所以，它的PSN值为1。WTP提供者(始发端)将一个与Segmented Stream Invoke PDU的固定头部分连接的DataEnd TPI发送给WTP提供者(应答器)。WTP提供者(应答器)调用WTP用户(应答器)中的一条服务原语TR-StreamInvoke Data.ind。
当它接收到调用报文时，WTP的用户(应答器)通过调用WTP提供者(应答器)中的服务原语TR-Stream Invoke Data.res响应。WTP提供者(应答器)将一与带有PSN的值为1的Stream PSN TPI、并与WTP提供者(始发端)连接的Stream Ack PDU发送出去。WTP提供者(始发端)调用WTP的用户(始发端)中的服务原语TR-Stream InvokeData.cnf。
一旦始发端再也没有数据发送时，就设置TR-Stream Invoke Data服务原语中的End-Of-Data标记。
如果始发端还要从TR-Stream Invoke Data服务原语开始发送若干数据报文，那么，还将通过Segmented Stream Invoke头向它们提供关于所述报文是否被分割的信息。如果需要分割，所述报文就被分割。当类3事务的附加数据在一个Stream Invoke报文后发送给应答器时，那么，在所有种情况下都要使用Segmented Stream InvokePDU。如果没有必要对报文进行分割，那么，所述PDU将是一个分组报文组的最后分组。
在最后的数据报文情况下，DataEnd TPI将与最后的SegmentedStream Invoke PDU头的固定部分连接。当那个报文是报文流中的最后报文时，End-Of-Data参数包括在Stream Invoke和Stream InvokeData服务原语中。服务原语的参数将被设置，因而，局部的WTP将DataEnd TPI与这个最后报文的最后PDU连接。
一旦应答器获得了对调用报文的响应数据，WTP用户(应答器)就通过在WTP提供者(应答器)中的初始TR-Stream Result请求服务原语发送结果报文。它可以或者以单个报文或者以被分割的报文发送，这取决于结果报文的特性。从Stream Result报文产生的第一个分组总是携带有Result PDU头，并且假设为具有隐含的分组编号0。如果结果报文需要被分割，它就以附加的Segmented Stream ResultPDU发送。
如果要求WTP的用户(应答器)还要发送数据块，这可以通过发布TR-Stream Result Data服务原语来实现。这导致发送几个StreamResult报文。所述TR-Stream Result Data服务原语在下表列出
即使没有必要对报文进行分割，所述服务原语将产生一个Segmented Stream Result PDU。在这种情况下，所述PDU将是第一个和最后一个报文分组，并将设置TTR标记。
在发送Stream Invoke或Stream Result报文后，PSN的计数器将在数据传输结束时才被清除。
在事务处理期间，当需要时，始发端和应答器各自可以利用单独的Stream Invoke Data和Stream Result Data报文发送几个数据块，直到事务处理结束为止。
一旦应答器再也没有数据发送时，它就通过设置Enf-Of-Data参数关闭事务处理的一侧，Enf-Of-Data参数或者在TR-Stream Result或者由在WTP提供者(应答器)中的WTP用户(应答器)调用发布的TR-Stream Result Data服务原语中设置，并传输End-Of-Data报文(带有与DataEnd TPI头连接的报文)。如果End-Of-Data参数没有在TR-Stream Result的请求原语中设置，应答器就不得不至少发布一个以上的TR-Stream Result Data服务原语。然而，由于应答器可以接收始发端的附加数据，所以，由应答器结束的信道直到接收到始发端的End-Of-Data报文才使事务处理结束。如果始发端和应答器两者都发送它们的End-Of-Data报文，则事务处理被终止。在任何情况下，一个事务处理可以在任何时候由调用事务处理故障服务原语的任一方放弃。所述服务原语在无线事务处理协议说明中定义。
当信道的最后报文被接收到时，就发送最后的Ack PDU。确认的发送者必须将状态信息保持，为的是能够处理前一个组的重发信息(例如，假设确认被丢失)。所述状态信息可以利用等待定时器来保持。
接收的和重组的报文被转移到WTP提供者的上一级，即转移到WTP用户级或其它地方，报文的大小与发送的相等。
与由WAP标准定义的事务类1和2不同，在类3事务中，所有报文都由显式Stream Ack PDU确认以表示被接收到的特定报文。可以将扩展的数据传输重叠，即两个信道可以并行工作，一直到接收到DataEnd TPI为止。事实上，这就意味着Stream Invoke Data PDU可以在一个方向上传输，同时，Stream Result Data PDU可以在相反方向传输。
WTP提供者(始发端)在接收以前事务的结果之前能够启动多个事务处理。这些事务可以异步处理，其中，在响应以前的事务之前，接收到对后面事务的响应。
PDU的固定头的变化部分可以由一个或几个TPI组成。一个TPI的长度可以是2或8位。
注1)如果分割和重组用于分割和重组报文，所述TPI才适用。
注2)所述TPI仅用于类3的事务。
Error TPI返回给发送者一个错误的或不支持的TPI。Info TPI用于对PDU头的变化部分的小数据量进行分段，例如，性能度量或统计数据。Option TPI用于在两个WTP实体之间传输参数。应当指出，与无线传输协议的规格不同，事务中的任何部分可以在任何时间分发任何Ack PDU中的最大组选择TPI，并且应该一直到下一个相同类型的TPI或事务结束都有效。DataEnd TPI可以与下列PDU连接
Invoke PDU
Result PDU
Segmented Stream Invoke PDU
Segmented Stream Result PDU
DataEnd TPI的意义在于，将没有任何数据从所述方向传输到所述事务的另一方。因此，这就是所述方向的最后被编号的分组。如果设置了TR-Stream Invoke、TR-Stream Result、TR-Stream Invoke Data或TR-Stream Result Data服务原语中任何一个的End-Of-Data标记参数，最后报文组的最后分组将携带所述DataEnd TPI。其结构如下
在类3的事务中，Ack PDU没有一个分组顺序编号字段，而流分组的顺序编号TPI用作为与Ack PDU头的变化部分的连接。以上介绍的两种传输方法的TPI是不同的。在传输方法1中，包括在AckPDU中的PSN是确认分组(GTR分组)的PSN。所述确认是累积在组里的；它确认到达的所述组的所有分组，但是不表示已经接收到的所述组以外的所有前面的分组。在传输方法2中，包括在Ack PDU中的PSN就是被确认的分组(GTR或TTR分组)的PSN。
图5示出有效的原语序列表。在任何一列中，作为列首的服务原语只能被用X标记的行中对应的服务原语跟随。End-Of-Data表示设置在服务原语中的标记。所述表只给出了允许的全部原语序列。
现在将说明在WSP层上涉及利用类3事务处理的步骤。图4示出在较高级上图3的流式调用事务处理，以便示出在发送者和接收者中对话层的有关情况。图4示出在每一个接收者和发送者中，由WSP提供者中的WSP用户调用的对话层的服务原语。
S-Stream方法调用的原语用于请求一个由服务器执行的操作。它只能与S-Stream Result服务原语一起使用。
End-Of-Data标记表示是否还由任何数据(请求体的延续)。如果设置了End-Of-Data标记，那么，它就是由Stream Invoke报文发送的所有数据。
S-Stream Invoke Data服务原语用于将开始请求操作的请求体的延续传输给服务器。它只能在以前的、它的End-Of-Data标记清除了的S-Stream Method Invoke原语出现之前调用。
End-Of-Data标记表示是否还有任何数据(请求体的延续)。如果设置了End-Of-Data标记，那么，这就是已经传输的最后数据。
S-Stream Result服务原语用于返回对操作请求的响应。它只能在前面的S-Stream Method Invoke原语出现后调用。
End-Of-Data标记表示是否还有任何数据(请求体的延续)。如果设置了End-Of-Data标记，那么，这就是已经发送的所述Stream Result报文中的所有数据。
S-Stream Result Data原语用于返回对操作请求的附加响应数据。它只能在前面的S-Stream Invoke原语出现后调用。
End-Of-Data标记表示是否还有任何数据(请求体的延续)。如果设置了End-Of-Data标记，那么，这就是已经发送的所有数据。
在S-Stream Method Invoke语句中，可以使用以下PDUGet、Post和Reply。这些PDU是在WAP标准中定义的。
另一个事务的例子是Stream Push事务。所述Stream Push事务也应用类3的WTP事务，但是，服务器起始发端的作用。与StreamInvoke事务不同，Stream Push事务仅仅是单向的。服务器启动事务，而客户机是响应者。大的数据量可以以上面说明的任何一种数据流形式传输。由于只有服务器将数据传输给客户机，所以应答器信道将被自动关闭。
Stream Push事务中使用的服务原语定义如下S-Stream PushS-Stream Push Data
在S-Stream Push语句中，使用在WAP标准中定义的PDUConfirmed push PDU。
为了提供这些任选的功能传输(Push)、核实传输(Confirmedpush)、挂起(Suspend)和恢复(Resume)、以及确认头(Acknowledgementheaders)，必须对WSP进行修改。更详细地说，必须添加两个协议任选标记，并且引入两个更强的功能最大的尚未认可的流式方法请求和最大的尚未认可的流式传输请求。
始发端能够发送第一调用报文，然后，在应答器接收第一调用报文之前，发送第二调用报文(即一个流式调用报文)。应答器将注意到，它接收到的第一调用报文有一个新的TID，但是，不能正确地启动事务。在这种情况下，应答器将第二调用报文存储，而不是放弃它，然后等待调用报文。
还可以提供类3事务中几个PDU的级联。它使用象与由WAP标准定义的其它类级联一样的规则。
本发明可以插入移动终端、WAP协议栈、WAP服务器或网关中。
图6示出一个通信系统，它包括多个能够访问互连网4的移动终端2。移动终端接收通过无线网络8接收和发送的信号6。所述信号包括根据WAP的无线标记语言(WML)和WAP命令。WML是一个基于标记的显示语言，并提供导航支持、数据输入、超级链接、文本和图像表示及生成。它是一个与HMTL类似的浏览语言。由网络8接收的信号10发送给代理或网关服务器12。服务器12将WAP的请求翻译成HTTP请求，这样就允许移动终端2向web服务器14请求信息，并浏览互连网4。从web服务器14获得的信息由网关编码成合适的格式，然后，通过无线网络传输给请求信息的移动终端2。移动终端2处理并应用这些信息。如果web服务器14以WAP/WML的格式提供其内容，服务器12可以直接从web服务器14恢复这些内容。然而，如果web服务器以WWW格式(例如，HTML)提供其内容，就要使用滤波器，将内容从WWW格式转换成WAP/WML格式。
虽然图6示出从互连网获得的信息，但是网关自已可以包括所需要的信息。例如，客户机可以从网关的文件系统恢复信息。
图7示出网关服务器的实施例的硬件结构、例如计算机20，计算机20具有动态存储器、处理功能及存放运行网关服务器需要的所有程序，例如，应用程序、协议栈及操作系统。计算机20包括用户接口，例如，键盘22和显示器(未标出)；以及服务器程序24。服务器程序24具有处理以下协议事件的应用程序25，例如，处理从服务器恢复WML的请求和协议栈，例如，WAP协议栈28和HTTP协议栈30。应用程序26控制计算机和各种网络，包括电话网络32、互连网34和数据网络以及电路开关数据网络35之间的数据流，包括命令、请求和信息。计算机20与互连网34的通信是通过HTTP协议栈30和接口36进行的。计算机20与电话网络34和数据网络35的通信是通过接 38和40进行的。服务器程序24包括在HTTP和WAP之间转换的应用程序42。SMS通信可以通过合适的硬件与操作员网络作数据连接实现。
出现在应用程序26和WAP协议栈28中的单个线程44使用计算机20中的处理器46完成需要的处理任务。将线程分配给处理器由在计算机20的操作系统50中的线程服务48规定。
WAP堆栈是建在所谓荷载电路(它提供数据包服务)的上部。这些电路可以是，例如，SMS或CSD。这些电路具有它们自已的协议，并且通过协议栈的实现来实现。
图8示出一个移动终端60的实施例。移动终端60包括中央处理器(CPU)62、收发信机64、存放内容的存储器66、WAP微浏览器和控制数据在收发信机64上转接的相关的协议68、显示器70以及用于移动终端的与电话相关的功能的存储器72。由于这与通常的移动终端60的电话活动有关，所述收发信机64在进行电话呼叫中的操作不予说明。CPU 62控制其它部件的操作。
图9示出图6的通信系统。它提供了显示客户机(例如，移动终端、网关和服务器，在此情况下的web服务器)详细情况的不同视图。
下面建议了一些本发明的应用程序，它们可以在实施例中获得，其中WAP用于双向报文的流动。自然，如果类3的功能可以在应用程序级实现，那么，极大多数这些应用程序可以使用现有的WAP堆栈。
在实现调用数据转移的事务处理后，有两个问题要着重考虑传输大容量数据和预定事务。发送报文序列使得能够连续传输大容量数据，并且也能传输预定的事件。如果使用多重事务，就不能保证按顺序发送和接收报文，因此，这就必须在应用程序级控制它们。由于许多应用程序需要小容量数据与先发送先到达的事件一起传输，所以，发送有序的事件是很重要的。
本发明可以用于视频会议。这样的视频会议系统提供了许多与能够使服务器作为分布中心的WAP连接的客户机。每一台客户机都通过发送和接收单独的图像或帧流的双向流与服务器连接。由于帧的顺序是重要的，以及没有流的应用程序自已必须重构帧的顺序，那么，流就是有用的。其优点是将视频会议与WAP组合在一起。可以提供高级用户接口作为用于选择、传输信息以及与会议连接的WML卡片盒。整个服务器可以提供简单的WAP服务器。基于WAP的视频服务的另一个重要的应用领域是蓝牙(bluetooth)服务器，其中，WAP可以用作浏览/存取视频信息的传输协议。
在另一个实施例中，主服务和其它服务配备有微型的WAP服务器，使它们能够从WAP客户机存取。一个例子是语音邮件服务器的WAP，它允许从WAP浏览器与报文状态浏览连接，并允许收听它们。从客户机到服务器的信道用作控制信道以便发送命令，以及使语音沿着信道从服务器流向客户机。发送给设备的命令可以包括跳过报文、删除报文等等。
在又一个实施例中，可以提供远程控制或远程测量系统，其中，客户机与提供测量数据流(例如，实时压力数据)的中央处理服务器连接，以及控制服务器传输反向控制或归纳数据流中的信息。如果系统是允许带有数据流支持的WAP，它就可以以带有WAP客户机的WAP服务器的形式实现。
在再一个实施例中，提供基于服务器的博弈系统。在这样一种多人游戏系统中，集中游戏服务器向用户提供连接。在实时动态游戏情况下，信息以流的形式发送和接收，其中，事件的顺序是重要的。例如，玩家不允许在它被“击败”后与其它玩家相互作用。游戏服务器和客户机可以用双向流协议连接以保证事件按顺序到达。
在另一个实施例中，可以提供基于WAP智能映射系统/定位测量服务器。在所述系统中，向服务器发送定位信息流，所述服务器按顺序传输反向映射，并映射坐标数据。如果定位的更新很频繁，由于跟踪是非常精确(象在一个城市跟踪一辆汽车或跟踪一个步行者，使得他或她可以发现一个具体商店)，因此，双向流用于保存事务的顺序。
在另一个实施例中，可以提供控制语音的WAP服务，所述服务接收语音命令和/或将语音文件发送给用户。从处理功能和重量的观点看，规定服务的命令集的语音识别可能很难提供便携式终端。利用本发明可以把语音数据经由输出信道发送给WAP服务器，其中，可以实现复杂的识别/语言选择。类似地，返回信道可以用于以响应的形式传输声音/语音数据。
本发明提供了一种新的事务类，所述事务类可以在单个事务中提供任意大小序列的报文。由于除新的特征外，新事务类3保特了WAP标准的所有特征，因此，本发明与WAP标准兼容。类3事务可以分别被鉴别和处理。处理错误、版本和TID的方法与WAP标准相同。
在类3事务中，报文的处理过程也使用现有的分割和重组处理，因而不需要定义单独的SAR处理。然而，应当指出，本发明用两种方法使用现有的分割和重组过程。它用类似于类2使用的方法使用它，那里将报文分割成分组。此外，不管分割和重组是否应用于特定报文，本发明也用它传输报文流。在任何情况下，总是使用PSN。这是与类2事务不一样的，在类2事务中，只要有一个分组，就不应用分割和重组。
虽然本发明说明了有关WAP，但是它可以适用于任何其它事务的基本通信协议。例如，它能够适用于IP网络上的浏览。特别适用于无线网络，但是也适用于有线网络。
本发明的具体实现和实施例已经说明。很清楚，对于本专业的技术人员来说，本发明没有局限于上面介绍的实施例的详细情况，而可以使用不背离本发明特征的等价方法在其它实施例中实现。本发明的范围仅仅由所附的权利要求书限制。
权利要求
1.一种经由发送者和接收者之间的链路实现事务处理、以便以多个数据报文的形式发送数据的方法，每一个所述数据报文包括至少一个数据分组，
所述方法包括以下步骤
所述接收者确认接收到的数据分组，以便提供可靠的连接；
所述发送者将每一个数据报文中的最后数据分组通知所述接收者；以及
所述发送者将最后数据报文通知所述接收者。
2.如权利要求1所述的方法，其特征在于数据不具有预先确定的长度。
3.如权利要求2所述的方法，其特征在于在事务处理内部传输任意长度的流式报文序列。
4.如上述权利要求中任意一个所述的方法，其特征在于在数据传输期间所述数据分组被按分组顺序号连续编号。
5.如权利要求5所述的方法，其特征在于所述分组顺序号是环绕式的。
6.如上述权利要求中任意一个所述的方法，其特征在于所述数据被分割和重组。
7.如上述权利要求中任意一个所述的方法，其特征在于所述发送者和所述接收者之间的通信在所述事务处理范围内是双向的。
8.如权利要求7所述的方法，其特征在于提供两个信道，一个用于将数据从始发端传输到应答器，而另一个用于在相反的方向上传输数据。
9.如权利要求8所述的方法，其特征在于通过发送所述数据的最后报文来关闭所述信道中至少一个信道。
10.如权利要求8或9所述的方法，其特征在于如果经由两个信道的传输被终止，则所述事务被终止。
11.如上述权利要求中任意一个所述的方法，其特征在于以分组的组的形式发送所述各分组。
12.如权利要求11所述的方法，其特征在于当从所述组接收到所有分组时，所述接收者确认一个完整的组。
13.如权利要求12所述的方法，其特征在于当所述接收者证实已接收到所述组的其它分组时，所述接收者确认一个组的最后分组。
14.如权利要求11至13中任意一个所述的方法，其特征在于在后续组的各分组中，可能存在尚未认可的分组的组，后者可以在接收到对前一个组的确认之前发送。
15.如权利要求11至13中任意一个所述的方法，其特征在于不可能存在尚未认可的分组的组。
16.如权利要求15所述的方法，其特征在于在接收到代表其分组的组的端点的分组之前，发送通知丢失分组的第一报文。
17.如权利要求16所述的方法，其特征在于如果已经接收到代表其分组的组的端点那个分组、而且所述丢失的分组仍然没有接收到，则发送通知丢失分组的第二报文。
18.如权利要求15至17中任意一个所述的方法，其特征在于以传输突发的形式发送一个组的分组，以及通知完成特定组的分组不包括在包括所述特定组的一些分组的传输突发中。
19.如权利要求18所述的方法，其特征在于以后续的组的形式发送所述通知完成特定组的分组。
20.如权利要求18或19所述的方法，其特征在于仅仅在接收到对前一个组的所有分组的确认时才发送所述通知完成特定组的分组。
21.如上述权利要求中任意一个的方法，其特征在于新的事务处理类具有一个可靠的调用报文和一个可靠的结果报文，利用可靠的数据报文有条件地扩展所述调用报文和结果报文。
22.如上述权利要求中任意一个所述的方法，其特征在于一旦通过调用报文启动事务处理，所述事务处理就由流式数据报文继续下去。
23.如上述权利要求中任意一个所述的方法，其特征在于当发送者发送表示数据结束的TPI并且该TPI被接收者接收到时，就终止经由一个信道的数据传输。
24.如上述权利要求中任意一个所述的方法，其特征在于在任何一个时刻，存在一个以上的未完成的事务处理。
25.如上述权利要求中任意一个所述的方法，其特征在于在单一对话中存在多个异步事务处理。
26.如上述权利要求中任意一个所述的方法，其特征在于所述链路是无线链路。
27.如上述权利要求中任意一个所述的方法，其特征在于它按照无线事务处理协议标准出现。
28.一种用于以多个数据报文的形式发送数据的移动终端，每一个报文至少包括一个数据分组，所述移动终端包括包含在存储器和协议栈中的应用程序，所述应用程序和所述协议栈经由发送者和接收者之间的无线链路实现对话，其中，所述发送者将报文按顺序发送给所述接收者、所述接收者确认接收到所述各分组、以便提供可靠的连接，所述发送者将每一个数据报文中的最后数据分组通知所述接收者，并且所述发送者将最后的数据报文通知所述接收者。
29.一种用于以多数据报文的形式发送数据的网关，每一个报文至少包括一个数据分组，所述网关包括包含在存储器和协议栈中的应用程序，所述应用程序和所述协议栈经由发送者和接收者之间的无线链路实现对话，其中，所述发送者将报文按所述接收者确认接收到所述各分组的顺序发送给所述接收者、以便提供可靠的连接，所述发送者将每一个数据报文的最后数据分组通知所述接收者，并且所述发送者将最后的数据报文通知所述接收者。
30.一种数据传输系统，它包括用于以多个数据报文的形式接收数据的多个移动终端，每一个所述移动终端包括包含在存储器和协议栈中的应用程序，所述应用程序和所述协议栈经由具有网关的无线链路实现事务处理，其中，所述网关将报文按顺序发送给所述移动终端、所述移动终端确认接收到所述报文、以便提供可靠的连接，并且所述网关将每一个数据报文的最后数据分组通知所述移动终端，并且所述网关将最后的数据报文通知所述移动终端。
31.一种数据传输系统，它包括用于以多个数据报文的形式发送数据的多个移动终端，每一个所述移动终端包括包含在存储器和协议栈中的应用程序，所述应用程序和所述协议栈经由具有网关的无线链路实现事务处理，其中，所述移动终端将所述报文按顺序发送给所述网关、所述网关确认接收到所述分组、以便提供可靠的连接，并且所述移动终端将每一个数据报文的最后数据分组通知所述网关，并且所述移动终端将最后的数据报文通知所述网关。
32.一种存储在计算机可读媒体上的计算机程序产品，所述计算机程序产品包括
用于使计算机经由发送者和接收者之间的无线链路实现事务处理的计算机可读程序方法，所述事务处理包括传输包含多个数据报文的的数据；
用于使所述发送者将所述报文按顺序发送给所述接收者的计算机可读程序方法；
用于使所述接收者确认接收到各分组、以便提供可靠的连接的计算机可读程序方法；
用于使所述发送者将每一个数据报文的最后数据分组通知所述接收者的计算机可读程序方法；以及
用于使所述发送者将最后的数据报文通知所述接收者的计算机可读程序方法。
全文摘要
本发明涉及经由移动终端和网关之间的链路实现包括数据传输的事务处理的方法。所述数据是多数据报文形式的，其中，每一个报文包括至少一个数据分组。报文的数目不预先确定。该方法包括以下步骤移动终端确认接收到的数据分组、以便提供可靠的连接；网关将每一个数据报文中的最后数据分组通知接收者；并且发送者将最后数据报文通知接收者。本发明特别适用于按照无线事务协议实现事务处理。
文档编号H04W88/16GK1451217SQ0081841
公开日2003年10月22日 申请日期2000年11月7日 优先权日1999年11月17日
发明者M·格伦戴, M·托斯, G·帕勒尔 申请人:诺基亚有限公司