home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / q / q1004.asc < prev    next >
Text File  |  1991-12-30  |  18KB  |  383 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Recommendation Q.1004
  8.  
  9.             LOCATION REGISTER RESTORATION PROCEDURES
  10.                                 
  11.                                 
  12.                             Contents
  13.  
  14.  
  15. 1.   Introduction
  16.  
  17. 2.   Technical realizations to achieve the objectives
  18.  
  19. 3.   Restoration of the location register memories
  20.  
  21. 4.   Restoration of the supplementary service parameters
  22.  
  23.  
  24. Recommendation Q.1004
  25.  
  26.             LOCATION REGISTER RESTORATION PROCEDURES
  27.  
  28. 1.     Introduction
  29.  
  30.        The data stored in the location registers are automatically  updated  and
  31. the main information is related to the location of the mobile station. The  data
  32. is updated when the mobile station moves from one area to another. The  loss  of
  33. this information would have an important impact on the service provided  to  the
  34. relevant mobile subscribers. It is therefore necessary to define solutions to limit 
  35. the perturbations following a register failure and to restore automatically these 
  36. tables.
  37.  
  38.        This Recommendation describes some methods that could be  implemented  in
  39. order to provide a good security of the data stored in the location registers and 
  40. procedures that could be performed to restore the location data and supplementary 
  41. services data after a location register failure.
  42.  
  43.        However, the implementation of  these  methods  and  procedures  are  not
  44. mandatory and are open to technical innovation.
  45.  
  46. 2.     Technical realizations to achieve the objectives
  47.  
  48.        To avoid a loss of all the data stored in  a  location  register  when  a
  49. failure occurs, it is necessary to implement a periodic safeguard of the memories. 
  50. This method is normally used in the telephone exchanges where a copy of the tables 
  51. is made periodically in order to allow a  restart  if  a  control  unit  failure
  52. occurs. This back-up can be made on either a disc device or a magnetic tape.
  53.  
  54. 3.     Restoration of the location register memories
  55.  
  56.        The perturbations due to a deterioration of the location tables  and  the
  57. restoration procedures are different if the equipment affected is a  home  or  a
  58. Visitor Location Register.
  59.  
  60. 3.1    The visitor location register
  61.  
  62. 3.1.1  Status of the data after a failure
  63.  
  64.        When a visitor  location  register  failure  occurs,  some  discrepancies
  65. between the actual location of the mobile station and the location information stored 
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77. may appear in the following cases:
  78.  
  79.        i)   since the last safeguard, the mobile moved to another location  area
  80.             in the same MSC area; the allocated roaming number  remains  correct
  81.             but the location area information is wrong;
  82.  
  83.        ii)  the mobile appeared in the MSC area after the last  safeguard;  this
  84.             mobile is then unknown by the visited location register while the home 
  85.             location register stored a roaming number corresponding to this  new
  86.             location;
  87.  
  88.        iii)      the mobile left the MSC area; a roaming number is allocated  in
  89.             the visitor register but the updating was made in the home register;
  90.  
  91.        iv)  the mobile left the MSC area and then came  back;  for  the  visitor
  92.             register, the mobile did not leave the MSC area and the previous roaming 
  93.             number is considered as correct by the visitor  register  while  the
  94.             home register stored another roaming number given  during  the  last
  95.             updating made before the failure. The location area information saved may 
  96.             not be the relevant one.
  97.  
  98. 3.1.2  Restoration procedures
  99.  
  100.        When a failure occurs, the data concerning  only  a  small  part  of  the
  101. mobiles located in the relevant area are lost. Therefore, it seems that a systematic 
  102. restoration method such as a general interrogation of the home location registers 
  103. would load the network and the equipments for so small a result.
  104.  
  105.        The restoration process is then the following:
  106.  
  107.        At the restart of the register each element of the memory is pointed  out
  108. by an indicator. This  indicator  is  turned  out  when  the  relevant  location
  109. information has been checked.
  110.  
  111.        a)   Outgoing calls
  112.  
  113.             When the restart occurs, each outgoing call from a  mobile  will
  114.             initiate   the    checking    operation    of    its    location
  115.             information.
  116.  
  117.             -    if the mobile is already registered in the MSC  area,  the
  118.                  location area information is updated, if necessary, but
  119.                  the location updating procedure is not initiated with the home 
  120.                  register (case i) solved);
  121.  
  122.             -    if the mobile is unknown in this MSC area, a roaming number
  123.                  is   allocated   to   that    station    and    a    location
  124.                  updating  procedure  is  started  with  the   home   register
  125.                  (case ii) solved).
  126.  
  127.        b)   Incoming calls
  128.  
  129.                         Concerning the incoming calls, in the cases ii) and iv) described 
  130.             above, the roaming number received by the MSC in the IAM  does  not
  131.             correspond to the right mobile station. In some cases,  it  is  not
  132.             allocated or it may be allocated to another mobile; this depends on the 
  133.             method used to allocate this number. The normal solution (see  also
  134.             note) to detect this difficulty is that the Initial Address Message 
  135.             received by the MSC  during  the  call  set-up  contains  also  the
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.             international ISDN number of the called subscriber. If this is the case, the 
  143.             visitor location register can check the couple to detect a possible 
  144.             mistake. If an inconsistency is noticed,  the  MSC  sends  then  an
  145.             Unsuccessful Backward Message to inform the originating exchange that is 
  146.             is unable to complete the call. The VLR interrogates  the  relevant
  147.             HLRs (the mobiles may be attached to two different HLRs) to correct 
  148.             its tables. Two interrogations have to be performed:
  149.  
  150.             -    one about the mobile station to which the VLR  allocated  this
  151.                  wrong roaming number (MS 1);
  152.  
  153.             -    the other about the station to which  the  call  was  destined
  154.                  (MS 2).
  155.  
  156.                  i)  The MS 1 left its MSC area; the VLR erases it from its
  157.                      table  and  updates   it   by   allocating   the   roaming
  158.                      number  to  MS  2  which  is   introduced   in   the   VLR
  159.                  tables.      The   data   attached   to   that   station   are
  160.                  requested from     its HLR; 
  161.  
  162.                  ii) The MS 1 is still in the MSC area:
  163.  
  164.                      - the VLR allocates a new roaming number to that 
  165.                        station and then updates the relevant HLR; 
  166.                      - the MS 2 is introduced in the VLR table and the 
  167.                        parameters  attached  to  that  station   are
  168.                  requested       from its HLR.  
  169.             If the mobile station left its location area since  the  last
  170.             safeguard,   the   paging   message    sent    will    remain
  171.             unanswered and the mobile will be considered as lost  or  out
  172.             of  service.  To  improve  the  service,  the  call   message
  173.             may be sent in all  the  location  areas  controlled  by  the
  174.             MSC.  If  the  mobile  answers,  the   location   information
  175.             is then  updated.  If  not,  the  mobile  is  considered  out
  176.             of reach and the appropriate unsuccessful end-of-selection message is sent backwards.
  177.  
  178.             If the mobile is switched off when it is called, the  result  is
  179.             the same as the above.
  180.  
  181. Note - As a national option, the HLR may use the "send parameter  from  VLR"
  182. operation of MAP to obtain the MSRN from the VLR on a per call  basis.  This
  183. is normally allowed only within a PLMN.
  184.  
  185.        c)   Particular cases
  186.  
  187.                         In case iii), as the mobile leaves the area, no traffic is 
  188.             related to that mobile; restoration is then impossible and a roaming 
  189.             number is frozen for nothing.  To solve  this  problem,  if  the
  190.             validation of the location information does not occur after a certain 
  191.             delay (in the order of one  day  or  more),  the  VLR  may  then
  192.             interrogate the HLR to know if this station is still located in its 
  193.             area. This method can also  solve  cases  ii)  and  iv)  if  the
  194.             corresponding mobiles have a very low traffic.
  195.  
  196. 3.2    The home location register
  197.  
  198.        The deterioration of the data contained in the home location register 
  199. is of concern not only for the PLMN but also for the whole service. The home 
  200. location register needs the help of all the visitor registers in  charge  of
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212. the MSC areas where its mobiles are located.
  213.  
  214.        When a restart of the home location register occurs, a specific reset 
  215. message is sent to all the visitor location registers to inform them about
  216. the failure. As the home register is unable to know the addresses of all the visitor 
  217. registers in service, the only  solution  is  to  send  the  message  only  to  the
  218. registers known. The list is extracted from the tables saved previously; of course some 
  219. modifications occurring since the last back-up are lost and therefore some  visitor
  220. registers involved in the control of mobiles managed by this home register will not be 
  221. contacted. But the number of registers forgotten will be very low. Another solution 
  222. could be that the reset message is sent only to the "neighbour" VLRs; a specific table 
  223. giving the addresses of these VLRs is then  contained  in  the  HLR  memories.  The
  224. content of that table is defined by the operating people according to the roaming traffic 
  225. of the mobile managed by this HLR. In  that  case  too,  the  number  of  forgotten
  226. registers will be very low.
  227.  
  228.        After receiving this reset message, when a mobile concerned by  the  failure
  229. sends a radio message, to update its location, to set up an outgoing call, to answer 
  230. an incoming call or a request coming from the MSC  or  to  activate  or  request  a
  231. supplementary service, the relevant visitor location register will initiate a location 
  232. updating procedure with the home location register. The latter then updates its tables 
  233. and validates the relevant data.
  234.  
  235.        If, after a certain delay, the location of some mobiles  is  not  confirmed,
  236. the home register interrogates the relevant visitor registers. If a positive answer 
  237. can be obtained, the location information is validated. If not, because the  mobile
  238. left the MSC area between the back-up and the failure, an alarm message may be given to 
  239. the technical staff in order to inform them about the loss of the location of  this
  240. subscriber.
  241.  
  242. 3.3    Periodic registration
  243.  
  244.        The delay to confirm the location of a subscriber after a failure depends on 
  245. the traffic of this station. If a station is silent for a long time,  it  would  be
  246. difficult to know if the location information stored is correct or not during  this
  247. period.
  248.  
  249.        A solution to reduce this delay is to force the mobile  to  send  a  message
  250. when it remains still during a long time. For that purpose, a time-out is reinitiated 
  251. at each message sent by the mobile. When this time-out expires, the station sends a 
  252. location updating message to the base station. A rough estimate  of  this  time-out
  253. value may be a few hours (this value is to be fixed according to traffic simulations and 
  254. it seems that it could be comprised between 12 and 24 hours); if  the  IMSI  detach
  255. procedure when switched off is not used, to avoid an overload of the control channel in 
  256. the morning, this time-out runs only when the station is  switched  on.  With  this
  257. method, the delay during which the mobile can be lost is less than the duration of this 
  258. time-out. The interruption of the time-out when the station is switched off is not a 
  259. problem because it is then unable to  receive  any  call;  therefore,  the  service
  260. provided to that subscriber is not degraded. If the IMSI detach procedure is used, the 
  261. first message sent by the mobile when it is switched on is the IMSI attach; in that 
  262. case the interruption of the time-out may or may not be implemented.
  263.  
  264. 4.     Restoration of the supplementary service parameters
  265.  
  266.        As well as the location data, the supplementary service  parameters  may  be
  267. disturbed when a register failure occurs. Therefore, it is necessary to define methods 
  268. to restore them.
  269.  
  270. 4.1    VLR fault recovery
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. a)     When the VLR fails, the HLR is able to retrieve the activation status of the 
  279. supplementary services. However, if the visitor location register does not  require
  280. any information from the home location register  in  order  to  comply  with  a  MS
  281. supplementary services activation request, the involved data are not available in the HLR 
  282. when the VLR fails. This situation cannot appear if the location area is  the  only
  283. information in the VLR which is unknown from the HLR. Otherwise, it would be necessary 
  284. to include in the deregistration request  and  in  the  location  cancellation  ack
  285. messages sent by the VLR to HLR the parameters of activations which would be only known 
  286. from the VLR.
  287.  
  288. b)     After the restart of a VLR, risks of inconsistency appear between the tables 
  289. of the VLR and of the HLR:
  290.  
  291.        -    relating to incoming calls,  the  mobile  may  have  recently  modified
  292.             activation status of supplementary services; reverse charging acceptance, 
  293.             diversion call on no reply, connect when free...;
  294.  
  295.        -    relating to outgoing  calls,  this  method  allows  checking  of  other
  296.             parameters; conditional barring of outgoing calls, preferential closer used 
  297.             group ... .
  298.  
  299.        Two few mobiles are involved in this situation  to  justify  the  systematic
  300. interrogation of the HLR by the VLR so it  is  suggested  that  the  VLR  sends  an
  301. information request message to the HLR if, and only if, one SS at least was registered in the 
  302. saved tables of the VLR. This message must request from the HLR all  parameters  of
  303. supplementary services that are related to the mobile.  Moreover, as soon as the data 
  304. of supplementary services are validated in the tables of the VLR, an indicator  has
  305. to be turned out.
  306.  
  307.        The retrieval procedures are not influenced by handover.
  308.  
  309. 4.2    HLR fault recovery
  310.  
  311.        When the restart of a home  location  register  occurs,  the  loading  of  a
  312. previously saved state is useful. However, the mobile may have changed its parameters of 
  313. registration or activation since the last back-up  of  the  HLR;  these  cases  are
  314. presented here.
  315.  
  316. 4.2.1  Retrieval of SS-registration status
  317.  
  318.        If the mobile station changed recently, by administrative means, the list of 
  319. the supplementary services for which it contracts a subscription, the operation can 
  320. be lost by the system when the HLR fails. It seems important to avoid this situation 
  321. with a high security.
  322.  
  323.        When the MS requests, by signalling means, the HLR to provide a registration 
  324. for a specific supplementary service, this capability being additional to  that  of
  325. providing subscriptions by administrative means, the HLR has to save this command with 
  326. a high level of security, against an eventual HLR failure. After that, the HLR  can
  327. send back a category/supplementary services information acknowledge message to  the
  328. VLR.
  329.  
  330. 4.2.2  Retrieval of SS-activation status
  331.  
  332.        After the HLR failure, the information which is related to  the  activations
  333. of supplementary services by a not-registered station are available in no VLR.
  334.  
  335.        Therefore, the reset message which is sent by the reinitialized HLR  to  all
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347. VLRs should contain implicitly an information request about the current  activation
  348. status of the supplementary services. Since in some cases the VLR may not know these 
  349. data, the relevant parameters should be held in the mobile  equipment.  To  recover
  350. them, two possibilities are available:
  351.  
  352.        -    to include this request into a "search" message, from the  VLR  towards
  353.             the MSC, and then to send a category/supplementary services information 
  354.             message to the HLR; however, the HLR cannot recover by this method  the
  355.             data associated with the non- registered mobiles;
  356.  
  357.        -    to wait for the next mobile originating message and to indicate to  the
  358.             mobile the loss of supplementary services status  in  the  system;  the
  359.             simplest solution is that the information is only given after a  status
  360.             request message from the mobile; but the quality of the service would be 
  361.             improved if the information was introduced into a field of any originating 
  362.             mobile message acknowledgement. It may be envisaged, too, that the mobile 
  363.             station equipment or the subscriber card contain the description of all 
  364.             supplementary service parameters.
  365.  
  366. 4.3    MSC fault recovery
  367.  
  368.        No information is stored in the home or visitor location  register  for  the
  369. following services:  
  370.        -    charging information (different forms of facilities)
  371.  
  372.        -    credit card call
  373.  
  374.        -    debit card call
  375.  
  376.        -    reverse charging, MS originating call
  377.  
  378.        -    completion of calls to busy subscriber, MS orig. and term. calls.
  379.  
  380.        All these services are invoked on a call per call basis; if the VMSC  fails,
  381. the location registers  cannot  help  the  MSC  to  recover  the  contexts  of  the
  382. established calls. There is no difference with a normal fixed exchange.  
  383.