BACKGROUND OF THE INVENTION The implementation of the Layer 1 functions has up to now related to the supervision and maintenance of the controlled hard- ware as well as the use thereof.

Different applications, all working at Layer 1, can make a different use of the same hardware, but the hardware as such, be- ing the same, will be supervised and maintained in the same way, independently of what the application is.

For example, the Primary Rate Access of ISDN includes a sec- tionalised maintenance of the digital link according ETSI ETS 300 233 rules, while the other types of accesses do not. Some digital links may be used for connecting the subscribers to the exchange, some others to connect exchanges among them; their handling could result in different implementations of the software managing the Layer 1 functions.

The present technology makes it possible to create compact cards hosting several circuits which implement the Layer 1 func- tions, such as receiver, code transmitters (CSR), Exchange Ter- minals (ETs), echo suppressors (EC) . Therefore, now that several circuits will be hosted on the same card, the need arises to handle a pool of circuits of the same type and with the same char- acteristics.

Taking into account for sake of example ET circuits, when one card was corresponding to one ET circuit, each software prod- uct implementing the Layer 1 functions was controlling its number of ET cards and the concept of common hardware platform was not necessary to be introduced. To have a common supervision and main- tenance of the hardware was indeed not so critical.

Presently, since a common part of the software is intended to the Layer 1 applications (the situation in terms of software products may be, for instance, the one depicted in fig. 1 of the annexed drawings), this part will handle the supervision, testing and maintenance of the hardware.

This results in a few problems, namely: a) Since there is the need to copy the common software part from one Layer 1 application to another one, the risk arises that a fault in this common part affects several different software products.

b) The same card can be configured in different ways accord- ing to the needs, which means that the distribution of the ET cir- cuits among the several Layer 1 applications can differ from a card to another. This might result in some systems to an over- sizing of the files existing within single software products, in order to match them to the maximum number of ET circuits to be controlled on the different cards, leading to a waste of memory usage.

c) In case an automatic change of the card is active in the event of fault, the spare card must be exactly configured as the replaced one, forcing all cards sharing the same spare unit (N+1 redundancy) to have the same distribution of ET circuits among the Layer 1 applications.

d) If a global test of the card is ordered by the operator, this function will have to poll all software products implementing the Layer 1 applications, each for its quote of controlled ET cir- cuits.

e) To introduce a new Layer 1 application involves the repe- tition of the part of commonn software, directly managing the hardware.

Presently no solution to the above mentioned problems is available, also because the possibility to host several circuits having the same function on the same card has been made available by the technology only recently.

SUMMARY OF THE INVENTION The present invention is involved with such problems and satisfactorily solves them by providing a model for the Layer 1 ISO-OSI protocol intended to handle the resources of a common hardware, characterised in that said Layer is divided into two sublayers, the lowest of them (PHLR) being designed to the control functions of a common hardware platform and the highest (PHLU) be- ing designed to the functions of the use of the hardware re- sources.

According to this model, the lowest sublayer (PHLR) does not know which is the use of the hardware resources, the highest sub- layer (PHLU) does not know implementing features of hardware re- sources and the lowest sublayer (PHLR) communicates with the highest sublayer (PHLU) , following a suitable protocol, to provide the services used by the same highest sublayer.

BRIEF DESCRIPTION OF THE DRAWINGS The invention is now further described, referring to the an- nexed drawings, wherein: fig. 1 is a diagram showing the use of a common hardware platform according to the prior art by several Layer 1 applica- tions; fig. 2 shows the sublayered model for the Layer 1 protocol according to this invention; fig. 3 is a diagram showing the use of common hardware re- sources by means of a sublayering model according to the inven- tion; fig. 4 shows a part of a switch system for telephone appar- atuses, where the application of the model for the Layer 1 proto- col according to the invention is particularly useful; fig. 5 shows a further application example of the model of Layer 1 protocol according to the invention; and figg. 6 and 7 show two different uses - respectively accord- ing to prior art and to the present invention - of the cards in magazines of a switch system employed for telephone apparatuses.

DESCRIPTION OF THE PREFERRED EMBODIMENT Referring now to the figures 2 and 3, according to the in- vention, the lowest layer 10 (Physical layer) in a ISO-OSI stack model (fig. 2) is divided into two sublayers: a lower sublayer 11 - referred to as PHLR (PHysical Layer Resources) - designed to im- plement all the tasks related to the hardware management (supervi- sion, maintenance, test), and an upper sublayer 12, referred to as PHLU (PHysical Layer Users) intended to implement all applicative aspects of the Layer 1 usage. Furthermore, fig. 2 shows with the numeral 13 Layer 2 (DDL: Data Link Layer) of the model and simply reports (numeral 14) the highest Layers (UL) 3 to 7.

