Mobile Application Part (MAP) -

Transcription

1 GPP X.S000--E v.0 Date: April 00 Mobile Application Part (MAP) - VICE FEATURE SCENARIS: FLEXIBLE ALERTING CPYRIGHT GPP and its rganizational Partners claim copyright in this document and individual Ps may copyright and issue documents or standards publications in individual rganizationial Partner s name based on this document. Requests for reproduction of this document should be directed to the GPP Secretariat at secretariat@gpp.org. Requests to reproduce individual rganizationial Partner s documents should be directed to that rganizational Partner. See for more information.

2 REVISIN HISTRY Revision Date Remarks X.S000--E v.0 April 00 Initial publication.

3 X.S000--E v.0 0 INTRDUCTIN Unless otherwise noted, the scenarios in this part depict features operating individually; i.e., feature interactions are not considered unless specifically noted. The scenarios in this part do not include a complete listing of operation parameters, either in the figures or in the accompanying text descriptions. Parameters are included where they are deemed necessary to improve the understanding of the scenario. For a complete description of the parameters associated with each operation, refer to Parts and 0. FLEXIBLE ALERTING This section depicts the interactions between network entities in various situations related to automatic roaming and Flexible Alerting (FA). These scenarios are for illustrative purposes only.. FA Membership Activation or De-Activation The information flows required for the activation or de-activation of membership in the member s default or specified FA group by an authorized MS are described in Part Section.. - INTRDUCTIN

4 X.S000--E v.0. FA Invocation call origination This scenario describes an invocation of FA. The FA group is comprised of three members: one member is a PSTN DN, FA-DN; the other two members are MSs, served by the same HLR and currently served by the same. These two MSs will be referred to as MIN and MIN throughout this part. riginating System LCREQ [DGTSDIAL, TRANSCAP] LRT call setup start call progress treatment call leg setup to FA-DN HLR call leg setup to TLDN call leg setup to TLDN release call leg to TLDN release call leg to FA-DN RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] routreq [TLDN] routreq [TLDN] call leg answered by TLDN Figure FA Invocation VLR Serving System RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] locreq [GRPINF, NATIME, TERMLIST, REDIND, TERMTRIG] routreq [TLDN] routreq [TLDN] TLDNAT TLDNAT a b c d e f g h i j k l m n o p q r 0 FLEXIBLE ALERTING -

5 X.S000--E v.0 0 a. A call origination and the dialed MS address digits (i.e., directory number) are received by the riginating. b. The riginating sends a LCREQ to the HLR associated with the MS; this association is made through the dialed MS address digits (which may not be the MIN). The riginating may optionally include the TransactionCapability parameter to specify the appropriate termination handling. c-f. The HLR recognizes the called number as an FA Pilot DN and that, based on the received TransactionCapability parameter, the riginating is capable of supporting an FA call. In this case, the two MSs in the FA group are registered in the same system; therefore, two RUTREQs are sent to the Serving VLR and the VLR forwards the RUTREQs to the Serving. LegInfo: FA parameters for call leg to MIN: [AlertCode] Include for distinctive alerting of MIN. [LegInformation] [netimefeature- Indicator] [TerminationTriggers] LegInfo: Used for HLR identification of call leg to MIN. Include at HLR option. Modify feature processing for the duration of this call leg. Include if termination trigger points are active for call leg to MIN. FA parameters for call leg to MIN: [AlertCode] Include for distinctive alerting of MIN. [LegInformation] [netimefeature- Indicator] [TerminationTriggers] Used for HLR identification of call leg to MIN. Include at HLR option. Modify feature processing for the duration of this call leg. Include if termination trigger points are active for call leg to MIN. g-j. In reaction to each RUTREQ, the Serving checks its internal data structures and determines that the MS is currently idle, then allocates a TLDN and returns this information to the VLR in a routreq. The VLR sends each routreq to the HLR. k. When all routreqs are received by the HLR, it returns a locreq to the riginating. The locreq includes multiple-termination routing information in the form of the TerminationList parameter, along with an indication of the reason for extending the incoming call (i.e., for FA) in the DMH_RedirectionIndicator parameter. TERMLIST List of FA group members identification information, from first member to last. R GRPINF Information associated with the FA Pilot DN. NATIME Indication of how long, in seconds, the riginating should wait before applying no answer treatment. Include to override riginating default. TERMTRIG Indicates active termination trigger points for members not having TerminationTriggers inside the TerminationList. - FLEXIBLE ALERTING

