KR20040067655A - OTAPA service method using timer for checking arrival of message error processing in mobile communication system - Google Patents

Abstract

PURPOSE: An OTAPA(Over-The-Air Parameter Administration) service method using a timer to confirm the reception of a message in a mobile communication system is provided to confirm the reception of the next SMDPP(Short Message Delivery Point to Point) request message in order to release a resource unnecessarily occupied due to an abnormal operation of an OTAF(Over-The-Air Activation Function) system when a session is executed between an MSC(Mobile Switching Center) and the OTAF system. CONSTITUTION: An MSC(31), receiving an SMDPP request message for the start of a session from an OTAF system(41), starts the session(300,310). Then the MSC transmits an SMDPP response message to the OTAF system, including a session processing result. If the session normally starts, the MSC receives an SMDPP request message to execute the next function(320). After executing the received message, the MSC transmits an SMDPP response message to the OTAF system(330). If the next SMDPP request message is received, the MSC executes an associated function and transmits an SMDPP response message to the OTAF system with result information for the associated function(340). If an SMDPP request message for the end of the session is received from the OTAF system, the MSC executes session end processing(360) and transmits a session end processing result to the OTAF system through an SMDPP response message(370).

Description

OTPA service method using timer for checking arrival of message error processing in mobile communication system}

The present invention relates to an OTP service method of a mobile communication system, and more particularly to an OTP service method using a timer for acknowledgment of a message at the interface of the OTP system and a mobile switching period to perform an OTP function. will be.

In general, a mobile communication system uses various OTA (Over-The-Air) services to change parameters of a terminal. In these OTA services, a service center (ie, a network operator) uses an OTAA (OTAPA: Over-The-Air Parameter Administration) service to change parameters for a corresponding terminal.

The OTAPA service scenario is described in Section 9.CC.2 of the IS-725-A Specification. The Mobile Application Part (hereinafter referred to as MAP) used for the OTAF (Over-The-Air Activation Function; OTAF) system in the above standard is SMP (Short Message Delivery Point to Point: hereinafter referred to as SMDPP). SMDPP is a MAP between the OTAF system and the exchange for parameter transmission between the terminal and the service center.

1 is a block diagram illustrating a mobile communication system for OTAPA service.

As shown in FIG. 1, the mobile communication system includes a base station 20 wirelessly connected to the terminal 10, a serving system 30, and a home system 40. In this case, a session for parameter transmission between the terminal 10 and the service center is performed between the serving system 30 and the home system 40.

The serving system 30 stores a Mobile Switcing Center (MSC) 31 that receives SMDPP transmitted from the home system 40 and stores subscriber information registered and managed in the mobile switch 31. It consists of a Visitor Location Register (VLR) 32.

The home system 40 is an OTAF system 41 that communicates with the mobile switch 31, and a home location register (HLR) that stores information such as terminal information, service subscription information, and location information in a real-time database. And an authentication center (AC) 43.

In the mobile communication system configured as described above, only the interface part of the OTAPA service scenario and the OTAF system will be described with reference to the accompanying drawings.

2 is a timing diagram illustrating an interface between a mobile switch and an OTAF system for a conventional OTAPA service.

As shown in FIG. 2, as a process of performing one session of the OTAPA function, the mobile exchange 31 receives an SMDPP request message indicating the start of the session from the OTAF system 41 in step 200. Here, the start of the session can be known from the action code value of the SMDPP request message.

Upon receiving the SMDPP request message, the mobile exchange 31 starts a session in step 210. The mobile exchange 31 then sends a smdpp response message containing the session processing result to the OTAF system 41.

When the session starts normally as described above, the mobile exchange 31 receives the SMDPP request message to perform the next function in step 220. Then, in step 230, the mobile exchange 31 processes the requested message and delivers the smdpp response message to the OTAF system 41. These steps 240 to 250 repeat the same operation as the steps 220 to 230 according to the corresponding function required. This may be repeated further depending on the function.

Then, when the mobile exchange 31 receives the SMDPP request message indicating that the end message is the last message from the OTAF system 41 in step 260, the mobile exchange 31 performs the session termination process, in step 270. The result of the session termination process is sent to the system 41 in the response message in the OTAF.

