Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements

Definitions

• the present invention relates to the field of the wireless digital communication networks and more precisely to a method to safely check whether a CS or PS domain in an UMTS network node is still properly working or it is out of service.
• the description will be provided for a UMTS FDD and TDD system, where this item well fits due to the specific network architecture, but can be easily extended to other kinds of cellular networks, like for instance GSM, which make use of a similar network architecture.
• GSM Global System for Mobile communications
• Fig.1 reports a general block diagram of a UMTS system.
• the system is constituted by a Core Network (CN), an Access Network as the 3GPP UTRAN 1 and a plurality of User Equipments (UE).
• the Access Network includes a plurality of base stations, called NodeBs (NB), connected via radio to the served UEs and via terrestrial lines to one ore more respective Radio Network Controllers RNC.
• NBs NodeBs
• RNC Radio Network Controller
• Two-way connections between NBs and RNC take place either directly on E1 lines or by means of an interposed STM multiplexer/demultiplexer, MP, for E1/STM-1 lines.
• the simplified Core Network includes the following network elements named: MSC, SGSN, and MGW.
• MSC is specific for serving Circuit Switched (CS) domain, SGSN for Packet Switched (PS) domain, while MGW performs the gateway function between the two CN domains and each domain and the Access Network.
• CS Circuit Switched
• PS Packet Switched
• MGW performs the gateway function between the two CN domains and each domain and the Access Network.
• the connections between the Core and the Access Network take place either straightforward or by an interposed ATM network with switches MP for STM lines at the two sides.
• the Core Network is connected to a PSTN, the IP network, and even other PLMNs.
• the various Network Elements represented in fig.1 are connected to each other via standardised line interfaces such as: the Uu air interface between the UEs and NodeBs; the lub interface between RNC and NodeBs; the lur interface between two RNCs with the same or adjacent cells; the Iu(CS) interface between RNC and MSC 1 and the Iu(PS) interface between RNC and SGSN.
• standardised line interfaces such as: the Uu air interface between the UEs and NodeBs; the lub interface between RNC and NodeBs; the lur interface between two RNCs with the same or adjacent cells; the Iu(CS) interface between RNC and MSC 1 and the Iu(PS) interface between RNC and SGSN.
• a NB is composed of one or more cells; inside a cell the NB is responsible of the radio transmission and reception of the signals to/from the User Equipments (UE).
• the NB is further responsible of Layer 1 (physical) protocol stack as well as of the requested line protocols for interfacing the RNC.
• the controller RNC is responsible of Layer 2 (RLC, MAC) and Layer 3 (RRC) protocol stacks, as well as of the requested line protocols for interfacing the Core Network and the controlled NBs.
• the Core Network is responsible for routing both signalling and payload relevant to the CS and PS domains between the originating and terminating nodes at the two sides.
• a CN domain (or for the UTRAN) to inform the UTRAN (or a CN domain) of its congestion state sending a RANAPJDVERLOAD message. It is possible as well for the UTRAN (or for a CN domain) to send either a RANAP_RESET message or a RANAP_RESET_RESOURCE message to a CN domain (or UTRAN) to force the reset of allocated resources:
• the RANAPJDVERLOAD message informs the far entity that the sending part, though still working, is congested, thus suggesting the receiving part to restrict the access to its services. This procedure allows at a given extend for signalling flow control between the interacting nodes.
• the RANAP_RESET message is used by the sender to re-initialise the receiver in the event of a failure at the sender side. This procedure actually tears down every communication currently established between the message sender and the message receiver.
• the RANAP_RESET_RESOURCE message informs the receiver of a failure event at the sender, so that the receiver can locally reset the status of the affected resources. This procedure tears down a specific signalling connection currently established between the message sender and the message receiver. All these procedures refer to the case that either the congested node, or the faulty one, informs the peer entity about its specific condition triggering a consequent action.
• the UTRAN can selectively restrict the access of the camped UE to a specific CS or PS domain via System Information (see Ref.[1]).
• System Information see Ref.[1]
• the 3GPP Standard, up to Release 6 included, provides the following mechanisms to control the access to a CN domain by the UTRAN:
• UEs can still camp on a cell characterized in this manner, but they are not allowed to access to the disabled Core Network domain services.
• This solution can be used to bar the access to a CN domain which results to be temporarily out of service. It is worth to remark that, while it is sensible to apply this solution for restricting the access to the PS domain, this may not be the case for the CS domain. In fact, inhibiting the access to the CS domain, implies to inhibit Emergency Calls as well.
• 3GPP specifications see Ref.[2]
• a cell not allowing for emergency calls is not even suited to be camped on, meaning that barring the CS CN domain actually corresponds to bar the cell.
• UTRAN knows whether a specific CN domain is out of service or properly working.
• the UTRAN it is not always possible for the UTRAN to get this information and take the consequent appropriate actions. For example it may happen that the far node (e.g. MSC or SGSN) crashes before informing the peer entity that it is going to run out of service. This can be the case that in consequence of a failure in the processor handling the RANAP at the far node, it is not in the condition to signal its temporarily unavailability to the peer entity.
• the far node e.g. MSC or SGSN
• the unavailability of a RNC which is not signalled over the Iu interface will induce the CN domain continuously try without success to send messages, e.g.: paging, to the unavailable RNC.
• the consequence is an increase of the load in the CN processors and waste of Iu transport resources.
• signalling the unavailability of the RNC which is actually properly working brings to that the CN domain will not try to send messages, e.g.: paging, to the available RNC causing loss of service.
• An object of the present invention is that to overcome the drawbacks of the prior art and indicate a method by which an Access Network Node can safely check the in service or out of service status of a specific CS or PS domain of a Core Network Node, to prevent the mobile terminals of accessing to the services provided by the out of service domain.
• "Safe” check here means "without resetting" active connections.
• Dual object of the present invention is that to indicate a method by which a Core
• Network Node can safely check the in service or out of service status of a specific Access Network Node, to prevent sending messages to mobile terminals camped on an out of service Access Network Node.
• 3GPP specifications do not foresee any means by which a UTRAN RNC can safely check the status of a CS or PS domain inside the Core Network, the same happens in the opposite direction.
• the invention achieves said objects by providing a method performable in a local node of a digital cellular communication system to discriminate between the out of service or in service status of a connected remote node, as disclosed in claim 1.
• a local node which detects an internal alarm or perceives a run time congestion relatively to its call processor/s during the execution of usual CS and/or PS procedures with one or more remote nodes, starts an interrogation of the interconnected remote nodes sending a new RANAP-compliant status request message towards a specific domain of said nodes.
• the local node shall wait for an acknowledgement message from each interrogated node within a first defined time interval ⁇ T1 , after that the previous sending/waiting step can be repeated up to N times, "N" being an integer equal to or greater than 1.
• each interrogated remote node shall reply with an acknowledgement message from the specific domain within a second time interval ⁇ T2.
• the local node if no acknowledgement is received from a remote node within ⁇ T1 time interval to the last sent status request message, concludes that the enquired specific domain is out of service in that remote node. Hence the local node carries out known preventive actions directed to inhibit to the mobile terminals the access to services provided by the specific domain deemed to be unavailable in the non responding remote node.
• the local node (optionally) sends an alarm/warning indication to the Operation & Maintenance Centre (OMC) about the not responding node.
• OMC Operation & Maintenance Centre
• the local node continues to send the status request message to the domain deemed to be out of service in the non responding node.
• the local node In case the local node receives the acknowledgement message from said remote node, it concludes that the specific domain becomes available again in that node and therefore it can restore those services previously inhibited, resetting the alarm/warning indication at the OMC if previously sent.
• the aforementioned preventive actions are depending on which local node is starting the safely check. In case that the UTRAN is the interrogating node and MSC and SGSN are the checked nodes, said preventive actions consist in updating the System Information SIB1 and/or SIB3/SIB4 or, alternatively, in discarding the messages received from the camped mobile terminals and directed to the unavailable domain.
• a possible preventive action consists in discarding the Paging messages directed to the unavailable UTRAN.
• the purpose of the Paging procedure is to enable the CN to request the UTRAN to contact UEs camped on that UTRAN.
• the paging procedure uses connectionless signalling.
• the status request and the acknowledgment messages can be sent in connectionless mode.
• the method of the invention contains an enquiry procedure on the status of a remote node.
• This procedure enables a local node, UTRAN or a specific CS or PS CN domain, to detect the true status of a remote node, a specific CS or PS domain or a UTRAN, in case the status information become de-facto impossible to be communicated by the remote node due for example to a crash in a remote node or to an interruption in the connection at the relevant interface, respectively Iu(CS) and Iu(PS).
• the local node shall therefore act in a manner to deduce from itself if a remote node domain is run out of service.
• This task may be indirectly performed beginning with checking the occurrence of a run time congestion of the internal call processor/s, so as to trigger the sending of enquiring messages and waiting for the corresponding replies.
• the congestion can be due to the overload of the call processors caused by a sudden increase on the signalling traffic generated by the repeated failed attempts to access the unavailable remote domain.
• the pair of status request and the respective acknowledgement messages is replaced by RESET_RESOURCE and RESET_RESOURCE_ACKNOWLEDGE messages already existing in the RANAP protocol (see Ref.[3]).
• the Information Element named "Iu Signalling Connection Identifier” shall include a code used by none of the currently handled connections or a fictitious code recognised as such on the Iu interface. It can be appreciated the originality of this variant consisting of using in a new way this pair of existing RANAP messages appositely standardized for selectively tear down established connections at the Iu interface. The new use is aimed to avoid the reset of active connections at the Iu interface: just the contrary of the standard proposal. This is possible because according to the current standardization (see Ref.[3]) it happens that:
• the list of active connections is known at the local node, so that this node is aware of the unassigned codes.
• An alternative to the check of the list of unassigned codes is that to reserve some fictitious codes at the purpose of the far node enquiry procedure, avoiding their assignment to any real Iu connection.
• the remote node when reads an unassigned code in the "Iu Signalling Connection Identifier" of the RESET_RESOURCE message, is forced to reply in any case with the RESET_RESOURCE_ACKNOWLEDGE message.
• - fig.2 shows the main network elements interconnected through the Iu interface of the UMTS network of fig.1 and the MTP-3 signalling protocols running on said network elements;
• - fig.3 shows the protocol stack at the Iu interface towards the CS domain of the CN network;
• fig.4 shows the protocol stack at the Iu interface towards the PS domain of the CN network;
• - fig.5a shows the structure of a new STATUS_REQUEST message transmitted at the Iu interface according to the safely check method of the present invention
• - fig.5b shows the structure of the STATUS_REQUEST_ACKNOWLEDGE message to the previous STATUS_REQUEST message
• - fig.6a shows the structure of the existing RESET_RESOURCE message (see Ref.[3]) transmitted at the Iu interface according to an alternative embodiment of the method of the present invention
• - fig.6b shows the structure of the RESET_RESOURCE_ACKNOWLEDGE message to the previous RESET_RESOURCE message
• figures 7 to 10 show some sequential diagrams embodying the safely check method of the present invention.
• MGW elements of fig.1 and between the MGW and both MSC and SGSN elements is highlighted together with the relevant signalling standard parts.
• OSI Open System Interconnection
• a sub-system N that consists of one or more layer entities N, interacts only with the sub-systems placed above and beneath.
• a layer entity N performs functions within the layer N it belongs to.
• peer entities For the communication among N entities of equal layer (peer entities) a protocol called peer-to-peer is used.
• the information unit that is exchanged through a peer-to-peer protocol is called N-PDU (N-Protocol Data Unit), it includes data and a control information N-PCI (N-Protocol Control Information).
• N-PDU N-Protocol Data Unit
• N-PCI N-Protocol Control Information
• Radio Access Bearer service provides the capability of transmission of signals between access points according to either connection-oriented or connectionless mode and an assigned QoS class.
• connection oriented mode a logical association called connection needs to be established between the source and the destination entities before information can be exchanged between them.
• connectionless mode no connection is established beforehand between the source and the destination entities; the source and destination network addresses need to be specified in each message.
• Fig.3 reports the protocol stacks at the Iu interface relevant to the CS domain.
• Protocol stacks are horizontally subdivided into Radio Network Layer and Transport
• Fig.4 reports the protocol stacks at the Iu interface relevant to the PS domain. Horizontal and vertical subdivisions are similar to fig.3.
• the Iu interface consists of four protocol stacks:
• a data transport stack for the circuit switched traffic also called CS user plane.
• a data transport stack for the packed oriented traffic also called PS user plane.
• a transport signalling protocol stack which is responsible for setting up the AAL2 (see ITU Recommendation 1.363.2 [4]). Its top layer is also called ALCAP (see ITU Recommendation Q.2630.1 [5]).
• the transport signalling stack is foreseen for the CS domain only.
• a Control signalling stack which comprises - RANAP (see TS 25.413 [3]); - Connection Management (CM), Session Management (SM), Mobility Management (MM) and GPRS Mobility Management messages which are sub-layers of the Non Access Stratum (NAS) layer;
• SCCP Signalling Connection Control Part
• MTP3-B Message Transfer Part Layer 3 Broadband
• SSCF-NNI Service Specific Coordination Function
• SSCOP Service Specific Connection Oriented Protocol
• ATM Asynchronous Transfer Mode
• the RANAP messages are used in some standard congestion control procedures, without safely check, already mentioned in the introduction.
• the RANAP protocol is placed at the top of the Control Plane of the Iu interface. It is responsible for the transmission of a large variety of control information to be exchanged between the Serving RNC (S-RNC) and the Core Network (MSC as well as SGSN).
• S-RNC Serving RNC
• MSC Core Network
• RAB management for the establishment, modification or release of one or more RABs for one specified UE.
• Mobility Management Idle State (only LAI or RAI known in the CN).
• the permanent Id of the UE is sent from the CN to the S-RNC to enable a co-ordination of the paging of the UE from PS and the CS CN domains.
• STATUS_REQUEST used in a preferred embodiment of the invention is shown in fig. 5a.
• the content of the STATUS_REQUEST_ACKNOWLEDGE reply message is shown in fig.5b .
• These new messages are represented in the figures according to the tabular form used to represent the 3GPP RRC messages.
• the description of the IEs already mentioned in Ref.[3] is referred to the corresponding Paragraphs indicated in the table.
• the following two IEs are created ex-novo: "Status" and "congestion cause”.
• the Range of the "Status” is enumerated as: congested, out of service, and in service.
• the "congestion cause” is coded as the "IE Establishment cause” defined in Ref.[1].
• the presence of the IE called "CN Domain Indicator” allows to discriminate between CS and PS domains.
• the two messages can be sent either by the UTRAN or by the specific CN domain using connectionless signalling.
• Figures 6a and 6b reproduce the existing RANAP messages RESET_RESOURCE and RESET_RESOURCE_ACKNOWLEDGE (see Ref.[3]) which are presently used in a proprietary way not foreseen by the current standardization.
• these two messages replace those represented in the figures 5a and 5b. They can be sent either by the UTRAN or by the specific CN domain, using connectionless signalling.
• the presence of the IE called "CN Domain Indicator” allows to discriminate between CS and PS domains.
• a code unused by the handled connections is assigned to the IE called "Iu Signalling Connection Identifier".
• a fictitious code recognised as such by all the Network Nodes is used.
• the field ⁇ maxnoofluSigConlds> means: Maximum no. of Iu signalling connection identifiers; a possible value is 250.
• Fig.7 shows a first embodiment of the safely check method of the present invention valid in case the CS CN domain fails. It is shown the scenario where the UTRAN is congested and starts enquiring the CS CN domain, assuming that the PS domain is correctly working and with that it is not indicated in fig.7. In the first part of Fig.7 it is assumed that the CS CN domain is yet working, as responding to the STATUS_REQUEST message sent by the UTRAN. Whereas in the second part of Fig.7, it is assumed that the CS CN domain is run out of service..
• the RNC perceives an overload of its call processors.
• the RNC starts an interrogation of the CS CN domain to test if the cause of congestion is due to a failure on this domain.
• the RNC sends a connectionless STATUS_REQUEST message to the CS domain and waits for a STATUS_REQUEST_ACKNOWLEDGE reply within a first defined time interval ⁇ T1 , after which the sending/waiting steps can be repeated up to N times.
• the RNC shall conclude that the interrogated CS CN domain is properly working, in spite of the run time congestion of its internal call processors.
• the interrogated CS CN domain shall reply with a STATUS_REQUEST_ACKNOWLEDGE message within a second time interval ⁇ T2 from the reception. This is not the case for the CS CN domain because this domain is run out of service (e.g.: due to a temporary failure) causing the perceived congestion.
• the RNC as no STATUS_REQUEST_ACKNOWLEDGE message is received to the last sent STATUS_REQUEST message within ⁇ T1 time, concludes that the enquired CS CN domain is out of service and performs the following actions: • continue to send, at periodical time intervals ⁇ T3, the STATUS_REQUEST message in order to detect whether the enquired CS CN domain becomes available again;
• the CS CN domain returns in service and correctly replies with STATUS_REQUEST_ACKNOWLEDGE message to the enquiry.
• the RNC then assumes that the remote CS CN domain is entered in service again and consequently performs the following actions:
• Fig.8 shows a second embodiment of the safely check method valid in case the
• PS CN domain fails.
• the description of the figure is dual to the preceding case.
• Fig.9 shows a third embodiment of the safely check method valid in case both CN domains, CS and PS, fail but the RNC is not able to detect which of the two domains is run out of service. Therefore in this case the RNC sends two ST ATUS-REQU EST messages, one per CN domain.
• both CN domains reply to the UTRAN enquiry sending the STATUS_REQUEST_ACKNOWLEDGE message, being both properly working.
• no CN domain replies to the UTRAN and therefore both domains are judged to be out of service. .
• the interrogated RNC is addressed by its Global RNC-ID Information Element, while the enquirirng CS and PS domains are indicated by the respective CN Domain Indicators.
• CN domain deduces that the addressed RNC is run out of service, some preventive actions finalized to stop messages towards the unavailable RNC are undertaken, i.e.: discard relevant PAGING messages. These actions are reset in the third part of the procedure when the the RNC sends its acknowledgements to the enquiring CN domains.
• An additional modification is to trigger the sending of the Status Request message immediately after the detection of an internal alarm.
• a further modification consits in that the actions taken to prevent the mobile terminals for accessing the out of service domain is performed discarding messages received by the local node from the camped mobile terminals addressing that speciifc domain.
• ITU-T Recommendation 1.363.2 "B-ISDN ATM Adaptation Layer specification: Type 2 AAL”.
• ITU-T Recommendation Q.2630.1 "AAL type 2 Signalling Protocol (Capability Set 1)".
• ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP)”.
• SSCOP Connection Oriented Protocol
• ITU-T Recommendation 1.432.1 8/96: "ISDN User-Network interfaces, Layer 1 Recommendations, General characteristics".
• ITU-T Recommendation Q.2140 "B-ISDN ATM adaptation layer - Service specific coordination function for signalling at the network node interface (SSCF AT NNI)".

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (1)

Applications Claiming Priority (3)

Publications (1)

Family

ID=34932891

Family Applications (2)

Family Applications Before (1)

Country Status (2)

Families Citing this family (2)

Family Cites Families (2)

• 2004
  • 2004-11-18 EP EP04425858A patent/EP1659811A1/de not_active Withdrawn
• 2005
  • 2005-11-10 WO PCT/IB2005/003417 patent/WO2006054144A1/en active Application Filing
  • 2005-11-10 EP EP05799779A patent/EP1815703A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events