6 X.S000--E v.0 l. n receipt of the locreq, the riginating may start call progress treatment to the calling party, if it has not already done so. m. The riginating provides call treatment as indicated in the locreq. In this case, the treatment is to attempt to establish, in parallel, calls to the FA-DN... n....to the TLDN, and... o....to the TLDN. In general, these calls may require outgoing trunks or be internal to the riginating. For each call attempt, the riginating monitors call progress; based on this information, it applies appropriate call progress treatment to the calling party. p. The party at TLDN answers. The riginating connects the calling party to the party at TLDN. q. The riginating releases the call to TLDN, and... r. The riginating releases the call to FA-DN. 0 FLEXIBLE ALERTING -

7 X.S000--E v.0. FA Invocation with a Busy FA Group Member (Single- User Type) This scenario describes an invocation of FA where a member busy condition is encountered. The FA group is comprised as described in Section.. The FA group is the single-user type (i.e., the FA group is considered busy when a member of the FA group is busy). riginating System Serving System HLR VLR 0 call origination LCREQ [DGTSDIAL, TRANSCAP] RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] LRT RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] routreq [TLDN] routreq [TLDN] routreq [ACCDEN=Busy] routreq [ACCDEN=Busy] locreq [ACCDEN=Busy] TLDNAT busy indication Timeout Figure FA Invocation with a Busy FA Group Member (Single-User Type) a b c d e f g h i j k l m a-f. g-h. i-j. Same as FA, Section., Steps a-f. In reaction to the RUTREQ received in Step-d, the Serving checks its internal data structures and determines that the MS is currently idle, then allocates a TLDN and returns this information to the VLR in a routreq. The VLR sends the routreq to the HLR. In reaction to the RUTREQ received in Step-f, the Serving checks its internal data structures and determines that the MS is currently busy in another call. The status of the MS is returned to the VLR by the Serving in the routreq. The VLR sends the routreq to the HLR. - FLEXIBLE ALERTING

8 X.S000--E v.0 k. The HLR determines from the service profile that the FA group is a single-user type; therefore, the group is considered busy (i.e., since MIN is busy). The HLR returns the busy status to the riginating in the locreq. l. The riginating then returns a busy indication to the calling party. m. The Serving detects that the TLDN Association Timer (TLDNAT) set for a MS expires; therefore, it frees the TLDN for other use and removes the record associated with that TLDN. 0 FLEXIBLE ALERTING -

9 X.S000--E v.0. FA Invocation with a Busy FA Group Member (Multiple-User Type) This scenario describes an invocation of FA where a member busy condition is encountered. The FA group is comprised as described in Section.. The FA group is the multiple-user type (i.e., the FA group is considered busy when all members of the FA group are busy). riginating System Serving System HLR VLR 0 call origination LCREQ [DGTSDIAL, TRANSCAP] RUTREQ [MIN, LegInfo] LRT RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] routreq [TLDN] routreq [TLDN] routreq [ACCDEN=Busy] routreq [ACCDEN=Busy] locreq [GRPINF, NATIME, TERMLIST, REDIND, TERMTRIG] strart call progress treatment TLDNAT call leg setup to FA-DN call leg setup to TLDN call leg answered by TLDN release call leg to FA-DN Figure FA Invocation with a Busy FA Group Member (Multiple-User Type) a b c d e f g h i j k l m n o p a-f. Same as FA, Section., Steps a-f. g-j. Same as FA, Section., Steps g-j. k. The HLR determines from the service profile that the FA group is a multiple-user type; therefore, the group is not considered busy even though MIN is busy. The HLR returns a locreq to the riginating. The locreq includes multiple- - FLEXIBLE ALERTING

10 X.S000--E v.0 termination routing information in the form of the TerminationList parameter, along with an indication of the reason for extending the incoming call (i.e., for FA) in the DMH_RedirectionIndicator parameter. TERMLIST List of FA group members identification information, from first member to last, excluding the busy member. GRPINF Information associated with the FA Pilot DN. NATIME Indication of how long, in seconds, the riginating should wait before applying no answer treatment. Include to override riginating default. TERMTRIG Indicates active termination trigger points for members not having TerminationTriggers inside the TerminationList. l. n receipt of the locreq, the riginating may start call progress treatment to the calling party, if it has not already done so. m. The riginating provides call treatment as indicated in the locreq. In this case, the treatment is to attempt to establish, in parallel, calls to FA-DN, and... n....tldn. In general, these calls may require outgoing trunks or be internal to the riginating. For each call attempt, the riginating monitors call progress; based on this information, it applies appropriate call progress treatment to the calling party. o. The party at TLDN answers. The riginating connects the calling party to the party at TLDN, and... p. The riginating releases the call to FA-DN. R 0 FLEXIBLE ALERTING -

