Abstract:
A system and method for handling an error in a LTE Positioning Protocol (LPP) transaction is provided. The method includes the steps of: receiving, by a receiver, at least one of a plurality of LPP messages from a sender, wherein each of the LPP messages has a sequence number; returning, by the receiver, an acknowledgment to the sender for each of the at least one received LPP message; returning, by the receiver, an error indication to the sender when the receiver detects an error in the at least one received LPP message; and receiving, by the receiver, at least one of the at least one received LPP message retransmitted by the sender.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 61/421,752, filed on Dec. 10, 2010, the entirety of which is incorporated by reference herein. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates to LTE Positioning Protocol (LPP), and in particular relates to a system and method for handling an error in LPP messages exchange. 
         [0004]    2. Description of the Related Art 
         [0005]    3GPP (3rd Generation Partnership Project) LPP (Long Term Evolution Positioning Protocol) is used in point-to-point systems between a location server (e.g. Evolved Serving Mobile Location Center (E-SMLC)) and a target device (e.g. a UE accessing E-UTRAN) in order to position the target device using position-related measurements obtained from one or more reference sources.  FIG. 1  shows the LPP configuration for control plane positioning in an E-UTRAN (Evolved Universal Terrestrial Radio Access Network). 
         [0006]    An LPP session is used between a location server and a target device in order to obtain location related measurements or a location estimate or to transfer assistance data. A single LPP session is used to support a single location request (e.g., for a single MT-LR, MO-LR or NI-LR). Multiple LPP sessions can be used between the same endpoints to support multiple different location requests. Each LPP session comprises one or more LPP transactions, with each LPP transaction performing a single operation (e.g. capability exchange, assistance data transfer, or location information transfer). In an E-UTRAN, the LPP transactions are realized as LPP procedures. 
         [0007]    Each LPP transaction involves the exchange of one or more LPP messages between the location server and the target device. The general format of an LPP message consists of a set of common fields followed by a body. The body (which may be empty) contains information specific to a particular message type. Each message type contains information specific to one or more positioning methods and/or information common to all positioning methods. The common fields are shown in Table 1. 
         [0000]    
       
         
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 Field 
                 Role 
               
               
                   
               
             
             
               
                 Transaction ID 
                 Identify messages belonging to the same transaction 
               
               
                 Transaction End 
                 Indicate when a transaction (e.g. one with periodic 
               
               
                 Flag 
                 responses) has ended 
               
               
                 Sequence Number 
                 Enable detection of a duplicate LPP message at a 
               
               
                   
                 receiver 
               
               
                 Acknowledgement 
                 Enable an acknowledgement to be requested and/or 
               
               
                   
                 returned for any LPP message 
               
               
                   
               
             
          
         
       
     
         [0008]    However, LPP is a positioning protocol for an E-UTRAN control plane. Reliable transport functionality of the LPP is not used in the user-plane solution. Therefore, LPP elementary messages (e.g. Request and Provision of Capabilities and Location Information and Assistance Data) of LPP Procedures each include a container, and an external Protocol Data Unit (EPDU), which can be used for standardization for outside 3GPP to define their own extensions to LPP messages. The Open Mobile Alliance Location (OMA LOC) group (OMA-TS-LPPe-V1 — 0) works on LPP extension (LPPe). 
         [0009]    LPP procedures include a capabilities transfer procedure, assistance data transfer procedure, location information transfer procedure, error handling procedure and abort procedure.  FIG. 2  is a diagram for illustrating the LPP error handling procedure. First, a sender  12  sends an LPP message to the receiver  11  in step S 101 . If the receiver  11  detects that the LPP message in S 101  contains an error, the receiver  11  returns an Error message in step S 102  to the sender  12  indicating the error or errors and discards the LPP message received in S 101 . Upon receiving an Error message, the sender  12  aborts ongoing procedures associated with the LPP message or restarts the aborted procedure in response to error information. 
         [0010]    As mentioned above, during normal LPP (e.g. Capabilities Transfer, Assistance Data Transfer, Location Information Transfer) procedures, if there are many (e.g. more than one) messages in the same transaction and an error happens, the receiver aborts ongoing procedures associated with the LPP-Transaction ID indicated in the message. However, earlier successfully delivered/acknowledged messages in this transaction will be discarded. 
         [0011]    In another situation, if an LPP/LPPe message is too large to be transferred on the user plane, a segmented message can be used. During LPP/LPPe transfer procedures, whenever a receiver detects an error in a received segment of the LPP messages from the sender, the receiver may return an LPP Error indication to the sender indicating the error. When this happens, the transfer is terminated, which means earlier delivered/acknowledged segments of the LPP/LPPe messages will be discarded. This is an undesired circumstance, especially when the receiver has successfully received (or acknowledged) a lot of sequential segments of the LPP/LPPe messages when the error happened. The termination of the transfer may cause a lot of wasted message transmissions. 
         [0012]    Therefore, it is desirable to have a flexible way for recovering from an LPP error message in the LPP messages exchange without aborting the ongoing transfer of LPP information, so that transactions of the LPP messages may be coordinated to avoid aborting the ongoing transfer of LPP information and reduce the waste of discarding the earlier delivered/acknowledged LPP messages because of the LPP error. 
       BRIEF SUMMARY OF THE INVENTION 
       [0013]    In one exemplary embodiment, the disclosure is directed to a method for handling an error in Long Term Evolution Positioning Protocol (LPP) messages exchange, comprising: receiving, by a receiver, at least one of a plurality of LPP messages from a sender, wherein each of the LPP messages has a sequence number; returning, by the receiver, an acknowledgment to the sender for each of the at least one received LPP message; returning, by the receiver, an error indication to the sender when the receiver detects an error in the at least one received LPP message; and receiving, by the receiver, at least one of the at least one received LPP message retransmitted by the sender. 
         [0014]    In another exemplary embodiment, the disclosure is directed to a method for handling an error in Long Term Evolution Positioning Protocol (LPP) messages exchange, comprising: receiving, by a receiver, at least one of a plurality of message segments of a LPP extension (LPPe) message from a sender, wherein each of the message segments has a segment number; returning, by the receiver, an acknowledgment to the sender for each of the at least one received message segment; returning, by the receiver, an error indication to the sender when the receiver detects an error in the at least one received message segment; and receiving, by the receiver, at least one of the at least one received message segment retransmitted by the sender. 
         [0015]    In one exemplary embodiment, the disclosure is directed to a system for handling an error in Long Term Evolution Positioning Protocol (LPP) messages exchange, comprising: a sender, transmitting at least one of a plurality of LPP messages, wherein each of the LPP messages has a sequence number; and a receiver, receiving the at least one of the LPP messages and returning an acknowledgment to the sender for each of the at least one received LPP message; wherein the receiver returns an error indication to the sender when the receiver detects an error in the at least one received LPP message, and the sender retransmits at least one of the at least one received LPP message to the receiver. 
         [0016]    In another exemplary embodiment, the disclosure is directed to a system for handling an error in Long Term Evolution Positioning Protocol (LPP) messages exchange, comprising: a sender, transmitting at least one of a plurality of message segments of a LPP extension (LPPe) message, wherein each of the message segments has a segment number; and a receiver, receiving the at least one of the message segments and returning an acknowledgment to the sender for each of the at least one received message segment; wherein the receiver returns an error indication to the sender when the receiver detects an error in the at least one received message segment, and the sender retransmits at least one of the at least one received message segment to the receiver. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]    The present invention can be more fully understood by reading the subsequent detailed description and examples with references made to the accompanying drawings, wherein: 
           [0018]      FIG. 1  is a diagram for illustrating the LPP configuration for control plane positioning in an E-UTRAN; 
           [0019]      FIG. 2  is a diagram for illustrating the LPP error handling procedure; 
           [0020]      FIG. 3  is a diagram for illustrating an LPP message transfer procedure with resume capability based on an LPP error according to an embodiment of the invention; 
           [0021]      FIG. 4  is a diagram for illustrating an LPP/LPPe segmented messages transfer procedure with resume capability based on an LPP error according to an embodiment of the invention; 
           [0022]      FIG. 5  is a diagram for illustrating an LPP message transfer procedure with resume capability based on a request made by a receiver according to an embodiment of the invention; and 
           [0023]      FIG. 6  is a diagram for illustrating an LPP/LPPe segmented messages transfer procedure with resume capability based on a request made by a receiver according to an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0024]    The following description is of the best-contemplated mode of carrying out the invention. This description is made for the purpose of illustrating the general principles of the invention and should not be taken in a limiting sense. The scope of the invention is best determined by reference to the appended claims. 
         [0025]    During normal LPP (e.g. Capabilities Transfer, Assistance Data Transfer, Location Information Transfer) procedures for the control plane, the sender transmits many (e.g. more than one) messages in the same transaction to the receiver.  FIG. 3  is a diagram for illustrating an LPP message transfer procedure with resume capability based on an LPP error according to an embodiment of the invention. As shown in  FIG. 3 , there is merely a receiver  21  and a sender  22  in this transfer procedure, wherein this transfer procedure may be used on the control plane for LPP reliable transport. In this embodiment, the receiver  21  sends an LPP Request message to the sender  22  as part of a new transaction with a transaction ID Tin step S 301 . 
         [0026]    The sender  22  sends the first message of the LPP messages carrying a sequence number S 1  to the receiver  21  in step S 302 . The first message with the sequence number S 1  includes a transaction ID T that is the same as in step S 301 , if step S 301  occurred and does not indicate that the transaction T has ended. The first message with the sequence number S 1  requests for an LPP Acknowledgment. 
         [0027]    Then, the receiver  21  recognizes that the LPP message will be transferred in a sequence of the LPP messages from the indication of the first message in step S 302  and that the transaction T has not ended. The receiver  21  acknowledges receipt of the first message in step S 302  by returning an LPP Acknowledgment to the sender  22  in step S 303 . The receiver  21  may use the LPP Acknowledgment to control the transmit flow of the sender  22 —e.g. the receiver  21  may delay sending the LPP Acknowledgment until the receiver  21  is ready to receive the next message. It is noteworthy that, the LPP Acknowledgment only confirms receipt of the first message with the sequence number S 1  in step S 302  and does not confirm that the first message was necessarily correct (e.g. decodable). 
         [0028]    The sender  22  transfers and the receiver  21  acknowledges the LPP messages with sequence numbers S 2  to S i  by repeating steps S 302  and S 303  in step S 304 . At any time during the transfer, either end may abort the transfer by sending an LPP Abort message to the other end. If the receiver  21  detects an error in a received LPP message from the sender  22 , it may return an LPP Error indication to the sender  22  indicating the error including the transaction ID and the sequence number in step S 305  (e.g., the sequence number is S 3  in step S 305 ) and will not abort the transaction. After receiving the LPP Error indication, the sender  22  does not terminate the transfer. Instead, the sender  22  decides how to resume the transfer of the LPP messages. In one embodiment, the sender  22  may decide to retransmit a part of the LPP messages prior to and including the message corresponding to the received sequence number S 3  sent in the LPP Error indication. This may reduce the traffic load of transferring LPP messages when the sender  22  considers the error type to not be critical. For example, the sender  22  retransmits the LPP messages and the receiver  21  acknowledges the LPP messages with sequence numbers S 2  to S 3  in steps S 306  to step S 309 . In another embodiment, the sender  22  may decide to retransmit the message of the LPP messages corresponding to the received sequence number S 3  sent in the LPP Error indication in step S 308  (i.e., step S 306  and step S 307  can be cancelled). In another embodiment, the sender  22  may retransmit all messages (e.g., the LPP messages with the sequence numbers S 1  to S 3 ) of the LPP messages prior to and including the message corresponding to the received sequence number S 3  sent in the LPP Error indication (not shown in  FIG. 3 ). Then, the sender  22  transfers and the receiver  21  acknowledges the LPP messages with the sequence numbers S 4  to S n-1  by repeating steps S 302  and S 303  in step S 310 . Next, the sender  22  transfers the last (n th ) message of the LPP messages with the sequence number S n  and requests for an LPP Acknowledgment from the receiver  21  in step S 311 . The last message sent by the sender  22  includes an indication for ending the transaction T. Finally, the receiver  21  acknowledges the last message and ends the transaction in step S 312 . 
         [0029]    In another embodiment, if an LPP/LPPe message has a large volume, segmented message transfer can be used. Please note that in this invention, the term LPP/LPPe, as defined in the specifications from the standard organizations (for example, Open Mobile Alliance), stands for LPPe. Both terms LPP/LPPe and LPPe can be equivalently used in this invention. Please refer to  FIG. 4 , which shows a diagram illustrating an LPP/LPPe segmented messages transfer procedure with resume capability based on an LPP Error according to an embodiment of the invention. The LPP/LPPe segmented messages transfer procedure is quite similar to the LPP messages transfer procedure, and reference may be made to the steps of the LPP messages transfer procedure in  FIG. 3 , for most of the LPP/LPPe segmented messages transfer procedure in  FIG. 4 . 
         [0030]      FIG. 4  is a diagram for illustrating an LPP/LPPe segmented messages transfer procedure with resume capability based on an LPP Error according to an embodiment of the invention. As shown in  FIG. 4 , there is merely a receiver  21  and a sender  22  in this transfer procedure, wherein this transfer procedure may be used on the user plane for LPP reliable transport. In this embodiment, the receiver  21  sends an LPP Request message to the sender  22  as part of a new transaction with a transaction ID T in step S 401 . The receiver  21  may include a preference to transfer the LPP messages in a segmented form. Note that such a preference is not mandatory for the sender  22  (i.e., the step S 401  can be ignored). 
         [0031]    The sender  22  may divide the LPP/LPPe message to be transferred to the receiver  21  into n segments. Each segment of the LPP/LPPe message must be capable of being transferred in a well formed LPP/LPPe message (i.e., a message that can be decoded and interpreted independently of any other message). The sender  22  sends the first segment of the LPP/LPPe messages carrying a reliable transport segment number  1  to the receiver  21  in step S 402 . The segment includes a transaction ID T that is the same as in step S 401 , if step S 401  occurred and does not indicate that the transaction T has ended. The first segment requests for an LPP reliable transport Acknowledgment. 
         [0032]    Then, the receiver  21  recognizes that the LPP/LPPe message will be transferred in a segment of the LPP/LPPe message from the indication in step S 402  that the transaction T has not ended. The receiver  21  acknowledges receipt of the first segment in step S 402  by returning an LPP Acknowledgment to the sender  22  in step S 403 . The receiver  21  may use the LPP Acknowledgment to control the transmit flow of the sender  22 —e.g. the receiver  21  may delay sending the LPP Acknowledgment until the receiver  21  is ready to receive the next message segment. It is noteworthy that, the LPP Acknowledgment only confirms receipt of the first segment in step S 402  and does not confirm that the first segment was necessarily correct (e.g. decodable). 
         [0033]    The sender  22  transfers and the receiver  21  acknowledges the LPP/LPPe message segments with the segment numbers  2  to i by repeating steps S 402  and S 403  in step S 404 . At any time during the transfer, either end may abort the transfer by sending an LPP Abort message to the other end. If the receiver  21  detects an error in a received LPP/LPPe message segment from the sender  22 , it may return an LPP Error indication to the sender  22  indicating the error including the transaction ID and the segment number in step S 405  (e.g., the segment number is 3 in S 405 ) and will not abort the transaction. After receiving the LPP Error indication, the sender  22  does not terminate the transfer. Instead, the sender  22  decides how to resume the transfer of the LPP/LPPe message segments. In one embodiment, the sender  22  may decide to retransmit a part of the segments of the LPP/LPPe message prior to and including the segment corresponding to the received segment number  3  sent in the LPP Error indication. This may reduce the traffic load of transferring LPP/LPPe message segments when the sender  22  considers the error type to not be critical. For example, the sender  22  retransmits the segment of the LPP/LPPe message and the receiver  21  acknowledges the segments with segment numbers  2  to  3  in steps S 406  to S 409 . In another embodiment, the sender  22  may decide to retransmit the segment of the LPP/LPPe message corresponding to the received segment number  3  sent in the LPP Error indication in step S 408  (i.e., step S 406  and S 407  can be cancelled). In another embodiment, the sender  22  may retransmit all segments (e.g., the segments with segment numbers  1  to  3 ) of the LPP/LPPe message prior to and including the segment corresponding to the received segment number  3  sent in the LPP Error indication (not shown in  FIG. 4 ). Then, the sender  22  transfers and the receiver  21  acknowledges the segments with the segment numbers  4  to n−1 by repeating steps S 402  and S 403  in step S 410 . Next, the sender  22  transfers the last (n th ) segment of the LPP/LPPe message with the segment number n and requests for an LPP Acknowledgment from the receiver  21  in step S 411 . The last segment sent by the sender  22  includes an indication for ending the transaction T. Finally, the receiver  21  acknowledges the last segment and ends the transaction in step S 412 . 
         [0034]      FIG. 5  is a diagram for illustrating an LPP message transfer procedure with resume capability based on the receiver request according to an embodiment of the invention. As shown in  FIG. 5 , there is merely a receiver  21  and a sender  22  in this transfer procedure, wherein the sender  22  transmits many (e.g. more than one) messages in the same transaction to the receiver  21  during normal LPP (e.g. Capabilities Transfer, Assistance Data Transfer, Location Information Transfer) procedures for the control-plane. In the embodiment, the receiver  21  sends an LPP Request message to the sender as part of a new transaction with a transaction ID Tin step S 501 . 
         [0035]    The sender  22  sends the first message of the LPP messages carrying a sequence number S 1  to the receiver  21  in step S 502 . The first message includes a transaction ID T that is the same as in step S 501 , if step S 501  occurred and does not indicate that the transaction T has ended. The first message with the sequence number S 1  requests for an LPP Acknowledgment from the receiver  21 . 
         [0036]    Then, the receiver  21  recognizes that the LPP/LPPe message will be transferred in a message of the LPP messages from the indication in step S 502  that the transaction T has not ended. The receiver  21  acknowledges receipt of the message in step S 502  by returning an LPP Acknowledgment to the sender  22  in S 503 . The receiver  21  may use the LPP Acknowledgment to control the transmit flow of the sender  22 —e.g. the receiver  21  may delay sending the Acknowledgment until the receiver is ready to receive the next message segment. It is noteworthy that, the LPP Acknowledgment only confirms receipt of the first message with the sequence number S 1  in step S 502  and does not confirm that the message was necessarily correct (e.g. decodable). 
         [0037]    The sender  22  transfers and the receiver  21  acknowledges the LPP messages with sequence numbers S 2  to S i  by repeating steps S 502  and S 503  in step S 504 . At any time during the transfer, either end may abort the transfer by sending an LPP Abort message to the other end. If the receiver  21  detects an error in a received LPP message from the sender  22 , the receiver  21  transmits an LPP Error indication in step S 505  and will not abort the transaction. Then, the receiver  21  decides to transmit an LPP Request message for requesting for the LPP message which the receiver  21  needs. In this embodiment, the receiver  21  detects an error in the message of the LPP messages with sequence number S 3 , and then the receiver  21  transmits an LPP Request message for requesting the message of the LPP messages with the sequence number S 3  in step S 506 . In another embodiment, the receiver  21  may request for specific messages of the LPP messages that are required for recovery from the LPP Error indication. For example, the receiver  21  may transmit an LPP Request message for requesting specific messages of the LPP messages with the sequence number S 2  and S 3 . In another embodiment, the receiver  21  may request for any previous messages of the LPP messages that it considers useful for recovery from the LPP Error indication. For example, the receiver  21  may transmit an LPP Request message for requesting for previous messages of the LPP messages with the sequence numbers S 1  and S 2 . After receiving the LPP Request message in step S 506 , the sender  22  sends the sequence of the LPP messages with the sequence number S 3  to the receiver  21  in step S 507 . The receiver  21  acknowledges the message of the LPP messages with the sequence number S 3  and returns an LPP Acknowledgment to the sender  22  in step S 508 . Then, the sender  22  transfers and the receiver  21  acknowledges the LPP messages with the sequence numbers S 4  to S n-1  by repeating steps S 502  and S 503  in step S 509 . Next, the sender  22  transfers the last (n th ) message of the LPP messages with the sequence number S n  and requests for an Acknowledgment from the receiver  21  in step S 510 . The last message sent by sender  22  includes an indication that the message ended transaction T. Finally, the receiver  21  acknowledges the last message of the LPP messages and ends the transaction in step S 511 . 
         [0038]    In another embodiment, if an LPP/LPPe message is a large volume of messages, segmented messages transfer can be used. Please refer to  FIG. 6 , which shows an LPP/LPPe segmented messages transfer procedure with resume capability based on a request made by a receiver according to an embodiment of the invention. The LPP/LPPe segmented messages transfer procedure is quite similar to the LPP messages transfer procedure, and reference to the steps of the LPP messages transfer procedure in  FIG. 5 , may be made to most of the LPP/LPPe segmented messages transfer procedure in  FIG. 6 . 
         [0039]      FIG. 6  is a diagram for illustrating an LPP/LPPe message transfer procedure with resume capability based on a request made by a receiver according to an embodiment of the invention. As shown in  FIG. 6 , there is merely a receiver  21  and a sender  22  in this transfer procedure, wherein this transfer procedure may be used on the user plane. In the embodiment, the receiver  21  sends an LPP Request message to the sender as part of a new transaction with a transaction ID T in step S 601 . The receiver  21  may include a preference to transfer the LPP messages in a segmented form. Note that such a preference is not mandatory for the sender  22  (i.e. the step S 601  can be ignored). 
         [0040]    The sender  22  may divide the LPP/LPPe message to be transferred to the receiver  21  into n segments. Each segment of the LPP/LPPe messages must be capable of being transferred in a well formed LPP/LPPe message (i.e. a message that can be decoded and interpreted independently of any other message). The sender  22  sends the first segment of the LPP/LPPe message carrying a reliable transport segment number  1  to the receiver  21  in step S 602 . The segment includes a transaction ID T that is the same as in step S 601 , if step S 601  occurred and does not indicate that the transaction T has ended. The first segment requests for an LPP reliable transport Acknowledgment from the receiver  21 . 
         [0041]    Then, the receiver  21  recognizes that the LPP/LPPe message will be transferred in a segment of the LPP/LPPe message from the indication in step S 602  that the transaction T has not ended. The receiver  21  acknowledges receipt of the first segment in step S 602  by returning an LPP Acknowledgment to the sender  22  in S 603 . The receiver  21  may use the LPP Acknowledgment to control the transmit flow of the sender  22 —e.g. the receiver  21  may delay sending the Acknowledgment until the receiver is ready to receive the next message segment. It is noteworthy that, the LPP Acknowledgment only confirms receipt of the first segment in step S 602  and does not confirm that the first segment was necessarily correct (e.g. decodable). 
         [0042]    The sender  22  transfers and the receiver  21  acknowledges the LPP/LPPe message segments with the segment numbers  2  to i by repeating steps S 602  and S 603  in step S 604 . At any time during the transfer, either end may abort the transfer by sending an LPP Abort message to the other end. If the receiver  21  detects an error in a received LPP/LPPe message from the sender  22 , the receiver  21  transmits an LPP Error indication in step S 605  and will not abort the transaction. Then, the receiver  21  decides to transmit an LPP Request message for requesting for the LPP/LPPe message segment which the receiver  21  needs. In this embodiment, the receiver  21  detects an error in the segment of the LPP/LPPe messages with segment number  3 , and then the receiver  21  transmits an LPP Request message for requesting the segment of the LPP/LPPe message with the segment number  3  in step S 606 . In another embodiment, the receiver may request for specific segments of the LPP/LPPe message that are required for recovery from the LPP Error indication. For example, the receiver  21  may transmit an LPP Request message for requesting specific segments of the LPP/LPPe message with the segment numbers  2  and  3 . In another embodiment, the receiver may request for any previous segments of the LPP/LPPe message that it considers useful for recovery from the LPP Error indication. For example, the receiver  21  may transmit an LPP Request message for requesting previous segments of the LPP messages with the segment numbers  1  and  2 . After receiving the LPP Request message in step S 606 , the sender  22  sends the segment of the LPP/LPPe message with the segment number  3  to the receiver  21  in step S 607 . The receiver  21  acknowledges the segment of the LPP/LPPe message with the segment number  3  and returns an LPP Acknowledgment to the sender  22  in step S 608 . Then, the sender  22  transfers and the receiver  21  acknowledges the LPP/LPPe message with the segment numbers  4  to n−1 by repeating steps S 602  and S 603  in step S 609 . Next, the sender  22  transfers the last (n th ) segment of the LPP/LPPe message with the segment number n and requests for an Acknowledgment from the receiver  21  in step S 610 . The last segment sent by the sender  22  includes an indication for ending the transaction T. Finally, the receiver  21  acknowledges the last segment of the LPP message and ends the transaction in step S 611 . 
         [0043]    In the invention, two methods are provided for recovering from an LPP error indication in the LPP messages exchange without aborting the ongoing transfer of LPP information. Using these methods may prevent the discarding of earlier delivered/acknowledged messages in the transaction and may not abort the transaction. 
         [0044]    While the invention has been described by way of example and in terms of the preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements (as would be apparent to those skilled in the art). Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.