1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T Q.3615 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (04/2015) SERIES Q: SWITCHING AND SIGNALLING Signalling requirements and protocols for the NGN Service and session control protocols supplementary services Protocol for
2、 GeoSMS Recommendation ITU-T Q.3615 ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T S
3、TANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4, 5, 6, R1 AND R2 Q.120Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.
4、999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND I
5、SDN Q.2000Q.2999 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR THE NGN Q.3000Q.3999 General Q.3000Q.3029 Network signalling and control functional architecture Q.3030Q.3099 Network data organization within the NGN Q.3100Q.3129 Bearer control signalling Q.3130Q.3179 Signalling and control requirements an
6、d protocols to support attachment in NGN environments Q.3200Q.3249 Resource control protocols Q.3300Q.3369 Service and session control protocols Q.3400Q.3499 Service and session control protocols supplementary services Q.3600Q.3649 NGN applications Q.3700Q.3849 Testing for next generation networks Q
7、.3900Q.3999 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T Q.3615 (04/2015) i Recommendation ITU-T Q.3615 Protocol for GeoSMS Summary Recommendation ITU-T Q.3615 standardizes the communication of location information between various location-based services (LBSs)
8、over short message service (SMS). The protocol for GeoSMS can be supported by existing telecommunication network infrastructures, further facilitating the advantage of interoperability. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T Q.3615 2015-04-29 11 11.1002/1000/12218 K
9、eywords GeoSMS, LBS, location-based service, SMS, short message service. _ * To access the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T Q.
10、3615 (04/2015) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is respo
11、nsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the I
12、TU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborati
13、ve basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain man
14、datory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements.
15、The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU tak
16、es no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual prope
17、rty, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2015 All rights reserved.
18、 No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Q.3615 (04/2015) iii Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 1 4 Abbre
19、viations and acronyms 1 5 Conventions 2 6 The encoding protocol for GeoSMS . 2 6.1 Element 1: URI with HTTP or HTTPS scheme . 2 6.2 Element 2: Query string with location parameter . 2 6.3 Element 3: Optional parameter(s) 3 6.4 Element 4: Postfix string 3 6.5 Element 5: Payload . 3 Appendix I Use cas
20、es of GeoSMS 4 I.1 Use case 1: GeoSMS with no optional parameter (Element 3) 4 I.2 Use case 2: GeoSMS with optional parameter (Element 3) . 4 I.3 Use case 3: GeoSMS with postfix string value (Element 4) 5 I.4 Use case 4: GeoSMS with no payload (Element 5) . 5 Bibliography. 6 Rec. ITU-T Q.3615 (04/20
21、15) 1 Recommendation ITU-T Q.3615 Protocol for GeoSMS 1 Scope This Recommendation defines the protocol for GeoSMS which is used to encode location information in a plain text message. GeoSMS can be sent in a short message service (SMS) message a capability provided by telecommunication networks. Thu
22、s, GeoSMS not only facilitates the interoperability of SMS, but also standardizes the communication of location content between different location-based services (LBSs), while still maintaining human readability of the content. That is, any application or service can simply encode the location infor
23、mation into an SMS message with this Recommendation. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recomm
24、endations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly
25、published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. IETF RFC 3986 IETF RFC 3986 (2005), Uniform Resource Identifier (URI): Generic Syntax. IETF RFC 7230 IETF RFC 7230 (2014), Hypertext Transfer Protocol (HTTP/
26、1.1): Message Syntax and Routing. OGC 11-030r1 Open Geospatial Consortium, OGC 11-030r1 (2012), OGC: Open GeoSMS Standard Core. 3 Definitions 3.1 Terms defined elsewhere None. 3.2 Terms defined in this Recommendation This Recommendation defines the following term: 3.2.1 GeoSMS: A message format of p
27、lain text, with geospatial information encoded that can be sent as an SMS message. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: app application HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure LBS Location-Based Service SMS
28、Short Message Service URI Uniform Resource Identifier 2 Rec. ITU-T Q.3615 (04/2015) WGS84 World Geodetic System 1984 5 Conventions None. 6 The encoding protocol for GeoSMS The structure of GeoSMS is shown in Table 6-1. The composed plain text of GeoSMS can be sent via short message service (SMS) alr
29、eady supported by telecommunication networks. This Recommendation adopts the structure defined in OGC 11-030r1. NOTE 1 The length of a GeoSMS message is not limited; longer messages can be supported by multiple SMS features by most of telecommunication networks and mobile devices. Table 6-1 Structur
30、e of GeoSMS Element 1: URI with HTTP or HTTPS Element 2: Query string with location parameter Element 3: Optional parameter(s) Element 4: Postfix string Element 5: Payload There are five elements for GeoSMS. Element 1, Element 2, Element 3 and Element 4 compose the first line of the GeoSMS message s
31、tructure. This first line is essential to the protocol for GeoSMS and conformance to IETF RFC 3986 is required. Element 5 is an optional freestyle text field. NOTE 2 For uniform resource identifier (URI) specific terminology, reference shall conform to IETF RFC 3986. 6.1 Element 1: URI with HTTP or
32、HTTPS scheme GeoSMS begins with a URI with a hypertext transfer protocol (HTTP) or HTTP secure (HTTPS) scheme. This URI conforms to IETF RFC 7230. This URI usually ends with a web service method that can handle Element 2, Element 3 and Element 4. 6.2 Element 2: Query string with location parameter T
33、he syntax of Element 2 is defined as follows: “?location_identifier=latitude,longitude“ The location information in GeoSMS is encoded in a query string. This query string starts with a question mark, “?“, and is followed by a location_identifier. The name of the location_identifier can be any valid
34、string that conforms to IETF RFC 3986. The recommended name for location_identifier in GeoSMS is “geo“. Two parameters, also called coordinates, are required for a location_identifier. These two parameters are latitude and longitude, which are in the b-WGS 84 datum. Both latitude and longitude are d
35、escribed using the decimal degree format without the symbol “. The values of latitude and longitude are bounded by 90 and 180, respectively. Positive latitudes are north of the equator and negative latitudes are south of the equator. Positive longitudes are east of the prime meridian and negative lo
36、ngitudes are west of the prime meridian. Latitude and longitude are expressed in that sequence: latitude before longitude. Rec. ITU-T Q.3615 (04/2015) 3 The symbol “=“ is used to represent the assignment of location information to the location_identifier, and “,“ is used as the separator for the two
37、 parameters. 6.3 Element 3: Optional parameter(s) There can be none, one or more than one optional parameter(s) that start with “ they are intended to illustrate the use of the GeoSMS protocol. I.1 Use case 1: GeoSMS with no optional parameter (Element 3) Chuang was born deaf and is not able to spea
38、k very well. He feels ill in a park near lake Geneva. How can he quickly inform a friend or an emergency responder of his urgent situation? He can report his location and situation with an application (app) conformant to this Recommendation. The app composes a plain text message with the five-elemen
39、t structure described in clause 6. http:/ ?q=46.221465,6.153052 &GeoSMS I am Chuang. I am feeling ill and urgently need some help! The following plain text message conforms to the protocol for GeoSMS. The app sends the message via the SMS service on his mobile phone. http:/ I am Chuang and I need so
40、me help due to an emergency situation. The receiver might be an emergency responder or Chuangs friend depending on the addressee of the message as defined by the user through the application. The receiver will know the location and the status of Chuangs situation, in a short period of time, thanks t
41、o the location that was encoded in the GeoSMS message. I.2 Use case 2: GeoSMS with optional parameter (Element 3) The following is an example of a GeoSMS query string using an optional element to specify an emergency and disaster management case for this Recommendation. http:/ ?geo=24.251,121.162 &a
42、pp=MeetUp &GeoSMS Lets meet up at 14:20 The plain text message, with the elements defined in this Recommendation, is composed as a GeoSMS message. It can later be sent by the app via SMS. The user sends the message to a friend saying, “Lets meet up at 14:20“, in the same way that SMS is used today f
43、or messaging friends. The difference here is that the GeoSMS message has embedded location information. http:/ Lets meet up at 14:20 The optional parameter in this use case is used to specify which application sent the GeoSMS message. In this case, the web service hosted by recognizes that the sour
44、ce app is MeetUp. Rec. ITU-T Q.3615 (04/2015) 5 I.3 Use case 3: GeoSMS with postfix string value (Element 4) This case is an example of a GeoSMS message with a value for a postfix string. Here, “EDM“ is defined as a service provider for emergency and disaster management. http:/maps.geosms.cc/show/ma
45、p ?geo=23.9572,120.6860 &GeoSMS=EDM Landslide occurred at 172K of Highway No. 8! Please avoid this route! This GeoSMS message can be sent as an emergency notification to receivers that are near the location of the emergency. http:/maps.geosms.cc/show/map?geo=23.9572,120.6860&GeoSMS=EDM Landslide occ
46、urred at 172K of Highway No. 8! Please avoid this route! This message can be sent to a subscribers mobile phone or it can be broadcast to devices of people in the immediate area. GeoSMS works even for phones that have no app installed. On a smart phone or personal navigation device, service provider
47、s can leverage this message to reroute the planned route because the value of the postfix string in the GeoSMS message indicates that this GeoSMS message contains an emergency notification. I.4 Use case 4: GeoSMS with no payload (Element 5) This use case can be used for vehicle tracking. The locatio
48、n tracker on a vehicle sends its position with GeoSMS periodically when the vehicle is moving. http:/ ?geo=23.9572,120.6860 &ID=MIA5678 &GeoSMS The following GeoSMS message describes the location of the vehicle and its car ID. http:/ The GeoSMS message without payload is usually adopted for machine-to-machine or service-to-service scenarios. 6 Rec. ITU-T Q.3615 (04/2015) Bibliography b-WGS84 World Geodetic System 1984 (WGS84), World Geodetic System (WGS) established in 1984 and last revised in 2004.http:/spatialreference.org/ref/epsg