11 X.S000--E v.0 0. FA Invocation with a No Answer FA Group Member with Member Redirection call origination This scenario describes an invocation of FA where a member no answer condition is encountered and forwarding is done on the member. The FA group is comprised as described in Section.. riginating System LCREQ [DGTSDIAL, TRANSCAP] LRT strart call progress treatment call leg setup to FA-DN HLR call leg setup to TLDN call leg setup to TLDN redreq release call leg to FA-DN routreq [TLDN] VLR Serving System RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] REDREQ [BILLID, LEGINF, REDREASN] TRANUMREQ [BILLID, LEGINF, REDREASN, PILT, TRANSCAP] TTNRT tranumreq [ACTCDE, REDIND, TERMLIST] release call leg to TLDN call leg setup to CFNA forward-to-number RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] call leg answered by TLDN release call leg to CFNA forward-to-number routreq [TLDN] routreq [TLDN] routreq [TLDN] locreq [GRPINF, NATIME, TERMLIST, REDIND, TERMTRIG] TLDNAT TLDNAT Figure FA Interaction with CFNA on FA Group Member page or answer timeout on MIN RDRT a b c d e f g h i j k l m n o p q r s t u v w x y - FLEXIBLE ALERTING

12 X.S000--E v.0 a-o. Same as FA, Section., Steps a-o. p. When the call for MIN is received at the Serving, the MS is paged and, if a page response is received, subsequently alerted. The MS fails to respond to the page or does not answer after alerting; the Serving determines from the service profile (including the profile overrides based on the TerminationTriggers parameter) that MIN has call forwarding active on no answer or no response to page conditions. q. The Serving sends a REDREQ to the riginating and includes the originating BillingID and RedirectionReason parameters to indicate that the call is being redirected due to a no answer or no page response condition. LEGINF LegInformation. Used for HLR identification of call leg to MIN. Include if available. r. If the riginating is able to redirect the call, it sends a TRANUMREQ to the HLR requesting the forward-to number appropriate for the no answer or no page response condition from the MS s service profile. Refer to Part Section. for procedures if the riginating is not able to redirect the call. BILLID PILT REDREASN LEGINF TRANSCAP BillingID. Used by HLR to relate the transfer request to the original FA call invocation. PilotNumber. May be used by HLR to relate the transfer request to the original FA call invocation. Indicates the reason for requesting a transferto number LegInformation. Used for HLR identification of call leg to MIN. Include if available. Indicates whether or not the riginating is capable of supporting an FA call. s. The HLR may use the BillingID or the PilotNumber and LegInformation to relate the transfer request to the original FA call. It may then check the service profile of the FA Pilot DN for CFNA. If precedence is given to the FA Pilot DN s CFNA and if it is active, the forward-to number is that of the FA Pilot DN. The HLR sends a tranumreq to the riginating, including the appropriate forward-to number, as well as the new value of the LegInformation, in the TerminationList parameter. Also included is an indication of the reason for extending the incoming call (i.e., for CFNA) in the DMH_RedirectionIndicator parameter. ptionally, an ActionCode set to Disconnect call leg may be included. t. When the tranumreq is received from the HLR, the riginating sends a redreq to the Serving. u. The riginating releases the voice path to the Serving. v. The riginating initiates call forwarding using the specified forward-to number. w. The party at TLDN answers. The riginating connects the calling party to the party at TLDN. x. The riginating releases the call to FA-DN, and... y. The riginating releases the call to the forward-to number. R R R R 0 FLEXIBLE ALERTING -

