Enabling Technologies for Wireless E-Business phần 8 pps

1 1. 3 .4 Arch i tecture MMS is an a pp lication-leve l service that fits into t h e current WAP architecture. T he basic concept of sending an MMS message is exactly t h e same as that o f SMS. T h e or igi nator a dd resses t h e rece i ver, t h e messa g e i s f i rst sent to t h e MMS center ( MMSC ) assoc i ate d w i t h t h at rece i ver, t h en t h e MM SC i nforms t h e rece i ver an d attempts to forwar d t h e messa g e to t h e rece i ver. If t h e rece i ver i s unreac h a bl e, MMSC stores the messa g e for some time, and if possible, delivers the messa g e all y discarded. In fact, it is a much more complicated process. To enable this Mobile Net w o r k B MM S Se rv er M M SC Ho m e L ocatio n R e gi ster M M S VA S Appli cat i on s P ost P rocess i n g Sy stem E x te rn al S erve r Roamin g MM S U ser Agen t Wireled E-mail Client M M 5 M M8 MM7 MM 6 MM4 M M 3 MM2 MM1 MMS Rela y MM S Use r Data B ase I n te rn et / IP N et w o rk 2 G / 3G M ob il e N etwork A M essa ge Stor e M M SE M MS User Agen t Online Charging S ystem MM 9 Fi g . 11. 6 . MMS architectural elements T he whole MMS environment (MMSE) encompasses all necessar y service elements for delivery, storage, and notification. The elements can be located w ithin one network, or across several ne t works or network types. In the case of t t roaming, the visited network is consider e d a p art of that user’s MMSE. However, s u b scr ib ers to anot h er serv i ce prov id er are cons id ere d to b e a part of a separate M M S E . Th e MMS re l ay an d MMS server may b e a s i ng l e l og i ca l e l ement or may b e s eparate. T h ese can b e di str ib ute d across di fferent d oma i ns. T h e com bi nat i on of t h e MMS re l a y/ server i s t h e MMSC. It i s i n c h ar g e of stor i n g an d h an dli n g later. If the message cannot be delivered within a certain time frame , it is eventu- Y. Yang and R. Yan266 service, a set of network elements is organized as shown in Fig. 11.6 [[14]] . 26 7 among different messaging systems. It should be able to generate charging data f or MMS an d VAS prov id er-re l ate d operat i ons. MM S user d ata b ase conta i ns u ser-re l ate d i nformat i on suc h as su b scr i pt i on an d conf i gurat i on. M MS user a g ent is an application la y er function that provides the users with the abilit y to view, compose, an d h andle multimedia messa g es. It r es i des o n th e user e q ui p ment (UE) or on an external device connected to the UE or MS. M MS VAS a pp lications p rovide VAS to MMS users. They can be seen as fixed M MS user agents but with some addi t ional features like multimedia message r ecall between MMS VAS a pp lications a n d MMSC. MMS VAS a pp lications sh ou ld b e a bl e to gen e rate t h e c h arg i ng d ata w h en rece i v i ng / su b m i tt i ng mu l t i me di a messages from / to MMSC. External servers ma y be included wit h i n, or connected to, an MMSE, e. g ., e-mail server, SMSC, and fax. MMSC would inte g rate different server t y pes ac r oss d iff e r e nt n e t wo rk s an d provide conver g ence functionalit y between external s ervers and MMS user agents. M M1 is the reference point between the MMS user agent and the MMSC. It is use d to su b m i t mu l t i me di a messages from MMS user agent to MMSC, to l et t h e M MS user agent pu ll mu l t i me di a messages from t h e MMSC, l et t h e MMSC pus h i nformat i on a b out mu l t i me di a messages to t h e MMS user Agent as a part of a multimedia messa g e notification, and to e xchan g e deliver y reports between M MSC an d MMS user a g ent. M M2 i s t h e reference p o i nt b etween t h e MMS re l a y an d t h e MMS server. Mos t M MS solutions offer a combined MMS relay and MMS server as a whole MMSC. This interface has not been s p ecified till now. M M3 is the reference p oint b e t ween the MMSC and external messaging sys - MMSC. To prov id e f l ex ibl e i mp l ementat i on of i ntegrat i on of ex i st i ng an d new f ramework the MMSC communicates with both MMS user a g ent and external s ervers. It can p rovide con v er g ence functionalit y b e t wee n e xt e rnal se r ve r s an d MMS user a g ents, and thus ena b l es the inte g ration of different server t y pes across di fferent networ k s. M M4 i s t h e reference po i nt b etween t h e MMSC an d anot h er MMSC t h at i s w i t hi n anot h er MMSE. It i s i n c h arge of transferr i ng messages b etween MMSCs b e l on gi n g to di fferent MMSEs. Interwor ki n g b etween MMSCs w ill b e b ase d on 11 Mo bil e C onten t De li ver y Tec h no l o gi es MM5 i s t h e reference po i nt b etween t h e MMSC an d t h e HLR. It may b e use d t o provide information to the MMSC a b out the subscriber to the MMSC. i ncom i n g/ out g o i n g messa g es an d i s respons ibl e for t h e transfer of messa g es tems. It i s use d by t h e MMSC to sen d / retr i eve mu l t i me di a messa g e s t o/ fr o m se r - vers of externa l messa gi n g s y stems t h at are co nn ec t ed t o t he se r vice prov id er’s t he MMS makes use of the p rotocol f ramework depicted in Fi g . 11.7. In this In MMSE, elements communicate via a set of interfaces [14]. services together with interoperability across different networks and terminals [14], SMTP according to IETF STD 10 (RFC2821) [15] shown in Fig. 11.8. MMS Use r A gent M M1 Trans f er P r otocol M M1 Trans f er P r otocol M M 3 Tr a n s f e r P rotoco l M M 3 Tr a n s f e r P rotoco l Lower La y er A Lower La y er A L ower La y er B L ower La y er B e.g. TCP/UD P e.g. TCP/UDP E xterna l S erver MM S C a p abl e UE/M S M M SE M M1 MM 3 MS C MM M P rotocol tlements necessar y in the terminal P rotocol tlements necessar y in the MM S E Additional protocol elements necessary to include external servers Fig. 11. 7 . Protocol framework to p rovide MMS M M S Use r Ag ent A MM S User Ag ent B M M SC A MM SC B S MTP MM 1 MM 1 MM4 M M SE S ervice Provider A M M SE S ervice Provider B F i g . 11 . 8 . Interworkin g of different MMSEs M M6 is the reference p oint between the MMSC and the MMS user database. M M7 is the reference p oint between the MMSC and the MMS VAS a pp lica- tions. It allows multimedia messages transferring from/to MMSC to/from MMS M M8 i s t h e reference p o in t b etween MMSC an d t h e postprocess i ng system. I t is needed when transfering MMS-specific CDRs from MMSC to the operators in th e postprocess i ng system. MM9 i s t h e reference po i nt b etween MMSC a n d on li ne c h arg i ng system. It i s u se d to transfer c h ar gi n g messa g es from MMSC to t h e on li ne c h ar gi n g s y stem. Y. Yang and R. Yan268 VAS applications. This interface will be based on SOAP 1.1 [16] and SOAP mes- sages with attachments [17] using an HTTP transport layer. 269 1 1. 3 . 5 Transact i ons T here are four typical MMS transactions: • M obile-originate d (MO) transactio n i s originated by an MS. The multi- m e di a messages are sent di rect l y to an MS or poss ibl y to an e-ma il a dd ress. If some sort of process i ng / convers i on i s nee d e d , t h e mu l t i me di a • M obile-terminate d ( MT ) transaction sends the messa g es to an MS. The originator of such messages can be a nother MS or an application. a a • A pplication originate d (AO) transactio n is originated by an application and terminated directly an MS or a n other a pp lication. Before the multi- m e di a messa g es are sent to t h e d est i nat i on, t h e y can b e processe d i n one or more app li cat i ons. • A pplication-terminated (AT) transaction i s term i nate d at an app li cat i on and ori g inated b y an MS or anothe r a pp lication. As noted in MO transac- t ion, the multimedia messa g es can be sen t to an a pp lication that does the processin g /conversion, so it is actuall y an AT transaction. Based on these four types of transactions, transactions for each interface are re - a lized that can be described in terms of abstract messages. The abstract messages c an be categorized into transactions c onsisting of “re q uests” and “res p onses.” To l a b e l t h e a b stract messa g e, t h e tra n sact i ons for a certa i n i nterface are pref i xe d by i ts name, e. g ., t h e tra n s a c t io n s f o r MM1 ar e p ref i xe d w i t h “MM1.” Bes id es, “requests” are id ent i f i e d w i t h “.REQ” as a suff i x an d “responses” are id ent i f i e d with the “.RES” suffix. E ach abstract messa g e carries certain IEs, which ma y var y accordin g to the spe - c ific message. All messages carry a protocol version and message type, so that the MMSE components are able to properly identify and manage the message contents. T he mapping of abstract messages to specific protocols is not necessarily a one-to- o ne re l at i ons hi p. Depen di ng on t h e MMS WAP i mp l ementat i on, one or more ab stract messages may b e mappe d to a s i ng l e l ower l ayer PDU an d v i ce versa. T h e following clause uses MM1 WAP im plementation for further discussion. m m 11.3.6 WAP Im p lementation of MM1 As noted earlier, WAP addresses the p rotocol im p lementation of the p articular i nterface. Now, MMS activities of the WAP Forum have been inte g rated to OMA. T here are two different confi g urations of the WAP architecture and protocol 1 1 Mo bil e C onten t D e li very Tec h no l og i es m essages are f i rst are sent to an app li cat i on t h at d oes t h e process i ng / convers i on, an d t h en to t h e d est i nat i on. stacks for im p lementation of MMS as s hown in Fig. 11.9 and Fig. 11.10. F i g . 11 . 9 . Im p lementation of MM1 inte r f ace usin g WAP 1.x g atewa y normally transferred using a wireless trans p ort such as WSP. T he second lin k connects the WAP gateway and the MMSC. In the WAP architecture the MMSC i s cons id ere d as or i g i n server. Messages trans i t over HTTP from t h e WAP gate- way to t h e MMSC. T h e WAP gateway p rov id es a common set of serv i ces over a var i ety of w i re l ess b earers b y us i ng “WAP stac k ,” w hi c h i nc l u d es WSP i nvocat i on of HTTP methods; WAP PUSH services; OTA securit y ; and capabilit y ne g otia- tions (UAProf). The “Pa y load” represents the MMS application la y er protocol data units (PDUs), which is carried b y WAP and HTTP. The structure of PDUs i s described later. F ig. 11. 10 . Implementation of MM1 interface using HTTP-based protocol stack An examp l e of en d -to-en d transact i ons t h at occur b etween t h e MMS user agent carr y MMS PDUs di rect ly b etween t h e MMS user a g ent an d t h e MMSC, an d a g atewa y i s on ly nee d e d f or pus h funct i ona li t y . A g atewa y i s om i tte d i n Fi g . 11.9 shows the WAP 1.x arch i t ec t u r e w ith t wo link s. Th e fir s t i s be t- ween the wireless MMS user agent and the WAP gateway, and the messages are Fig. 11.10 shows a different arc h i tectural configuration. HTTP is used to F i g. 11.10. an d t h e MMSC i s d ep i cte d i n F i g. 11.11. Y. Yang and R. Yan270 271 T he transactions on MM1 interface utilize a variet y of transport schemes, e. g ., abstract messages. The MMS user agent issues a multimedia message by sending an M-Send.req to the MMSC using a WSP/HTTP POST method. This operation t ransmits the re q uired data from the M MS user agent to the MMSC as well as p rov id es a transact i ona l context for t h e resu l t i ng M-Sen d .conf response. T h e MMSC uses WAP PUSH tec h no l ogy to sen d th e M-Not i f i cat i on. i n d to t h e MM S u ser agent to i nfor m t h e ava il a bili ty of mu l t i me di a message for retr i eva l . T h e URI o f the multimedia messa g e is also includ e d in the data. In the URI, the MMS user ag ent uses the WSP/HTTP GET method to retrieve the messa g e. The fetchin g of t he URI returns the M-retrieve.conf, which contains the actual multimedia mes - sage to be presented to the user. The M-Acknowledge.ind passed from the MMS u ser agent to MMSC is to indicate that the message is actually received by the MMS user agent. An d t h e MMSC i s respons ibl e for prov idi ng a d e li very repor t b ac k to t h e or i g i nator MMS user agent aga i n ut ili z i ng t h e WAP PUSH tec h no l ogy w i t h t h e M-De li very. i n d message. E ach abstract messa g e ma y be mapped to one or more lower la y er PDUs, w hi c h i s d i scussed in the followin g . M M SC Ori g inator MMS U ser Ag en t Reci p ient MMS U ser Ag en t M -Send.re q M - S end.con f M -N o tifi ca ti o n.in d M-Noti fy Resp.in d WSP GET.req M-r e tri e v e . co nf M - A c k now l e dg e. i n d M - D e li very. i n d F i g . 11 . 11 . Exam p le of MMS transactional flow in WAP 1 1.3.7 Structure In the earlier transaction, most messa g es are sent as MMS PDUs. An MMS PDU may consist of MMS headers and MMS body; also it can include only headers. T he MMS PDUs are, in turn, p assed in the content section of WAP or HTTP mes - s ages, an d t h e content type of t h ese messages i s set as app li cat i on / vn d .wap.mms - message. 11 Mo bil e C onten t D e li ver y Tec h no l o gi es The MMS headers contain MMS-specific information of the PDU, mainly about how to transfer the multimedia message from the originating terminal to the recipient terminal. The MMS body includes multimedia objects, each in separate part, as well as optional presentation part. The order of the parts has no signifi- cance. The presentation part contains instructions on how the multimedia content should be rendered on the terminal. There may be multiple presentation part, but one of them must be the root part; in the case of multipart/related, the root part is pointed from the Start parameter. Examples of the presentation techniques are WSP Header Content-type: application/vnd.wap.mms-message WSP Content MMS Header MMS Body Presentation image/jpeg text/plain audio/wav Start Fig. 11.12. Model of MMS data encapsulation and WSP message The MMS headers consist of header fields that in general consist of a field name and a field value. Some of the header fields are common header fields and others are specific to MMS. There are different types of MMS PDUs used for dif- ferent roles, and they are distinguished by the parameter “X-Mms-Message-Type” in MMS headers. Each type of message is with a kind of MMS headers with par- ticular fields.In the earlier example, the M-Send.conf message contains an MMS 11.3.8 Supported Media and File Formats Multiple media elements can be combined into a composite single multimedia support media types should comply with the following selection of media formats: header only and it includes several fields listed in Table 11.3. Fig. 11.12 is an example of how multimedia content and presentation information Y. Yang and R. Yan272 can be encapsulated to a single message and be contained by a WSP message [18]. synchronized multimedia integration language (SMIL) [19], wireless markup lan- guage (WML) [20], and XHTML. message using MIME multipart format as defined in RFC 2046 [21]. The minimum 2 7 3 T able 11. 3 . M -Sen d .conf messa g e fi e ld name f i e ld content d escr i pt i o n X-Mms-Message-Typ e M essage-type-va l ue = m-not i f y resp- i n d man d atory s pec i f i es t h e PDU typ e X-Mms-Transact i on-I D Transact i on- id -va l u e man d atory id ent i f i es t h e transact i on s tarte d b y M - N ot i f i cat i on. i n d PD U X-Mms-MM S - V ers i o n M M S -vers i on-va l u e man d atory t h e MM S vers i on num b er. X-Mms- S tatus S tatus-va l u e man d atory message status. T h e status r etr i eve d w ill b e use d on l y aft e r success f ul r e tr iev a l of t he MM X-Mms-Report - A llowed Report-a ll owe d -va l u e opt i ona l . Defau l t: Yes. i n di cat i on of w h et h er or no t • T ext. p lain text must be supported. Any c haracter encoding that contains a subset of the logical characters in unicode can be used. • Speec h . the A RM c o d ec supports narrow b an d speec h . T h e ARM w id e - b an d ( ARM-WB ) speec h co d ec of 16- k Hz samp li n g frequenc y i s sup - p orte d . T h e ARM an d ARM-WB i s use d for speec h me di a-t y pe a l one. • Audio . MPEG-4 AAC low complexit y ob j ec t t y pe with a samplin g rate u p to 48 kHz is su pp orted. The chan n el confi g urations to be supported are mono ( 1 / 0 ) an d stereo ( 2 / 0 ) . In a ddi t i on, t h e MPEG-4 AAC l ong-term p re di ct i on o bj ect type m a y b e supporte d . • Synthetic audio. Th e sca l a bl e po l yp h ony MIDI ( SP-MIDI ) content format requ i rements d ef i ne d i n sca l a bl e p o ly p h on y MIDI d ev i ce 5-t o -24 n o t e 11 Mobile Conten t Deliver y Technolo g ies A ccor di n g to t hi s spec i f i cat i on, t h e vers i on i s 1 . 2 r eport i s a ll owe d by t h e t h e sen di n g of d e li ver y r eci p ient MMS clien t defined in scalable polyphony MIDI specification [22] and the device profile for 3GPP [23] are supported. SP-MIDI content is delivered in the • Still image. ISO/IEC JPEG together with JFIF is supported. When sup - p orting JPEG, baseline DCT is mandatory while progressive DCT is opt i ona l . • B itmap g rap h ics. GIF87a, GIF89a, an d PNG bi tmap g rap hi cs formats are s u pp orted. • Vi d e o . The mandator y video codec for the MMS is ITU-T recommenda - tion H.263 p rofile 0, level 10. In ad d ition, H.263 Profile 3 , Level 10, and M PEG-4 Visual Sim p le Profile Level 0 are o p tional to im p lement. • Vector grap h ics. For term i na l s support i ng me d i a type “2D vector grap h- i cs” t h e “T i ny” prof il e of t h e sca l a bl e vector grap hi cs ( SVG-T i ny ) format i s supporte d , an d t h e “Bas i c” prof il e of t h e sca l a bl e vector g rap hi cs ( SVG-Bas i c ) format ma y b e supporte d . • File f ormat f or d y namic media . To ensure i ntero p era bili t y for t h e trans - p ort of video and associated s p eech/audio and timed text in a multimedia messa g e, the 3GPP file format is supported. • Media synchronization and presentation f ormat. d T he mandator y format f or me di a sync h ron i zat i on an d sce n e d escr i pt i on of mu l t i me di a messag- i ng i s SMIL. T h e 3GPP MMS uses a su b set of SMIL 2.0 as t h e format o f t h e scene d escr i pt i on. A ddi t i ona lly , 3 GPP MMS s h ou ld prov id e t h e for - mat of XHTML mo bil e prof il e. • D RM f orma t . T h e support of DRM i n MMS conforms to t h e OMA DRM f ormat of OMA DRM content format ( DCF ) for di screte me di a an d 1 1.3.9 Client-Side Structure T he g eneral model of how the MMS user a g ent fits within the g eneral WAP Clien t T h e MMS user agent i s respons ibl e for t h e compos i t i on an d ren d er i ng of mu l - t i me di a messa g es as we ll as sen di n g an d rece i v i n g mu l t i me di a m essa g es by ut ili z - ing the message transfer services of the a ppropriate network protocols. The MMS a a user agent is not dependent on, but may use, the services of the other components s hown in Fig. 11.13, i.e., the common functions, WAP identity module (WIM) OMA p acketized DRM content format (PDCF) for p acketized (continuou s or format 1. precedence over message distribution indication and over MM7 content adaptation registration from REL-6 onward. The protected files are in the Y. Yang and R. Yan274 structure specified in standard MIDI files 1.0 [24], either in format 0 specifications [25]. DRM protection of a multimedia message takes media [26]. architecture is depicted in Fig. 11.13 [18]. [27] and external functionality interface (EFI) [28]. 27 5 Application Framework (WAE User Agent, Push Dispatcher, MMS Uer Agent) Network Protocols Content Renderers (Images, Multimedia, ect.) Common Functions (Persistence, Sync, etc.) WIM EFI Fig . 11. 13 . G enera l W AP c li ent arc hi tecture 11.4 Transcoding Techniques In this section , we focus on progresses in conten t t ranscoding techniques. We i ntroduce the prevailing status and give details of some transcoding techniques wi t h di fferent me di a types. As an a pp li cat i on an d en h ancement of content transco di n g , we a l so i ntro d uce some p r o g resses i n a d apt i ve content d e li ver y an d s calable content codin g . 1 1.4.1 Transcod i ng – The Br i dge f or C ontent Del i very Because of the various mobile computing technologies involved, multimedia con- tent access on mo bil e d ev i ces i s poss ibl e. W hil e stat i onar y comput i n g d ev i ces s uc h as PCs an d STBs h a d mu l t i me di a support l on g b efore, mo bil e d ev i ces h ave sp ecial features that make them differen t f rom stationar y computin g devices. Due to limitations of design and usability, m obile devices normally have lower com - p ut i ng power, sma ll er an d l ower reso l ut i on di sp l ay, li m i te d storage, s l ower an d l ess re li a bl e networ k connect i ons , an d l ast b ut i mportant l y, li m i te d user i nteract i on i nterfaces. As a result, onl y speciall y tailored c o nt e nt s c an ha ve th e bes t use r experiences on these devices. In this case, content creators ma y choose to produce contents specifically for mobile devices. However, large quan t iti es o f m u ltim ed ia contents an d d ocuments h ave a l rea d y b een create d for stat i onary comput i ng d ev i ces w i t h high b an d w id t h an d p rocess i n g capa bili t i es. Convert i n g t h ese ex i st - i n g contents to fit the special re q uirements of the mobile devices is another more cost-effective and reasonable a pp roach. The p rocess that does this conversion is called transcoding. G enera lly spea ki n g , we can d ef i ne tr a nsco di n g as t h e process of transform i n g contents from one re p resentation format or leve l o f de tail s t o an o th e r o n e. In so m e 11 Mo bil e C onten t D e li very Tec h no l og i e s c ases, transco di ng can b e tr i v i a l an d can ta k e p l ace w h en t h e contents are b e i ng [...]... Recognition (ICDAR ’01), pp 85 9 86 4 CIL_whatis.htm 80 11 Mobile Content Delivery Technologies 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 297 A Fox, S.D Gribble, Y Chawathe, E.A Brewer (19 98) Adapting to network and client variation using infrastructural proxies: Lessons and perspect tives IEEE Personal Communication 5(4):10–19 R Schaefer, A Dangberg, W Mueller (2002) Fuzzy rules for HTML transcoding In:... 11 Mobile Content Delivery Technologies 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 295 H Sun, W Kwok, J Zdepski (1996) Architectures for MPEG compressed bitstream scaling IEEE transaction on Circuits and Systems fro Video Technology 6(2):191–199 N Bjork, C Christopoulos (19 98) Transcoder architectures for video coding IEEE Transactions on Consumer Electronics 44(1) :88 – 98 A Eleftheriadis, D Anastassiou... http://www-2.cs.cmu.edu/~ph/ciq_thesis G.W Braudaway (1 986 ) A procedure for optimum choice of a small number of colors from a large color palette for color imaging In: Proceedings of Electronic Imaging 86 – International Electronic Imaging Exposition and Conference, pp 75–79 Y Linde, A Buzo, R.M Gray (1 980 ) An algorithm for vector quantizer design IEEE Transactions on Communication 28( 1) :84 –95 M Orchard, C Bouman (1991)... displacement information (motion vector, MV) In the MC process, one or two reference frames can be used accordingly for unidirectional and bidirectional predictions With intraframe coding, each 8 8 block in one MB is transformed by discrete cosine transform (DCT) first, then vector quantization (VQ) is applied to the DCT results (this is where the loss comes from) Afterward, the resulting 8 8 blocks are... G.L Bodic, Mobile Messaging Technologies and Services: SMS, EMS and MMS”, Alcatel, France, ISBN 047 084 8766 3GPP TS 23.040 Technical Realization of the Short Message Service (SMS), March 2004 11 Mobile Content Delivery Technologies 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 293 C Peersman, S Cvetkovic, P Griffiths, and H Spear (2000) The global system for mobile communications Short... transcoder for spatial resolution downconversion Lecture Notes in Computer Science: Recent Advances in Visual Information Systems 2002(3):207–2 18 296 64 65 66 67 68 69 70 71 72 73 74 Y Yang and R Yan A Vetro, C.W Chen (2002) Rate-reduction transcoding design for wireless video streaming Proceedings of 2002 International Conference on Image Processing 1:29–32 Y Yu, C.W Chen (2000) SNR scalable transcoding for. .. Wang, S Yu (19 98) Dynamic rate scaling of coded digital video for IVOD applications IEEE Transaction on Consumer Electronics 44 (8) :743–749 P Assunção, M Ghanbari (19 98) A frequency-domain video transcoder for dynamic bit-rate reduction of MPEG-2 bitstreams IEEE Transactions on Circuits and Systems fro Video Technology 8( 12):953–967 J Xin, M.T Sun, K Chun (2002) Motion re-estimation for MPEG-2 to MPEG-4... Sometimes the context information is the key to the success of mobile services The primary context information includes locations, resources, environments users reside in, and so on That information could be very rich and depends on specific applications heavily For example, a weather forecast service must know where the service requester is located before sending the relevant weather information A car dealer... service on a Web proxy For example, TranSend [81 ], ProxyNet ProxiWare, SpyGlass Prism Server, and OnlineAnywhere FlashMap use proxy servers to adjust Web pages to fit the display of small devices based on some heuristic rules and special content filters designed for specific Websites to extract the most important contents from HTML pages Similar approaches are reported in [82 ] [83 ] [84 ] Instead of specific... encoding format conversion audio result type video key frame extraction video Transcoding method encoding format conversion Transrating source type image representation format conversion format conversion text to speech screen rendering image document audio image summary of typical scenes film sound track CD audio to MP3 320 kbps MP3 to 1 28 kbps 5.1 channels surround to 2 channels stereo 44.1 kHz to 8 kHz . opt i ona l . • B itmap g rap h ics. GIF87a, GIF89a, an d PNG bi tmap g rap hi cs formats are s u pp orted. • Vi d e o . The mandator y video codec for the MMS is ITU-T recommenda - tion. producin g con t e nts for mobile devices. Some p eo p le consider th e techni q ues to add more redundan t information for error resilience and recovery with t error-prone wireless network channels. macroblocks (MBs), each MB consisting of luminance block (16×16 or four 8 8) and related chromatic blocks as Cb and Cr (8 8) . There are two types of frame coding methods. One is intraframe coding,