专利名称：用于处理移动电台中的视频点播数据的方法
技术领域：
本发明涉及移动电台，以及更具体地说，涉及用于处理移动电台中的视频点播(VOD)数据的方法，能快速地处理连接到VOD服务供应商的移动电台中的VOD内容。
背景技术：
近年来，随着通信技术发展，移动电台具有许多辅助的功能以及普通通信功能。这些辅助功能包括照相机功能、摄像放像机功能和多媒体功能。其中，多媒体功能是再现包括语音、文本、静止图像、运动图像等待的各种媒体的数据，因此具有多媒体功能的移动电台的用户能通过无线网络，从多媒体供应商接收用于各种多媒体内容，即诸如电影、音乐视频等等的视频数据(例如“VOD”数据)的VOD服务。
VOD服务以流式格式(换句话说，实时)提供媒体内容。移动电台除用于执行移动电台的一般控制功能的控制芯片(例如移动电台调制解调器(MSM))外，还包含单独的多媒体芯片(诸如多媒体处理器)，以便更稳定地处理VOD数据。
图1A和1B是分别表示在传统的移动电台中，用于VOD服务的MSM和多媒体处理器的VOD协议栈的视图。
用于图1A所示的MSM的协议栈包括为最低层的物理层、无线电链路协议(RLP)层、点对点协议(PPP)层、网际协议(IP)层、传输控制协议/用户数据报协议(TCP/UDP)层、套接层(socket layer)和按顺序最高层的无线应用协议(WAP)层。
即，该MSM通过PPP层的协商连接到基于WAP的互联网。
同时，用于如图1B中所示的多媒体处理器的协议栈包括IP层、TCP/UDP层、套接层和实时传输协议/实时会议层/实时流式协议/超文本传输协议(RTP/RTCP/RTSP/HTTP)层。
这种多媒体处理器接收通过基于WAP的互联网，由MSM接收并通过MSM，从VOD数据的最高层到PPP层解封装的VOD数据，以及通过从IP层到RTP/RTCP/RTSP/HTTP层解封装VOD数据，处理该VOD。同时，将数据传送到VOD服务器，多媒体处理器按与接收VOD数据处理顺序相反的顺序，将传输数据传送到MSM。
在这种情况下，MSM根据如图2所示的优先级，处理VOD数据。在图2中，“TASK”表示MSM，为VOD服务而执行的任务，“CPU时间(ms)”表示每秒的MSM占用率，“NO任务转换”表示在占用时间周期期间，由其他任务剥夺相关任务的占用电动机的时间量，以及“优先级”表示相关任务的优先级。其中，较大优先级号表示较高优先级。
参考图2，应理解到优先级越高，MSM占用率变为越高，导致任务间的切换时间量越小。
根据具有上述结构的传统移动电台的VOD服务方法，在移动电台通过基于WAP互联网，访问VOD服务器时，MSM处理多媒体数据直到PPP层，然后，多媒体处理器处理从IP层到RTP/RTCP/RTSP/HTTP层的多媒体数据。用这种方式，传统的移动电台能通过多媒体处理器，处理已经通过无线网络，从VOD服务器接收的VOD数据。
然而，如图2所示，传统的移动电台必须处理具有相当小的优先级的数据服务(DS)和数据协议服务(PS)，诸如在MSM处的“70”和“60”，以致向其施加过载，因此，难以确保最大处理速度。
发明内容
因此，已经做出了本发明来解决在现有技术中出现的上述问题，以及本发明的目的是提供用于处理移到电台中的VOD数据的方法，能通过改变多媒体处理器的协议栈来快速地处理VOD数据，通过当移动电台通过MSM连接到基于WAP的互联网时协商的协议，处理VOD数据。
为实现该目的，根据本发明的一个方面，提供一种用于处理移动电台中的视频点播(VOD)数据的方法，移动电台包括用于处理多媒体数据的多媒体处理器和用于控制移动电台的移动电台调制解调器(MSM)，方法包括步骤当移动电台通过MSM访问无线应用协议(WAP)时，通过执行与服务器通信的点对点协议(PPP)协商，协商PPP选项信息；将通过MSM协商的PPP选项信息传送到多媒体处理器；将所传送的PPP选项信息用作多媒体处理器的PPP信息，设置VOD数据路径；处理根据VOD数据路径，在MSM中接收的VOD数据达VOD数据的RLP层，然后，将VOD数据传送到多媒体处理器；以及在多媒体处理器中，处理来自最低层的PPP层、传送到多媒体处理器的VOD数据。
从下述结合附图的详细描述，本发明的上述和其他目的、特征和优点将更显而易见，其中图1A和1B是分别表示在传统的移动电台中，用于VOD服务的MSM和多媒体处理器的VOD协议栈的视图；图2是表示在传统的移动电台中，根据任务的MSM占用率和优先级的视图；图3是示例说明根据本发明的实施例，移动电台的结构的框图；图4A和4B是表示图3中所示的用于VOD服务的多媒体处理器和MSM的VOD协议栈的示例视图；图5是表示根据本发明的实施例，处理移动电台中的VOD数据的方法的流程图；图6是示意性地示例说明根据本发明的实施例，移动电台和无线网络间的PPP协商过程的流程图；图7是表示用在图6所示的LCP协商过程的LCP帧的结构的视图；图8是表示图7中所示的LCP帧的详细结构的视图；以及图9是表示用在图6所示的IPCP协商的IPCP帧的详细结构的视图。
具体实施例方式
在下文中，将参考附图，描述根据本发明的实施例，用于处理移动电台中的VOD数据的方法。在本发明的实施例的下述描述中，为简洁起见，将省略其中金惟的已知功能和结构的详细描述。
图3是示例说明根据本发明的实施例的移动电台的结构的框图。
射频(RF)单元21执行移动电台的传输和接收功能。RF单元21包括RF发射机和RF接收机。RF发射机上变频和放大将传输的信号的频率以及RF接收机低噪声放大所接收的信号和下变频所接收的信号的频率。
数据处理器23包括用于编码和调制将传送的信号的发射机和用于解调和解码所接收的信号的接收机。即，数据处理器23可以包括调制器和解调器(调制解调器)和编码器/解码器(编解码器)。
音频处理器25再现从数据处理器23输出的接收音频信号和将从麦克风输出的传输音频信号传送到数据处理器23。同时，音频处理器25将根据本发明的实施例，实时通过VOD数据传送的语音信号输出到扬声器。
键盘27包括用于数字和字符信息的键和用于设置各种功能的功能键。根据本发明的实施例，键盘27可以包括VOD访问键、菜单键、方向键和确认键。
存储器29可以包括程序存储器和数据存储器。程序存储器存储用于控制移动电台的一般操作的程序和根据本发明的实施例，用于处理VOD数据的程序。
多媒体处理器31在执行VOD服务时，处理通过无线网络接收的VOD数据。根据本发明的实施例的多媒体处理器31通过MSM10，执行WAP访问时协商的PPP选项信息，然后将所接收的PPP选项信息用作多媒体处理器1的PPP信息。另外，当将PPP选项信息用作多媒体处理器31的PPP信息时，多媒体处理器31形成由MSM10的无线电链路协议(RLP)处理、用于处 VOD数据的上层(IP、TCP/UDP、套接、RTP/RTCP/RTSP/HTTP)，然后从MSM10输出，以及根据每个层，通过VOD数据的解封装处理VOD数据。另外，多媒体处理器31封装从最高协议层到最低协议层、对应于从MSM10接收的VOD数据的传输数据以便将传输数据传送到MSM10。
MSM10执行控制移动电台的一般操作的功能。另外，当用键盘27选择用于VOD服务器访问的菜单项时，MSM10识别它并将通过在执行WAP访问时，执行PPP协商设置的PPP选项信息和有关通过WAP访问形成的上层协议(IP、TCP/UDP和套接)的信息传送到多媒体处理器31。同时，MSM10接收根据由多媒体处理器31接收的VOD数据，从多媒体处理器31输出的传输数据以及将所接收的传输数据传送到VOD服务器。
显示单元40在MSM10的控制下，显示在程序操作期间生成的消息。另外，显示单元40显示从MSM10输出的用户数据。另外，根据本发明的实施例，显示单元40由多媒体处理器31处理并输出的VOD数据。其中，显示单元40可以包括LCD。在这种情况下，显示单元40还可以包括LCD控制器、用于存储图像数据的存储器和LCD元件。当LCD具有触摸屏结构时，键盘27和LCD可以充当输入部。
现在，将参考图3来描述移动电台的操作。在呼出呼叫模式的情况下，当用户在使用键盘27执行拨号操作后，选择呼出呼叫模式时，MSM10识别它，并控制接收由数据处理器23处理接收拨号信号后输出的拨号信息以及由RF单元21转换成RF信号。此后，当从被叫用户生成应答信号时，移动电台通过RF单元21和数据处理器23识别应答信号。然后，通过音频处理器25形成语音通信信道。以便变为对用户来说可以与其他用户通信。同时，在呼入呼叫的情况下，MSM10识别出数据处理器23选择呼入呼叫模式，以及通过语音处理器25生成振铃信号。此后，当用户选择响应振铃信号时，MSM10识别它，然后，通过语音处理器25形成语音通信信道，以便变为对用户来说，可以与呼叫用户通信。尽管语音通信已经描述为呼出呼叫模式和呼入呼叫模式的例子，将理解到本实施例也可以应用于除语音通信外，用于分组数据和图像数据的通信的数据通信。同时，在等待模式期间或在字符通信模式期间，MSM10在显示单元40上显示由数据处理器23处理过的字符数据。
现在，将描述如上所述的移动电台的WAP访问和VOD数据处理过程。在键盘27中按压VOD访问键，或通过确认键，选择在已经按压菜单键后显示的菜单项中、对应于VOD访问键的菜单项。然后，MSM10识别通过VOD访问键或确认键生成的按键数据，并尝试WAP访问。在这种情况下，为MSM10访问基于WAP的互联网或具有VOD服务，首先执行用于VOD服务器和基站间的用于数据传输协议的协商过程。
现在，将参考附图，详细地描述通过WAP，允许用户使用VOD服务的协商过程。
图4A和4B是表示用于如图3所示的VOD服务的多媒体处理器和MSM的VOD协议栈的示例视图。
图4A表示具有与用于传统的MSM的协议栈相同结构的MSM10的协议栈。即，用于图4A中所示的MSM10的协议栈包括最低层的物理层、RLP层、层、IP层、TCP/UDP层、套接层和顺序中的最高层的WAP层。
即，MSM10使所接收的数据经受根据每个层的解封装过程，以及通过最高层的WAP层，将所接收的数据传送到应用程序。
图4B表示不同于包括从RTP/RTCP/RTSP/HTTP层到最低层的IP层的层的传统多媒体处理器的协议栈、将PPP层包括为最低层的多媒体处理器31的协议栈。
即，多媒体处理器31的协议栈将PPP层包括为最低层，以及包括顺序地层叠在PPP层上的IP层、TCP/UDP层、套接层和RTP/RTCP/RTSP/HTTP层。
通过这种协议栈(protocol stack)，MSM10将在MSM10访问基于WAP互联网时协商的PPP层的选项信息传送到多媒体处理器31。然后，多媒体处理器31接收PPP层的选项信息以及将所接收的选项信息用作多媒体处理器31的PPP信息。
因此，通过MSM10，仅将通过MSM10接收的VOD数据处理至RLP层，以及通过多媒体处理器31，处理RLP层的上层的从PPP层到最高层的VOD数据。
图5示例说明根据本发明的实施例，在移动电台中处理VOD数据的方法的流程图。
在等待模式中，在步骤511中，MSM10感知是否通过键盘27选择VOD访问键或对应于VOD访问键的菜单项。
作为感知结果，当通过键盘27选择VOD访问键或对应于VOD访问键的菜单项时，在步骤512，MSM10识别它并尝试WAP访问。在这种情况下，MSM10与无线互联网执行协商以便通过基于WAP的互联网，从无线网络中的VOD服务器接收VOD数据。
现在，将参考附图，描述用于WAP访问的MSM10的PPP协商过程。
图6是示意性地示例说明根据本发明的实施例，在移动电台和无线网络间的示例性PPP协商过程的流程图。在图6的下述描述中，移动电台表示MSM10。
LCP协商过程如步骤611至616所示，验证(PAP/CHAP)过程如步骤617和618所示，以及IPCP协商过程如步骤619至623所示。
首先，在步骤611中，移动电台将用于LCP协商的“Conf_req(1)”传送到PDSN(用于无线互联网访问的分组数据服务节点)。其中“Conf_req(1)”中的数字“1”表示代表用于传输数据的序列号的ID信息。
如图7所示，用于“Conf_req(1)”帧包括第一标记字段、地址字段、控制字段、信息字段、CRC字段和第二标记字段，以及用于“Conf_req(1)”的帧最好由最多1500字节构成。每个字段具有与标准帧的字段相同的功能，将省略其详细描述。在用于PPP协商的PPP数据帧中，第一标记字段的值为“7E”，地址值为“FF”以及控制字段的值为“O3”。信息字段最好包括多个协议的一个和多个数据(IP/LCP/IPCP/PAP数据)信息的一个。因此，根据协议，IP/LCP/IPCP/PAP数据彼此不同。
如图7所示，当帧是IP帧时，IP协议为“0021”，当帧是LCP帧时，LC协议为“C021”，当帧是IPCP帧时，IPCP协议为“8021”，以及当帧是PAP帧时，PAP协议为“C023”。另外，在各个协议后的每个部分中，包括相关协议的数据。因此，通过协议信息，可以识别将包括的IP/LCP/IPCP/PAP数据的任何数据。下面，将结合IPCP和PAP协商过程的描述，详细地描述PAP/IPCP的帧。其中，应注意如参考图7所述，除具有不同协议和相关协议的数据外，用于PPP协商的数据帧(LCP、PAP/CHAP和IPCP)和用于VOD数据的PPP数据具有相同的帧结构。
在图7所示的信息字段中，如图8所示，细分除有关协议的信息外的相关协议的数据。即，相关协议的数据包括8位码信息、标识符(ID)信息、表示选项信息(类型+长度+数据或类型+长度)的16位长度信息和具有剩余位的相关协议的实际数据(诸如选项信息)。图8是表示三个LCP协商选项信息的示例视图，其中码信息是“1”以及类型信息是“2”、“7”和“8”。
现在，将更详细地描述在图8中细分的协议数据。
首先，码信息的每个数字具有下表1所示的含义。
表1
在下文中，将简单地描述如表1中所述的码号的“1”、‘2’、‘3’和‘4’的码号。码号‘1’表示在PPP协商过程的LCP协商过程中，从移动台发送到PDSN或反之亦然的数据，以及表示请求LCP协商的信号。码号‘1’上凶手 在如图6所示的‘Conf_Req(1)’、‘Conf_Rej’和‘Conf_req(2)’信号的每一个中的码号。
码号“2”表示用于在LCP协商过程中，告知移动电台或PDSN(例如接收方)正常接收从PDSN或移动电台(例如传输方)传送的数据的信号，以及应答所接收的数据。码号“2”是包括在图6所示的“Conf_Ack”中的码号。
码号“3”表示当接收方未正常地接收从传输方传送的数据或当在LCP协商过程中，接收方拒绝码号“1”的“Configure Request”时，用于请求传输方再次请求LCP协商的信号。码号“3”是与码号“2”相反的码号。
码号“4”表示用于表示在LCP协商过程中，移动电台或PDSN(例如接收方)拒绝码号“1”的“Configure Request”的信号。
ID信息是有关相关协议数据的信息以及码信息表示数据的序列号。即，号“1”的“Conf_Req(1)”和号“2”的“Conf_Req(2)”是数据的序列号。
“长度”表示数据的长度，以及“长度”信息后的选项信息包括表示用于“Configure Request”的类型的“类型”、表示对应于选项信息的数据的长度的“长度”以及用于“Configure Request”的数据。
首先，类型信息的数字的含义如下表2所示。
表2
即，类型号“1’表示包括有关能接收实际VOD数据的最大大小的睥信息。基本上，能接收1500字节的VOD数据。类型号“3”表示有关将用于验证的协议(PAP或CHAP)的信息。类型号“4”表示有关定期丢失的分组和传输八位字节的数量的信息。类型号“5”是随机选择来区分PDSNs或移动电台已经发生错误的状态的号码。即，类型号“5”表示有关服务器或移动电台的信息。类型号“7”表示有关是否能接收压缩PPP字段的信息。类型号“8”表示有关是否能接收无地址和控制字段的VOD数据帧的信息。最后，类型号“0D”表示通知相关服务器移动电台在执行验证后，想结束连接以便在另一应用中能使用它的信息。
同时，长度信息表示在LCP选项信息中，有关数据的长度的信息。即，如图8所示，在第一LCP选项信息中的长度信息包括2字节的类型信息，以及4字节的数据信息，从而包括总共6个字节，因此，表示为“06”。在第一LCP选项信息后的每个LCP选项信息的长度信息仅包括2字节的类型信息，从而表示为“02”。尽管三个LCP选项信息如图5的例子所示，应理解到，能改变LCP选项信息的数量。
在长度信息后的数据表示根据相关类型的数据。
同时，在步骤612，已经接收具有上述结构的LCP帧的“Conf_req(1)”的PDSN将告知已经正常接收“Conf_req(1)”的“Conf_Ack(码号2”传送到移动电台。相反，当在PDSN中未正常接收“Conf_req(1)”时，PDSN将“Conf_Nak”(码号3)传送到移动电台。
已经传送“Conf_req(1)”的移动电台进入步骤613，其中当LCP协商过程中有另一请求数据时，移动电台传送“Conf_req(2)”。在这种情况下，当PDSN正常接收数据时，PDSN进入步骤614，其中PDSN将“Conf_Ack”传送到移动电台。相反，当在PDSN中未正常接收数据时，PDSN传送“Conf_Nak”，从而要求重传LCP协商请求数据。
但是，在步骤615，在PDSN响应“Conf_req(1)”，将“Conf_Rej(码号4)”到移动电台的情况下，已经接收到“Conf_Rej(码号4)”的移动电台改变LCP选项信息，然后传送包括所改变的LCP选项信息的LCP协商请求数据。
当在步骤614中，移动电台接收“Conf_Ack”时，移动电台结束LCP协商过程。
尽管上面描述了在步骤611中，移动电台将“Conf_req(1)”传送到PDSN的情形，能理解到PDSN能将LCP协商请求数据传送到移动电台。
当在步骤614中，移动电台接收“Conf_Ack”后，LCP协商过程结束时，移动电台进入步骤616，其中，移动电台请求验证PDSN。
即，移动电台将“Authenticate_Req”传送到PDSN来请求验证。在步骤617中，响应验证请求，已经接收验证请求的PDSN将“Authenticate_Ack”传送到移动电台。
此后，当移动电台接收“Authenticate_Ack”时，移动电台结束验证过程，然后执行IPCP协商过程。
在步骤618，已经接收“Authenticate_Ack”的移动电台将用于IPCP协商的“IPCP_Req(1)”传送到PDSN。即，移动电台请求IP和域名系统(DSN)地址，以及PDSN响应移动电台的请求，向移动电台分配IP和DNS地址。其中，“IPCP_Req(1)”的数字“1”是表示传输数据的序列号的ID信息。
然后，在步骤619，响应“IPCP_Req(1)”，PDSN将“IPCP_Ack(码号2)”传送到移动电台。同时，在步骤623，当响应稍后所述的步骤621，将“IPCP_Ack(码号3)”从PDSN传送到移动电台时，PPP协商过程结束。相反，在PDSN中未正常接收“IPCP_Req”，PDSN将“IPCP_Nak(码号3)”传送到移动电台。
然而，在步骤620，PDSN将“Conf_Rej(码号4)”传送到移动电台的情况下，移动电台接收“Conf_Rej(码号4)”，改变IPCP选项信息，然后传送包括所改变的IPCP选项信息的IPCP协商请求数据。这些步骤同样应用于在步骤621和622中传送的“IPCP_Req(2)”和“IPCP_Req(3)”。
此后，当其他IPCP协调请求数据存在时，移动电台根据请求数据量，分别通过步骤621和622传送“IPCP_Req(2)”和“IPCP_Req(3)”。
由于该IPCP帧包括协议字段和IPCP数据字段，如图7所示，可以细分IPCP数据字段，如图9所示。如图8和9所示，LCP帧和IPCP帧具有彼此相同的结构。在下文中，将描述IPCP帧中，与LCP帧不同的码信息和类型信息，而省略其他字段的描述。
IPCP帧的码信息如表3所示。
表3
码号“1”表示在IPCP协商过程的IPCP协商过程中，从移动电台传送到PDSN或反之亦然的数据，以及表示请求LCP协商的信号。码号“1”是包括在如图6所示的“IPCP_Req(1)”、“IPCP_Req(2)”和“IPCP_Req(3)”的每一个中的码号。
码号“2”表示用于告知在IPCP协商过程中，移动电台或PDSN(例如接收方)正常接收从PDSN或移动电台(例如传输方)传送的数据以及确认所接收的数据的信号。码号“2”是包括在如图6所示的“IPCP_Ack”中的码号。
码号“3”表示在LCP协商过程中，当接收方未正常地接收从传输方传送的数据或当接收方拒绝码号“1”的“Configure Request”时，要求传输方再次请求IPCP协商的信号。码号“3”是与码号“2”相反的码号。
码号“4”表示用于通知在IPCP协商过程中，移动电台或PDSN(例如接收方)拒绝“Configure Request”的信号。
除上述码信息外，在IPCP帧和LCP帧间，还有各种不同的类型信息，如表4所示。
表4
再参考图5，在MSM10通过上述过程执行PPP协商后，在步骤513中，MSM10将PPP协商的PPP选项信息传送到多媒体处理器31。然后，多媒体处理器31将所接收的PPP选项信息用作构成用于多媒体处理器31的协议栈的最低层的PPP信息。
此后，在MSM10中，仅处理达RLP层的VOD数据，以及设置数据路径以便将VOD数据传送到多媒体处理器31。即，在步骤514中，MSM10仅处理达RLP层的VOD数据，然后，将VOD数据传送到多媒体处理器31。
表4-5其中，前向补充信道(F-SCH)支持动态建立和无限长连接，即永久连接模式，因此，针对分组数据特点，以上的前向业务信道采用了一条或两条F-SCH作为集群业务的共享业务信道。相应的，在反向业务信道采用了反向专用控制信道/反向补充信道(R-DCCH/R-SCH)，其中R-SCH可进行动态建立，每个MS可以有一到两条R-SCH信道传输反向业务数据。前向分组数据流通过共享的信道F-SCH传输，F-SCH可有一条或两条，共享信道长码掩码与上例相同，可根据组ID经过特定算法如加密算法计算得到；反向分组数据通过每用户一条的R-DCCH信道或者动态建立的R-SCH传输；F-SCH可实现软切换也可不实现，由CDMA协议的高层如应用层实现业务的连续性。
这种信道模式不仅可传输普通分组数据，也可传输业务质量(QoS)要求较高的多媒体业务流，包括分组语音，如VoIP或分组化的语音信息。
其中，集群业务逻辑信道与物理信道的对应关系也可以采用和表3-5的分配方法进行。为了适合分组数据的特性，表3-5中前向业务信道可以动电台连接到基于WAP的互联网时，MSM使用通过MSM协商的PPP选项信息，处理达PPP层的接收VOD数据，然后，多媒体处理器处理从IP层到最高层的VOD数据。相反，根据本发明的实施例，MSM处理达RLP层的接收VOD数据，然后，多媒体处理器处理从PPP层到最高层的接收VOD数据。这是因为在MSM的协议栈中的低层的占用率很低，难以在PPP层中正常地处理从低层产生的数据。
如上所述，根据本发明的移动电台的VOD数据处理方法的实施例，将PPP层设置成用于多媒体处理器的协议层的最低层，以便MSM能处理仅达RLP层的VOD数据，而VOD数据的其余协议层能在多媒体处理器中处理，从而当提供VOD服务时，能提高VOD数据处理速度。
尽管参考其某些优选实施例示出和描述了本发明，本领域的技术人员将理解到在不背离如在附加权利要求中所定义的本发明的精神和范围的情况下，可以在形式和细节方面做出各种改变。因此，本发明的范围不是由上述实施例而是由要得要求及其等效来限定。
权利要求
1.一种用于处理移动电台中的视频点播(VOD)数据的方法，所述移动电台包括用于处理多媒体数据的多媒体处理器和用于控制所述移动电台的移动电台调制解调器(MSM)，所述方法包括步骤当所述移动电台通过MSM访问无线应用协议(WAP)时，通过执行与服务器通信的协商，协商点对点协议(PPP)选项信息；将通过所述MSM协商的所述PPP选项信息传送到所述多媒体处理器；将所传送的PPP选项信息用作所述多媒体处理器的PPP信息，设置VOD数据路径；处理根据所述VOD数据路径，在所述MSM中接收的VOD数据达所述VOD数据的RLP层，然后，将所述VOD数据传送到所述多媒体处理器；以及在所述多媒体处理器中，处理从最低层的PPP层传送到所述多媒体处理器的VOD数据。
2.如权利要求1所述的方法，其中，当响应表示开始VOD服务的MSM信号，传送表示所述VOD服务可用的信号时，将所述PPP选项信息传送到所述多媒体处理器。
3.一种移动电台，包括射频单元，用于执行所述移动电台的传输和接收功能；数据处理器，包括用于编码和调制将传送的信号的发射机和用于解调和解码所接收的信号的接收机；音频处理器，用于再现从所述数据处理器输出的接收的音频信号和用于将从麦克风输出的传输音频信号传送到所述数据处理器；键盘，包括用于输入数字和字符信息的键和用于设置各种功能的功能键；存储器，包括程序存储器和数据存储器；以及多媒体处理器，用于处理通过无线网络接收的视频点播数据，其中在执行所述无线应用协议访问的同时，所述多媒体处理器接收由移动电台协商的点对点协议选项信息，然后，将所接收的点对点协议选项信息用作所述多媒体处理器的点对点协议信息。
4.如权利要求3所述的移动电台，其中，所述多媒体处理器在将点对点协议选项信息用作所述多媒体处理器的点对点协议信息的同时，所述多媒体处理器形成用于处理由所述移动电台调制解调器的无线链路协议处理的视频点播数据的上层，以及根据每个层，通过所述视频点播数据的解封装过程，处理所述视频点播数据。
5.一种用在移动电台中处理在执行VOD服务时通过无线网络接收的VOD数据的多媒体处理器，所述多媒体处理器被编程为在执行用于移动电台的无线应用协议(WAP)访问时，接收由移动电台调制解调器(MSM)协商的点对点协议(PPP)选项信息，以便将所接收的PPP选项信息用作用于所述多媒体处理器的PPP信息，形成包括IP、TCP/UDP、套接层和RTP/RTCP/RTSP/HTTP层的上层，用于处理VOD数据，以及根据每个层，经解封装VOD数据，处理所述VOD数据。
6.如权利要求5所述的多媒体处理器，其中，所述多媒体处理器进一步编程来封装从最高协议层到最低协议层的对应于从所述MSM接收的VOD数据的传输数据，以将所述传输数据传送到所述MSM。
7.如权利要求5所述的多媒体处理器，其中，所述多媒体处理器可用来将包括所述PPP层的协议栈用作其最低层，以及IP层、TCP/UDP层、套接层和RTP/RTCP/RTSP/HTTP层顺序地层叠在PPP层上。
8.如权利要求7所述的多媒体处理器，其中，所述MSM可用来将包括物理层的协议栈用作其最低层，然后，无线链路协议(RLP)层、点对点协议(PPP)层、网际协议(IP)层、传输控制协议/用户数据报协议(TCP/UDP)层、套接层和无线应用协议(WAP)作为其最高层，所述MSM根据每个层解封装所接收的数据，以及通过所述WAP层，将所接收的数据传送到应用程序，所述MSM用来传送所述PPP层的PPP选项信息，以允许所述多媒体处理器接收所述PPP层的选项信息以及将所接收的选项信息用作所述多媒体处理器的PPP信息，从而允许由所述MSM仅处理达所述RLP层的通过所述MSM接收的VOD数据以及由所述多媒体处理器处理从所述PPP层到最高层的VOD数据。
9.一种用在移动电台中，处理所述VOD数据的移动电台调制解调器(MSM)，所述MSM用来当用户请求通过VOD服务器访问时，通过传送PPP选项信息设置和有关从由IP、TCP/UDP和套接协议组成的组选择的上层协议的信息，控制所述移动电台，所述MSM用来传送通过在执行WAP访问时，执行PPP协商时设置的PPP选项信息，所述MSM通过WAP访问连接到其上的多媒体处理器，形成有关上层协议的信息。
10.如权利要求9所述的MSM，其中，所述MSM配置成根据在所述多媒体处理器接收的VOD数据，接收从所述多媒体处理器输出的传输数据，以及将所接收的传输数据传送到VOD服务器。
全文摘要
公开了一种用于处理移动电台中的VOD数据的方法，移动电台包括多媒体处理器和用于控制移动电台的MSM，该方法包括步骤当移动电台通过MSM访问WAP时，通过执行用于与服务器通信的PPP协商，协商PPP选项信息；将通过MSM协商的PPP选项信息传送到多媒体处理器；将所传送的PPP选项信息用作多媒体处理器的PPP信息，设置VOD数据路径；处理根据VOD数据路径，在MSM中接收的VOD数据达VOD数据的RLP层，然后，将VOD数据传送到多媒体处理器；以及在多媒体处理器中，处理来自最低层的PPP层、传送到多媒体处理器的VOD数据。
文档编号H04N7/173GK1642271SQ200510005730
公开日2005年7月20日 申请日期2005年1月17日 优先权日2004年1月17日
发明者赵贤昱, 朴大圭, 孙载坤, 金彊郁 申请人:三星电子株式会社