13 X.S000--E v.0 0. FA Invocation with a No Answer FA Group Member with Group Redirection call origination This scenario describes an invocation of FA where a member no answer condition is encountered and forwarding is done on the FA Pilot Group (i.e., The TerminationTriggers from outside the TerminationList are hit). The Pilot HLR is queried and returns a group forwarding number in the TerminationList. The FA group is comprised as described in Section.. riginating System LCREQ [DGTSDIAL, TRANSCAP] strart call progress treatment call leg setup to FA-DN NoAnswerTime expires LRT HLR call leg setup to TLDN call leg setup to TLDN routreq [TLDN] Figure FA Invocation with a No Answer FA Group Member with Group Redirection VLR a-o. Same as FA, Section., Steps a-o. p. The NoAnswerTime in the riginating expires. Serving System RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] routreq [TLDN] TRANUMREQ [BILLID, GRPINF, REDREASN, PILT, TRANSCAP] TTNRT release call leg to FA-DN tranumreq [REDIND, TERMLIST] release call leg to TLDN and TLDN call leg setup to CFNA forward-to-number RUTREQ [MIN, LegInfo] RUTREQ [MIN, LegInfo] routreq [TLDN] locreq [GRPINF, NATIME, TERMLIST, REDIND, TERMTRIG] TLDNAT routreq [TLDN] TLDNAT a b c d e f g h i j k l m n o p q r s t u - FLEXIBLE ALERTING

14 X.S000--E v.0 q. If the riginating is able to redirect the call, it sends a TRANUMREQ, containing the GroupInformation if available, to the HLR requesting the forward-to number appropriate for the no answer or no page response condition from the MS s service profile. Refer to Part Section. for procedures if the riginating is not able to redirect the call. BILLID PILT BillingID. May be used by HLR to relate the transfer request to the original FA call invocation. PilotNumber. May be used by HLR to relate the transfer request to the original FA call invocation. r. The HLR may use the BillingID or the PilotNumber and GroupInformation to relate the transfer request to the original FA call. The HLR sends a tranumreq to the riginating, including the appropriate forward-to number for the FA Group in the TerminationList parameter and an ActionCode set to Drop all call legs. Also included is an indication of the reason for extending the incoming call (i.e., for CFNA) in the DMH_RedirectionIndicator parameter. s. The riginating releases the voice path to TLDN and TLDN, and... t. The riginating releases the call to FA-DN, and... u. The riginating initiates call forwarding using the specified forward-to number. R R 0 FLEXIBLE ALERTING -

15 X.S000--E v.0 0. FA Invocation on Revertive Call to FA Pilot DN This scenario describes the invocation of FA when the call is originated by a member of the FA group whose MDN is the FA Pilot DN. The FA group is comprised as described in Section. (where one of the MDNs in the group is the FA Pilot DN). The FA group is the multiple-user type (i.e., the FA group is considered busy when all accessible members of the FA group are busy). An RREQ is used because the Revertive Call trigger in the riginationtriggers parameter is set. Serving System for MS MS - HLR VLR- - digits + SEND RREQ [DGTSDIAL, MSID, TRANSCAP] LRT start call progress treatment call leg setup to FA-DN release call leg to FA-DN RUTREQ [MIN, LegInfo] Serving System for MS orreq [GRPINF, NATIME, REDIND, TERMLIST, TERMTRIG] call leg setup to TLDN call leg answered by TLDN RUTREQ [MIN, LegInfo] routreq [TLDN] routreq [TLDN] Figure FA Invocation on Revertive Call to FA Pilot DN a. Dialed digits are received by the Serving. b. The Serving detects that the dialed digits correspond to the served MS's MDN and the Revertive Call riginationtriggers is set. The Digits Dialed and TransactionCapability are included in an RREQ and sent from the Serving to the HLR associated with the MS. The MS s MSID is also included. c. The HLR recognizes the called number as an FA Pilot DN and the calling party as the FA Pilot DN (based on the MDN within the subscriber record as identified by the MSID in the RREQ). It also recognizes that, based on the received a b c d e f g h i j k l - FLEXIBLE ALERTING

16 X.S000--E v.0 TransactionCapability parameter, the Serving is capable of supporting an FA call. Therefore, the HLR skips the FA Pilot DN and sends a RUTREQ to the VLR where the other MSs in the FA group (i.e., MIN) is registered. LegInfo: FA parameters for call leg to MIN: [AlertCode] Include for distinctive alerting of MIN. [LegInformation] [netimefeature- Indicator] [TerminationTriggers] Used for HLR identification of call leg to MIN. Include at HLR option. Modify feature processing for the duration of this call leg. Include if termination trigger points are active for call leg to MIN. d. The VLR sends the RUTREQ to the Serving. e. In reaction to the RUTREQ, the Serving checks its internal data structures and determines that the MS is currently idle, then allocates a TLDN and returns this information to the VLR in a routreq. f. The VLR sends the routreq to the HLR. g. The HLR returns an orreq to the Serving. The orreq includes multipletermination routing information in the form of the TerminationList parameter, along with an indication of the reason for extending the incoming call (i.e., for FA) in the DMH_RedirectionIndicator parameter. TERMLIST List of FA group members identification information, from first member to last, excluding the R FA Pilot DN. GRPINF Information associated with the FA Pilot DN. NATIME Indication of how long, in seconds, the riginating should wait before applying no answer treatment. Include to override riginating default. TERMTRIG Indicates active termination trigger points for members not having TerminationTriggers inside the TerminationList. h. n receipt of the orreq, the Serving may start call progress treatment to the calling party, if it has not already done so. i. The Serving provides call treatment as indicated in the orreq. In this case, the treatment is to attempt to establish, in parallel, calls to FA-DN, and... j....tldn. In general, these calls may require outgoing trunks or be internal to the Serving. For each call attempt, the Serving monitors call progress; based on this information, it applies appropriate call progress treatment to the calling party. k. The party at TLDN answers. The Serving connects the calling party to the party at TLDN, and... l. The Serving releases the call to FA-DN. 0 FLEXIBLE ALERTING -