The implementation of the Layer 1 functions, which according to the prior art was carried out as in fig. 1, is carried out as in fig. 3 when employing the model of Layer 1 of the present in- vention. Thus, the part directly handling the hardware corresponds to the PHLR sub-layer and the Layer 1 applications to the PHLU sublayer. The PHLR sub-layer controls the hardware platform and does not know which is the use of the resources of the common hardware, while PHLU uses just such resources and it does not know the implementing features of the hardware. The PHLR and PHLU sub- layers communicate following a specific protocol, internal to the Layer 1 and - according to ISO-OSI stack model - the lowest sub- layer (PHLR) provides the highest sublayer (PHLU) with the ser- vices used by the latter.

Application Example 1 AUS cards ("Access Unit Switch"), such as the one 20 shown in fig. 4, are employed in a switch system recently developed by the Applicant. In such a card, a first group 21 of ET circuits is employed to connect subscriber 2048 kbits/s lines 22 and a second group 23 of ET circuits is employed in order to connect the sub- scriber stage to the main switch 24 of the exchange, by means of 2048 bits/s lines 25.

A subscriber selector TS (Time Switch) 26 in the AUS card 20 enables the transport of information, both by speech and by signalling, from an ET circuit to another one within the same card.

A group selector GS (Group Switch) 27 in the main switch 24 enables the connection among ET circuits (namely among users) of different AUS cards (only one being shown in fig. 4).

All circuits on AUS card are implemented in the same way, but they are employed for different purpouses.

If the traditional managing model were employed in the above AUS cards - according to which a first software controls the ET circuits used to connect the users and a second, different soft- ware controls the ET circuits employed to connect the subscriber stage to the main switch - there would be no possibility to take advantage of the group of ET circuits of the card as a hardware platform common for several applications extracting and using the hardware resources.

On the contrary, the application to AUS cards of the manage- ment model according to the invention results in: - the possibility to change the number of ET circuits of different cards and to differently distribute them into the ones relevant to users and the ones relevant to the main switch; - the possibility to insert new users of the hardware re- sources, without modifying the manager of the same resources; - an improved software quality, since a sole product manages the whole hardware; - the possibility that the configuration of spare AUS cards is not predefined, since a spare AUS inherits the distribution of ET circuits into users and main switch from the faulty AUS upon the automatic substitution of a faulty AUS; and - as a consequence of the previous item, the possibility not to assign the identical, rigid configuration to each AUS card sharing the same spare card.

Application Example 2 Several not specific hardware cards 31A 31N are in- stalled (fig. 5) in a new magazine 30. They are instanced by a specific firmware in the microprocessor 32A....32N of the same cards, in order to intend the latter to a specific application. In the example in fig. 5, the cards 31A and 31C are instanced in mi- croprocessors 32A and 32C by a firmware which devotes them to ap- plication 1 (numerals 33A in fig. 5), the cards 31B and 31N being instanced in the microprocessors 32B and 32N by a different firm- ware which devotes them to application N (numeral 33N in fig. 5).

The cards 31 involve identical circuits, but the programs down- loaded in respective microprocessors 32 thereon change, depending on the user of each card. All cards but one are used by different applications, the latter card 34 being spared to automatically substitute a possible faulty one.

Such an implementation is only possible with a management model according to this invention, which separates the use of the hardware from its control. Indeed, such a model provides a manager of the common hardware platform that assigns the resources of said platform to the different software users. Since it is a priori un- known which card is going to fail, it may not be foreseen to which application the spare card will be assigned; anyway, according to the managing model of this invention, it is enough to assign the spare card to the software using the faulty one, after instanced by downloading thereon the firmware characteristic of such an application. This would be not possible according to a traditional model, since each user software is also manager of its amount of cards, that is rigidly assigned and it may not be re-configured if mistaken.

The first three advantages listed in the previous example are obtained also according to this application.

Application Example 3 Four ET cards for the connection to the subscriber lines and two ET cards for the connection of the subscriber stage to the main switch are used in the magazines employed by the Applicant to connect the 2048 kbits/s digital subscriber lines in a switch system as the one described in Example 1. These cards are pres- ently controlled by two different softwares, as shown in fig. 6, and the possible problems of the traffic flow between the sides (depending on the kind of connected subscribers) are nowadays solved by providing said magazines with less ET cards on the sub- scriber side, in order to reduce the traffic so that both cards on main switch side can manage it.

