PDF移动媒体 使其成为现实
两个原型应用程序揭示了交付移动媒体服务方面的挑战。
FRED KITSON，惠普实验室
许多未来的移动应用都基于丰富、交互式媒体服务的存在。此类服务的承诺和挑战是在最恶劣的条件下，以低成本向期望高的用户群体提供应用。情境感知服务需要了解用户是谁、在哪里、何时以及在做什么的信息，并且必须及时、以最小的延迟交付。本文揭示了一些当前最先进的“魔力”和研究挑战。
在我们的研究中，我们正在结合媒体系统和移动系统，以支持为移动或游牧用户创建、分发和消费丰富的媒体。在本文中，我们提出了未来应用的两种愿景。第一个是利用 RFID 技术的个人情境感知移动服务的示例。第二个是高度协作的交互式移动游戏系统。这个例子尤其突出了我们在开发原型时遇到的一些关键技术挑战。然后，我们重点关注需要解决的一些更广泛的系统和软件问题，以充分实现商业上可行的移动媒体系统。特别是，我们总结了在任何地方获取媒体、在任何地方创建媒体以及在任何地方安全交付媒体的复杂性。
指尖上的世界
我们许多人都想象过一个物体内容丰富、互动性强并提供个性化信息的世界。但是问题很多：关于物体的信息在哪里？我们如何将内容传递给所述物体？如何确保内容与消费者相关（例如，我与我的祖母）？如何授权用户，以便他们可以决定他们希望体验什么内容？
考虑以下示例：您走进一家电影院观看电影。当您穿过大厅时，您注意到一张即将上映的电影海报，您想了解更多信息。您走到海报前，注意到它有一个“触摸此处”标签。您用手机触摸标签，立即收到电影的视频预览，并有机会预订首映之夜的票。
这种情况离现实并不遥远。当前的三项技术发展使这成为可能
- 普及的无线网络（例如，Wi-Fi 热点、蜂窝 3G/GPRS）
- “智能”无线设备（手机或 PDA）的广泛普及
- 廉价的、可嵌入的无线 RFID 标签
最后一种技术发展，嵌入式标签，是实现这一愿景的关键。RFID 标签正在迅速获得广泛的行业认可。1 RFID 的一个简单版本已在零售环境中使用多年，以限制“损耗”（读作：商店盗窃）。随着技术的进步，已经开始大力推动在供应链管理中使用 RFID 标签。2 这两种应用都使用远场 RFID 技术，其中标签可以在两到四米的距离内读取。
RFID 技术的另一种变体是近场，其中标签和读取器必须非常靠近，通常为两厘米或更小。标签也小得多。近场 RFID 标签最常见的实现是“门禁卡”，许多组织使用它来控制对其设施的访问。
进入 inHand
在惠普，我们希望利用 RFID 和其他无线技术开发我们自己的平台，以提供丰富的媒体体验。进入 inHand 平台。inHand 的消费者端由一个移动设备（iPAQ PDA）组成，该设备增强了近场 RFID 读取器/写入器，以及一个将读取器/写入器连接到 Web 浏览器和其他在 PDA 上显示内容的应用程序的小型应用程序。这提供了一个直观的触摸使用界面，在物理单词标记的对象上显示虚拟信息。
繁重的工作发生在后端，后端由三个主要组件组成，如图 1 所示：一个将标签 ID 映射到 URL 的解析器；一个标签应用程序管理器，用于确定要提供的内容及其自定义；以及一个用户配置文件数据库。
回到我们的交互式电影海报示例，“触摸此处”标签背后的“魔力”是 RFID 标签。将移动设备靠近 RFID 标签允许移动设备中的读取器读取标签的内容。通常，由于内存有限，标签将被编程为包含产品制造商代码、产品代码和序列号。
然后，客户端将标签数据和移动设备标识发送到指定的服务器。后一个数据至关重要，因为识别谁在读取标签对于提供定制内容至关重要。
客户端将标签 ID 和用户 ID 发送到后端服务器，以便将 ID 映射到为该特定用户定制的产品或服务。后端服务器的主机名配置在客户端中。GPRS 或 802.11 无线数据连接将客户端连接到后端服务器。
解析器在数据库中查找标签 ID，以找到品牌和适当的内容。用户 ID 用于查找用户配置文件。将两者结合起来即可获得个性化内容。个性化可以是简单的问候文本替换（“嗨，迈克”）、区域化内容或为唯一用户量身定制的唯一消息。内容可以是 Flash、HTML、视频、音乐、音频或任何其他数字内容。用户的系统交互也被记录下来（如果获得许可），以便可以将有关消费者的信息用于内容定制。
在电影海报示例中，标签应用程序管理器通过立即发送电影的流媒体视频预览来响应。您可以因触摸几个不同的标签（在相同或其他电影海报上）或因使用特殊的会员专享预览或优惠券购买特许商品而获得奖励。
在后端，原始事件（标签滑动和设备/用户标识符）既用于选择适当的内容模板，又用于自定义它。此选择可以像直接查找一样简单，也可以涉及应用业务逻辑以根据过去的用户交互来更改模板选择。为了支持此选择过程，之前的交互存储在数据库中，并且可以查询以确定重复或相关的标签滑动，以及该用户的过去导航模式。
选择内容模板后，将使用上下文信息实例化它。此信息再次从数据库中提取，可能包括用户个性化、相关内容和以前的导航模式。模板在后端以适合显示设备和传输容量的形式呈现，并返回到请求设备。此外，内容中的导航链接（如果有）是为该特定用户、设备和当前传输机制量身定制的。后端使用 MySQL 数据库、Apache Web 服务器和 PHP 脚本实现，在 Linux 服务器上运行。
inhand 的挑战
从技术角度来看，InHand 可能听起来很简单，但我们在其他方面遇到了很多挑战。以下是我们遇到的一些困难。
为小型显示器创建情境感知内容是一项新技能。我们与多个品牌合作，每次他们的本能都是将他们的内容从 Web 移动到手持格式。内容需要精确且切中要点——从而产生俳句风格。广告商更习惯于吸引人们关注品牌，而不习惯于创建针对特定用户配置文件和产品的内容。
由于可能存在无数标签，因此管理标签与产品的解析和关联非常复杂。在某些情况下，标签应与品牌关联，而在其他情况下，应与品牌中的一条线甚至产品的特定实例关联。标签不是顺序编号的，这需要手动过程来使用标签对后端进行编程。
确定如何有效利用用户配置文件数据是一个挑战。对于每个标签解析，都需要执行一个小的用户配置文件引擎，并确定如何自定义此标签。如何区分我和我的祖母？或者用营销术语来说，如何根据用户的行为对用户进行细分？如果我拿起一包热狗，很容易提醒我买面包，但这对我购买汽车的偏好意味着什么？
移动多人互动游戏
最具吸引力但技术要求最高的移动媒体服务之一是支持互动多人移动游戏。为了应对这类新的移动应用程序，我们希望为第三代移动网络提供一个具有多人游戏服务环境的平台。我们还希望为情境感知游戏和应用程序设计系统。
这样的基础设施将很容易在性能和规模方面拥有资源，以适应应用程序开发人员将设想的许多要求较低的移动服务。此外，交互式游戏应用程序不仅需要支持玩家之间游戏状态的及时分发，还需要支持增强整体游戏和社区体验的服务，例如大厅、聊天和语音通信。人们常说，好的多人游戏，玩家“为行动而来，为彼此停留”。本质上，促进社区交流的多人游戏往往会产生游戏忠诚度。因此，我们认为启用这种类型的社区体验是我们游戏平台的必要要求。然而，很少有人在没有尝试或先观看其他人玩游戏的情况下直接加入游戏社区。因此，我们希望提供一种方法，让潜在的游戏玩家可以观察经验丰富的玩家玩游戏。
我们不仅希望开发一个满足交付这些移动多人和情境感知游戏挑战的系统，而且还希望以这样一种方式构建它，使开发人员与移动网络实现的细节隔离。这使他们能够专注于实际的游戏设计和逻辑，并为他们提供开发丰富的社区互动和引人入胜的游戏体验所需的独特移动服务。为此，我们还希望通过遵守此应用程序开发领域中正在兴起的互操作性标准，使我们的平台对开发人员具有吸引力。
MGSP 游戏平台
我们将我们的游戏平台命名为多人游戏服务平台 (MGSP)。从架构上讲，它位于 3G 移动网络的包网络服务基础设施内。它旨在利用 IMS（IP 多媒体子系统）基础设施功能来控制实时和非实时富数据服务，例如视频、会议、游戏、流媒体和消息传递在同一 IP 传输网络上（图 2）。它为基于 IP 的多媒体应用程序提供安全的基础设施。因此，3G 移动游戏应用程序可以使用 MGSP 网关服务和 API 提供的框架与 3G IMS 核心进行交互。这种抽象将游戏服务逻辑与底层网络功能和协议隔离开来。
这使 MGSP 能够访问所有必要的底层网络服务——例如，游戏会话管理功能，如注册和路由、用户身份验证、QoS（服务质量）支持、存在和位置。在游戏过程中，该服务通过其 QoS 管理器进程及其与核心网络的接口，管理富媒体游戏元素的适当 QoS 分配。这确保了网络功能范围内实时和非实时多人游戏的正确体验。
为了解决移动游戏群组通信的需求，我们转向了 PTT/PoC（一键通/蜂窝一键通）和 VoIP 等技术。典型的模型涉及一组玩家发起群组会议。我们对该模型的实现包括游戏服务大厅和 MRF（媒体资源功能）。我们使用 Opencall 媒体平台的 MRF 功能，该平台包含适用于移动音频会议的 softDSP 媒体混合功能。此外，结合实际的游戏状态和会议状态会产生有趣的情境感知会议模型。通过 MGSP 向游戏服务器提供对网络内会议控制功能的访问，可以实现动态的与游戏相关的会议。例如，随着玩家位置在游戏中更新，将在同地玩家之间创建动态会议。玩家可以通过 softDSP 媒体处理器实现额外的游戏音频效果。
被动玩家的普遍访问
MGSP 还提供了一种工具，允许任何用户通过流媒体媒体到移动终端来查看近乎实时的多人游戏动作。这种交互模式不仅对休闲游戏玩家和新手以被动方式熟悉游戏很有用，而且对于任何仅配备移动媒体播放器的用户来说，也可以通过这种方式访问游戏世界。在观察者模式下，玩家选择查看另一个活跃玩家头像的摄像头。此模式与具有流式音频/视频输出通道的网络端客户端结合使用。然而，流式数据是使用帧缓冲区中的原始合成游戏图像数据优化的。
流式观察者模式为任何拥有移动媒体播放器的人提供了一种机制，可以在不需要客户端代码下载的情况下查看特定游戏（或跟踪持久世界游戏中特定游戏英雄的冒险经历）。由于流式视频的定时要求较低，因此游戏服务平台可以将图形渲染转移到观察者视图 MRF（移动渲染功能），如图 3 所示。3D 图形渲染器提供渲染帧以及附加信息，这些信息用于增强最终的移动兼容视频输出。例如，3D 场景的深度值可用于为更靠近观看者的对象提供增强的分辨率。我们预计“观察者”甚至可能比“玩家”更多，因此可扩展性而不是延迟是问题所在。
MGSP 为游戏客户端和服务器分别提供了用于多人游戏会话管理的 API。在这方面，与适当标准保持一致是我们平台成功采用的重要因素。在标准化机构内，OMA（开放移动联盟）游戏服务工作组的任务是为网络支持的游戏创建互操作性规范、API 和协议。因此，OMA 代表了 MGSP 的标准化参考。
mgs 的挑战
与 inHand 一样，MGSP 的某些方面似乎很容易实现——但实现再次揭示了重大挑战。在这种情况下，最大的挑战更具技术性。我们发现以下领域尤其值得注意。
IP 包传输在 3G 蜂窝网络上的一个众所周知的特性是由于链路层执行的重传和交织以对抗时变无线信道中的丢失而导致的长传输延迟。某些类型的多人游戏是快节奏的“抽搐”游戏，并且尝试在移动包网络环境中提供此类游戏目前超出了挑战——这根本不可能。通常，为了获得良好的游戏体验，这种类型需要总 ping（往返）时间少于 200 毫秒。当将此数据与实际 ping 测试数据进行比较时，UMTS（通用移动通信系统）网络上的平均延迟约为 350 毫秒，问题显而易见。
这使我们注意到移动游戏应用程序的实际传输要求以及 UDP 和 TCP 的适用性问题。我们认为 UDP 不适用，因为它不提供可靠性。TCP 不适用于无线游戏应用程序，因为它具有持久的重传和拥塞控制机制。我们的方法是分析游戏应用程序的实际传输要求，并设计一种针对此类应用程序在 UMTS 无线链路上的优化协议。此外，虽然当前的 IP 服务是“尽力而为”的，但 3GPP（第三代合作伙伴项目）规范提供了无线电资源预留的流量类别，其中包括延迟容错会话类，目标延迟小于 250 毫秒。这种流量类别将适用于近实时移动多人游戏应用程序。运营商是否真会实施这种 QoS 机制还有待观察。
另一个主要挑战是游戏服务用户界面的实现。具体来说，这些移动设备包含存在和服务组列表等服务的客户端。这就提出了一个问题，即一个人应该能够通过好友列表客户端应用程序还是仅通过游戏大厅客户端来查看另一个人的游戏状态。游戏世界中的人有各种身份或“句柄”，这些身份或“句柄”与其在存在和服务组列表服务中维护的真实世界身份不符。此外，玩家可以在不同的游戏实例中采用不同的身份。对于初始设计，我们决定使用客户端游戏大厅应用程序作为确定游戏好友状态的唯一手段。然而，在当前的项目（昵称 Wormhole）中，我们计划提供从游戏世界存在和服务组服务到真实世界存在和组列表服务的映射接口。
在与聊天等其他游戏服务相关的问题中也出现了类似的问题。此类服务应该仅在游戏应用程序外部提供（例如，在大厅应用程序中）还是直接集成在游戏中？我们认为后者有可能使游戏开发人员能够通过内置聊天、VoIP、流媒体音乐等来区分他们的移动游戏应用程序，并为移动游戏玩家提供更引人入胜的体验。
媒体创建、交付和安全方面的挑战
即使关键的后端内容交付元素已到位，从媒体通信的角度来看，仍然存在许多技术挑战。接下来，我们将讨论充分实现此类移动媒体系统的三个关键技术挑战领域。第一个是在网络中推送或拉取媒体的能力，这需要有线和无线协议，以支持实时和低成本的各种内容。第二个涉及从用户处获取媒体或内容。最后，我们提出了一个对这些服务的成功和采用至关重要的问题：端到端安全。
在任何地方获取媒体
在任何地方访问媒体的关键方面都涉及具有 WAN 连接，例如，由 2.5G 或 3G 蜂窝网络提供，并由新兴的 802.11 网络补充。虽然最终用户可以看到手机技术的快速进步，但许多用于将媒体流传输到手机的关键推动因素是隐藏的，并且涉及用于媒体交付的新型基于数据包的基础设施的设计和部署。出现了许多挑战，包括确保不同制造商生产的基础设施和设备之间的互操作性。3 3GPP 正在指定一组标准及其用途（例如，MPEG 压缩标准和 IETF 传输协议），用于通过 3G 网络进行媒体交付。4
提供在许多地点（例如，在当地咖啡店、机场、飞机、火车或其他人们可能聚集的地方）获取内容的能力是困难的。挑战包括提供广泛的内容选择、快速响应时间和成本。例如，内容应本地缓存；否则，每次请求特定信息时，都将在网络上发送其新副本，从而导致不必要的带宽成本。缓存的另一个动机是，我们希望提供此服务的位置可能没有足够大的宽带连接（与请求的内容大小相比），这可能会导致传输大型媒体对象时出现相当大的延迟。
出现的另一个问题是：缓存什么？媒体缓存比 Web 缓存更困难，因为媒体对象的大小和时间维度。由于 Web 对象很小（数十千字节），因此可以轻松地完整缓存它们，而媒体对象要大得多（兆字节到千兆字节），即使是少量的媒体对象也可能很快填满可用的缓存空间。此外，媒体对象通常不会被完整消费。例如，许多人在决定完整观看单个视频之前，仅观看许多音乐视频的前 10 到 20 秒。同样，人们通常只想观看足球比赛中进球发生的部分，而不是整个两小时的比赛。
消费模式的这些差异对媒体缓存系统的设计产生了重大影响。例如，通过自动识别和仅缓存媒体内容的最常请求的片段（而不是整个内容），我们可以显着提高性能，同时仅使用原本所需存储空间的一小部分。这个概念上简单的想法在实践中具有挑战性，因为压缩视频和音频以标准文件格式（例如，MP4 或 3GPP）存储的方式与媒体内容的自然时间顺序相比非常复杂。
在任何地方创建媒体
今天的技术使普通人可以创建内容并与他人分享。例如，最新的 PDA 包括集成的图像/视频摄像头，并且能够执行实时视频捕获、MPEG-4 编码和以 MP4 文件格式存储，以及用于共享捕获内容的 802.11 无线。下一代支持视频的 PDA 将具有增强的视频捕获和编码功能，包括更高的空间分辨率和更高的帧速率，以及 802.11 和蜂窝网络连接，并且它们将支持符合标准的流媒体到基础设施中。然后，基础设施可以存储内容并根据需要共享内容。随着创建内容能力的增强，随之而来的是如何索引、搜索和检索此内容的问题。
另一个挑战与使用 802.11 连接的 PDA 启用 VoIP 或可视电话等会话服务有关。这是一个问题，因为 802.11 可能会受到数百毫秒延迟的影响，从而使会话服务无法接受。新的 802.11e 标准以及正在开发的其他技术可能有助于缓解这些问题。安全的端到端媒体交付
媒体交付系统可能需要将媒体流交付给具有不同设备功能（例如，屏幕显示尺寸、计算或内存资源）和连接质量（例如，可用带宽）的不同客户端。这可能需要中间网络节点或代理执行流适配或转码，以使流适应下游客户端功能和时变网络条件。
另一个重要的属性是安全性，以保护内容免受窃听者的侵害。这使得有必要以加密形式传输流。然而，在适应下游条件的同时提供安全性问题对于移动无线客户端尤为突出，因为可用带宽可能是高度动态的，并且无线通信使得传输极易受到窃听者的攻击。
解决此问题的传统方法是解密流、转码解密后的流，然后重新加密结果。然而，这构成了严重的安全威胁，因为它需要向转码器提供密钥，然后解密内容。出现的一个挑战是如何在中间进行转码，同时保持端到端安全。媒体应在发送者处加密，仅在接收者处解密——并在两者之间的所有点保持加密。我们将此功能称为安全转码，以强调转码是在不需要解密的情况下执行的，从而保持了端到端安全。
通过使用称为 SSS（安全可扩展流媒体）的框架共同设计压缩、加密和数据包化，可以实现安全转码的期望功能。5 图 4 显示了一个场景，其中发送者将加密内容传输到中间网络节点或代理，该节点或代理执行安全转码操作，以使接收到的受保护数据适应三个客户端中的每一个：一个具有低带宽，一个具有中等带宽，另一个具有高带宽。中间网络节点执行安全转码（无需解密的转码），因此保持了端到端安全。实际上，转码是在加密域中执行的。请注意，加密密钥仅对发送者和接收客户端可用，而对执行安全转码操作的中间网络节点不可用。
从概念上讲，安全转码的工作原理是使中间网络节点能够智能地丢弃不太重要的信息，同时仍然使剩余的更重要的信息能够被接收者解密和解码。此功能是通过共同设计的编码、加密和数据包化实现的。由于转码是通过丢弃信息来执行的，而无需解密，因此保持了端到端安全。为简单起见，本讨论重点关注了机密性安全服务（由加密提供）；SSS 框架还支持其他安全服务，例如身份验证和数字签名。这项技术正在纳入 JPEG-2000 安全 (JPSEC) 标准。6
路上的乐趣
我们介绍了一些新的移动媒体前沿示例，以及构成我们愿景基础的研究系统和技术。我们相信未来包括基于用户将需要适合相当受限外形尺寸的简单自然界面的概念的“路上的乐趣”。此类服务也可以通过非移动界面（例如信息亭或等离子显示器）交付给移动用户，但仍然需要为在旅途中的人们提供可理解的使用模型。因此，鉴于用户通常随身携带他们的“界面工具”（例如眼睛、耳朵和嘴巴），并且对通信和娱乐充满热情，移动媒体服务似乎是必不可少的。本文中说明的应用程序——即，互动游戏、视频和音频通信以及个性化的情境感知活动（如购物或看电影）——都将通过这些移动服务得到增强并变得更加愉快。
参考文献
- Want, R. 2004. RFID 的魔力。 2(7): 41-48。
- Beckett, J. 2004. 供应链中的 RFID 和传感：挑战和机遇。 http://www.hpl.hp.com/news/2004/apr-jun/rfid.html。
- Wee, S. J., Apostolopoulos, J. G., Roy, S., 和 Tan, W. 2003. 移动流媒体媒体内容交付网络 (MSM-CDN) 的研究和设计。IEEE ICME（7 月）。 http://www.hpl.hp.com/techreports/2003/HPL-2003-77.html。
- www.3gpp.org.
- Wee, S. J., 和 Apostolopoulos, J. G. 2001. 安全可扩展流媒体支持无需解密的转码。IEEE ICIP（10 月）。
- ISO/IEC JPEG-2000 安全 (JPSEC)，最终委员会草案。2004 年 11 月。
致谢
本文是在惠普实验室的 John Apostolopoulos、Nina Bhatti、Nic Lyons、Shinya Nakagawa、John Schettino 和 Michael Sweeney 的贡献下编写的。
FREDERICK LEE KITSON 是惠普公司研究实验室的高级主管，他在那里负责全球移动和媒体系统的研究。他的技术专长领域包括移动系统、计算机系统、消费类电器以及多媒体数字信号处理、通信和计算机图形等特定技术。他还负责惠普参与麻省理工学院的“氧气”普及计算项目，以及多项研究合作，尤其是在亚洲，例如与 NTT DoCoMo 就第四代移动系统进行的合作。Kitson 获得了特拉华大学电气工程学士学位、佐治亚理工学院 M.S.E.E. 学位以及科罗拉多大学电气和计算机工程博士学位。他是佐治亚理工学院的兼职教师，并在加州大学伯克利分校和科罗拉多州立大学任教。
最初发表于 Queue vol. 3, no. 4—
在 数字图书馆 中评论本文
更多相关文章
Andre Charland, Brian LeRoux - 移动应用程序开发：Web 与原生
几年前，大多数移动设备，如果用一个更好的词来形容，就是“哑巴”。当然，有一些早期的智能手机，但它们要么完全专注于电子邮件，要么缺乏可以不用手写笔使用的复杂触摸屏。即使是更少的智能手机也配备了像样的移动浏览器，能够显示简单的文本、链接，甚至可能是一张图像。这意味着，如果您拥有这些设备之一，那么您要么是沉迷于电子邮件的商务人士，要么是希望今年将成为智能手机年的 Alpha 极客。
Stephen Johnson - 茶杯中的 Java
鲜有技术领域能像无线行业一样发展如此迅速。随着市场和设备的成熟，对移动应用的需求（和潜力）也在增长。越来越多的移动设备预装了 Java 平台，使得大量的 Java 程序员可以尝试嵌入式编程。然而，并非所有的 Java 移动设备都是相同的，这给新的 J2ME（Java 2 平台，微型版）程序员带来了许多挑战。本文使用一个示例游戏应用程序，说明了与 J2ME 和蓝牙编程相关的一些挑战。
- 流媒体与标准：交付移动视频
不相信我？请继续阅读… 移动电话无处不在。每个人都有一部。想想你上次乘坐飞机，航班在地面延误的情景。在可怕的通知之后，你立刻听到每个人都拿起手机开始拨号。
Bruce Zenel - 企业级无线
我们以各种形式在无线领域工作了超过 10 年，并参与了其成熟过程的每个阶段。我们见证了无线技术从互联网泡沫之前的玩具技术，到泡沫期间真正有前景的技术，再到泡沫破裂后令人失望的技术，当时人们发现该技术尚未为黄金时期做好准备。幸运的是，现在看来我们终于达到了技术和企业期望最终融合的程度。
© 保留所有权利。