17 X.S000--E v.0 0. FA Invocation on Call from FA Group Member This scenario describes the invocation of FA when the call is originated by a member of the FA group. The other (two) termination addresses in the FA group are directory numbers (DNs). The FA group is the multiple-user type (i.e., the FA group is considered busy when all accessible members of the FA group are busy). MS VLR HLR digits + SEND Serving System call setup routreq [ACCDEN=Busy] RUTREQ [MIN, LegInfo] riginating System LCREQ [DGTSDIAL, TRANSCAP] RUTREQ [MIN, LegInfo] Figure FA Invocation on Call from FA Group Member a. Dialed digits are received by the Serving. b. The Serving establishes a call to the riginating. c. The dialed digits and the TransactionCapability parameter are included in a LCREQ and sent from the riginating to the HLR associated with the MS. d. The HLR recognizes the called number as an FA Pilot DN. It also recognizes that, based on the received TransactionCapability parameter, the riginating is capable of supporting an FA call. The FA group contains three numbers: FA-DN, FA-DN, and the MSID of MS, MIN. If the HLR is aware that the calling party is MS (e.g., via calling party number information in the call setup), it may skip to Step-h. therwise, the HLR constructs a LRT routreq [ACCDEN=Busy] locreq [GRPINF, NATIME, REDIND, TERMLIST, TERMTRIG] start call progress treatment call leg answered by FA-DN call leg setup to FA-DN call leg setup to FA-DN release call leg to FA-DN a b c d e f g h i j k l m - FLEXIBLE ALERTING

18 X.S000--E v.0 RUTREQ and sends it to the VLR where MS is registered. LegInfo: FA parameters for call leg to MIN: [AlertCode] Include for distinctive alerting of MIN. [LegInformation] [netimefeature- Indicator] [TerminationTriggers] Used for HLR identification of call leg to MIN. Include at HLR option. Modify feature processing for the duration of this call leg. Include if termination trigger points are active for call leg to MIN. e. The VLR forwards the RUTREQ to the current Serving. f. In reaction to the RUTREQ, the Serving checks its internal data structures and determines that the MS is busy in another call. The status of the MS is returned to the VLR by the Serving in the routreq. g. The VLR sends the routreq to the HLR. h. Since MS is busy and the FA group is the multiple-user type (i.e., the FA group is considered busy when all accessible members of the FA group are busy), the HLR skips MS and sends a locreq to the riginating. The locreq includes multiple-termination routing information in the form of the TerminationList parameter, along with an indication of the reason for extending the incoming call (i.e., for FA) in the DMH_RedirectionIndicator parameter. TERMLIST List of FA group members identification information, from first member to last, excluding the R busy member. GRPINF Information associated with the FA Pilot DN. NATIME Indication of how long, in seconds, the riginating should wait before applying no answer treatment. Include to override riginating default. TERMTRIG Indicates active termination trigger points for members not having TerminationTriggers inside the TerminationList. i. n receipt of the locreq, the riginating may start call progress treatment to the calling party, if it has not already done so. j. The riginating provides call treatment as indicated in the locreq. In this case, the treatment is to attempt to establish, in parallel, calls to FA-DN, and... k....fa-dn. In general, these calls may require outgoing trunks or be internal to the riginating. For each call attempt, the riginating monitors call progress; based on this information, it applies appropriate call progress treatment to the calling party. l. The party at FA-DN answers. The riginating connects the calling party to the party at FA-DN, and... m. The riginating releases the call to FA-DN. 0 FLEXIBLE ALERTING -