The use of the management model according to the invention makes it possible to distribute the six ET cards fully arbitrarily to both applications (subscriber side and main switch side) for each magazine, as shown in fig. 7. A better traffic management results (for instance by assigning three ET cards to the sub- scriber side and three ET cards to the main switch side), while advantage is totally taken of the capacity of each magazine.

Application example 4 The usage of the model of Layer 1 protocol according to the invention is explained below, by means of simplified sequential schemes.

According to the inventive ISO-OSI stack model, the two sub- layers PHLR and PHLU communicate following a specific protocol, internal to the Layer 1 and the lowest sublayer (PHLR) offers ser- vices to the highest one (PHLU) which uses them, as already set forth above.

Primitives within this protocol are for instance the follow- ing ones: From PHLR to PHLU: a) PHLR~fault~ind to report fault in the hardware b) PHLR~fault~cease~ind to report the ceasing of a hardware fault c) PHLR HW change ind to report a change of the hardware due to automatic hardware change in the event of hardware fault From PHLU to PHLR: a) PHLR HW change ans to accept the hardware change b) PHLR HW change~rej to reject the hardware change c) PHLR~user~ind to inform about the PHLU address of the function using the HW.

Both sublayers communicate according to the following se- quential scheme, if no change is provided: PHLR PHLU HW fault PHLR~fault~ind Z HW fault ceasing PHLR fault cease ind According to this scheme, PHLR informs PHLU that a hardware fault is occourring; the latter stops its functions, until the fault ceases, either because spontaneously ceased or because a hand change has taken place in the hardware.

On the contrary, if automatic change is provided, the se- quential scheme is the following: PHLR PHLU HW fault PHLR fault ind HW change PHLR fault change ind HW change acceptable? PHLR~HW changeans PHLR fault cease ind YES PHLR HW change rej NO s According to this scheme, PHLR informs PHLU that a hardware fault is occourring and that a change is possible; PHLU answers whether such a change is acceptable or not; in the first case an automatic hardware change removes the fault; in the second case, the PHLU functions are stopped until the fault ceases, either spontaneously or because a hand change has taken place in the hardware.

The sequential scheme to assign PHLU instances to PHLR in- stances is the following: PHLR PHLU PHLU PHLR user ind in order to let PHLR know which of the PHLU functions is actually using the hardware.

This protocol could comprise other primitives and the list above has not to be exhaustive, but it only shows an example of the interwork between the two sublayers within the Layer 1.

- - ooo O ooo - - The model of Layer 1 protocol according to the invention at- tains a lot of improvements, the most important of them being: - a tidy interface (actually a protocol) is defined between the Layer 1 resource owner (PHLR) and the Layer 1 applications (PHLUs) using those resources; - when applying the model wherein the hardware handling are very well separated - as above - from the hardware usage ones, it is possible to obtain at software level different products imple- menting the two hardware functions with clear interfaces between them; - the part handling the hardware (PHLR sublayer) is unique within the system and is only dependant on the hardware design (different hardware platforms correspond to different instances of the PHLR sub-layer) : thus the problem under item a) (page 2) is solved; - all applicative aspects are left outside the hardware handling function (PHLR) and put in the PHLU sublayer which may consist of several instances interworking with a common PHLR sub- layer (i.e. hardware platform); there is an instance of the PHLU sublayer for each user of the hardware platform and the actual di- stribution of the PHLU functions over different cards implementing the same hardware platform can differ from card to card, being im- plemented in the PHLU sublayer: thus the problem under item b) (page 2) is solved; - in case of hardware fault or hardware change due to an automatic fault recovery, PHLR sublayer only informs the PHLU sub- layer, which is responsible for all decisions in handling this event; this ensure a higher degree of flexibility and the hardware tests and the maintenance activities are smoother and straight- forward; therefore the problem under item d) (page 3) is solved; - the cards where ET circuits are defined need to be config- ured only when used for the traffic; the process of configuration in the spare cards intended to replace faulty cards can be stopped just to the definition of PHLR sublayer, whilst the distribution of PHLU sublayers can be copied from the faulty cards upon the substitution; then, also the problem under item c) (page 3) is solved; - the separation of the control functions from the usage ones of hardware enables an easy addition of software applications that use the resources from an existing hardware platform, due to the well defined protocol between the PHLR and PHLU sublayers, without affecting the existing applications (PHLU) or said plat- form (PHLR); then, also the problem under item e) (page 3) is solved.

Of course, other embodiments and applications of the inven- tion are possible, different from the ones described. Particular- ly, the model according to the invention, when convenient, may be applied to the conventional technology, for instance to cards carrying only one single circuit thereon.