idnits 2.17.1 draft-ietf-spirits-mobility-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7734 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 588, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 591, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 598, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 600, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Daniel Moreno 3 Document: draft-ietf-spirits-mobility-01.txt VODAFONE SPAIN 4 February 2003 5 Expires: August 2003 7 Mobility Events Management in SPIRITS 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This particular draft is intended to be discussed in the SPIRITS 31 Working Group. Discussion of it therefore belongs on that list. The 32 charter for SPIRITS working group may be found at 33 http://www1.ietf.org/html.charters/spirits-charter.html. 35 Abstract 36 This document describes the management of the mobility events 37 considered in SPIRITS protocol and the definition of their related 38 parameters. 40 The mobility events management will allow a SPIRITS server to 41 subscribe to and to be notified of location changes of a mobile 42 user. The events would only be applicable to mobile users reachable 43 through a CS network. The sending of these events must be allowed by 44 setting the related marks in the HLR. Besides, the SPIRITS protocol 45 must be able to translate the CAMEL operations involving mobility 46 information into events that can be transferred to the SPIRITS 47 client. 49 Mobility Events Management in SPIRITS February 2003 51 Table of contents 52 Status of this Memo...............................................1 53 Abstract..........................................................1 54 1. INTRODUCTION...................................................2 55 2. LIST OF MOBILITY EVENTS........................................2 56 3. LOCATION INFORMATION DESCRIPTION...............................3 57 3.1 CODING OF LOCATION INFORMATION ELEMENTS.......................4 58 3.1.1 Geographical Information....................................4 59 3.1.2 Age Of Location Information.................................5 60 3.1.3 CellId Or LAI...............................................5 61 3.1.4 location Number.............................................5 62 3.1.5 Geodetic Information........................................5 63 4. WIRELESS-SPECIFIC SECURITY CONSIDERATIONS ON MOBILITY MANAGEMENT 64 ..................................................................6 65 5. XML DTDS FOR MOBILITY EVENTS...................................7 66 5.1 XML DTDS FOR NOTIFY...........................................7 67 5.2 XML DTDS FOR SUBSCRIBE.......................................13 68 6. REFERENCES....................................................13 69 7. ACKNOWLEDGEMENTS..............................................14 70 8. CHANGES.......................................................14 71 9. AUTHOR'S ADRESS...............................................14 73 1. INTRODUCTION 74 The mobility events management will allow a SPIRITS server to 75 subscribe to and to be notified of location changes of a mobile 76 user. The events would only be applicable to mobile users reachable 77 through a CS network. The sending of these events must be allowed by 78 setting the related marks in the HLR. Besides, the SPIRITS protocol 79 must be able to translate the CAMEL operations involving mobility 80 information into events that can be transferred to the SPIRITS 81 client. 83 The inclusion of mobility events into SPIRITS protocol provides user 84 location information and allows the smart use of mobile phones in 85 services like Internet Call Waiting. 87 2. LIST OF MOBILITY EVENTS 88 The events considered in this document are: 90 - Location Update in the same VLR service area 91 - Location Update in another VLR service area 92 - IMSI attach 93 - MS initiated IMSI detach 94 - Network initiated IMSI detach 95 Mobility Events Management in SPIRITS February 2003 97 Every time a mobility event occurs, the subscribed SPIRITS servers 98 will be notified about it, and they will receive the following 99 information elements: 101 - Service Key. This IE indicates the service logic that the gsmSCF 102 will apply. 103 - Event type. This IE indicates the type of Mobility Management that 104 lead to the notification. 105 - Address. This IE identifies the mobile subscriber to whom the 106 Mobility Event applies. 107 - Location information. This IE indicates the current location of 108 the MS. 110 The first three parameters will be mandatory, and the last one will 111 be optional, depending on the network capabilities. 113 3. LOCATION INFORMATION DESCRIPTION 114 The Location information provided to the SPIRITS client would be 115 very different depending on the mobile network capabilities, as not 116 all the networks are able to supply detailed location information 117 about its users. Therefore all the possible information elements 118 considered into the location information must be marked as optional, 119 and each network will try to make available as much information as 120 possible. 122 The compound information element Location information consists of 123 the following subordinate information elements, all of them 124 optional: 126 - Location number 127 This parameter is used to convey the geographical area address for 128 mobility services. It is used when the calling Party Number does not 129 contain any information about the geographical location of the 130 calling party (for example, origin dependent routing when the 131 calling party is a mobile subscriber). It can be present if the 132 wireless network VLR can derive it from the stored service area 133 identity (for UMTS) or cell global identity (for GSM) or location 134 area identity; otherwise shall be absent. The mapping from service 135 area identity or cell ID and location area to location number is 136 network-specific, and the format is left open to final 137 implementations. For a definition of this information element, see 138 [1]. 140 - Cell Id or Location Area ID 141 Mobility Events Management in SPIRITS February 2003 143 Location area identity or Cell global identity of the cell in which 144 the mobile user is currently in radio contact or in which the mobile 145 user was last in radio contact. Will be present if the mobile user 146 uses radio access and the subscriber record is marked as confirmed 147 by radio contact; otherwise shall be absent. 149 - Geographical information 150 Will be present if the VLR can derive it from the stored cell global 151 identity or location area identity; otherwise shall be absent (for a 152 definition of this information element, see 3G TS 23.032). 154 - Geodetic information 155 Can be present if the VLR can derive it from the stored cell global 156 identity or location area identity; otherwise shall be absent. (This 157 information element corresponds to the Calling Geodetic Location 158 defined in ITU-T Q.763). 160 - Age of location information 161 This parameter represents the elapsed time in minutes since the last 162 network contact with the mobile user (i.e. the actuality of the 163 location information). Will be present if available in the MSC/VLR; 164 otherwise shall be absent. 166 - Selected LSA Identity 167 The IE shall only be sent, if SoLSA is supported. It indicates the 168 LSA identity associated with the current position of the mobile 169 user. Will be Sent if the LSA ID of subscription and LSA ID of the 170 used cell matches. In the case of multiple matches the one with the 171 highest priority is sent. See 3G TS 23.073. 173 3.1 CODING OF LOCATION INFORMATION ELEMENTS 175 3.1.1 Geographical Information 176 The GeographicalInformation parameter refers to Geographical 177 Information defined in GSM 03.32 Version 5.0.0. Only the description 178 of an ellipsoid point with uncertainty circle as specified in GSM 179 03.32 is allowed to be used. 181 The GeographicalInformation parameter contains the following sub- 182 parameters: 184 - TypeofShape 185 Type of shape can only have the value of an ellipsoid point with 186 uncertainty circle. 188 - LAT is the latitude expressed in degrees, and includes its related 189 sign (expressed as either North or South). 191 Mobility Events Management in SPIRITS February 2003 193 - LON is the longitude expressed in degrees, and includes its 194 related sign (expressed as either East or West). 196 - UncertaintyCode: K (exponent), defines the numerical 197 representation of the radius R expressed in meters, where: 198 K 199 R = 10 ((1.1) - 1) 0 <= K <= 127 201 3.1.2 Age Of Location Information 202 Usually coded as an integer (0..32767). The value represents the 203 elapsed time in minutes since the last network contact of the mobile 204 station. 205 Some implementations define two special values: 206 - value "0" indicates that the MS is currently in contact with the 207 network 208 - value "32767" indicates that the location information is at least 209 32767 minutes old 211 3.1.3 CellId Or LAI 212 It is usually coded as a string. The Cell Global Identification is 213 defined in TS GSM 03.03. The internal structure is not described 214 here (Octets are coded according to TS GSM 04.08). 216 3.1.4 location Number 217 It is usually coded as a string (length : 2 - 10 octets). The 218 internal structure is not described here. 220 3.1.5 Geodetic Information 221 Information that indicates the geodetic location of the user. This 222 information element is defined in ITU-T Q.763. It consists of the 223 following sub-parameters: 225 - Screening Indicator 226 Information sent in either direction to indicate whether the 227 address/location information was provided by the user or network. 229 - TypeofShape 230 Described above. 232 - LAT & LON 233 Described above. 235 - Confidence 237 The confidence by which the position of a target entity is known to 238 be within the shape description, (expressed as a percentage) is 239 Mobility Events Management in SPIRITS February 2003 241 directly mapped from the 7 bit binary number K, except for K=0 which 242 is used to indicate �no information�, and 100 < K <= 128 which 243 should not be used but may be interpreted as "no information" if no 244 received. 246 4. WIRELESS-SPECIFIC SECURITY CONSIDERATIONS ON MOBILITY MANAGEMENT 248 The inclusion of mobility events management in SPIRITS protocol 249 allows locating a mobile user and using this information into new 250 services which can provide several advantages for IP users. But this 251 feature can become also a security problem if a mobile user's 252 location information is provided to non-authenticated applications 253 or users. The location information must be treated with maximum 254 care, and it must be guaranteed that no external parties will be 255 able to get it in any way. 257 For example, if an enterprise has a set of mobile users and an 258 application over SPIRITS, which periodically provides their location 259 information, there must be a way to authenticate the subscribing IP 260 users (enterprise), in order to provide the information only to the 261 right ones. On the other hand, the enterprise (SPIRITS server) will 262 only be able to access to the information related to their own 263 phones, and not to any other one that is not included into a related 264 list of accessible phones. 266 It is better to consider authentication and securing as matters to 267 be implemented in the final applications. The security requirements 268 must ensure that an IP user will not be allowed to subscribe to any 269 notifications on mobile phones that are out of its control. This can 270 be carried out by managing access control lists, whose definition is 271 out the scope of this document. 273 Another difficulty appears in case of connections from users that 274 employ non-fixed IP addresses (i.e. GPRS connections from a mobile 275 user), because those IP addresses couldn't be checked against a list 276 of profiles. A possible alternative could be the inclusion of secret 277 key-codes into every subscription request. These key-codes would be 278 checked by the SPIRITS application before enabling notifications of 279 mobility events about a certain mobile phone. This case is not 280 included into this document, and it would imply adding a new 281 parameter (access-code) into the "Subscribe XML DTD". This point is 282 left open for future discussing. 284 Mobility Events Management in SPIRITS February 2003 286 5. XML DTDS FOR MOBILITY EVENTS 287 This section presents XML DTDs for managing the mobility events and 288 their related parameters. 290 5.1 XML DTDS FOR NOTIFY 291 The next lines comprehend the DTD's for notifying a mobility event. 292 The Event_met parameter can be considered as a subset of the 293 complete events list. 295 302 308 311 318 320 326 333 339 341 347 349 356 359 366 369 377 379 384 386 392 394 400 402 408 410 416 417 Mobility Events Management in SPIRITS February 2003 419 425 427 433 435 441 443 449 450 452 458 459 461 469 470 472 478 479 481 487 489 495 497 504 506 514 516 522 524 530 532 538 540 546 548 554 555 Mobility Events Management in SPIRITS February 2003 557 558 560 %spirits_adr.dtd; 562 5.2 XML DTDS FOR SUBSCRIBE 563 The DTDs for subscribing to a mobility event could be like this 564 (some of its elements are already defined in the notify section): 566 573 579 581 The DTDs for ServiceKey, Event_met and ADDRESS are the same as 582 defined in section 5.1, so they are not included here. 584 6. REFERENCES 586 [1] ITU-T Q.763, December 1999: "Specifications of Signalling System 587 No. 7 � Formats and codes of the ISDN user part". 588 [2] 3G TS 23.032, "Universal Geographical Area Description (GAD)". 589 [3] 3G TS 23.073, "Support of Localised Service Area (SoLSA); Stage 590 2" 591 [4] GSM 03.32 Version 5.0.0, " Digital cellular telecommunications 592 system (Phase 2+) (GSM); Universal Geographical Area Description 593 (GAD) " 594 [5] TS GSM 03.03, " Digital cellular telecommunications system 595 (Phase 2+) (GSM); Numbering, addressing and identification" 596 Mobility Events Management in SPIRITS February 2003 598 [6] TS GSM 04.08, " Digital cellular telecommunications system 599 (Phase 2+) (GSM); Mobile radio interface; Layer 3 specification" 600 [7] IETF Spirits Workgroup, "On selection of IN parameters to be 601 carried by the SPIRITS Protocol", 603 7. ACKNOWLEDGEMENTS 604 Thanks to Musa Unmehopa for the comments and suggestions made to the 605 previous version of this draft. They helped me a lot in creating 606 this new one. 608 8. CHANGES 609 - Inclusion of Service Key as a mobility event parameter. 610 - Basic MSISDN parameter has been replaced by Address parameter. 611 - Definition for Geodetic Information (also in DTD). 612 - Redefinition of LAT and LON parameters. 614 9. AUTHOR'S ADRESS 616 Daniel Moreno Buendia 617 Vodafone Spain 618 C/ Trespaderne, 24 619 Barajas-1 Building, 1st Floor 620 28042 MADRID 621 SPAIN 622 email: daniel.moreno@odafone.com 623 Phone number: +34610513410