However, unlike the above, when the mobile switch 31 does not transmit the smapp response message to the OTAF system 41, an error occurs. The timer SMT1 is used to handle such an error, and the timer SMT1 is driven whenever an SMDPP request message is received from the OTAF system 41. If an error occurs, the timer is terminated and the session is terminated. Can be processed.

However, in the prior art, the error coping method due to various abnormal operations of the OTAF system 41 after the mobile exchange sends a response message is not considered, and due to this abnormal operation, the error, the following SMDPP message, for example, session termination, is not considered. If it does not receive the SMDPP message indicating that there is a problem that does not release resources for the OTAPA session and continue to occupy unnecessarily.

Accordingly, an object of the present invention is a timer for confirming receipt of a desired next SMDPP request message to release an unnecessary occupied resource due to abnormal operation of the OTAF system when performing a session between a mobile switch and an OTAF system in a mobile communication system. In providing an OTAPA service method using.

The method for achieving the above object of the present invention is a mobile switch that relays a predetermined request message received from an OTP system requesting to perform OTP service to update a parameter of a predetermined terminal to the terminal. In the mobile communication system comprising a step of performing the OAP service in the mobile switch, when the request message is received performing the requested function through the request message, and performing the function And checking whether a response message is transmitted to the OTF system during the first preset timer period, and checking whether the next request message is received during the second preset timer period as the response message is transmitted. Characterized in that.

Another method for achieving the object of the present invention is to move the relay to transmit a predetermined request message received from the OTP system requesting to perform the OTP service to update the parameters of the predetermined terminal to the terminal. In a mobile communication system having a switch, the OTP system performs the OTP service, wherein the OTP system transmits a response message for a preset first timer period after transmitting the request message to the terminal. Confirming that the received message is received, performing a requested function through the response message when the response message is received, and transmitting a next request message during a second preset timer period as the response message is received. Scoop to include course Gong.

1 is a block diagram illustrating a mobile communication system for OTP service;

FIG. 2 is a timing diagram illustrating an interface between a mobile switch and an OTAF system for a conventional OTP service.

3 is a timing diagram illustrating an interface between a mobile switch and an OTAF system for an OTP service according to an embodiment of the present invention;

FIG. 4 is a flowchart illustrating an operation for processing an error generated at an interface between a mobile switch and an OTAF system for an OTP service according to an embodiment of the present invention.

5 is a timing diagram illustrating OTP service operation according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, there are many specific details such as specific messages, etc., which are provided to help a more general understanding of the present invention, and the present invention may be practiced without these specific details. It is self-evident for those who have In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

Processes for performing functions between the mobile exchange and the OTPA system according to an embodiment of the present invention are performed through one OTAPA session, and SMDPP request messages and smdpp response messages are provided between the mobile exchange and the OTAPA system. Interfaced.

3 is a timing diagram illustrating an interface between a mobile switch and an OTAF system for an OTAPA service according to an embodiment of the present invention.

Referring to FIG. 3, the mobile exchange 31 receives an SMDPP request message indicating the start of a session from the OTAF system 41 in step 300. Here, the start of the session can be known from the action code value of the SMDPP request message.

Upon receipt of the SMDPP request message, the mobile exchange 31 starts a session in step 310. The mobile exchange 31 then sends a smdpp response message containing the session processing result to the OTAF system 41.

When the session starts normally as described above, the mobile exchange 31 receives the SMDPP request message to perform the next function in step 320. Then, in step 330, the mobile exchange 31 performs the requested message and then delivers the smdpp response message to the OTAF system 41. Then, if another requested corresponding function exists in step 340, that is, when the next SMDPP request message is received, the mobile exchange 31 performs the corresponding function, and then the smdpp response message carrying the result information of the corresponding function to the OTAPA system 41. Send it. If there is another function to be performed in the current session, the same processes as in steps 340 to 350 are repeated.

