BS DD ENV 12313-4-2000 Traffic and traveller information (TTI) - TTI messages via traffic message coding - Coding protocol for radio data system - Traffic message channel (RDS-TMC).pdf

1、| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DRAFT FOR DEVELOPMENT DD ENV 12313-4:2000

2、ICS 35.240.60 NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW Traffic and Traveller Information (TTI) TTI Messages via Traffic Message Coding Part 4: Coding Protocol for Radio Data System Traffic Message Channel (RDS-TMC) RDS-TMC using ALERT Plus with ALERT CThis British Stand

3、ard, having been prepared under the direction of the Electrotechnical Sector Committee, was published under the authority of the Standards Committee and comes into effect on 15 July 2000 BSI 07-2000 ISBN 0 580 32749 3 DD ENV 12313-4:2000 Amendments issued since publication Amd. No. Date Comments Nat

4、ional foreword This Draft for Development is the official English language version of ENV 12313-4:2000. This publication is not to be regarded as a British Standard. It is being issued in the Draft for Development series of publications and is of a provisional nature because the level of innovation

5、on this subject is currently high. It should be applied on this provisional basis, so that information and experience of its practical application may be obtained. Comments arising from the use of this Draft for Development are requested ao that UK experience can be reported to the European organiza

6、tion responsible for its conversion into a European Standard. A review of this publication will be initiated 2 years after its publication by the European organization so that a decision can be taken on its status at the end of its three-year life. The commencement of the review period will be notif

7、ied by an announcement in Update Standards. According to the replies received by the end of the review period, the responsible BSI committee will decide whether to support the conversion into a European Standard, to extend the life of the prestandard or to withdraw it. Comments should be sent in wri

8、ting to the Secretary of BSI Technical Committee EPL/278, Road transport informatics, at 389 Chiswwick High Road, London W4 4AL, giving the document reference and clause number and proposing, where possible, an appropriate revision of the text. A list of organizations represented on this committee c

9、an be obtained on request to its secretary. Cross-references The British Standards which implement international or European publications referred to in this document may be found in the BSI Standards Catalogue under the section entitled “International Standards Correspondence Index”, or by using th

10、e “Find” facility of the BSI Standards Electronic Catalogue. A British Standard does not purport to include all the necessary provisions of a contract. Users of British Standards are responsible for their correct application. Compliance with a British Standard does not of itself confer immunity from

11、 legal obligations. Summary of pages This document comprises a front cover, an inside front cover, the ENV title page, pages 2 to 40, an inside back cover and a back cover. The BSI copyright notice displayed in this document indicates when the document was last issued.EUROPEANPRESTANDARD PRNORMEEURO

12、PENNE EUROPISCHEVORNORM ENV123134 April2000 ICS35.240.60 Englishversion TrafficandTravellerInformation(TTI)TTIMessagesviaTraffic MessageCodingPart4:CodingProtocolforRadioData SystemTrafficMessageChannel(RDSTMC)RDSTMC usingALERTPluswithALERTC ThisEuropeanPrestandard(ENV)wasapprovedbyCENon26April1999a

13、saprospectivestandardforprovisionalapplication. TheperiodofvalidityofthisENVislimitedinitiallytothreeyears.AftertwoyearsthemembersofCENwillberequestedto submittheir comments,particularlyonthequestionwhethertheENVcanbeconvertedintoaEuropeanStandard. CENmembersarerequiredtoannouncetheexistenceofthisEN

14、VinthesamewayasforanENandtomaketheENVavailablepromp tly atnationallevelinanappropriateform.Itispermissibletokeepconflictingnationalstandardsinforce(inparalleltothe ENV)untilthefinal decisionaboutthepossibleconversionoftheENVintoanENisreached. CENmembersarethenationalstandardsbodiesofAustria,Belgium,

15、CzechRepublic,Denmark,Finland,France,Germany,Greece, Iceland,Ireland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain,Sweden,SwitzerlandandUnitedKingdom. EUROPEANCOMMITTEEFORSTANDARDIZATION COMITEUROPENDENORMALISATION EUROPISCHESKOMITEEFRNORMUNG CentralSecretariat:ruedeStassart,36B1050Brussels 200

16、0CEN Allrightsofexploitationinanyformandbyanymeansreserved worldwideforCENnationalMembers. Ref.No.ENV123134:2000EPage2 ENV123134:2000 CONTENTSLIST CONTENTSLIST 2 FOREWORD 4 INTRODUCTION 4 1.SCOPE 6 1.1Application 6 1.2Presentation 6 1.3Servicemanagement 7 1.4Transmission 7 2.NORMATIVEREFERENCES 8 3.

17、APPLICATION 8 3.1ContentoftheTMC“travelservice“ 8 3.2TMCterminal 9 3.3Eventorientatedinformation(ALERTC) 9 3.4Statusorientatedinformation(ALERTPlus) 9 3.5Strategicandtacticalinformation 9 3.6Geographicrelevance 10 3.7Transmittedmessagepriority 10 4.PRESENTATION 10 4.1Eventorientatedmessages 10 4.2St

18、atusorientatedmessages 10 4.2.1Messageformat(variant:4bits) 11 4.2.2Collection(11or12bits) 12 4.2.3Statuses(20or21bits) 13 4.2.4Codingmechanism 13Page3 ENV123134:2000 5.SERVICEMANAGEMENT 20 5.1Introduction 20 5.1.1PureALERTCservice 21 5.1.2Addedvalueservices(ALERTCandALERTPlus) 21 5.2Systemmessages(

19、32bits) 24 5.2.1Servicelayerinformation 24 5.2.2Networklayerinformation 25 6.TRANSMISSION 32 6.1Systemmessages 33 6.1.1Type1Agroups 33 6.1.2Type5Agroups 34 6.1.3Type3Agroups 35 6.1.4Type8Agroups 36 6.2Immediaterepetition 37 6.3Eventorientatedmessages(ALERTC) 38 6.4Statusorientatedmessages(ALERTPlus)

20、 38 6.5Summary 40Page4 ENV123134:2000 FOREWORD ThisEuropeanPrestandardhasbeenpreparedbyFORCE/ECORTISWP13.6expert teamonALERTPluscodingprotocolandlocationreferencingandbyTechnical CommitteeCEN/TC278“Roadtransportandtraffictelematics“,thesecretariatof whichisheldbyNNI . AccordingtotheCEN/CENELECIntern

21、alRegulations,thenationalstandards organizationsofthefollowingcountriesareboundtoannouncethisEuropean Prestandard:Austria,Belgium,CzechRepublic,Denmark,Finland,France,Germany, Greece,Iceland,Ireland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain, Sweden,SwitzerlandandtheUnitedKingdom. INTRODUCTI

22、ON TheALERTPlusfunctionisacompatibleextensionoftheALERTCfunctionand makesitpossibletouseRDSTMCbroadcaststatusorientatedinformation.This informationisrelatedto: theroadtraffic,suchaslevelofserviceortraveltime, thecarparkoccupancy, thepublictransport,suchastraveltime,frequencyorheadway. Otherstatusori

23、entatedinformationhavestilltobeconsidered,suchasthe informationaboutsnowontheroad,waterheight,windforce,pollution, time delaylostduetotrafficcondition.Thecodingmechanismsarethesame. Thisfunctionconstitutesanadditionalresponsetotheinformationneedsofroad users,particularlyindenseurbanareas,bytakingint

24、oaccounttheconstraintswhich affecttheroadnetworkorthepublictransportoperators. TheALERTPlusbroadcastingprotocolprovidesaninformationcodingtechnique whichallowstherecipienttorecoverthebroadcastinformationinitsentirety.The transmittedmessagescontaindynamicdata(statuses)whichcanonlybeinterpreted withre

25、ferencetostaticdata(locations.).Tofacilitatebroadcasting,locationsare groupedtogetherinaddressescalledcollections.Bothtransmitterandreceivermust beawareofallelements. TherearemanyfunctionalresponsibilitiesassociatedwiththeprovisionofanRDS TMCservice,rangingfromroadbaseddatacollection,tomessagecompil

26、ationand finallytransmission.Becauseitwasnotedthatthefunctionalresponsibilitiesandtheir nameswerenotcommonlyunderstood,thekeyfunctionsaredefinedintheENV 123131,ALERTCProtocol, date.Thesedefinitionsarealsousefultounderstandthe standarddescribedinthisdocument.Howevertheyhavetobecompletedbythe followin

27、gdefinitionwhichcharacterisesafunctionalresponsibilityofimportancefor theALERTPlusfunction: RoadNetworkOperator:Page5 ENV123134:2000 Apublicorprivateauthorityresponsibleforpartoftheroadnetworkofacountry. Withoutmakingassumptionsregardingtheagreementswhichdataserviceprovider mayenterintowithroadnetwo

28、rkoperators,thestandardallowsinformationtobe broadcastinunscrambledorscrambledformusingeitherthepubliccollectionswhich belongtoroadnetworkoperators,ifsuchcollectionsexist,orprivatecollections. Thepresentprestandarddescribesthebroadcastingofdynamicdata.Allparts referringtolocationreferencingaredealts

29、eparatelybyCENTC278SWG7.3andare notincludedinthisdocument. TwoapproachesaregenerallydistinguishedintheRDSTMCworld: ThefirstapproachisbasedontheideaofanuniversalALERTCservice.Thisis possibleifacontinuousandinteroperablenetworkofALERTCfreeaccessservices isinplaceinacountryoraroundacontinent.Agoodexamp

30、lecouldbetheRDS TMCPanEuropeanServiceALERT. Thesecondapproachgivesamoreimportantroletothedataserviceproviderandis suitableforoperatingaddedvalue,generallypaidfor,services.Inthatcase,ALERTC protocolisusedtotransmiteventorientatedmessagesandALERTPlusprotocolto transmitstatusorientatedmessages. Forhist