Then, when the mobile exchange 31 receives the SMDPP request message indicating that the session is the last message from the OTAF system 41 in step 360, the mobile switch 31 performs the session termination process. The result of the termination process is transmitted in the smdpp response message to the OTAF system 41. In this process, the mobile switch 31 drives the first timer SMT1 for a predetermined period each time the SMDPP request message is received from the OTAF system 41. The mobile exchange 31 drives the second timer for a preset period each time an smdpp response message is sent to the OTAF system 41. The operation of the mobile exchange is briefly described with reference to the flowchart of FIG. 4 in consideration of the case where an error occurs during the session execution process as follows.

Referring to FIG. 4, in step 400, the mobile exchange 31 checks whether the SMDPP request message indicating the start of the session is received by the OTAF system 41. If the check result is not received, step 400 is continued, and if received, the first timer SMT1 is driven in step 410.

Then, in step 420, it is checked whether the first timer has expired. At this time, if it has expired, the session is terminated at step 480. If not, at step 430, if the smdpp response message is transmitted to the OTAPA system 41, it is not transmitted. Check. On the other hand, if the smdpp response message is sent, check whether there is the next function to be performed in step 440. In other words, it checks if there is a desired next SMDPP request message. If there is no next SMDPP request mesh, the session is terminated in step 480, and if there is a next SMDPP request mesh, the second timer SMT2 is driven in step 450. Then, in step 460, the mobile exchange 31 checks whether the second timer SMT2 has expired, and if so, terminates the session in step 480, and if not, in step 470, the mobile switch 31 determines whether the next SMDPP request message has been received. . As a result of the check, if it is not received, step 460 is performed again, and when it is received, the process returns to step 410 to drive the first timer again.

As described above in more detail the operation of the OTAPA service in the mobile communication system according to the present invention.

5 is a timing diagram illustrating an OTAPA service operation according to an embodiment of the present invention.

Referring to FIG. 5, in step 500, the OTAF system 41 requests a parameter update to the home location register 42 when there is a parameter to be updated for the corresponding terminal 10 (hereinafter, referred to as an SMSREQ message). ). The SMSREQ message includes information related to the mobile terminal (MSID: Mobile Station IMSI Detached, ESN: Electrical Serial Number, SRVIND: Service Indicator). The home location register 42 then checks the SRVIND (parameters supporting CDMA OTAPA) of the SMSREQ information and responds to the SMSREQ message containing the parameters (SMS-Address parameters) of the address information of the mobile exchange 31 serving. Hereinafter, an smsreq message) is transmitted to the OTAF system 41.

The OTAF system 41 then sends a SMDPP request message to the mobile exchange 31 informing the start of the session in step 510. In this case, the SMDPP request message includes parameters (MSID, ESN, SRVIND, ACTCODE, etc.) for the information of the terminal 10, and requests OTAPA service, that is, information indicating the start of the session (OTAPA Request) for the corresponding function. It includes an SMS BearerData parameter that contains information. Accordingly, the mobile switch 31 receiving the SMDPP message drives the first timer, changes the channel set with the terminal 10 from the access channel to the call channel, and then includes the data included in the SMDPP request message (hereinafter referred to as SMS_BearerData). Information required for the OTAPA service is extracted and sent to the terminal 10 through the call channel. Then, in step 515, before the first timer expires, information on the response to the OTAPA service start received from the terminal 10 is included in the SMS_BearerData parameter of the smdpp response message and transmitted to the OTAF system 41. At this time, if there is a next message desired, the mobile exchange 31 drives the second timer SMT2.

Then, the OTAF system 41 analyzes the SMS_BearerData in step 520, and if there is a response, the OTAF system 41 sends a message for authentication (Over-The-Air Service Provisioning: hereinafter, OTASPREQ message) for authentication of the terminal 10. The authentication is sent to the authentication center 43 through the register 42. When the authentication processing is completed, the authentication center 43 sends the authentication result information to the OTAF system 41 via the home location register 42 in the response message (otaspreq message) for the OTASPREQ message.

Then a SMDPP request message for the next function to be performed is sent to the mobile exchange 31. For example, if the next function is the authentication process result information, that is, the information for requesting validation (Validation Request), in step 530, the OTAF system 41 sends the SMDPP request message including the validity request information to the mobile exchange 31. To pass. In this case, the validity request information is included in the SMS_BearerData parameter of the SMDPP request message, and the SMDPP message includes information about the terminal.