31、oricalreasons,twoRDSTMCOpenDataApplications(ODA)havebeen defined.Withthefirstone,youarelimitedtothefirstkindofservicesinceonly ALERTCisspecified.TheALERTservicecanbeoperatedusingthisfirstODA. ThesecondODAtakesintoaccountbothapproaches(ALERTCandALERTPlus), allowingtooperatetheALERTserviceaswellasanad

32、dedvalueTMCserviceon thesametransmitter.AserviceprovideristhusabletooffertheALERTservice, andtoproposeinparalleltohisclientsamoresophisticatedinformationsuchastravel times.ThisadditionalservicemaybepaidforandencryptedwhilethebasicALERT Cservicemayremainfreeaccess.Finallythissecondsolutionhastheadvan

33、tagesof beingbackwardcompatiblewiththeexistingimplementationusingthe1A/8A ALERTC,aswellasALERTPlusformat. ThistwoODAsarefullycompatible,sincetheALERTCpartofthemixedALERT C/ALERTPlusODAisexactlythesameastheprotocolofthepureALERTCODA. ForinstanceaserviceprovidermayoperatetheALERTserviceusingindifferen

34、tly oneofbothODA.OnlythetransmittedApplicationIDentifier(AID)isdifferent.A RDSTMCreceivermustbeawareofthetwodifferentAIDsandthatisall.Theuser messages,aswellasthesystemmessagesarethesame. ThisdocumentdescribesthemixedALERTC/ALERTPlusODA,butsystematically referstothepureALERTCODA(RDSTMCALERTCProtocol

35、,CENENV 123131,June1997)whendealingwiththeALERTCprotocol.The1A/5A/8A formatisalsostandardisedinordertotakeintoaccountexistingimplementations. HoweverinthefutureallRDSTMCservicesshouldmigrateintotheODAformat.Page6 ENV123134:2000 1. SCOPE 1.1 APPLICATION TheALERTPlusfunctionisanextensionoftheALERTCfun

36、ction.WhileALERTC coverseventorientatedinformationtobeconveyedbytheRDSmedium,ALERT Plusdealswithstatusorientatedinformationtobeconveyedbythesamemedium. TheALERTPlusfunctioninformsmotoristsaboutthechangesaffectingthestatusof trafficatpredefinedlocations.Different statustypesaredefinedsuchaslevelof se

37、rviceonroadsectionsorareas,traveltimesonroadsections,carparkoccupancy, statusofpublictransporttraffic. Alocationcanbearoadsection,apole,acarpark,.,referencedinthe location table.LocationreferencingishoweverdealtseparatelybyCENTC278SWG7.3and isnotincludedinthisdocument. Apartofthedocumentisvalidforot

38、herdatatransmissionmediasuchasAMor SWIFTbroadcastdatasystems,thedigitalcellularradiosystem(GSM),andthe digitalaudiobroadcasting(DAB).Atleasttheusermessagescontentismedium independent. 1.2 PRESENTATION Thisdocumentdealswiththecodingprotocolforthemultiplexbroadcastingofevent orientatedandstatusorienta

39、tedinformation,butitessentiallydescribesthecontentof statusorientatedmessages.TheeventorientatedmessagesaredescribedintheENV 123131,ALERTCProtocol, date . Thepresentationsectiondescribesthewayinwhichmessagesarecodedfor broadcasting. Themaincodingprincipleforstatusorientatedmessagesistogathertogether

40、the informationwhichrelatestoseverallocationsinthesamemessage,andtotransmita socalledcollectionnumberinsteadoftransmittingdirectlylocationnumberslikein theALERTCprotocol.Eachcollectionidentifiesasetoflocationsaccordingtothe collectiontable . Statusorientatedmessagescontainthreefields: messageformat,

41、 collectionnumber, statusesofthelocationsidentifiedbythecollection. The tra n smitte d messageformat makesitpossibletodifferentiatebetweentwotypes ofmessages,thosewhichgiveinformationaboutfivedifferentlocationsandthose whichgiveinformationaboutsevendifferentlocations.Thisdifferenceintheformat allows

42、moreflexibilityaccordingtothestatustypeandthelocationtype. Page7 ENV123134:2000 The tra n smitte d col l ecti o nisanumberwhichrepresentsasetoffiveorseven locations.Acollectionisalsoassociatedwithaparticularstatustype.Thismechanism hastheadvantageoflimitingtheinformationtransmittedsinceonlyonecollec

43、tion numberistransmittedinsteadofthefiveorsevencorrespondinglocationsnumbers. Accordingtothemessageformat,thecollectionidentifiesfiveorsevenlocations. Thetransmittedfiveorsevenstatusesareinformationaboutthefiveorseven locationsidentifiedbythetransmittedcollectionnumber.Allthestatusesina particularme

44、ssagehavethesameformatsetbythetransmittedmessageformat.The statusesarecodedaccordingtothe codeconversiontables . Thefollowingtablesmustbeinstalledintheterminalandintheencodingsystemto enablethemtoprocessTMCmessages: locationtables, collectiontables, codeconversiontables, 1.3 SERVICEMANAGEMENT Adistinctionismadebetweenusermessagesandservicemanagementmessages.User messagesarethosepotentiallymadeknowntothedriver,as