When the SMDPP request message including the validity request information is received, the mobile exchange 31 drives the first timer SMT1 again, extracts the validity request information from the SMS_BearerData, and delivers the validity request information to the terminal 10. Then, the terminal 10 checks whether the authentication OAPAAU included in the validity request information transmitted from the network matches the value calculated by the terminal. As a result of confirmation, when the transmitted value and the calculated value coincide, the mobile exchange 31 transmits the result information indicating the successful authentication to the OTAF system 41 in the SMS_BearerData parameter of the smdpp response message in step 535.

Then, the OTAF system 41 checks the smdpp response message including the authentication result information, and if there is another function to be performed, transmits the SMDPP message to the mobile exchange 31 to perform the corresponding function. For example, if the download function is performed, the OTAF system 41 sends the download request information to the mobile switch 31 in the SMS_BearerData parameter of the SMDPP message in step 540. In this case, in step 530 to 535, the terminal 10 updates the parameter according to the successful validation. Therefore, the mobile exchange 31 that receives the download request extracts the air interface message, transmits the message to the terminal 10, and drives the first timer SMT1. Accordingly, the terminal 10 responds to the mobile exchange 31 with the extracted information. In operation 545, the mobile switch 31 receives the contents of the terminal 10 loaded in the SMS_Bearer Data parameter and transmits the smsdpp response message including the information on the download response to the OTAF system 41. At this time, the mobile exchange 31 drives the second timer SMT2 if there is a function to be performed next. After these processes, the terminal 10 downloads the actual parameters.

The OTAF system 41 then checks the smdpp response message for the download response and, if there is a message for another function, sends the SMDPP request message for that function to the mobile exchange 31. For example, if there is a storage request function for storing the result data in the permanent memory of the terminal 10 after the download is completed, after the download is completed in step 550, the mobile switch 31 includes the storage request information. Send a SMDPP Request message. The mobile exchange 31 then sends the received storage request message to the terminal 10. Accordingly, the terminal 10 receiving the storage request message stores the downloaded data in the permanent memory. Thereafter, the mobile exchange 31 transmits a smdpp response message including the information on the stored response to the OTAF system 41 in step 555. At this time, if there is a next function to be performed, the second timer SMT2 starts to be driven.

Then, if there is a function to be performed last to terminate the session, the OTAF system 41 transmits a SMDPP request message including information indicating the end of the session to the mobile exchange 31 in step 560. The session termination information is carried in the SMS_Bearer Data parameter of the SMDPP request message. Upon receiving the SMDPP message indicating the end of the session, the mobile switch 31 drives the first timer, extracts the session end information from the SMS_Bearer Data parameter, and sends it to the terminal 10. After receiving the response from the terminal 10, the mobile exchange 31 transmits a smdpp response message for terminating the session to the OTAF system 41 in step 565. Accordingly, the communication channel set between the mobile switch 31 and the terminal 10 is released. The session ends.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, the present invention terminates the session by applying a timer for acknowledging receipt of the next SMDPP request message to be performed by the mobile exchange in order to handle an error generated when the OTAPA service is performed. It is effective to release the resources of the system.

Claims (6)

In a mobile communication system having a mobile switch relaying a predetermined request message received from an OTP system requesting to perform OTP service to update a parameter of a predetermined terminal to the terminal, In the method of performing the OTP service, Performing the requested function through the request message when the request message is received; Checking whether a response message has been transmitted to the OTF system during a first preset timer period after performing the function; And checking whether the next request message is received during the second preset timer period as the response message is transmitted. The method of claim 1, And ending the session if the next message is not received during the second timer period. The method of claim 1, And ending the session if the next message received is the last message. In a mobile communication system having a mobile switching system for relaying a predetermined request message received from an OTP system requesting OTP service to update a parameter of a predetermined terminal to the terminal, the OTP system In the method of performing the OTP service, Confirming whether a response message is received by the OTF system during a preset first timer period after transmitting the request message to the terminal; Performing the requested function through the response message when the response message is received; And transmitting a next request message during a preset second timer period as the response message is received. The method of claim 4, wherein Terminating the session if the response message is not received. The method of claim 4, wherein And ending the session if the next request message is not transmitted during the second timer period.